weird BGP cisco-ism?

Matthew Kaufman matthew at scruz.net
Fri Jul 11 00:29:38 UTC 1997


Original message <199707110721.HAA01250 at ice.genuity.net>
From: Danny McPherson <danny at genuity.net>
Date: Jul 11,  0:21
Subject: Re: weird BGP cisco-ism?
> 
> 
> if the primary route becomes unavailable and routing falls over to the "nailed 
> up" route, a bgp update is still sent.  (if dampening is enabled) this update 
> is recorded by ebgp peers as a "flap".  i'd guess from your message below that 
> when this occurs your router(s) are also changing the med attached to the 
> prefix, which seems normal to me...

WHAT?!?
This is ridiculous. There *must* be a way to have routes truly "nailed up"
such that flaps do not occur. I have static routes in there precisely
because I want to be friendly and reduce the number of routing announcements
which occur when interfaces transition (I have dozens and dozens of
people with class C networks attached via unreliable dialup lines)

> i'd suggest you have a look at the stability of the interface to which the 
> primary route is attached (?carrier transitions, interface resets, etc...?).  
> you might also consider breaking the primary route (/20) into 2 /21 blocks 
> internally and allowing the longer "nailed up" route to be the permanent 
> source of the /20 advertisement.  for example:

However, in this case, I don't have *anything* as the "primary route".
In fact, the very first /24 of the route is currently unused and goes
nowhere... and the rest of the block goes as /24's, /29's and the like to
various people who connect and disconnect all the time... just like I have
on several other CIDR blocks I've got. But *this* one, and *only* this one,
insists on sending a readvertisement.

So, to readdress my first paragraph, apparently these static routes as
I have them configured do just the trick, since if they didn't, I'd see
lots of other things flapping on my BGP monitor software I just wrote,
but instead I only see this one. Sounds like a real bug of some sort.

-matthew 




More information about the NANOG mailing list