Re: weird BGP cisco-ism? [problem resolved]
Well, that was a week-long disruption in routing that shouldn't have been able to happen. This is an explaination of the problem I described last night... We have a handful of CIDR blocks that we announce, but one of them was getting flap-damped. By writing a tool to monitor the BGP announcements, we discovered that a reannouncement was happening every few minutes, for no apparent cause. What was happening is that, about a week ago, another provider got a request from a customer to route them a single /24 from the middle of our (non-portable) block. Because there was no IGP route for that customer, but a network line was in place, the other provider was, every 5-20 minutes, announcing the route for about 30 seconds, and then withdrawing it. We peer with that provider directly, and can also see them via our transit provider, and we have "summary-only" set in our BGP configuration. Every time the /24 appeared, our router would send *four* repeated announcements of the /20 block... once when it appeared via the direct session, again when it appeared via our transit provider, and then twice more, once for each withdrawl. This then triggered the flap damping code at our peers, causing them to ignore the /20 route altogether. Problem took forever to find because the only way to catch it was to know exactly when the flaps were happening and then, at that very moment, look for any longer prefixes in the table. Any suggestion as to how to prevent my Cisco from saying *anything* when someone else decides to briefly present a more specific route would be appreciated, and yet again, we'd be better off with some sort of authentication as to who can advertise what to whom. -matthew kaufman matthew@scruz.net
provider, and we have "summary-only" set in our BGP configuration. Every
Try it w/o the summary-only stuff. I don't use summary-only, or aggregate-address, or network XXX at all. I redis my connected & static routes into bgp and arrange for my global routes to make it beyond my AS. I also use pull up static routes to null0 for all of my blocks. Try it this way & see if it make things more stable. --asp@partan.com (Andrew Partan)
On Fri, 11 Jul 1997, Matthew Kaufman wrote:
We peer with that provider directly, and can also see them via our transit provider, and we have "summary-only" set in our BGP configuration. Every
I'd suggest moving away from "summary-only" aggregation. If you are a transit network, and have customers who are multihomed numbered out of your CIDR block, then you'd need to do aggregation without "summary-only" anyway, so it's a good thing to move towards even in general case if you are a transit network. You can remove the specifics at the edges of your network either via community based filtering or prefix based filtering. The former is much more flexible and is the one I'd recommend. -dorian
You can remove the specifics at the edges of your network either via community based filtering or prefix based filtering. The former is much more flexible and is the one I'd recommend.
-dorian
I'd think prefix based filters would be more likely to be correct. Since you have to explicitly list what you think you should be announcing you protect against having routes you don't expect in your tables and against having interactions that cause unexpected routes to get tagged as announceable. -- -Chris (cgarner@sni.net)
participants (4)
-
Andrew Partan
-
Chris Garner
-
Dorian R. Kim
-
matthew@scruz.net