[67617] in North American Network Operators' Group
Re: BGP - weight
daemon@ATHENA.MIT.EDU (Sven Huster)
Sat Feb 14 13:53:46 2004
Date: Sat, 14 Feb 2004 18:52:47 +0000
To: "Stephen J. Wilcox" <steve@telecomplete.co.uk>
Cc: nanog@merit.edu
Mail-Followup-To: sven@trapdoor.merit.edu,
"Stephen J. Wilcox" <steve@telecomplete.co.uk>, nanog@merit.edu
In-Reply-To: <Pine.LNX.4.44.0402141346590.30014-100000@server2.tcw.telecomplete.net>
From: Sven Huster <sven@huster.me.uk>
Errors-To: owner-nanog-outgoing@merit.edu
On Sat, Feb 14, 2004 at 01:49:05PM -0500, Stephen J. Wilcox wrote:
> On Sat, 14 Feb 2004, Sven Huster wrote:
>
> >
> > On Sat, Feb 14, 2004 at 12:46:09PM -0500, Stephen J. Wilcox wrote:
> > > > Dumb question:
> > > > If I apply a equal weight to all our transit/peers, will
> > > > that affect route announcements to iBGP or eBGP peers anyhow?
> > >
> > > No it wont affect announcements, weight is local to the router you apply it.
> > >
> > > > What I want to achieve is that traffic leaves through
> > > > the border router it arrived, rather than have it bounced around.
> > >
> > > eBGP should be preferred over iBGP anyhow assuming all other things are equal,
> > > if theyre not equal then either make them equal or you probably want to choose a
> > > different path anyhow (eg shorter as path).
> > >
> > > if you dont want any traffic to go across your network why bother meshing the
> > > ibgp in the first place?
> >
> > Just to make it a bit more clear:
> >
> > Transit1 Peers Transit2 Peers Customers via BGP
> > | | | | |
> > ----R1---- ----R2---- R3
> > | | |
> > | | |
> > | | |
> > ---------------------Core---------------------
> > |
> > |
> > Data Center
> >
> > Full-mesh between R1,R2,R3 and Core
> >
> >
> > We carry traffic from the DC as well as the customers in the core to transit and peers.
> > We normally want to advertise full routes to customers, which are multi-homed.
> >
> > >
> > > > We had some recent issues were it looks like the core got "out of sync" with
> > > > the border (looks more like a sw issue than just convergence delay) and
> > > > packets bounced back and forth between them. I know this doesn't solve the
> > > > cause but the before digging for the initial reason I want a quick workaround.
> > >
> > > hmm, i'd suggest emergency maintenance before doing some weird screwy stuff like
> > > that :)
> >
> > The thing that happend was that the core believed that the best path out is via
> > R1, which R1 thought it was via R2. So a little loop there.
> >
> > We weren't able to reproduce the problem nor to find a source yet.
>
> Is this all the same vendor hardware?
Nope.
R1-3 - Cisco
Core - Extreme Alpine 3808
>
> Check the bgp configs are identical eg deterministic-med, dampening,
> always-compare-med etc are all configured the same..
I'll have a look there.
Thanks
Sven
