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

[Hyunseog Ryu]

I used to program load-balance using static routing like this.

ip route 10.0.0.0 255.255.255.0 1.1.1.2
ip route 10.0.0.0 255.255.255.0 2.2.2.2

When the interface for 1.1.1.2 went down, routing for 10.0.0.0/24 was
pointing to 2.2.2.2 AND next-hop for default route.
Since Cisco deployed recursive lookup for next hop, if you have default
route or aggregate route from BGP, it will point to the next hop ip 
address for those.

Hyun



Rey Martin wrote:
> ok now Im curious how the recursive routing can affect load balancing 
> over multiple connection?
> any example?
> but Im agree that it could cause some unexpected behaviour.
> 
> 
> ----- Original Message ----- From: "Hyunseog Ryu" <r.hyunseog at ieee.org>
> To: <chooweikeong at pacific.net.sg>
> Cc: <cisco-nsp at puck.nether.net>
> Sent: Tuesday, February 15, 2005 1:00 PM
> Subject: Re: [c-nsp] Different behaviour for static route on different IOS?
> 
> 
>> I believe I had same issue around that version.
>> Cisco started to implement recursive lookup for next hop,
>> so load balancing over multiple connections didn't work.
>> Therefore since then, using interface name was mandatory solution.
>> I've been spent a lot of time with Cisco TAC, and they had no clue.
>>
>> Hyun
>>
>>
>> chooweikeong at pacific.net.sg wrote:
>>
>>> Hi All,
>>>
>>> Realise that there is a different behaviour for static route 
>>> (next-hop to
>>> an interface ip) on IOS 12.3 and 12.0.
>>>
>>> As shown below, i've a static route next-hop to an interface ip, and the
>>> interface has been shutdown. For 12.0, the static route is not 
>>> active, but
>>> for 12.3, the static route is active, even though the interface is down.
>>>
>>> Is this a 'new' feature? Since when is this feature introduced?
>>>
>>> Appreciate your feedback.
>>>
>>> Thanks,
>>> Wei Keong
>>>
>>>
>>> IOS Ver 12.3(10)
>>> ----------------
>>>
>>> Serial5/0.1/1/3/1:8   192.168.16.49  YES manual administratively down 
>>> down
>>>
>>> ip route 10.0.200.120 255.255.255.252 192.168.16.50
>>>
>>>
>>>
>>>> sh ip route 10.0.200.120
>>>
>>>
>>> Routing entry for 10.0.200.120/30
>>>    Known via "static", distance 1, metric 0
>>>    Redistributing via ospf 10
>>>    Advertised by ospf 10 subnets
>>>    Routing Descriptor Blocks:
>>>    * 192.168.16.50
>>>        Route metric is 0, traffic share count is 1
>>>
>>>
>>>
>>>> sh ip route 192.168.16.50
>>>
>>>
>>> Routing entry for 192.168.16.0/21, supernet
>>>    Known via "ospf 10", distance 110, metric 20, type extern 2, 
>>> forward metric 1
>>>    Last update from 10.9.1.6 on GigabitEthernet0/1, 6d22h ago
>>>    Routing Descriptor Blocks:
>>>    * 10.9.1.6, from 192.168.3.6, 6d22h ago, via GigabitEthernet0/1
>>>        Route metric is 20, traffic share count is 1
>>>
>>>
>>> IOS Ver 12.0(22)
>>> ----------------
>>> Serial6/3             192.168.16.49  YES manual administratively down 
>>> down
>>>
>>> ip route 10.0.200.120 255.255.255.252 192.168.16.50
>>>
>>>
>>>> sh ip route 10.0.200.120
>>>
>>>
>>> % Subnet not in table
>>>
>>>
>>>> sh ip route 192.168.16.50
>>>
>>>
>>> Routing entry for 192.168.16.0/21, supernet
>>>    Known via "ospf 10", distance 110, metric 20, type extern 2, 
>>> forward metric 1
>>>    Last update from 10.9.1.6 on GigabitEthernet0/3, 6d22h ago
>>>    Routing Descriptor Blocks:
>>>    * 10.9.1.6, from 192.168.3.6, 6d22h ago, via GigabitEthernet0/3
>>>        Route metric is 20, traffic share count is 1
>>>
>>> _______________________________________________
>>> 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/
>>>
>>>
>>
>>
>> _______________________________________________
>> 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/ 
> 
> 
> 
>