BGP as-override and allow-as-in

These two functions are pretty similar, just with subtle differences. They can be used in an environment where a customer is using one AS number for many sites that are connected to an ISP. This is shown in the example below.

You can see that AS 65001 connects to the ISP at two locations. So when R2 receives the prefix 99.99.99.99/32, he will see that the AS path is via 1, 65001. Because of the loop prevention mechanism, R2 will have to reject this prefix because it can see its own AS in the AS_PATH attribute. I’ll demonstrate that now. But first, I’m going to post the full configurations because this can be pretty confusing to configure.

PE1#
ip vrf google
 rd 100:1
 route-target export 100:1
 route-target import 100:1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
 ip vrf forwarding google
 ip address 10.10.10.10 255.255.255.0
!
interface FastEthernet0/1
 ip address 15.15.15.1 255.255.255.0
 mpls ip
!
router ospf 1
 network 1.1.1.1 0.0.0.0 area 0
 network 15.15.15.0 0.0.0.255 area 0
!
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 1
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 next-hop-self
 no auto-summary
 !
 address-family vpnv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf google
  neighbor 10.10.10.11 remote-as 65001
  neighbor 10.10.10.11 activate
  no synchronization
 exit-address-family

PE2#
ip vrf google
 rd 100:1
 route-target export 100:1
 route-target import 100:1
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 ip vrf forwarding google
 ip address 20.20.20.20 255.255.255.0
!
interface FastEthernet0/1
 ip address 25.25.25.2 255.255.255.0
 mpls ip
!
router ospf 1
 network 2.2.2.2 0.0.0.0 area 0
 network 25.25.25.0 0.0.0.255 area 0
!
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 1.1.1.1 next-hop-self
 no auto-summary
 !
 address-family vpnv4
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf google
  neighbor 20.20.20.21 remote-as 65001
  neighbor 20.20.20.21 activate
  no synchronization
 exit-address-family

R1#
interface Loopback0
 ip address 99.99.99.99 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.10.10.11 255.255.255.0
!
router bgp 65001
 no synchronization
 bgp log-neighbor-changes
 network 10.10.10.0 mask 255.255.255.0
 network 99.99.99.99 mask 255.255.255.255
 neighbor 10.10.10.10 remote-as 1
 no auto-summary

R2#
interface FastEthernet0/0
 ip address 20.20.20.21 255.255.255.0
!
router bgp 65001
 no synchronization
 bgp log-neighbor-changes
 network 20.20.20.0 mask 255.255.255.0
 neighbor 20.20.20.20 remote-as 1
 no auto-summary

P1#
interface FastEthernet0/0
 ip address 15.15.15.2 255.255.255.0
 mpls ip
!
interface FastEthernet0/1
 ip address 25.25.25.1 255.255.255.0
 mpls ip
!
router ospf 1
 network 15.15.15.0 0.0.0.255 area 0
 network 25.25.25.0 0.0.0.255 area 0
 network 35.35.35.0 0.0.0.255 area 0

So currently, on R2, he is not accepting any prefixes from R1 in the other site; as shown below (we would expect the 10.10.10.0/24 and 99.99.99.99/32 networks to be in the BGP table).

R2#sh ip bgp | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 20.20.20.0/24    0.0.0.0                  0         32768 i

The debug below shows why he’s not accepting these prefixes.

*Mar  1 02:28:03.515: %BGP-5-ADJCHANGE: neighbor 20.20.20.20 Up
*Mar  1 02:28:03.559: BGP(0): 20.20.20.20 rcv UPDATE w/ attr: nexthop 20.20.20.20, origin i, originator 0.0.0.0, path 1 65001, community , extended community
*Mar  1 02:28:03.559: BGP(0): 20.20.20.20 rcv UPDATE about 10.10.10.0/24 -- DENIED due to: AS-PATH contains our own AS;
*Mar  1 02:28:03.559: BGP(0): 20.20.20.20 rcv UPDATE about 99.99.99.99/32 -- DENIED due to: AS-PATH contains our own AS;

One way to fix this is to use the allow-as-in command. This allows R2 to override the loop prevention mechanism by allowing an instance of AS 65001 to be in the AS_PATH. Let’s do that now.

