Nat overload and IPSLA

[Emil Naklicki]

I have a Cisco ISR that I am trying to add two ISPs for basic internet traffic. I configured IP sla and tracking so that when ISP1 fails, ISP2 becomes the gateway of last resort. This works exactly how I expect it. However, I am confused on how NAT plays into this setup. I have a NAT overload configured on Gi0/0/0 for the primary. But I cannot figure out how the second NAT overload can be placed on Gi0/0/1 when ISP1 fails. Is there some sort of NAT tracking similar to how I can track with IP SLAs?

[Reza Sharifi · Accepted solution]

You use the same NAT statmnet that you are using for ISP1 for ISP2 as well.

ip nat inside source route-map ISP1 interface gi0/0/0 overload

ip nat inside source route-map ISP2 interface gi0/0/1 overload

Asumming you have 2 default routes, when the first one failes, the second ISP should start forwarding traffic. 

HTH

[Emil Naklicki]

I was assuming the same thing however here is the reply I get back.

Cannot change mapping's interface name; remove mapping first

I technically do not have two default gateways since I am using IP tracking. I have one GLR until it becomes unreachable, then it gets replaced with the second GLR.

[Reza Sharifi]

Why can't you add a second static route twards the second provider as well?

Assuming isp1 is primary and isp2 is backup:

ip route 0.0.0.0 0.0.0.0 <isp1>

ip route 0.0.0.0 0.0.0.0 <isp2> 10

This way the first one is your primary and the second one is on stand-by (since it has higher admin) to take over in case the first one fails.

HTH

[Emil Naklicki]

Reza,

Your configuration would work but the problem is, ip route 0.0.0.0 0.0.0.0 <isp1>. Lets say the address for ISP1 is 3.3.3.2 and my address interfacing that router is 3.3.3.3. If ISP1 loses internet connectivity further down the LEC, I would still be able to reach 3.3.3.2 even though the internet is down due to a connection further along the communications chain. Therefore my gateway would still point to this GLR and not the isp2 gateway with the higher metric. This is why I am using IP sla. So if I cannot ping say 8.8.8.8 from my ISP1 interface, then I deem that connection down and my routing table pulls 0.0.0.0 0.0.0.0 <isp1> and replaces it with 0.0.0.0 0.0.0.0 <isp2> 10

All of this part explained above works, however, I'm still at a lose with my NAT overload as I cannot add that state with this current configuration

[Georg Pauwen]

Hello,

in addition to Reza's remarks, an alternative might be an EEM script that activates the backup interface (and also clears the existing NAT translations).

Post the full config of your ISR, so I can add the necessary bits and pieces for this approach...

[Emil Naklicki]

Georg,

I think the EEM script may do the trick. I could have a script pull the Current NAT statement and replace it with the ISP2 NAT. However, I would think with the nature of SLAs and IP tracking, Cisco would have a way of dynamically updating NAT along SLA events.

[Georg Pauwen]

Hello,

post the config you currently have. At the very least the EEM script should clear the current NAT translations...

[Emil Naklicki]

So to anyone wondering. The proper way of accomplishing this is to create route-maps for ISP1 and ISP2 With the route map you are able to add Multiple overload statements. EX

ip nat inside source route-map NAT-ISP1 interface GigabitEthernet0/1/0 overload
ip nat inside source route-map NAT-ISP2 interface GigabitEthernet0/0/1 overload

Additionally you could route subnets to use specific ISPs

[Richard Burts]

Thank you for confirming that the approach of using route maps to control the address translation does work. From the first response Reza was advocating that you using route maps. And I think that he might have assumed that you already were using a route map. But I am guessing that your configuration was using a simple ip nat inside referencing an access list to perform the overload. One of the advantages of using a route map is that you can then match on both the access list and the interface being used. Glad to know that you have it working now.

HTH

Rick

[Emil Naklicki]

Richard,

You are correct. I just marked his response as the solution.

Thank you,

[Richard Burts]

Marking his answer as correct is the right thing to do. He was the one to identify this option. By marking this question as solved you will make it easier for other participants in the community to recognize discussions that have helpful information. I hope to see you continue to be active in the community.

HTH

Rick