Mainly because propagating a flapping route across the entire Internet is damaging to performance of things other your own equipment and that of your customer. It is just "bad manners" to propagate a flapping route to your peers and it helps maintain a minimum level of stability that it required to keep you "on the Internet". Imagine a table where 1000s of providers are each sending 100s of unstable routes and that those unstable routes might be redistributing into various IGPs that may not respond very gracefully to rapid table changes (like most distance vector IGPs). Also think of this scenario, your link to your customer might be flapping but that same customer might have other carriers advertising the same address space over a stable link. In that case you would be doing a dis-service by not withdrawing that route and having a local-pref does not help since you don't necessarily have visibility to all of your customers other carrier networks.
You do have the ability to clear the RFD timers for a route if you need to manually intervene for example when you know for a fact that you fixed the problem. That means that if no one is watching or intervening the network will "do the safe thing". Steven Naslund Chicago IL > >I always wondered why does it have to be so binary. > >I don't want to decide for my customers if partial visibility is better than >busy CPU, but I do appreciate stability. Why can't we have local-pref penalty >for flapping route. If it's only option, keep offering it, if there are other, >more >stable options, offer those. > >-- > ++ytti
