BGP Add-Path Policy Control
This chapter provides information about BGP add-path policy control.
Topics in this chapter include:
Applicability
This chapter was initially based on SR OS Release 15.0.R4, but the CLI in the current edition corresponds to SR OS Release 22.10.R2.
Overview
BGP add-path allows for advertising multiple paths per prefix for faster convergence, load sharing, and reduction of routing churn. See the BGP Add-Path chapter for more information.
The BGP add-path policy control feature extends the functionality of BGP add-path, which was able to control the number of advertised paths per prefix per address family. This meant that all prefixes that belonged to an address family (such as IPv4, IPv6, and so on) were subject to the same sending limit imposed by the send <number|keyword> command configured at the BGP instance, group, or neighbor level.
BGP add-path policy control adds the capability to configure the number of advertised paths on a per-prefix basis. The add-paths-send-limit route policy action allows overriding the sending limit in the bgp context for selected prefixes. This adds finer granularity to BGP add-path, where a global path limit is defined at the relevant BGP level and specific limits can be defined for exceptional prefixes at an import policy level.
A value between 1 and 16 is configurable for add-paths-send-limit.
BGP add-paths before policy control shows a topology for BGP add-paths before policy control.
In BGP add-paths before policy control, PE-2 receives two prefixes with three diverse paths from PE-1. PE-2 has a sending limit with a value of 3 configured at a BGP level that is applicable to PE-3. Therefore, PE-2 sends both prefixes with three different path IDs to PE-3.
BGP add-paths after policy control shows a topology for BGP add-paths after policy control.
In BGP add-paths after policy control, a BGP-import policy is applied on PE-2. The policy selectively applies a sending limit of 1 on the paths received for Prefix-2. Therefore, PE-2 sends only one path for Prefix-2 to PE-3, while the BGP level sending limit of 3 still applies for Prefix-1.
The policy action is only applicable for BGP-import policy and has no effect on BGP-export policy, VRF-import policy, or VRF-export policy. The reason for this is that the policy needs to be applied on the routes accepted into the RIB-IN, otherwise two or more paths may not be present.
The BGP-import policy does not match VPN-IP routes unless the vpn-apply-import true command is configured in the BGP global base, group, or neighbor level.
The route policy only controls the number of advertised paths, not the set of paths.
Configuration
The following configuration examples are in this section:
BGP add-path for address family IPv4 without policy control
BGP add-path for address family IPv4 with policy control
BGP add-path for address family VPN-IPv4 with policy control
Example topology
Example topology - IPv4 shows the example topology used for the BGP add-path policy control feature for the IPv4 address family. The topology used is similar to the one in the BGP Add-Path chapter, with the following characteristics:
CE-4 in AS 64500 advertises both prefixes 10.1.0.0/16 and 10.2.0.0/16 to its eBGP peers PE-1 and PE-2 in AS 64496.
RR-5 is route reflector for all PEs in AS 64496.
add-path is configured on all PE routers and RR-5 with a sending limit of 2.
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
Router interfaces
IS-IS as IGP on all interfaces within AS 64496 (alternatively, OSPF can be used)
LDP on all interfaces between the PEs in AS 64496, but not toward RR-5. LDP is used to create the transport tunnels that bind to the VPRN services in the VPN-IPv4 address family section.
BGP is configured on all the nodes. CE-4 peers with PE-1 and PE-2 and exports prefixes 10.1.0.0/16 and 10.2.0.0/16 to both eBGP peers, as follows:
# on CE-4:
configure {
router "Base" {
autonomous-system 64500
bgp {
rapid-withdrawal true
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
group "eBGP" {
peer-as 64496
export {
policy ["export-bgp"]
}
}
neighbor "172.16.14.1" {
group "eBGP"
}
neighbor "172.16.24.1" {
group "eBGP"
}
}
interface "int-loopback-1" {
loopback
ipv4 {
primary {
address 10.1.1.1
prefix-length 16
}
}
}
interface "int-loopback-2" {
loopback
ipv4 {
primary {
address 10.2.1.1
prefix-length 16
}
}
}
}
policy-options {
prefix-list "10.1.0.0/16" {
prefix 10.1.0.0/16 type longer {
}
}
prefix-list "10.2.0.0/16" {
prefix 10.2.0.0/16 type longer {
}
}
policy-statement "export-bgp" {
entry 10 {
from {
prefix-list ["10.1.0.0/16"]
}
action {
action-type accept
}
}
entry 20 {
from {
prefix-list ["10.2.0.0/16"]
}
action {
action-type accept
}
}
}
}
}The BGP configuration on CE-6 is similar, except for the export policy.
PE-1 peers with CE-4 in AS 64500 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
}
group "iBGP" {
next-hop-self true
peer-as 64496
add-paths {
ipv4 {
send 2
receive true
}
}
}
neighbor "172.16.14.2" {
group "eBGP"
}
neighbor "192.0.2.5" {
group "iBGP"
}
}
}
}The BGP configuration on PE-2 and PE-3 is similar to that of PE-1.
RR-5 acts as a 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" {
peer-as 64496
cluster {
cluster-id 5.5.5.5
}
add-paths {
ipv4 {
send 2
receive true
}
}
}
neighbor "192.0.2.1" {
group "iBGP"
}
neighbor "192.0.2.2" {
group "iBGP"
}
neighbor "192.0.2.3" {
group "iBGP"
}
}
}
}BGP add-path for address family IPv4 without policy control
RR-5 receives both the 10.1.0.0/16 and 10.2.0.0/16 prefixes with two paths from PE-1 and PE-2:
[/]
A:admin@RR-5# show router bgp routes
===============================================================================
BGP Router ID:192.0.2.5 AS:64496 Local AS:64496
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network LocalPref MED
Nexthop (Router) Path-Id IGP Cost
As-Path Label
-------------------------------------------------------------------------------
u*>i 10.1.0.0/16 100 None
192.0.2.1 2 10
64500 -
*i 10.1.0.0/16 100 None
192.0.2.2 2 10
64500 -
u*>i 10.2.0.0/16 100 None
192.0.2.1 1 10
64500 -
*i 10.2.0.0/16 100 None
192.0.2.2 1 10
64500 -
-------------------------------------------------------------------------------
Routes : 4
===============================================================================
RR-5 propagates these updates to its clients, for example to PE-3, as follows:
12 2023/01/26 12:57:20.218 CET MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 41
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 6 AS Path:
Type: 2 Len: 1 < 64500 >
Flag: 0x40 Type: 3 Len: 4 Nexthop: 192.0.2.1
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0x80 Type: 9 Len: 4 Originator ID: 192.0.2.1
Flag: 0x80 Type: 10 Len: 4 Cluster ID:
5.5.5.5
NLRI: Length = 14
10.1.0.0/16 Path-ID 11
10.2.0.0/16 Path-ID 12
"3 2023/01/26 12:56:53.218 CET MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 41
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 6 AS Path:
Type: 2 Len: 1 < 64500 >
Flag: 0x40 Type: 3 Len: 4 Nexthop: 192.0.2.2
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0x80 Type: 9 Len: 4 Originator ID: 192.0.2.2
Flag: 0x80 Type: 10 Len: 4 Cluster ID:
5.5.5.5
NLRI: Length = 14
10.1.0.0/16 Path-ID 1
10.2.0.0/16 Path-ID 2
"PE-3 receives both prefixes in its BGP routing table with two different paths (also, optionally, has ECMP and BGP multipath enabled as described in the BGP Add-Path chapter):
# on PE-3:
configure {
router "Base" {
ecmp 2
bgp {
multipath {
max-paths 2
}
}
}
}[/]
A:admin@PE-3# show router bgp routes
===============================================================================
BGP Router ID:192.0.2.3 AS:64496 Local AS:64496
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network LocalPref MED
Nexthop (Router) Path-Id IGP Cost
As-Path Label
-------------------------------------------------------------------------------
u*>i 10.1.0.0/16 100 None
192.0.2.1 11 10
64500 -
u*>i 10.1.0.0/16 100 None
192.0.2.2 1 10
64500 -
u*>i 10.2.0.0/16 100 None
192.0.2.1 12 10
64500 -
u*>i 10.2.0.0/16 100 None
192.0.2.2 2 10
64500 -
-------------------------------------------------------------------------------
Routes : 4
===============================================================================
BGP add-path for address family IPv4 with policy control
The following policy is enabled on RR-5, which limits the number of advertised paths for prefix 10.2.0.0/16 to one:
# on RR-5
configure {
policy-options {
prefix-list "10.2.0.0/16" {
prefix 10.2.0.0/16 type longer {
}
}
policy-statement "import-add-path" {
entry 10 {
from {
prefix-list ["10.2.0.0/16"]
}
action {
action-type accept
add-paths-send-limit 1
}
}
}
}
router "Base" {
bgp {
group "iBGP" {
import {
policy ["import-add-path"]
}
}
}
}
}RR-5 sends the following withdrawal message to PE-3:
13 2023/01/26 13:03:13.218 CET MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 7
10.2.0.0/16 Path-ID 2
Total Path Attr Length = 0
"PE-3 deletes the route with Path-ID 12 for prefix 10.2.0.0/16:
[/]
A:admin@PE-3# show router bgp routes
===============================================================================
BGP Router ID:192.0.2.3 AS:64496 Local AS:64496
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network LocalPref MED
Nexthop (Router) Path-Id IGP Cost
As-Path Label
-------------------------------------------------------------------------------
u*>i 10.1.0.0/16 100 None
192.0.2.1 11 10
64500 -
u*>i 10.1.0.0/16 100 None
192.0.2.2 1 10
64500 -
u*>i 10.2.0.0/16 100 None
192.0.2.1 12 10
64500 -
-------------------------------------------------------------------------------
Routes : 3
===============================================================================
BGP add-path for address family VPN-IPv4 with policy control
Example topology - VPN-IPv4 shows the example topology used for the BGP add-path policy control feature for VPN-IPv4 route family. The topology used is similar to the one used in the BGP Add-Path chapter. CE-4 exports both prefixes 172.31.1.0/24 and 172.31.2.0/24 to VPRN 1 on PE-1 and PE-2.
VPRN 1 is configured on all PEs in AS 64496. The configuration of VPRN 1 is similar on all PEs; for example, for PE-1, the VPRN configuration is as follows:
# on PE-1:
configure {
service {
vprn "VPRN 1" {
admin-state enable
service-id 1
customer "1"
autonomous-system 64496
bgp-ipvpn {
mpls {
admin-state enable
route-distinguisher "64496:1"
vrf-target {
community "target:64496:1"
}
auto-bind-tunnel {
resolution any
}
}
}
bgp {
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
group "eBGP-1" {
peer-as 64500
}
neighbor "172.16.114.2" {
group "eBGP-1"
}
}
interface "int-PE-1-CE-4-VPRN1" {
ipv4 {
primary {
address 172.16.114.1
prefix-length 30
}
}
sap 1/1/c1/2:1 {
}
}
}
}
}On the CEs, the configuration is either in the base routing instance, with additional router interfaces and BGP neighbors, or in a VPRN. In this example, the following VPRN is configured on CE-4:
# on CE-4:
configure {
service {
vprn "VPRN 1" {
admin-state enable
service-id 1
customer "1"
autonomous-system 64500
bgp-ipvpn {
mpls {
admin-state enable
route-distinguisher "64500:1"
}
}
bgp {
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
group "eBGP-1" {
peer-as 64496
export {
policy ["export-VPRN1"]
}
}
neighbor "172.16.114.1" {
group "eBGP-1"
}
neighbor "172.16.124.1" {
group "eBGP-1"
}
}
interface "int-CE-4-PE-1-VPRN1" {
ipv4 {
primary {
address 172.16.114.2
prefix-length 30
}
}
sap 1/1/c1/1:1 {
}
}
interface "int-CE-4-PE-2-VPRN1" {
ipv4 {
primary {
address 172.16.124.2
prefix-length 30
}
}
sap 1/1/c1/2:1 {
}
}
interface "loopback1-VPRN1" {
loopback true
ipv4 {
primary {
address 172.31.1.1
prefix-length 24
}
}
}
interface "loopback2-VPRN1" {
loopback true
ipv4 {
primary {
address 172.31.2.1
prefix-length 24
}
}
}
}
}
}The export policy to export prefixes 172.31.1.0/24 and 172.31.2.0/24 is defined as follows:
# on CE-4:
configure {
policy-options {
prefix-list "172.31.0.0/16" {
prefix 172.31.0.0/16 type longer {
}
}
policy-statement "export-VPRN1" {
entry 10 {
from {
prefix-list ["172.31.0.0/16"]
}
action {
action-type accept
}
}
}
}
}The configuration on CE-6 is similar, but no prefix is exported from CE-6.
For all BGP speakers in AS 64496, BGP must be configured for address family VPN-IPv4 as well as for IPv4, as follows:
# on PE-1, PE-2, PE-3, RR-5:
configure {
router "Base" {
bgp {
group "iBGP" {
family {
ipv4 true
vpn-ipv4 true
}
}
}
}
}BGP add-path cannot be enabled in the bgp context within a VPRN. However, it can be enabled in the base routing instance for address family VPN-IPv4. This is done on all PEs and RR-5 at group level with the following configuration:
# on PE-1, PE-2, PE-3, RR-5:
configure exclusive
router "Base" {
bgp {
group "iBGP" {
add-paths {
vpn-ipv4 {
send 2
receive true
}
}
}
}
}
}The BGP configuration on PE-1 is as follows:
# on PE-1:
configure {
router "Base" {
bgp {
rapid-withdrawal true
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
group "eBGP" {
peer-as 64500
}
group "iBGP" {
next-hop-self true
peer-as 64496
family {
ipv4 true
vpn-ipv4 true
}
add-paths {
ipv4 {
send 2
receive true
}
vpn-ipv4 {
send 2
receive true
}
}
}
neighbor "172.16.14.2" {
group "eBGP"
}
neighbor "192.0.2.5" {
group "iBGP"
}
}
}
}With add-path enabled for address family VPN-IPv4, PE-1 and PE-2 advertise their routes for prefixes 172.31.1.0/24 and 172.31.2.0/24 as VPN-IPv4 routes to RR-5. RR-5 advertises both routes to its other RR clients. PE-3 receives two VPN-IPv4 routes for each of the prefixes 172.31.1.0/24 and 172.31.2.0/24, as follows:
[/]
A:admin@PE-3# show router bgp routes 172.31.0.0/16 vpn-ipv4 longer
===============================================================================
BGP Router ID:192.0.2.3 AS:64496 Local AS:64496
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
Flag Network LocalPref MED
Nexthop (Router) Path-Id IGP Cost
As-Path Label
-------------------------------------------------------------------------------
u*>i 64496:1:172.31.1.0/24 100 None
192.0.2.1 21 10
64500 524283
u*>i 64496:1:172.31.1.0/24 100 None
192.0.2.2 9 10
64500 524283
u*>i 64496:1:172.31.2.0/24 100 None
192.0.2.1 20 10
64500 524283
u*>i 64496:1:172.31.2.0/24 100 None
192.0.2.2 10 10
64500 524283
-------------------------------------------------------------------------------
Routes : 4
===============================================================================
All routes are used because of the ECMP setting in VPRN 1:
# on PE-3:
configure {
service {
vprn "VPRN 1" {
ecmp 2
}
}
}Alternatively, BGP FRR can be enabled for VPRN 1, as described in the BGP Add-Path chapter.
To limit the advertisement of prefix 172.31.2.0/24 to a single path, the following route policy is configured on RR-5:
# on RR-5:
configure {
policy-options {
prefix-list "172.31.2.0/24" {
prefix 172.31.2.0/24 type longer {
}
}
policy-statement "import-add-path" {
entry 20 {
from {
prefix-list ["172.31.2.0/24"]
}
action {
action-type accept
add-paths-send-limit 1
}
}
}
}
}The policy entry for prefix 172.31.2.0/24 can be configured in a new policy-statement or be added to an existing BGP policy (used for the previous IPv4 add-path policy section, for example).
If this is a new policy-statement, apply the policy in the group "iBGP" context on RR-5:
# on RR-5:
configure {
router "Base" {
bgp {
group "iBGP" {
import {
policy ["import-add-path"]
}
}
}
}
}At this point, PE-3 still has two paths for each of the prefixes:
[/]
A:admin@PE-3# show router bgp routes 172.31.0.0/16 vpn-ipv4 longer
===============================================================================
BGP Router ID:192.0.2.3 AS:64496 Local AS:64496
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
Flag Network LocalPref MED
Nexthop (Router) Path-Id IGP Cost
As-Path Label
-------------------------------------------------------------------------------
u*>i 64496:1:172.31.1.0/24 100 None
192.0.2.1 21 10
64500 524283
u*>i 64496:1:172.31.1.0/24 100 None
192.0.2.2 9 10
64500 524283
u*>i 64496:1:172.31.2.0/24 100 None
192.0.2.1 20 10
64500 524283
u*>i 64496:1:172.31.2.0/24 100 None
192.0.2.2 10 10
64500 524283
-------------------------------------------------------------------------------
Routes : 4
===============================================================================
The following configuration is applied on RR-5 to make the BGP policy effective for VPN-IPV4 routes:
# on RR-5:
configure {
router "Base" {
bgp {
vpn-apply-import true
}
}
}Upon application of this configuration, RR-5 sends the following withdrawal to PE-3:
57 2023/01/26 13:14:03.218 CET MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 26
Flag: 0x90 Type: 15 Len: 22 Multiprotocol Unreachable NLRI:
Address Family VPN_IPV4
172.31.2.0/24 RD 64496:1 Label 0 (Raw label 0x1) Path-ID 10
"PE-3 now has a single route for prefix 172.31.2.0/24 in its BGP routing table:
[/]
A:admin@PE-3# show router bgp routes 172.31.0.0/16 vpn-ipv4 longer
===============================================================================
BGP Router ID:192.0.2.3 AS:64496 Local AS:64496
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
Flag Network LocalPref MED
Nexthop (Router) Path-Id IGP Cost
As-Path Label
-------------------------------------------------------------------------------
u*>i 64496:1:172.31.1.0/24 100 None
192.0.2.1 21 10
64500 524283
u*>i 64496:1:172.31.1.0/24 100 None
192.0.2.2 9 10
64500 524283
u*>i 64496:1:172.31.2.0/24 100 None
192.0.2.1 20 10
64500 524283
-------------------------------------------------------------------------------
Routes : 3
===============================================================================
PE-3 has installed a single route for prefix 172.31.2.0/24 in its VPRN route table:
[/]
A:admin@PE-3# show router 1 route-table 172.31.0.0/16 longer
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
172.31.1.0/24 Remote BGP VPN 00h06m31s 170
192.0.2.1 (tunneled) 10
172.31.1.0/24 Remote BGP VPN 00h06m31s 170
192.0.2.2 (tunneled) 10
172.31.2.0/24 Remote BGP VPN 00h01m26s 170
192.0.2.1 (tunneled) 10
-------------------------------------------------------------------------------
No. of Routes: 3
Flags: n = Number of times nexthop is repeated
B = BGP backup route available
L = LFA nexthop available
S = Sticky ECMP requested
===============================================================================
Conclusion
The BGP add-path policy control feature allows BGP speakers to advertise multiple distinct paths for the same prefix. The potential benefits of using BGP add-path policy control are increased granularity and flexibility in advertising multiple paths to BGP neighbors.