05-29-2009 01:19 AM - edited 03-06-2019 05:59 AM
We have some static routes which point to SVI's. We've had a problem recently with the switch going down which the static route is pointing to. The problem is the route is still in the routing table. Is this normal behaviour and why isn't the route removed from the routing table.
05-29-2009 02:31 AM
Hello Darren,
the static route is kept in the routing table for the following reasons:
interface SVI is still up/up because there is at least one L2 interface in vlan X in STP forwarding state.
the ARP table still contains an entry for the static router next-hop
you can try to clear the ARP entry to speed up the process.
Hope to help
Giuseppe
05-29-2009 03:55 AM
Darren
Just to add a bit to the response from Giuseppe: yes this is normal behavior. The reason it does this is that the device with the static route still thinks that the static route is valid. After all the outbound interface on that device (through which the static route points) is still working ok. This is a common problem when static routes point out Ethernet interfaces.
If this is a problem for you there is an alternative which you can consider. Cisco introduced a feature to use object tracking to track a static routes and to remove the static route if the next hop is not reachable. This link should provide information to help get you started if you want to do this.
http://www.cisco.com/en/US/docs/ios/12_3/12_3x/12_3xe/feature/guide/dbackupx.html
HTH
Rick
09-19-2012 10:06 AM
Bump !
To me it's not an expected behavior; a static route shouldn't be kept in the routing table if the underlying interface used to reach the next hop is down
here are my traces; I have a static route belonging to a VRF
show run | i ip route vrf
ip route vrf VRF-PF1 4.0.0.0 255.255.255.128 10.101.219.100
This network points to a SVI which is kept in the "shutdown" state
D7400_DC#show ip interface brief | i 10.101
Vlan5 10.101.219.2 YES NVRAM administratively down down
Here is the output of the routing table
D7400_DC#show ip route vrf VRF-PF1 static
Routing Table: VRF-PF1
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter areaN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static routeo - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop overrideGateway of last resort is 192.168.230.34 to network 0.0.0.0
4.0.0.0/25 is subnetted, 1 subnetsS 4.0.0.0 [1/0] via 10.101.219.100
D7400_DC#
So the next hop of my static route is bound to a local interface which is down, but the route is still in the routing table (no old entry in the arp cache or anything else)
If the next hop of a static route is bound to an Ethernet interface (instead of a SVI) which is put in a shutdown state; then the route doesn't appear in the routing table.
Any idea about that ?
I'm running 4500 SUP 7E with the latest IOS 3.3.1SG / IOS XE 15.1SG
09-19-2012 11:29 AM
Hello Surya,
the IP routing table of the VRF shows only a static route, no local or connected route is present in confirmation that you have disabled the SVI associated to the VRF.
However, I see a statement that says:
>> Gateway of last resort is 192.168.230.34 to network 0.0.0.0
Have you configured any form of route leaking to this VRF?
If the answer is positive the default route to 192.168.230.34 ( I don't know where it is, it is not a connected route in this VRF as far as we can see) might have been used to "resolve" the IP next-hop of the static route with destination 4.0.0.0/25.
Hope to help
Giuseppe
09-19-2012 12:37 PM
Hi.
As you could see in the command I issued in the IOS the output is filtered to show only static routes; I do have an OSPF process by which I learn the default but I can ensure it doesn't conflict / resolve the next hop referenced as next-hop with my static route (you could notice it's a dummy route to a dummy public network).
Here was my Arp cache when I took the trace
D7400_DC#show arp vrf VRF-PF1
Protocol Address Age (min) Hardware Addr Type InterfaceInternet 192.168.230.33 6 0011.0afe.3820 ARPA GigabitEthernet2/46
Internet 192.168.230.34 1 0001.e794.0601 ARPA GigabitEthernet2/46Internet 192.168.230.35 - 2c54.2dd3.0c3f ARPA GigabitEthernet2/46
Internet 192.168.230.65 - 2c54.2dd3.0c3f ARPA Port-channel2Internet 192.168.230.66 50 2c54.2dd3.0aff ARPA Port-channel2
D7400_DC#
As I said it's clear now that if a static route points to an SVI which is down; the route still appears in the routing table; if it points to a physical Ethernet interface; the route is not shown in the routing table.
I'll try this again tomorrow on my 4500 / IOS XE 15.1 and then on a 3560 running 12.2(55); maybe the behavior changes according to the IOS version.
It's clearly a big problem as I have 2 chassis; I redistribute all my static routes into my OSPF processes with different costs (to get an active/standby design; I redistribute all static routes with a metric of 50 / E2 on the first chassis and a metric of 100 / E2 on the second unit); so as I have to put into a "shutdown" state all my SVI to prepare my migration; the chassis are still anouncing the static routes (which are being announced in OSPF; as they're present in the routing table; even if all next-hops are unreachable as all SVI are down).
I've never noticed this before.
09-20-2012 05:45 AM
Hi.
Finally you're probably right; I'll have to investigate furthermore but the problem disappears when I disable OSPF.
So the status of a configured static route in the "live" routing table is not only related to the status of the underlying interface (but it should be);
The correct algorithm for the IOS would check if the nexthop of a configured static route is reachable through a "directly connected" network instead a remote network. Can someone from Cisco confirm ?
09-20-2012 07:26 AM
Hello Surya,
the issue arises from the fact that Cisco IOS allows to configure static routes with not directly connected IP next-hop invoking routing recursion.
In your scenario when you shut the SVI, the static route next-hop is searched in the VRF routing table and the default route provided by OSPF can be enough to make the route still alive.
At this point, you should try to use reliable static routing with object tracking, so that the static route is removed when the IP SLA with destination = IP next-hop fails.
see
http://www.cisco.com/en/US/docs/ios/12_3/12_3x/12_3xe/feature/guide/dbackupx.html
Hope to help
Giuseppe
09-20-2012 07:35 AM
So for each configured static route; the best practice is to track the status of the underlying interface owning the next-hop ? it sucks !
Can you explain this point in detail ? it sounds to me as a nonsense Except for static route leaking between VRF ?
Cisco IOS allows to configure static routes with not directly connected IP next-hop invoking routing recursion.
09-20-2012 08:39 AM
Hello Giuseppe,
In your scenario when you shut the SVI, the static route next-hop is searched in the VRF routing table and the default route provided by OSPF can be enough to make the route still alive.
Hmmm... A next hop of a static route should never be resolved using a default route. It can be resolved through any more specific route (i.e. a prefix length of at least /1) but Cisco routers should never use a default route to resolve some other route's next hop. That was my understanding and experience. Are you suggesting that the behavior is different?
Thank you!
Best regards,
Peter
09-20-2012 08:45 AM
Hi Peter.
What you say makes sense; the subnet which owns the nexthop address is announced by several routers in my OSPF backbone.
The network owning the ip address of my next hop within my static route is learnt through OSPF.
09-20-2012 09:14 AM
Hello Peter,
you are right I have made a wrong assumption when I had not enough details for the case we were discussing
Rated as it deserves (I try to pay my debts ...)
As Surya has added in his last post the IP subnet of the next-hop is learned in OSPF in the VRF so when the local node SVI is disabled the IP next-hop is resolved with the specific OSPF route and the IP next-hop becomes not directly connected.
Surya:
the recursion is actually this: the IP next-hop of the static route resolved by another route
Best Regards
Giuseppe
09-20-2012 09:21 AM
Ok thank you all I understand now.
Is there any real application of route recursion if the next hop is not directly connect ?
In my case it creates a blackhole.
09-20-2012 11:59 AM
Hi Surya,
Is there any real application of route recursion if the next hop is not directly connect ?
Sure - think of BGP, for example. In iBGP, the next hop is the ASBR either in the next AS or in your own AS (depending on whether you're using the next-hop-self). This concept has many applications also in MPLS world, like MPLS L3 VPNs, 6PE, 6VPE, etc.
Best regards,
Peter
09-20-2012 11:57 AM
Hello Giuseppe,
No need to apologize, I wasn't pointing out any inaccuracy - I just got intrigued by your statement. As it happens so often, things taken for granted are often quite different.
And most certainly, there is no debt on your part! On the contrary, I feel indebted to you for many, many things. Are you perhaps coming to Live! 2013 to London? It would be awesome to meet you there...
Best regards,
Peter
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide