Introduction to BGP override and BGP allow-as-in
Today I am going to talk about the difference between BGP override and BGP allow-as-in. many of you already knew that BGP override is generally used in the ISP side while BGP allow-as-in at the client side with the same feature sets.
As i said earlier, both have the same feature under the different subtitle names. 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.
In the above mentioned diagram, we have two different AS numbers. The diagram shows that AS 65001 connects to the ISP at two different locations. So when R2 accepts the prefix 33.33.33.33/32, You can see that the AS path is via 1, 65001. Because of the loop prevention mechanism, NB_R2 will have to reject this prefix because it can see its own AS in the AS_PATH attribute.
 |
| Fig 1.1- BGP Override and Allow-as-in |
Configurations on NB_PE1 router
NB_PE1#
ip vrf cisco
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 Cisco
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 cisco
neighbor 10.10.10.11 remote-as 65001
neighbor 10.10.10.11 activate
no synchronization
exit-address-family
!
Configurations on NB_PE2 router
NB_PE2#
ip vrf cisco
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 cisco
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 cisco
neighbor 20.20.20.21 remote-as 65001
neighbor 20.20.20.21 activate
no synchronization
exit-address-family
!
Now configuring routers ate client Side
Configuration on NB_R1 router
NB_R1#
interface Loopback0
ip address 33.33.33.33 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 33.33.33.33 mask 255.255.255.255
neighbor 10.10.10.10 remote-as 1
no auto-summary
Configuration on NB_R2 router
NB_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
!
NB_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 NB_R2, he is not accepting any prefixes from NB_R1 in the other site; as shown below (we would expect the 10.10.10.0/24 and 33.33.33.33/32 networks to be in the BGP table).
NB_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 33.33.33.33/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 NB_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.
NB_R2(config-router)#neighbor 20.20.20.20 allowas-in 1
NB_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 33.33.33.33/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 33.33.33.33/32 -> 20.20.20.20(main) to main IP table
NB_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
*> 33.33.33.33/32 20.20.20.20 0 1 65001 i
So you can see (on NB_R2) that the AS_PATH is 1, 65001 for these prefixes. It keeps all the AS_PATH information and simply just allows 1 occurrence of 65001 to be in the AS_PATH; thus overriding the loop prevention mechanism. We would obviously need to do this on NB_R1 in order for R1 to have reachability to the 20.20.20.0/24 prefix (sitting between NB_PE2 and NB_R2) so that he can have a route back to NB_R2.
NB_R1(config)#router bgp 65001
NB_R1(config-router)#neighbor 10.10.10.10 allowas-in 1
NB_R2#ping 33.33.33.33
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 33.33.33.33, 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 NB_PE1 & NB_PE2 to just strip AS 65001 from the BGP UPDATE before sending it to the customer edge routers. Let’s do that now.
NB_R1(config-router)#no neighbor 10.10.10.10 allowas-in 1
NB_R2(config-router)#no neighbor 20.20.20.20 allowas-in 1
NB_PE2(config)#router bgp 1
NB_PE2(config-router)#address-family ipv4 unicast vrf google
NB_PE2(config-router-af)#neighbor 20.20.20.21 as-override
NB_PE1(config)#router bgp 1
NB_PE1(config-router)#address-family ipv4 unicast vrf google
NB_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 NB_R2 below.
NB_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
*> 33.33.33.33/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.
