RE: Weird BGP Behaviour

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

Blogs and organic groups at http://www.ccie.net
Received on Sun Oct 10 2010 - 15:01:02 ART