Sorry about the wait…

An interesting BGP configuration option I have recently come-across is the “Conditional Advertisement Feature” -> it’s been around for a while, and what it allows you to do is to apply policy to outbound BGP advertisements…

Two examples of the kind of export policy that can be performed are:

1)
“Only advertise “route A” when “route B” isn’t available”
the yang being:
“Don’t advertise “route A” when “route B” is available”

2)
“Only advertise “route A” if “route B” is available”
the yang being:
“Don’t advertise “route A” if “route B” isn’t available”

The core commands required to add advertisement policies are added to BGP configuration as neighbor statements and take the following form:

neighbor {ip address} advertise-map ‘send_this’ non-exist-map ‘if_this_is_missing’

neighbor {ip address} advertise-map ‘send_this’ exist-map ‘if_this_exists’

 

Let’s break that down:

The advertise-map name specifies the route map that matches routes that can have conditional advertisement policy applied against them; any routes not matched by the advertise-map cannot have conditional advertisement policy applied (and will always be advertised so long that nothing else is preventing it).

When a non-exist-map is used alongside the advertise map:
If ‘route A’ is matched by the advertise-map and ‘route B’ is matched by the non-exist-map, ‘route A’ will be advertised only when ‘route B’ is not present in the local BGP table.  If ‘route B’ appears in the local BGP table the advertisement of ‘route A’ will cease.

When an exist-map is used alongside the advertise map:
If ‘route A’ is matched by the advertise-map and ‘route B’ is matched by the non-exist-map, ‘route A’ will be advertised only when ‘route B’ is present in the local BGP table.  If ‘route B’ disappears from the local BGP table the advertisement of ‘route A’ will cease.

Notes.
- A “match” = route-map “permit” + referenced access/prefix/as-path list “permit”
– Any other combination = no match
- When a non-exist-map or exist-map is configured it is scanned for changes by the BGP scanner process every 60 seconds (be patient…)

So, let’s bring this to life (i.e. into the real world)… starting with an Advertise-Map with a Non-Exist-Map

Here’s a simple multi-homed setup:

AS456 is the primary ISP of “SanFran Systems” and AS789 is the backup ISP, AS456 is providing a full internet routing table and a default route whereas AS789 is providing just a default route.  SanFran Systems’ public address space is provided by ISP1.  The plan is to not advertise any local AS routes to AS789 so long that AS456 is providing us with the routes we need, this will be achieved by selecting a route originated in AS456 and tracking its existence in the local BGP table -> existence = don’t advertise anything to AS789, non-existence = advertise to AS789

Getting into the details, our requirements on SF_R1 are:
- If 146.55.0.0/16 exists in the local BGP table, do not advertise the 146.55.43.0/26 prefix to ISP2_R1.
- If 146.55.0.0/16 does not exist in the local BGP table, advertise the 146.55.43.0/26 prefix to ISP2_R1

Before getting into the configuration of conditional advertisement we need to ensure that the information it relies on is valid – we do this by giving the routes learned from each of the ISPs an identification to match against, by doing this we are being a little bit more pro-active vs reactive (I’ll explain more later), here is our initial BGP configuration on SF_R1:

router bgp 123  no synchronization  bgp log-neighbor-changes  network 146.55.43.0 mask 255.255.255.192  neighbor 146.55.251.13 remote-as 456  neighbor 146.55.251.13 route-map AS456_IN in  neighbor 146.55.251.13 route-map AS456_OUT out  neighbor 163.86.53.5 remote-as 789  neighbor 163.86.53.5 route-map AS789_IN in  neighbor 163.86.53.5 route-map AS789_OUT out  no auto-summary ! ip as-path access-list 1 permit ^$ ! route-map AS456_OUT permit 10  match as-path 1 ! route-map AS789_OUT permit 10  match as-path 1 ! route-map AS789_IN permit 10  set community 8061717 ! route-map AS456_IN permit 10  set community 8061384  set local-preference 110 !   Configuration explanation: In this base configuration we are preventing AS123 from becoming a transit AS by affecting outbound policy towards both AS456 and AS789 using an AS path list to filter. The “set local-preference” line causes BGP routers in AS123 to prefer routes received from AS456 over AS789 -> i.e. the default route. We are also setting unique community tags on routes as they are received inbound from AS456 and AS789 -> 8061717 = 123:456 and 8061384 = 123:789

Here’s a snapshot of the BGP table of ISP2_R1 following the configuration above:

ISP2_R1#show ip bgp neighbor 163.86.53.6 received-routes *output omitted* *> 146.55.43.0/26   163.86.53.6              0             0 123 i

Our aim is to stop the advertisement of 146.55.43.0/26 from SF_R1 whilst it is still receiving routes from ISP1_R1, here is how we do it:

ip community-list 1 permit 123:456 ! ip prefix-list ISP456_TRACK seq 10 permit 146.55.0.0/16 ip prefix-list CONDITIONAL seq 10 permit 146.55.43.0/26 ! route-map IF_THIS_IS_MISSING permit 10  match ip address prefix-list ISP456_TRACK  match community 1 ! route-map SEND_THIS permit 10  match ip address prefix-list CONDITIONAL ! router bgp 123  neighbor 163.86.53.5 advertise-map SEND_THIS non-exist-map IF_THIS_IS_MISSING ! exit ! exit clear ip bgp 163.86.53.5 soft in   Configuration explanation: A permit line in the advertise-map named “SEND_THIS” references a permit line in a prefix list, thus causing a match (or a “1” vs “0” in my mind – does anybody else think like that?).  This is the route that will be advertised when any routes matched in the following non-exist-map aren’t present in the local BGP table. The following non-exist-map named “IF_THIS_IS_MISSING” references not only a prefix list but a community list – the prefix list defines a route to track and the match on community ensures that we have learned the route from the correct place -> it’s quite possible that the conditional advertisement feature can fail because the route you are tracking is also received from another source (i.e. AS789)… <- see my reference to being pro-active.  Using a community list is one way to do this but others exist – such as using an AS path list…

ISP2_R1’s BGP table following the change:

ISP2_R1#show ip bgp neighbor 163.86.53.6 received-routes Total number of prefixes 0

 

So it’s working up until now, lets shutdown the link to ISP1_R1 and see what happens:

SF_R1(config)#interface serial 1/0 SF_R1(config-if)#shutdown   After waiting a little while…. ISP2_R1#show ip bgp neighbor 163.86.53.6 received-routes *output omitted* *> 146.55.43.0/26   163.86.53.6              0             0 123 i

Success!

More to come…