Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Cisco 7600 Static Route ECMP Failover Issue

Greetings,

This is my first post on this fourm so thanks ahead of time for any feedback.  I have run into a problem testing static route failovers using ECMP.  I have an edge device (SUT) that has 2 NIC interfaces to an internal Loopback.  Each NIC is a unique Gi port on an 7609 VLAN tagged with unique IP subnets.  The 7600 is configured to route the loopback via the 2 NIC.  I am using CEF in the network for other traffic performance testing.  Using an external sniffer we can verify that when a ping is initiated externall to the SUT loopback a specific path is selected by the router. 

Ping host ------Network-----7609 Gi1/21 (172.16.110.9)-----------SUT Nic1 (172.16.110.10)

                                        |                             |

                                        |                             -------Loopback 137.168.68.114/32

                                        |                             |

                            7609 Gi2/21 (172.16.110.73)------------SUT Nic2 (172.16.110.74)

RTRL011#show ip route | section 137.168.68.114

S        137.168.68.114/32 [1/0] via 172.16.110.74

                           [1/0] via 172.16.110.10

RTRL011#

Now, when the selected path is taken out of server (pulling cable for example), the 7609 is not clearing the routing table to indicate that particular path is down and failing over to the secondary path.  Other things I have noticed is the show ip cef still shows both peers as well as the arp table but the interface shows down (show interface gi1/21 for example).  I am running 15.1.  My understanding is that since the ports are directly connected to the router, the ports should be detected as down and any association of the IP for the down port should removed.  This should trigger the static route to update the static route for the end destination to use the second path and traffic should continue. 

Let me know if more detial is needed to help understand this issue or if there is a known issue with Static ECMP routing.


ROM: System Bootstrap, Version 12.2(17r)S2, RELEASE SOFTWARE (fc1)
BOOTLDR: Cisco IOS Software, c7600s72033_rp Software (c7600s72033_rp-ADVENTERPRISEK9-M), Version 15.1(1)S1, RELEASE SOFTWARE (fc1)

Thanks

4 REPLIES
New Member

Cisco 7600 Static Route ECMP Failover Issue

Bump to top.

Re: Cisco 7600 Static Route ECMP Failover Issue

Hi,

Wellcome and hope to see more posts from you, Eric.

I think that the software uses this route even though the next-hop is not directly connected, and its trying to do recursive lookup for the next-hop. Do you have any default route in the routing table, or any summary that would include the IP of the interface ?

Regards

Dan

New Member

Cisco 7600 Static Route ECMP Failover Issue

Hi Eric,

You said you are getting the following output even when Gi1/21 for example is unplugged;

show ip route | section 137.168.68.11

S        137.168.68.114/32 [1/0] via 172.16.110.74

                                      [1/0] via 172.16.110.10

So the route via 172.16.110.10 should be gone, so what then happens if you do "show ip route | i 172.16.110.10" ? Does it say Gi1/21  / 172.16.110.9 as the output interface?

New Member

Cisco 7600 Static Route ECMP Failover Issue

I want to thank you all for helping.  I figured out the current issue.  When I set the VLANs for some reason I got a step out of order and all VLANS were being tagged on all interfaces.  So when NIC1 for example went down, the VLAN was still active because it was also tagged on NIC2 interfaces even though the other side was not reachable (it did not have the same vlan settings).  I have fixed the VLAN tags to the correct port mapping and now the routes are cleared as expected.  I am still a bit concerned that the router did nto realize it could not reach the next hop and still maintained the routes..

Thanks again..

883
Views
0
Helpful
4
Replies
CreatePlease to create content