BGP Conditional Route Advertisement
This chapter provides information about BGP Conditional Route Advertisement.
Topics in this chapter include:
Applicability
The information and configuration in this chapter was originally based on SR OS Release 15.0.R4. The CLI in the current edition is based on SR OS Release 23.3.R2.
Overview
The BGP conditional route advertisement feature allows a router to control the advertisement of routes based on predetermined routes in the route table. Conditional BGP Route Advertisement - ISP Peering shows an example in which this feature can bring flexibility in an ISP peering scenario.
ISP 1 and ISP 2 have two peering points; a first between ASBR1 and ASBR3, and a second between ASBR2 and ASBR4. For redundancy, ISP 1 has two links between ASBR1 and the internal P1 router, one with 100 Gb/s and the other with 10 Gb/s capacity. According to the service agreement, ISP 1 instructs ISP 2 to send traffic using the upper path (between ASBR1 and ASBR3) only if the 100 Gb/s link between P1 and ASBR1 is up. If this is not the case, ISP 2 uses the lower path.
To implement the BGP conditional route advertisement feature, a conditional route policy entry is used. The route policy is as follows:
Within a policy-statement entry, a conditional expression is created.
The conditional expression tests for active IPv4 or IPv6 routes defined in a prefix list.
If the expression is true, the action commands of the policy entry are applied.
If the expression is false, the entire policy entry is skipped and processing continues with the next policy entry.
Conditional expressions are only applicable when the route policy is used as a BGP export policy or a VRF export policy.
Conditional BGP Route Advertisement Implementation Example shows the implementation using the example in Conditional BGP Route Advertisement - ISP Peering.
The prefix of the 100G interface between ASBR1 and P1 is 172.16.141.0/30. ASBR1 receives prefix 10.0.0.0/8 from P1 via BGP. Under standard conditions, the 100G interface is up and 172.16.141.0/30 exists in the route table and ASBR1 advertises 10.0.0.0/8 with a community value of 64500:100. ASBR2 advertises the same prefix with a community value of 64500:50. ASBR3 and ASBR4 in ISP 2 use an import policy that applies local preference values of 100 and 50 on the routes advertised by ASBR1 and ASBR2, respectively. As a result, the routers in ISP 2 prefer ASBR3 as an exit point for traffic flowing toward ISP 1.
If the 100G interface goes down, the prefix 172.16.141.0/30 is withdrawn from the route table and, as a result, ASBR1 starts advertising 10.0.0.0/8 with a community value of 64500:10. ASBR3 and ASBR4 adjust the local preference value for ASBR1 to 10 and, therefore, ASBR4 becomes the preferred exit point for routers in ISP 2.
The only conditional expression that can be contained in a policy-statement entry is a route-existence test defined by the route-exists keyword in the CLI. The command accepts two parameters: all and none:
If neither the all nor the none parameter is used, the match logic is any - that is, the conditional expression is true if any exact match entry in the referenced prefix list has an active route in the route table associated with the policy.
all - the conditional expression is true only if all the exact match entries in the referenced prefix list have an active route in the route table associated with the policy.
none - the conditional expression is true only if none of the exact match entries in the referenced prefix list have an active route in the route table associated with the policy.
Configuration
The following configuration examples are covered in this section:
BGP Conditional Route Advertisement Using "any" Prefix List Match
BGP Conditional Route Advertisement Using "all" Prefix List Match
BGP Conditional Route Advertisement Using "none" Prefix List Match
Example Topology shows the example topology for BGP conditional route advertisement with the following characteristics:
CE-4 in AS 64500 advertises prefix 10.0.0.0/8 to its eBGP peers PE-1 and PE-2 in AS 64496.
PE-1 has three loopback interfaces configured to demonstrate the use of conditional route advertisement: LP-1, LP-2, and LP-3.
RR-5 is route reflector for all PEs in AS 64496.
CE-6 in AS 64501 peers with PE-3 in AS 64496 and can send traffic to CE-4 in 64500.
Initial Configuration
The initial configuration on all nodes includes:
Cards, MDAs, ports
LAG configured for the link between CE-4 and PE-1 with two member links
Router interfaces
IS-IS as IGP on all interfaces within AS 64496 (alternatively, OSPF can be used)
BGP is configured on all the nodes. CE-4 peers with PE-1 and PE-2 and exports the prefix 10.0.0.0/8 to both eBGP peers, which includes the address of the int-loopback-1 interface, as follows:
# On CE-4:
configure {
policy-options {
prefix-list "10.0.0.0/8" {
prefix 10.0.0.0/8 type longer {
}
}
policy-statement "policy-export-bgp" {
entry 10 {
from {
prefix-list ["10.0.0.0/8"]
}
action {
action-type accept
}
}
}
}
router "Base" {
autonomous-system 64500
interface "int-loopback-1" {
loopback
ipv4 {
primary {
address 10.1.1.1
prefix-length 8
}
}
}
bgp {
rapid-withdrawal true
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
group "eBGP" {
peer-as 64496
export {
policy ["policy-export-bgp"]
}
}
neighbor "172.16.14.1" {
group "eBGP"
}
neighbor "172.16.24.1" {
group "eBGP"
}
}
}
}
The BGP configuration on CE-6 is identical, except for the loopback interface and export policy.
PE-1 peers with CE-4 in AS 65400 and RR-5 in AS 64496. The BGP configuration on PE-1 is as follows:
# On PE-1:
configure {
router "Base" {
autonomous-system 64496
bgp {
rapid-withdrawal true
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
group "eBGP" {
peer-as 64500
}
neighbor "172.16.14.2" {
group "eBGP"
}
group "iBGP" {
next-hop-self true
peer-as 64496
}
neighbor "192.0.2.5" {
group "iBGP"
}
}
exit all
The BGP configuration on PE-2 and PE-3 is similar to that of PE-1.
RR-5 is the route reflector to all the PEs in AS 64500 with a cluster ID of 5.5.5.5. The configuration on RR-5 is as follows:
# On RR-5:
configure {
router "Base" {
autonomous-system 64496
bgp {
rapid-withdrawal true
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
group "iBGP" {
cluster {
cluster-id 5.5.5.5
}
peer-as 64496
}
neighbor "192.0.2.1" {
group "iBGP"
}
neighbor "192.0.2.2" {
group "iBGP"
}
neighbor "192.0.2.3" {
group "iBGP"
}
}
exit all
Three loopback interfaces are configured in PE-1 to be used for route existence tests:
# On PE-1:
configure {
router "Base" {
interface "int-loopback-1" {
admin-state enable
loopback
ipv4 {
primary {
address 172.31.1.1
prefix-length 24
}
}
}
interface "int-loopback-2" {
admin-state enable
loopback
ipv4 {
primary {
address 172.31.2.1
prefix-length 24
}
}
}
interface "int-loopback-3" {
admin-state enable
loopback
ipv4 {
primary {
address 172.31.3.1
prefix-length 24
}
}
}
exit all
BGP Conditional Route Advertisement Using "any" Prefix List Match
In the initial condition, RR-5 receives the prefix 10.0.0.0/8 from PE-1 and PE-2 with no community values and the default local preference value of 100:
[/]
A:admin@RR-5# show router bgp routes 10.0.0.0/8 hunt brief | match '^Nexthop|^Community|Pref'
Nexthop : 192.0.2.1
Local Pref. : 100 Interface Name : int-RR-5-PE-1
Community : No Community Members
Nexthop : 192.0.2.2
Local Pref. : 100 Interface Name : int-RR-5-PE-2
Community : No Community Members
The following policy is configured on PE-1 that adds the community 64500:100 to the 10.0.0.0/8 prefix advertised to RR-5 if any of the conditional prefixes in the prefix list are active in the route table:
# On PE-1:
configure {
policy-options {
community "64500:10" {
member "64500:10" { }
}
community "64500:100" {
member "64500:100" { }
}
prefix-list "10.0.0.0/8" {
prefix 10.0.0.0/8 type longer {
}
}
prefix-list "prefix-conditional-routes" {
prefix 172.31.1.0/24 type longer {
}
prefix 172.31.2.0/24 type longer {
}
prefix 172.31.3.0/24 type longer {
}
}
policy-statement "policy-bgp-community" {
entry 10 {
conditional-expression {
route-exists "[prefix-conditional-routes]"
}
from {
prefix-list ["10.0.0.0/8"]
}
action {
action-type accept
community {
add ["64500:100"]
}
}
}
entry 20 {
from {
prefix-list ["10.0.0.0/8"]
}
action {
action-type accept
community {
add ["64500:10"]
}
}
}
}
exit all
Special attention is required on the policy syntax. The square brackets […] in the expression of the route-exists command are very important.
The following policy is configured on PE-2 that adds the community 64500:50 to the 10.0.0.0/8 prefix advertised to RR-5 without any conditions:
# On PE-2:
configure {
policy-options {
community "64500:50" {
member "64500:50" { }
}
prefix-list "10.0.0.0/8" {
prefix 10.0.0.0/8 type longer {
}
}
policy-statement "policy-bgp-community" {
entry 10 {
from {
prefix-list ["10.0.0.0/8"]
}
action {
action-type accept
community {
add ["64500:50"]
}
}
}
}
exit all
The policy is applied to the iBGP group on PE-1 and PE-2:
# On PE-1 and on PE-2:
configure {
router "Base" {
bgp {
group "iBGP" {
export {
policy ["policy-bgp-community"]
exit all
The prefix 10.0.0.0/8 is received on RR-5 with the respective community values and still with the default local preference values:
[/]
A:admin@RR-5# show router bgp routes 10.0.0.0/8 hunt brief | match '^Nexthop|^Community|Pref'
Nexthop : 192.0.2.1
Local Pref. : 100 Interface Name : int-RR-5-PE-1
Community : 64500:100
Nexthop : 192.0.2.2
Local Pref. : 100 Interface Name : int-RR-5-PE-2
Community : 64500:50
The following policy is configured on RR-5 to apply different local preference values based on the corresponding community value:
# On RR-5:
configure {
policy-options {
community "64500:10" {
member "64500:10" { }
}
community "64500:100" {
member "64500:100" { }
}
community "64500:50" {
member "64500:50" { }
}
policy-statement "policy-bgp-preference" {
entry 10 {
from {
community {
name "64500:100"
}
}
action {
action-type accept
local-preference 100
}
}
entry 20 {
from {
community {
name "64500:50"
}
}
action {
action-type accept
local-preference 50
}
}
entry 30 {
from {
community {
name "64500:10"
}
}
action {
action-type accept
local-preference 10
}
}
}
exit all
The policy is applied on RR-5:
# On RR-5:
configure {
router "Base" {
bgp {
group "iBGP" {
import {
policy ["policy-bgp-preference"]
exit all
The following command output shows that the correct local preference values are applied on the routes received from PE-1 and PE-2:
[/]
A:admin@RR-5# show router bgp routes 10.0.0.0/8 hunt brief | match '^Nexthop|^Community|Pref'
Nexthop : 192.0.2.1
Local Pref. : 100 Interface Name : int-RR-5-PE-1
Community : 64500:100
Nexthop : 192.0.2.2
Local Pref. : 50 Interface Name : int-RR-5-PE-2
Community : 64500:50
TieBreakReason : LocalPref
RR-5 advertises the route with local preference of 100 to PE-3, with next hop PE-1:
[/]
A:admin@PE-3# show router bgp routes 10.0.0.0/8 hunt brief | match '^Nexthop|^Community|Pref'
Nexthop : 192.0.2.1
Local Pref. : 100 Interface Name : int-PE-3-PE-1
Community : 64500:100
The first loopback interface is shutdown on PE-1, which results in the withdrawal of prefix 172.31.1.0/24 from the route table on PE-1:
# On PE-1:
configure {
router "Base" {
interface "int-loopback-1" {
admin-state disable
exit all
PE-1 still advertises the prefix 10.0.0.0/8 with the community 64500:100:
[/]
A:admin@RR-5# show router bgp routes 10.0.0.0/8 hunt brief | match '^Nexthop|^Community|Pref'
Nexthop : 192.0.2.1
Local Pref. : 100 Interface Name : int-RR-5-PE-1
Community : 64500:100
Nexthop : 192.0.2.2
Local Pref. : 50 Interface Name : int-RR-5-PE-2
Community : 64500:50
TieBreakReason : LocalPref
The second loopback interface is shutdown on PE-1, which results in the withdrawal of prefix 172.31.2.0/24 from the route on PE-1:
# On PE-1:
configure {
router "Base" {
interface "int-loopback-2" {
admin-state disable
exit allPE-1 still advertises the prefix 10.0.0.0/8 with the community 64500:100:
[/]
A:admin@RR-5# show router bgp routes 10.0.0.0/8 hunt brief | match '^Nexthop|^Community|Pref'
Nexthop : 192.0.2.1
Local Pref. : 100 Interface Name : int-RR-5-PE-1
Community : 64500:100
Nexthop : 192.0.2.2
Local Pref. : 50 Interface Name : int-RR-5-PE-2
Community : 64500:50
TieBreakReason : LocalPref
The third and the last loopback interface is shutdown on PE-1, which results in the withdrawal of prefix 172.31.3.0/24 from the route table on PE-1:
# On PE-1:
configure {
router "Base" {
interface "int-loopback-3" {
admin-state disable
exit all
PE-1 now starts advertising the prefix 10.0.0.0/8 with the community 64500:10 and RR-5 applies local preference 10 for this route:
[/]
A:admin@RR-5# show router bgp routes 10.0.0.0/8 hunt brief | match '^Nexthop|^Community|Pref'
Nexthop : 192.0.2.2
Local Pref. : 50 Interface Name : int-RR-5-PE-2
Community : 64500:50
Nexthop : 192.0.2.1
Local Pref. : 10 Interface Name : int-RR-5-PE-1
Community : 64500:10
TieBreakReason : LocalPref
RR-5 advertises prefix 10.0.0.0/8 to PE-3 with the next-hop address of PE-2:
[/]
A:admin@PE-3# show router bgp routes 10.0.0.0/8 hunt brief | match '^Nexthop|^Community|Pref'
Nexthop : 192.0.2.2
Local Pref. : 50 Interface Name : int-PE-3-PE-2
Community : 64500:50
BGP Conditional Route Advertisement Using "all" Prefix List Match
The loopback interfaces on PE-1 are re-enabled:
# On PE-1:
configure {
router "Base" {
interface "int-loopback-1" {
admin-state enable
}
interface "int-loopback-2" {
admin-state enable
}
interface "int-loopback-3" {
admin-state enable
}
exit all
The policy on PE-1 is changed so that the prefix 10.0.0.0/8 is advertised with community 64500:100 only if all the prefixes in the prefix list are active:
# On PE-1:
configure {
policy-options {
policy-statement "policy-bgp-community" {
entry 10 {
conditional-expression {
route-exists "[prefix-conditional-routes] all"
exit all
The first loopback interface is shutdown on PE-1, which results in the withdrawal of prefix 172.31.1.0/24 from the route table on PE-1:
# On PE-1:
configure {
router "Base" {
interface "int-loopback-1" {
admin-state disable
exit all
PE-1 now advertises the prefix 10.0.0.0/8 with the community 64500:10:
[/]
A:admin@RR-5# show router bgp routes 10.0.0.0/8 hunt brief | match '^Nexthop|^Community|Pref'
Nexthop : 192.0.2.2
Local Pref. : 50 Interface Name : int-RR-5-PE-2
Community : 64500:50
Nexthop : 192.0.2.1
Local Pref. : 10 Interface Name : int-RR-5-PE-1
Community : 64500:10
TieBreakReason : LocalPref
RR-5 advertises prefix 10.0.0.0/8 to PE-3 with the next-hop address of PE-2:
[/]
A:admin@PE-3# show router bgp routes 10.0.0.0/8 hunt brief | match '^Nexthop|^Community|Pref'
Nexthop : 192.0.2.2
Local Pref. : 50 Interface Name : int-PE-3-PE-2
Community : 64500:50
BGP Conditional Route Advertisement Using "none" Prefix List Match
The loopback interfaces on PE-1 are re-enabled:
# On PE-1:
configure {
router "Base" {
interface "int-loopback-1" {
admin-state enable
}
interface "int-loopback-2" {
admin-state enable
}
interface "int-loopback-3" {
admin-state enable
}
exit all
The policy on PE-1 is changed so that the prefix 10.0.0.0/8 is advertised with community 64500:100 only if none of the prefixes in the prefix list are active:
# On PE-1:
configure {
policy-options {
policy-statement "policy-bgp-community" {
entry 10 {
conditional-expression {
route-exists "[prefix-conditional-routes] none"
exit all
PE-1 advertises the prefix 10.0.0.0/8 with the community 64500:10, because all loopback interface prefixes are active:
[/]
A:admin@RR-5# show router bgp routes 10.0.0.0/8 hunt brief | match '^Nexthop|^Community|Pref'
Nexthop : 192.0.2.2
Local Pref. : 50 Interface Name : int-RR-5-PE-2
Community : 64500:50
Nexthop : 192.0.2.1
Local Pref. : 10 Interface Name : int-RR-5-PE-1
Community : 64500:10
TieBreakReason : LocalPref
The loopback interfaces are shut down one by one or together using a range with the following command on PE-1:
# On PE-1:
configure {
router "Base" {
interface "int-loopback-1" {
admin-state disable
}
interface "int-loopback-2" {
admin-state disable
}
interface "int-loopback-3" {
admin-state disable
}
exit all
PE-1 now advertises the prefix 10.0.0.0/8 with the community 64500:100:
[/]
A:admin@RR-5# show router bgp routes 10.0.0.0/8 hunt brief | match '^Nexthop|^Community|Pref'
Nexthop : 192.0.2.1
Local Pref. : 100 Interface Name : int-RR-5-PE-1
Community : 64500:100
Nexthop : 192.0.2.2
Local Pref. : 50 Interface Name : int-RR-5-PE-2
Community : 64500:50
TieBreakReason : LocalPref
RR-5 advertises prefix 10.0.0.0/8 to PE-3 with the next-hop address of PE-1:
[/]
A:admin@PE-3# show router bgp routes 10.0.0.0/8 hunt brief | match '^Nexthop|^Community|Pref'
Nexthop : 192.0.2.1
Local Pref. : 100 Interface Name : int-PE-3-PE-1
Community : 64500:100
Conclusion
BGP conditional route advertisement allows the control of BGP updates based on routes in the route table. A conditional policy entry can be created that tests whether any, all, or none of the prefixes in a prefix list are active and executes the related policy actions.