You are here: Home > Publications > RIPE Document Store > RIPE Routing Working Group Recommendations on Route Flap Damping

Changes to RIPE Routing Working Group Recommendations on Route Flap Damping

Legend (+) Added (-) Deleted
Changed Tag Added Tag Deleted
ripe-580: ripe-210: RIPE Routing Working Group Recommendations on Route Flap Routing-WG Recommendation For Coordinated Route-flap Damping Parameters
delete: <p> delete: <a class="anchor-link" href="#introduction"> Introduction delete: </a> delete: </p> delete: <p> delete: <a class="anchor-link" href="#history"> History and Background delete: </a> delete: </p> delete: <p> delete: <a class="anchor-link" href="#analysis"> Analysis delete: </a> delete: </p> delete: <p> delete: <a class="anchor-link" href="#recommendations"> Recommendations delete: </a> delete: </p> delete: <p> delete: <a class="anchor-link" href="#references"> References and Further Reading delete: </a> delete: </p> delete: <h2> delete: </h2> delete: <h3> delete: <a name="introduction"> delete: </a> Introduction delete: </h3> delete: <p> Route Flap Damping (RFD) [ delete: <a class="anchor-link" href="#ref1"> 1 delete: </a> ] is a mechanism for BGP speaking routers that penalises prefixes that exhibit a large number of updates (‘flapping'), and suppresses a route when the accumulated penalty exceeds a given threshold. The penalty decays over time until it reaches a lower threshold at which point the route is unsuppressed. RFD is intended to improve the overall stability of the Internet routing table and reduce the load on BGP speaking routers. In ripe-378 [ delete: <a class="anchor-link" href="#ref2"> 2 delete: </a> ] it was stated that due to the dynamics of BGP, especially a phenomenon called ‘path hunting,' the default configurations of flap damping can do more harm than good as it may suppress a prefix after it has only flapped a few times. Consequently RFD was deprecated due to the problem of over damping (see [ delete: <a class="anchor-link" href="#ref2"> 2 delete: </a> ] for more details). delete: </p> delete: <p> A small number of prefixes on the Internet continue to flap rapidly and cause a disproportionate number of updates to BGP and load on BGP speaking routers. This document uses experimental data gathered from an operational environment to suggest changes to the RFD parameters to suppress the prefixes that flap the most, while minimising the suppression of other prefixes. delete: </p>

This document suggests parameters which would make RFD usable and is based around the work of Cristel Pelsser, Olaf Maennel, Pradosh Mohapatra, Randy Bush, and Keyur Patel presented at PAM2011[ delete: <a class="anchor-link" href="#ref3"> 3 delete: </a> ]. delete: </p> delete: <h3> delete: <a name="history"> delete: </a> History and Background delete: </h3> delete: <p> In the early 1990s the accelerating growth in the number of prefixes being announced to the Internet (often due to inadequate prefix aggregation), the denser meshing through multiple inter-provider paths, and increased instabilities started to cause significant impact on the performance and efficiency of some Internet backbone routers. Every time a routing prefix altered state because of a single line-flap, the withdrawal was advertised to the whole BGP-Speaking Zone (BSZ) and handled by every router that carried the full Internet routing table. delete: </p> delete: <p> The load this processing placed on the control planes of routers caused further instability as the routers were not able to process other BGP updates or they dropped traffic transiting the device. This could produce cyclic crashing behaviour. delete: </p> delete: <p> To overcome this situation RFD was developed in 1993 and has since been integrated into most router BGP software implementations. RFD is described in detail in RFC 2439[ delete: <a class="anchor-link" href="#ref1"> 1] delete: </a> . delete: </p> delete: <p> When RFD was first implemented in commercial routers, vendor implementations had different default values and different characteristics. As this inconsistency would result in different rates of flap damping, and therefore introduce inconsistent path selection and behavior that was hard to diagnose, the operator community introduced a consistent set of recommendations for flap damping parameters, so that ISPs deploying RFD would treat flapping prefixes in the same way. delete: </p> delete: <p> This call for consistency resulted in the RIPE Routing Working Group producing first ripe-178, then ripe-210, and finally the ripe-229 documents [ delete: <a class="anchor-link" href="#ref2a"> 2a delete: </a> ]. The parameters documented in ripe-229 were considered, at time of publication in 2001, the best current practice. In 2006, this was reviewed again and resulted in ripe-378 [ delete: <a class="anchor-link" href="#ref2"> 2 delete: </a> ] which recommended to disable RFD because it created more harm than good. delete: </p> delete: <h3> delete: <a name="analysis"> delete: </a> Analysis delete: </h3> delete: <p> In the work by Pelsser et al [ delete: <a class="anchor-link" href="#ref3"> 3 delete: </a> ], it is shown that 3% of all prefixes cause 36% of BGP updates, and just 0.01% of the prefixes cause 10% of the BGP updates. The aim is to only penalise those prefixes with excessive numbers of updates. delete: </p> delete: <p> The default values used in current implementations of RFD apply a penalty of 1000 each time a route flaps, and suppresses the prefix when the penalty exceeds a figure in the region of 2000 (Cisco IOS) or 3000 (Juniper JunOS). delete: </p> delete: <p> The table shows the percentage of prefixes above the suppress threshold and the percentage reduction in BGP churn for various values of suppress threshold. The current default suppress value of 2000 reduces BGP churn by 47%, but it suppressed 14% of the prefixes at some point over the lifetime of the experiment. Significantly larger values of suppress threshold such as 12000, 15000 or 18000 still reduced BGP churn, but suppressed far fewer prefixes which it is believed reduces the risk of penalising otherwise well-behaved prefixes. delete: </p> delete: <p> delete: </p> delete: <table class="listing"> delete: <tbody> delete: <tr> delete: <td> delete: <p> delete: <b> Suppress delete: </b> delete: </p> delete: <p> delete: <b> Threshold delete: </b> delete: </p> delete: </td> delete: <td> delete: <p> delete: <b> % prefixes delete: </b> delete: </p> delete: <p> delete: <b> suppressed delete: </b> delete: </p> delete: </td> delete: <td> delete: <p> delete: <b> % reduction in BGP churn delete: </b> delete: </p> delete: <p> delete: <b> compared with no damping delete: </b> delete: </p> delete: </td> delete: </tr> delete: <tr> delete: <td> delete: <p> 2000 delete: </p> delete: <p> 4000 delete: </p> delete: <p> 6000 delete: </p> delete: <p> 12000 delete: </p> delete: <p> 15000 delete: </p> delete: <p> 18000 delete: </p> delete: </td> delete: <td> delete: <p> 14 delete: </p> delete: <p> 4.2 delete: </p> delete: <p> 2.1 delete: </p> delete: <p> 0.63 delete: </p> delete: <p> 0.44 delete: </p> delete: <p> 0.32 delete: </p> delete: </td> delete: <td> delete: <p> 47 delete: </p> delete: <p> 26 delete: </p> delete: <p> 19 delete: </p> delete: <p> 11.26 delete: </p> delete: <p> 9.51 delete: </p> delete: <p> 8.12 delete: </p> delete: </td> delete: </tr> delete: </tbody> delete: </table> delete: <h3> delete: <a name="recommendations"> delete: </a> Recommendations delete: </h3> delete: <p> In order to punish the biggest offenders - those prefixes that flap the most – yet without punishing others, the RIPE Routing-WG recommends vendors raise the maximum suppress threshold in router implementations to 50,000 and operators configure a suppress threshold value of at least 6,000. The vendors might also change the default suppress threshold to 6,000. But this might surprise operators who use the default. delete: </p> delete: <p> This has a number of advantages: delete: </p> delete: <ul> delete: <li> it is easy to implement delete: </li> delete: <li> it will reduce the churn compared to the situation we havenow where no RFD is applied delete: </li> delete: <li> it spares the smaller offenders. delete: </li> delete: </ul> delete: <p> Changing the default suppress threshold could result in an increase in forwarding table size or announcement rate for operators who use RFD with the default settings. This warrants further discussion. delete: </p> delete: <h3> delete: <a name="references"> delete: </a> References and Further Reading delete: </h3> delete: <p> delete: <a name="ref1"> delete: </a> [1] Curtis Villamizar, Ravi Chandra, Ramesh Govindan delete: </p> delete: <p> RFC2439: BGP Route-flap Damping (Proposed Standard) delete: </p> delete: <p> delete: <a href="ftp://ftp.ietf.org/rfc/rfc2439.txt"> ftp://ftp.ietf.org/rfc/rfc2439.txt delete: </a> delete: </p> delete: <p> delete: </p> delete: <p> delete: <a name="ref2"> delete: </a> [2] Most recent RIPE Document is available in ASCII and PDF

delete: <p> delete: <a href="ftp://ftp.ripe.net/ripe/docs/ripe-378.txt"> ftp://ftp.ripe.net/ripe/docs/ripe-378.txt delete: </a> delete: </p> delete: <p> delete: </p> delete: <p> delete: <a name="ref2a"> delete: </a> [2a] Older RIPE Documents delete: </p> delete: <p> delete: <a href="ftp://ftp.ripe.net/ripe/docs/ripe-178.txt"> ftp://ftp.ripe.net/ripe/docs/ripe-178.txt delete: </a> delete: </p> delete: <p> delete: <a href="ftp://ftp.ripe.net/ripe/docs/ripe-210.txt"> ftp://ftp.ripe.net/ripe/docs/ripe-210.txt delete: </a> delete: </p> delete: <p> delete: <a href="ftp://ftp.ripe.net/ripe/docs/ripe-229.txt"> ftp://ftp.ripe.net/ripe/docs/ripe-229.txt delete: </a> delete: </p> delete: <p> delete: </p> delete: <p> delete: <a name="ref3"> delete: </a> [3] Cristel Pelsser, Olaf Maennel, Pradosh Mohapatra, Randy Bush and Keyur Patel. "Route Flap Damping Made Usable". PAM 2011, March 2011. delete: </p> delete: <p> delete: <a href="http://www.iij-ii.co.jp/en/lab/researchers/cristel/publications/Pelsser-RFD-PAM2011.pdf"> http://www.iij-ii.co.jp/en/lab/researchers/cristel/publications/Pelsser-RFD-PAM2011.pdf delete: </a> delete: </p> delete: <p> delete: </p> delete: <p> [4] Zhouqing Mao, Ramesh Govindan, George Varghese, Randy Katz delete: </p> delete: <p> Route-flap Damping Exacerbates Internet Routing Congerence SIGCOMM 2002 delete: </p> delete: <p> delete: <a href="http://www.eecs.umich.edu/~zmao/Papers/sig02.pdf"> http://www.eecs.umich.edu/~zmao/Papers/sig02.pdf delete: </a> delete: </p> delete: <p> delete: </p> delete: <p> [5] Randy Bush, Tim Griffin, Zhouqing Mao Route-flap Damping: Harmful? delete: </p> delete: <p> NANOG 26 delete: </p> delete: <p> delete: <a href="http://www.nanog.org/mtg-0210/ppt/flap.pdf"> http://www.nanog.org/mtg-0210/ppt/flap.pdf delete: </a> delete: </p> delete: <p> delete: </p> delete: <p> [6] Craig Labovitz, Abha Ahuja, Abhijit Bose, Farnam Jihanian delete: </p> delete: <p> Delayed Internet Routing Convergence SIGCOMM 2000 delete: </p> delete: <p> delete: <a href="http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-5-2.pdf"> http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-5-2.pdf delete: </a> delete: </p>
RIPE Routing Working Group Recommendations on Route Flap Routing-WG Recommendation For Coordinated Route-flap Damping Parameters
RIPE Documents Search