- NANOG - lists.nanog.org

Draft revision of RIPE-210: Coordinated Route Flap Damping Parameters
by Philip Smith 24 Apr '01

24 Apr '01

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

1 0

Re: Future of route-servers
by Dale Fay 24 Apr '01

24 Apr '01

Merit is interested in providing route servers on the Mae-East ATM and discussions with WorldCom are continuing. Please let Merit RSng (rsng(a)merit.edu) and WorldCom know that you are interested in this service. Dale On Mon, Apr 23, 2001 at 10:45:53AM -0400, Vinny India wrote: > > Anyone out there know what the future is for route servers at MAE-EAST, I > don't know of any route-servers being implemented off the MAE-ATM service. > If anyone knows something please let us know. > -- Dale Fay Merit RSng/RADB www.rsng.net www.radb.net ----- End forwarded message ----- -- Dale Fay Merit RSng/RADB www.rsng.net www.radb.net

1 0

Fw: Information from an FTP violation this weekend.
by Moe Allen 24 Apr '01

24 Apr '01

Good luck, guys. We had left an incoming open on our FTP server for our Unix guys to upload code on. BTW, this occurred over the Thanks Giving Holiday. Anyway a guy from .ru uploaded the latest version of (sp)Tumbarator 5 which had just been released in Europe, that morning & Mummy. Then the bum put our IP address on all the warez sites and we had so may people hitting our server that we had no bandwidth left back to the Internet and no more ports on our FTP Unix server. It got so bad that we had to deny all of Europe just to take some of the load off us. Then for the next 60 days we handled the US group. Needless to say we logged everything and contacted the software groups involved and made them available. But it was a nightmare for a long time at our office. So I can sympathize with your problems. Respectfully, Morris Allen VidcomNet, Inc. ----- Original Message ----- From: "Stephen J. Wilcox" <steve(a)opaltelecom.co.uk> To: "Smith, Rick" <rsmith(a)atsworld.com> Cc: <nanog(a)merit.edu> Sent: Monday, April 23, 2001 11:19 AM Subject: Re: Information from an FTP violation this weekend. > > And I thought the Internet was such a friendly, welcoming > environment.. maybe I should remove all my telnet guest logins from my > servers and remove my credit card number from my homepage.. > > Steve > > > > On Mon, 23 Apr 2001, Smith, Rick wrote: > > > > > > > Nanog; fyi. > > > > APNIC / Excite / Home.net - > > > > We have an ftp site running on 209.123.52.40 that is made writable at > > certain periods of time for anonymous users. Some of our customer's systems > > are programmed to send in bug reports, problem programs, etc at these times. > > One of these periods of time was this past Friday (4/20/01) from 6pm EST to > > Saturday afternoon at Noon. In that time period, a couple of hundred megs > > of movies / warez / crap was dropped onto the ftp site, and then the people > > that were (I presume) loading up the site got cut off. > > > > Not only did the violator from 203.164.51.0/24 store illegal information on > > our ftp site, they also deleted everything that existed. Not anyone's fault > > there but our own, and no problem since there were backups, but just fyi > > that this stuff is happening out there from the reported networks. > > > > Here's some information I collected from a .htaccess file in one of the > > directories that these <insert explative here> left. > > > > <Limit GET> > > order allow,deny > > deny from 141.201.222. > > deny from 24.141.20. > > deny from 24.141.36. > > deny from 65.1.50. > > . > > . Bunch of Denies > > . > > allow from 203.164.51. > > deny from 203.164.3. > > deny from 62.30.0. > > . > > . Bunch of Denies > > . > > allow from all > > </Limit> > > > > > > > > I run Portsentry on my FreeBSD firewall, which caught and denied this: > > 987814775 - 04/20/2001 20:59:35 Host: www.uov.net/209.37.153.6 Port: 515 TCP > > Blocked > > > > > > The swip info for the one allow statement in that htaccess file: > > > > [root]# whois -h whois.arin.net 203.164.51.0 > > > > Asia Pacific Network Information Center (APNIC2) > > These addresses have been further assigned to Asia-Pacific users. > > Contact info can be found in the APNIC database, > > at WHOIS.APNIC.NET or http://www.apnic.net/ > > Please do not send spam complaints to APNIC. > > AU > > > > Netname: APNIC-CIDR-BLK > > Netblock: 202.0.0.0 - 203.255.255.255 > > Maintainer: AP > > > > > > Gee - go figure - a cable modem ween > > > > [root]# whois -h whois.apnic.net 203.164.51.0 > > > > % Rights restricted by copyright. See > > http://www.apnic.net/db/dbcopyright.html > > > > inetnum: 203.164.48.0 - 203.164.51.255 > > netname: ATHOME-AU-RIVRW-1 > > descr: Infrastructure > > country: AU > > admin-c: HH85-AP > > tech-c: AI13-AP > > mnt-by: MAINT-AU-ATHOME > > changed: ipmgmt(a)excitehome.net 20000911 > > source: APNIC > > > > person: Hostmaster Home Network Australia > > address: 100 Harris Street > > address: Pyrmont > > address: NSW 2009 > > phone: +61 2 9005 1000 > > fax-no: +61 2 9005 1076 > > country: AU > > e-mail: hostmaster(a)homenetwork.com.au > > nic-hdl: HH85-AP > > mnt-by: MAINT-AU-ATHOME > > changed: judithh(a)corp.home.net 20000830 > > source: APNIC > > > > person: ATHome-AU IP Mgmt > > address: 450 Broadway Street > > address: Redwood City, CA 94063 > > address: US > > phone: +1-800-872-3595 > > country: AU > > e-mail: ipmgmt(a)excitehome.neet > > nic-hdl: AI13-AP > > mnt-by: MAINT-AU-ATHOME > > changed: judithh(a)corp.home.net 20000830 > > source: APNIC > > > > > > > > Thanks, > > Rick Smith > > Director of Technical Services > > Applied Tactical Systems > > (A division of Vertex Interactive, Inc.) > > <http://www.atsworld.com> --- <http://www.vertexinteractive.com> > > (973) 808 - 1750 x382 > > > > > > > > -- > Stephen J. Wilcox > IP Services Manager, Opal Telecom > http://www.opaltelecom.co.uk/ > Tel: 0161 222 2000 > Fax: 0161 222 2008 > >

