Re: with a flap flap here and a flap flap there...
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.
On 4 Feb 1998, Sean M. Doran wrote:
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.
But the loop avoidance from having paths constrains you to the width of the Internet in terms of ASes. It isn't completely a distance vector protocol. [...]
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...
I guess I'm just suprised at how wide the Internet has grown and at the lack of noticeable public acknowledgment of the resulting problems.
participants (2)
-
Marc Slemko -
Sean M. Doran