Provider-Assigned NAT Breaks During ISP Failover
R1 is the only edge router for an office of 4,000 users with internal network 10.20.0.0/16. It has two uplinks: ISP-A on GigabitEthernet0/0 (203.0.113.2/30) and ISP-B on GigabitEthernet0/1 (198.51.100.2/30). Both providers filter inbound packets whose source address is outside their own allocation, and ISP-B additionally drops RFC 1918 sources at its edge. No BGP is used; a floating static default route points at ISP-B with administrative distance 250, and an IP SLA ICMP echo to 203.0.113.1 with a track object withdraws the primary default route.
NAT is configured as ip nat inside source route-map TO-A interface GigabitEthernet0/0 overload, with route-map TO-A containing match interface GigabitEthernet0/0. During a maintenance window the ISP-A circuit goes down. The default route fails over to ISP-B within 10 seconds and the router itself can ping 8.8.8.8, but every PC in the office loses Internet access until ISP-A is restored. show ip nat translations is empty for the affected flows, and show ip nat statistics shows no hits on the TO-A rule.
1. Explain why PC traffic fails while traffic originated by the router itself still works.
Read the worked answer
NAT is applied after the route lookup, and a route-map-driven NAT rule is evaluated against the egress interface the routing table chose for that flow. When ISP-A is up, the default route points at GigabitEthernet0/0, match interface GigabitEthernet0/0 succeeds, and the flow is translated to the interface address before it is encapsulated.
When the floating static takes over, the egress interface for new flows becomes GigabitEthernet0/1. The route-map no longer matches, so no ip nat inside source rule exists for that flow. The packet is forwarded untranslated with its 10.20.x.x source address and is dropped in ISP-B's edge for having an RFC 1918 source. There is no error, no translation entry, and no hit counter increment, which is exactly what show ip nat statistics shows.
Router-originated traffic is unaffected because traffic generated by the router itself is never NAT translated through an inside-source rule unless it is explicitly sourced from an inside interface. That is why the ICMP echo to 8.8.8.8 succeeds and misleads the first responder into thinking the circuit is fine. Existing translations also remain in the table pointing at the dead interface until they age out, which can make the outage look partial.
2. Give the corrected NAT design and describe how to make the failover clean rather than merely functional.
Read the worked answer
Add a second, independent rule: ip nat inside source route-map TO-B interface GigabitEthernet0/1 overload with route-map TO-B containing a single match interface GigabitEthernet0/1. Two match statements inside one route-map entry would be ANDed and could never both be true, so the two exits must be separate route-maps, not two lines in one. Confirm that both WAN interfaces are ip nat outside and the LAN is ip nat inside; on this platform you cannot have two outside interfaces in a single inside-source rule, which is why two rules are required rather than one shared pool.
Make the failover clean. Existing translations still reference the ISP-A address after the switch and will drop return traffic, so clear the table once the route has converged, or shorten the translation timeouts. Verify with show ip nat statistics that both rules show hits, and show route-map to confirm which entry matched. Consider whether the address change also breaks anything that pins the old public address, such as published DNS records or IPsec peers.
A NAT pool of ISP-A provider-assigned addresses will not help during failover: ISP-B filters any source outside its own allocation regardless of how the pool is built, so only the ISP-B interface address or an ISP-B-assigned block will pass.
3. The business wants failover to be transparent to users. Which parts of this design still cause visible interruption, and what would you change?
Read the worked answer
Three separate timers and state machines cause the visible break, and fixing NAT only addresses one of them.
First, failure detection: the IP SLA probe plus track object must expire before anything happens, so the 10-second convergence is a design choice. Tighten the probe interval and threshold, or use object tracking combined with a BFD session to the ISP if the provider supports it, so the switch happens in a couple of seconds.
Second, address translation: every active flow is translated to the ISP-A address, so even a perfect switch resets all TCP sessions, because the reply path to the old public address no longer exists. Nothing in this design can preserve sessions across providers; only a provider-independent address block announced by BGP would. Set expectations accordingly, and shorten the translation timeouts so stale entries do not blackhole new flows.
Third, the return path: with floating statics there is no inbound redundancy at all, so any service published on 198.51.100.0/24 is unreachable from the Internet during the outage if that block belonged to ISP-A. If the business truly needs transparent failover, the correct change is a PI address block, BGP with both providers, and NAT applied per egress interface as designed here.