Static route not appearing in route table

Answered Question
Feb 5th, 2007

Any ideas why this static route won't show up in the route table?:

Router#sh ver

Cisco Internetwork Operating System Software

IOS (tm) C2600 Software (C2600-IO3-M), Version 12.3(3), RELEASE SOFTWARE (fc2)

Copyright (c) 1986-2003 by cisco Systems, Inc.

Compiled Tue 19-Aug-03 16:32 by dchih

Image text-base: 0x80008098, data-base: 0x80D11A24

ROM: System Bootstrap, Version 12.1(3r)T2, RELEASE SOFTWARE (fc1)

Router uptime is 1 hour, 31 minutes

System returned to ROM by reload

System image file is "flash:c2600-io3-mz.123-3.bin"

cisco 2620 (MPC860) processor (revision 0x600) with 28672K/4096K bytes of memory.

Processor board ID JAD05230548 (3698220586)

M860 processor: part number 0, mask 49

Bridging software.

X.25 software, Version 3.0.0.

1 FastEthernet/IEEE 802.3 interface(s)

2 Serial network interface(s)

32K bytes of non-volatile configuration memory.

8192K bytes of processor board System flash (Read/Write)

Configuration register is 0x2101

Router#wr t

Building configuration...

Current configuration : 638 bytes


version 12.3

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption


hostname Router






no aaa new-model

ip subnet-zero




ip audit notify log

ip audit po max-events 100

no ftp-server write-enable





interface FastEthernet0/0

ip address

duplex auto

speed auto


interface Serial0/0

ip address

no fair-queue


interface Serial0/1

no ip address



ip http server

ip classless

ip route




line con 0

line aux 0

line vty 0 4





Router#sh ip route

Codes: 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

Gateway of last resort is not set is subnetted, 1 subnets

C is directly connected, FastEthernet0/0 is subnetted, 1 subnets

C is directly connected, Serial0/0


I have this problem too.
0 votes
Correct Answer by sundar.palaniappan about 9 years 7 months ago

Shouldn't the next hop IP for the static route be pointing to Is it a typo?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Correct Answer
sundar.palaniappan Mon, 02/05/2007 - 10:52

Shouldn't the next hop IP for the static route be pointing to Is it a typo?

mmorris11 Mon, 02/05/2007 - 11:01

Yes it is a typo. Arg. I just couldn't see it! I had a intern doing a simple lab and came up wit this issue. I think that this is instructive though; seeing that a static route pointing to a destination not on an adjacent interface will not put anything in the route table. I guess that is a nice feature of IOS to keep from blackholing routes that might get learned some other way. Thanks Sundar.


Richard Burts Mon, 02/05/2007 - 11:54


Perhaps a bit of clarification is in order. You say: "a static route pointing to a destination not on an adjacent interface will not put anything in the route table". This is not quite the right understanding. It is not a question of adjacent interface, but is a question of whether the next hop is reachable. It is quite reasonable and functional to configure static routes with next hop addresses that are several hops away, as long as the next hop addressses are reachable. This is called a recursive lookup.

I recently had an experience that shows how and why someone might do this. There was a remote router which had a static default route configured using a next hop address which was a loopback interface on the enterprise border router which was several hops away. As long as the internal routing protocol was advertising the address of the border router, the remote router had a default route and would forward traffic. But if the border router did not appear to be reachable then the remote did not forward.

So in your situation if there had been something (another static route or a dynamic route) that made seem reachable then the route would have been put into the routing table.



sundar.palaniappan Mon, 02/05/2007 - 12:07


Thanks for rating the post.

Rick is correct in that the next hop IP need not be a directly connected device. The reason I didn't get into all that is because it clearly looked like a case of typo.

In your case if you had a static route for reachable via the static route you originally had in there would have showed up in the routing table. The router would have performed recursive route lookup to forward the traffic. As Rick explained there are some valid reasons for using a next-hop that's not directly connected but your case doesn't look like it needs one though.



mmorris11 Mon, 02/05/2007 - 12:07

Point taken. That is a good clarification. Thank you.

As for the sample application for recursive lookup, could this be described as sort of poor man's object tracking? Meaning that the strategy is to track the status of the far end device?

Richard Burts Mon, 02/05/2007 - 12:13


In some sense the recursive lookup of a remote next hop address could be seen as the beginning step in object tracking.




This Discussion