RETICUX BGP Mastery - BGP Extended Communities: Structured Policy Metadata — Day 26

at

BGP Extended Communities: Structured Policy Metadata

Opening

Standard communities are useful, but many production applications need structure: a type, an administrator field and semantics that can survive across routing domains. Extended communities provide that structure.


BGP Extended Communities: Structured Policy Metadata

BGP Extended Communities: Structured Policy Metadata



Learning objectives

  • Explain the protocol mechanism precisely.
  • Distinguish standards behavior from Cisco implementation behavior.
  • Build a deterministic policy with explicit match and action logic.
  • Verify both received and advertised routing information.
  • Diagnose the failure mode and roll back safely.

Concept and standards behavior

Extended Communities add structure and a larger application space to the original community attribute. RFC 4360 defines the attribute and its type structure; extended communities are foundational to MPLS VPN route targets, site-of-origin policy and many other BGP applications. This post separates the generic attribute from later VPN-specific use.

Implementation boundary: the standard defines the wire attribute and semantics; Cisco IOS XE syntax, defaults and verification commands must be checked against the selected 17.18.x platform documentation before claiming exact execution behavior.

Engineering scenario

The lab uses three documentation-safe routers: EDGE-A (AS 65001), TRANSIT-A (AS 65002) and EDGE-B (AS 65003). EDGE-A originates 192.0.2.0/24 and 198.51.100.0/24; EDGE-B provides a second policy domain. Loopbacks and point-to-point links use TEST-NET values. No production prefixes, credentials or real ASNs are used.

The engineering requirement is to express policy using reusable metadata and precise filters, then prove that the resulting Adj-RIB-In, best path and Adj-RIB-Out behavior match the intended policy.

Topology


BGP Extended Communities: Structured Policy Metadata

        AS 65002 TRANSIT-A
       /                   \
  AS 65001 EDGE-A ---- AS 65003 EDGE-B
  192.0.2.0/24
  198.51.100.0/24

Prerequisites

  • Cisco IOS XE 17.18.x or a release with equivalent documented commands.
  • Working eBGP sessions.
  • Reachability between BGP next hops.
  • Address family ipv4 unicast enabled.
  • Console/out-of-band access for rollback.

Baseline configuration

The lab uses a minimal BGP baseline and then introduces only the policy feature under study. Representative configuration is shown below; exact interface names may differ by image.

router bgp 65001
 bgp router-id 10.255.1.1
 neighbor 192.0.2.2 remote-as 65002
 address-family ipv4
  neighbor 192.0.2.2 activate
  network 192.0.2.0 mask 255.255.255.0
 exit-address-family

Verification before modification

Use evidence rather than assumptions:

show ip bgp summary
show ip bgp
show ip bgp neighbors 192.0.2.2 advertised-routes
show ip bgp neighbors 192.0.2.2 received-routes
show ip bgp 192.0.2.0/24

Record the session state, prefix counts, selected path, relevant attributes and advertisement state before changing policy.

Controlled modification

Introduce an extended community and show how it is matched separately from the standard COMMUNITIES attribute. Explain why route-target and site-of-origin are application-specific uses and defer full VPN route-target architecture to the later MPLS L3VPN module.

Fault injection

Illustrative lab — not a real incident. Inject one deliberate policy error: either omit the required send-community capability, invert a permit/deny condition, or apply the policy in the wrong direction. The fault must be introduced independently from the baseline so the learner can prove causality.

Expected symptoms include a route missing a tag, a prefix unexpectedly accepted or rejected, an attribute not being propagated, or an advertisement disappearing from Adj-RIB-Out.

Troubleshooting

  1. Define the affected prefix and peer.
  2. Confirm the BGP session is Established.
  3. Inspect the route in Adj-RIB-In.
  4. Inspect the relevant attribute/community state.
  5. Verify the policy match condition.
  6. Verify the policy direction.
  7. Inspect the selected best path.
  8. Inspect Adj-RIB-Out toward the affected neighbor.
  9. Check whether the capability required for attribute exchange is enabled.
  10. Apply the smallest correction and re-check both control-plane and forwarding results.

Root cause

The smallest proven root cause should be stated only after the evidence chain identifies where the expected policy state diverged from the observed state. Do not blame “BGP” when the evidence points to a policy predicate, attribute propagation rule, address-family activation or missing capability.

