BGP Best External and Add-Path: Advertise More Paths

2026年9月14日 LOG admin

BGP advertises one best path per prefix. That single rule creates two well-known problems: the backup path exists in the RIB but is never advertised, so convergence after a failure depends on re-learning rather than pre-programmed forwarding; and in a route-reflector hierarchy, an iBGP best path can hide a customer's own eBGP exit, causing traffic to leave an AS through the wrong door. Best external and add-path (RFC 7911, advertisement of multiple paths) are the standard answers. This guide covers what each solves, the vendor commands, and how to verify the extra paths really arrive.

Why One Path Per Prefix Is a Problem

BGP runs a best-path decision over everything it learned, hands the winner to the RIB, and by default advertises exactly that winner to its peers. The other candidates stay in the table as backups but are never sent anywhere. In a small network that is fine. In a multi-homed, multi-border network it produces two specific failure modes.

Slow failover, or no pre-programmed failover. A border router may hold four paths to a given prefix — one best and three backups — and yet its neighbours know about none of them. When the best path dies, the router re-runs the decision and advertises a new one, and the rest of the network waits for that update. BGP PIC (prefix-independent convergence) exists to fix exactly that by pre-installing a backup into the forwarding plane, but the whole idea depends on the backup path being available as a path, not just as an entry in the local RIB.

Hot-potato routing gone wrong. Consider an AS with two border routers that both peer with the same transit provider, and an internal route reflector connecting them. Router A learns 198.51.100.0/24 from its eBGP peer; router A also learns the same prefix over iBGP from router B with a better LOCAL_PREF or a shorter IGP distance to B. A now selects the iBGP path as best — perfectly legal — and therefore stops advertising the external path to its iBGP peers. If the iBGP session to B goes away, A has nothing to fall back on toward the original external exit, and packets take the long way around the AS, crossing the backbone twice before leaving the correct door. This is the classic "BGP best external" scenario, and it is why the feature exists.

Which Problem Are You Solving?

Feature	Problem it solves	Scope
Best external	A border router selects an iBGP path as best and therefore stops advertising the customer's external path to its iBGP peers — breaking BGP PIC/FRR and causing suboptimal hot-potato routing	One extra path (the best external) beyond the best path
Add-path (RFC 7911)	Generic path diversity: send and receive several paths per prefix, not just the active one	Configurable path count (2–20 or more depending on platform), filtered by policy

Best External: What It Actually Advertises

The best external path is defined as the best path among those learned from external peers, evaluated even when the overall best path is internal. Enabling best external means the border router advertises that path to its iBGP peers alongside (or instead of, depending on vendor and configuration) the customer's internally learned path. Downstream routers — the route reflector and its clients — then hold a real external exit for the prefix and can use it for fast reroute or for a cold-potato exit decision instead of relying on a path that no longer exists.

Two properties are worth being precise about:

Best external does not change which path you forward on. It changes what you advertise. Your data plane still follows the best-path decision; the extra advertisement is a gift to your iBGP neighbours.
The receiving routers are what benefit. Advertising a diverse path into a network where nobody can install or use it gains you nothing except memory consumption. Where best external is used for PIC, both the sender and the receiver usually need a platform and release that support PIC.

IOS-XE: Best External, Old and New Syntax

The original one-liner enables calculation, installation and advertisement together:

router bgp 65000
 address-family ipv4 unicast
  bgp advertise-best-external

Newer releases split the behaviour into three knobs, which is what you want when you want control over each step:

router bgp 65000
 address-family ipv4 unicast
  bgp additional-paths select best-external
  bgp additional-paths install
  neighbor 10.5.1.2 advertise diverse-path best-external

Notes from the Cisco documentation that matter in practice:

If bgp additional-path select best-external is not configured, the system still calculates and installs the best external path — it just never advertises it.
Configuring bgp advertise-best-external implicitly enables the BGP PIC feature; you do not also need bgp additional-paths install.
Issued in VPNv4 address-family mode it applies to all IPv4 VRFs; issued in an IPv4 address family it applies only to that VRF.

IOS-XE: Additional Paths (Generic)

router bgp 100
 address-family ipv4
  bgp additional-paths send receive
  bgp additional-paths select group-best all
  neighbor 192.168.2.2 advertise additional-paths best 3

If the selection policy is more restrictive than the advertisement policy, IOS-XE tells you so and only advertises the best path:

% BGP: AF level 'bgp additional-paths select' more restrictive than advertising policy.

Read that as: the set you advertise must be a subset of the set you selected.

The selection keywords you will meet are worth knowing individually, because each one buys a different kind of diversity:

best-external — the best path learned from eBGP, regardless of the overall best-path winner.
group-best — one best path per peer group, which spreads advertisements across the different eBGP exits without flooding the table. On a router with four transit peers this is often the most useful single setting.
all — every path that survives policy, which is the most complete and by far the most expensive in memory and advertisement churn.
ecmp-best or equal-cost selection — the equal-cost members of a multipath set, which pairs well with add-path when you want the receiver to see every member of an ECMP group rather than one representative.

Combine a selective keyword with a neighbour-level cap: bgp additional-paths select best-external group-best plus neighbor ... advertise additional-paths best 2 keeps the advertisement set small and predictable, and predictable is what you want when you have to explain the design to the next engineer.

Junos: add-path send and receive

set protocols bgp group ibgp type internal
set protocols bgp group ibgp local-address 10.0.0.1
set protocols bgp group ibgp neighbor 10.0.0.2 add-path send path-count 6
set protocols bgp group ibgp neighbor 10.0.0.2 add-path receive
set protocols bgp group ibgp multipath


Three operational details from the Junos documentation:

The minimum valid send configuration is add-path send path-count <n>; you cannot configure the bare add-path statement, and receive is separate (add-path receive).
Add-path is negotiated per session. If R1 sends and R2 has not configured receive, R1 will not send multiple paths. Capability mismatch is the number one reason "add-path is configured but nothing changed".
On PTX1000 platforms the add-path statement is not supported under routing instances — check platform support before designing around it.

Useful optional knobs on Junos: prefix-policy to limit add-path to specific prefixes, path-selection-mode (all-paths | equal-cost-paths), and include-backup-path when you want the pre-computed backup included in the advertisement.
Junos: advertise-external for the Hot-Potato Case
Junos solves the best-external problem with a different statement name, applied at the group level on the routers that have both eBGP and iBGP peers:
set protocols bgp group TO-ISP type external
set protocols bgp group TO-ISP peer-as 64512
set protocols bgp group TO-ISP neighbor 192.0.2.1

set protocols bgp group TO-RR type internal
set protocols bgp group TO-RR local-address 10.0.0.1
set protocols bgp group TO-RR advertise-external
set protocols bgp group TO-RR advertise-external conditional
set protocols bgp group TO-RR neighbor 10.0.0.2
advertise-external tells the router to advertise the best external route to its internal peers even when the active route is internal, which is the direct fix for the "external exit hidden by an iBGP best path" problem. conditional narrows that behaviour: it advertises the external route only when there is no external route to advertise for that prefix otherwise. The conditional form is the safer default in a network that already has enough prefix churn, because it changes what is advertised only in the case that would otherwise leave a neighbour with nothing.
What RFC 7911 Actually Changes on the Wire
Add-path is a capability, not a policy. Both peers negotiate capability code 69 during session establishment, and only when both sides agree do multiple paths flow. Once negotiated, every NLRI that belongs to an add-path-capable address family carries a four-byte path identifier in front of the prefix. That identifier is what makes two advertisements of the same prefix distinguishable — without it, the second advertisement would look like a duplicate and be treated as a withdrawal, which is exactly the kind of silent misconfiguration that produces "the session is up but paths keep flapping" tickets.
Three consequences follow:

Best-path selection is unchanged. Add-path does not alter the decision process, LOCAL_PREF, MED or any other tiebreaker. It only changes how many of the results you transmit.
Path identifiers are local to the session. They have no global meaning; a receiver uses them to track distinct paths, not to compare them across peers.
Both directions are independent. Sending multiple paths and receiving multiple paths are separate capabilities. A route reflector typically needs send toward its clients and receive from its clients, which is why "configure it in both directions on both ends" is the deployment motto.

Verification
# IOS-XE
show bgp ipv4 unicast 198.51.100.0/24
show bgp ipv4 unicast 198.51.100.0/24 bestpath
show bgp ipv4 unicast additional-paths advertise 198.51.100.0/24
show bgp ipv4 unicast additional-paths receive 198.51.100.0/24
show bgp ipv4 unicast additional-paths best-external 198.51.100.0/24
show bgp summary | include additional