R2(config-router)#neighbor 20.20.20.20 allowas-in 1
R2(config-router)#
*Mar  1 02:34:34.927: BGP: 20.20.20.20 sending REFRESH_REQ(5) for afi/safi: 1/1
*Mar  1 02:34:34.927: BGP: 20.20.20.20 send message type 5, length (incl. header) 23
*Mar  1 02:34:35.015: BGP(0): 20.20.20.20 rcvd UPDATE w/ attr: nexthop 20.20.20.20, origin i, path 1 65001
*Mar  1 02:34:35.015: BGP(0): 20.20.20.20 rcvd 10.10.10.0/24
*Mar  1 02:34:35.015: BGP(0): 20.20.20.20 rcvd 99.99.99.99/32
*Mar  1 02:34:35.019: BGP(0): Revise route installing 1 of 1 routes for 10.10.10.0/24 -> 20.20.20.20(main) to main IP table
*Mar  1 02:34:35.019: BGP(0): Revise route installing 1 of 1 routes for 99.99.99.99/32 -> 20.20.20.20(main) to main IP table
R2(config-router)#do sh ip bgp
BGP table version is 4, local router ID is 20.20.20.21
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.10.10.0/24    20.20.20.20                            0 1 65001 i
*> 20.20.20.0/24    0.0.0.0                  0         32768 i
*> 99.99.99.99/32   20.20.20.20                            0 1 65001 i

So you can see (on R2) that the AS_PATH is 1, 65001 for these prefixes. It keeps all the AS_PATH information and simply just allows 1 occurance of 65001 to be in the AS_PATH; thus overriding the loop prevention mechanism. We would obviously need to do this on R1 in order for R1 to have reachability to the 20.20.20.0/24 prefix (sitting between PE2 and R2) so that he can have a route back to R2.

R1(config)#router bgp 65001
R1(config-router)#neighbor 10.10.10.10 allowas-in 1

R2#ping 99.99.99.99

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 99.99.99.99, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/83/116 ms

The other way you can complete this task is by getting PE1 & PE2 to just strip AS 65001 from the BGP UPDATE before sending it to the customer edge routers. Let’s do that now.

R1(config-router)#no neighbor 10.10.10.10 allowas-in 1
R2(config-router)#no neighbor 20.20.20.20 allowas-in 1

pe2(config)#router bgp 1
pe2(config-router)#address-family ipv4 unicast vrf google
pe2(config-router-af)#neighbor 20.20.20.21 as-override

pe1(config)#router bgp 1
pe1(config-router)#address-family ipv4 unicast vrf google
pe1(config-router-af)#neighbor 10.10.10.11 as-override

By configuring this command it actually resets the peer, so there’s no need to clear any neighbors. The result of this is shown on R2 below.

R2#sh ip bgp | b Network

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.10.10.0/24    20.20.20.20                            0 1 1 i
*> 20.20.20.0/24    0.0.0.0                  0         32768 i
*> 99.99.99.99/32   20.20.20.20                            0 1 1 i

So the AS_PATH has been overridden by the PE routers to their AS number instead. This is the key difference between the two commands. Allow-as-in allowed the loop prevention to be ignored for the configured amount of instances, and the as-override caused the PE routers to modify the AS_PATH.

