How to configure NAT overload PAT with route-map on Catalyst 9200

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

Port Address Translation with a route-map is what I reach for when a customer has more than one upstream and wants traffic NAT-ed to a specific public IP based on source subnet. Standard PAT with an ACL works until you add a second ISP. Then you need the route-map to bind translation to the correct egress interface. I ran into this last month at a Redington warehouse in Chennai where the primary 1 Gbps ACT fibre and the backup 200 Mbps Airtel link had to keep their NAT pools separate. On Catalyst 9200, the config below has held up through three failovers.

Pre-requisites

• Catalyst 9200 running IOS XE 17.9.4a or later. On older 16.x trains, route-map NAT behaviour shifted twice: best to upgrade before you debug.
• Two ISP uplinks already in place. Each with a public IP and a default route weighted or tagged for selection.
• An inside ACL that matches the source subnets you want translated. Standard ACL is fine here. Don't use a named extended ACL unless you actually need port matching.
• SmartNet (₹85,000-2 lakh per year depending on the SKU), useful when the route-map NAT misbehaves and you need TAC to look at show platform software ip nat translations.
• Console access. PAT changes will drop active sessions when the translation table flushes.

Step-by-step on Catalyst 9200

1. Identify your inside source ACL. access-list 10 permit 192.168.10.0 0.0.0.255. This is the subnet that will be PAT-ed.
2. Build the route-map. route-map RM-NAT-ISP1 permit 10, then match ip address 10, then match interface GigabitEthernet0/0/0. The interface match is what binds this NAT pool to ISP1's egress.
3. Apply the NAT statement. ip nat inside source route-map RM-NAT-ISP1 interface GigabitEthernet0/0/0 overload. The trailing overload keyword is what turns this into PAT.
4. Mark the interfaces. Under the inside interface: ip nat inside. Under each ISP interface: ip nat outside. Without these, the translation never fires.
5. Repeat for ISP2. Build RM-NAT-ISP2 with a different match interface, then the matching NAT statement. Keep the ACL the same. the route-map interface match is what splits traffic.
6. Verify the translation table. show ip nat translations | inc 192.168.10. Each active flow should show the right outside-global IP. If everything shows ISP1, you've got a route-map ordering problem, check sequence numbers.
7. Save the running-config. write memory on IOS XE, copy running-config startup-config on classic IOS, copy run start short-form on NX-OS.

A deployment I shipped

The Redington Chennai warehouse I mentioned earlier ran ACT fibre as primary and Airtel 4G LTE as backup on a Catalyst 9200. Their previous engineer had used a single PAT statement with no route-map. When ACT failed and the default route shifted to Airtel, the NAT pool stuck to ACT's old public IP because IOS keeps the translation entry alive until the timeout hits. Outbound mail stopped because the Airtel ISP filters spoofed source IPs at the BNG. We rebuilt with the route-map approach above. Now failover is clean: the new translations bind to the Airtel public IP within seconds because the route-map interface match forces a fresh entry. Total cost of the rebuild: about 90 minutes including a test window. SmartNet ticket count since: zero.

How I verify the change actually works

1. show ip nat translations, each entry shows the correct outside-global IP.
2. show ip nat statistics. both pools have non-zero hit counters.
3. show route-map RM-NAT-ISP1, match count climbs as traffic flows.
4. show interface GigabitEthernet0/0/0 stats: output drops stay near zero.

Gotchas I've eaten in production

• Translations binding to the wrong public IP. Route-map order matters. Lower sequence numbers match first. If RM-NAT-ISP1 is sequence 10 and RM-NAT-ISP2 is sequence 20, ISP1 wins for any flow that matches both.
• %LINEPROTO-5-UPDOWN bouncing the outside interface. Each flap clears NAT translations bound to that interface, sessions die. Stabilise the interface first.
• show ip nat translations is empty. Either ip nat inside isn't on the LAN interface, or the inside ACL isn't matching. Try a debug, but only briefly. debug ip nat detail will hose a busy box.
• Asymmetric return path. If reply traffic comes back on ISP2 but NAT is bound to ISP1, the stateful inspection on a Firepower NGIPS box drops it. Use policy-based routing to lock return-path symmetry.

Cost impact

Numbers are 2026 indicative ranges and depend on the SKU plus your reseller. Redington and Ingram Micro typically beat list by 8-14% for partner-managed renewals. GeM-tender pricing varies again, most government rate contracts include first-year SmartNet bundled into the hardware price.

Tooling I keep on the bench

• Putty 0.78 for the console session. Logging is on by default for every box I touch.
• SecureCRT 9.4 when the customer has tab-heavy sessions or needs tabbed scripting against a fleet.
• Wireshark 4.2 for any time the platform behaviour does not match the documentation. A 10-second capture answers what 30 minutes of show commands cannot.
• Cisco DNA Center / Catalyst Center for fleets above 30 devices. The compliance dashboard catches drift that an engineer never sees.
• Cisco Modeling Labs (CML 2.7) for pre-prod testing. ₹0 for personal use up to 20 nodes; commercial licence runs about ₹1.2 lakh annually.
• Ansible 2.16 for templated rollouts. The cisco.ios and cisco.nxos collections both handle the platforms in this guide.

How this interacts with other Cisco surfaces

Hardly any change on Catalyst 9200 lives alone. The features in this guide ripple into adjacent boxes: sometimes within seconds, sometimes the next morning. Here is what I trace before I close a ticket.

Catalyst Center (DNAC) compliance

