From: Nathan Chessin (nchessin@cisco.com)
Date: Tue Nov 05 2002 - 20:55:22 GMT-3
Joe,
I don' t think there is a time you should "always" do something that is
optional. Next-hop-self is a way to make sure and iBGP relationship forms
because of iBGP requirements. If there isn't a NHS statement on iBGP peers,
then you would have to use a static route, or else redistribute the eBGP
interface into the routing protocol running within your AS.
Next-hop-self is easier, and doesn't get into confusing redistribution or
network statement into BGP.
Nate
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Joe Martin
> Sent: Tuesday, November 05, 2002 3:11 PM
> To: peter; Jim Terry
> Cc: ccielab@groupstudy.com
> 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