These two functions are pretty similar, just with subtle differences. They can be used in an environment where a customer is using one AS number for many sites that are connected to an ISP. This is shown in the example below. You can see that AS 65001 connects to the ISP at two locations. So when R2 receives the prefix 99.99.99.99/32, he will see that the AS path is via 1, 65001. Because of the loop prevention mechanism, R2 will have to reject this prefix because it can see its own AS in the AS_PATH attribute. I’ll demonstrate that now. But first, I’m going to post the full configurations because this can be pretty confusing to configure. PE1# ip vrf google rd 100:1 route-target export 100:1 route-target import 100:1 ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface FastEthernet0/0 ip vrf forwarding google ip address 10.10.10.10 255.255.255.0 ! interface FastEthernet0/1 ip address 15.15.15.1 255.255.255.0 mpls ip ! router ospf 1 network 1.1.1.1 0.0.0.0 area 0 network 15.15.15.0 0.0.0.255 area 0 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 2.2.2.2 remote-as 1 neighbor 2.2.2.2 update-source Loopback0 neighbor 2.2.2.2 next-hop-self no auto-summary ! address-family vpnv4 neighbor 2.2.2.2 activate neighbor 2.2.2.2 send-community extended exit-address-family ! address-family ipv4 vrf google neighbor 10.10.10.11 remote-as 65001 neighbor 10.10.10.11 activate no synchronization exit-address-family PE2# ip vrf google rd 100:1 route-target export 100:1 route-target import 100:1 ! interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface FastEthernet0/0 ip vrf forwarding google ip address 20.20.20.20 255.255.255.0 ! interface FastEthernet0/1 ip address 25.25.25.2 255.255.255.0 mpls ip ! router ospf 1 network 2.2.2.2 0.0.0.0 area 0 network 25.25.25.0 0.0.0.255 area 0 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 update-source Loopback0 neighbor 1.1.1.1 next-hop-self no auto-summary ! address-family vpnv4 neighbor 1.1.1.1 activate neighbor 1.1.1.1 send-community extended exit-address-family ! address-family ipv4 vrf google neighbor 20.20.20.21 remote-as 65001 neighbor 20.20.20.21 activate no synchronization exit-address-family R1# interface Loopback0 ip address 99.99.99.99 255.255.255.255 ! interface FastEthernet0/0 ip address 10.10.10.11 255.255.255.0 ! router bgp 65001 no synchronization bgp log-neighbor-changes network 10.10.10.0 mask 255.255.255.0 network 99.99.99.99 mask 255.255.255.255 neighbor 10.10.10.10 remote-as 1 no auto-summary R2# interface FastEthernet0/0 ip address 20.20.20.21 255.255.255.0 ! router bgp 65001 no synchronization bgp log-neighbor-changes network 20.20.20.0 mask 255.255.255.0 neighbor 20.20.20.20 remote-as 1 no auto-summary P1# interface FastEthernet0/0 ip address 15.15.15.2 255.255.255.0 mpls ip ! interface FastEthernet0/1 ip address 25.25.25.1 255.255.255.0 mpls ip ! router ospf 1 network 15.15.15.0 0.0.0.255 area 0 network 25.25.25.0 0.0.0.255 area 0 network 35.35.35.0 0.0.0.255 area 0 So currently, on R2, he is not accepting any prefixes from R1 in the other site; as shown below (we would expect the 10.10.10.0/24 and 99.99.99.99/32 networks to be in the BGP table). R2#sh ip bgp | b Network Network Next Hop Metric LocPrf Weight Path *> 20.20.20.0/24 0.0.0.0 0 32768 i The debug below shows why he’s not accepting these prefixes. *Mar 1 02:28:03.515: %BGP-5-ADJCHANGE: neighbor 20.20.20.20 Up *Mar 1 02:28:03.559: BGP(0): 20.20.20.20 rcv UPDATE w/ attr: nexthop 20.20.20.20, origin i, originator 0.0.0.0, path 1 65001, community , extended community *Mar 1 02:28:03.559: BGP(0): 20.20.20.20 rcv UPDATE about 10.10.10.0/24 -- DENIED due to: AS-PATH contains our own AS; *Mar 1 02:28:03.559: BGP(0): 20.20.20.20 rcv UPDATE about 99.99.99.99/32 -- DENIED due to: AS-PATH contains our own AS; One way to fix this is to use the allow-as-in command. This allows R2 to override the loop prevention mechanism by allowing an instance of AS 65001 to be in the AS_PATH. Let’s do that now. R2(config-router)#neighbor 20.20.20.20 allowas-in 1 R2(config-router)# *Mar 1 02:34:34.927: BGP: 20.20.20.20 sending REFRESH_REQ(5) for afi/safi: 1/1 *Mar 1 02:34:34.927: BGP: 20.20.20.20 send message type 5, length (incl. header) 23 *Mar 1 02:34:35.015: BGP(0): 20.20.20.20 rcvd UPDATE w/ attr: nexthop 20.20.20.20, origin i, path 1 65001 *Mar 1 02:34:35.015: BGP(0): 20.20.20.20 rcvd 10.10.10.0/24 *Mar 1 02:34:35.015: BGP(0): 20.20.20.20 rcvd 99.99.99.99/32 *Mar 1 02:34:35.019: BGP(0): Revise route installing 1 of 1 routes for 10.10.10.0/24 -> 20.20.20.20(main) to main IP table *Mar 1 02:34:35.019: BGP(0): Revise route installing 1 of 1 routes for 99.99.99.99/32 -> 20.20.20.20(main) to main IP table R2(config-router)#do sh ip bgp BGP table version is 4, local router ID is 20.20.20.21 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.10.10.0/24 20.20.20.20 0 1 65001 i *> 20.20.20.0/24 0.0.0.0 0 32768 i *> 99.99.99.99/32 20.20.20.20 0 1 65001 i So you can see (on R2) that the AS_PATH is 1, 65001 for these prefixes. It keeps all the AS_PATH information and simply just allows 1 occurance of 65001 to be in the AS_PATH; thus overriding the loop prevention mechanism. We would obviously need to do this on R1 in order for R1 to have reachability to the 20.20.20.0/24 prefix (sitting between PE2 and R2) so that he can have a route back to R2. R1(config)#router bgp 65001 R1(config-router)#neighbor 10.10.10.10 allowas-in 1 R2#ping 99.99.99.99 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 99.99.99.99, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/83/116 ms The other way you can complete this task is by getting PE1 & PE2 to just strip AS 65001 from the BGP UPDATE before sending it to the customer edge routers. Let’s do that now. R1(config-router)#no neighbor 10.10.10.10 allowas-in 1 R2(config-router)#no neighbor 20.20.20.20 allowas-in 1 pe2(config)#router bgp 1 pe2(config-router)#address-family ipv4 unicast vrf google pe2(config-router-af)#neighbor 20.20.20.21 as-override pe1(config)#router bgp 1 pe1(config-router)#address-family ipv4 unicast vrf google pe1(config-router-af)#neighbor 10.10.10.11 as-override By configuring this command it actually resets the peer, so there’s no need to clear any neighbors. The result of this is shown on R2 below. R2#sh ip bgp | b Network Network Next Hop Metric LocPrf Weight Path *> 10.10.10.0/24 20.20.20.20 0 1 1 i *> 20.20.20.0/24 0.0.0.0 0 32768 i *> 99.99.99.99/32 20.20.20.20 0 1 1 i So the AS_PATH has been overridden by the PE routers to their AS number instead. This is the key difference between the two commands. Allow-as-in allowed the loop prevention to be ignored for the configured amount of instances, and the as-override caused the PE routers to modify the AS_PATH.

