RETICUX BGP Mastery — Day 36 --- Dual-Provider Traffic-Engineering Capstone

at

1. Opening

A production multihoming design must work as a system. Outbound and inbound engineering are different problems, and a design that optimizes both during steady state can fail badly when one provider, one prefix or one policy condition disappears.

The operational objective is not simply to make BGP choose a route. It is to make the intended behavior predictable during the normal state, degraded state, and rollback state.


Dual-Provider Traffic-Engineering Capstone
Dual-Provider Traffic-Engineering Capstone


2. Concept and standards behavior

The capstone combines previously isolated mechanisms. LOCAL_PREF controls enterprise outbound choice. Export policy controls what each provider can learn. A provider community is treated as a provider-specific signal. Conditional advertisement supplies a backup route only when a defined BGP condition changes. RFC 8212's explicit-policy principle is used as the safety mindset at every external boundary.

BGP remains a policy protocol. RFC 4271 provides the protocol framework, while several practical traffic-engineering controls are Cisco or operator-policy mechanisms. Evaluate each design at three layers: protocol behavior, IOS XE implementation, and neighboring-AS policy.

Separate route eligibility, route selection, and route export. Eligibility asks whether a path is usable. Selection determines the local best path. Export policy determines what a neighbor is permitted to learn.

3. Scenario

AS 65010 is dual-homed to ISP-A AS 65020 and ISP-B AS 65030. The enterprise service prefix is 203.0.113.0/24. Transit links use 192.0.2.0/30 and 198.51.100.0/30.

Success criteria 1. Primary and backup behavior is explicit. 2. No route is exported merely because it exists locally. 3. Failure behavior is observable in BGP and advertised-route evidence. 4. Rollback is independent of session redesign. 5. A negative test proves unintended advertisement is absent.

4. Topology

Dual-Provider Traffic-Engineering Capstone
Dual-Provider Traffic-Engineering Capstone

ISP-A AS65020 --- 192.0.2.0/30 --- EDGE1/AS65010
                                      |
                               203.0.113.0/24
                                      |
ISP-B AS65030 --- 198.51.100.0/30 --- EDGE2/AS65010

5. Prerequisites

  • IOS XE 17.18.x documentation baseline.
  • IPv4 unicast activated for both eBGP peers.
  • Service prefix valid for origination.
  • Independent management access.
  • Pre-change capture of BGP state and advertised routes.

6. Baseline configuration

Topic-specific configuration excerpt --- not a complete device configuration.

ip prefix-list PL-SERVICE permit 203.0.113.0/24

route-map FROM-ISP-A permit 10
 set local-preference 200
route-map FROM-ISP-B permit 10
 set local-preference 150

route-map EXPORT-SERVICE permit 10
 match ip address prefix-list PL-SERVICE

router bgp 65010
 address-family ipv4
  neighbor 192.0.2.1 route-map FROM-ISP-A in
  neighbor 198.51.100.1 route-map FROM-ISP-B in
  neighbor 192.0.2.1 route-map EXPORT-SERVICE out
  ! Add provider-specific community and conditional backup policy
  ! only after validating the provider contract and exact lab syntax.
 exit-address-family

7. Verification before modification

show bgp ipv4 unicast
show bgp ipv4 unicast 203.0.113.0/24
show bgp ipv4 unicast neighbors
show bgp ipv4 unicast neighbors 192.0.2.1 advertised-routes
show bgp ipv4 unicast neighbors 198.51.100.1 advertised-routes
show route-map
show ip prefix-list

The question is not whether the policy object exists; it is whether the intended route is selected, matched and actually exported to the intended neighbor.

8. Controlled modification

Stage the change: first explicit import/export filters, then outbound LOCAL_PREF, then inbound TE signal, then conditional backup behavior. Validate each stage before adding the next.

Predict Adj-RIB-Out behavior before applying the change. Re-evaluate policy using the least disruptive supported mechanism.

9. Fault injection

Illustrative lab — not a real incident.

Inject three faults separately: ISP-A session loss, loss of only the primary condition route while the session stays up, and removal of community transmission. Each should produce a different observable symptom.

Change one variable only, capture the changed state, and compare it with the baseline.

10. Troubleshooting

  1. Confirm affected prefix and traffic direction.
  2. Confirm eBGP sessions are Established.
  3. Confirm local route eligibility/origination.
  4. Inspect selected BGP route.
  5. Inspect match objects.
  6. Inspect route-map sequence and implicit deny.
  7. Inspect advertised routes per provider.
  8. Confirm policy direction.
  9. Determine whether route refresh is required.
  10. Run positive traffic test.
  11. Run negative/containment test.
  12. Correct the smallest proven cause and repeat the same evidence set.

11. Root cause and correction

A capstone failure is usually caused by interacting controls being changed together. Restore the last known-good stage, prove baseline behavior, then reintroduce one control at a time.

12. Post-fix verification

Verify session state, route acceptance, selected path, exported attributes, advertised routes, forwarding and the negative test. Local advertisement does not prove remote selection.

13. Rollback

Revert only the new policy action, re-evaluate policy with the least disruptive supported method, and confirm both providers return to baseline. Roll back immediately for loss of all reachability, unintended transit, unapproved deaggregation or export outside the approved prefix set.

14. Production lessons

The strongest multihoming design is not the one with the most attributes. It is the one whose normal, partial-failure, total-failure and rollback states are all explicit and testable.

15. Knowledge check

map?

policy?

leaking?

  1. Why is advertised-routes stronger evidence than displaying a route
  2. Which parts are controlled locally and which depend on upstream
  3. What negative test proves the restricted/backup advertisement is not

Answers

inbound selection are remote policy.

routes in the healthy state.

  1. It validates resulting per-neighbor export state.
  2. Local selection/export are local; remote LOCAL_PREF, propagation and
  3. Verify the protected prefix is absent from the neighbor's advertised

16. Sources

  • RFC 4271
  • RFC 1997
  • RFC 8212
  • Cisco IOS XE 17.x --- BGP policy and conditional advertisement
Labels:

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