BGP Add-Paths
This chapter provides information about BGP Add-Path.
Topics in this chapter include:
Applicability
The CLI in the latest update of this chapter is based on SR Linux Release 26.3.3.
Overview
When a BGP router learns multiple paths for the same prefix, it selects one route as its best path and advertises only this route to its BGP peers. The BGP add-paths feature allows advertising the best n paths for the same prefix, where n is configurable. If the set of n paths includes multiple paths with the same BGP next hop, only the best route with a specific next hop is advertised and the other paths are suppressed.
The BGP add-paths feature increases path visibility in the Autonomous System (AS), because more routes are stored in the Routing Information Base (RIB). BGP add-paths has the following benefits:
Faster convergence after failure
Enhanced load-sharing
Reduced routing churn
These benefits are described in the following sections.
Faster convergence after failure
RR advertises best path only – path A preferred over path B shows a network that does not support BGP add-paths. CE-4 advertises two paths for prefix 10.0.4.0/24 to its EBGP neighbors: PE-1 and PE-2. PE-1 has an import policy that sets the local preference (LP) of path A to 200; PE-2 keeps the default LP of 100 for path B. Therefore, path A that is advertised to PE-1 is preferred in AS 64496. The route reflector RR-5 advertises the preferred path A to PE-2 and PE-3. PE-2 suppresses the advertisement of its external path (B) to RR-5, because path A is preferred. Traffic from CE-6 to CE-4 is sent via PE-3 and PE-1.
When the link between CE-4 and PE-1 fails, the following steps take place for reconvergence:
PE-1 sends a BGP update withdrawing path A to RR-5.
RR-5 receives and propagates the withdrawal to its other clients: PE-2 and PE-3.
PE-2 receives the withdrawal of path A and reruns the BGP decision process. PE-2 selects path B as its best route and advertises path B to RR-5.
RR-5 receives the BGP update for path B and reruns its BGP decision process. RR-5 selects path B as its best path and advertises path B to its other clients: PE-1 and PE-3.
PE-1 and PE-3 rerun their BGP decision process and determine that path B is the best path. Traffic can flow from CE-6 to CE-4 via PE-3 and PE-2.
Reconvergence after path failure (without add-paths) shows the BGP updates sent to withdraw path A and advertise path B.
If the propagation time of a BGP update message between RR-5 and any of its clients is X, the convergence time is four times X, plus processing, transmission, and queuing delays.
With the use of add-paths on all BGP routers in AS 64496, the convergence time can be reduced considerably, because PE-3 has more than one path for prefix 10.0.4.0/24 in its RIB-IN before the failure takes place. When there are no failures, PE-2 decides that path A is best, and PE-2 also advertises its second-best path (B)—which is its best external path—to RR-5. With add-paths enabled, the RR has knowledge of two paths for prefix 10.0.4.0/24 and advertises both to its clients. PE-3 receives two routes for prefix 10.0.4.0/24, reruns the BGP decision process, and updates its forwarding table based on the results. The following options are possible:
Path A is the best path, whereas path B is maintained in the RIB-IN. The FIB entry for destination 10.0.4.0/24 points at path {A} only.
When BGP FRR is enabled as described in chapter BGP Fast Reroute, path A is the best path and path B is the second-best path. The FIB entry for destination 10.0.4.0/24 points to path {A,B}. If path A is available, it is used for all traffic to the destination; if path A is unavailable but path B is available, then all traffic to the destination is directed to path B. In this case, path B is effectively a pre-computed, pre-installed backup path for the destination.
When Equal Cost Multi-Path (ECMP) and BGP multipath are enabled and the paths have an equal cost, both paths A and B represent the best path. The FIB entry for destination 10.0.4.0/24 points to multipath entry {A,B}. When both paths are available, traffic to the destination is load-shared across paths A and B. If only one path is available, traffic is directed to that available path.
Advertised paths when BGP add-paths is enabled in PEs and RR shows the BGP update messages when there are no failures. RR-5 receives path A from PE-1 and path B from PE-2, whereas it advertises path B to PE-1, path A to PE-2, and both path A and path B to PE-3. Path B has the default LP 100, whereas path A gets LP 200 as per import policy on PE-1. However, in case of ECMP, both paths keep the default LP 100.
Reconvergence after path failure when BGP add-paths is enabled shows the BGP update messages that are sent after a link failure between CE-4 and PE-1. With add-paths, fewer steps are required for convergence:
PE-1 sends a BGP update message withdrawing path A.
RR-5 receives the withdrawal and propagates it to its clients PE-2 and PE-3.
PE-2 and PE-3 receive the withdrawal, rerun the BGP decision process, and update the forwarding entry for destination 10.0.4.0/24: path B is best.
The convergence time with add-paths is much shorter than without add-paths. If X is the propagation time of a BGP update message between RR and any of the PEs, then the convergence time is the time required for the BGP update from PE-1 to RR-5 (X) plus the time required for the BGP update propagation from RR-5 to the other PEs (X), in addition to delays for processing, transmission, and queuing. The convergence with add-paths is twice as fast as without add-paths.
For some types of failures, the convergence can be even faster:
When PE-1 becomes unreachable, the next-hop tracking by PE-3 invalidates path A before the BGP withdrawal message is received from RR-5.
If PE-3 implements BGP FRR and path A has been marked as unusable, PE-3 can switch traffic destined for 10.0.4.0/24 to path B.
When Bidirectional Forwarding Detection (BFD) is enabled on the EBGP sessions and on the IGP protocol, the failure is detected faster and BGP convergence can be sped up when BGP FRR is enabled.
Enhanced load-sharing
When paths A and B are equal in cost or preference, and ECMP and BGP multipath are enabled on all PEs, load-sharing can be done for traffic with destination 10.0.4.0/24. With BGP add-paths, both paths A and B are advertised to the PEs. PE-3 runs the BGP decision process and determines that paths A and B are both best paths to destination 10.0.4.0/24, so paths A and B are combined into one multipath forwarding entry: {A,B}.
The benefits of load-sharing for traffic to destination 10.0.4.0/24 are the following:
More even bandwidth utilization of the links in AS 64496
More even bandwidth utilization for traffic across peering points PE-1 and PE-2 with AS 64500
Faster reaction to some failures; for example, the BGP next hop for one of the paths becomes unreachable in the IGP and next hop tracking is enabled.
Reduced routing churn
Routing churn refers to repeated advertisements and withdrawals of a prefix and path. Some degree of routing churn is normal and expected in most networks. However, it should be contained as much as possible to avoid overloading router CPUs. Routing churn can be caused by:
Flapping links (links that repeatedly transition between up and down state)
Route oscillation (networks that use RRs or AS confederations and BGP path selection relies on Multi Exit Discriminator (MED) and IGP cost comparisons)
Add-paths helps to reduce routing churn by constraining the effect of some failures to the local AS where they occur. For example, the link between CE-4 and PE-1 could repeatedly cycle up and down because of a misconfiguration. When the link goes down, a BGP withdrawal message is sent by PE-1 to RR-5 and from RR-5 to the other RR clients (PE-2 and PE-3). PE-3 withdraws and advertises path A to its EBGP peer CE-6 in AS 64501, but path B is constantly advertised to CE-6 (when add-paths has been negotiated between PE-3 and CE-6).
Without add-paths, PE-2 would be affected by the instability in AS 64496 and there would be periods of time when AS 64501 has no paths to destination 10.0.4.0/24 (between the withdrawal of path A and the advertisement of path B).
Add-paths implementation
BGP add-paths is configured in the default routing instance, for IBGP or EBGP, per address family at different levels: in the global bgp context, per group, and per neighbor. BGP add path is configured per address family.
Up to 16 paths are configurable per address family per peer (send-limit):
--{ +* candidate shared default }--[ network-instance default protocols bgp group grp-IBGP afi-safi ipv4-unicast add-paths ]--
A:admin@PE-1# send-max ?
usage: send-max <1..16>
Send the N best paths for a single NLRI, or as many as possible until there are no more valid paths to send.
This ensures the best path is advertised but does not limit the additional paths to being 'used' paths.
Positional arguments:
value [number, range 1..16]
Only the number of advertised routes per prefix is controlled, not the number of received routes. All routes advertised by an add-paths peer are accepted; otherwise, routing loops may occur. If a BGP speaker is configured with <send-limit> n, but has more than n paths available in the LOC-RIB, it selects the n best paths with unique BGP next hops following the Add-n path selection algorithm described in draft-ietf-idr-add-paths-guidelines.
When BGP add-paths is configured for an address family, the BGP capability is announced to the BGP peer as part of the BGP open message, as follows:
# Enable debugging for BGP open messages on PE-1:
enter candidate
network-instance default {
protocols {
bgp {
trace-options {
flag open {
}
}
2026-06-17T11:39:14.371457+00:00 PE-1 sr_bgp_mgr: bgp|388029|388061|00096|TR||D: VR default (1) BGP OPEN: Peer 1: 172.16.14.2 - Send (Active) BGP OPEN: Version 4
AS Num 64496: Holdtime 90: BGP_ID 192.0.2.1: Opt Length 26 (ExtOpt F)
Opt Para: Type CAPABILITY: Length = 24: Data:
Cap_Code GRACEFUL-RESTART: Length 2
Bytes: 0x1 0x2c
Cap_Code MP-BGP: Length 4
Bytes: 0x0 0x1 0x0 0x1
Cap_Code ROUTE-REFRESH: Length 0
Cap_Code 4-OCTET-ASN: Length 4
Bytes: 0x0 0x0 0xfb 0xf0
Cap_Code ADD-PATH: Length 4
Bytes: 0x0 0x1 0x1 0x3
The BGP add-paths capability code value typically consists of one or more blocks of four bytes; two octets for the Address Family Identifier (AFI), one octet for the Subsequent Address Family Identifier (SAFI), and one octet for send/receive. In this example, AFI/SAFI bytes point to an IPv4 address family and send/receive value 3 means that the sender is able to receive and send multiple paths from/to its BGP peer.
In BGP update messages, a 4-octet path identifier (ID) is added to the Network Layer Reachability Information (NLRI) field. The combination of both prefix and path ID identifies a BGP path. SR OS allocates path IDs sequentially on a per address family basis, not per prefix. The path ID is only locally significant, which means that when a BGP speaker re-advertises a route with path IDs, it must generate its own path ID.
# Enable debugging for BGP UPDATE messages on RR-5:
enter candidate
network-instance default {
protocols {
bgp {
trace-options {
flag update {
}
}RR-5 received the following BGP update for prefix 10.0.4.0/24 with path ID.
2026-06-17T11:39:19.072811+00:00 RR-5 sr_bgp_mgr: bgp|384120|384153|00102|TR||D: VR default (1) Peer 1: 192.0.2.2 UPDATE: Peer 1: 192.0.2.2 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 34
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:
4:0
NLRI: Length = 8
10.0.4.0/24 Path-ID 2
--When routers have negotiated to advertise (and receive) routes with path identifiers, all BGP updates (advertisements or withdrawals) without path identifier are rejected. This results in an NLRI parsing error—because the BGP update has an incorrect length—and a notification is sent.
Configuration
The following configuration examples are in this section:
BGP without add-paths
BGP with add-paths for address family IPv4: no BGP FRR, no ECMP
BGP with add-paths for address family IPv4 and BGP FRR enabled
BGP with add-paths for address family IPv4 and ECMP enabled
BGP with add-paths for address family VPN-IPv4 and BGP FRR enabled
BGP with add-paths for address family VPN-IPv4 and ECMP enabled
Example topology shows the example topology with CE-4 in AS 64500 advertising route 10.0.4.0/24 to its EBGP peers PE-1 and PE-2 in AS 64496. PE-1 has an import policy that sets the LP for this route to 200, whereas PE-2 keeps the default local preference of 100. RR-5 is RR 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 AS 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
BGP is configured on all the nodes. CE-4 peers with PE-1 and PE-2 and exports prefix 10.0.4.0/24 to both EBGP peers, as follows:
# on CE-4:
enter candidate
routing-policy {
prefix-set ps-10.0.4.0 {
prefix 10.0.4.0/24 mask-length-range exact {
}
}
standard-community-set scs-4:0 {
member [
4:0
]
}
standard-community-set scs-6:0 {
member [
6:0
]
}
policy rp-comm-6:0 {
default-action {
policy-result reject
}
statement stmt-10 {
match {
bgp {
standard-community {
standard-community-set scs-6:0
}
}
}
action {
policy-result accept
}
}
}
policy rp-export-10.0.4.0 {
statement stmt-10 {
match {
prefix {
prefix-set ps-10.0.4.0
}
}
action {
policy-result accept
bgp {
standard-community {
operation add
method reference
referenced-sets [
scs-4:0
]
}
origin {
set igp
}
}
}
}
}
}
network-instance default {
protocols {
bgp {
admin-state enable
router-id 192.0.2.4
autonomous-system 64500
afi-safi ipv4-unicast {
admin-state enable
}
group grp-EBGP {
peer-as 64496
export-policy [
rp-export-10.0.4.0
]
import-policy [
rp-comm-6:0
]
}
neighbor 172.16.14.1 {
peer-group grp-EBGP
}
neighbor 172.16.24.1 {
peer-group grp-EBGP
}
}
The BGP configuration on CE-6 is similar.
PE-1 peers with CE-4 in AS 64500 and RR-5 in AS 64496. An import policy is configured to set the LP to 200 for all routes received from CE-4 with community 4:0, as follows:
# on PE-1:
enter candidate
routing-policy {
standard-community-set scs-4:0 {
member [
4:0
]
}
standard-community-set scs-6:0 {
member [
6:0
]
}
policy rp-import-LP200 {
default-action {
policy-result reject
}
statement stmt-10 {
match {
bgp {
standard-community {
standard-community-set scs-4:0
}
}
}
action {
policy-result accept
bgp {
local-preference {
value 200
operation set
}
}
}
}
}
policy rp-comm-6:0 {
default-action {
policy-result reject
}
statement stmt-10 {
match {
bgp {
standard-community {
standard-community-set scs-6:0
}
}
}
action {
policy-result accept
}
}
}
}
network-instance default {
protocols {
bgp {
admin-state enable
autonomous-system 64496
router-id 192.0.2.1
afi-safi ipv4-unicast {
admin-state enable
}
group grp-EBGP {
peer-as 64500
export-policy [
rp-comm-6:0
]
import-policy [
rp-import-LP200
]
}
group grp-IBGP {
next-hop-self true
peer-as 64496
}
neighbor 172.16.14.2 {
peer-group grp-EBGP
}
neighbor 192.0.2.5 {
peer-group grp-IBGP
}
}
The BGP configuration on PE-2 and PE-3 is similar, but the import policy does not configure the local preference, so the default local preference of 100 applies.
The BGP configuration on RR-5 is as follows:
# on RR-5:
enter candidate
network-instance default {
protocols {
bgp {
admin-state enable
router-id 192.0.2.5
autonomous-system 64496
afi-safi ipv4-unicast {
admin-state enable
}
route-reflector {
client true
cluster-id 192.0.2.5
}
group grp-IBGP {
peer-as 64496
}
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
}
}PE-1 advertises a route for prefix 10.0.4.0/24 with LP 200 to RR-5. RR-5 propagates this route to its other clients: PE-2 and PE-3. When PE-2 learns this route, it does not advertise its own route for 10.0.4.0/24 with LP 100 to RR-5 anymore. PE-3 only learns the route for prefix 10.0.4.0/24 with LP 200, as follows:
--{ + running }--[ ]--
A:admin@PE-3# show / network-instance default protocols bgp routes ipv4 prefix 10.0.4.0/24
-------------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.0.4.0/24" network-instance "default"
-------------------------------------------------------------------------------------------
Network: 10.0.4.0/24
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference: MED is -, LocalPref is 200
BGP next-hop : 192.0.2.1
Path : i [64500]
Communities : 4:0
Path 1 was advertised to:
[ 172.16.36.2 ]
-------------------------------------------------------------------------------------------
Reconvergence without add-paths
A failure of the link between CE-4 and PE-1 is simulated as follows:
# on CE-4:
enter candidate
interface ethernet-1/1 {
subinterface 1 {
admin-state disable
The following four BGP update messages are received or sent by RR-5.
RR-5 receives the following withdrawal message from PE-1:
# on RR-5:
2026-06-17T11:26:19.101796+00:00 RR-5 sr_bgp_mgr: bgp|384120|384153|00059|TR||D: VR default (1) Peer 1: 192.0.2.1 UPDATE: Peer 1: 192.0.2.1 - Received BGP UPDATE:
Withdrawn Length = 4
10.0.4.0/24
Total Path Attr Length = 0
RR-5 propagates this withdrawal to its other clients, for example to PE-2, as follows:
# on RR-5:
2026-06-17T11:26:22.643609+00:00 RR-5 sr_bgp_mgr: bgp|384120|384154|00004|TR||D: VR default (1) Peer 1: 192.0.2.2 UPDATE: Peer 1: 192.0.2.2 - Send BGP UPDATE:
Withdrawn Length = 4
10.0.4.0/24
Total Path Attr Length = 0
When PE-2 receives this withdrawal, it reruns the BGP decision process and decides that its route for prefix 10.0.4.0/24 with LP 100 is the best route. PE-2 advertises this route to RR-5; it is received by RR-5 as follows:
# on RR-5:
2026-06-17T11:26:23.364813+00:00 RR-5 sr_bgp_mgr: bgp|384120|384153|00060|TR||D: VR default (1) Peer 1: 192.0.2.2 UPDATE: Peer 1: 192.0.2.2 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 34
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:
4:0
NLRI: Length = 4
10.0.4.0/24
RR-5 propagates this message to its other clients: PE-1 and PE-3. The following BGP update is sent to PE-3:
# on RR-5:
2026-06-17T11:26:26.646051+00:00 RR-5 sr_bgp_mgr: bgp|384120|384154|00006|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:
4: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 = 4
10.0.4.0/24
Again, PE-3 has only one route for prefix 10.0.4.0/24, but this time with next hop 192.0.2.2, as follows:
--{ + running }--[ ]--
A:admin@PE-3# show / network-instance default protocols bgp routes ipv4 prefix 10.0.4.0/24
------------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.0.4.0/24" network-instance "default"
------------------------------------------------------------------------------------------
Network: 10.0.4.0/24
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.2
Path : i [64500]
Communities : 4:0
Path 1 was advertised to:
[ 172.16.36.2 ]
------------------------------------------------------------------------------------------
The configuration is restored as follows:
# on CE-4:
enter candidate
interface ethernet-1/1 {
subinterface 1 {
admin-state enable
Add-paths enabled: no BGP FRR, no ECMP
Before add-paths is enabled, the following information is displayed on PE-1 for BGP neighbor RR-5:
--{ + running }--[ ]--
A:admin@PE-1# info from state network-instance default protocols bgp neighbor 192.0.2.5 afi-safi ipv4-unicast add-paths
receive false
send false
Add-paths is enabled on PE-1 and PE-2 with a send path limit of two for groups grp-EBGP and grp-IBGP and no limit on the receive path, as follows:
# on PE-1 and PE-2:
enter candidate
network-instance default {
protocols {
bgp {
group grp-EBGP {
afi-safi ipv4-unicast {
add-paths {
receive true
send true
send-max 2
}
}
}
group grp-IBGP {
afi-safi ipv4-unicast {
add-paths {
receive true
send true
send-max 2
}
}
}
When the preceding info from state command is repeated on PE-1 or PE-2, the local BGP add-paths capabilities are specified for address family IPv4: a maximum of two paths can be sent for a specific IPv4 prefix.
--{ + running }--[ ]--
A:admin@PE-1# info from state network-instance default protocols bgp group grp-EBGP afi-safi ipv4-unicast add-paths
receive true
send true
send-max 2
--{ + running }--[ ]--
A:admin@PE-1# info from state network-instance default protocols bgp group grp-IBGP afi-safi ipv4-unicast add-paths
receive true
send true
send-max 2
The remote peer RR-5 does not have add-paths enabled yet, so PE-1 did not receive the add-paths capability from RR-5:
--{ + running }--[ ]--
A:admin@PE-1# info from state network-instance default protocols bgp neighbor 192.0.2.5 received-capabilities
received-capabilities [
ROUTE_REFRESH
4-OCTET_ASN
MP_BGP
GRACEFUL_RESTART
] ## ADD_PATH capability is not included in the list
Initially, add-paths remains disabled on PE-3. On the RR, add-paths is enabled for neighbors 192.0.2.1 and 192.0.2.2, but not for 192.0.2.3 yet. For neighbor 192.0.2.1, the receive false option implies that the add-paths receive capability is not negotiated.
# on RR-5:
enter candidate
network-instance default {
protocols {
bgp {
neighbor 192.0.2.1 {
afi-safi ipv4-unicast {
add-paths {
receive false # add-path receive capability not negotiated
send true
send-max 2
}
}
}
neighbor 192.0.2.2 {
afi-safi ipv4-unicast {
add-paths {
receive true # add-path receive capability negotiated
send true
send-max 2
}
}
}The following output shows that add-paths is enabled locally on RR-5 for address family IPv4. RR-5 can send a maximum of two paths for a specific prefix toward PE-1 and PE-2; toward PE-3, add-paths remains disabled.
--{ + running }--[ ]--
A:admin@RR-5# info from state network-instance default protocols bgp neighbor 192.0.2.1 afi-safi ipv4-unicast add-paths
receive false
send true
send-max 2
--{ + running }--[ ]--
A:admin@RR-5# info from state network-instance default protocols bgp neighbor 192.0.2.2 afi-safi ipv4-unicast add-paths
receive true
send true
send-max 2
--{ + running }--[ ]--
A:admin@RR-5# info from state network-instance default protocols bgp neighbor 192.0.2.3 afi-safi ipv4-unicast add-paths
receive false
send false
The receive false option indicates that RR-5 does not negotiate the add-paths receive capability with its peer, so RR-5 is not willing to receive multiple paths from PE-1 for IPv4 unicast. PE-1 knows that peer 192.0.2.5 may send IPv4 routes with a path ID because the add-paths capability is negotiated, but PE-1 has no information about what RR-5 receives. The following shows that PE-1 received the add-paths capability from RR-5:
--{ + running }--[ ]--
A:admin@PE-1# info from state network-instance default protocols bgp neighbor 192.0.2.5 received-capabilities
received-capabilities [
ROUTE_REFRESH
4-OCTET_ASN
MP_BGP
GRACEFUL_RESTART
ADD_PATH
]
With BGP add-paths enabled, PE-2 advertises its second-best route for prefix 10.0.4.0/24 with LP 100 to RR-5. RR-5 has two valid routes for prefix 10.0.4.0/24 in its RIB-IN, but only the route with LP 200 is best and used, as follows:
--{ + running }--[ ]--
A:admin@RR-5# show / network-instance default protocols bgp routes ipv4 prefix 10.0.4.0/24
------------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.0.4.0/24" network-instance "default"
------------------------------------------------------------------------------------------
Network: 10.0.4.0/24
Received Paths: 2
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.1
Route Preference: MED is -, LocalPref is 200
BGP next-hop : 192.0.2.1
Path : i [64500]
Communities : 4:0
Path 2: <Valid,>
Route source : neighbor 192.0.2.2
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.2
Path : i [64500]
Communities : 4:0
Path 1 was advertised to:
[ 192.0.2.1, 192.0.2.2, 192.0.2.3 ]
------------------------------------------------------------------------------------------
Even though RR-5 has two routes for this prefix, it only advertises its best route to PE-3, because add-paths is not enabled for this BGP session. Therefore, PE-3 only has the route for 10.0.4.0/24 with LP 200, as follows:
--{ + running }--[ ]--
A:admin@PE-3# show / network-instance default protocols bgp routes ipv4 prefix 10.0.4.0/24
------------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.0.4.0/24" network-instance "default"
------------------------------------------------------------------------------------------
Network: 10.0.4.0/24
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference: MED is -, LocalPref is 200
BGP next-hop : 192.0.2.1
Path : i [64500]
Communities : 4:0
Path 1 was advertised to:
[ 172.16.36.2 ]
------------------------------------------------------------------------------------------
When add-paths is enabled on the session between PE-3 and RR-5, the second route is advertised, as follows:
# on PE-3:
enter candidate
network-instance default {
protocols {
bgp {
group grp-IBGP {
afi-safi ipv4-unicast {
add-paths {
receive true
send true
send-max 2
}
}
}
# on RR-5:
enter candidate
network-instance default {
protocols {
bgp {
neighbor 192.0.2.3 {
afi-safi ipv4-unicast {
add-paths {
receive true
send true
send-max 2
}
}
}
--{ + running }--[ ]--
A:admin@PE-3# show / network-instance default protocols bgp routes ipv4 prefix 10.0.4.0/24
-------------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.0.4.0/24" network-instance "default"
-------------------------------------------------------------------------------------------
Network: 10.0.4.0/24
Received Paths: 2
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference: MED is -, LocalPref is 200
BGP next-hop : 192.0.2.1
Path : i [64500]
Communities : 4:0
Path 2: <Valid,>
Route source : neighbor 192.0.2.5
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.2
Path : i [64500]
Communities : 4:0
Path 1 was advertised to:
[ 172.16.36.2 ]
-------------------------------------------------------------------------------------------
BGP add-paths is enabled, but BGP FRR or ECMP are disabled. The routing table on PE-3 only contains one entry for prefix 10.0.4.0/24:
--{ + running }--[ ]--
A:admin@PE-3# show / network-instance default ipv4 route 10.0.4.0/24
===========================================================================================
IPv4-unicast route table for default network-instance
-------------------------------------------------------------------------------------------
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)
-------------------------------------------------------------------------------------------
10.0.4.0/24 bgp 10 170 > 192.0.2.1(route:isis)
Reconverge with add-paths: no BGP FRR, no ECMP
A link failure between CE-4 and PE-1 is simulated as follows:
# on CE-4:
enter candidate
interface ethernet-1/1 {
subinterface 1 {
admin-state disable
PE-1 sends a withdrawal message for route 10.0.4.0/24 with LP 200 to RR-5 and reruns the BGP decision process. RR-5 propagates this withdrawal message to its other clients that rerun the BGP decision process. As a result, the route for prefix 10.0.4.0/24 with LP 100 is used on all nodes; for example, on PE-3:
--{ + running }--[ ]--
A:admin@PE-3# show / network-instance default protocols bgp routes ipv4 prefix 10.0.4.0/24
--------------------------------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.0.4.0/24" network-instance "default"
--------------------------------------------------------------------------------------------------------------
Network: 10.0.4.0/24
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.2
Path : i [64500]
Communities : 4:0
Path 1 was advertised to:
[ 172.16.36.2 ]
--------------------------------------------------------------------------------------------------------------
The routing table contains a route to 10.0.4.0/24 with PE-2 as next hop, as follows:
--{ + running }--[ ]--
A:admin@PE-3# show / network-instance default ipv4 route 10.0.4.0/24
==============================================================================================================
IPv4-unicast route table for default network-instance
--------------------------------------------------------------------------------------------------------------
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)
--------------------------------------------------------------------------------------------------------------
10.0.4.0/24 bgp 10 170 > 192.0.2.2(route:isis)
The convergence with add-paths enabled is twice as fast as without BGP add-paths. With BGP add-paths disabled, four sequential messages are sent:
PE-1 sends a withdrawal to RR-5.
RR-5 propagates withdrawal.
PE-2 advertises its route.
RR-5 propagates the route.
In the scenario with add-paths, the last two messages are already sent before the failure happened. During convergence, only two withdrawal messages are sent: PE-1 sends a withdrawal to RR-5; RR-5 propagates this to its clients.
Add-path and BGP FRR
The convergence time can be further reduced by enabling BGP FRR, where the BGP decision process runs for the best route and the backup path before any failure happens, as described in chapter BGP Fast Reroute. On all PEs, BGP FRR is enabled for the IPv4 address family, as follows:
# on all PEs:
enter candidate
network-instance default {
protocols {
bgp {
afi-safi ipv4-unicast {
ipv4-unicast {
backup-paths {
install true
}
}Each PE has two valid routes for prefix 10.0.4.0/24 and when BGP FRR is enabled, both are used, but one is used as backup, indicated by the Backup-flag in the following output:
--{ + running }--[ ]--
A:admin@PE-3# show / network-instance default protocols bgp routes ipv4 prefix 10.0.4.0/24
-------------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.0.4.0/24" network-instance "default"
-------------------------------------------------------------------------------------------
Network: 10.0.4.0/24
Received Paths: 2
Path 1: <Valid,Used,Backup,>
Route source : neighbor 192.0.2.5
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.2
Path : i [64500]
Communities : None
Path 2: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference: MED is -, LocalPref is 200
BGP next-hop : 192.0.2.1
Path : i [64500]
Communities : None
Path 2 was advertised to:
[ 172.16.36.2 ]
-------------------------------------------------------------------------------------------The following routing table on PE-3 shows both the active and the backup route for prefix 10.0.4.0/24:
--{ + running }--[ ]--
A:admin@PE-3# show / network-instance default ipv4 route 10.0.4.0/24
==============================================================================================================
IPv4-unicast route table for default network-instance
--------------------------------------------------------------------------------------------------------------
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)
--------------------------------------------------------------------------------------------------------------
10.0.4.0/24 bgp 10 170 > 192.0.2.1(route:isis)
backup:192.0.2.2(route:isis)
In case of link failure between CE-4 and PE-1, the same BGP withdrawals are sent from PE-1 to RR-5 and from RR-5 to PE-2 and PE-3. When PE-2 and PE-3 receive the withdrawal, the BGP decision process need not run again. The backup path is promoted to active immediately.
Add-paths and ECMP
On PE-1, the import policy is replaced by a policy that does not modify the local preference value of 100 (default), as follows. The paths via PE-1 and PE-2 have an equal cost.
# on PE-1:
enter candidate
routing-policy {
policy rp-comm-4:0 {
default-action {
policy-result reject
}
statement stmt-10 {
match {
bgp {
standard-community {
standard-community-set scs-4:0
}
}
}
action {
policy-result accept # the local preference is not changed
}
}
}
info
commit stay
}
network-instance default {
protocols {
bgp {
group grp-EBGP {
import-policy [
rp-comm-4:0
]
ECMP is enabled in IS-IS instance 0 on all PEs with a value of two, as follows:
# on all PEs:
enter candidate
network-instance default {
protocols {
isis {
instance 0 {
max-ecmp-paths 2
On all PEs, BGP multipath is configured with the maximum number of paths equal to two for AFI-SAFI ipv4-unicast, as follows:
# on all PEs:
enter candidate
network-instance default {
protocols {
bgp {
afi-safi ipv4-unicast {
multipath {
ebgp {
maximum-paths 2
}
ibgp {
maximum-paths 2
}
}
All PEs have two routes for prefix 10.0.4.0/24 and both are active when ECMP is enabled; for example, for PE-3, as follows:
--{ + running }--[ ]--
A:admin@PE-3# show / network-instance default protocols bgp routes ipv4 prefix 10.0.4.0/24
-------------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.0.4.0/24" network-instance "default"
-------------------------------------------------------------------------------------------
Network: 10.0.4.0/24
Received Paths: 2
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.2
Path : i [64500]
Communities : None
Path 2: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.1
Path : i [64500]
Communities : None
Path 2 was advertised to:
[ 172.16.36.2 ]
---------------------------------------------------------------------------------------------{ + running }--[ ]--
A:admin@PE-3# show / network-instance default ipv4 route 10.0.4.0/24
===========================================================================================
IPv4-unicast route table for default network-instance
-------------------------------------------------------------------------------------------
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)
-------------------------------------------------------------------------------------------
10.0.4.0/24 bgp 10 170 > 192.0.2.1(route:isis)
192.0.2.2(route:isis)
Traffic flows with destination 10.0.4.0/24 are sprayed over the two active paths.
Add-path for family VPN-IPv4 with BGP FRR
Example topology with IP-VRFs shows the example topology with IP-VRF-1 configured on the PEs in AS 64496. CE-4 exports prefix 172.31.0.0/16 to IP-VRF-1 on PE-1 and PE-2.
IP-VRF-1 is configured on all PEs in AS 64496, but not on the RR. BGP FRR is enabled in the IP-VRF. 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
system {
mpls {
label-ranges {
dynamic dlb-services {
start-label 30000
end-label 39999
}
}
services {
network-instance {
dynamic-label-block dlb-services
}
}
}
}
routing-policy {
standard-community-set scs-4:1 {
member [
4:1
]
}
standard-community-set scs-6:1 {
member [
6:1
]
}
policy rp-import-4:1-LP200 {
default-action {
policy-result reject
}
statement stmt-10 {
match {
bgp {
standard-community {
standard-community-set scs-4:1
}
}
}
action {
policy-result accept
bgp {
local-preference {
value 200
operation set
}
}
}
}
}
policy rp-export-6:1-ip-vrf {
default-action {
policy-result reject
}
statement stmt-10 {
match {
protocol bgp-ipvpn
bgp {
standard-community {
standard-community-set scs-6:1
}
}
}
action {
policy-result accept
}
}
}
}
network-instance IP-VRF-1 {
type ip-vrf
admin-state enable
interface int-ip-vrf-1-PE-1-CE-4 {
interface-ref {
interface ethernet-1/4
subinterface 2 # IP address: 172.16.114.1/30
}
}
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 {
next-hop-self true
peer-as 64500
export-policy [
rp-export-6:1-ip-vrf
]
import-policy [
rp-import-4:1-LP200
]
afi-safi ipv4-unicast {
admin-state enable
}
}
neighbor 172.16.114.2 {
peer-group grp-EBGP-1
}
}
bgp-vpn {
backup-paths { ## BGP FRR for imported VPN-IP routes
ipv4-unicast {
install true
}
}
bgp-instance 1 {
route-distinguisher {
rd 192.0.2.1:1
}
route-target {
import-rt target:64496:1
export-rt target:64496:1
}
}
}
The import policy sets the LP to 200 for the routes received from CE-4. The configuration on PE-2 is similar, but the import policy keeps the default LP 100. Therefore, the path via PE-1 with LP 200 is preferred over the path via PE-2. This prevents PE-2 to advertise it own EBGP route to CE-4, so another import policy is configured on PE-2 to replace LP 200 by LP 100 and this policy is applied to the VPN-IPv4 address family in the default network instance, as follows:
# on PE-2:
enter candidate
routing-policy {
standard-community-set scs-4:1 {
member [
4:1
]
}
policy rp-import-bgpipvpn-4:1-LP100 {
statement stmt-10 {
match {
bgp {
standard-community {
standard-community-set scs-4:1
}
}
}
action {
policy-result accept
bgp {
local-preference {
value 100
operation set
}
}
}
}
}
}
network-instance default {
protocols {
bgp {
group grp-IBGP {
afi-safi l3vpn-ipv4-unicast {
admin-state enable
import-policy [
rp-import-bgpipvpn-4:1-LP100
]
}
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, the following IP-VRF is configured on CE-4:
# on CE-4:
enter candidate
routing-policy {
standard-community-set scs-4:1 {
member [
4:1
]
}
standard-community-set scs-6:1 {
member [
6:1
]
}
prefix-set ps-172.31.0.0 {
prefix 172.31.0.0/24 mask-length-range exact {
}
}
policy rp-export-4:1-ip-vrf {
statement stmt-10 {
match {
prefix {
prefix-set ps-172.31.0.0
}
}
action {
policy-result accept
bgp {
standard-community {
operation add
method reference
referenced-sets [
scs-4:1
]
}
origin {
set igp
}
}
}
}
}
policy rp-import-6:1-ip-vrf {
default-action {
policy-result reject
}
statement stmt-10 {
match {
bgp {
standard-community {
standard-community-set scs-6:1
}
}
}
action {
policy-result accept
}
}
}
}
network-instance IP-VRF-1 {
type ip-vrf
admin-state enable
interface int-CE-4-ip-vrf-1-PE-1 {
interface-ref {
interface ethernet-1/1
subinterface 2 # IP address 172.16.114.2/30
}
}
interface int-CE-4-ip-vrf-1-PE-2 {
interface-ref {
interface ethernet-1/2
subinterface 2 # IP address 172.16.124.2/30
}
}
interface lo0-172.31.0.1 {
interface-ref {
interface lo0
subinterface 1
}
}
protocols {
bgp {
admin-state enable
autonomous-system 64500
router-id 192.0.2.4
afi-safi ipv4-unicast {
admin-state enable
}
group grp-EBGP-1 {
peer-as 64496
export-policy [
rp-export-4:1-ip-vrf
]
import-policy [
rp-import-6:1-ip-vrf
]
afi-safi ipv4-unicast {
admin-state enable
}
}
neighbor 172.16.114.1 {
peer-group grp-EBGP-1
}
neighbor 172.16.124.1 {
peer-group grp-EBGP-1
}
}
The configuration on CE-6 is similar.
For all BGP speakers in AS 64496, BGP must be configured for address family VPN-IPv4 and BGP add-paths can be enabled for VPN-IPv4, for example, at group level:
# on PE-1, PE-2, PE-3:
enter candidate
network-instance default {
protocols {
bgp {
afi-safi l3vpn-ipv4-unicast {
admin-state enable
}
group grp-IBGP {
afi-safi l3vpn-ipv4-unicast {
admin-state enable
add-paths {
receive true
send true
send-max 2
}
}
}
In this example, BGP add-paths is enabled at neighbor level on RR-5, as follows:
# on RR-5:
enter candidate
network-instance default {
protocols {
bgp {
neighbor 192.0.2.1 {
afi-safi l3vpn-ipv4-unicast {
admin-state enable
add-paths {
receive true
send true
send-max 2
}
}
}
neighbor 192.0.2.2 {
afi-safi l3vpn-ipv4-unicast {
admin-state enable
add-paths {
receive true
send true
send-max 2
}
}
}
neighbor 192.0.2.3 {
afi-safi l3vpn-ipv4-unicast {
admin-state enable
add-paths {
receive true
send true
send-max 2
}
}
}
With add-paths enabled for address family VPN-IPv4, PE-1 and PE-2 advertise their route for prefix 172.31.0.0/16 as VPN-IPv4 route to RR-5. RR-5 advertises both routes to its other RR clients. PE-3 receives two VPN-IPv4 routes for prefix 172.31.0.0/16, as follows:
--{ + running }--[ ]--
A:admin@PE-3# show / network-instance default protocols bgp routes l3vpn-ipv4-unicast prefix 172.31.0.0/24
----------------------------------------------------------------------------------------------------------
Show report for the BGP routes to network "172.31.0.0/24" network-instance "default"
----------------------------------------------------------------------------------------------------------
Route-distinguisher: 192.0.2.1:1 Network: 172.31.0.0/24
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference: MED is -, LocalPref is 200
BGP next-hop : 192.0.2.1
Path : i [64500]
Communities : 4:1, target:64496:1
Path 1 was advertised to:
[ ]
----------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------
Show report for the BGP routes to network "172.31.0.0/24" network-instance "default"
----------------------------------------------------------------------------------------------------------
Route-distinguisher: 192.0.2.2:1 Network: 172.31.0.0/24
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.2
Path : i [64500]
Communities : 4:1, target:64496:1
Path 1 was advertised to:
[ ]
----------------------------------------------------------------------------------------------------------
Both routes are used: the route via PE-1 has local preference 200 and the route via PE-2 has local preference 100.
The routing table for IP-VRF 1 on PE-3 shows the active and the backup route for prefix 172.31.0.0/16, as follows:
--{ + running }--[ ]--
A:admin@PE-3# show / network-instance IP-VRF-1 ipv4 route 172.31.0.0/24
=======================================================================================================
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)
-------------------------------------------------------------------------------------------------------
172.31.0.0/24 bgp-ipvpn 10 170 > 192.0.2.1(tunnel:ldp, label:30000)
backup:192.0.2.2(tunnel:ldp, label:30000)
Add-paths for family VPN-IPv4 with ECMP
The import policy is replaced in IP-VRF 1 on PE-1 to make the cost of the paths via PE-1 and PE-2 equal, as follows:
# on PE-1:
enter candidate
routing-policy {
policy rp-import-4:1-LP100 {
default-action {
policy-result reject
}
statement stmt-10 {
match {
bgp {
standard-community {
standard-community-set scs-4:1
}
}
}
action {
policy-result accept # local preference 100 is not modified
}
}
}
}
network-instance IP-VRF-1 {
protocols {
bgp {
group grp-EBGP-1 {
import-policy [
rp-import-4:1-LP100
]
ECMP is enabled in IP-VRF 1 on all PEs, as follows:
# on PE-1, PE-2, PE-3:
enter candidate
network-instance IP-VRF-1 {
protocols {
bgp-ipvpn {
bgp-instance 1 {
ecmp 2
BGP multipath needs to be enabled in the base routing context, but that already happened.
With ECMP enabled, the two routes that are received on PE-3 from RR-5 are both active, as follows:
--{ + running }--[ ]--
A:admin@PE-3# show / network-instance default protocols bgp routes l3vpn-ipv4-unicast prefix 172.31.0.0/24
----------------------------------------------------------------------------------------------------------
Show report for the BGP routes to network "172.31.0.0/24" network-instance "default"
----------------------------------------------------------------------------------------------------------
Route-distinguisher: 192.0.2.1:1 Network: 172.31.0.0/24
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.1
Path : i [64500]
Communities : 4:1, target:64496:1
Path 1 was advertised to:
[ ]
----------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------
Show report for the BGP routes to network "172.31.0.0/24" network-instance "default"
----------------------------------------------------------------------------------------------------------
Route-distinguisher: 192.0.2.2:1 Network: 172.31.0.0/24
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.2
Path : i [64500]
Communities : 4:1, target:64496:1
Path 1 was advertised to:
[ ]
----------------------------------------------------------------------------------------------------------
ECMP is enabled with a value of two, so traffic flows in IP-VRF-1 on PE-3 with destination 172.31.0.0/16 are distributed over two paths: one via PE-1 and another via PE-2, as follows:
--{ + running }--[ ]--
A:admin@PE-3# show / network-instance IP-VRF-1 ipv4 route 172.31.0.0/24
==============================================================================================
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)
----------------------------------------------------------------------------------------------
172.31.0.0/24 bgp-ipvpn 10 170 > 192.0.2.1(tunnel:ldp, label:30000)
192.0.2.2(tunnel:ldp, label:30000)
Conclusion
BGP add-paths allows BGP speakers to advertise multiple distinct paths for the same prefix. The potential benefits of BGP add-paths include reduced routing churn, faster convergence, and better load-sharing.