Copy and WIN : http://ow.ly/KNICZ

These two functions are pretty similar, just with subtle differences. They can be used in an environment where a customer is using one AS number for many sites that are connected to an ISP. This is shown in the example below. You can see that AS 65001 connects to the ISP at two locations. So when R2 receives the prefix 99.99.99.99/32, he will see that the AS path is via 1, 65001. Because of the loop prevention mechanism, R2 will have to reject this prefix because it can see its own AS in the AS_PATH attribute. I’ll demonstrate that now. But first, I’m going to post the full configurations because this can be pretty confusing to configure. PE1# ip vrf google rd 100:1 route-target export 100:1 route-target import 100:1 ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface FastEthernet0/0 ip vrf forwarding google ip address 10.10.10.10 255.255.255.0 ! interface FastEthernet0/1 ip address 15.15.15.1 255.255.255.0 mpls ip ! router ospf 1 network 1.1.1.1 0.0.0.0 area 0 network 15.15.15.0 0.0.0.255 area 0 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 2.2.2.2 remote-as 1 neighbor 2.2.2.2 update-source Loopback0 neighbor 2.2.2.2 next-hop-self no auto-summary ! address-family vpnv4 neighbor 2.2.2.2 activate neighbor 2.2.2.2 send-community extended exit-address-family ! address-family ipv4 vrf google neighbor 10.10.10.11 remote-as 65001 neighbor 10.10.10.11 activate no synchronization exit-address-family PE2# ip vrf google rd 100:1 route-target export 100:1 route-target import 100:1 ! interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface FastEthernet0/0 ip vrf forwarding google ip address 20.20.20.20 255.255.255.0 ! interface FastEthernet0/1 ip address 25.25.25.2 255.255.255.0 mpls ip ! router ospf 1 network 2.2.2.2 0.0.0.0 area 0 network 25.25.25.0 0.0.0.255 area 0 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 update-source Loopback0 neighbor 1.1.1.1 next-hop-self no auto-summary ! address-family vpnv4 neighbor 1.1.1.1 activate neighbor 1.1.1.1 send-community extended exit-address-family ! address-family ipv4 vrf google neighbor 20.20.20.21 remote-as 65001 neighbor 20.20.20.21 activate no synchronization exit-address-family R1# interface Loopback0 ip address 99.99.99.99 255.255.255.255 ! interface FastEthernet0/0 ip address 10.10.10.11 255.255.255.0 ! router bgp 65001 no synchronization bgp log-neighbor-changes network 10.10.10.0 mask 255.255.255.0 network 99.99.99.99 mask 255.255.255.255 neighbor 10.10.10.10 remote-as 1 no auto-summary R2# interface FastEthernet0/0 ip address 20.20.20.21 255.255.255.0 ! router bgp 65001 no synchronization bgp log-neighbor-changes network 20.20.20.0 mask 255.255.255.0 neighbor 20.20.20.20 remote-as 1 no auto-summary P1# interface FastEthernet0/0 ip address 15.15.15.2 255.255.255.0 mpls ip ! interface FastEthernet0/1 ip address 25.25.25.1 255.255.255.0 mpls ip ! router ospf 1 network 15.15.15.0 0.0.0.255 area 0 network 25.25.25.0 0.0.0.255 area 0 network 35.35.35.0 0.0.0.255 area 0 So currently, on R2, he is not accepting any prefixes from R1 in the other site; as shown below (we would expect the 10.10.10.0/24 and 99.99.99.99/32 networks to be in the BGP table). R2#sh ip bgp | b Network Network Next Hop Metric LocPrf Weight Path *> 20.20.20.0/24 0.0.0.0 0 32768 i The debug below shows why he’s not accepting these prefixes. *Mar 1 02:28:03.515: %BGP-5-ADJCHANGE: neighbor 20.20.20.20 Up *Mar 1 02:28:03.559: BGP(0): 20.20.20.20 rcv UPDATE w/ attr: nexthop 20.20.20.20, origin i, originator 0.0.0.0, path 1 65001, community , extended community *Mar 1 02:28:03.559: BGP(0): 20.20.20.20 rcv UPDATE about 10.10.10.0/24 -- DENIED due to: AS-PATH contains our own AS; *Mar 1 02:28:03.559: BGP(0): 20.20.20.20 rcv UPDATE about 99.99.99.99/32 -- DENIED due to: AS-PATH contains our own AS; One way to fix this is to use the allow-as-in command. This allows R2 to override the loop prevention mechanism by allowing an instance of AS 65001 to be in the AS_PATH. Let’s do that now. R2(config-router)#neighbor 20.20.20.20 allowas-in 1 R2(config-router)# *Mar 1 02:34:34.927: BGP: 20.20.20.20 sending REFRESH_REQ(5) for afi/safi: 1/1 *Mar 1 02:34:34.927: BGP: 20.20.20.20 send message type 5, length (incl. header) 23 *Mar 1 02:34:35.015: BGP(0): 20.20.20.20 rcvd UPDATE w/ attr: nexthop 20.20.20.20, origin i, path 1 65001 *Mar 1 02:34:35.015: BGP(0): 20.20.20.20 rcvd 10.10.10.0/24 *Mar 1 02:34:35.015: BGP(0): 20.20.20.20 rcvd 99.99.99.99/32 *Mar 1 02:34:35.019: BGP(0): Revise route installing 1 of 1 routes for 10.10.10.0/24 -> 20.20.20.20(main) to main IP table *Mar 1 02:34:35.019: BGP(0): Revise route installing 1 of 1 routes for 99.99.99.99/32 -> 20.20.20.20(main) to main IP table R2(config-router)#do sh ip bgp BGP table version is 4, local router ID is 20.20.20.21 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.10.10.0/24 20.20.20.20 0 1 65001 i *> 20.20.20.0/24 0.0.0.0 0 32768 i *> 99.99.99.99/32 20.20.20.20 0 1 65001 i So you can see (on R2) that the AS_PATH is 1, 65001 for these prefixes. It keeps all the AS_PATH information and simply just allows 1 occurance of 65001 to be in the AS_PATH; thus overriding the loop prevention mechanism. We would obviously need to do this on R1 in order for R1 to have reachability to the 20.20.20.0/24 prefix (sitting between PE2 and R2) so that he can have a route back to R2. R1(config)#router bgp 65001 R1(config-router)#neighbor 10.10.10.10 allowas-in 1 R2#ping 99.99.99.99 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 99.99.99.99, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/83/116 ms The other way you can complete this task is by getting PE1 & PE2 to just strip AS 65001 from the BGP UPDATE before sending it to the customer edge routers. Let’s do that now. R1(config-router)#no neighbor 10.10.10.10 allowas-in 1 R2(config-router)#no neighbor 20.20.20.20 allowas-in 1 pe2(config)#router bgp 1 pe2(config-router)#address-family ipv4 unicast vrf google pe2(config-router-af)#neighbor 20.20.20.21 as-override pe1(config)#router bgp 1 pe1(config-router)#address-family ipv4 unicast vrf google pe1(config-router-af)#neighbor 10.10.10.11 as-override By configuring this command it actually resets the peer, so there’s no need to clear any neighbors. The result of this is shown on R2 below. R2#sh ip bgp | b Network Network Next Hop Metric LocPrf Weight Path *> 10.10.10.0/24 20.20.20.20 0 1 1 i *> 20.20.20.0/24 0.0.0.0 0 32768 i *> 99.99.99.99/32 20.20.20.20 0 1 1 i So the AS_PATH has been overridden by the PE routers to their AS number instead. This is the key difference between the two commands. Allow-as-in allowed the loop prevention to be ignored for the configured amount of instances, and the as-override caused the PE routers to modify the AS_PATH.

