North American Network Operators Group

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

Re: BGP - weight

  • From: Sven Huster
  • Date: Sun Feb 15 11:52:30 2004

On Sun, Feb 15, 2004 at 04:47:30AM +0000, E.B. Dreger wrote:
> SH> Date: Sat, 14 Feb 2004 18:00:51 +0000
> SH> From: Sven Huster
> SH> The thing that happend was that the core believed that the
> SH> best path out is via R1, which R1 thought it was via R2. So a
> SH> little loop there.
> So core sends to R1, which sends to R2... where does R2 send the
> packets?  Back to R1?

The core sends to R1, which believes the best path is via R2 and
sends it back to the core as that's the only way to reach R2.
Then the core again sends it to R1 and all the same again.

> What are you doing in your IGP?  Are you using { iBGP | OSPF |
> IS-IS | ... }?  How does R1 learn routes from Transit2?

As this is a small network internally everything is routed via
static routes.
R1 and R2 have full BGP views from the transit providers as well
as partial view from the peers. They run iBGP with R3 and the core.

> What about confederations?  Used correctly, they're helpful.
> Used incorrectly in similar scenarios, an iBGP mesh becomes a
> constantly-oscillating iBGP mess.
> Are you using either
> 	router bgp xxxx
> 	 bgp bestpath compare-routerid
> or
> 	router bgp xxxx
> 	 no bgp bestpath compare-routerid
> on all routers?  I'm wondering if R1 prefers Transit2 and R2
> prefers Transit1 due to different path selection algorithms...

All devices use the default settings in this respect.
R1-3 are Cisco routers, the core Extreme Alpine.

> Can you "sh route" or "sh ip bgp" for a route that loops?

It seems to be a temp problem, which we just figured out once
it went away based on netflow data and traffic dumps. So there
is no data available for this right now.