Post-fix verification

Verify the peer, prefix, attribute state, selected path, advertised path and traffic behavior. For policy-only changes, also verify that the session did not flap unnecessarily.

Rollback

Remove the new policy or restore the previous sequence, then re-verify the same evidence points used before the change. If the change affects an Internet edge, use out-of-band access and a predefined rollback trigger.

Production lessons

  • Treat BGP policy as code: explicit inputs, deterministic predicates and observable outputs.
  • Prefer reusable metadata over repeated prefix-specific rules where the architecture supports it.
  • Keep import and export intent separate.
  • Verify both sides of a policy boundary.
  • Never assume an attribute is being exchanged merely because it exists locally.

Knowledge check

  1. What is the difference between a route tag and a route decision attribute?
  2. What evidence proves that an outbound policy actually changed Adj-RIB-Out?
  3. Why is a policy change safer when it can be refreshed without tearing down the BGP session?

Answers

  1. A tag such as a community carries policy metadata; a decision attribute such as LOCAL_PREF directly influences selection.
  2. The neighbor’s advertised-route view, combined with the route’s attribute state, proves the outbound result.
  3. Avoiding an unnecessary session reset reduces convergence disruption and preserves established control-plane state.

Sources

  • RFC 4360: https://www.rfc-editor.org/rfc/rfc4360
  • Cisco communities: https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ip-routing/b-ip-routing/m_irg-external-sp-0.html

Publishing assets

  • Excerpt: Standard communities are useful, but many production applications need structure: a type, an administrator field and semantics that can survive across routing d
  • Social caption: BGP policy becomes safer when intent is explicit, metadata is reusable and every change is observable.
  • Hashtags: #BGP #Networking #Routing #Cisco #NetworkEngineering #NetOps
  • Diagram alt text: Day 26: BGP Extended Communities: Structured Policy Metadata shown across a three-router BGP policy topology.
Read more
Labels:

RETICUX BGP Mastery — Day 25 - BGP Communities: Turning Routes into Policy Signals

at

BGP Communities: Turning Routes into Policy Signals

A BGP route can be perfectly valid and still be the wrong route for a business. The missing piece is often policy metadata: a small label that tells downstream routers how the route should be treated.

Learning objectives

  • Explain the protocol mechanism precisely.
  • Distinguish standards behavior from Cisco implementation behavior.
  • Build a deterministic policy with explicit match and action logic.
  • Verify both received and advertised routing information.
  • Diagnose the failure mode and roll back safely.

Concept and standards behavior

Communities let operators attach reusable policy metadata to routes so policy can be expressed as intent instead of repeated prefix lists. RFC 1997 defines the original COMMUNITIES attribute and well-known values such as NO_EXPORT and NO_ADVERTISE. Cisco IOS XE requires explicit community exchange with neighbor send-community and supports community lists and route maps for matching and setting communities.

Implementation boundary: the standard defines the wire attribute and semantics; Cisco IOS XE syntax, defaults and verification commands must be checked against the selected 17.18.x platform documentation before claiming exact execution behavior.


BGP Communities: Turning Routes into Policy Signals
BGP Communities: Turning Routes into Policy Signals


Engineering scenario

The lab uses three documentation-safe routers: EDGE-A (AS 65001), TRANSIT-A (AS 65002) and EDGE-B (AS 65003). EDGE-A originates 192.0.2.0/24 and 198.51.100.0/24; EDGE-B provides a second policy domain. Loopbacks and point-to-point links use TEST-NET values. No production prefixes, credentials or real ASNs are used.

The engineering requirement is to express policy using reusable metadata and precise filters, then prove that the resulting Adj-RIB-In, best path and Adj-RIB-Out behavior match the intended policy.

Topology


BGP Communities: Turning Routes into Policy Signals
BGP Communities: Turning Routes into Policy Signals

        AS 65002 TRANSIT-A
       /                   \
  AS 65001 EDGE-A ---- AS 65003 EDGE-B
  192.0.2.0/24
  198.51.100.0/24

Prerequisites

  • Cisco IOS XE 17.18.x or a release with equivalent documented commands.
  • Working eBGP sessions.
  • Reachability between BGP next hops.
  • Address family ipv4 unicast enabled.
  • Console/out-of-band access for rollback.

Baseline configuration

