[apops] Draft revision of RIPE-210: Coordinated Route Flap Damping Param

  • To: routing-wg at ripe dot net
  • Subject: [apops] Draft revision of RIPE-210: Coordinated Route Flap Damping Parameters
  • From: Philip Smith <pfs at cisco dot com>
  • Date: Wed, 25 Apr 2001 02:35:20 +1000
  • Sender: owner-apops@lists.apnic.net
    • Hi,
      
      bcc: nanog, apops, APNIC routing SIG, afnog
      
      Please accept my apologies for any duplicates.
      
      The attached is a proposed update and revision of the RIPE-210 Coordinated 
      Route Flap Damping Parameters document. The authors would welcome any 
      comments and feedback regarding the content of this document, either to the 
      RIPE Routing Working Group, or at the RIPE meeting in Bologna, Italy, on 
      w/b 30th April.
      
      We would also welcome links/sample configurations/examples for other router 
      platforms (specifically Juniper/Foundry/Extreme and any other platforms 
      which may be found in today's Internet) to augment the Cisco IOS 
      configuration examples given in the Appendix.
      
      thanks, and kind regards,
      
      philip
      --
      
       >>>>begin
      
      
      RIPE Routing-WG Recommendation for coordinated route-flap damping parameters
      
      Philip Smith
      Daniel Karrenberg
      Christian Panigl
      Joachim Schmitz
      
      
      This document Obsoletes: ripe-210, ripe-178
      
        -----------------------------------------------------------------
      
      Document status Version 1.2, April 24th, 2001
      
      Abstract
      
      This paper recommends a set of route-flap damping parameters which should
      be applied by all ISPs in the Internet and should be deployed as default
      values by BGP router vendors.
      
      Table of Contents
      
           1. Introduction
           1.1 Motivation for route-flap damping
           1.2 What is route-flap damping ?
           1.3 "Progressive" versus "flat&gentle" approach
           1.4 Motivation for coordinated parameters
           1.5 Aggregation versus damping
           1.6 "Golden Networks"
           2. Recommended damping parameters
           2.1 Motivation for recommendation
           2.2 Description of recommended damping parameters
           2.3 Example configuration for Cisco IOS
           3. Other Features contributing to Internet Stability
           3.1 BGP Route Refresh
           3.2 Soft Reconfiguration (Cisco IOS)
           3.3 Fast-External-Fallover (Cisco IOS)
           4. Potential problems
           4.1 Multiplication of flaps between ASes with multiple interconnections
           4.2 Non-recommended flap damping parameters
           5. References
           6. Acknowledgements
           Appendices
           A.1 "Golden Networks"
           A.2 Sample Cisco IOS Configuration
           A.3 Study of Flap Damping Operation
      
      1. Introduction
      
      Route-flap damping is a mechanism for (BGP) routers which is aimed at
      improving the overall stability of the Internet routing table and reducing
      the load on the CPUs of the core routers.
      
      1.1 Motivation for route-flap damping
      
      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 the Internet backbone routers. Every time a routing prefix
      becomes unreachable because of a single line-flap, the withdrawal has to
      be advertised to the whole core Internet and dealt with by every single
      router which is carrying the full Internet routing table.
      
      To overcome this situation a route-flap damping mechanism was invented in
      1993 and has been integrated into several router software implementations
      since 1995 (for example, Cisco, Merit/RSd, GateD Consortium). The
      implementation is described in detail in RFC2439. The flap damping mechanism
      is now widely used to help keep severe instabilities under control and
      more localised in the Internet.
      
      And there is a second benefit: it is raising the awareness of the
      existence of instabilities because severe route/line-flapping problems
      lead to permanent suppression of the unstable area by means of holding
      down the flapping prefixes.
      
      Route-flap damping has its greatest and most consistent value if it
      is applied as near to the source of the problem as possible. Therefore
      flap-damping should be applied both at peering and upstream boundaries,
      as well as at customer boundaries (see 1.4 and 1.5 for details).
      
      1.2 What is route-flap damping ?
      
      When BGP route-flap damping is enabled in a router the router starts
      to collect statistics about the announcement and withdrawal of
      prefixes. Route-flap damping is governed by a set of parameters with
      vendor-supplied default values which may be modified by the router
      manager. The names, semantic and syntax of these parameters differ
      between the various implementations; however, the behaviour of the
      damping mechanism is basically the same.
      
        Each time a prefix is withdrawn, the router will increment the damping
        penalty by a fixed amount. When the number of withdrawals/announcements
        (=flap) is exceeded in a given time frame (cutoff threshold) the
        path is no longer used and not advertised to any BGP neighbour for a
        predetermined period starting from when the prefix stops flapping. Any
        more flaps happening after the prefix enters suppressed state will
        attract additional penalty. Once the prefix stops flapping, the penalty
        is decremented over time using a half-life parameter until the penalty is
        below a reuse threshold. Once below this reuse threshold the suppressed
        path is then re-used and re-advertised to BGP neighbours.
      
      Pointers to some more detailed and vendor specific documents:
      
      Cisco BGP Case Studies: Route Flap Damping
      http://www.cisco.com/warp/public/459/16.html
      
      ISI/RSd Configuration: Route Flap Damping
      http://www.isi.edu/div7/ra/RSd/doc/dampen.html
      
      GateD Configuration: Weighted Route Damping Statement
      http://www.gated.org/gated-web/code/doc/manuals/config_guide/bgp/
      weighted_route_dampening.html
      
      See also "5. References"
      
      1.3 "Progressive" versus "flat&gentle" approach
      
      One easy approach would be to just apply the current default-parameters
      which are treating all prefixes equally ("flat&gentle") everywhere. However,
      there is a major concern to penalise longer prefixes (=smaller aggregates)
      more than well aggregated short prefixes ("progressive"), because the
      number of short prefixes in the routing table is significantly lower and
      it seems in general that those are tending to be more stable and also are
      tending to affect more users.
      
      Another aspect is that progressive damping might increase the awareness
      of aggregation needs. However, it has to be accompanied by a careful
      design which doesn't force a rush to request and assign more address space
      than needed.
      
      A significant number of important services is sitting in long prefixes
      (e.g. root name servers), so the progressive approach has to exclude the
      strong penalisation for these so-called "golden" prefixes.
      
      With this recommendation we are trying to make a compromise and it is
      therefore called "graded damping".
      
      1.4 Motivation for coordinated parameters
      
      There is a strong need for the coordinated use of damping parameters for
      several reasons:
      
      Coordination of "progressiveness":
      
      If penalties are not coordinated throughout the Internet, route-flap damping
      could lead to additional flapping or inconsistent routing because longer
      prefixes might already be re-announced through some parts of the Internet
      where shorter prefixes are still held down through other paths.
      
      Coordination of hold-down and reuse-threshold parameters between ISPs:
      
      If an upstream or peering provider would be damping more aggressively
      (e.g. triggered by less flaps or applying longer hold-down timers) than an
      access-provider towards his customers it will lead to a very inconsistent
      situation, where a flapping network might still be able to reach "near-line"
      parts of the Internet. Debugging of such instabilities is then much harder
      because the effect for the customer leads to the assumption that there
      is a problem "somewhere" in the "upstream" Internet instead of making him
      just call his ISPs hot-line and complain that he can't get out any longer.
      
      Further, after successful repair of the problem the access-provider
      can easily clear the flap-damping for his customer on his local router
      instead of needing to contact upstream NOCs all over the Internet to get
      the damping cleared.
      
      Vendor Defaults:
      
      As with most software implementations, there need to be some default values
      set when route-flap damping is enabled on routers. Vendors choosing different
      default values will result in a similar situation to that described above,
      where the more aggressive values will result in "black spots" in the
      Internet. Coordinated values will ensure consistency in dealing with
      instabilities.
      
      1.5 Aggregation versus damping
      
      If a customer of an ISP is only using Provider Aggregated addresses,
      the aggregating upstream provider doesn't need to apply damping on these
      prefixes towards his customer, because instabilities of such prefixes
      will not propagate into the Internet. However, if a customer insists on
      announcing prefixes which can't be aggregated by its provider, damping
      should be applied. Reasons for leaking prefixes might include dual-homing
      (to different providers) of a customer, or customer's reluctance to renumber
      into the provider's aggregated address range.
      
      1.6 "Golden Networks"
      
      Even though damping is strongly recommended, in some cases it may make sense
      to exclude certain networks or even individual hosts from damping.  This is
      especially true if damping would cut off the access to vital infrastructure
      elements of the Internet. A most prominent example are the root name servers.
      
      At least in principle, there should be enough redundancy for root name
      servers. However we are still facing a situation where, at least outside USA,
      large parts of the Internet are seeing all of them through the same one or
      two backbone/upstream links (sea cable) and any instability of those links
      which is triggering damping would unnecessarily prolong the inaccessibility
      of the root name servers for an hour (at least those sitting in a /24 or
      longer prefix).
      
      Other examples of inclusions in the "Golden Networks" might be the Global
      Top Level Domain (gTLD) name servers, and possibly overseas or "special"
      networks the local ISP wishes to have continued connectivity to regardless
      of the instability of the infrastructure inbetween.
      
      Appendix 1 gives an example of the Golden Networks at the time
      of publication of this document. Before implementation of route flap
      damping using these Golden Networks, network managers are strongly
      encouraged to check that the networks listed are indeed still being
      announced, and are home to the servers mentioned. This can be done by
      matching BGP table announcements with the published addresses for the
      listed servers.
      
      These exceptions must only be made if there are strong and identifiable
      needs for them - the rule should be to apply coordinated route flap
      damping throughout.
      
      2. Recommended damping parameters
      
      2.1 Motivation for recommendation
      
      At RIPE26 and 27 Christian Panigl presented the following network backbone
      maintenance example from his own experience, which was triggering flap
      damping in some upstream and peering ISPs routers for all his and his
      customers /24 prefixes for more than 3 hours because of too "aggressive"
      parameters:
      
      scheduled SW upgrade of backbone router failed:
      
          - reload after SW upgrade       1 flap
          - new SW crashed                1 flap
          - reload with old SW            1 flap
                                          ------
                                          3 flaps within 10 minutes
      
      which resulted in the following damping scenario at some boundaries with
      progressive route-flap damping enabled:
      
      Prefix length:      /24     /19     /16
      suppress time:      ~3h     45-60'  <30'
      
      Therefore, in the Routing-WG session at RIPE27, it was agreed that
      suppression should not start until the 4th flap in a row and that the maximum
      suppression should in no case last longer than 1 hour from the last flap.
      
      It was agreed that a recommendation from RIPE would be desirable. Given that
      the current allocation policies are expected to hold for the foreseeable
      future, it was suggested that all /19's or shorter prefixes are not
      penalised harder (longer) than current Cisco default damping does. More
      recently, this recommendation has been altered so that only prefixes longer
      than a /21 are now damped more aggresively. The registries' minimum
      allocation is currently a /20, and a /21 announcement is quite feasible for a
      multihoming situation.
      
      With these suggestions in mind, Tony Barber designed the following set of
      route-flap damping parameters which have proved to work smoothly in his
      environment for a couple of months prior to the publication of RIPE-178 (the
      original version of this document).
      
      2.2 Description of recommended damping parameters
      
      Basically the recommended values do the following with harsher treatment
      for /24 and longer prefixes:
      
          * don't start damping until the 4th flap
          * /24 and longer prefixes: max=min outage 60 minutes
          * /22 and /23 prefixes: max outage 45 minutes; min outage of 30 minutes
          * all other prefix lengths: max outage 30 minutes; min outage 10 minutes
      
      If a specific damping implementation does not allow configuration of
      prefix-dependent parameters the least aggressive set should be used:
      
          * don't start damping before the 4th flap in a row
          * max outage 30 minutes; min outage 10 minutes
      
      A sample configuration for Cisco IOS is provided in Appendix 2. This sample
      can be used as a basis for a configuration on other router platforms.
      
      3. Other Features contributing to Internet Stability
      
      3.1 BGP Route refresh
      
      RFC2918 describes a Route Refresh Capability for BGP-4. Prior to this, there
      was no mechanism to reset or refresh a BGP peering session without tearing
      it down and waiting for it to re-establish. This process is destructive -
      prefixes being exchanged between the two peering routers are withdrawn from
      their respective ASes, and this withdrawal can potentially pass through
      the whole Internet causing the burden and increased instability discussed
      earlier. Usually all that an ISP wishes when reseting a BGP session is to
      implement new or revised policy - destroying a BGP session carrying a large
      or the full routing table has severe impact on the ISP and his neighbours
      on the Internet. Furthermore, reset of a BGP session means the withdrawal
      of reachability information from the ISP's customers, and they have the
      perception that the Internet has "vanished" - the impression left with
      the end-user is that of an unreliable network.
      
      Route Refresh implements a messaging system whereby a router wishing to
      refresh or reset its BGP peering with its neighbour simply has to send the
      notification. When the neighbour receives the notification, it will send
      its entire announcement to its peer (obtained from BGP best path table and
      applicable outbound policy).
      
      To find out if your neighbour supports Route Refresh, using Cisco IOS as an
      example, enter:
      
      Router# sho ip bgp neigh w.x.y.c | include refresh
         Received route refresh capability(new) from peer
         Route refresh request: received 0, sent 0
      
      If your router and your peer router support Route Refresh, you can use:
      
      Router# clear ip bgp w.x.y.c in
      
      for requesting a route refresh without clearing the BGP session.
      
      For an outbound route refresh without clearing the BGP session use
      
      Router# clear ip bgp w.x.y.c out
      
      It is recommended that all users of BGP use the route refresh capability
      when implementing new BGP policy.
      
      3.2 Soft-Reconfiguration (Cisco IOS)
      
      Where the neighbour does not support RFC 2918 Route Refresh, there is a
      functionality in Cisco IOS called "Soft Reconfiguration". This reserves
      additional memory in the router to store the BGP table exactly as it was
      received from the peer, prior to any inbound policy being applied. The
      advantage of this is that the ISP can then change any inbound policy on the
      router without reseting the BGP session - the router simply uses the "raw"
      BGP table it has received from its peer. Disadvantage is that this
      functionality could potentially consume almost twice the amount of memory
      required for the BGP table heard from the peer.
      
      To configure soft-reconfiguration in IOS, simply add the extra line to
      the BGP peer configuration as below.  Soft-reconfiguration is configured
      on a per-neighbour basis.
      
      !
      router bgp 65501
        neighbor 10.0.0.2 remote-as 65502
        neighbor 10.0.0.2 soft-reconfiguration inbound
      !
      
      Without the keyword "soft" a "clear ip bgp x.x.x.x" will completely reset
      the BGP session and therefore always withdraw all announced prefixes from/to
      neighbour x.x.x.x and re-advertise them (= route-flap for all prefixes which
      are available before and after the clear). With "clear ip bgp x.x.x.x
      soft out" the router doesn't reset the BGP session itself but sends an
      update for all its advertised prefixes. With "clear ip bgp x.x.x.x soft
      in" the router just compares the already received routes (stored in the
      "received" data structures) from the neighbour against locally configured
      inbound policy statements.
      
      It is recommended to use soft-reconfiguration with all peers which do not
      support RFC2918 Route Refresh Capability.
      
      3.3 Fast-External-Fallover (Cisco IOS)
      
      Cisco IOS by default implements a feature known as "fast-external-fallover".
      This feature immediately clears the BGP session whenever the line-protocol
      to the external neighbour goes down. This feature is desirable so that
      there is fast failover in case of link failures - the router can withdraw
      paths as soon as the line goes down, rather than waiting for BGP keepalive
      timers.  The drawback of this, however, is that circuits which are prone
      to unreliability will cause BGP sessions to drop and return (i.e. flap),
      resulting in instability within the ISP's network, and the potential for
      flap damping by upstreams or peers.
      
      If fast-external-fallover is turned off, the BGP sessions will survive
      these short line-flaps as it will use the longer BGP keepalive/hold timers
      (default 60/180 seconds). The drawback of turning it off - and currently
      it has to be done for a whole router and can not be selected peer-by-peer -
      is that the switch-over to an alternative path will take longer.
      
      We recommend turning off fast-external-fallover whenever possible:
      
      !
      router bgp 65501
        no bgp fast-external-fallover
      !
      
      Alternatively it might be considered acceptable to retain
      "fast-external-fallover" and to turn off "interface keepalives" on unreliable
      circuits to overcome the immediate BGP resets on any significant CRC
      error period.
      
      Another potentially more satisfactory alternative would be to use a shorter
      per-neighbour BGP keepalive timer which has to be applied on both routers
      (e.g. 10 seconds which gives a hold-timer of 30 seconds):
      
      !
      router bgp 65501
        neighbor w.x.y.z timers 10
      !
      
      4. Potential problems
      
      4.1 Multiplication of flaps between ASes with multiple interconnections
      
      Christian Panigl experienced the following during a circuit upgrade of an
      Ebone customer:
      
      - Only ONE flap was generated as a result of the upgrade process (disconnect
         router-port from modem A, reconnect to modem B). Nevertheless the
         customer's prefix was damped in all ICM routers.
      
      - The flap statistics in the ICM routers stated *4* flaps !!!
      
      - The only explanation would be that the multiple interconnections
         between Ebone/AS1755 and ICM/AS1800 did multiply the flaps
         (advertisements/withdrawals arrived time-shifted at ICM routers through
         the multiple circuits).
      
      - This would then potentially hold true for any meshed topology because
         of the propagation delays of advertisements/withdrawals.
      
      There are two potential solutions to workaround this problem. The first
      one is operational, the second one is a software configuration feature
      (for Cisco IOS and possibly other implementations as well).
      
        * Schedule a downtime for at least 3-5 minutes which should be enough
          time for the prefix withdrawals to have propagated through all paths
          before reconnection and re-advertisement of the prefix.  Avoid clearing
          BGP sessions as this also could generate a 30 minute outage through
          flap damping!
      
        * Configure a permanent static route pointing to the customer interface.
          Even if the interface goes down, there is still an entry in the routing
          table for the customer network, and BGP will therefore still announce
          the prefix. Example:
      
          !
          router bgp 65500
           network 169.254.0.0 mask 255.255.0.0
          ip route 169.254.0.0 255.255.0.0 serial 5/0 permanent
          !
      
          If migrating the customer from one router port to another, simply enter
          the second static route pointing to the new interface. Move the cable
          between ports - BGP continues to announce the prefix as the entry is
          still in the routing table.
      
          Note: this solution only applies to customers who connect using
          static routes. If the customer connects using BGP, first disable
          fast-external-fallover on both the customer and ISP router, and then
          move the cable in a time period less than the BGP hold-timer.
      
      4.2 Non-recommended flap damping parameters
      
      There are situations where service providers would like to design their
      own route flap damping parameters for local needs or conditions. If this is
      really desired, then it is important to pay attention to how flap damping
      parameters are configured, whether the values are feasible or not, etc.
      
      For example, in Cisco IOS, it is perfectly possible to configure flap damping
      parameters which do nothing.
      
        * One example might be the configuration "set dampening 15 500 3000
          30". Here the reuse limit is 500, maximum suppress time is 30 minutes
          and the half life is 15 minutes. Using these three parameters gives a
          maximum possible penalty value of 2000, well below the suppress limit of
          3000. So even though this can be successfully configured on the router,
          no damping will take place.
      
        * Another example might be the configuration "set dampening 15 750 3000 30".
          Here the reuse limit is 750, maximum suppress time is 30 minutes and the
          half life is 15 minutes. Using these three parameters gives a maximum
          possible penalty of 3000, exactly the same as the suppress-limit. In
          Cisco IOS, the penalty is decayed every 5 seconds, so flap damping will
          only be take place if the update follows the withdraw within that 5
          second time frame. 99% of the time no flap damping will take place.
      
      5. References
      
      RIPE/Routing-WG Minutes dealing with Route Flap Damping:
      
      http://www.ripe.net/ripe/meetings/archive/ripe-24/ripe-m-24.txt
      http://www.ripe.net/ripe/meetings/archive/ripe-25/ripe-m-25.txt
      http://www.ripe.net/wg/routing/r25-routing.html
      http://www.ripe.net/wg/routing/r26-routing.html
      http://www.ripe.net/wg/routing/r27-routing.html
      
      Curtis Villamizar, Ravi Chandra, Ramesh Govindan
      RFC2439: BGP Route Flap Damping (Proposed Standard)
      ftp://ftp.ietf.org/rfc/rfc2439.txt
      
      Enke Chen
      RFC2918: Route Refresh Capability for BGP-4 (Proposed Standard)
      ftp://ftp.ietf.org/rfc/rfc2918.txt
      
      Merit/IPMA: Internet Routing Recommendations
      http://www.merit.edu/ipma/docs/help.html
      
      Cisco BGP Case Studies: Route Flap Damping
      http://www.cisco.com/warp/public/459/16.html
      
      Cisco Documentation: Configuring BGP / Route Dampening
      http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/
      121cgcr/ip_c/ipcprt2/1cdbgp.htm
      
      Cisco Documentation: BGP Soft Reset Enhancement
      http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/
      120newft/120t/120t7/sftrst.htm
      
      ISI/RSd Configuration: Route Flap Damping
      http://www.isi.edu/div7/ra/RSd/doc/dampen.html
      
      GateD Configuration: Weighted Route Damping Statement
      http://www.gated.org/gated-web/code/doc/manuals/config_guide/bgp/
      weighted_route_dampening.html
      
      6. Acknowledgements
      
      Thanks to all the contributors to this updated version.
      
      7. Changes over previous versions
      
      This document is a significant rewrite and update of RIPE-210. The "Golden
      Networks" have now been moved to an Appendix as they are frequently changing
      and the authors have come across several instances of providers implementing
      the recommendations without actually checking that the Root Nameserver
      networks were still as listed in the document.
      
      Updates to the Cisco IOS configuration have been made, and the parameters
      chosen for /24 networks have been corrected to make them feasible. Examples
      of flap damping in operation have been added to Appendix 3.
      
      The sample configuration has been moved to Appendix 2 - again IOS is used
      as a known working example.
      
      Appendices
      
      A.1 "Golden Networks"
      
      This appendix lists some examples of Golden Networks which could be used
      when applying route flap damping at the edge of an ISP's network. The
      example uses Cisco IOS configuration syntax. The list was correct at time
      of writing (April 2001).
      
      ip prefix-list golden-networks description Golden Networks
      ! Root Nameservers
      ip prefix-list golden-networks permit 198.41.0.0/24      ! A & J
      ip prefix-list golden-networks permit 128.9.0.0/16       ! B
      ip prefix-list golden-networks permit 192.33.4.0/24      ! C
      ip prefix-list golden-networks permit 128.8.0.0/16       ! D
      ip prefix-list golden-networks permit 192.203.230.0/24   ! E
      ip prefix-list golden-networks permit 192.5.4.0/23       ! F
      ip prefix-list golden-networks permit 192.112.36.0/24    ! G
      ip prefix-list golden-networks permit 128.63.0.0/16      ! H
      ip prefix-list golden-networks permit 192.36.148.0/24    ! I
      ip prefix-list golden-networks permit 193.0.14.0/24      ! K
      ip prefix-list golden-networks permit 198.32.64.0/24     ! L
      ip prefix-list golden-networks permit 202.12.27.0/24     ! M
      ! Global Top Level Domain Servers
      ip prefix-list golden-networks permit 192.5.6.0/24       ! A
      ip prefix-list golden-networks permit 203.181.96.0/19    ! B
      ip prefix-list golden-networks permit 192.26.92.0/24     ! C
      ip prefix-list golden-networks permit 192.31.80.0/24     ! D
      ip prefix-list golden-networks permit 192.12.94.0/24     ! E
      ip prefix-list golden-networks permit 192.35.51.0/24     ! F
      ip prefix-list golden-networks permit 192.42.93.0/24     ! G
      ! ip prefix-list golden-networks permit ????             ! No H
      ip prefix-list golden-networks permit 192.36.144.0/24    ! I
      ip prefix-list golden-networks permit 210.132.96.0/19    ! J
      ip prefix-list golden-networks permit 213.177.192.0/21   ! K
      ip prefix-list golden-networks permit 192.41.162.0/24    ! L
      ip prefix-list golden-networks permit 202.153.112.0/20   ! M
      
      
      A.2 Sample Cisco IOS Configuration
      
      ! Parameters are :
      ! set damp <half-life-time> <reuse-at> <suppress-at> <max-suppress-time>
      ! There is a 1000 penalty for each flap
      ! There is a 500 penalty for change in attribute
      ! Penalty decays at granularity of 5 seconds, decay starts as soon as
      !  prefix is withdrawn
      ! Unsuppressed at granularity of 10 seconds
      ! damping info kept until penalty becomes < half of reuse limit.
      !
      ! Cisco/IOS value-ranges:
      !
      !   <half-life-time> (range is 1-45 minutes).
      !   <reuse-value> (range is 1-20000).
      !   <suppress-value> (range is 1-20000).
      !   <max-suppress-time> (range is 1-255 minutes ).
      !
      !-----------------------------------------------------------------------
      ! ENABLE BGP DAMPenING using "graded" route-map
      !-----------------------------------------------------------------------
      router bgp 65500
      NO bgp damp
      bgp damp route-map graded-flap-damping
      !
      !-----------------------------------------------------------------------
      ! DEFINE "graded" route-map
      !-----------------------------------------------------------------------
      NO route-map graded-flap-damping
      !
      ! don't damp Candidate Default Routes
      ! OPTIONAL (not part of recommendation)
      ! prefix-list default-networks lists the Candidate Default Routes
      !
      !route-map graded-flap-damping deny 5
      ! match ip address prefix-list default-networks
      !
      ! don't damp Golden Networks
      !
      route-map graded-flap-damping deny 10
        match ip address prefix-list golden-networks
      !
      !    - /24 and longer prefixes: max=min outage 60 minutes
      !
      route-map graded-flap-damping permit 20
        match ip address prefix-list min24
        set damp 30 820 3000 60
      !
      !    - /22 and /23 prefixes: max outage 45 minutes but potential for
      !	 less because of shorter half life value - minimum of 30 minutes
      !	 outage
      
      route-map graded-flap-damping permit 30
        match ip address prefix-list max22-23
        set damp 15 750 3000 45
      !
      !    - all else prefixes: max outage 30 minutes min outage 10 minutes
      !
      route-map graded-flap-damping permit 40
        set damp 10 1500 3000 30
      !
      !-----------------------------------------------------------------------
      ! DEFINE PREFIX-LISTS
      !-----------------------------------------------------------------------
      !
      ! OPTIONAL default-networks
      !no ip prefix-list default-networks
      !ip prefix-list default-networks description Candidate Default Routes
      !
      no ip prefix-list golden-networks
      ip prefix-list golden-networks description Golden Networks
      ! See 7.1 above for sample list
      !
      no ip prefix-list min24
      ip prefix-list min24 description Apply to /24 and longer prefixes
      ip prefix-list min24 permit 0.0.0.0/0 ge 24
      !
      no ip prefix-list max22-23
      ip prefix-list max22-23 description Apply to /22 and /23 prefixes
      ip prefix-list max22-23 permit 0.0.0.0/0 ge 22 le 23
      !
      
      A.3 Study of Flap Damping Operation
      
      It is instructive to observe how route flap damping actually works on
      a router - doing so will help the reader understand how the particular
      values described above were chosen.
      
      The test bed had two Cisco routers connected to each other. One router
      originated prefixes, the other one had the flap damping parameters described
      above in the text. The router originating the prefixes would withdraw a
      prefix, then reannounce, then withdraw, reannounce, etc. The BGP process
      in IOS checks every 60 seconds for any new or withdrawn prefixes in the
      local configuration - so on the source router, the withdraw and announce
      was done by removing and adding the BGP network statement for the prefix
      in question.  The router monitoring the flaps would see the prefix being
      withdrawn and then announced 60s later.
      
      A.3.1 For /24s
      
      Parameters used are "set dampening 15 820 3000 30"
         1st flap   1000   decay to 966, 982 at update
         2nd flap   1966   decay to 1894, 1926 at update
         3rd flap   2894   decay to 2787, 2846 at update
         4th flap   3280   decay to 3165, 3226 at update
      
      Maximum possible penalty is 3280 as defined by the flap parameters, so
      the penalty at the 4th flap was only incremented from 2787 to 3280, not
      3787 as might have been expected. At the 4th flap the prefix was marked as
      being suppressed for 59 minutes when the update message was received. If
      the update after the 4th flap was not received within 4 minutes and 20
      seconds, the penalty dropped below 3000, and the prefix was not suppressed.
      
      A.3.2 For /22s, /23s
      
      Parameters used are "set dampening 15 750 3000 45"
         1st flap   1000   decay to 921, 960 at update
         2nd flap   1921   decay to 1777, 1850 at update
         3rd flap   2777   decay to 2583, 2671 at update
         4th flap   3583   decay to 3311, 3451 at update
      
      Maximum possible penalty is 6000. At the 4th flap the prefix was marked as
      being suppressed for 33 minutes when the update message was received. If
      the update after the 4th flap was not received within 4 minutes and 40
      seconds, the penalty dropped below 3000, and the prefix was not suppressed.
      
      A.3.3 For remaining prefixes
      
      Parameters used are "set dampening 10 1500 3000 30"
         1st flap   1000   decay to 889, 946 at update
         2nd flap   1889   decay to 1679, 1781 at update
         3rd flap   2679   decay to 2367, 2526 at update
         4th flap   3367   decay to 3019, 3176 at update
      
      Maximum possible penalty is 12000. At the 4th flap the prefix was marked as
      being suppressed for 10 minutes when the update message was received. If the
      update after the 4th flap was not received within 2 minutes and 5 seconds,
      the penalty dropped below 3000, and the prefix was not suppressed.
      
      A.3.4 Summary
      
      When analysing flap damping performance on the router or across the network,
      network managers should compare with the above lab tests. Note especially
      that slowly flapping prefixes are unlikely to be suppressed even though
      they show significant flapping history. A future version of this document
      may consider what to do in this instance.
      
      
       >>>>end
      
      *             APOPS: Asia Pacific Operations Forum              *
      * To unsubscribe: send "unsubscribe" to apops-request at apnic dot net *