[c-nsp] Different behaviour for static route on different IOS?

Oliver Boehmer (oboehmer) oboehmer at cisco.com
Wed Feb 16 04:18:33 EST 2005


In general it is expected behaviour (and, as far as I recall, day-one
behavior) that the next-hop is recursively looked up in the RIB.
Assuming CEF is enabled, this process is done at the time the prefix is
installed in the FIB, and it even does more than one recursion (i.e.
when "ip route A B" is entered, and B is known via C and C via D, a FIB
entry "A->D" is installed, I think up to 6 or 8 recursions).

The behavior reported by Gert in 12.0 with "classful" route looks like a
corner case (i.e. "ip route 192.168.0.1 255.255.255.0 192.168.20.1" and
the only route known is 192.168.0.0/16.

If you do not want this, nail the route to an interface..

	oli


chooweikeong at pacific.net.sg <> wrote on Wednesday, February 16, 2005
4:00 AM:

> Hi,
> 
> Perhaps someone from cisco can help to verify and let us know the
> exact behaviour?
> 
> It's would be quite disastrous when the static route is still active
> when the interface is down...
> 
> I guess have to change to "ip route <addr> <mask> <interface>
> <next-hop>" to make sure everything works...
> 
> Rgds,
> Wei Keong
> 
> On Tue, 15 Feb 2005, Gert Doering wrote:
> 
>> Hi,
>> 
>> On Tue, Feb 15, 2005 at 08:25:29AM -0800, Tim Bulger wrote:
>>> Thanks, but we are discussing static routes, not BGP learned routes.
>>> Obviously recursive next hop lookup is necessary for BGP as that is
>>> how the protocol is designed.
>> 
>> The forwarding part of the machine doesn't care where the route came
>> from. 
>> 
>> Besides that, it doesn't need to be so complicated - *every* route
>> that points to a gateway IP address (as opposed to "to an
>> interface") is recursive: 
>> 
>> interface eth0
>>   ip address 10.1.1.1 255.255.255.0
>> 
>> ip route 0.0.0.0 0.0.0.0 10.1.1.2
>> 
>> - that's already recursive routing.  With static.
>> 
>>> Wei's example clearly illustrates different behavior between IOS
>>> versions regarding static routes.  In the 12.0 example, there is no
>>> recursive next hop lookup taking place for the static.  In the 12.3
>>> example, there is. 
>> 
>> It's funny indeed, and classful stuff seems to play a role here.
>> 
>> I've done some experimenting with 12.0(27) right now, and the
>> specific behaviour depends on the target IP - if route and gateway
>> in the same "class A" (10.44.44.0/24 -> 10.0.0.1), the route will
>> not be used, but 
>> if it's a different network (10.44.44.0/24 -> 192.168.0.1), it *will*
>> be used:
>> 
>> Cisco#sh ip route 10.44.44.0
>> Routing entry for 10.44.44.0/24
>>  Known via "static", distance 1, metric 0
>>  Routing Descriptor Blocks:
>>  * 192.168.0.1
>>      Route metric is 0, traffic share count is 1
>> 
>> Cisco#sh ip route 192.168.0.1
>> Routing entry for 192.168.0.0/16, supernet
>>  Known via "eigrp 99", distance 170, metric 1807872, type external 
>>  Redistributing via eigrp 99 Last update from 195.30.X.X on
>> Serial3/0, 5w2d ago 
>> 
>> funny stuff.
>> 
>> It's *great* that this has been cleaned up, to work in a
>> deterministic and not classful-addressing-related way.
>> 
>> gert
>> --
>> USENET is *not* the non-clickable part of WWW!
>>                                                          
>> //www.muc.de/~gert/ Gert Doering - Munich, Germany                  
>> gert at greenie.muc.de fax: +49-89-35655025                       
>> gert at net.informatik.tu-muenchen.de 
>> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



More information about the cisco-nsp mailing list