2 1

ARIN virtual web hosting policy change
by Alec H. Peterson 23 Apr '01

23 Apr '01

The ARIN Advisory Council has recommended changes to the now-suspended virtual webhosting policy. Here is a link to the proposal: http://www.arin.net/mailinglists/ppml/0238.html Please direct __ALL__ comments about this to the ppml(a)arin.net mailing list. This is just an informational posting. Thanks, Alec -- Alec H. Peterson - ahp(a)hilander.com Staff Scientist CenterGate Research Group - http://www.centergate.com "Technology so advanced, even _we_ don't understand it!"

1 0

RE: What does 95th %tile mean?
by Andrew Odlyzko 23 Apr '01

23 Apr '01

I used to believe in the desirability and inevitability of metered rates for the Internet. However, my studies over the last few years have convinced me that flat rates are underappreciated and have a promising future. This is not the place to summarize my papers on this subject (all are available on my home page), but I couldn't resist the temptation to note that the discussion on this list over the last few days provides an interesting additional argument in favor of flat rates. First, while there have been many postings about 95th %tile pricing, nobody has said what that pricing actually is. Well, here is an example of such pricing, downloaded from the UUNet page 2 years ago. (I could not find current prices there on a quick scan. Perhaps somebody else can post them, especially for higher bandwidth connections.) Ignoring one-time start-up fees, regular flat rate T-1 service was available from UUNet at $2,495 per month. The burstable rate (based on the 95th %tile rating) was: T1 Usage Level Burstable Service Monthly Rate 0 to 128 Kbps $1,295 128 Kbps to 256 Kbps $1,895 256 Kbps to 384 Kbps $2,495 384 Kbps to 512 Kbps $2,750 Over 512 Kbps $3,000 Note that even if the link is not used at all, you pay more than half the cost of a full T-1 connection. (Hence some of the imaginative gaming schemes that have been proposed, involving rotating Web hosting traffic among a bunch of connections, are clear losers, as some posters have already noted. It is less expensive to have a single unlimited service T-1 than two burstable one.) Moreover, if your usage gets above a certain level, you pay more than for the full T-1. Yet another factor that comes in is that of discounts. The prices listed above were the list prices. I have been told by one member of this list that substantial discounts are common for full connections, but seldom for burstable ones, which makes the case against flat rate links even weaker. Second, after these preliminaries, here is the he novel argument for flat rates that I draw from the discussions on this list. Prices serve two main purposes. One is simply to collect enough money to pay for the service that is provided. How that money is collected can be based on a variety of criteria, such as charging what the service is worth to the consumer (as in airline Saturday night stopover restrictions, designed to get more money from business travelers than from discretionary vacationers), or fairness (which has many dimensions, as the discussion on this list showed, as in whether charges should be based on distance packets are carried, on time of day, ...). The other possible purpose of prices, and one often touted as their advantage on the Internet, is that they can be used to influence user behavior in ways that lead to more efficient utilization of resources (such as charging for email to reduce spam, or getting users to reduce their traffic during periods of congestion). However, for this second purpose to be realized, users have to understand the pricing scheme, and have to modify their behavior in response. But let's look at the discussion on this list. Here we have a group of unusually sophisticated Internet professionals, apparently many paying these 95th %tile prices. Yet it appears that many (perhaps even most) have been too busy to figure out how those prices are calculated. Most of the gaming that is going on (and that appears to be relatively little, by just a few sophisticated players) is apparently in ways to get around the rules of this 95th %tile schemes, while most people just pay the bills as they arrive and do not worry about what they should be doing differently. Yet if the members of this list behave like that (and I am definitely not suggesting this is economically irrational behavior, people do weigh costs and benefits, and my conclusion is that most people have more valuable things to do), then can one hope to introduce any sophisticated pricing scheme to the great bulk of Internet users? Andrew Odlyzko ************************************************************************ Andrew Odlyzko amo(a)research.att.com AT&T Labs - Research voice: 973-360-8410 http://www.research.att.com/~amo fax: 973-360-8178 ************************************************************************

