Information About BGP Additional Paths
Overview
BGP routers and
route reflectors (RRs) propagate only their best paths over their
sessions. The advertisement of a prefix replaces the previous
announcement of that prefix (this behavior is known as an implicit
withdraw). The implicit withdraw can achieve better scaling, but at the
cost of path diversity.
Path hiding can
prevent efficient use of BGP multipath, prevent hitless planned
maintenance, and lead to multi-exit discriminator (MED) oscillations and
suboptimal hot-potato routing. In a next-hop failure, path hiding
inhibits fast and local recovery because the network has to wait for BGP
control plane convergence to restore traffic. The BGP Additional Paths
feature offers path diversity; the best external or best internal
features offer path diversity in limited scenarios.
Path-Hiding Scenario
The following
figure shows prefix p with paths p1 and p2 advertised from BR1 and BR4
to RR1. RR1 selects the bes tpath of the two and then advertises only p1
to the PE.
In the above
figure, prefix x with path x1 is advertised from BR2 to BR3 (which has
path x2) with local preference 100. BR3 also has path x2, but due to the
routing policy, BR3 advertises to the RRs x1 (not shown) instead of x2,
x2 is suppressed. You could turn on the advertisement of best external
on BR3 and advertise x2 to the route reflectors (RRs), but, the RRs
advertise only the best path.
Suboptimal Hot-Potato Routing Scenario
To minimize
internal transport costs, transit Internet service providers try to
forward packets to the closest exit point (according to the Interior
Gateway Protocol (IGP) cost). This behavior is known as hot-potato
routing. In the distributed RR cluster model of the figure below, assume
traffic that is coming from LA must go to Mexico. All links have the
same IGP cost. If there are two exit points toward Mexico—one toward
Austin and one toward Atlanta—the border router will try to send traffic
to Austin based on the lower IGP cost from LA toward Austin than toward
Atlanta. In a centralized RR model where the central RR resides where
RR3 is (and RR1, RR2, RR4, and RR5 do not exist), the closest exit point
toward Mexico, as seen from RR3, might be Atlanta. Sending the traffic
from LA toward the Atlanta border router (BR) results in suboptimal
hot-potato routing and is not desirable.
Benefits of Additional BGP Paths
BGP routers and
route reflectors (RR) propagate only their best path over their
sessions. The advertisement of a prefix replaces the previous
announcement of that prefix (also known as an implicit withdraw).
While this behavior
might achieve better scaling, it can prevent path diversity, which
tends to be poor or completely lost. This behavior prevents efficient
use of the BGP multipath, prevents hitless planned maintenance, and lead
to multi-exit discriminator (MED) oscillations and suboptimal
hot-potato routing. It also inhibits fast and local recovery for
next-hop failures, because the network has to wait for BGP control plane
convergence to restore traffic.
BGP Additional Paths Functionality
You can use the BGP
Additional Paths feature by adding a path identifier to each path in
the Network Layer Reachability Information (NLRI). The path identifier
(ID) can be considered as something similar to a route distinguisher
(RD) in virtual private networks (VPNs), except that a path ID can apply
to any address family. Path IDs are unique to a peering session and are
generated for each network. The path identifier is used to prevent a
route announcement from implicitly withdrawing the previous one. The
Additional Paths feature allows the advertisement of more paths, in
addition to the best path and allows the advertisement of multiple paths
for the same prefix, without the new paths implicitly replacing any
previous paths.
1.
Specify whether the device can send, receive, or send and receive
additional paths at the address family level or the neighbor level.
During session establishment, two BGP neighbors negotiate the additional
path capabilities (whether they can send or receive) between them.
Specify whether the device can send, receive, or send and receive
additional paths at the address family level or the neighbor level.
During session establishment, two BGP neighbors negotiate the additional
path capabilities (whether they can send or receive) between them.
To send or receive
additional paths, the additional path capability must be negotiated
between the neighbors. If no negotiation occurs, even if the selection
criteria marks the best path and the neighbor is configured to advertise
the marked paths, the selections are useless because only the best path
is advertised.
Configuring BGP to
send or receive additional paths triggers negotiation of an additional
path’s capability with the device's peers. Neighbors that have
negotiated the capability are grouped together in an update group (if
other update group policies allow), and in a separate update group from
those peers that have not negotiated the capability. Therefore, the
additional path capability causes the neighbor's update group membership
to be recalculated.
Configuring BGP Additional Paths
- Configuring BGP Additional Paths for each Address Family
- Configuring BGP Additional Paths for each Neighbor
- Configuring Additional Paths Using a Peer Policy Template
- Filtering and Setting Actions for Additional Paths
DETAILED STEPS
BEFORE YOU BEGIN
Ensure that you have enabled the BGP feature (see the “Enabling the BGP Feature” section).
SUMMARY STEPS
DETAILED STEPS
BEFORE YOU BEGIN
Ensure that you have enabled the BGP feature (see the “Enabling the BGP Feature” section).
SUMMARY STEPS
DETAILED STEPS
Filtering and Setting Actions for Additional Paths
You can optionally
use a route map to filter the paths to be advertised by matching on the
prefix of additional paths that are candidates to be advertised. (These
prefixes are configured with the additional-paths selection command.)
You can also
optionally set one or more actions to take for those paths that pass
through the route map. This procedure uses the set metric command. Other set commands are available that are not shown in this task.
You would set a metric for paths marked with all
(all paths with a unique next-hop) if the neighbor is receiving the
same routes from its neighbors. Suppose the neighbor 2001:DB8::1037 is
receiving the same route from different neighbors. Routes received from
the local device have a metric of 565 and routes from another device
have a metric of 700. Routes with metric 565 have precedence over the
routes with metric 700.
Configuration Examples for BGP Additional Paths
- BGP Additional Paths Send and Receive Capabilities
- BGP Additional Paths Using a Peer Policy Template
R1
In this example,
R1's address is 2001:db8::1045; its neighbor R2 has an address of
2001:db8::1037. Updates are sent from R2 to R1 with additional-paths
(all paths advertised). Updates are sent from R1 to R2 with only the
classic BGP best path advertised because R2 can only send additional
paths, not receive additional paths.
