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:
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.
It looks to me as if the router has 10.32.1.4 configured as it's interface address on fa0/0.
No other reason why it should state: connected
Thanks for the quick repsponse.
Unfortunatly thats not the case
Router#show ip int bri
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.32.1.2 YES manual up up
FastEthernet0/1 unassigned YES NVRAM administratively down down
Serial0/2/0 192.168.95.130 YES NVRAM up up
FA0/0 is the ethernet link to the customers network
Serial 0/2/0 is the serial link, the other end of which is 192.168.95.129.
Is the static route showing in the running config?. Try to remove it and add it again.
Watch out for typographical errors.
Watch out also if there is any logged message when the route is added.
Please feed us back
Hi, Thanks for the response.
Yes the static is showing in the show run,
router#show run | include route
ip route 10.32.1.3 255.255.255.255 192.168.95.129
ip route 10.32.1.4 255.255.255.255 192.168.95.129
We have tried the following, we have removed and re-inserted the static, we have tried inserting the route with an interface as the next hop rather than the ip address.
This is puzzling us a lot.
It may be helpful to have the debug output. I would also like to see the router config. I assume that there is something in the config that is causing this.
What you are trying to do isn't possible, you can't have the 10.32.1.0/24 net on your FastEthernet0/0 interface, while routing 2 host addresses out your WAN interface.
That is why you see the two hosts as directly connected.
I'm actually surprised that you see the 10.32.1.3/32 as static via Serial0/2/0.
If you were to shutdown the FastEthernet0/0, I guess you would se both hosts via Serial0/2/0, is that correct?
The one thing I would suggest is to change the static routes to point to Serial0/2/0 instead of the next hop address eg. ip route 10.32.1.4 255.255.255.255 Serial0/2/0, but i doubt it will make any difference.
Actually what he is trying to do is quite possible. You may be thinking that you could not put the other addresses on a different interface (and the IOS will prevent you from putting addresses in the same subnet on different LAN interfaces). But you can certainly define static routes for particular addresses and point them out some other interface. And he does not see the two hosts as directly connected. The one host shows as directly connected because the static route is missing and the router believes that the address is part of the connected subnet.
I would be extremely surprised if changing the static routes from using next hop addresses to using outbound interface would make any difference in this situation.
Well, well what do you know.
Your are right Rburts, I just had time to test it, and it does work.
I guess the only thing left to do for rob-lay, is to try and clear the route table or shutdown the LAN interface to see if the static route for 10.32.1.4 comes up in the routetabel.
Morning All, Thanks for the helpful comments, I have finally managed to resolve this. I had tried clearing the routing table several times, each time one of the 2 routes would appear, but not the other. Having done some more investigation it turns out that a colleuge originally configured the ethernet interface with the IP address 10.32.1.4, and then reconfigured it with the IP address 10.32.1.2(so Leo was actually pretty much right,when he said that he couldn't see any other reason why is would advertise it as directly connected). There was nothing in the config which was causing a problem however the router had not been restarted since he made the configuration change. The old configuration had placed the routing table entry with 10.32.1.4 as the interface address and clearing the routing table from the CLI (using clear ip route * which I believe should clear the entire table??) had no effect. The router has since been rebooted and this entry has now been fully flushed from the table. Working in a live environment meant that the reboot had to be scheduled for out of hours as it was only partially not working and so I was having to try anything else first. I have now learnt the lesson the deffinately reload the routers after significant config changes (probably a best practice anyway?) Thanks again.
just a comment on this statement. I would not reload the router in case everything works. The other thing that could have been tried is to "shut" and "no shut" the interface, which also should remove the entry from the IP routing table. But as the effect observed is not the proper behaviour anyhow, one might also doubt, whether this would have helped.
thats a valid point, and I'm aware that its certainly not always possible to reload routers due to load and usage etc. I might add that I hadn't tried shut / no shut on the router. should have done that to be fair.
Thanks for the pointer.
Thank you Rick. I had had a similar issue that you just resolved for me. I had static routes configured but they did not show in the sh ip route static. Read what you said, tried a sh ip routes connected, and there they were!! Removed the static routes for them. Much appreciated sir!
Thanks for letting me know that my explanation has been helpful. I am always happy when I hear from someone who has found my information beneficial.
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.
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.