If the customer runs Catalyst Center, any out-of-band CLI edit will show as compliance drift inside 15 minutes. I either pre-stage the change as a template in the Network Design workflow, or I accept the drift flag and immediately re-sync the device state. Leaving the drift unresolved means the next compliance scan re-applies the previous template and silently wipes your change.

SD-WAN policy fabric

On a fabric router under vManage / Cisco SD-WAN control, CLI edits to features the controller manages get reverted on the next template push. The right move is to apply the change via a feature template, attach a CLI add-on for what the GUI does not cover, and push from vManage. If you are testing in isolation, detach the device from vManage first.

Identity Services Engine (ISE) RADIUS sessions

When the platform you are touching also acts as a NAS for 802.1X, every config save reloads the RADIUS subsystem briefly. Active wired sessions held by ISE can reauthenticate. Schedule the change outside the 9 a.m. login spike or use aaa accounting update periodic 5 to keep stale sessions visible to ISE while the box settles.

Firepower / FTD inspection

If a Firepower NGIPS or FTD sits between the inside and outside zones, any new NAT flow needs an access-control rule allowing it. The control-plane change on the router does not automatically open the firewall. I keep a paired change request open on FMC so the rule lands in the same window.

Duo MFA for admin login

If admin logins are protected by Cisco Duo, plan for the push prompt during your change window. A Duo push that times out at the wrong moment can leave you locked out of the second box mid-change. I keep a parallel console session open before I touch any auth-related config.

Long-term monitoring I leave running

A clean change is one that still looks clean a month later. On Catalyst 9200, I leave the following hooks in place after every deployment touched by this guide.

• SNMPv3 polling on the interfaces involved, CPU, memory, input / output bps, errors. PRTG or LibreNMS both work; the customer's existing NMS is usually fine.
• Syslog forwarding to a central collector. I prefer Graylog 5.2 with a dashboard that filters on %LINEPROTO-5-UPDOWN, %SYS-5-CONFIG_I, %SPANTREE-2-RECV_PVID_ERR, %OSPF-4-ERRRCV, and any platform-specific NAT / MPLS facility codes.
• NetFlow / IPFIX at low sample rate (1 in 1,000) to the customer's flow collector. Useful for proving that the NAT pool is being used the way the design intended.
• Monthly compliance scan via Catalyst Center or a manual show running-config diff against the change baseline. Drift catches silent edits.
• Quarterly review of SmartNet entitlement. If the SmartNet contract is about to expire (₹85,000 - 2 lakh annual, set a calendar 60 days out), renewal lead time on a GeM-tender customer can be 90 days.

None of these are heavy lifts. Combined, they catch the regressions that an ad-hoc show command will not. Customers who run them rarely call us about repeat incidents on the same change.

More frequently asked questions

Can I roll back without a reload?

Yes for every topic in this guide. The no-form of each command unwinds the change in real time. Run show running-config before and after so you can diff with VSCode or notepad++ if anything looks off.

Does this break IPv6?

No. None of these features touch the IPv6 forwarding path. If you run dual-stack on Catalyst 9200, IPv6 keeps its own LSDB, its own NAT (or NPTv6) state, and its own LDP context. they share nothing with IPv4 here.

What about IOS XE Stack-Wise V1/V2 mismatch?

Mixing Stack-Wise V1 and V2 members in the same stack is unsupported and reliably breaks NAT pool ownership. Replace the older member before configuring any of these features on a stacked Catalyst.

Is this safe to run during business hours?

Read-only verification is always safe. Config changes, even the no-op-looking ones: can disturb production. I schedule a 30-minute window with the customer, capture pre-change state, run the change, verify, and stop. A Comsys Mumbai-style runbook keeps this consistent across teams.

Will SmartNet TAC help if I get stuck?

Yes. With an active SmartNet (₹85,000 - 2 lakh annually depending on SKU and tier) TAC will accept a P3 ticket and review the running-config plus the relevant show outputs. Without SmartNet you can still post on the Cisco Community forum but expect community response speed, not SLA speed.

How do I avoid this becoming legacy debt?

Document the change in CMDB. Tag it with the project name. Add the verification commands to the runbook. Add a Catalyst Center compliance policy if you run one. The engineer who picks this up in 2028 will thank you.

What I do after the change is in

Three habits keep me sane after any production config change. First, I leave the console session logged in for 15 minutes and watch the syslog buffer. Second, I run show logging | last 100 from a fresh session 24 hours later. Third, I ask the customer's NOC to confirm zero alerts during the window. The combination catches almost every regression before it becomes a Monday morning ticket.

On a Catalyst 9200-class platform, the syslog patterns that I watch for are %LINEPROTO-5-UPDOWN on the affected interfaces, %SYS-5-CONFIG_I for unexpected re-edits, and %SPANTREE-2-RECV_PVID_ERR on the L2 underlay. If none of those show up in the next 48 hours, the change has settled.

If you came here because of a live outage, the fastest rollback is almost always the no-form of the commands above. Restore. Stabilise. Then reschedule the change for a quiet window. Production is not the time to be brave.

Related fixes

Related guides worth a look while you sort this one out:

• How to configure NAT overload PAT with route-map on Catalyst 8300/8500
• How to configure NAT overload PAT with route-map on Catalyst 9300
• How to configure NAT overload PAT with route-map on Catalyst 9400
• How to configure NAT overload PAT with route-map on Catalyst 9500
• How to configure NAT overload PAT with route-map on Catalyst 9800 WLC
• How to configure NAT overload PAT with route-map on Catalyst Center / DNAC