Static route fallback issue with C1111-8PLTE routers

[dofange]

I am encountering a routing fallback issue on our Cisco ISR C1111-8P-LTE routers, running Cisco IOS XE Software, Version 16.08.01. The scenario involves two static routes configured within a VRF:  

• Primary Route: Directs traffic through a VPN tunnel with a metric of 1. 
• Secondary Route: Directs traffic to a neighboring router directly with a metric of 10. 

 The initial failover process functions as expected: when the VPN tunnel (primary route) fails, the router correctly shifts traffic to the secondary route. However, when the VPN tunnel is restored, and the primary route is reinstalled in the routing table (and the secondary route is removed as expected), traffic fails to revert back to the primary route.  

This issue consistently occurs with a continuous UDP unicast stream, consisting of approximately 8 packets per second. Currently, the only workaround to redirect the traffic back to the primary route involves manually shutting down the interface connected to the secondary route for about 30-40 seconds.  

Any suggestions how to overcome this issue? I've tried using tracking and EEM to do "shut" "wait 40s" "no shut" but that did not work for some reason.

Br,

-seppo 

[MHM Cisco World]

The only thing prevent thisnif you have FW in router ? Do you have any zone firewall in your router ?

MHM

[dofange]

Thanks for the answer. No, there is no zone firewall stuff in the routers.

-seppo

[MHM Cisco World]

Do you use route-map with NAT command 

MHM

[dofange]

No, unfortunately. Just a very basic static route configuration inside a VRF.

-seppo

[MHM Cisco World]

Then friend you need two NAT 

Ip nat inside source route-map ISP1 interface <ISP1> overload 

Ip nat inside source route-map ISP2 interface <ISP2> overload 

Route-map ISP1 permit 10

Match ip address <subnet acl>

Match interface <ISP1>

Route-map ISP2 permit 10

Match ip address <subnet acl>

Match interface <ISP2>

MHM

[dofange]

Sorry I don't quite understand what does your suggested configuration do, and how that could help?

[MHM Cisco World]

https://danjmcintyre.com/2020/02/13/cisco-router-dual-wan-uplinks-with-nat/

Check this link

Abd what I suggest is using NAT route-map to make router NATing depend on egress interface 

MHM

[Flavio Miranda]

@dofange 

 If I understood correctly what you described is the expect behavior. First, the router is doing its job with route fallback. Then you are facing issue with application based in UDP which is an application problem due the fact that UDP is connectionless thus the stream will continue and source will not care if the path has change or not. If you have NAT it will be even worth.

 As the router is a layer3 device and have no visibility of layer4, where the UDP reside, you need to fix it in the application layer.

[dofange]

Thanks for the reply Flavio. There has been some misundestanding: there is no problem with the application. The problem is, that when the primary route comes back online, the router still keeps forwarding packets via secondary route even though routing table is correctly updated. The application of course works but it is not the behaviour we want from the router.

-seppo

[Flavio Miranda]

 Got it.   This could be some configuration on the router with with Sticky Connections

https://www.cisco.com/c/en/us/td/docs/ios/slb/configuration/guide/slb_cg_book/slb_cg_xmp.html#wp1062228

[dofange · Accepted solution]

I felt that NAT was not required in my setup, and Policy-based routing didn't help either. But in the meanwhile I stumbled to the route cause of my problem: the secondary route (ie. secondary next-hop) was reachable via switchport interface as they were in the same subnet with the source. I realized that changes to the routers routing table didn't affect the UDP flow because packets were directly forwarded in the  layer2 trunk to the next-hop router before entering the route-lookup at the original router.

So I made a new L3 vlan interface between the original router and the secondary next-hop router and used that as a secondary route. Now the static routes act as they are supposed to.

Thanks all for the replies. 

Cheers,

-seppo