Understanding, Configuring, and Troubleshooting BGP Conditional Advertisement
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
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:
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.
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
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.
We use cookies to ensure a great experience using this website. By continuing we will assume that you understand and accept our policy on cookies.ACCEPT AND CONTINUEPRIVACY POLICY
