NAT Issues with Cisco 1921 and Verizon Wireless LTE 4G

[jbugasch11]

The infrastructure in place is a Cisco 1921 with primary Internet connectivity via a cable ISP.  Backup connectivity is to be provided by VZW with dynamic IP address.  Failover is doing with IP SLA tracking, but the issue is not that far into the configuration.

The cellular interface stays up and stable with a negogiated IP address with no issues.  However, the second I point my default route towards to the cellular interface, the interface resets (continues to flap until default is removed).  To me this sounds like a source nat issue that others have experienced.  If I point smaller subnets towrards the cellular interface, it works fine.  It seems like it's only when it's the default route that that the issue occurs.

I've run numerous debugs and verified my NAT translations to be accurate.  I am still suspicious that Verizon is detecting a NAT violation, but I see nothing that could be causing that.  Attached is the config snipet (very basic) in hopes someone can shed some light on this for me:

track 1 ip sla 1 reachability

delay down 30 up 30

interface Cellular0/1/0

description to VZW

ip address negotiated

no ip unreachables

ip nat outside

interface GigabitEthernet0/0

description to Cable ISP

ip address X.X.X.94 255.255.255.252

ip nat outside

interface GigabitEthernet0/1.10

encapsulation dot1Q 10

ip address 10.1.1.1 255.255.255.0

ip nat inside

ip sla auto discovery

ip sla 1

icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0

threshold 500

frequency 10

ip sla schedule 1 life forever start-time now

route-map VERIZON-NAT permit 10

match ip address 105

match interface Cellular0/1/0

route-map CABLE-NAT permit 1

match ip address 104

match interface GigabitEthernet0/0

ip nat inside source route-map CABLE-NAT interface GigabitEthernet0/0 overload

ip nat inside source route-map VERIZON-NAT interface Cellular0/1/0 overload

access-list 104 permit ip 10.1.1.0 0.0.0.255 any

access-list 105 permit ip any any

ip route 0.0.0.0 0.0.0.0 X.X.X.93 track 1

ip route 0.0.0.0 0.0.0.0 Cellular0/1/0 track 1

Thx,

Jon

[Richard Burts]

Jon

I wonder why you are using track 1 on the static default route using the cellular interface. The reason for tracking the route through the cable interface is clear but why do you need to track the cellular?

I also wonder why the static default route using the cellular is not configured as a floating static? If the intent is that the primary outbound will be cable and that cellular should be backup it would seem more logical that the cellular route should be a floating static rather than a normal static with default admin distance.

I am not sure what difference it will make but I will suggest that you re-write the access lists used to select the traffic to translate. Rather than having extended access lists that permit any destination configure the access lists as standard access lists that permit the source addresses that matter to you.

Give these suggestions a try and let us know if the behavior changes?

HTH

Rick

[jbugasch11]

Sorry I typed this a little distracted.  There is indeed a weight on the Cellular default route and the track is only on the primary link (thanks for noting that)...my apologies.  See corrected config below:

ip route 0.0.0.0 0.0.0.0 X.X.X.93 track 1

ip route 0.0.0.0 0.0.0.0 Cellular0/1/0 250

The reason why ACL 105 is permitting any was a troubleshooting measure.  This way there is no chance any traffic would leave that interface without being natted.  I did have an ACL matching on the specific network I wanted to nat (the 10.1.1.0/24) and it made no difference.

Thank you.

[Richard Burts]

Jon

Thank you for the clarification about the static routes and the tracking. It is good to know that my suggestions there were on target.

I understand, and agree, with the logic that the access list for translation on the cellular should permit any. The point that I was trying to make was the difference between using an extended access list and a standard access list. You are not doing anything in either of the translation access lists that requires the capabilities of an extended access list and you can achieve the desired results with a standard access list. I have seen some situations where odd things might happen in address translation where the access list was extended with permit any for the destination.

HTH

Rick