Re: Weird BGP Behaviour

hi Bob,

Very interesting! i have seen different results on 12.3 where the
default was not used for next-hop recursion.
Peering over the default route hasnt changed and never worked afaik.

The only difference i see now is that your default is a static one,
and the one from Garth a OSPF default. Afaik there are no exclusions
to this when it comes to recursion.

Were you able to work this out already Garth? I hope this is not a
dynamips issue?

On 10 October 2010 21:01, Bob Sinclair <bob_at_bobsinclair.net> wrote:
> Hi Garth,
>
> Maybe I have magical routers (I do lead a charmed life), but I am able to
> use a BGP next hop that recurs using a default route.
>
> Below you see the next hop to e.g., 140.10.4.0/24 is 172.40.10.10. This
> route is not in my routing table. The only path to this next hop is the
> default route.
>
> R5#sh ip b
> BGP table version is 13, local router ID is 172.16.105.1
> Status codes: s suppressed, d damped, h history, * valid, > best, i -
> internal,
> r RIB-failure, S Stale
> Origin codes: i - IGP, e - EGP, ? - incomplete
>
> Network Next Hop Metric LocPrf Weight Path
> *>i140.10.4.0/24 172.40.10.10 0 100 0 1581 9999 i
> *>i140.10.5.0/24 172.40.10.10 0 100 0 1581 9999 i
> *>i140.10.6.0/24 172.40.10.10 0 100 0 1581 9999 i
> *>i140.10.7.0/24 172.40.10.10 0 100 0 1581 9999 i
> R5#sh ip b 140.10.4.0
> BGP routing table entry for 140.10.4.0/24, version 10
> Paths: (1 available, best #1, table Default-IP-Routing-Table)
> Flag: 0x820
> Advertised to update-groups:
> 2
> 1581 9999
> 172.40.10.10 from 172.16.65.6 (172.116.1.1)
> Origin IGP, metric 0, localpref 100, valid, internal, best
> R5#sh ip route
>
> Gateway of last resort is 172.16.65.6 to network 0.0.0.0
>
> 140.10.0.0/24 is subnetted, 4 subnets
> B 140.10.6.0 [200/0] via 172.40.10.10, 00:01:54
> B 140.10.7.0 [200/0] via 172.40.10.10, 00:01:54
> B 140.10.4.0 [200/0] via 172.40.10.10, 00:01:54
> B 140.10.5.0 [200/0] via 172.40.10.10, 00:01:54
> 172.16.0.0/24 is subnetted, 13 subnets
> O E2 172.16.34.0 [110/20] via 172.16.15.1, 00:05:51, FastEthernet0/0
> O 172.16.12.0 [110/2] via 172.16.15.1, 00:05:51, FastEthernet0/0
> O E2 172.16.13.0 [110/20] via 172.16.15.1, 00:05:51, FastEthernet0/0
> C 172.16.15.0 is directly connected, FastEthernet0/0
> O E2 172.16.11.0 [110/20] via 172.16.15.1, 00:05:51, FastEthernet0/0
> O E2 172.16.120.0 [110/20] via 172.16.15.1, 00:05:51, FastEthernet0/0
> O E2 172.16.110.0 [110/20] via 172.16.15.1, 00:05:51, FastEthernet0/0
> O E2 172.16.104.0 [110/20] via 172.16.15.1, 00:05:51, FastEthernet0/0
> C 172.16.105.0 is directly connected, Loopback105
> O E2 172.16.101.0 [110/20] via 172.16.15.1, 00:05:51, FastEthernet0/0
> O 172.16.102.0 [110/3] via 172.16.15.1, 00:05:51, FastEthernet0/0
> O E2 172.16.103.0 [110/20] via 172.16.15.1, 00:05:51, FastEthernet0/0
> C 172.16.65.0 is directly connected, FastEthernet0/1
> S* 0.0.0.0/0 [1/0] via 172.16.65.6
> R5#
>
>
> As I recall, BGP will not use a default to a peering address, but it seems
> it will use it for next hop resolution. My IOS is
> (C3725-ADVENTERPRISEK9-M), Version 12.4(15)T11. I think Garth may have
> something else going on.
>
> Best regards,
>
> Bob Sinclair CCIE 10427 CCSI 30427
> CIERS2 Online Instructor
> www.tinyurl.com/ciers2online
>
>
>> -----Original Message-----
>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>> Wouter Prins
>> Sent: Sunday, October 10, 2010 10:24 AM
>> To: Garth Bryden
>> Cc: Cisco certification
>> Subject: Re: Weird BGP Behaviour
>>
>> On 10 October 2010 14:53, Garth Bryden
>> <hacked.the.planet.on.28.8k.dialup_at_gmail.com> wrote:
>> > Hey Group,
>> >
>> > I have a switch running BGP that is doing some weird behaviour, that
>> I just
>> > dont understand....
>> >
>> > I am receiving routes from my neighbor (iBGP) but they will not go
>> into the
>> > route table as they keep coming up that my next hop is inaccessible,
>> but the
>> > next hop is accessible via a default route... will the recursive
>> routing not
>> > function correctly with a default route in use?
>>
>> BGP is not able to use the default route for next-hop recursion, as
>> you found out yourself. ;) This is as expected.
>> To fix it, either set the advertising router to set the next-hop to
>> itself. Or on the receiving router a route-map with set ip next-hop
>> (which may require recursion ;)). Or advertise the subnet/prefix where
>> the next-hop is into your igp.
>>
>> HTH!
>> --
>> Wouter Prins
>> wp_at_null0.nl
>> CCIE #25628
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 9.0.862 / Virus Database: 271.1.1/3188 - Release Date:
>> 10/10/10 02:34:00
>
>

-- 
Wouter Prins
wp_at_null0.nl
Blogs and organic groups at http://www.ccie.net