North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: BGP - weight

  • From: Sven Huster
  • Date: Sat Feb 14 13:05:37 2004

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
       |                     |                      |
       |                     |                      |
       |                     |                      |
                         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.

So the plan right now was: if the core decides that traffic should go out via
R1, R1 just just send it out via the best path it got from eBGP.
So that we get some more time for debugging what's going on there.