4 4

RE: Chinese hackers attack - Risk Assessment?
by Petri Stephen 23 Apr '01

23 Apr '01

So far I've only seen this reported on Wired. The questions is; how serious is this threat? Any thoughts? Stephen Petri -----Original Message----- From: Rob Healey [mailto:rhealey@onvoy.com] Sent: Friday, April 20, 2001 1:18 PM To: Petri Stephen Cc: nanog(a)merit.edu Subject: Re: Chinese hackers plan week-long attack on American websites and ne tworks > .....As China and the United States attempt to peacefully end their > diplomatic standoff ...........crackers from both countries continue to wage > private wars on the Internet. > > ......Chinese hackers are now vowing to retaliate with a planned week-long > all-out crack attack on American websites and networks which will start on > May 1. ....... > > http://www.wired.com/news/politics/0,1283,43134,00.html?tw=wn20010419 > Hmmm, we've been seeing picked up activity from Chinese sites for well over a week now. They seem to be biased toward x86/Linux hacks/holes for now judging from attack analysis. General Port scan, DNS, HTTP and RPC hacks as well although specific buffer overflow/breakin code seems to be exclusively x86 for now. I suppose Solaris SPARC will soon follow as well as the x86 BSD's. -Rob -- Rob Healey rhealey(a)onvoy.com NE II ONVOY Core of Engineers Onvoy Phone (612) 362-5823 2829 University Avenue, S.E. Problems (612) 362-5800 Minneapolis, MN 55414 FAX (612) 362-5899

1 0

RE: Information from an FTP violation this weekend.
by Jade E. Deane 23 Apr '01

23 Apr '01

