From: Connary, Julie Ann (jconnary@xxxxxxxxx)
Date: Mon Feb 05 2001 - 11:16:41 GMT-3
Hi All,
I have also noticed the following about "next hop self". If you have
route-relflectors to
not have a full mesh. You receive an EBGP route on router A, you have
next-hop-self and it is sent
to the IBGP peer - router B with router A as the next hop. That IBGP -
router B - reflects the route to
another IBGP peer - router C. "Next-hop-self" does not work on the
route-reflector, it maintains
the next hop as router- A that originally received the external route. I
have not played
with confederations yet. This week.
Julie Ann
At 11:38 AM 2/4/2001 +0000, Jeremy Gray wrote:
>Here's a few tips.
>
>Next-hop-self - This typically being for IBGP sessions. EBGP will have your
>outbound interface as the update-source for each update by default.
>
>You simply set this instead of advertising the subnet of the EBGP peer(s)
>into your IGP.
>
>For example lets say you're an ISP at LINX. You can either advertise the
>linx subnet in your IGP (redist connected, etc ) ; so that your IBGP peers
>who receive this update have the source (the external LINX LAN) subnet in
>their routing table and can therefore treat the EBGP routes from any LINX
>peers as valid (since the next hop reachable)....
>
>OR...
>
>You can set next-hop-self on the IBGP sessions to your IBGP peers on the
>assumption they know how to get to you... Because your source address is
>known or adverised in the IGP already.
>
>When you may not to use NEXT-HOP-SELF on an IBGP session...
>
>If you have a pair of routers on a shared NAP (say MEA-EAST1 and MEA-EAST2)
>it may be more efficient to retain the EBGP next-hop when you advertise
>these routes to your IBGP peers.
>
>This is becuase ...When packets are then routed towards these routes they
>can then flow back to both of you border routers rather than 'one'. For
>example even if the original EBGP peering session was on your MEA-EAST1
>router, they can leave via MEA-EAST2, if the external nexthop route being
>followed via each routers recursive lookup used the best metric back to
>'mae-east subnet' instead of a specific host address. This is of course
>touching on design issues...
>
>When you don't care about the next-hop...
>
>If the EBGP peer is via a point-to-point subnet it makes no odds.. but you
>still MUST do one or the other, route the EBGP peers subnet or use
>next-hop-self.
>
>
>
>SYNC.
>
>A somehwat inappropraite default these days... Use this only if your EBGP
>peers are seperated with none-BGP router hops in your AS. And then
>redistributed the BGP routes into the IGP, the tow statements really go
>together SYNC = (redistributed into you IGP). Clearly this has limited
>value in the real world. The internet now has over 90k routes and even the
>most robust IGP's are going to have trouble. In reality if you had to do
>this with teh entire internet, you'd need big-monster routers anyway - so
>you may as well run BGP on them, then you're back to "NO SYNC", since you
>really don't want to kill your IGP.
>
>In a lab scenario ... or other non INTERNET-SCALE network...
>
>EBGP routers are seperated by none-BGP routers. The none-BGP routers need to
>have the same routes, so that if a BGP router forwards a packet via one of
>these routers the receiving router has somewhere they can send it (other
>than the bit bucket). The problem is that the EBGP router needs to know
>when the none BGP routers "are ready" to forward packets. Therefore they
>wait until they can see the routes in the IGP before they do. And thus they
>are then "synchronised" with teh IGP and can actually use the BGP routes to
>forward packets. Likewise they can then also advertise all synchronised
>routes to other EBGP peers as each route becomes 'synchronised'.
>
>
>NO SYNC.
>
>All routers between EBGP routers run BGP. THerefore packets routed across
>your network will be routable on each hop, since each hop as the full BGP
>routing table. No need to check if the route is in the IGP, coz its not.
>The the real world this is what you'll use.
>
>Update-source.
>
>Its a good common practice to set update-soure between IBGP peers to the
>loopbacks and this is useful when your routers have multiple interfaces
>because it creates resilience if an interface fails. The neighbor statement
>to the to remote peer therefore points to your loopback address, and your
>neighbor statement points to theirs and you both use update-source loopbackN
>
>Hopefully this clarifies rather than complicates....
>
>Regards, Jeremy.
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>Fred Ingham
>Sent: 04 February 2001 03:06
>To: Alan Basinger
>Cc: CCIE Newsgroup (E-mail)
>Subject: Re: BGP Next hop self
>
>
>Alan: On the r1 neighbor statement only, assuming that r1 does not have
>the subnet between
>r2 and r3 in its routing table. You could also redistribute the r2-r3
>subnet into the r1-r2
>IGP. What did you see when you tried this out?
>
>Fred.
>
>Alan Basinger wrote:
> >
> > Hi all,
> > With only 2 weeks till me second attempt I am now in the panic mode.
> > Here is my question.
> >
> > r1 ------- r2 ------- r3
> >
> > r1 being in bgp as 10 and r3 being in bgp as 20 and r2 is the border
>router.
> > Would I use the bgp next hop self command on r2 pointing to both r1 and
>r3?
> >
> > Alan Basinger
> > Systems Engineer
> > SBC DataComm
> > Houston Texas
> > abasinge@swbell.net
> >
> > | |
> > ||| |||
> > .|||||. .|||||.
> > .:|||||||||:.:|||||||||:.
> > C i s c o S y s t e m s
> > Certified Gold Partner
> >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:28:37 GMT-3