From: Vikas Gupta (vicky_gupta1803@xxxxxxxxx)
Date: Mon Feb 05 2001 - 13:38:39 GMT-3
This is the expected behavior as condeferation keeps
LP, MED and *next-hop* as the route propogates between
Sub-AS. Use next-hop-self on neighbor statements
pointing towards your Sub-AS border routers or make
sure that your sub-AS can reach the DMZ.
See Halabi Pg. 263 Para 2 under Confederation 1st Ed.
HTH
Vikas
--- Robert DeVito <robertdevito@hotmail.com> wrote:
> I also noticed, could be wrong, that the next-hop
> stays the same throughout
> all your "BGP confederation peers". Has anyone else
> notice this? So if have
> three AS's 1022,1033,1044 and all of them are
> confederated to AS 1, the next
> hop will be constant throughout AS's 1022,1033,1044.
> Thoughts?
>
> Robert
>
>
> ----Original Message Follows----
> From: "Chris Mott" <cmott@home.com>
> Reply-To: "Chris Mott" <cmott@home.com>
> To: "CCIE" <ccielab@groupstudy.com>
> Subject: RE: BGP Next hop self
> Date: Mon, 5 Feb 2001 08:29:52 -0600
>
> I've noticed the same thing ... fortunately the lab
> I was working had the
> next-hop route (2 hopa away, of course) in the IGP,
> so it worked, but I
> wonder how one would deal with this without an IGP
> to save the day ... any
> thoughts?
>
> -----Original Message-----
> From: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com]On Behalf Of
> Connary, Julie Ann
> Sent: Monday, February 05, 2001 8:17 AM
> To: Jeremy Gray
> Cc: Fred Ingham; Alan Basinger; CCIE Newsgroup
> (E-mail)
> Subject: RE: BGP Next hop self
>
>
> 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....
> >
>
=== message truncated ===
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:28:39 GMT-3