Hello, my toaster is connected at 192.168.5.44 and it was hax0red. My social security number is 275-53-4678, and my favorite color is blue. How pointless is this mail-list? /paxil > On Mon, 23 Apr 2001, Smith, Rick wrote: > > > > > > > Nanog; fyi. > > > > APNIC / Excite / Home.net - > > > > We have an ftp site running on 209.123.52.40 that is made writable at > > certain periods of time for anonymous users. Some of our customer's systems > > are programmed to send in bug reports, problem programs, etc at these times. > > One of these periods of time was this past Friday (4/20/01) from 6pm EST to > > Saturday afternoon at Noon. In that time period, a couple of hundred megs > > of movies / warez / crap was dropped onto the ftp site, and then the people > > that were (I presume) loading up the site got cut off. > > > > Not only did the violator from 203.164.51.0/24 store illegal information on > > our ftp site, they also deleted everything that existed. Not anyone's fault > > there but our own, and no problem since there were backups, but just fyi > > that this stuff is happening out there from the reported networks. > > > > Here's some information I collected from a .htaccess file in one of the > > directories that these <insert explative here> left. > > > > <Limit GET> > > order allow,deny > > deny from 141.201.222. > > deny from 24.141.20. > > deny from 24.141.36. > > deny from 65.1.50. > > . > > . Bunch of Denies > > . > > allow from 203.164.51. > > deny from 203.164.3. > > deny from 62.30.0. > > . > > . Bunch of Denies > > . > > allow from all > > </Limit> > > > > > > > > I run Portsentry on my FreeBSD firewall, which caught and denied this: > > 987814775 - 04/20/2001 20:59:35 Host: www.uov.net/209.37.153.6 Port: 515 TCP > > Blocked > > > > > > The swip info for the one allow statement in that htaccess file: > > > > [root]# whois -h whois.arin.net 203.164.51.0 > > > > Asia Pacific Network Information Center (APNIC2) > > These addresses have been further assigned to Asia-Pacific users. > > Contact info can be found in the APNIC database, > > at WHOIS.APNIC.NET or http://www.apnic.net/ > > Please do not send spam complaints to APNIC. > > AU > > > > Netname: APNIC-CIDR-BLK > > Netblock: 202.0.0.0 - 203.255.255.255 > > Maintainer: AP > > > > > > Gee - go figure - a cable modem ween > > > > [root]# whois -h whois.apnic.net 203.164.51.0 > > > > % Rights restricted by copyright. See > > http://www.apnic.net/db/dbcopyright.html > > > > inetnum: 203.164.48.0 - 203.164.51.255 > > netname: ATHOME-AU-RIVRW-1 > > descr: Infrastructure > > country: AU > > admin-c: HH85-AP > > tech-c: AI13-AP > > mnt-by: MAINT-AU-ATHOME > > changed: ipmgmt(a)excitehome.net 20000911 > > source: APNIC > > > > person: Hostmaster Home Network Australia > > address: 100 Harris Street > > address: Pyrmont > > address: NSW 2009 > > phone: +61 2 9005 1000 > > fax-no: +61 2 9005 1076 > > country: AU > > e-mail: hostmaster(a)homenetwork.com.au > > nic-hdl: HH85-AP > > mnt-by: MAINT-AU-ATHOME > > changed: judithh(a)corp.home.net 20000830 > > source: APNIC > > > > person: ATHome-AU IP Mgmt > > address: 450 Broadway Street > > address: Redwood City, CA 94063 > > address: US > > phone: +1-800-872-3595 > > country: AU > > e-mail: ipmgmt(a)excitehome.neet > > nic-hdl: AI13-AP > > mnt-by: MAINT-AU-ATHOME > > changed: judithh(a)corp.home.net 20000830 > > source: APNIC > > > > > > > > Thanks, > > Rick Smith > > Director of Technical Services > > Applied Tactical Systems > > (A division of Vertex Interactive, Inc.) > > <http://www.atsworld.com> --- <http://www.vertexinteractive.com> > > (973) 808 - 1750 x382 > > > > > > > > -- > Stephen J. Wilcox > IP Services Manager, Opal Telecom > http://www.opaltelecom.co.uk/ > Tel: 0161 222 2000 > Fax: 0161 222 2008 > >

1 0

Future of route-servers
by Vinny India 23 Apr '01

23 Apr '01

Anyone out there know what the future is for route servers at MAE-EAST, I don't know of any route-servers being implemented off the MAE-ATM service. If anyone knows something please let us know.

2 1

Information from an FTP violation this weekend.
by Smith, Rick 23 Apr '01

23 Apr '01

