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

RETICUX BGP Mastery — Day 023 — BGP Multipath: Turning Multiple Equal Paths into Forwarding Capacity

Learning objective

Distinguish best-path selection from multipath installation and configure controlled iBGP/eBGP multipath on IOS XE.


BGP Multipath: Turning Multiple Equal Paths into Forwarding Capacity
BGP Multipath: Turning Multiple Equal Paths into Forwarding Capacity



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

R1 receives two or more paths that qualify for multipath after the relevant BGP selection conditions are satisfied. The lab first demonstrates the default single-best-path behavior, then enables a controlled number of parallel paths and verifies that multiple paths are installed.

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

4. Topology

                         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
  maximum-paths ibgp 2
 exit-address-family

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

7. Verification before modification

Check show ip bgp 203.0.113.0 for multiple eligible paths and show ip route 203.0.113.0 for multiple installed next hops. Confirm that the paths satisfy the platform's multipath criteria rather than assuming equal prefix reachability is sufficient.

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 only the appropriate multipath command for the topology. First prove that BGP has one installed best path. Then enable two-path multipath and compare the BGP table with the IP routing table.

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. Configure two paths that look equal to the operator but differ in an attribute required for multipath. The symptom is that only one path is installed even though both paths appear in the BGP table.

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 cause is the difference between path eligibility, best-path selection and multipath installation. Multiple BGP paths can exist without all of them being installed in the forwarding table.

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

Remove maximum-paths or restore the previous value. Confirm that only the best path remains installed and that forwarding is stable.

14. Production lessons

Multipath is a capacity and resiliency feature, not simply a second best-path algorithm. Treat memory, hardware path limits, hashing behavior and convergence as part of the design.

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

Cisco documentation notes additional memory use for iBGP multipath and platform-dependent limits. Do not publish a universal maximum without checking the exact platform and release.

16. Sources

  • RFC 4271 — IETF/RFC Editor; standards baseline for BGP behavior relevant to this post.
  • Cisco IOS XE 17.x iBGP Multipath Load Sharing — 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

RETICUX BGP Mastery — Day 022 — Cluster List and Final BGP Tie-Breakers: Making the Last Decision Explainable

Learning objective

Explain cluster-list length and final neighbor-address tie-breaking, especially in route-reflector environments.


Cluster List and Final BGP Tie-Breakers: Making the Last Decision Explainable
Cluster List and Final BGP Tie-Breakers: Making the Last Decision Explainable



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

Two paths reach the same prefix through route reflectors. Earlier attributes and router identity are equal enough that the remaining route-reflector metadata becomes relevant. The lab shows how Cluster List length prevents loops and can also participate in path selection, followed by the final neighbor-address tie-breaker.

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

4. Topology

                         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
 bgp cluster-id 10.255.0.10
 address-family ipv4 unicast
  neighbor 10.0.20.2 remote-as 65100
  neighbor 10.0.20.2 activate
  neighbor 10.0.20.2 route-reflector-client
 exit-address-family

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

7. Verification before modification

Use detailed BGP output to inspect the path source and reflected metadata. Compare Cluster List length and, only when all preceding criteria remain equal, the final peer-address tie-breaker. Verify that the selected path is consistent with the documented topology.

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

Use two route-reflector paths with identical earlier attributes but different reflected metadata. Change the cluster topology only in the lab and observe how the resulting Cluster List differs. Do not alter path attributes at the same time.

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. Introduce a second RR path with a longer Cluster List and create a competing path whose final neighbor address is lower. The symptom is a surprising selection when engineers inspect only AS_PATH and LOCAL_PREF.

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 a late-stage tie-breaker, not an unexpected preference for one physical link. In RR networks, reflected-path metadata is part of the control-plane evidence and must be inspected when the common attributes do not explain the result.

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

Restore the intended cluster IDs/topology and remove the temporary peer. Verify route reflection and best-path selection before considering the lab complete.

14. Production lessons

Route reflectors solve scale but add control-plane metadata. Engineers should understand Cluster ID, Cluster List and Originator ID before diagnosing a route-reflector path that appears to violate the simple best-path sequence.

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

The final neighbor-address decision should be treated as a true last resort. It is not a traffic-engineering tool; if an operator wants a deterministic business preference, an explicit policy attribute is safer and more explainable.

16. Sources

  • RFC 4456 — IETF/RFC Editor; standards baseline for BGP behavior relevant to this post.
  • Cisco IOS XE 17.x BGP route-reflector and best-path 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

RETICUX BGP Mastery — Day 021 — BGP Router ID: The Late Tie-Breaker That Can Decide the Route