Copy and WIN : http://ow.ly/KNICZ

Detail to explain how DSL works

This post will go into detail to explain how DSL works end to end between the customer and the ISP. It will be a pretty heavy read, so this ain’t for the light hearted. In the scope of the CCIE RS lab exam you have to know how to configure a broadband access group (a bba-group) on the ISP side, and also how to configure PPP on the client side. For me, that isn’t enough detail/reality in order to get a good understanding of how DSL works, so this post will explain how connectivity works in a real life scenario. In this post if you are not from the UK, when I mention BT, assume I’m talking about a mainline telephone/internet provider. So in America this would be equivalent of Comcast, or Germany would be Deutsche Telekom, or France would be Orange etc.
Understanding connectivity using standard copper cabling
When customers need to connect to an ISP using DSL, they do so via their normal telephone lines. If your using a Cisco 1800/2800 sereis router you need a WIC card, usually a HWIC-1ADSL-M card (which is backwards compatible with ADSL, ADSL2 and ADSL2+ for Annex A, as well as supporting Annex M), or HWIC-1VDSL if you’re using a 1900/2900 series router. Effectively what these WIC’s do is just provide an interface to the ATM network between your customer router and the DSLAM. The diagram below represents basic customer router connectivity to the DSLAM & the BRAS (I’ll talk about the BRAS in just a moment). The reason I’ve put a cloud between the customer router and DSLAM is just to represent that loads of customers will be connecting to this DSLAM via the ATM network.


