From: Hamele Kassa (hkassa@attrmc.net)
Date: Tue Nov 05 2002 - 21:15:27 GMT-3
neighbor x.x.x.x next-hop self" should be used for IBGP peers.
HK
----- Original Message -----
From: "Joe Martin" <jmartin@capitalpremium.net>
To: "peter" <pvo@usermail.com>; "Jim Terry" <jtixthus@attbi.com>
Cc: <ccielab@groupstudy.com>
Sent: Tuesday, November 05, 2002 6:10 PM
Subject: RE: BGP on NBMA
> Peter,
>
> If I understand your statement on the use of next-hop self command, I
should
> always use the command "neighbor x.x.x.x next-hop self" for all EBGP
peers.
> Is this a correct statement? If so, does this also apply to
> inter-confederation peers?
>
> Thanks in advance.
>
> Joe Martin
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> peter
> Sent: Tuesday, November 05, 2002 10:12 AM
> To: Jim Terry
> Cc: ccielab@groupstudy.com
> Subject: Re: BGP on NBMA
>
>
> On Tue, 2002-11-05 at 16:03, Jim Terry wrote:
> > Hi all/Pete,
> >
> > It looks like this is slowly being solved.
> >
> > #1-First it was a problem with my layer 2 connectivity. I had my frame
> map
> > statements entered incorrectly on my NBMA network
> >
> > #2- I appear to have a loop in my routing table caused by a triple
> > redistribution problem on one of the routers and no distribute list to
> stop
> > the feedback :( .
> >
> > 3- curious still as to your comment on the next hop self pertaining to
> IBGP
> > and not EBGP. I specifically got the next hop self from the BGP Case
> Study
> > #2 on CCO about multiple ASs in an NBMA network. Did I read that
> > incorrectly? Are you saying that you only use the next hops self
command
> > w/in IBGP? What do you mean by reset next hop for EBGP?
>
> Next-Hop Self is used on EBGP learned prefixes to enable IBGP
> reachability so it might be somewhat ambiguous in various definations.
> My comment was that it wasn't going to help extra AS routers resolve
> next hops from a given router.
>
> By reset I was referring the fact that a bgp speaker must reset the BGP
> next-hop attribute with his address upon transmission. In other words,
> when sending an EBGP update, it is normal and indeed mandatory to do
> "next-hop self" whereas on an IBGP update, it is optional.
>
> Pete
>
>
>
> > Thanks,
> >
> > JT
> >
> > ----- Original Message -----
> > From: "Peter van Oene" <pvo@usermail.com>
> > To: <ccielab@groupstudy.com>
> > Sent: Tuesday, November 05, 2002 5:48 AM
> > Subject: Re: BGP on NBMA
> >
> >
> > > At 11:23 AM 11/4/2002 -0800, Jim Terry wrote:
> > > >Hi all,
> > > >
> > > >I have another BGP question on an NBMA network.
> > >
> > > BGP runs over TCP and so long as you have IP reach ability, the L2
> > topology
> > > shouldn't matter
> > >
> > > >All spokes and hub are running OSPF and there is proper connectivity.
> > > >The hub is one AS and the spokes are in a different AS.
> > >
> > > I must say this is a bizarre setup.
> > >
> > > >I can ping the loopbacks for all OSPF advertised interfaces but
cannot
> > ping
> > > >the loopbacks that are advertised in BGP with the network command.
It
> > does
> > > >not matter if I am pinging spoke to spoke(same AS) or spoke to
> > hub(different
> > > >AS)
> > >
> > > As with your last example, did you verify:
> > >
> > > a) appropriate routes are in the bgp table (show ip bgp)
> > > b) BGP next-hop is reachable
> > > c) appropriate routes are in the local rib (show ip route)
> > >
> > > Keep in mind this is bi-directional and you'll need to make sure that
> your
> > > destinations can respond to the source of your pings.
> > >
> > >
> > > >I do have in BGP the next-hop-self from the hub to one spoke. That
one
> > > >spoke is the route-reflector for the other spokes. Spoke to spoke
> > > >connectivity is only via the serial links in the NBMA through the
hub.
> > >
> > > Next-hop Self is an IBGP function and does not relate to EBGP
peering.
> > In
> > > EBGP, you must reset next-hop. Are your spoke to spoke peerings
> > > established? What do the adj-rib in/outs look like (show ip bgp
> neighbor
> > > x.x.x.x. advertised-routes / received routes)
> > >
> > >
> > > >Does anyone have any ideas?
> > >
> > > You really need to step through a logical debugging process here much
> like
> > > you would any reach ability problems. BGP adds the additional steps
of
> > > verifying peering, route advertisement / reception, BGP next-hop
> > > resolution, and sync if you have it enabled.
> > >
> > > >JT
> > >
> > > Pete
This archive was generated by hypermail 2.1.4 : Tue Dec 03 2002 - 07:22:53 GMT-3