Learning objective

Understand router-ID-based tie-breaking, originator-ID interaction, deterministic selection, and safe router-ID changes.


BGP Router ID: The Late Tie-Breaker That Can Decide the Route
 BGP Router ID: The Late Tie-Breaker That Can Decide the Route



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

Three candidate paths remain equal through the earlier selection criteria. The lab then changes the BGP router ID of a peer so the final selection can be observed. A second scenario introduces route-reflection context to show why Originator ID can participate in the comparison.

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

4. Topology

                         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
 bgp router-id 10.255.0.1
 address-family ipv4 unicast
  neighbor 10.0.12.2 remote-as 65100
  neighbor 10.0.12.2 activate
  neighbor 10.0.13.2 remote-as 65100
  neighbor 10.0.13.2 activate
 exit-address-family

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

7. Verification before modification

Capture the BGP table before and after. Inspect the path source, router ID information and any Originator ID/Cluster List fields available in detailed output. Do not infer the tie-breaker solely from which path is marked best.

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

Change only the router ID on one candidate source, using a planned maintenance window in a real network. In a lab, reset the BGP process/session as required by the platform so the new identity is actually negotiated and advertised.

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. Configure two peers with otherwise equivalent paths but unintentionally choose router IDs that make a different peer win. The symptom is a best-path change after a control-plane identity change, even though route policy is unchanged.

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 cause is the late tie-breaker based on BGP identity information. In route-reflector environments, Originator ID can represent the original source and can therefore matter more directly than the RR's own identity.

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

Restore the original router ID and re-establish the affected sessions. Confirm that the intended best path returns and that no unintended cluster or session changes remain.

14. Production lessons

Router ID is an operational design input, not merely a cosmetic identifier. Make it stable, deterministic and documented. Never change it casually on a production RR or Internet-edge router.

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

A router-ID change is a control-plane event. The lab should distinguish the configuration change from the resulting BGP session reset or recalculation.

16. Sources

  • RFC 4271; RFC 4456 — IETF/RFC Editor; standards baseline for BGP behavior relevant to this post.
  • Cisco IOS XE 17.18.x BGP decision attributes — 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

RETICUX BGP Mastery — Day 020 — IGP Metric to the BGP NEXT_HOP: The Hot-Potato Decision

Learning objective

Use the IGP cost to a BGP next hop as a controlled best-path decision and troubleshoot recursive reachability.


IGP Metric to the BGP NEXT_HOP: The Hot-Potato Decision
IGP Metric to the BGP NEXT_HOP: The Hot-Potato Decision



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

R1 has two otherwise equivalent BGP paths to 203.0.113.0/24. One next hop is reached through a low-cost IGP path and the other through a higher-cost internal path. The lab removes earlier differences so the IGP metric to the BGP next hop becomes the deciding factor.

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

4. Topology

                         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 ospf 100
 network 10.0.12.0 0.0.0.3 area 0
 network 10.0.13.0 0.0.0.3 area 0
!
router bgp 65100
 address-family ipv4 unicast
  neighbor 10.0.12.2 remote-as 65100
  neighbor 10.0.12.2 activate
  neighbor 10.0.13.2 remote-as 65100
  neighbor 10.0.13.2 activate
 exit-address-family

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 the BGP paths and the recursive next-hop routes with show ip route <next-hop>. Then inspect the BGP entry. The expected evidence is a different best path without a change to LOCAL_PREF, AS_PATH, ORIGIN or MED.

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

Increase the IGP cost toward one BGP next hop while leaving BGP attributes equal. Confirm the BGP best path changes only after the IGP metric becomes the first differentiator.

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. Remove the IGP route to the selected next hop. The BGP path should become unusable or cease to be eligible for installation depending on the exact topology. The symptom is a route-selection or installation change that cannot be explained by BGP attributes alone.

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 proven cause is recursive next-hop reachability and its IGP cost. BGP may retain path information while the RIB/FIB decision depends on the ability to resolve the BGP next hop through the underlying routing topology.

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

Restore the original IGP metric or route. Verify the next hop is reachable, then confirm the expected BGP path and RIB entry return.

14. Production lessons

This is the operational meaning of hot-potato routing: once earlier policy attributes tie, the router can prefer the exit whose BGP next hop is closer according to the internal routing protocol. Troubleshoot BGP and IGP together.

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

Use a packet path or traceroute only after proving the control-plane decision. A changed IGP metric is not the same thing as a changed BGP policy.

