Understanding, Configuring, and Troubleshooting BGP Conditional Advertisement

By Radu Pavaloiu
BGP by default advertises the permitted best paths in its BGP routing information base (RIB) to external peers. In certain cases, this might be undesirable. Advertisement of some routes might depend on the non-existence of some other routes. In other words, the advertisement in this case is conditional. In a multihomed network, some prefixes are to be advertised to one of the providers only if information from the other provider is missing, such as a failure in the peering session or partial reachability. Figure 1 shows a topology of a conditional advertisement that tracks the non-existence of a prefix. AS 100 is multihomed to AS 200 and AS 300, with the link to AS 300 as the primary connection. The address block of AS 100 (172.16.1/24) is assigned from AS 300, within the range of 172.16/16. AS 100 does not advertise 172.16.1/24 to its backup AS, AS200 unless the link to AS 300 fails.  
Figure 1. GP conditional advertisement in primary-backup scenario
So, as long as AS 100 is connected to AS 300, traffic will flow to AS100 via AS 300 – – – > AS 100 path as only the aggregate (172.16/16) covering the AS 100 block (172.16.1/24) is advertised to the Internet by AS 300. When AS 100 loses the primary provider (AS 300) based on the missing prefix (172.16.2/24) received via BGP from AS 300 it starts to advertise its own block to the backup provider (AS 200). When the connectivity to the primary provider restores R1/AS 100 stops to advertise its own block to the backup provider (AS 200), so the traffic will reconverge over the primary provider (AS 300). Let us see this in action. 
R1 (AS 100) is receiving the tracked prefix (172.16.2.0/24) from R3 (AS 300) and install it in its own RIB:
admin@R1-cli> show bgp neighbor brief
routing-instance: R1VR

Neighbor V MsgRcvd MsgSent Uptime State/PfxRcd PfxSent AS
192.168.12.2 4 147 150 01:03:15 0 1 200
192.168.13.3 4 150 151 01:03:15 1 1 300

admin@R1-cli> show route table ipv4.unicast receive-protocol bgp neighbor-address 192.168.13.3
Routes for Routing instance : R1VR AFI: ipv4 SAFI: unicast

Prefix/Mask Next-hop MED Lclpref AS path
----------- -------- --- ------- -------
172.16.2.0/24 192.168.13.3 0 100 300
As a result, even if its own block (172.16.1/24) is in the R1’s RIB and configured to be advertised via BGP to AS 200, R1 does not advertise it toward R2 (AS 200): 
admin@R1-cli> show route routing-instance R1VR 172.16.1.0
Routes for Routing instance : R1VR AFI: ipv4 SAFI: unicast
[+] - Active Route
Routing entry for 172.16.1.0 (mask 255.255.255.0) [+]
Known via 'netmgmt', distance 1, metric 1, forward metric 1
Redistributing via netmgmt
Last update from 0.0.0.0 02:19:39 ago
Routing Descriptor Blocks:
* 0.0.0.0 , via Indirect 02:19:39 ago
admin@R1-cli> show route table ipv4.unicast advertising-protocol bgp neighbor-address 192.168.12.2 172.16.1.0/24
Routes for Routing instance : R1VR AFI: ipv4 SAFI: unicast
% No entries found.
A transmission failure triggers the BGP session between R1(AS 100) and R3(AS 200) to go down: 
admin@R1-cli> show bgp neighbor brief
routing-instance: R1VR
Neighbor V MsgRcvd MsgSent Uptime State/PfxRcd PfxSent AS
192.168.12.2 4 340 343 02:26:17 0 1 200
192.168.13.3 4 338 343 n/a Connect 0 300
The tracked prefix (172.16.2/24) received from AS 300 is flushed from R1’s RIB: 
admin@R1-cli> show route routing-instance R1VR

Routes for Routing instance : R1VR  AFI: ipv4  SAFI: unicast

Codes: E1 - OSPF external type 1, E2 - OSPF external type 2
IA - inter area, iA - intra area,
L1 - IS-IS level-1, L2 - IS-IS level-2
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
RTI - Learnt from another routing-instance
+ - Active Route

Prot   Type  Dest Address/Mask   Next-hop        Age      Interface name
----   ----  -----------------   --------        ---      --------------
static N/A  +172.16.1.0/24       0.0.0.0         02:29:06 Indirect
conn   N/A  +192.168.12.0/24     0.0.0.0         02:28:35 vni-0/0.0
local  N/A  +192.168.12.1/32     0.0.0.0         02:28:35 directly connected
As a result of the BGP conditional advertisement config R1 (AS 100) starts to advertise its own block (172.16.1/24) toward the backup provider (R2 in AS 200): 
admin@R1-cli> show route table ipv4.unicast advertising-protocol bgp neighbor-address 192.168.12.2 172.16.1.0/24

Routes for Routing instance : R1VR  AFI: ipv4  SAFI: unicast


