Static Route Not Appearing In Routing Table.

[rob_lay]

Hi. I have an issue with a 2800 series with a basic configuration on it. we have a situation where by the router is connected to a subnet (10.32.1.0/24) via int FA0/0. This is a management link to a customers site to which all the customers equipment sends snmp traps for monitoring purposes. The actual destinaion servers 10.32.1.3 & 10.32.1.4 are actually situated at the other end of a serial link to the router. On the router the following static routes are configured: ip route 10.32.1.3 255.255.255.255 192.168.95.129 (the next hop) and ip route 10.32.1.4 255.255.255.255 192.168.95.129. These syntaxes are identical except for the host digit. The 1.3 static route appears in the routing table and traffic is routed correctly,

router#show ip route 10.32.1.3

Routing entry for 10.32.1.3/32

Known via "static", distance 1,metric 0

Routing Descriptor Blocks:

* 192.168.95.129

Route metric is 0, traffic share count is 1

However the static route for 1.4 is not placed in the routing table and when searched the routing table provides the longest prefix match it has, which is the interface on a 24 bit mask:

router#show ip route 10.32.1.4

Routing entry for 10.32.1.0/24

Known via "connected", distance 0, metric 0 (connected, via interface)

Routing Descriptor Blocks:

* directly connected, via FastEthernet0/0

Route metric is 0, traffic share count is 1.

Whilst I appreciate this is an unusual way of going about the routing it has been forced due to legacy configurations. My problem is why does one static route appears in the table and not the other. Has anyone else seen this problem before and can anyone help please?? any help would be gratefully received.

[P_Tone ATG]

This is crazy old but gets a lot of views and there is a different way to do this. 

An alternative to specifying an interface which may not work if your interface isn't layer 3 is to use the "permanent" option on your route command. 

[Richard Burts]

This is an interesting theory. But I do not believe that it would solve the issue. Normal behavior is that if you have a static route in the forwarding table and the next hop becomes unavailable then the static route is removed from the table. Using the permanent parameter changes the behavior so that even if the next hop becomes unavailable the static route will be maintained in the table.

But the issue here is not about the next hop availability. The issue is that IOS has two entries for the same prefix. It has 10.32.1.4/32 as a static route and 10.32.1.4/32 as a connected route of the interface address. With these prefixes IOS chooses the connected one and I do not believe that adding permanent to the static would change this.

HTH

Rick