Cisco: How to improve BGP table stability with route dampening

By On December 3, 2008 · 4 Comments

One of the issues that can affect BGP table stability is link flapping. Imagine that if a link to a network is flapping very often, BGP process has to remove the route to that network from the BGP table and implicit from the routing table and then we the link is available again to re-introduce the prefix in these tables. All this means some BGP operations that consume CPU and memory of the machine.

A way to improve the BGP table stability is to use route dampening. This BGP feature monitor the prefixes in the BGP table and when a route to some prefixes flaps more than BGP dampening is set to allow, it will take out the prefixes from the BGP table. In the following tutorial I will show you a way to configure BGP dampening with some explanations.

For this tutorial we will use the same topology like in the post “Cisco: BGP path selection for outgoing traffic” where we have already a working BGP environment. I took out the configuration for BGP path selection, so we have a simple BGP config running. If you do not have the topology, you can download it here and the initial configuration files here.

Please see the tutorial below:

Tagged with: • • • • •
 
If you enjoyed this article, please consider sharing it!
Reddit FacebookTwitterDelicious

  • Pingback: Cisco: How to improve BGP table stability with route dampeni « Binary Insanity

  • Matt

    I found it a little bit concerning that your document is dated December 2008 and seems to promote BGP route flap dampening. (RFD) . Just checking that you realise that RFD is considered obsolete and in the current world in fact “harmful”. The reasons for applying BGP RFD  ( eg CPU issues / routing “storms” ) are simply not applicable in the current environment. In the late 80′s when CPU was a premium and routing storms could tear down routers, sure, but in the current world your claims are simply factually incorrect.

    Note:

    “ This Routing Working Group document proposes that with the current implementations of BGP flap damping, the application of flap damping in ISP networks is NOT recommended. The recommendations given in ripe-229 and previous documents [2] are considered obsolete henceforth.”

    “ If flap damping is implemented, the ISP operating that network will cause side-effects to their customers and the Internet users of their customers <..> These side-effects would quite likely be worse than the impact caused by simply not running flap damping at all.”


    “ With current vendor implementations, BGP flap damping is harmful to the reachability of prefixes across the Internet.”

    References

    http://www.ripe.net/ripe/docs/routeflap-damping.html


    http://www.apnic.net/meetings/20/docs/sigs/routing/routing-pres-smith-flap-damping.pdf

  • http://www.firstdigest.com Calin

    Hi Matt and thank you for your detailed comment!

    What you say (I checked also the links) it’s true. I also had a lot of problems with BGP dampening in the real environment with ISP not advertising my routes after some link was flapping.
    But, on this website I’m trying to show something that can be useful to others, not to promote one technology over the other. Also I wanted this blog to be useful for the persons that prepare for Cisco exams like CCIE RS or SP, and if you have a look into the Cisco materials and labs, there is a lot of BGP dampening scenarios that you have to implement. If some tool or implementation is not recommend, this does not mean that you shouldn’t know about it or how it is working. At least this is my idea. If you want to use it or not, that depend of your own professionla skills and way of thinking.

  • Rob W

    I would have to agree and disagree with Matt’s comments.  I agree that dampening in the ISP environment is detrimental to the overall stability of the Internet.  However, dampening by the customer …especially when the customer requires (for some reason) to take in the full BGP table.  On highly utilized/high speed links to the ISP, you will run into CPU issues with the BGP process (of course there are other mechanism to tackle that problem) …the FIFO interface buffers have to potential of not getting serviced when the CPU is getting micro-pegged when the BGP process is playing around with prefixes coming and going.

    My .02