Cisco 4431 using wrong route

[Richard Tapp]

I have a Cisco 4431 that was reloaded at the weekend, config saved and confirmed the same as before.

It has two WAN interfaces.

WAN 1 with the default route pointing to it

WAN 2 with higher cost default route pointing to it.

Before the weekend it was working fine via WAN 1.

In the routing table it still thinks WAN 1 is primary and in use

S* 0.0.0.0/0 [1/0] via 62.253.x.x

But all traffic is going via WAN 2, 'Whats My IP' and Speed tests confirm this.

So far I have shut down and brought back up both WAN interfaces.

Removed the static to WAN 2, traffic did not start to flow via WAN 1.

Removed static to WAN 1 and reapplied.

Cleared, NAT, ARP, IP traffic etc.

I have a route to 8.8.4.4 via WAN 1 and traffic to this IP is using WAN 1

Can anyone think of anything else to try before a reload ( bit difficult at the site, it is in use 24x7)

[Seb Rupik]

Hi there,

Can you share the entire running config with us?

cheers,

Seb.

[Deepak Kumar]

Hi,

Share the running configuration and have you applied any route-map or modified any NAT?

Regards,

Deepak Kumar

[Richard Tapp]

I am wondering if it is the NAT. I did not really think about it before, maybe our route-map naming is misleading.

NAT translations are showing it is using gig 0/0/1, but default route is via gig 0/0/0

How does NAT decide which interface to NAT out of ? I have other sites where we have the same order as below that are working fine.

This has been working for months with the config below, but I do remember having NAT issues the day we applied this config.

I am wondering if I had the second NAT statement (RM primary) running first and it all worked correctly. Then applied the first NAT (RM backup) and it carried on with the 'primary' one. Then when we reloaded it picked up the 'backup' one.

This config has never mention 'match interface GigabitEthernetx/x/x' in the RM's, where as another config I have looked at does

ip nat inside source route-map backup interface GigabitEthernet0/0/1 overload

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

ip route 0.0.0.0 0.0.0.0 62.253.x.x

ip route 0.0.0.0 0.0.0.0 208.178.x.x 10

i!

route-map primary permit 10

 match ip address NATLIST

route-map backup permit 10

 match ip address NATLIST

[Richard Burts]

Your route maps should have 2 match statements so that you are matching the particular interface as well as matching the access list. That is most likely the issue. If changing that does not solve the issue then please provide config sections from the current running config for interfaces, for nat, for route maps and access lists. Also please post the output of show ip route and of show ip interface brief.

HTH

Rick

[Seb Rupik]

Whilst we what for the remaining configuration items, to answer your question "How does NAT decide which interface to NAT out of ?"

When performing NAT from inside to outside, policy routing then routing decisions are taken before NAT. So in your case the routing decision is taken to use Gi0/0/0 due to the static route which has the lower AD, upon exiting Gi0/0/0 the packet is translated.

cheers,

Seb.

[Deepak Kumar]

Hi,

Also share some more output as Sho ip route, Sho ip access-list, Sho ip interface brief, Sho ip route.

Regards,

Deepak Kumar

[paul driver · Accepted solution]

Hello

Just like to add to @Richard Burts  comments ( which is you also should be matching in the route-maps  on the outgoing interface of each ISP)

route-map primary permit 10
match ip address NATLIST
match interface GigabitEthernet0/0/0

route-map backup permit 10
match ip address NATLIST
match interface GigabitEthernet0/0/1

I would also like to suggest apply some conditional tracking on your default static routes if applicable.

ip sla 1
icmp-echo <isp1 ip address> source-interface GigabitEthernet0/0/0
ip sla schedule 1 life forever start-time now

track 1 rtr 1 reachability
ip route 0.0.0.0 0.0.0.0 62.253.x.x name primary-isp track 1

[Richard Burts]

I agree with Paul that in the context of this discussion that the major issue is that the route maps used for address translation should match on both the interface and the acl. I also agree with Paul that if you are going to have a primary static default route and a backup static default route than using tracking is very desirable as a way to trigger failover from primary to backup. Since we have not seen the complete config I do not know whether there is already tracking or not. But if there is not already tracking in the config then I agree with Paul that it would be desirable.

HTH

Rick

[Richard Tapp]

Thanks for al the replies. It was just 'match interface x/x/x' missing from the route maps.

Also thanks, I had forgotten to put IP SLA on this router, now updated.

[Deepak Kumar]

Hi,

This is Good News. Please vote to solutions has helped you to find an issue and accept the solution as well.

Regards,

Deepak Kumar