16. Sources

  • RFC 4271 — IETF/RFC Editor; standards baseline for BGP behavior relevant to this post.
  • Cisco IOS XE 17.18.x BGP configuration guidance — 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

RETICUX BGP Mastery — Day 019 — eBGP over iBGP: Why External Routes Win After MED

Learning objective

Explain and prove the eBGP-over-iBGP decision point, including when it is reached and why it does not mean “eBGP is always better.”


eBGP over iBGP: Why External Routes Win After MED
eBGP over iBGP: Why External Routes Win After MED



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

R1 in AS 65100 receives the same /24 through an eBGP peer on R2 and an iBGP path from another internal router. Earlier attributes are held equal. The lab then changes only the session type presented to the decision process so the reader can observe the eBGP-over-iBGP step rather than treating it as a slogan.

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

4. Topology

                         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
  neighbor 10.0.12.2 remote-as 65100
  neighbor 10.0.12.2 activate
  neighbor 10.0.21.2 remote-as 65110
  neighbor 10.0.21.2 activate
 exit-address-family

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

7. Verification before modification

Use show ip bgp 203.0.113.0 and inspect the path markers and attributes. Confirm the eBGP candidate is the selected path only after earlier attributes are equal. Verify show ip route 203.0.113.0 for installation.

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

Remove the local preference/AS_PATH/MED differences that would otherwise decide the route first. Then present equal candidates where one is eBGP and one is iBGP. The eBGP path should win at the eBGP-over-iBGP decision point.

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. Apply a higher LOCAL_PREF to the iBGP path while leaving the eBGP path unchanged. The expected symptom is that the iBGP path remains best, proving that eBGP preference is not an absolute first-place rule; it occurs only after earlier criteria tie.

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 not “BGP prefers eBGP.” The precise cause is that the candidates reached the eBGP-versus-iBGP comparison with earlier attributes equal. When LOCAL_PREF differs, the earlier LOCAL_PREF decision wins instead.

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

Remove the temporary LOCAL_PREF policy and restore the original equal-attribute state. Recheck the selected path and forwarding entry before closing the change.

14. Production lessons

Treat “eBGP beats iBGP” as an ordered-algorithm statement, not as a universal override. In production, document which earlier attribute is intentionally controlling the route. This makes troubleshooting far faster than starting from session type alone.

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

This day is deliberately a bridge between attribute-based selection and topology-based selection. It should precede IGP-cost and tie-breaker topics.

16. Sources

  • RFC 4271 — IETF/RFC Editor; standards baseline for BGP behavior relevant to this post.
  • Cisco IOS XE 17.x BGP Decision Attributes — 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

Day 18 — BGP MED: Same-AS Comparison, Deterministic MED and `always-compare-med`

Learning objective

Use MED to express a preferred entry point from one neighboring AS, explain Cisco's normal MED comparison scope, distinguish bgp deterministic-med from bgp always-compare-med, and troubleshoot a MED inversion without relying on arrival-order assumptions.


BGP MED: Same-AS Comparison, Deterministic MED and `always-compare-med`
BGP MED: Same-AS Comparison, Deterministic MED and `always-compare-med`



1. Opening — MED is intentionally weaker than many engineers expect

An upstream AS connects to your network at two locations. It advertises the same prefix over both links and wants to tell you which entry point it prefers you to use when sending traffic toward that AS.

That is the classic role of the Multi-Exit Discriminator (MED).

Lower MED is preferred.

But MED is not a universal cross-provider metric. RFC and operational guidance treat it as a relatively weak hint, and Cisco normally limits comparison so MEDs learned from different neighboring ASes are not automatically compared as if they were a common metric.

This scope is the source of many troubleshooting mistakes.


2. What MED communicates

MED lets one AS indicate a preferred entry point to another AS when multiple interconnections exist.

Conceptually:

Upstream AS65010
   Link A MED 50  ---->
                       Enterprise AS65020
   Link B MED 150 ---->

If all earlier path-selection attributes tie and both advertisements are treated as comparable for MED, the lower value 50 is preferred.

MED is an optional non-transitive attribute in the base BGP attribute model. Its policy meaning is generally local between directly related ASes rather than something expected to cross the Internet unchanged.


3. Cisco best-path position

Cisco's documented sequence evaluates MED after earlier attributes such as:

  • Weight
  • LOCAL_PREF
  • local origination
  • AS_PATH length
  • ORIGIN

Therefore a lower MED does not rescue a path that already lost to a higher LOCAL_PREF.

This is why MED should not be explained as “BGP's metric” without qualification.


4. Normal comparison scope

