RETICUX BGP Mastery — Day 024 — Best External and ADD-PATH: Preserving Path Diversity Beyond One Best Path

Learning objective

Explain why one best path can hide useful alternatives and compare Cisco Best External with standards-based ADD-PATH.


Best External and ADD-PATH: Preserving Path Diversity Beyond One Best Path
Best External and ADD-PATH: Preserving Path Diversity Beyond One Best Path



1. Opening — the decision point that is easy to misread

BGP best-path selection is sequential. A router does not assign a single universal “route score” and then pick the smallest or largest number. It evaluates eligible paths through an ordered decision process. The first meaningful difference can end the comparison; later attributes may never be examined.

That matters operationally because engineers often see two routes and jump directly to AS_PATH length. By the time AS_PATH is reached, several earlier decisions may already have eliminated one candidate. Conversely, when two routes remain equal through MED, later implementation-specific or topology-dependent decisions become decisive.

This day isolates one such decision point so that the result can be proven rather than inferred from a route table alone.

2. Standards behavior versus Cisco behavior

RFC 4271 defines BGP's route selection framework but deliberately leaves implementation-specific selection details to implementations. Cisco IOS XE documents an ordered decision process containing Cisco-local and BGP attributes.

The engineering rule is therefore: use RFC text to understand protocol semantics, and Cisco documentation to verify the actual IOS XE decision order and configuration knobs. Do not copy an algorithm from a different vendor and assume Cisco behaves identically.

This distinction becomes particularly important for router ID, multipath, best-external and route-reflector features.

3. Scenario

A route reflector or edge router has a useful alternate path that is not the primary best path. The lab first shows why ordinary BGP advertisement can hide that alternate path, then contrasts Cisco Best External with standards-based ADD-PATH, which uses a Path Identifier so multiple paths for the same prefix can coexist in the session.

The lab uses documentation-safe addressing and private lab ASNs. No production prefixes, credentials or real operator identifiers are used.

4. Topology


Best External and ADD-PATH: Preserving Path Diversity Beyond One Best Path
Best External and ADD-PATH: Preserving Path Diversity Beyond One Best Path


                         AS 65100
                 +---------------------+
                 |       R1 / Core     |
                 |   BGP decision point|
                 +----------+----------+
                            | iBGP
                            |
                         +--+--+
                         | R2  |
                         +--+--+
                            |
                 +----------+----------+
                 |                     |
              eBGP                  eBGP
                 |                     |
              +--+--+               +--+--+
              | ISP-A|               | ISP-B|
              |65110 |               |65120 |
              +-----+               +-----+

Prefix under test: 203.0.113.0/24

5. Prerequisites

  • IOS XE 17.18.x target image or equivalent supported IOS XE 17.x lab image.
  • Reachable loopbacks/interfaces before BGP policy is tested.
  • IPv4 unicast address family enabled.
  • Private/documentation-safe ASNs and prefixes.
  • show ip bgp, show ip bgp summary, and show ip route available.
  • NTP or a stable lab clock is recommended for incident timestamps.

6. Baseline configuration

router bgp 65100
 address-family ipv4 unicast
  bgp additional-paths select best 2
  neighbor 10.0.20.2 additional-paths send
 exit-address-family
!
! Cisco Best External is a separate feature and must be checked against the exact AF/platform support before deployment.

The configuration above is intentionally scoped to the learning objective. It should not be described as a universal production template.

7. Verification before modification

Verify negotiated capabilities, selected additional paths, and the receiving router's BGP table. For ADD-PATH, inspect the path identifier behavior conceptually; for Best External, verify which external path is being advertised and to which peer class.

Record the baseline best path before changing the single variable under test. The evidence must show both the BGP table and the installed IP route when forwarding behavior is part of the objective.

8. Controlled modification

Enable ADD-PATH only after verifying send/receive capability on both ends. Treat Best External as a distinct Cisco feature with its own support matrix. Do not configure both mechanisms simply because they both advertise more than one path.

Change only the variable under investigation. Do not simultaneously alter LOCAL_PREF, MED, AS_PATH, next-hop reachability and multipath settings; doing so destroys causal clarity.