# Junos
show route 198.51.100.0/24 extensive | match "Add-path|Local AS|Peer AS"
show route advertising-protocol bgp 10.0.0.2 198.51.100.0/24
show bgp neighbor 10.0.0.2 | match -i "add-path|path-count"
What you are looking for: more than one path entry with the add-path marker, and a session capability line showing that add-path was negotiated in the direction you configured. If the capability is negotiated but only one path is advertised, revisit the select/advertise policy — not the session.
The three additional-paths views on IOS-XE deserve separate attention because they answer different questions. advertise shows you what you are about to send to a given peer and is the fastest way to catch a policy that is silently dropping the diverse path. receive shows what actually arrived, which is where you confirm that the other side negotiated correctly. best-external shows the path the router computed as its best external candidate — useful when you cannot tell whether the feature is doing nothing because of policy or because there is genuinely no external path to advertise.
On Junos, show route advertising-protocol bgp is the most direct check: it lists the exact NLRI being advertised to a specific neighbour. Compare it against show route receive-protocol bgp on the far end. If the two disagree, the problem is on the wire or in the session capability; if they agree and the path is still not installed, the problem is the receiving router's selection and installation settings.
A Worked Example: Two Borders, One Route Reflector
Take an AS 65000 with border routers PE1 (10.0.0.1) and PE2 (10.0.0.2), a route reflector RR1, and a customer prefix 198.51.100.0/24 learned by both borders over eBGP from AS 64512. Both borders peer with the RR over iBGP.

PE1 selects its eBGP path. PE2 also selects its eBGP path — the same prefix, a different next hop. Each border, evaluating only its own view, is happy.
Now add an iBGP-learned path that wins on LOCAL_PREF or IGP distance. PE1's best path becomes the one via PE2. Without best external, PE1 stops advertising its own external path entirely.
With bgp additional-paths select best-external plus neighbor 10.0.0.2 advertise diverse-path best-external on IOS-XE (or advertise-external in the internal group on Junos), PE1 keeps sending its external path to the RR.
The RR now holds two external paths for the prefix and can offer both to its clients, so when the session to PE2 drops, a client that had pre-installed the PE1 path via PIC can switch in the forwarding plane instead of waiting for BGP to re-converge.
Verify on the RR that both paths are present with distinct path identifiers, and verify on PE1 that additional-paths advertise lists the prefix. If either check fails, the other is meaningless.

Deployment Cautions

More advertised paths means more RIB/FIB entries and memory. Cap path-count to what the hardware can actually install, and use prefix-policy rather than advertising multiple paths for the whole table.
Installation and advertisement are separate: installing extra paths is what gives you fast reroute, advertising them is what gives you hot-potato correctness. Know which one you are buying.
Test capability negotiation in both directions before rolling out; a mismatched neighbour pair works in the lab and fails after a software upgrade.
Cap the advertisement set per neighbour, not just globally. A neighbour-level limit of two or three paths keeps the control plane predictable even when the address family is configured for more.
Expect more BGP update churn once multiple paths are advertised, because a change to any of the advertised paths now produces an update rather than being absorbed locally. Watch the update rate on the route reflector, not just on the borders.
Filter on receipt as well. A router has no obligation to accept every diverse path a neighbour offers; a receive-side prefix policy keeps a peer's configuration mistake from consuming your own memory.
Re-check platform support before designing. Statements that work in one address family or routing instance are not always supported on every platform or in every release, and the failure is usually a commit warning rather than a hard error.

相关阅读：BGP 路由翻动抑制：Penalty、Half-Life 与 Reuse、BGP 邻居卡在 Idle/Active 的排障 以及 TI-LFA 与 SR 快速重路由配置。
相关阅读

BGP Best Path Selection: The 13-Step Algorithm Explained — the decision process that creates the hidden-exit problem in the first place.
BGP Route Reflector cluster-id: Configuration Guide — the reflector design that makes best external and add-path necessary.
BGP ECMP Configuration: Cisco, Juniper and Arista — when you want multiple paths used, not just advertised.

原文链接：Juniper - Example: Advertising Multiple Paths in BGP


                        
                                    版权声明：
                    作者：admin
                    链接：https://gitgit.ee/bgp-best-external-add-path-advertise-configuration.html
                    文章版权归作者所有，未经允许请勿转载。
                            
                                    
                
                    
                
                                bgp
                                cisco
                                juniper
                                routing