The lab uses a minimal BGP baseline and then introduces only the policy feature under study. Representative configuration is shown below; exact interface names may differ by image.

router bgp 65001
 bgp router-id 10.255.1.1
 neighbor 192.0.2.2 remote-as 65002
 address-family ipv4
  neighbor 192.0.2.2 activate
  network 192.0.2.0 mask 255.255.255.0
 exit-address-family

Verification before modification

Use evidence rather than assumptions:

show ip bgp summary
show ip bgp
show ip bgp neighbors 192.0.2.2 advertised-routes
show ip bgp neighbors 192.0.2.2 received-routes
show ip bgp 192.0.2.0/24

Record the session state, prefix counts, selected path, relevant attributes and advertisement state before changing policy.

Controlled modification

Create a named community list for a “preferred-transit” tag and apply it with a route map. Demonstrate the difference between replacing the community set and adding a community with additive. Enable neighbor send-community and prove the tag appears on the receiving side.

Fault injection

Illustrative lab — not a real incident. Inject one deliberate policy error: either omit the required send-community capability, invert a permit/deny condition, or apply the policy in the wrong direction. The fault must be introduced independently from the baseline so the learner can prove causality.

Expected symptoms include a route missing a tag, a prefix unexpectedly accepted or rejected, an attribute not being propagated, or an advertisement disappearing from Adj-RIB-Out.

Troubleshooting

  1. Define the affected prefix and peer.
  2. Confirm the BGP session is Established.
  3. Inspect the route in Adj-RIB-In.
  4. Inspect the relevant attribute/community state.
  5. Verify the policy match condition.
  6. Verify the policy direction.
  7. Inspect the selected best path.
  8. Inspect Adj-RIB-Out toward the affected neighbor.
  9. Check whether the capability required for attribute exchange is enabled.
  10. Apply the smallest correction and re-check both control-plane and forwarding results.

Root cause

The smallest proven root cause should be stated only after the evidence chain identifies where the expected policy state diverged from the observed state. Do not blame “BGP” when the evidence points to a policy predicate, attribute propagation rule, address-family activation or missing capability.

Post-fix verification

Verify the peer, prefix, attribute state, selected path, advertised path and traffic behavior. For policy-only changes, also verify that the session did not flap unnecessarily.

Rollback

Remove the new policy or restore the previous sequence, then re-verify the same evidence points used before the change. If the change affects an Internet edge, use out-of-band access and a predefined rollback trigger.

Production lessons

  • Treat BGP policy as code: explicit inputs, deterministic predicates and observable outputs.
  • Prefer reusable metadata over repeated prefix-specific rules where the architecture supports it.
  • Keep import and export intent separate.
  • Verify both sides of a policy boundary.
  • Never assume an attribute is being exchanged merely because it exists locally.

Knowledge check

  1. What is the difference between a route tag and a route decision attribute?
  2. What evidence proves that an outbound policy actually changed Adj-RIB-Out?
  3. Why is a policy change safer when it can be refreshed without tearing down the BGP session?

Answers

  1. A tag such as a community carries policy metadata; a decision attribute such as LOCAL_PREF directly influences selection.
  2. The neighbor’s advertised-route view, combined with the route’s attribute state, proves the outbound result.
  3. Avoiding an unnecessary session reset reduces convergence disruption and preserves established control-plane state.

Sources

  • RFC 1997: https://www.rfc-editor.org/rfc/rfc1997
  • RFC 8642: https://www.rfc-editor.org/rfc/rfc8642
  • Cisco communities: https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ip-routing/b-ip-routing/m_irg-external-sp-0.html
  • Cisco command reference: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr-book/bgp-c1.html

Publishing assets

  • Excerpt: A BGP route can be perfectly valid and still be the wrong route for a business. The missing piece is often policy metadata: a small label that tells downstream
  • Social caption: BGP policy becomes safer when intent is explicit, metadata is reusable and every change is observable.
  • Hashtags: #BGP #Networking #Routing #Cisco #NetworkEngineering #NetOps
  • Diagram alt text: Day 25: BGP Communities: Turning Routes into Policy Signals shown across a three-router BGP policy topology.
Read more
Labels:

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

at

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

Read more
Labels:

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

at

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

Read more
Labels:

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

at

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

Read more
Labels:

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

at

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

Read more
Labels:

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

at

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

Read more
Labels:
Subscribe to: Posts (Atom)

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