Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
5382
Views
15
Helpful
16
Replies

Static routes to a SVI's problem

darrenriley5
Level 1
Level 1

‎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.

Labels:
0 Helpful
16 Replies 16

Surya ARBY
Level 4
Level 4
In response to Peter Paluch

‎09-21-2012 06:47 AM

Hi all.

I could make some tests on a 3560 12.2(55)SE6 ip services :

  1. When a network owning the nexthop ip address is not announced through OSPF it's ok; static routes don't appear in my routing table.
  2. As soon as I announce a route to the nexthop network through OSPF; my static routes appear in the routing table.
  3. At some point I withdraw the subnet from the OSPF network; so the subnet of the nexthop is not propagated and OSPF converges well but...
  4. it takes near 1 minute for the IOS to withdraw all the static routes from the routing table; have you ever seen that kind of convergence times ?

Here is the output of a "debug ip routing"

when I add a remote network in the OSPF backbone; static routes are installed in the routing table; the next hop is 10.101.219.103 and for my test I add somewhere in the OSPF backbone a route to 10.0.0.0/8

*Mar  1 04:30:21.847: RT(VRF-PF1): add 10.0.0.0/8 via 192.168.230.36, ospf metric [110/11]
*Mar  1 04:30:27.820: RT(VRF-PF1): add 0.0.0.0/0 via 10.101.219.103, static metric [1/0]
*Mar  1 04:30:27.820: RT(VRF-PF1): default path is now 0.0.0.0 via 10.101.219.103
*Mar  1 04:30:27.820: RT(VRF-PF1): new default network 0.0.0.0
*Mar  1 04:30:27.820: RT(VRF-PF1): add 55.8.56.162/32 via 10.101.219.100, static metric [1/0]
*Mar  1 04:30:27.820: RT(VRF-PF1): add 66.237.42.30/32 via 10.101.219.100, static metric [1/0]
*Mar  1 04:30:27.820: RT(VRF-PF1): add 86.65.172.65/32 via 10.101.219.100, static metric [1/0]
*Mar  1 04:30:27.820: RT(VRF-PF1): add 134.26.27.96/27 via 10.101.219.100, static metric [1/0]
*Mar  1 04:30:27.820: RT(VRF-PF1): add 147.204.2.0/24 via 10.101.219.100, static metric [1/0]
*Mar  1 04:30:27.820: RT(VRF-PF1): add 155.94.56.0/22 via 10.101.219.100, static metric [1/0]
*Mar  1 04:30:27.820: RT(VRF-PF1): add 172.16.21.50/32 via 10.101.219.100, static metric [1/0]
*Mar  1 04:30:27.820: RT(VRF-PF1): add 172.16.21.51/32 via 10.101.219.100, static metric [1/0]
[output suppressed]

At some point I withdraw the 10.0.0.0/8 from the OSPF network; look to the timestamps !!

*Mar  1 04:34:33.724: RT(VRF-PF1): del 10.0.0.0 via 192.168.230.36, ospf metric [110/11]
*Mar  1 04:34:33.724: RT(VRF-PF1): delete network route to 10.0.0.0
*Mar  1 04:35:27.855: RT(VRF-PF1): del 0.0.0.0 via 10.101.219.103, static metric [1/0]
*Mar  1 04:35:27.855: RT(VRF-PF1): delete network route to 0.0.0.0
*Mar  1 04:35:27.855: RT(VRF-PF1): del 55.8.56.162/32 via 10.101.219.100, static metric [1/0]
*Mar  1 04:35:27.855: RT(VRF-PF1): delete subnet route to 55.8.56.162/32
*Mar  1 04:35:27.855: RT(VRF-PF1): delete network route to 55.0.0.0
*Mar  1 04:35:27.855: RT(VRF-PF1): del 66.237.42.30/32 via 10.101.219.100, static metric [1/0]
*Mar  1 04:35:27.855: RT(VRF-PF1): delete subnet route to 66.237.42.30/32
*Mar  1 04:35:27.855: RT(VRF-PF1): delete network route to 66.0.0.0
*Mar  1 04:35:27.855: RT(VRF-PF1): del 86.65.172.65/32 via 10.101.219.100, static metric [1/0]
*Mar  1 04:35:27.855: RT(VRF-PF1): delete subnet route to 86.65.172.65/32
*Mar  1 04:35:27.855: RT(VRF-PF1): delete network route to 86.0.0.0
*Mar  1 04:35:27.855: RT(VRF-PF1): del 134.26.27.96/27 via 10.101.219.100, static metric [1/0]
*Mar  1 04:35:27.855: RT(VRF-PF1): delete subnet route to 134.26.27.96/27
*Mar  1 04:35:27.855: RT(VRF-PF1): delete network route to 134.26.0.0
*Mar  1 04:35:27.855: RT(VRF-PF1): del 147.204.2.0/24 via 10.101.219.100, static metric [1/0]
*Mar  1 04:35:27.855: RT(VRF-PF1): delete subnet route to 147.204.2.0/24
*Mar  1 04:35:27.855: RT(VRF-PF1): delete network route to 147.204.0.0

