06-29-2007 12:32 PM - edited 03-03-2019 05:40 PM
I have included a config and the "sho ip route" output of a router that is behaving strangely. As you can see, I have static routes to 65.171.249.0 that don't show in the routing table. I know that sometimes "floating static" routes are hidden by routes inserted by dynamic protocols but this doesn't seem to be the case here. Can anybody shed some light on this?
Thanks,
Diego
Solved! Go to Solution.
06-29-2007 12:54 PM
Diego
I see at least some of the problems with the static routes.
- first lets deal with the route for:
ip route 65.171.249.0 255.255.255.0 206.22.142.253
this does not appear in the routing table because the next hop is not reachable. I wonder if it is a typo mistake and is supposed to be 206.22.143.253
- because this static route would supply the route for the destination address of the tunnel interface, the tunnel will be in a protocol down state.
- because the tunnel is in a protocol down state the static default route (floating) will not work. The issue is not that it is floating but the issue is that the static can not work because the tunnel interface is not up.
[edit] I am surprised at your response which shows the tunnel as up/up. In the config as you posted it I do not see how this would be. If the tunnel destination is not in the routing table the tunnel will not be up/up. And as posted the tunnel destination is not in the routing table. Did something change between the config that you posted and the situation in your response?
HTH
Rick
06-29-2007 12:40 PM
Hi,
For the IP route to be available in the routing table the next-hop must be available (and the outgoing interface must be up/up if the route is configured with the outgoing interface), can you assure this for your desired route.
HTH,
Mohammed Mahmoud.
06-29-2007 12:46 PM
Check and check... See below:
pmp_1710#
pmp_1710#sho ip int bri
Interface IP-Address OK? Method Status Prot
ocol
Ethernet0 10.0.15.1 YES NVRAM up down
FastEthernet0 206.22.143.252 YES NVRAM up up
Tunnel204 10.204.15.2 YES NVRAM up up
pmp_1710#ping 206.22.143.253
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 206.22.143.253, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
pmp_1710#
06-29-2007 12:52 PM
Diego,
The problem is you don't have a specific route to get to 206.22.142.253 (next-hop).
If you are getting to 206.22.142.253 via fastethernet0 then add a static route as follows.
ip route 206.22.142.253 255.255.255.255 206.22.143.242
This would make the router install the 65.171.249.0/24 network to the routing table.
HTH
Sundar
06-29-2007 12:54 PM
Diego
I see at least some of the problems with the static routes.
- first lets deal with the route for:
ip route 65.171.249.0 255.255.255.0 206.22.142.253
this does not appear in the routing table because the next hop is not reachable. I wonder if it is a typo mistake and is supposed to be 206.22.143.253
- because this static route would supply the route for the destination address of the tunnel interface, the tunnel will be in a protocol down state.
- because the tunnel is in a protocol down state the static default route (floating) will not work. The issue is not that it is floating but the issue is that the static can not work because the tunnel interface is not up.
[edit] I am surprised at your response which shows the tunnel as up/up. In the config as you posted it I do not see how this would be. If the tunnel destination is not in the routing table the tunnel will not be up/up. And as posted the tunnel destination is not in the routing table. Did something change between the config that you posted and the situation in your response?
HTH
Rick
06-29-2007 03:48 PM
I guess after staring at the config for soo long you juse lose focus, your eyes glazeover.... The typo ".142" for the next hop was it. I am up and running?
Thank you very much guys!
BTW, the tunnel always showed up/up with no changes in between the first post and the upload of the config.
06-30-2007 05:50 PM
Diego
I am surprised that the tunnel showed up/up even when there was not a valid route to the tunnel destination. My experience over multiple versions of IOS has been that if there was a valid route to the destination (not necessarily that there was connectivity) the tunnel would be up/up and if there was not a valid route to the destination then the tunnel would be up/down.
Thanks for using the rating system to indicate that your issue was resolved (and thanks for the rating). It makes the forum more useful when people can read about an issue and can know that they will read a response that resolved the issue. I encourage you to continue your participation in the forum.
HTH
Rick
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: