Marc Slemko <marcs@znep.com> writes:
3333 6905 5623 1136 3300 7018 6478 1 701 814 7189 1691 852 6171 (history entry) Am I the only one that has a problem with this? You withdraw a route once, and it has flapped enough to be dampened in numerous places. I could have been half convinced that we had gone back to distance vector routing seeing this going on...
BGP *is* a distance-vector routing protocol. What you were witnessing was a counting-to-infinity problem that is bounded by timers and toplogical constraints. Welcome to the wonderful world of BGP == RIP. This is precisely why a mechanism which constrains the amount of prefix transitions is so important: magnification of flapping is predictable. However, welcome to the wonderful world of lack of filtering, too. There is no apparent reason why a number of those ASes should have reannounced your routes to each other. Each BGP peering (customer and peer alike) should either explicitly allow announcements only from a list of appropriate ASes, or explicitly disallow announcements which have been through peers and (at least large) other BGP-talking customers. This is an Incredibly Smart Thing To Do. On a Cisco, the _ operator is your best regexp friend... Sean.