Prefix/Mask         Next-hop          MED  Lclpref  AS path
-----------         --------          ---  -------  -------
172.16.1.0/24       192.168.12.1      0    0        100
When the BGP session between R1(AS 100) and R3(AS 300) recovers, R1(AS 100) ceases to advertise its own block toward the backup provider (R2/AS 200): 
admin@R1-cli> show bgp neighbor brief
routing-instance: R1VR

Neighbor        V  MsgRcvd   MsgSent    Uptime     State/PfxRcd  PfxSent AS
192.168.12.2    4  378       381        02:42:57   0             1       200
192.168.13.3    4  345       350        00:01:36   1             1       300

[ok][2021-02-17 03:04:38]
admin@R1-cli> show route routing-instance R1VR

Routes for Routing instance : R1VR  AFI: ipv4  SAFI: unicast

Codes: E1 - OSPF external type 1, E2 - OSPF external type 2
IA - inter area, iA - intra area,
L1 - IS-IS level-1, L2 - IS-IS level-2
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
RTI - Learnt from another routing-instance
+ - Active Route

Prot   Type  Dest Address/Mask   Next-hop        Age      Interface name
----   ----  -----------------   --------        ---      --------------
static N/A  +172.16.1.0/24       0.0.0.0         02:43:46 Indirect
BGP    N/A  +172.16.2.0/24       192.168.13.3    00:01:53 vni-0/1.0
conn   N/A  +192.168.12.0/24     0.0.0.0         02:43:15 vni-0/0.0
local  N/A  +192.168.12.1/32     0.0.0.0         02:43:15 directly connected
conn   N/A  +192.168.13.0/24     0.0.0.0         00:01:54 vni-0/1.0
local  N/A  +192.168.13.1/32     0.0.0.0         00:01:54 directly connected


admin@R1-cli> show route table ipv4.unicast advertising-protocol bgp neighbor-address 192.168.12.2 172.16.1.0/24

Routes for Routing instance : R1VR  AFI: ipv4  SAFI: unicast
% No entries found.
Let’s see now what to check in case we have to troubleshoot BGP conditional advertising. First, BGP logging has to be enabled. Figure 2 presents the config part of BGP logging.
Figure 2. BGP logging configuration.
As you can see “All Flags” box should be checked and the severity of the captured messages should be set to level “Debug”. The messages are written on the rtdtrc.log file of the following path: /var/log/versa/rtdtrc.log. When the BGP session with the primary upstream provider is impacted, the local prefix (172.16.1/24) is added to BGP ADJ-RIB-OUT and it is used when the BGP update for the backup provider is built: 
21-02-17 04:45:18.00: qbraaro1.c   0538(R1VR): Allocated ARO Route CB for 172.16.1/24
21-02-17 04:45:18.00: qbraaro1.c   0785(R1VR): Adding route 172.16.1/24 to ADJ-RIB-OUT (1/1)
21-02-17 04:45:18.00: qbraaro1.c   0973(R1VR): Deleting route 172.16.2/24 from ADJ-RIB-OUT (1/1)
21-02-17 04:45:18.00: qbumupdt.c   0146(R1VR): Building Update message for peer 192.168.12.2
21-02-17 04:45:18.00: qbumupdt.c   0168(R1VR): AFI/SAFI 1/1, Add/Rem Rts 1/1, Adv Prfx 1
21-02-17 04:45:18.00: qbumupdt.c   0348(R1VR):   Withdrawn IPv4 NLRI count : 1
21-02-17 04:45:18.00: qbumupdt.c   0349(R1VR):   Withdrawn IPv4 NLRIs :
21-02-17 04:45:18.00: qbumupdt.c   0373(R1VR):     172.16.2/24
21-02-17 04:45:18.00: qbumupdt.c   0514(R1VR):   ORIGIN attribute value : 0
21-02-17 04:45:18.00: qbumupdt.c   0524(R1VR):   AS PATH : 100
21-02-17 04:45:18.00: qbumupdt.c   0583(R1VR):   Nexthop : 192.168.12.1
21-02-17 04:45:18.00: qbumupdt.c   0661(R1VR):   COMMUNITY count : 1
21-02-17 04:45:18.00: qbumupdt.c   0667(R1VR):   COMMUNITIES :  200:100
21-02-17 04:45:18.00: qbumupdt.c   1608(R1VR):   Updated IPv4 NLRI count : 1
21-02-17 04:45:18.00: qbumupdt.c   1609(R1VR):   Updated IPv4 NLRIs :
21-02-17 04:45:18.00: qbumupdt.c   1635(R1VR):     172.16.1/24
When the connectivity with the primary provider (AS 300) recovers, we can see that the local prefix (172.16.1/24) is withdrawn in the BGP update sent to the backup provider (AS 200) and concomitantly the prefix is removed from the BGP Adj-RIB-OUT table. 
21-02-17 04:47:02.00: qbraaro1.c   0538(R1VR): Allocated ARO Route CB for 172.16.2/24
21-02-17 04:47:02.00: qbraaro1.c   0973(R1VR): Deleting route 172.16.2/24 from ADJ-RIB-OUT (1/1)
21-02-17 04:47:02.00: qbraaro1.c   0657(R1VR): Destroying route 172.16.2/24 from ADJ-RIB-OUT (1/1)
21-02-17 04:47:02.00: qbraaro1.c   0785(R1VR): Adding route 172.16.2/24 to ADJ-RIB-OUT (1/1)
21-02-17 04:47:02.00: qbumupdt.c   0146(R1VR): Building Update message for peer 192.168.12.2
21-02-17 04:47:02.00: qbumupdt.c   0168(R1VR): AFI/SAFI 1/1, Add/Rem Rts 1/1, Adv Prfx 1
21-02-17 04:47:02.00: qbumupdt.c   0348(R1VR):   Withdrawn IPv4 NLRI count : 1
21-02-17 04:47:02.00: qbumupdt.c   0349(R1VR):   Withdrawn IPv4 NLRIs :
21-02-17 04:47:02.00: qbumupdt.c   0373(R1VR):     172.16.1/24
21-02-17 04:47:02.00: qbumupdt.c   0514(R1VR):   ORIGIN attribute value : 0
21-02-17 04:47:02.00: qbumupdt.c   0524(R1VR):   AS PATH : 100,300
21-02-17 04:47:02.00: qbumupdt.c   0583(R1VR):   Nexthop : 192.168.12.1
21-02-17 04:47:02.00: qbumupdt.c   0661(R1VR):   COMMUNITY count : 1
21-02-17 04:47:02.00: qbumupdt.c   0667(R1VR):   COMMUNITIES :  100:300
21-02-17 04:47:02.00: qbumupdt.c   1608(R1VR):   Updated IPv4 NLRI count : 1
21-02-17 04:47:02.00: qbumupdt.c   1609(R1VR):   Updated IPv4 NLRIs :
21-02-17 04:47:02.00: qbumupdt.c   1635(R1VR):     172.16.2/24


