BGP Add-paths Policy Control
This chapter provides information about BGP add-paths policy control.
Topics in this chapter include:
Applicability
The CLI in the latest update corresponds to SR Linux Release 26.3.3.
Overview
BGP add-paths allows for advertising multiple paths per prefix for faster convergence, load sharing, and reduction of routing churn. See the BGP Add-Paths chapter for more information.
The BGP add-paths policy control feature extends the functionality of BGP add-paths and allows to control the number of advertised paths per prefix per address family. With BGP add-paths, all prefixes that belong to an address family (such as IPv4, IPv6, and so on) are subject to the same sending limit imposed by the add-paths send-max <number> command configured at the BGP instance, group, or neighbor level.
BGP add-paths policy control adds the capability to configure the number of advertised paths on a per prefix per address family basis. The eligible-prefix-policy <routing-policy> allows specifying per address family the prefixes for which add-paths send-max <number> as configured at the BGP instance, group, or neighbor level applies. This adds finer granularity to BGP add-paths, where a global path limit is defined per address family at the relevant BGP level and specific policies specify per address family what prefixes it is applied for.
As an example, 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 eligible-prefix-policy <policy> is applied on PE-2. The policy selectively applies add-paths only for Prefix-1, so PE-2 sends Prefix 1 with three different path IDs to PE-3 . However, PE-2 sends only one path for Prefix-2 to PE-3, because the add-paths sending limit of 3 only applies for Prefix-1.
The routing policy only controls the eligibility of the prefix-set for the add-paths control, not the number of advertised paths or the set of paths.
Configuration
The following configuration examples are in this section:
Example topology
Example topology - IPv4 shows the example topology used for the BGP add-paths policy control feature for the IPv4 address family. The topology used is similar to the one in the BGP Add-Paths chapter, with the following characteristics:
-
CE-4 in AS 64500 advertises both prefixes 10.1.0.0/16 and 10.2.0.0/16 in the default network instance to its eBGP peers PE-1 and PE-2 in AS 64496.
RR-5 is route reflector for all PEs in AS 64496.
add-paths is configured for the IPv4 address family 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:
Interfaces
IS-IS as IGP on all interfaces within AS 64496
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 IP-VRF 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:
enter candidate
network-instance default {
protocols {
bgp {
admin-state enable
autonomous-system 64500
router-id 192.0.2.4
afi-safi ipv4-unicast {
admin-state enable
}
trace-options {
flag update {
}
}
group grp-EBGP {
peer-as 64496
export-policy [
rp-export-bgp
]
}
neighbor 172.16.14.1 {
peer-group grp-EBGP
}
neighbor 172.16.24.1 {
peer-group grp-EBGP
}
}
}
interface loopback1 {
interface-ref {
interface lo0
subinterface 1
}
}
interface loopback2 {
interface-ref {
interface lo0
subinterface 2
}
}
}
interface lo0 {
admin-state enable
subinterface 1 {
description loopback1
admin-state enable
ipv4 {
admin-state enable
address 10.1.1.1/16 {
primary
}
}
}
subinterface 2 {
description loopback2
admin-state enable
ipv4 {
admin-state enable
address 10.2.1.1/16 {
primary
}
}
}
}
routing-policy {
standard-community-set scs-1:0 {
member [
1:0
]
}
prefix-set ps-10.1.0.0 {
prefix 10.1.0.0/16 mask-length-range exact {
}
}
prefix-set ps-10.2.0.0 {
prefix 10.2.0.0/16 mask-length-range exact {
}
}
policy rp-export-bgp {
statement stmt-10 {
match {
prefix {
prefix-set ps-10.1.0.0
}
}
action {
policy-result accept
bgp {
standard-community {
operation add
method reference
referenced-sets [
scs-1:0
]
}
origin {
set igp
}
}
}
}
statement stmt-20 {
match {
prefix {
prefix-set ps-10.2.0.0
}
}
action {
policy-result accept
bgp {
standard-community {
operation add
method reference
referenced-sets [
scs-1:0
]
}
origin {
set igp
}
}
}
}
}
}The BGP configuration on CE-6 is similar.
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:
enter candidate
network-instance default {
protocols {
bgp {
admin-state enable
autonomous-system 64496
router-id 192.0.2.1
afi-safi ipv4-unicast {
admin-state enable
}
trace-options {
flag update {
}
}
group grp-EBGP {
peer-as 64500
import-policy [
rp-import-1:0
]
}
group grp-IBGP {
next-hop-self true
peer-as 64496
afi-safi ipv4-unicast {
admin-state enable
add-paths {
receive true
send true
send-max 2
}
}
}
neighbor 172.16.14.2 {
peer-group grp-EBGP
}
neighbor 192.0.2.5 {
peer-group grp-IBGP
}
}
}
}
routing-policy {
standard-community-set scs-1:0 {
member [
1:0
]
}
policy rp-import-1:0 {
default-action {
policy-result reject
}
statement stmt-10 {
match {
bgp {
standard-community {
standard-community-set scs-1:0
}
}
}
action {
policy-result accept
}
}
}
}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 64496 with a cluster ID of 192.0.2.5. The configuration on RR-5 is as follows:
# on RR-5:
enter candidate
network-instance default {
protocols {
bgp {
admin-state enable
autonomous-system 64496
router-id 192.0.2.5
afi-safi ipv4-unicast {
admin-state enable
}
route-reflector {
client true
cluster-id 192.0.2.5
}
trace-options {
flag update {
}
}
group grp-IBGP {
peer-as 64496
afi-safi ipv4-unicast {
admin-state enable
add-paths {
receive true
send true
send-max 2
}
}
}
neighbor 192.0.2.1 {
peer-group grp-IBGP
}
neighbor 192.0.2.2 {
peer-group grp-IBGP
}
neighbor 192.0.2.3 {
peer-group grp-IBGP
}BGP add-paths 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 / network-instance default protocols bgp routes ipv4 summary
---------------------------------------------------------------------------------------------------------------------------------------------------------
Show report for the BGP route table of network-instance "default"
---------------------------------------------------------------------------------------------------------------------------------------------------------
Status codes: u=used, *=valid, >=best, x=stale, b=backup, w=unused-weight-only
Origin codes: i=IGP, e=EGP, ?=incomplete
---------------------------------------------------------------------------------------------------------------------------------------------------------
+--------+------------------------------------+------------------------------------+--------+--------+-------------------------------------------------+
| Status | Network | Next Hop | MED | LocPre | Path Val |
| | | | | f | |
+========+====================================+====================================+========+========+=================================================+
| u*> | 10.1.0.0/16 | 192.0.2.1 | | 100 | i[64500] |
| * | 10.1.0.0/16 | 192.0.2.2 | | 100 | i[64500] |
| u*> | 10.2.0.0/16 | 192.0.2.1 | | 100 | i[64500] |
| * | 10.2.0.0/16 | 192.0.2.2 | | 100 | i[64500] |
| ---snip--- |
+--------+------------------------------------+------------------------------------+--------+--------+-------------------------------------------------+
---------------------------------------------------------------------------------------------------------------------------------------------------------
13 received BGP routes: 11 used, 13 valid, 0 stale
11 available destinations: 2 with ECMP multipaths
---------------------------------------------------------------------------------------------------------------------------------------------------------RR-5 propagates these updates to its clients, for example to PE-3, as follows:
# on RR-5:
2026-06-17T21:18:02.087858+00:00 RR-5 sr_bgp_mgr: bgp|181370|181403|00023|TR||D: VR default (1) Peer 1: 192.0.2.3 UPDATE: Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 48
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: 0xc0 Type: 8 Len: 4 Community:
1:0
Flag: 0x80 Type: 9 Len: 4 Originator ID: 192.0.2.2
Flag: 0x80 Type: 10 Len: 4 Cluster ID:
192.0.2.5
NLRI: Length = 14
10.1.0.0/16 Path-ID 8
10.2.0.0/16 Path-ID 10# on RR-5:
2026-06-17T21:18:02.087881+00:00 RR-5 sr_bgp_mgr: bgp|181370|181403|00024|TR||D: VR default (1) Peer 1: 192.0.2.3 UPDATE: Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 48
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: 0xc0 Type: 8 Len: 4 Community:
1:0
Flag: 0x80 Type: 9 Len: 4 Originator ID: 192.0.2.1
Flag: 0x80 Type: 10 Len: 4 Cluster ID:
192.0.2.5
NLRI: Length = 14
10.1.0.0/16 Path-ID 7
10.2.0.0/16 Path-ID 9PE-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-Paths chapter):
# on PE-3:
enter candidate
network-instance default {
protocols {
bgp {
afi-safi ipv4-unicast {
multipath {
ibgp {
maximum-paths 2
}
}
}
}
isis {
instance 0 {
max-ecmp-paths 2
}
}A:admin@PE-3# show / network-instance default protocols bgp routes ipv4 summary
---------------------------------------------------------------------------------------------------------------------------------------------------------
Show report for the BGP route table of network-instance "default"
---------------------------------------------------------------------------------------------------------------------------------------------------------
Status codes: u=used, *=valid, >=best, x=stale, b=backup, w=unused-weight-only
Origin codes: i=IGP, e=EGP, ?=incomplete
---------------------------------------------------------------------------------------------------------------------------------------------------------
+--------+------------------------------------+------------------------------------+--------+--------+-------------------------------------------------+
| Status | Network | Next Hop | MED | LocPre | Path Val |
| | | | | f | |
+========+====================================+====================================+========+========+=================================================+
| u*> | 10.1.0.0/16 | 192.0.2.1 | | 100 | i[64500] |
| u*> | 10.1.0.0/16 | 192.0.2.2 | | 100 | i[64500] |
| u*> | 10.2.0.0/16 | 192.0.2.1 | | 100 | i[64500] |
| u*> | 10.2.0.0/16 | 192.0.2.2 | | 100 | i[64500] |
| ---snip--- |
+--------+------------------------------------+------------------------------------+--------+--------+-------------------------------------------------+
---------------------------------------------------------------------------------------------------------------------------------------------------------
14 received BGP routes: 14 used, 14 valid, 0 stale
14 available destinations: 0 with ECMP multipaths
---------------------------------------------------------------------------------------------------------------------------------------------------------Or, with a grep to reduce output:
A:admin@PE-3# show / network-instance default protocols bgp routes ipv4 summary | grep -E '10.(1|2)'
| u*> | 10.1.0.0/16 | 192.0.2.1 | | 100 | i[64500] |
| u*> | 10.1.0.0/16 | 192.0.2.2 | | 100 | i[64500] |
| u*> | 10.2.0.0/16 | 192.0.2.1 | | 100 | i[64500] |
| u*> | 10.2.0.0/16 | 192.0.2.2 | | 100 | i[64500] |BGP add-paths for address family IPv4 with policy control
The following routing policy is enabled on RR-5 and applied as eligible for the IPv4 address family. This policy allows add-paths only for the matching prefixes. So, the number of advertised paths for the non-matching prefix 10.2.0.0/16 falls back to one:
# on RR-5:
enter candidate
routing-policy {
prefix-set ps-10.1.0.0 {
prefix 10.1.0.0/16 mask-length-range exact {
}
}
policy rp-add-paths-eligible-10.1 {
default-action {
policy-result reject
}
statement stmt-10 {
match {
prefix {
prefix-set ps-10.1.0.0
}
}
action {
policy-result accept
}
}
}
}
network-instance default {
protocols {
bgp {
afi-safi ipv4-unicast {
add-paths {
send true
eligible-prefix-policy rp-add-paths-eligible-10.1
}
}
}
}
}RR-5 sends the following withdrawal message to PE-3:
# on RR-5:
2026-06-17T21:38:45.285816+00:00 RR-5 sr_bgp_mgr: bgp|181370|181403|00026|TR||D: VR default (1) 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 10
Total Path Attr Length = 0PE-3 deletes the route with path ID 10 for prefix 10.2.0.0/16:
A:admin@PE-3# show / network-instance default protocols bgp routes ipv4 summary | grep -E '10.(1|2)'
| u*> | 10.1.0.0/16 | 192.0.2.1 | | 100 | i[64500] |
| u*> | 10.1.0.0/16 | 192.0.2.2 | | 100 | i[64500] |
| u*> | 10.2.0.0/16 | 192.0.2.1 | | 100 | i[64500] |BGP add-paths for address family VPN-IPv4 with policy control
Example topology - VPN-IPv4 shows the example topology used for the BGP add-paths policy control feature for VPN-IPv4 address family. The topology used is similar to the one used in the BGP Add-Paths chapter, with the following characteristics:
-
CE-4 in AS 64500 advertises both prefixes 172.31.1.0/24 and 172.31.2.0/24 in IP-VRF-1 to its eBGP peers PE-1 and PE-2 in AS 64496.
-
RR-5 is route reflector for all PEs in AS 64496.
-
add-paths is configured for the VPN-IPv4 address family 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.
IP-VRF-1 is configured on all PEs in AS 64496. The configuration of IP-VRF-1 is similar on all PEs; for example, for PE-1, the IP-VRF configuration is as follows:
# on PE-1:
enter candidate
network-instance IP-VRF-1 {
type ip-vrf
admin-state enable
protocols {
bgp-ipvpn {
bgp-instance 1 {
admin-state enable
mpls {
next-hop-resolution {
allowed-tunnel-types [
ldp
]
}
}
}
}
bgp {
admin-state enable
autonomous-system 64496
router-id 192.0.2.1
afi-safi ipv4-unicast {
admin-state enable
}
group grp-EBGP-1 {
peer-as 64500
import-policy [
rp-import-1:0
]
}
neighbor 172.16.114.2 {
peer-group grp-EBGP-1
}
}
bgp-vpn {
bgp-instance 1 {
route-distinguisher {
rd 64496:1
}
route-target {
export-rt target:64496:1
import-rt target:64496:1
}
}
}
}
interface int-PE-1-CE-4-in-IP-VRF-1 {
interface-ref {
interface ethernet-1/4
subinterface 2
}
}
}
interface ethernet-1/4 {
admin-state enable
vlan-tagging true
ethernet {
port-speed 100G
}
subinterface 2 {
type routed
description int-PE-1-CE-4-in-IP-VRF-1
admin-state enable
ipv4 {
admin-state enable
address 172.16.114.1/30 {
}
}
vlan {
encap {
single-tagged {
vlan-id 1
}
}
}
}
}On the CEs, the configuration is either in the base routing instance, with additional router interfaces and BGP neighbors, or in an IP-VRF. In this example, IP-VRF-1 is configured on CE-4 and exports prefixes 172.31.1.0/24 and 172.31.1.0/24 to its eBGP peers, as follows:
# on CE-4:
enter candidate
network-instance IP-VRF-1 {
type ip-vrf
admin-state enable
protocols {
bgp {
admin-state enable
autonomous-system 64500
router-id 172.20.2.4
afi-safi ipv4-unicast {
admin-state enable
}
group grp-EBGP-1 {
peer-as 64496
export-policy [
rp-export-ip-vrf-1
]
}
neighbor 172.16.114.1 {
peer-group grp-EBGP-1
}
neighbor 172.16.124.1 {
peer-group grp-EBGP-1
}
}
}
interface loopback1-in-IP-VRF-1 {
interface-ref {
interface lo1
subinterface 1
}
}
interface loopback2-in-IP-VRF-1 {
interface-ref {
interface lo1
subinterface 2
}
}
}
interface lo1 {
admin-state enable
subinterface 1 {
description loopback1-in-IP-VRF-1
admin-state enable
ipv4 {
admin-state enable
address 172.31.1.1/24 {
}
}
}
subinterface 2 {
description loopback2-in-IP-VRF-1
admin-state enable
ipv4 {
admin-state enable
address 172.31.2.1/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:
enter candidate
routing-policy {
prefix-set ps-172.31.1.0 {
prefix 172.31.1.0/24 mask-length-range exact {
}
}
prefix-set ps-172.31.2.0 {
prefix 172.31.2.0/24 mask-length-range exact {
}
}
policy rp-export-ip-vrf-1 {
statement stmt-10 {
match {
prefix {
prefix-set ps-172.31.1.0
}
}
action {
policy-result accept
bgp {
standard-community {
operation add
method reference
referenced-sets [
scs-1:0
]
}
origin {
set igp
}
}
}
}
statement stmt-20 {
match {
prefix {
prefix-set ps-172.31.2.0
}
}
action {
policy-result accept
bgp {
standard-community {
operation add
method reference
referenced-sets [
scs-1:0
]
}
origin {
set igp
}
}
}
}
}The configuration on CE-6 is similar.
BGP add-paths cannot be enabled in the bgp context within an IP-VRF. However, it can be enabled in the default network instance for address family VPN-IPv4. So, for all BGP speakers in AS 64496, BGP must be configured for address family VPN-IPv4 as well as for 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:
enter candidate
network-instance default {
protocols {
bgp {
group grp-IBGP {
---snip---
afi-safi ipv4-unicast {
admin-state enable
---snip---
}
afi-safi l3vpn-ipv4-unicast {
admin-state enable
add-paths {
receive true
send true
send-max 2
}
}The BGP configuration on PE-1 is as follows:
# on PE-1:
enter candidate
network-instance default {
protocols {
bgp {
admin-state enable
autonomous-system 64496
router-id 192.0.2.1
afi-safi ipv4-unicast {
admin-state enable
}
trace-options {
flag update {
}
}
group grp-EBGP {
peer-as 64500
import-policy [
rp-import-1:0
]
}
group grp-IBGP {
next-hop-self true
peer-as 64496
afi-safi ipv4-unicast {
admin-state enable
add-paths {
receive true
send true
send-max 2
}
}
afi-safi l3vpn-ipv4-unicast {
admin-state enable
add-paths {
receive true
send true
send-max 2
}
}
}
neighbor 172.16.14.2 {
peer-group grp-EBGP
}
neighbor 192.0.2.5 {
peer-group grp-IBGP
}With add-paths 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 BGP 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 / network-instance default protocols bgp routes l3vpn-ipv4-unicast summary
---------------------------------------------------------------------------------------------------------------------------------------------------------
Show report for the BGP route table of network-instance "default"
---------------------------------------------------------------------------------------------------------------------------------------------------------
Status codes: u=used, *=valid, >=best, x=stale, b=backup, w=unused-weight-only
Origin codes: i=IGP, e=EGP, ?=incomplete
---------------------------------------------------------------------------------------------------------------------------------------------------------
+--------------------+--------------------+--------------------+--------------------+--------------------+--------------------+--------------------+
| Status | Route | Network | Next Hop | MED | LocPref | Path Val |
| | Distinguisher | | | | | |
+====================+====================+====================+====================+====================+====================+====================+
| ---snip--- |
| u*> | 64496:1 | 172.31.1.0/24 | 192.0.2.1 | | 100 | i[64500] |
| u*> | 64496:1 | 172.31.1.0/24 | 192.0.2.2 | | 100 | i[64500] |
| u*> | 64496:1 | 172.31.2.0/24 | 192.0.2.1 | | 100 | i[64500] |
| u*> | 64496:1 | 172.31.2.0/24 | 192.0.2.2 | | 100 | i[64500] |
+--------------------+--------------------+--------------------+--------------------+--------------------+--------------------+--------------------+
---------------------------------------------------------------------------------------------------------------------------------------------------------
7 received BGP routes: 7 used, 7 valid, 0 stale
7 available destinations: 0 with ECMP multipaths
---------------------------------------------------------------------------------------------------------------------------------------------------------All routes are used because of the ECMP setting in IP-VRF-1:
# on PE-3:
enter candidate
network-instance IP-VRF-1 {
type ip-vrf
admin-state enable
protocols {
bgp-ipvpn {
bgp-instance 1 {
admin-state enable
ecmp 2
}
}
}Alternatively, BGP FRR can be enabled for IP-VRF-1, as described in the BGP Add-Paths chapter.
To limit the advertisement of prefix 172.31.2.0/24 to a single path, the following routing policy is configured on RR-5:
# on RR-5:
enter candidate
routing-policies {
prefix-set ps-172.31.1.0 {
prefix 172.31.1.0/24 mask-length-range exact {
}
}
policy rp-add-paths-eligible-172.31.1.0 {
default-action {
policy-result reject
}
statement stmt-10 {
match {
prefix {
prefix-set ps-172.31.1.0
}
}
action {
policy-result accept
}
}
}The policy entry for prefix 172.31.1.0/24 can be configured in a new routing policy or be added to an existing routing policy (used for the previous IPv4 add-paths policy section, for example).
If this is a new routing policy, apply the policy in the bgp afi-safi l3vpn-ipv4-unicast context on RR-5:
# on RR-5:
enter candidate
network-instance default {
protocols {
bgp {
afi-safi l3vpn-ipv4-unicast {
add-paths {
send true
eligible-prefix-policy rp-add-paths-eligible-172.31.1.0Upon application of this configuration, RR-5 sends the following withdrawal to PE-3:
# on RR-5:
2026-06-17T17:18:31.499789+00:00 RR-5 sr_bgp_mgr: bgp|181370|181403|00021|TR||D: VR default (1) 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 15PE-3 now has a single route for prefix 172.31.2.0/24 in its BGP routing table:
A:admin@PE-3# show / network-instance default protocols bgp routes l3vpn-ipv4-unicast summary | grep '172.31.'
| u*> | 64496:1 | 172.31.1.0/24 | 192.0.2.1 | | 100 | i[64500] |
| u*> | 64496:1 | 172.31.1.0/24 | 192.0.2.2 | | 100 | i[64500] |
| u*> | 64496:1 | 172.31.2.0/24 | 192.0.2.1 | | 100 | i[64500] |IP-VRF-1 on PE-3 has installed a single route for prefix 172.31.2.0/24 in its route table:
A:admin@PE-3# show / network-instance IP-VRF-1 ipv4 route all
=========================================================================================================================================================
IPv4-unicast route table for ip-vrf network-instance: IP-VRF-1
---------------------------------------------------------------------------------------------------------------------------------------------------------
Flags: > (best), * (unviable), ! (failed)
: L (leaked route from another network-instance)
: B (backup NHG active and displayed)
: S (statistics supported)
: D (dynamic LB), R (resilient LB)
---------------------------------------------------------------------------------------------------------------------------------------------------------
Prefix Route Type Metric Pref Flags Next-Hop(s)
---------------------------------------------------------------------------------------------------------------------------------------------------------
---snip---
172.31.1.0/24 bgp-ipvpn 10 170 > 192.0.2.1(tunnel:ldp, label:30000)
192.0.2.2(tunnel:ldp, label:30000)
172.31.2.0/24 bgp-ipvpn 10 170 > 192.0.2.1(tunnel:ldp, label:30000)Conclusion
The BGP add-paths policy control feature allows BGP speakers to advertise multiple distinct paths for the same prefix. The potential benefits of using BGP add-paths policy control are increased granularity and flexibility in advertising multiple paths to BGP neighbors.