Re: Weird BGP Behaviour

Heya,

Nah I was absolutely exhausted last night, went to sleep straight after I
posted that as I couldn't keep my eyes open.

It was actually running on a switch so I believe it'd have been running
version 12.2. It was part of an INE Mock Lab, I initially was just trying to
figure out why my redistribute connected with the route map wasn't working
correctly, since my configuration appeared the same as in the solution guide
and when I initially put the configuration in it was working!

That was when I noticed all this other behaviour as well :-|

On Mon, Oct 11, 2010 at 3:39 AM, Wouter Prins <wp_at_null0.nl> wrote:

> 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
Received on Mon Oct 11 2010 - 08:28:46 ART