A BGP device generally advertises only its best path to neighboring devices, even when multiple paths exist; the advertisement of the same prefix from the same neighbor replaces the previous announcement of that prefix. This path hiding is an implicit withdrawal behavior, which achieves better scaling but at the cost of path diversity. Path hiding can affect the efficient use of BGP multipath and path diversity, and prevent hitless planned maintenance. Upon next-hop failures, path hiding also inhibits fast and local recovery because the network must wait for BGP control plane convergence to restore traffic.
The following figure shows two types of path hiding:
Paths P1 and P2 (for prefix P) are advertised to RR1.
P1 is advertised from BR1 and P2 is advertised from BR2. RR1 selects P1 as the best
path and advertises only P1 to PE.
Paths X1 and X2 (for prefix X) are advertised to BR4.
X1 is advertised from BR3 with a local preference of 100. BR4 also has path X2 with
a local preference 50. However, only the best path (X1) is selected. BR3 advertises
X1 to the RRs and X2 is suppressed.
BGP path hiding
BGP additional-paths enables BGP to advertise
even secondary best routes, so that multiple paths for the same prefix can be advertised
without the new paths implicitly replacing previous paths. BGP additional-paths provides
a generic way of offering path diversity.
BGP additional-paths is implemented by including
an additional four-octet value known as a path identifier (ID) for each path in the
Network Layer Reachability Information (NLRI). Path IDs are unique to a peering session
and are generated for each network. That is, a generated path ID is unique for each peer
for each prefix.
A BGP device can receive the same path ID for the same prefix from two different peers, or it can receive the same path ID from the same peer for two different prefixes:
When the same prefix is received with the same path ID from the same peer, it is considered to be a replacement route or duplicate route.
When the same prefix is received with a different path ID from the same peer, it is considered to be an additional path to the prefix.
To send or receive additional paths, the
additional-paths capability must be negotiated. When it is not negotiated, only the best
path is sent.
When the additional-paths capability is negotiated, BGP updates carry the path ID. To carry the path ID in an update message, the existing NLRI encodings are extended by prepending the path ID field, which consists of four octets.
The BGP device uses the prefix and path ID to
uniquely identify a path advertised to a neighbor so as to continue to send updates for
that path. The receiving BGP neighbor that re-advertises a route regenerates its own
path ID that is to be associated with the re-advertised route.
The set of additional paths advertised to each
neighbor can be different, and advertisement filters are provided for each neighbor.
The following figure shows a BGP additional-paths configuration that supports path diversity.
BGP additional-paths
Although route reflector RR1 has two sources for prefix N, it advertises only the best route to its peers when the additional-paths capability is not configured.
When the additional-paths capability is configured at RR1 and PE3, PE3 receives two routes to prefix N. Receiving two routes facilitates quick network convergence and recovery:
Using PE1 and PE2
ECMP paths to PE1 and PE2
Configuration of BGP additional-paths
The configuration of BGP additional-paths involves the following actions:
Capability negotiation: Specifying, at the
address family, peer group, or neighbor levels, whether the device can send,
receive, or both send and receive additional-paths .
Candidate path selection: Specifying, at the
address family level, selection criteria for a set or sets of candidate
paths to be advertised.
Advertisement of additional-paths from the
candidate set: Specifying, at the neighbor or peer group levels, a
set or sets of additional-paths to advertise to a neighbor. The
additional-paths to advertise must be from the candidate paths that are
marked.
Advantages of BGP
additional-paths
Fast convergence and fault
tolerance: When BGP additional-paths is enabled, more than one path to a
destination is advertised. When one of the paths goes down, connectivity is
easily restored due to the availability of backup paths. When the next-hop for
the prefix becomes unreachable, the device can switch to the backup route
immediately without having to wait for BGP control plane messages.
Enhanced load-balancing
capabilities: Traditionally with route reflectors (RRs) in an iBGP
domain, only the best path is given to clients, even when ECMP paths exist.
Giving only the best path affects load balancing. When additional paths are
advertised by RRs, the clients have more effective load balancing.
Considerations and limitations for BGP additional-paths
BGP additional-paths is supported for
the following BGP address families:
IPv4 unicast
IPv4 unicast VRF
IPv6 unicast
IPv6 unicast VRF
BGP additional-paths is not supported for BGP VPNv4 unicast, BGP VPNv6, and BGP
EVPN address families.
Changes in the capability of receiving
or sending additional-paths are reflected only after the BGP session is
restarted.
RIB-in:
When BGP additional-paths is
not configured, only one NLRI for each prefix for each peer is
supported. Any additional NLRI update for the same prefix from the same
peer replaces the existing one.
When BGP additional-paths is
configured, a device can receive multiple NLRI advertisements for the
same prefix from the same peer that are uniquely identified by NLRI path
identifiers.
The maximum number of
additional-paths for each peer for each prefix is 128.
RIB-out:
The maximum number of paths
that can be advertised for each prefix is 16. When more than 16 paths
for a prefix exist in the RIB-in, only 16 can be advertised.
For smooth RIB-out processing,
the number of RIB-in paths for any prefix should be maintained within
the range from 1 through 16. RIB-out processing time increases
exponentially in the scaled scenarios.
Upgrade and downgrade considerations for BGP additional-paths
BGP additional-paths configuration should be removed before a downgrade to a version of software that does not support additional-paths.
When BGP additional-paths is enabled and the
configuration saved, an error message occurs when the software is downgraded to an
earlier version that does not support the feature. To avoid this error message, the
BGP additional-paths configuration should be removed before the downgrade takes
place and reconfigured when upgraded again.