A critical Cisco behavior is that MED is normally compared among paths received from the same neighboring AS under the documented best-path rules.

If Path A comes from AS65010 with MED 10 and Path B comes from AS65020 with MED 200, the router does not simply conclude that 10 is better than 200 in the same way it would for two paths from AS65010.

Cisco provides bgp always-compare-med when an operator intentionally wants MED compared across different neighboring ASes.

That command materially changes policy semantics and must not be enabled casually.


5. bgp deterministic-med is different

bgp deterministic-med does not mean “compare MED across all ASes.”

Its purpose is to make MED comparison deterministic among paths from the same neighboring AS by grouping/comparing those paths in a consistent way, rather than allowing path arrival order to influence which comparisons occur.

Cisco IOS command documentation states that deterministic MED comparison is not enabled by default in classic IOS behavior; verify the exact target platform/release before treating a default as universal. IOS XR and other implementations can differ.

The key distinction:

  • bgp deterministic-med → consistent same-neighbor-AS MED comparison ordering.
  • bgp always-compare-med → compare MED across paths from different neighboring ASes.

They solve different problems.


6. Scenario — Twin Gate MED

Illustrative lab — not a real incident.

Topology

         U1                      U2
       AS65010                 AS65010
       MED 50                  MED 150
          \                     /
           \ eBGP         eBGP /
            \                 /
                 E
              AS65020

Both U1 and U2 belong to the same upstream AS65010 and advertise 203.0.113.0/24 to enterprise router E.

Objective

  • Keep Weight, LOCAL_PREF, AS_PATH length and ORIGIN equal.
  • U1 advertises MED 50.
  • U2 advertises MED 150.
  • E prefers the lower MED path through U1.
  • Inject an incorrect MED 250 on U1 and observe the path move to U2.
  • Explain how deterministic MED matters when more same-AS paths and update-order interactions exist.

7. Prerequisites

  • Three routers.
  • U1 and U2 configured with the same ASN 65010 in the closed lab.
  • Separate directly connected eBGP sessions to E AS65020.
  • Both upstream routers originate or learn the same lab prefix with equal earlier attributes.
  • Reachable next hops.

Using two separate routers with one ASN is normal as a lab representation of a multi-router autonomous system, but the underlay between U1 and U2 is omitted because the focus is external MED behavior.


8. Topic-specific configuration excerpt

U1 — advertise MED 50

route-map MED-TO-E permit 10
 set metric 50
!
router bgp 65010
 neighbor 192.0.2.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 192.0.2.2 activate
  neighbor 192.0.2.2 route-map MED-TO-E out
 exit-address-family

U2 — advertise MED 150

route-map MED-TO-E permit 10
 set metric 150
!
router bgp 65010
 neighbor 198.51.100.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 198.51.100.2 activate
  neighbor 198.51.100.2 route-map MED-TO-E out
 exit-address-family

E — AS65020

router bgp 65020
 neighbor 192.0.2.1 remote-as 65010
 neighbor 198.51.100.1 remote-as 65010
 address-family ipv4 unicast
  neighbor 192.0.2.1 activate
  neighbor 198.51.100.1 activate
 exit-address-family

The companion lab files include complete interfaces and service-prefix origination.


9. Verification before modification

On E:

show ip bgp 203.0.113.0
show ip route 203.0.113.0
show ip bgp neighbors 192.0.2.1 routes
show ip bgp neighbors 198.51.100.1 routes

Confirm:

  • both paths are valid;
  • both next hops resolve;
  • Weight and LOCAL_PREF tie;
  • AS_PATH length and ORIGIN tie;
  • both paths were learned from the same neighboring AS65010;
  • MED differs: 50 versus 150.

Expected best path: U1 with MED 50, subject to the verified equality of all earlier criteria.


10. Controlled modification — invert U1's MED

On U1:

route-map MED-TO-E permit 10
 set metric 250

After a safe outbound refresh, E should receive:

  • U1 MED 250
  • U2 MED 150

If earlier attributes still tie, U2 becomes preferred because 150 is lower.


11. Fault injection

Illustrative lab — not a real incident.

Lab name

Twin Gate MED Inversion

Fault

A maintenance template changes U1's intended MED from 50 to 250.

Symptoms

  • both eBGP sessions remain Established;
  • all prefixes remain present;
  • traffic exits through the secondary interconnection;
  • no route withdrawal occurs;
  • the reason is visible only in path-attribute comparison.

This is a policy incident, not a session incident.