9. Fault injection

Illustrative lab — not a real incident.

Illustrative lab — not a real incident. A primary path becomes less useful after a failure elsewhere, but an RR had previously advertised only its selected path. The symptom is path hiding and slower recovery until path diversity is deliberately provided.

The purpose of the fault is to create a recognizable symptom while preserving enough evidence to identify the exact decision point.

10. Troubleshooting

Use this evidence chain:

  1. Confirm the affected prefix.
  2. Confirm both candidate paths are present.
  3. Compare attributes in decision order.
  4. Confirm the next hop is recursively reachable.
  5. Identify the first attribute where the candidates differ.
  6. Confirm whether the result is a best-path decision or a multipath/install decision.
  7. Verify the selected route in the RIB.
  8. Perform a positive forwarding test.
  9. Perform a negative/containment test where safe.
  10. Record the smallest proven cause.

Useful IOS XE commands

show ip bgp 203.0.113.0
show ip bgp 203.0.113.0 longer-prefixes
show ip bgp summary
show ip route 203.0.113.0
show ip route <next-hop>
show ip bgp neighbors <peer> advertised-routes
show ip bgp neighbors <peer> routes

Adapt the command set to the actual feature under test. Do not claim output was observed unless the exact lab was executed.

11. Root cause

The root cause is the one-best-path advertisement model of base BGP. ADD-PATH changes the advertisement model by identifying multiple paths; Best External is a Cisco-specific mechanism for selected external-path advertisement and must not be conflated with RFC 7911.

12. Post-fix verification

Re-run the same evidence set used before the change. The comparison should demonstrate the intended decision change without unrelated routing changes.

13. Rollback

Disable the additional-path/Best-External feature used in the lab, restore the original advertisement policy and verify the receiving table returns to the baseline.

14. Production lessons

Path diversity should be introduced intentionally. More paths mean more state, memory, policy complexity and potential control-plane load. Use them to solve a specific path-hiding or convergence problem, not as a blanket default.

15. Knowledge check

  1. Question: What is the first decision point that can distinguish the two candidate paths in this lab?
  • Answer: Inspect the ordered attributes and identify the first actual difference; do not assume AS_PATH is always the first useful discriminator.
  1. Question: Why must a best-path change be verified in both the BGP table and the IP routing table?
  • Answer: A BGP path can be selected while recursive next-hop or installation conditions prevent the expected forwarding entry.
  1. Question: What configuration change would make the lab result misleading?
  • Answer: Changing multiple selection inputs simultaneously, because the engineer can no longer prove which factor caused the outcome.

Engineering notes

RFC 7911 defines ADD-PATH as a capability and Path Identifier mechanism. Cisco Best External is an implementation feature with separate rules and support boundaries. Always identify which mechanism a design actually uses.

16. Sources

  • RFC 7911; RFC 4271 — IETF/RFC Editor; standards baseline for BGP behavior relevant to this post.
  • Cisco IOS XE BGP Best External and Additional Paths documentation — Cisco official configuration/implementation documentation for IOS XE 17.x/17.18.x.
  • RFC 4456 where route-reflector behavior or Cluster List is discussed.
  • RFC 7911 where ADD-PATH behavior is discussed.

Access date: 12 August 2026

Featured Post

Day 41 — BGP Confederations: Sub-AS Design, External View and Migration

1. Opening Confederations are another way to scale BGP inside a large administrative domain. They divide the domain into member autonomous systems while presenting a single confederation identifier to external peers. They are powerful, but their operational model is more complex than simply 'using private ASNs inside.' The engineering goal is not to memorize another BGP command. It is to understand what information each speaker is allowed to propagate, what path information can be hidden, and what failure domain is created by the chosen control-plane architecture . 2. Concept and standards behavior RFC 5065 defines AS_CONFED_SEQUENCE and AS_CONFED_SET and how member-AS relationships are represented. Confederation external sessions have eBGP-like properties inside the confederation, while the confederation is presented externally as one AS. Modern guidance must also account for the fact that RFC 9774 prohibits new origination of AS_SET/AS_CONFED_SET in ordinary aggregation c...