Day 35 --- Hot-Potato vs Cold-Potato Routing

1. Opening

Hot-potato routing hands traffic to another AS at the nearest acceptable exit. Cold-potato routing intentionally carries traffic farther inside the local network before handoff. Neither is a BGP message type; both emerge from policy, topology and the interaction between BGP and the IGP.

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.

#ccna #ccnp #cisco #network #engineer #BGP

Hot-Potato vs Cold-Potato Routing

2. Concept and standards behavior

When earlier BGP attributes tie, IGP cost to the BGP NEXT_HOP can influence which exit is selected. Operators can override that outcome using LOCAL_PREF or other policy. The key design question is whether the AS wants to minimize its own transport cost or control the egress location for performance, economics or service reasons.

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

Hot-Potato vs Cold-Potato Routing

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.

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

! IGP configuration is topology-specific.
! Verify recursive cost to each BGP NEXT_HOP before changing BGP policy.

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

First allow equal higher-priority BGP attributes so the lower IGP cost wins. Then set a higher LOCAL_PREF on the farther exit and verify that policy overrides hot-potato behavior.

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.

Increase the IGP cost to the currently selected next hop without changing LOCAL_PREF. If higher BGP policy already fixes the exit, the traffic should not move merely because the IGP cost changed.

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

The failure is troubleshooting only the IGP when a higher-priority BGP attribute already determines the exit. Correct by walking the best-path decision in order.

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

Hot versus cold potato is an architecture decision with cost, latency and failure-domain consequences. Document which layer is intended to own the exit choice.

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 --- BGP decision process
• Cisco IOS XE 17.x --- BGP best-path/next-hop behavior