If you ever took a programming course or have done any development, you probably have heard of an “If/Then” statement. An "If/Then" statement is one that says if a condition exists, then take a specific action. BGP conditional advertising uses a similar logic, but uses something called advertise maps and non-exist or exist maps. In this example, I will use the advertise map and non-exist map.
Diagram1-1
In this example, we have R4 multi-homed with two different ISPs. The company has a few public addresses to advertise to the internet to ensure reachability. The subnets include the following:
- 77.10.12.0/24
- 77.14.16.0/24
- 78.55.97.0/24
The company BGP policy states that subnet 77.10.12.0/24 & 78.55.97.0 should be advertised to both service providers. The policy also states that traffic entering the AS for subnet 77.14.16.0/24 must use the link between R2 & R4. If the link between R2 & R4 should fail, traffic for subnet 77.14.16.0/24 should use the link between R3& R4 to ensure reachability.
While we could use AS path prepending to hint to the upstream providers how traffic should enter the AS. This doesn't mean all traffic will use only one path if AS path prepending is used. One way to ensure all traffic for subnet 77.14.16.0/24 uses a specific link, is to only advertise the subnet to the ISP where the traffic is expected. With the requirements that are given, BGP conditional advertising can be used to meet those requirements.
The way in which to approach this is by using a non-exist-map to check for the existence of a default route from R2. (That's the “If”part) If the default route from R2 is removed from the BGP table, the non-exist-map will match and R4 will begin to advertise the 77.14.16.0/24 network to R3 with the advertise-map. (That's the“Then” part)
If the default route from R2 is installed into the BGP table, the non-exist-map will not match and the route being advertised to R3 will be withdrawn.
Here are the intermediate configurations of R2, R3 and R4
R2
interface Loopback77
ip address 7.7.7.7 255.255.255.255
!
!
router bgp 200
no synchronization
bgp router-id 2.2.2.2
bgp log-neighbor-changes
network 7.7.7.7 mask 255.255.255.255
neighbor 10.10.12.1 remote-as 100
neighbor 10.10.24.4 remote-as 400
neighbor 10.10.24.4 default-originate
no auto-summary
R3
router bgp 300
no synchronization
bgp router-id 3.3.3.3
bgp log-neighbor-changes
neighbor 10.10.13.1 remote-as 100
neighbor 10.10.34.4 remote-as 400
neighbor 10.10.34.4 default-originate
no auto-summary
R4
interface Loopback1
ip address 77.10.12.1 255.255.255.0
!
interfaceLoopback2
ip address 77.14.16.1 255.255.255.0
!
interfaceLoopback3
ip address 78.55.97.1 255.255.255.0
!
!
router bgp 400
no synchronization
bgp router-id 4.4.4.4
bgp log-neighbor-changes
network 77.10.12.0 mask 255.255.255.0
network 77.14.16.0 mask 255.255.255.0
network 78.55.97.0 mask 255.255.255.0
neighbor 10.10.24.2 remote-as 200
neighbor 10.10.24.2 distribute-list 5 in
neighbor 10.10.24.2 distribute-list 10 out
neighbor 10.10.34.3 remote-as 300
neighbor 10.10.34.3 distribute-list 5 in
neighbor 10.10.34.3 distribute-list 10 out
neighbor 10.10.34.3 advertise-map ADVERTISE non-exist-map NON-EXIST
no auto-summary
!
!
access-list 5 permit 0.0.0.0
access-list 10 permit 77.10.12.0 0.0.0.255
access-list 10 permit 77.14.16.0 0.0.0.255
access-list 10 permit 78.55.97.0 0.0.0.255
access-list 30 permit 0.0.0.0
access-list 40 permit 77.14.16.0 0.0.0.255
!
!
!
route-map NON-EXIST permit 10
match ip address 30
!
route-map ADVERTISE permit 40
match ip address 40
There is a problem with the above configuration. With this configuration, the NON-EXIST portion of the BGP conditional advertisement will never match. The reason is that it's only checking for the existence of a default route. R4 is receiving a default route from both R2 &R3. The NON-EXIST portion would never match because there will always be a default route in the routing table. The engineer needs a way to identify which default route to look for. With BGP conditional advertising, the engineer can create an as-path access-list to identify which AS the default route should be coming from. The additional configuration would be:
Ip as-path access-list 10 permit ^200$
!
!
route-map NON-EXIST permit 10
match ip address 30
match as-path 10
**Note** The configuration is applied using the neighbor advertise-map non-exist-map configuration command.
Now, if the link between R2 & R4 fails, the non-exist-map will match because both conditions have matched. The default route has been removed and it was sourced from AS 200.
We can verify that the configuration is working as expected by viewing the routes we are advertising to R3. R4 should not be advertising the 77.14.16.0/24 network because R4 is receiving a default route from R2.
R4#show ip bgp neighbor 10.10.34.3 advertised-routes | b O
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>77.10.12.0/24 0.0.0.0 0 32768 i
*>78.55.97.0/24 0.0.0.0 0 32768 i
To test this, a continuous ping will be started to 77.14.16.1 from R1. The link between R2 & R4 will be shut down to simulate a link failure. Because BGP is timer driven, and there has been no changes to the default timers, it will take BGP 3 minutes or longer to converge. The timers can be adjusted in a lab environment to get the results faster, but in this example the timers will be left at their defaults so the reader can get an understanding of how long it takes BGP to converge after a link failure using BGP conditional advertising.
Once the link between R2 & R4 is shut down a console message on R4 appears.
*Mar 1 01:33:29.675: BGP(0): 10.10.34.3 rcv UPDATE about 77.14.16.0/24 – withdrawn
Note the time that the interface failed in the console message. This is when BGP sent an UPDATE message to withdraw routes. Now let's take a look at the debug output when the non-exist-map get a match.
*Mar 1 01:36:25.859: BPG(0): Condition NON-EXIST changes to Advertise
*Mar 1 01:36:25.863: BPG(0): Condition NON-EXIST changes to Advertise
*Mar 1 01:36:25.867: BGP(0): net 77.14.16.0/24 matches ADV MAP ADVERTISE: bump version to 11
*Mar 1 01:36:26.651: BGP(0): 10.10.34.3 77.14.16.0/24 matches advertise map ADVERTISE, state: Advertise
*Mar 1 01:36:55.935: BGP(0): 10.10.34.3 send UPDATE (format) 77.14.16.0/24, next 10.10.34.4, metric 0, path Local
Looking at the time stamps, we can see it took 3 min (180 seconds) for BGP to converge. The default hold timer for BGP is 180 seconds.
Now let's take a look at R1 where the pings were running.
Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 77.14.16.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!U....................................
......................................................!!!!!!!!!!!!!!!!
To verify that the conditional advertising is working, we can look at the routes we are sending to R3. We should now see that R4 is advertising the 77.14.16.0/24 network to R3.
R4#show ip bgp neighbor 10.10.34.3 advertised-routes | b O
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 77.10.12.0/24 0.0.0.0 0 32768 i
*> 77.14.16.0/24 0.0.0.0 0 32768 i
*> 78.55.97.0/24 0.0.0.0 0 32768 i
Now let's bring the link between R2 & R4 back up and examine the debug output on R4.
*Mar 1 01:56:32.463: BPG(0): Condition NON-EXIST changes to Withdraw
*Mar 1 01:56:32.463: BPG(0): Condition NON-EXIST changes to Withdraw
*Mar 1 01:56:32.463: BGP(0): net 77.14.16.0/24 matches ADV MAP ADVERTISE: bump version to 8
*Mar 1 01:56:32.679: BGP(0): 10.10.24.2 skip UPDATE 77.14.16.0/24(chgflags: 0x0), next 0.0.0.0, path *Mar 1 01:56:32.679: BGP(0): 10.10.34.3 77.14.16.0/24 matches advertise map ADVERTISE, state: Withdraw
You can see that once the link is brought back online the NON-EXIST condition does not match and the state changes from advertise to withdraw.
In conclusion, this document outlined the basic function and operation of BGP conditional advertisement. For more information, please refer to the documentation at Cisco.com.
No comments:
Post a Comment