12. Troubleshooting sequence

  1. Confirm the affected prefix and expected preferred interconnection.
  2. Verify both eBGP sessions.
  3. Compare Weight and LOCAL_PREF.
  4. Compare AS_PATH length.
  5. Compare ORIGIN.
  6. Confirm the candidate paths came from the same neighboring AS for normal MED comparison.
  7. Read the MED values.
  8. Inspect outbound set metric policy on U1 and U2.
  9. Check whether E has bgp always-compare-med or bgp deterministic-med configured.
  10. Correct the policy and verify stable selection after refresh.

13. Different neighboring ASes: why always-compare-med matters

Now imagine U1 is AS65010 and U2 is AS65020.

The numeric values 50 and 150 are no longer automatically treated as a common cross-provider metric under normal Cisco behavior.

If the operator enables:

router bgp 65030
 bgp always-compare-med

Cisco can compare MED across different neighboring ASes.

That is a major policy change. It should be introduced only with a network-wide design rationale, consistency review and rollback plan.


14. Why deterministic MED exists

In networks with several paths from the same neighboring AS, the sequence in which routes arrive can interact with pairwise best-path comparisons. bgp deterministic-med groups same-AS paths so MED comparisons are performed in a deterministic order.

This becomes more important with:

  • multiple border routers;
  • route reflectors;
  • many paths from the same provider AS;
  • policy changes that cause routes to be reprocessed in different orders.

RFC 4451 discusses MED deployment considerations and the kinds of unexpected behavior that can appear in complex topologies.

A later route-reflector incident lab will revisit MED oscillation and path hiding at larger scale.


15. Root cause and correction

Root cause

U1 advertised a higher MED than intended, causing E to prefer U2 after all earlier criteria tied.

Correction

Restore the intended value:

route-map MED-TO-E permit 10
 set metric 50

Why it works

Both paths originate from the same neighboring AS and are equal through earlier selection stages, so the lower MED path through U1 becomes preferred again.


16. Post-fix verification

On E:

show ip bgp 203.0.113.0
show ip route 203.0.113.0
show running-config | include bgp.*med

On U1/U2:

show route-map MED-TO-E
show ip bgp neighbors <E-peer> advertised-routes

If the lab includes forwarding hosts, verify the actual path after the control-plane change.


17. Rollback

To remove MED rewriting from U1:

router bgp 65010
 address-family ipv4 unicast
  no neighbor 192.0.2.2 route-map MED-TO-E out

If bgp always-compare-med or bgp deterministic-med was introduced as part of an experiment, remove only after verifying the original behavior and network-wide dependency.

Preserve the pre-change route table because MED incidents can be difficult to reconstruct after route refreshes.


18. Production lessons

Protocol lesson

MED is a hint about a preferred entry point, not a universal Internet cost metric.

Selection lesson

Lower MED is preferred only after earlier best-path criteria tie and the paths are eligible for MED comparison.

Scope lesson

Normal Cisco behavior compares MED within the appropriate same-neighbor-AS context; always-compare-med expands that scope.

Determinism lesson

deterministic-med addresses comparison ordering among same-AS paths; it does not mean the same thing as always-compare-med.

Change-management lesson

MED defaults and deterministic behavior differ across platforms. Never assume IOS XE, IOS XR and NX-OS have identical defaults without release-specific documentation.


19. Knowledge check

Q1

Which MED is preferred, 50 or 150, when the paths are comparable and all earlier attributes tie?

Answer: 50, because lower MED is preferred.

Q2

Does bgp deterministic-med cause MED values from different neighboring ASes to be compared?

Answer: No. It makes same-neighbor-AS MED comparison deterministic. bgp always-compare-med is the Cisco feature that expands MED comparison across different neighboring ASes.

Q3

Why can a path with lower MED still lose?

Answer: An earlier best-path criterion such as higher Weight, higher LOCAL_PREF, local origination, shorter AS_PATH or better ORIGIN can decide first.


20. Sources

  1. RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)* — MULTI_EXIT_DISC and Decision Process.
  2. RFC 4451 — *BGP MULTI_EXIT_DISC (MED) Considerations* — MED deployment and comparison considerations.
  3. Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.18.x: Configuring BGP* — MED in the Cisco best-path sequence.
  4. Cisco — *Connecting to a Service Provider Using External BGP, IOS XE 17.x* — setting MED with set metric and bgp always-compare-med guidance.
  5. Cisco — *Use Multi-Exit Discriminator to Select Best Path for BGP* — bgp deterministic-med behavior.
  6. Cisco — *Cisco IOS IP Routing: BGP Command Reference* — bgp deterministic-med default and command semantics.

Accessed: 2026-08-11.


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...