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

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

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.