21-02-17 04:47:03.00: qbumaro.c    0767(R1VR): No change to route 172.16.1/24 in ADJ-RIB-OUT (1/1)
21-02-17 04:47:03.00: qbraaro1.c   0657(R1VR): Destroying route 172.16.1/24 from ADJ-RIB-OUT (1/1)
21-02-17 04:47:14.00: qbraaro1.c   0657(R1VR): Destroying route 172.16.1/24 from ADJ-RIB-OUT (1/1)
Let us move now to the configuration side of this feature. First two prefix lists have two be configured, one for the tracked prefix (AS300-track: 172.16.2/24) and one for the local block (Local-prefix: 172.16.1/24).
Figure 3. Prefix lists for tracked prefix and the local block
admin@R1-cli> show configuration routing-instances R1VR protocols bgp prefix-list | display set
set routing-instances R1VR protocols bgp 1 prefix-list AS300-track seq 10 address-family ipv4 unicast address-mask 172.16.2.0/24
set routing-instances R1VR protocols bgp 1 prefix-list Local-prefix seq 10 address-family ipv4 unicast address-mask 172.16.1.0/24
Next step is to configure two policies, one which is checking the existence of the tracked prefix in the BGP RIB (AS300-IN) and one which conditionally starts to advertise the local block when the tracked prefix disappears from the BGP RIB.
Figure 4. BGP policies required for BGP conditional advertisement
admin@R1-cli> show configuration routing-instances R1VR protocols bgp routing-peer-policy | display set
set routing-instances R1VR protocols bgp 1 routing-peer-policy AS200-OUT term AdvertiseLocal match family inet
set routing-instances R1VR protocols bgp 1 routing-peer-policy AS200-OUT term AdvertiseLocal match ip nlri prefix-list Local-prefix
set routing-instances R1VR protocols bgp 1 routing-peer-policy AS200-OUT term AdvertiseLocal action accept
set routing-instances R1VR protocols bgp 1 routing-peer-policy AS200-OUT term AdvertiseLocal action rib-bgp-ecmp false
set routing-instances R1VR protocols bgp 1 routing-peer-policy AS300-IN term TrackPrefix match family inet
set routing-instances R1VR protocols bgp 1 routing-peer-policy AS300-IN term TrackPrefix match community 100:300
set routing-instances R1VR protocols bgp 1 routing-peer-policy AS300-IN term TrackPrefix match ip nlri prefix-list AS300-track
set routing-instances R1VR protocols bgp 1 routing-peer-policy AS300-IN term TrackPrefix action accept
set routing-instances R1VR protocols bgp 1 routing-peer-policy AS300-IN term TrackPrefix action rib-bgp-ecmp false
Last step is to apply the above two policies to the backup provider/router (AS200/R2)
Figure 5. BGP policies applied for the backup of BGP peer/provider
admin@R1-cli> show configuration routing-instances R1VR protocols bgp 1 group AS200 neighbor 192.168.12.2 | display set
set routing-instances R1VR protocols bgp 1 group AS200 neighbor 192.168.12.2 advertise-policy AS200-OUT
set routing-instances R1VR protocols bgp 1 group AS200 neighbor 192.168.12.2 non-exist-policy AS300-IN

Summary

In this article, we saw what BGP conditional advertisement feature means, how to configure and troubleshoot it on the Versa VOS.