BGP4+ Additional Paths Configuration
Overview
The Border Gateway Protocol (BGP) ADDPATH feature allows the advertisement of multiple paths through the same peering session for a given prefix without the new paths implicitly replacing any previous paths. This behavior promotes path diversity and reduces the severity of a network failure, thereby improving the control plane convergence in case of network failures.
Normal BGP Behavior
By default, all BGP routers and Route-Reflectors propagate only their best paths over their sessions. In case they advertise any route with the same NLRI as a previously advertised route, the latest one implicitly replaces the previous advertisement, which is known as an Implicit Withdraw. The Implicit Withdraw can achieve better scaling, but at the cost of path diversity.
The use of route-reflectors (or confederations), thus has significant effect on redundancy by hiding alternate paths. Using full-mesh is not an option, so a mechanism is needed to allow the propagation of multiple alternate paths in an RR/Confederation environment. Such mechanism is already available in BGP/MPLS VPN scenarios, where multiple point of attachments for CE sites could utilize different RD values to differentiate the same routes advertised from different connection points. However, a generic solution is required, allowing for advertising multiple alternate paths with IPv4 or any other address-family.
The “Advertisement of Multiple Paths in BGP” or “BGP Add-Path” as the feature is usually called is a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previously advertised ones.
BGP Behavior with Additional Paths
The advertisement of multiple paths in BGP is made possible by aending a BGP OPEN message to the neighbor with a BGP capability code of 69, which identifies the BGP ADD-PATH Capability.
Address Family Identifier(AFI) | 2 octets |
Subsequent Address Family Identifier(SAFI) | 1 octet |
Send/Receive | 1 octet |
The send/receive field in the BGP Capability TLV indicates whether for a given <AFI, SAFI>, the sender is able to:
• Receive multiple paths from its peer (value 1)
• Send multiple paths to its peer (value 2), or
• both (value 3)
• Each alternate path is identified by a Path Identifier in addition to the address prefix
Path Identifier | 4 octets |
Length | 1 octet |
Prefix | variable |
In the event of a next-hop failure, the BGP Add-Path feature hence improves the BGP control plane convergence
Last modified date: 10/16/2023