From: Joe Martin (jmartin@capitalpremium.net)
Date: Tue Nov 05 2002 - 20:10:33 GMT-3
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