Ok, so at the other end of the ATM cloud is where the telephone exchange is located. The copper pair from each customer goes into a huge patch pannel, called the Main Distribution Frame (MDF). This is then connected to the DSLAM using something like this 50pin RJ21 to RJ11 cable shown below. So the RJ11 ends would plug into the MDF, and each copper pair relating to that RJ11 would be wired into the RJ21 connector at the end of the cable, which would then connect to the DSLAM. This one cable would allow one RJ21 connector to support 24 DSL subscriber lines.

The DSLAM now needs to connect to the Broadband Remote Access Server (BRAS). The functionality of the BRAS is to authenticate the end users PPP session in order to gain access to BT’s network. It can also send PPP sessions to other ISP’s for authentication, but I’ll dig into that in just a sec. But basically what you need to know is that a bunch of subscribers will connect from the MDF into the DSLAM, and then all these subscibers will use the uplink towards the BRAS router via the ATM cloud.
From the DSLAM to the BRAS then, the connection can either be done by Ethernet or ATM. Traditionally it was done via ATM. So the DSLAM would be connected to an ATM switch (which would just be there to take connections from a bunch of DSLAMs in the exchange) which would be configured to create a Permanent Virtual Circuit (PVC) between the BRAS and the DSLAMs using ATM sub-interfaces. This PVC is then mapped to a subscriber line-id, which is basically just a VLAN on the DSLAM that has been used for a particular local loop copper pair towards a customer.
The connection between the DSLAM and the BRAS could also be done via Ethernet instead of ATM, but requires just a little more config to embed the subscriber line-id into the PPP discovery frame. All this does is just tell the BRAS which DSLAM contains which subscriber-id.

Terminating PPP sessions to a third party ISP
Ok, I’ve made a simplified diagram of the network above so that I can explain how to terminate PPP sessions to a third party ISP, for this example lets just say Plusnet is the 3rd party ISP. See the diagram below.