Should I open a case ? I don't have a 4500 sup7 or any switch with IOS 15 to test currently; right now my 4500 are connected on a production network so I can't play with it anymore.

Also I did another test : when I add a valid static route to 10.0.0.0/8 it takes more than 30 seconds to ba taken in account by the IOS for making all other static routes up in the routing table :

*Mar  1 04:45:52.807: RT(VRF-PF1): add 10.0.0.0/8 via 192.168.230.36, static metric [1/0]
*Mar  1 04:46:27.955: RT(VRF-PF1): add 0.0.0.0/0 via 10.101.219.103, static metric [1/0]
*Mar  1 04:46:27.955: RT(VRF-PF1): default path is now 0.0.0.0 via 10.101.219.103
*Mar  1 04:46:27.955: RT(VRF-PF1): new default network 0.0.0.0
*Mar  1 04:46:27.955: RT(VRF-PF1): add 55.8.56.162/32 via 10.101.219.100, static metric [1/0]
*Mar  1 04:46:27.955: RT(VRF-PF1): add 66.237.42.30/32 via 10.101.219.100, static metric [1/0]
*Mar  1 04:46:27.955: RT(VRF-PF1): add 86.65.172.65/32 via 10.101.219.100, static metric [1/0]
*Mar  1 04:46:27.955: RT(VRF-PF1): add 134.26.27.96/27 via 10.101.219.100, static metric [1/0]
*Mar  1 04:46:27.955: RT(VRF-PF1): add 147.204.2.0/24 via 10.101.219.100, static metric [1/0]
*Mar  1 04:46:27.955: RT(VRF-PF1): add 155.94.56.0/22 via 10.101.219.100, static metric [1/0]
*Mar  1 04:46:27.955: RT(VRF-PF1): add 172.16.21.50/32 via 10.101.219.100, static metric [1/0]
*Mar  1 04:46:27.955: RT(VRF-PF1): add 172.16.21.51/32 via 10.101.219.100, static metric [1/0]

then I withdraw the static route to 10.0.0.0/8 it takes more than 30 seconds to flush the static routes which are blackholed

*Mar  1 04:48:56.710: RT(VRF-PF1): del 10.0.0.0 via 192.168.230.36, static metric [1/0]
*Mar  1 04:48:56.710: RT(VRF-PF1): delete network route to 10.0.0.0
*Mar  1 04:49:28.083: RT(VRF-PF1): del 0.0.0.0 via 10.101.219.103, static metric [1/0]
*Mar  1 04:49:28.083: RT(VRF-PF1): delete network route to 0.0.0.0
*Mar  1 04:49:28.083: RT(VRF-PF1): del 55.8.56.162/32 via 10.101.219.100, static metric [1/0]
*Mar  1 04:49:28.083: RT(VRF-PF1): delete subnet route to 55.8.56.162/32
*Mar  1 04:49:28.083: RT(VRF-PF1): delete network route to 55.0.0.0
*Mar  1 04:49:28.083: RT(VRF-PF1): del 66.237.42.30/32 via 10.101.219.100, static metric [1/0]
*Mar  1 04:49:28.083: RT(VRF-PF1): delete subnet route to 66.237.42.30/32
*Mar  1 04:49:28.083: RT(VRF-PF1): delete network route to 66.0.0.0

The delay to withdraw the static routes is extremely long; so what I learn from these tests is that tracking the status of underlying interfaces for static routing is mandatory; and it's not explained in any course !

0 Helpful

Peter Paluch
Cisco Employee
Cisco Employee
In response to Surya ARBY

‎09-21-2012 07:10 AM

Hello Surya,

The static routes are being revalidated for installation or purge from the routing table using a periodic IOS process. By default, this process runs every 60 seconds which should explain the delay you have seen. It is possible to shorten this interval using the global configuration command

ip route static adjust-time seconds

with the seconds argument in the range between 1 and 60. You may want to shorten this interval but if you have a large count of static routes, shortening this interval may lead to higher CPU utilization. Read more here:

http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_pi/command/iri-cr-a1.html#GUID-9EC9E26A-0012-4332-A1D2-0710C551D798

Best regards,

Peter

0 Helpful
Customers Also Viewed These Support Documents
Review Cisco Networking products for a $25 gift card