RE: BGP on NBMA

From: Peter van Oene (pvo@usermail.com)
Date: Wed Nov 06 2002 - 06:25:08 GMT-3


I may have confused some with my last statement. The Next-Hop attribute
is not modified in IBGP updates, but MUST be modified in EBGP updates.
However, these actions are the responsibility of the BGP implementation
itself, not you as the operator. As an operator, you have the
opportunity to override this behavior and change the next-hop attribute
in IBGP updates. However, there is no need to manually configure
anything next-hop related for EBGP connections.

Pete

On Tue, 2002-11-05 at 18:10, Joe Martin wrote:
> 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:54 GMT-3