So in order for another ISP to authenticate DSL subscriber PPP sessions (i.e. Plusnet’s customers), we need a way of tunneling the layer 2 ppp session over towards the ISP’s router. The way this is done is by using Layer 2 Tunneling Protocol. So when the PPP session is initiated from the customer, it includes some authentication parameters, such as the CHAP username and password. Typically the username would contain a domain name such as stevegarbett@plusnet.net and some random password. Technically the plusnet.net is considered a realm in the ISP world, and it’s this parameter that the BRAS uses to decide where to forward the PPP session. The L2TP tunnel is then created between the BRAS (also known as a Layer 2 Access Conecntrator, LAC, since it’s creating a load of layer 2 tunnels to different ISPs/locations) and the ISP’s Layer 2 Network Server (LNS) router based on the PPP realm sent from the customer.
In short, the customer creates a PPP sessions to the ISP. The session hits BT’s LAC who do a lookup on the realm (usually using a RADIUS server). Then the LAC forwards this over to the LNS over in Plusnet’s ISP. The ISP authenticates the customers PPP credentials, which then gives the customer access to the service provider network. So the layer 2 forwarding path at a very high level overview is just from the customers router to the ISP’s LNS.
The ISP then provides connectivity to the rest of the world using a transit ISP. Basically, what this means is that Plusnet will have an upstream transit service provider that they create a BGP peering session with. The transit provider will be have a tonne of BGP peers in various peering exchanges across the country that connect to other ISP’s, which effectively create the internet. Some peering exchanges I’ve used myself are LINX and LONAP in London.

NAT server on Huawei USG5500

The last article dealt with outbound NAT. Let's focus today on NAT server. NAT server enables private network servers to provide services for external networks with public IP addresses. In this lab, our enterprise provides FTP services for external users.

We can use the topology from the last post:

In our case AR router works as FTP server:

#
FTP server enable
aaa
 local-user labnario password cipher qGj8!H#yx.ajUn1vMEIB1lG#
 local-user labnario privilege level 3
 local-user labnario ftp-directory flash:
 local-user labnario service-type ftp
#
interface GigabitEthernet0/0/1
 ip address 172.16.1.254 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 172.16.1.1

Configuration of Internet router:

#
interface GigabitEthernet0/0/2
 ip address 1.1.1.2 255.255.255.0
#
ip route-static 1.1.1.100 255.255.255.255 1.1.1.1

Firewall USG5500 configuration

Set IP addresses of interfaces and add them to proper security zones:

[SRG]dis current-configuration interface GigabitEthernet 
#
interface GigabitEthernet0/0/1
 ip address 172.16.1.1 255.255.255.0
#
interface GigabitEthernet0/0/2
 ip address 1.1.1.1 255.255.255.0

[SRG]display current-configuration configuration zone 
#
firewall zone untrust
 set priority 5
 add interface GigabitEthernet0/0/2
#
firewall zone dmz
 set priority 50
 add interface GigabitEthernet0/0/1

Configure interzone packet filtering to ensure that users in Untrust zone can access the FTP server in DMZ zone:

[SRG]display current-configuration configuration policy-interzone 
#
policy interzone dmz untrust inbound
 policy 1
  action permit
  policy service service-set ftp
  policy destination 172.16.1.254 0

Configure internal server. Create a mapping relation between public and private IP addresses of FTP server:

[SRG]nat server 0 protocol tcp global 1.1.1.100 ftp inside 172.16.1.254 ftp

Configure the NAT ALG function for the DMZ-Untrust interzone to ensure that the server provides FTP services for extranet users normally:

[SRG]display current-configuration configuration interzone 
#
firewall interzone dmz untrust
 detect ftp

What is NAT ALG for? NAT translates only IP addresses in IP packet headers and port information in TCP/UDP packet headers. In our case, the firewall must identify the IP address and port number in the payload field of the FTP application, to continue NAT processing. Without NAT ALG, the NAT process fails.

Verification of NAT server

[SRG]display firewall session table verbose
 Current Total Sessions : 1
  ftp  VPN:public --> public
  Zone: untrust--> dmz  TTL: 00:10:00  Left: 00:09:52
  Interface: GigabitEthernet0/0/1  NextHop: 172.16.1.254  MAC: 54-89-98-91-56-e2
  <--packets:6 bytes:363   -->packets:8 bytes:364
  1.1.1.2:61428+->1.1.1.100:21[172.16.1.254:21]

[SRG]display nat server 
Server in private network information:
 id                : 0                  
 zone              : ---           
 interface         : ---           
 global-start-addr : 1.1.1.100           global-end-addr   : ---                
 inside-start-addr : 172.16.1.254        inside-end-addr   : ---                
 global-start-port : 21(ftp)             global-end-port   : ---                
 insideport        : 21(ftp)            
 globalvpn         : public              insidevpn         : public             
 protocol          : tcp                 vrrp              : ---                
 no-reverse        : no                 

  Total   1 NAT servers

