Conditional Advertisement
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 existence and nonexistence of some other routes. In other words, the advertisement 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. The conditional BGP announcements are in addition to the normal announcements that a BGP router sends to its peers.
NOTE
A conditional advertisement does not create routes; it only withholds them until the condition is met. These routes must already be present in the BGP RIB.
Configurations
Conditional advertisement has two forms: advertisement of some prefixes when some other prefixes do not exist and advertisement of some prefixes when they do exist. The prefixes to be advertised are defined by a special route map called advertise-map. The condition is defined by a route map called non-exist-map for conditions that do not exist or by a route map called exist-map for conditions that do exist.
The first form of conditional advertisement is configured as follows:
neighbor advertise-map map1 non-exist-map map2
The route map associated with the non-exist-map specifies the prefix (or prefixes) that the BGP speaker tracks. Only permit is accepted; any deny is ignored. When a match is made, the status of the advertise-map is Withdraw; when no match is made, the status becomes Advertise.
Within the non-exist-map, a match statement for the prefix is required. You can configure it with a prefix list or a standard access list. Only an exact match is supported. Additionally, AS_PATH and community can be matched.
The route map associated with the advertise-map defines the prefix (or prefixes) that are advertised to the specific neighbor when the prefixes in the non-exist-map no longer exist—that is, when the status is Advertise. When the status is Withdraw, the prefix or prefixes defined in the advertise-map are not advertised or withdrawn. Note that the advertise-map applies only on the outbound direction, which is in addition to the other outbound filters.
The second form of conditional advertisement is configured as follows:
neighbor advertise-map map1 exist-map map2
In this case, the route map associated with the exist-map specifies the prefix (or prefixes) that the BGP speaker tracks. The status is Advertise when the match is positive—that is, when the tracked prefix exists. The status is Withdraw if the tracked prefix does not exist. The route map associated with the advertise-map defines the prefix (or prefixes) that are advertised to the specific neighbor when the prefix in the exist-map exists. Prefixes in both route maps must exist in the local BGP RIB.
Examples
Figure 4-2 shows a topology of a conditional advertisement that tracks the nonexistence 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 is assigned from AS 300, within the range of 172.16.0.0/16. The address block 172.16.1.0/24 is not to be advertised to AS 200 unless the link to AS 300 fails. AS 300 sends 172.16.2.0/24 to AS 100, and it is tracked by the non-exist-map on R1. Example 4-14 shows R1's BGP configuration. Note that the community 100:300 is set and matched for the prefix to be tracked to ensure that the prefix is indeed from AS 300.
)
Figure
4-2 Conditional Advertisement in a Primary-Backup ScenarioÅ@
Example 4-14 Sample BGP Configuration for Conditional Advertisement on R1
router bgp 100 network 172.16.1.0 mask 255.255.255.0 neighbor 192.168.12.2 remote-as 200 neighbor 192.168.12.2 advertise-map AS200-out non-exist-map AS300-in neighbor 192.168.13.3 remote-as 300 neighbor 192.168.13.3 route-map Set-comm in ! ip community-list 1 permit 100:300 ip prefix-list AS300-track seq 5 permit 172.16.2.0/24 ip prefix-list Local-prefix seq 5 permit 172.16.1.0/24 ! route-map AS300-in permit 10 match ip address prefix-list AS300-track match community 1 ! route-map Set-comm permit 10 set community 100:300 ! route-map AS200-out permit 10 match ip address prefix-list Local-prefix
When prefix 172.16.2.0/24 is present in R1's BGP RIB, 172.16.1.0/24 is not advertised to R2, as shown in Examples 4-15 and 4-16.
Example 4-15 Advertisement Status in R1 Under Normal Conditions
R1#show ip bgp 172.16.2.0 BGP routing table entry for 172.16.2.0/24, version 3 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 192.168.12.2 300 192.168.13.3 from 192.168.13.3 (192.168.13.3) Origin IGP, metric 0, localpref 100, valid, external, best Community: 100:300 R1#show ip bgp neighbor 192.168.12.2 | include Condition-map Condition-map AS300-in, Advertise-map AS200-out, status: Withdraw
Example 4-16 R2 Does Not Have 172.16.1.0 Under Normal Conditions
R2#show ip bgp 172.16.1.0 % Network not in table
When the session between R1 and R3 is down, 172.16.2.0/24 is removed from R1's BGP RIB. R2's advertisement status is now Advertise, as shown in Example 4-17. The prefix 172.16.1.0/24 is now available in R2, as shown in Example 4-18. For this design to work, it is important to ensure that the right prefix from the provider is being tracked.
Example 4-17 Advertisement Status During Primary Link Failure
R1#show ip bgp neighbor 192.168.12.2 | include Condition-map Condition-map AS300-in, Advertise-map AS200-out, status: Advertise
Example 4-18 Prefix 172.16.1.0 Is Present on R2 During a Primary Link Failure
R2#show ip bgp 172.16.1.0 BGP routing table entry for 172.16.1.0/24, version 14 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 100 192.168.12.1 from 192.168.12.1 (192.168.13.1) Origin IGP, metric 0, localpref 100, valid, external, best
Figure 4-3 shows a topology of conditional advertisement to track the existence of a prefix. Within AS 100, R1 is the only BGP speaker, and it has an eBGP session with R3 in AS 300. All routers within AS 100 communicate using OSPF. The internal address block 10.0.0.0/16 is translated into a public block 172.16.0.0/16 on R2. The policy is that R1 should not advertise 172.16.0.0/16 to R3 unless 10.0.0.0/16 is available.
)
Figure
4-3 Conditional Advertisement to Track the Existence of a Prefix
Example 4-19 shows a sample BGP configuration on R1. Both the prefix to be advertised (172.16.0.0) and the prefix tracked (10.0.0.0) are injected into the BGP RIB. The private prefix is then blocked from being advertised to R3 with the prefix list Block10. The exist map Prefix10 tracks the existence of 10.0.0.0/16, which is learned from OSPF. When the match returns true (status: Advertise), AS300-out is executed. When 10.0.0.0/16 is gone from OSPF (status: Withdraw), 172.16.0.0/16 is not advertised or withdrawn.
Example 4-19 Sample BGP Configuration on R1
router bgp 100 network 10.0.0.0 mask 255.255.0.0 network 172.16.0.0 neighbor 192.168.13.3 remote-as 300 neighbor 192.168.13.3 prefix-list Block10 out neighbor 192.168.13.3 advertise-map AS300-out exist-map Prefix10 no auto-summary ! ip prefix-list Block10 seq 5 deny 10.0.0.0/16 ip prefix-list Block10 seq 10 permit 0.0.0.0/0 le 32 ip prefix-list adv-out seq 5 permit 172.16.0.0/16 ip prefix-list Private10 seq 5 permit 10.0.0.0/16 ! route-map Prefix10 permit 10 match ip address prefix-list Private10 ! route-map AS300-out permit 10 match ip address prefix-list adv-out
Example 4-20 shows what happens when 10.0.0.0/16 is available on R1's BGP RIB. The prefix 172.16.0.0/16 is advertised to R3.
Example 4-20 Advertisement of 172.16.0.0/16
R1#show ip bgp 10.0.0.0 BGP routing table entry for 10.0.0.0/16, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer Local 192.168.12.2 from 0.0.0.0 (192.168.13.1) Origin IGP, metric 20, localpref 100, weight 32768, valid, sourced, local, best R1#show ip bgp 172.16.0.0 BGP routing table entry for 172.16.0.0/16, version 4 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 192.168.13.3 Local 192.168.12.2 from 0.0.0.0 (192.168.13.1) Origin IGP, metric 20, localpref 100, weight 32768, valid, sourced, local, best R1#show ip route 10.0.0.0 Routing entry for 10.0.0.0/8, 1 known subnet O E2 10.0.0.0/16 [110/20] via 192.168.12.2, 00:36:47, Ethernet0/0 R1#show ip bgp neighbor 192.168.13.3 | include Condition-map Condition-map Prefix10, Advertise-map AS300-out, status: Advertise
R3#show ip bgp 172.16.0.0 BGP routing table entry for 172.16.0.0/16, version 12 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 100 192.168.13.1 from 192.168.13.1 (192.168.13.1) Origin IGP, metric 20, localpref 100, valid, external, best
Example 4-21 shows what happens when 10.0.0.0 is not available on R1.
Example 4-21 No Advertisement When 10.0.0.0 Is Down
R1#show ip bgp neighbor 192.168.13.3 | include Condition-map Condition-map Prefix10, Advertise-map AS300-out, status: Withdraw R3#show ip bgp 172.16.0.0 % Network not in table
Example 4-22 shows the output of debug ip bgp update on R1 when 10.0.0.0/16 is down. Example 4-23 shows a similar output when 10.0.0.0/16 is up again.
Example 4-22 Output of debug ip bgp update on R1 When 10.0.0.0 Is Down
*Jul 29 21:37:39.411: BGP(0): route 10.0.0.0/16 down *Jul 29 21:37:39.411: BGP(0): no valid path for 10.0.0.0/16 *Jul 29 21:37:39.411: BGP(0): nettable_walker 10.0.0.0/16 no best path *Jul 29 21:37:39.411: BGP(0): 192.168.13.3 computing updates, afi 0, neighbor version 4, table version 5, starting at 0.0.0.0 *Jul 29 21:37:39.411: BGP(0): 192.168.13.3 update run completed, afi 0, ran for 0ms, neighbor version 4, start version 5, throttled to 5 *Jul 29 21:38:20.331: BPG(0): Condition Prefix10 changes to Withdraw *Jul 29 21:38:20.331: BGP(0): net 172.16.0.0/16 matches ADV MAP AS300-out: bump version to 6 *Jul 29 21:38:20.379: BGP(0): nettable_walker 172.16.0.0/16 route sourced locally *Jul 29 21:38:20.379: BGP(0): 192.168.13.3 computing updates, afi 0, neighbor version 5, table version 6, starting at 0.0.0.0 *Jul 29 21:38:20.379: BGP(0): 192.168.13.3 172.16.0.0/16 matches advertise map AS300-out, state: Withdraw *Jul 29 21:38:20.379: BGP(0): 192.168.13.3 send unreachable 172.16.0.0/16 *Jul 29 21:38:20.379: BGP(0): 192.168.13.3 send UPDATE 172.16.0.0/16 -- unreachable *Jul 29 21:38:20.379: BGP(0): 192.168.13.3 1 updates enqueued (average=26, maximum=26) *Jul 29 21:38:20.379: BGP(0): 192.168.13.3 update run completed, afi 0, ran for 0ms, neighbor version 5, start version 6, throttled to 6
Example 4-23 Output of debug ip bgp update on R1 When 10.0.0.0 Is Up
*Jul 29 21:40:10.679: BGP(0): route 10.0.0.0/16 up *Jul 29 21:40:10.679: BGP(0): nettable_walker 10.0.0.0/16 route sourced locally *Jul 29 21:40:10.679: BGP(0): 192.168.13.3 computing updates, afi 0, neighbor version 6, table version 7, starting at 0.0.0.0 *Jul 29 21:40:10.679: BGP(0): 192.168.13.3 update run completed, afi 0, ran for 0ms, neighbor version 6, start version 7, throttled to 7 *Jul 29 21:40:20.539: BPG(0): Condition Prefix10 changes to Advertise *Jul 29 21:40:20.539: BGP(0): net 172.16.0.0/16 matches ADV MAP AS300-out: bump version to 8 *Jul 29 21:40:21.119: BGP(0): nettable_walker 172.16.0.0/16 route sourced locally *Jul 29 21:40:37.639: BGP(0): 192.168.13.3 computing updates, afi 0, neighbor version 7, table version 8, starting at 0.0.0.0 *Jul 29 21:40:37.639: BGP(0): 192.168.13.3 172.16.0.0/16 matches advertise map AS300-out, state: Advertise *Jul 29 21:40:37.639: BGP(0): 192.168.13.3 send UPDATE (format) 172.16.0.0/16, next 192.168.13.1, metric 20, path *Jul 29 21:40:37.639: BGP(0): 192.168.13.3 1 updates enqueued (average=51, maximum=51) *Jul 29 21:40:37.639: BGP(0): 192.168.13.3 update run completed, afi 0, ran for 0ms, neighbor version 7, start version 8, throttled to 8