From: Erick B. (erickbe@yahoo.com)
Date: Thu Nov 07 2002 - 02:17:23 GMT-3
Just a note on this, with confederations eBGP
connections between ASs in the confed the next-hop
doesn't change by default and behaves like iBGP.
Erick
--- Peter van Oene <pvo@usermail.com> wrote:
> 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