[SRG]display firewall server-map 
11:30:50  2015/04/22
 server-map item(s) 
 ------------------------------------------------------------------------------
 Nat Server, any -> 1.1.1.100:21[172.16.1.254:21], Zone: ---
   Protocol: tcp(Appro: ftp), Left-Time: --:--:--, Addr-Pool: ---
   VPN: public -> public

 Nat Server Reverse, 172.16.1.254[1.1.1.100] -> any, Zone: ---
   Protocol: any(Appro: ---), Left-Time: --:--:--, Addr-Pool: ---
   VPN: public -> public


<Internet>ftp 1.1.1.100
Trying 1.1.1.100 ...
Press CTRL+K to abort
Connected to 1.1.1.100.
220 FTP service ready.
User(1.1.1.100:(none)):labnario
331 Password required for labnario.
Enter password:
230 User logged in.

Threat-Centric Security for Service Providers

Security has never been more critical for service providers. As Sanjeev Mervana said in his recent blog: Security has become a service provider imperative. it is a key enabler for open and programmable networks that enhances business agility and profitability. With secure networks, emerging video, wireless mobility, Internet of Everything (IoE) and cloud services can more reliably drive new revenue opportunities and business outcomes. Unfortunately, cyber adversaries exploit the growing attack surface that these services expose by launching more sophisticated attacks that impact both the service provider and their customers.
Until now, the only viable approach for service providers to protect their networks has been to deploy multiple point security solutions. Massive and expensive over-provisioning of equipment is the norm to handle burstable workloads and ‘absorb’ attacks, while continuing to deliver services. Even with open APIs, the integration cost to tie these point solutions together is excessive. Worse, once integrated, the solution becomes inflexible to service chaining requirements. This approach also leaves gaps between the “integrated” security silos that attackers can exploit. Without a unifying and highly automated way to deploy secure services, organizations are challenged to keep pace with the dynamic workloads and multiple topologies they must provision.
A New, Multi-Service Security Approach
Cisco is focused on solving the integration, performance, and security effectiveness challenges that plague legacy security architectures and put service providers, their customers and data at risk. Threat-centric security is the foundation of Cisco’s Evolved Programmable Network (EPN), which provides comprehensive threat protection across the attack continuum before, during and after an attack.
Introducing Cisco Firepower 9300
 
The new Cisco Firepower 9300 security appliance is a scalable, carrier-class, multi-service platform, designed to deliver integrated security services. With tightly integrated, threat-centric security services from Cisco and complementary security partners, Cisco Firepower 9300 lowers integration costs and enables realization of secure, open, and programmable networks.
The Firepower 9300 is the appliance component of Cisco’s scalable and agile security services portfolio for service providers. It is the first component of Cisco’s vision for consistent security policies across physical, virtual, and cloud environments. This unique solution is purpose-built to protect architectures including Cisco Evolved Programmable Networks, and Evolved Services Platform, as well as secure customer workloads transiting service provider offerings.
With this new security appliance, Cisco has reimagined service provider security by utilizing containerization of its own and partner security services. Advanced threats are identified, contained and remediated without inhibiting service delivery or network flexibility, speed or scalability. In addition, dynamic and intelligent service stitching is employed to optimize both threat defense and network performance. By dynamically “stitching in” only the security services necessary to further inspect classified traffic, unnecessary processing is eliminated and throughput is optimized. With Cisco Firepower 9300’s unique security and open network approach, service providers can realize enhanced agility, reduced expense, and increased revenue.
The first shipments of Cisco Firepower 9300 include Cisco ASA firewalling and VPN. Application DDoS mitigation, powered by Radware DefensePro and additional security services, including Firepower Threat Defense capabilities (Advanced Malware Protection (AMP), Next Generation IPS (NGIPS), Application Visibility and Control (AVC) and URL Filtering) will be added in the fall.
With scalable, tightly integrated, threat-centric, security services from Cisco and its partners, Cisco Firepower 9300 lowers integration costs and enables realization of secure, open, and programmable networks. For more information, please visit our website.
Tweet us @CiscoSP360 or find us on Facebook, we would love to hear your questions or comments!
Tags: attacks, Cisco, Cisco EPN, cisco live, esp, firepower 9300, secure networks, security, service providers, threat protection

We'd love to hear from you! To earn points and badges for participating in the conversation, join Cisco Social Rewards. Your comment(s) will appear instantly on the live site. Spam, promotional and derogatory comments will be removed.