Nanog; fyi. APNIC / Excite / Home.net - We have an ftp site running on 209.123.52.40 that is made writable at certain periods of time for anonymous users. Some of our customer's systems are programmed to send in bug reports, problem programs, etc at these times. One of these periods of time was this past Friday (4/20/01) from 6pm EST to Saturday afternoon at Noon. In that time period, a couple of hundred megs of movies / warez / crap was dropped onto the ftp site, and then the people that were (I presume) loading up the site got cut off. Not only did the violator from 203.164.51.0/24 store illegal information on our ftp site, they also deleted everything that existed. Not anyone's fault there but our own, and no problem since there were backups, but just fyi that this stuff is happening out there from the reported networks. Here's some information I collected from a .htaccess file in one of the directories that these <insert explative here> left. <Limit GET> order allow,deny deny from 141.201.222. deny from 24.141.20. deny from 24.141.36. deny from 65.1.50. . . Bunch of Denies . allow from 203.164.51. deny from 203.164.3. deny from 62.30.0. . . Bunch of Denies . allow from all </Limit> I run Portsentry on my FreeBSD firewall, which caught and denied this: 987814775 - 04/20/2001 20:59:35 Host: www.uov.net/209.37.153.6 Port: 515 TCP Blocked The swip info for the one allow statement in that htaccess file: [root]# whois -h whois.arin.net 203.164.51.0 Asia Pacific Network Information Center (APNIC2) These addresses have been further assigned to Asia-Pacific users. Contact info can be found in the APNIC database, at WHOIS.APNIC.NET or http://www.apnic.net/ Please do not send spam complaints to APNIC. AU Netname: APNIC-CIDR-BLK Netblock: 202.0.0.0 - 203.255.255.255 Maintainer: AP Gee - go figure - a cable modem ween [root]# whois -h whois.apnic.net 203.164.51.0 % Rights restricted by copyright. See http://www.apnic.net/db/dbcopyright.html inetnum: 203.164.48.0 - 203.164.51.255 netname: ATHOME-AU-RIVRW-1 descr: Infrastructure country: AU admin-c: HH85-AP tech-c: AI13-AP mnt-by: MAINT-AU-ATHOME changed: ipmgmt(a)excitehome.net 20000911 source: APNIC person: Hostmaster Home Network Australia address: 100 Harris Street address: Pyrmont address: NSW 2009 phone: +61 2 9005 1000 fax-no: +61 2 9005 1076 country: AU e-mail: hostmaster(a)homenetwork.com.au nic-hdl: HH85-AP mnt-by: MAINT-AU-ATHOME changed: judithh(a)corp.home.net 20000830 source: APNIC person: ATHome-AU IP Mgmt address: 450 Broadway Street address: Redwood City, CA 94063 address: US phone: +1-800-872-3595 country: AU e-mail: ipmgmt(a)excitehome.neet nic-hdl: AI13-AP mnt-by: MAINT-AU-ATHOME changed: judithh(a)corp.home.net 20000830 source: APNIC Thanks, Rick Smith Director of Technical Services Applied Tactical Systems (A division of Vertex Interactive, Inc.) <http://www.atsworld.com> --- <http://www.vertexinteractive.com> (973) 808 - 1750 x382

2 1

Cooler servers for the Internet
by Sean Donelan 23 Apr '01

23 Apr '01

IBM is announcing several new servers today. One interesting feature of the press release is a new focus on power consumption and cooling. IBM directly targets the high heat generated by the SUN servers. Compared to a Sun Server, the new IBM servers have 1/3 the heat dissipation, based on the published specifications. IBM eServer p660 is 3,294 BTUs/hr compared with 9,420 BTUs/hr for a Sun Fire 3800. Of course, these numbers are pretty bogus. Most computer manufacture specification sheets are useless for accurately forecasting the power consumption of the equipment. I suspect, after Sun's PR people realize they are getting beat up, they will go back and better calculate the power consumption figures for their servers. I'm not very interested in who really has the coolest, most efficient computers. I am interested in getting accurate information for planning purposes. If this leads to computer vendors publishing more accurate information, great. I'm afraid instead, the pendulum will swing the other direction and vendors will begin understating their true power requirements.

5 5