Re: Advertising local host routes in BGP?

FTR, I was *not* able to reproduce the problem using statics to interface.
I think that the referred CEF problem needs a *default* route to
interface to be triggered.
You may be hunting in the wrong cave :)
-Carlos

Jeffrey Pazahanick @ 6/05/2010 17:53 -0300 dixit:
> That is very interesting...
>
> Anyone have an ASR1k running 2.5.2 laying around to test? :)
>
> On Thu, May 6, 2010 at 3:39 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar> wrote:
>> Using a 2811:
>>
>> PSTN1(config)#int f 0/0
>> PSTN1(config-if)#ip add 192.168.1.241 255.255.0.0
>> PSTN1(config-if)#no shut
>> PSTN1(config-if)#
>> *May 6 20:47:20.373: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed
>> state to up
>> *May 6 20:47:21.373: %LINEPROTO-5-UPDOWN: Line protocol on Interface
>> FastEthernet0/0, changed state to up
>> PSTN1(config-if)#end
>> PSTN1#
>> *May 6 20:47:26.533: %SYS-5-CONFIG_I: Configured from console by console
>> PSTN1#
>> PSTN1#ping 192.168.0.1
>>
>> Type escape sequence to abort.
>> Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
>> .!!!!
>> Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms
>> PSTN1#conf t
>> Enter configuration commands, one per line. End with CNTL/Z.
>> PSTN1(config)#ip route 192.168.0.1 255.255.255.255 192.168.0.1
>> PSTN1(config)#end
>> PSTN1#ping 192.168.0.1
>> *May 6 20:48:19.337: %SYS-5-CONFIG_I: Configured from coconf t
>> PSTN1#ping 192.168.0.1
>>
>> Type escape sequence to abort.
>> Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
>> !!!!!
>> Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
>> PSTN1#sh ip route
>> Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
>> D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
>> N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
>> E1 - OSPF external type 1, E2 - OSPF external type 2
>> i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
>> ia - IS-IS inter area, * - candidate default, U - per-user static
>> route
>> o - ODR, P - periodic downloaded static route
>>
>> Gateway of last resort is not set
>>
>> 192.168.0.0/32 is subnetted, 1 subnets
>> S 192.168.0.1 [1/0] via 192.168.0.1
>> C 192.168.0.0/16 is directly connected, FastEthernet0/0
>>
>> PSTN1#sh ip cef 192.168.0.1
>> 192.168.0.1/32, version 10, epoch 0
>> 0 packets, 0 bytes
>> via 192.168.0.1, 0 dependencies, recursive
>> unresolved
>> PSTN1#ping 192.168.0.1
>>
>> Type escape sequence to abort.
>> Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
>> !!!!!
>> Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
>> PSTN1#sh ver
>> Cisco IOS Software, 2800 Software (C2800NM-ADVENTERPRISEK9_IVS-M), Version
>> 12.4(9)T7, RELEASE SOFTWARE (fc3)
>> Technical Support: http://www.cisco.com/techsupport
>> Copyright (c) 1986-2008 by Cisco Systems, Inc.
>> Compiled Thu 10-Jan-08 16:36 by prod_rel_team
>> ...
>>
>>
>> So it seems it's either architecture or IOS version dependent.
>>
>>
>> Jeffrey Pazahanick @ 6/5/2010 12:14 -0300 dixit:
>>> Carlos,
>>> What platform did you test a static route pointing to a host on a
>>> locally connected network?
>>> I'm labbing this on 1841s add get the following:
>>>
>>> R1(config)#do ping 1.1.1.5
>>>
>>> Type escape sequence to abort.
>>> Sending 5, 100-byte ICMP Echos to 1.1.1.5, timeout is 2 seconds:
>>> !!!!!
>>> Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
>>> R1(config)#ip route 1.1.1.5 255.255.255.255 1.1.1.5
>>> R1(config)#do ping 1.1.1.5
>>> *May 6 15:14:52.925: RT: network 1.0.0.0 is now variably masked
>>> *May 6 15:14:52.925: RT: add 1.1.1.5/32 via 1.1.1.5, static metric [1/0]
>>> *May 6 15:14:52.925: RT: NET-RED 1.1.1.5/32
>>> *May 6 15:14:53.021: RT: recursion error routing 1.1.1.5 - probable
>>> routing loop
>>> R1(config)#do ping 1.1.1.5
>>>
>>> Type escape sequence to abort.
>>> Sending 5, 100-byte ICMP Echos to 1.1.1.5, timeout is 2 seconds:
>>>
>>> *May 6 15:14:54.677: RT: recursion error routing 1.1.1.5 - probable
>>> routing loop
>>> *May 6 15:14:54.677: RT: recursion error routing 1.1.1.5 - probable
>>> routing loop.
>>> *May 6 15:14:56.677: RT: recursion error routing 1.1.1.5 - probable
>>> routing loop
>>> *May 6 15:14:56.677: RT: recursion error routing 1.1.1.5 - probable
>>> routing loop
>>> *May 6 15:14:56.677: RT: recursion error routing 1.1.1.5 - probable
>>> routing loop.
>>> *May 6 15:14:58.677: RT: recursion error routing 1.1.1.5 - probable
>>> routing loop
>>> *May 6 15:14:58.677: RT: recursion error routing 1.1.1.5 - probable
>>> routing loop
>>> *May 6 15:14:58.677: RT: recursion error routing 1.1.1.5 - probable
>>> routing loop.
>>> *May 6 15:15:00.677: RT: recursion error routing 1.1.1.5 - probable
>>> routing loop
>>> *May 6 15:15:00.677: RT: recursion error routing 1.1.1.5 - probable
>>> routing loop
>>> *May 6 15:15:00.677: RT: recursion error routing 1.1.1.5 - probable
>>> routing loop.
>>> *May 6 15:15:02.677: RT: recursion error routing 1.1.1.5 - probable
>>> routing loop
>>> *May 6 15:15:02.677: RT: recursion error routing 1.1.1.5 - probable
>>> routing loop
>>> *May 6 15:15:02.677: RT: recursion error routing 1.1.1.5 - probable
>>> routing loop.
>>> Success rate is 0 percent (0/5)
>>>
>>>
>>> On Mon, Apr 26, 2010 at 3:32 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>
>>> wrote:
>>>> Have you been able to reproduce the issue in a lab environment ?
>>>> Because the statics pointing to the next hop should take care of the CEF
>>>> problem if I understood it...
>>>>
>>>> -Carlos
>>>>
>>>> Jeffrey Pazahanick @ 26/04/2010 17:28 -0300 dixit:
>>>>> The topology is like this:
>>>>>
>>>>> upstream peer upstream peer
>>>>> | |
>>>>> -------------------------------------------
>>>>> | |
>>>>> R1 (1.1.1.2) R2 (1.1.1.3)
>>>>> | g0/0 | g0/0
>>>>> -------------------------------------------
>>>>> |
>>>>> host (1.1.1.5)
>>>>>
>>>>> The issue I had was related to the CEF issue I mentioned when using
>>>>> static routes pointing to an interface, so I need find a different way
>>>>> of advertising host routes into BGP from a local network.
>>>>>
>>>>>
>>>>> On Thu, Apr 22, 2010 at 7:20 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar>
>>>>> wrote:
>>>>>> Would you please repost your original topology and perceived problem ?
>>>>>> I got carried away because of your reference to the CEF issue, but
>>>>>> you have provided not enough info to actually reproduce your situation.
>>>>>>
>>>>>> -Carlos
>>>> --
>>>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>>>
>> --
>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net