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

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 area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - 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 route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is 192.168.230.34 to network 0.0.0.0

      4.0.0.0/25 is subnetted, 1 subnets
S        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

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

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   Interface
Internet  192.168.230.33          6   0011.0afe.3820  ARPA   GigabitEthernet2/46
Internet  192.168.230.34          1   0001.e794.0601  ARPA   GigabitEthernet2/46
Internet  192.168.230.35          -   2c54.2dd3.0c3f  ARPA   GigabitEthernet2/46
Internet  192.168.230.65          -   2c54.2dd3.0c3f  ARPA   Port-channel2
Internet  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.      

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 ?

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

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.

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

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.

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

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.

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

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