- routing-wg - mailman.ripe.net

Re: DRAFT 2.0 of Route-Flap Dampening Paper, last call for comments
by Christian Panigl, ACOnet/UniVie 10 Feb '98

10 Feb '98

>Date: Sun, 8 Feb 1998 20:32:03 -0500 (EST) >From: Andrew Partan <asp(a)partan.com> > >I don't really have much of a problem with some 'golden' prefixes >but I think that you should put down some more of the reasoning >and background in the document. Hi Andrew, yeah, thanks, your question triggered another final-final update, which made it into the doc: ======================================================================= = 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 = of the access to vital infrastructure elements of the Internet. A most = prominent example are root nameservers. = = At least in principle, there should be enough redundancy for root = nameservers. Though, in fact 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 nameservers for an = hour (at least those sitting in a /24 or longer prefix). Therefore we = decided to define those "golden networks". Probably we could remove the = exemptions for the A, D and H servers, which are sitting in a /16. We = might consider this for a new version of the recommendation. Our = recommendation is just dealing with a minimum set of "golden networks" = which of course might be extended by local decision. = = Still these must be exceptions resulting from strong needs - the rule = should be to apply coordinated route flap damping throughout. ======================================================================= >But please don't hold up this document just for this - getting the >rest of the stuff done - with global uniform deployment of dampening >is quite important. [For what its worth, Verio (AS 2914) deployed >your documented dampening parameters last week - we had been running >dampening with the cisco defaults prior to this.] Hey great news, thanks !!! Regards CP --- ---------------------------------------------------------------------- --- --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet - VIX : -------------------------------------------- --- --- Universitaetsstrasse 7 : Mail: Panigl(a)CC.UniVie.ac.at (CP8-RIPE) --- --- A-1010 Vienna / Austria : Tel: +43 1 4277-14032 (Fax: -9140) --- --- ---------------------------------------------------------------------- ---

2 1

Re: DRAFT 2.0 of Route-Flap Dampening Paper, last call for comments
by Christian Panigl, ACOnet/UniVie 09 Feb '98

09 Feb '98

>Date: Mon, 26 Jan 1998 21:02:14 -0500 (EST) >From: Andrew Partan <asp(a)partan.com> > >Can someone spell out a bit more the reason behind exempting the >routes that the root servers live in from being damped? Why should >they get special treatment? And why just them (and the rest of >the hosts that happen to live in those prefixes)? > >There are a lot of root servers; if you can't reach some of them, >so what? Hi Andrew, we've been through this a couple of times. You are perfectly right, that, at least in principle, there should be enough redundancy for root nameservers. Though, in fact 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 nameservers for an hour (at least those sitting in a /24 or longer prefix). Therefore we decided to define those "golden networks". Probably we could remove the exemptions for the A, D and H servers, which are sitting in a /16. We might consider this for a new version of the recommendation. Our recommendation is just dealing with a minimum set of "golden networks" which of course might be extended by local decision. I'm now finishing the Version 1.0 of the paper, considering all other comments received so far. Any further input is still welcome and will be considered for an updated version which, if needed, may be expected for autumn this year. Kind regards CP --- ---------------------------------------------------------------------- --- --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet - VIX : -------------------------------------------- --- --- Universitaetsstrasse 7 : Mail: Panigl(a)CC.UniVie.ac.at (CP8-RIPE) --- --- A-1010 Vienna / Austria : Tel: +43 1 4277-14032 (Fax: -9140) --- --- ---------------------------------------------------------------------- ---

2 1

unsubscribe
by Cao Pierre 03 Feb '98

03 Feb '98

unsubscribe

1 0

Re: The Cidr Report
by Vince Fuller 02 Feb '98

02 Feb '98

> As you can see things are startng to move up recently. I'd suggest > folks take a look at the "Interesting Aggregates" section on the web > page as it appears there's been a large influx of routes > here. Particularly AS719 who look like they may have a config error > with many many /28s showing up. They aren't the only ones as there > seems to be a lot of potential savings to be made here just by > eye-balling the aggregates. It looks like AS 719 may have cleaned-up their act, but there is still a lot of garbage in that section of the report. Most of them seem to be subnets of /16's that all have the same AS path and therefore have no reason to not be aggregated. 168.108.x.y, 166.102.x.y, 152.166.x.y-152.172.x.y, 129.81.x.y, and 139.175.x.y are the most obvious offenders - all of the components of each are singly-homed to a single AS path (yes, AS 1 has a couple of small ones not listed above - I'll see about chasing those down). Others, like 161.11.x.y, 138.87.x.y, 137.15.x.y, 137.98.x.y, and 143.233.x.y appear to be multi-homed but still shouldn't need to be propagated to the global Internet. If you're going to accept CIDR block subcomponents from your customers for load-balancing or other purposes, please set community "no-advertise" or otherwise prevent them from leaking out to the rest of the net - everyone else doesn't need to see your trash... --Vince (note: from address modified to discourage spam)

2 1

The Cidr Report
by Tony Bates 30 Jan '98

30 Jan '98

This is an auto-generated mail on Fri Jan 30 12:00:00 PST 1998 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 30Jan98 0) General Status Table History ------------- Date Prefixes 230198 48658 240198 48671 250198 48612 260198 49037 270198 49125 280198 49117 290198 50396 300198 50242 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 95.9.43.0/24 from AS2878 *** Bogus 212.192.0.0/16 from AS5568 *** Bogus 212.255.0.0/16 from AS2871 AS Summary ---------- Number of ASes in routing system: 3169 Number of ASes announcing only one prefix: 1477 (766 cidr, 711 classful) Largest number of cidr routes: 1103 announced by AS719 Largest number of classful routes: 1022 announced by AS701 1) Gains by aggregating at the origin AS level --- 30Jan98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 726 386 340 46.8% iSTAR Internet, Inc. AS6235 495 252 243 49.1% Intermedia Communications, Inc. AS4293 424 215 209 49.3% IMCI AS174 856 659 197 23.0% Performance Systems International AS816 598 417 181 30.3% UUNET Canada (ASN-UUNETCA-AS4) AS3602 456 304 152 33.3% Sprint Canada Inc. AS3749 200 59 141 70.5% TECNET AS701 1022 909 113 11.1% Alternet AS1785 456 371 85 18.6% NYSERNet Backbone AS3751 123 47 76 61.8% SNET-AS AS2048 165 93 72 43.6% LaNet AS5668 107 40 67 62.6% Century Telephone Inc. AS1239 602 539 63 10.5% SprintLink Backbone AS3804 203 141 62 30.5% Bell Solutions AS1 842 784 58 6.9% BBNPLANET AS271 111 56 55 49.5% BCnet Backbone AS3464 119 67 52 43.7% Alabama Research and Education Ne AS719 519 468 51 9.8% LANLINK autonomous system AS549 210 160 50 23.8% ONet Backbone AS7545 115 67 48 41.7% TPG Internet Pty Ltd AS72 84 36 48 57.1% Schlumberger Information Network AS4763 128 80 48 37.5% Telstra New Zealand AS1221 263 218 45 17.1% AARNET-AS AS7046 123 81 42 34.1% UUNET-CUSTOMER AS2711 97 55 42 43.3% SUNBELT-AS AS684 85 44 41 48.2% Manitoba Regional Network Backbon AS3561 914 873 41 4.5% MCI AS852 155 116 39 25.2% AGT Advance Communication AS6335 62 24 38 61.3% NTRNET AS1691 162 124 38 23.5% BCTEL For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 1

Subscribe
by Mark Johnson 29 Jan '98

29 Jan '98

1 0

DRAFT 2.0 of Route-Flap Dampening Paper, last call for comments
by Christian Panigl, ACOnet/UniVie 27 Jan '98

27 Jan '98

=============================================================================== RIPE Routing-WG Recommendation for coordinated route-flap dampening paramters Tony Barber Sean Doran Daniel Karrenberg Christian Panigl Joachim Schmitz Document status: DRAFT 2.0 26-JAN-1998 to be released as an official RIPE document shortly after RIPE29 meeting ABSTRACT This paper recommends a set of route-flap dampening parameters which should be applied by all ISPs in the Internet and should be deployed as new default values by BGP router vendors. Table of Contents ABSTRACT 1. Introduction 1.1 Motivation for route-flap dampening 1.2 What is route-flap dampening ? 1.3 "Progressive" versus "flat&gentle" approach 1.4 Motivation for coordinated parameters 1.5 Aggregation versus dampening 2. Recommended dampening parameters 2.1 Motivation for recommendation 2.2 Description of recommended dampening parameters 2.3 Example configuration for Cisco IOS 2.4 No BGP fast-external-fallover (Cisco IOS) 2.5 Clear IP BGP soft (Cisco IOS) 3. Further problems 3.1 Multiplication of flaps through multiply interconnected ASes 3.2 Software bug counts flaps twice 4. References 1. Introduction Route-flap dampening is a mechanism for (BGP) routers which is aimed at improving the overall stability of the Internet routing table and offloading core-routers CPUs. In the Routing WG session of RIPE26 Christian Panigl asked whether people are interested to participate in a BOF on route flap dampening. The BOF session was held after the plenary session of RIPE26. The discussion was continued in the Routing WG session of RIPE27 and led to a task-force directed to write a proposal document for coordinated route-flap dampening parameters. 1.1 Motivation for route-flap dampening In the early 1990s the massive growth of the Internet with regard to the number of announced prefixes (often due to inadequate prefix-aggregation), multiple paths and instabilities started to do significant harm to the efficiency of the core routers of the Internet. Every single line-flap at the periphery which makes a routing prefix unreachable has to be advertised to the whole core Internet and has to be dealt by every single router by means of updates of the routing-table. To overcome this situation a route-flap dampening mechanism was invented in 1993 and has been integrated into several router code since 1995 (Cisco, ISI/RSd, GateD Consortium). It significantly helps now with keeping severe instabilities more local. And there's a second benfit: it's 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 dampening is at its best value and most consistent and helpfull if applied as near to the source of the problem as possible. Therefore flap-dampening should not only be applied at peering and upstream boundaries but even more at customer boundaries (see 1.4 and 1.5 for details). 1.2 What is route-flap dampening ? When BGP route-flap dampening is enabled in a router the router starts to collect statistics about the announcement and withdrawal of prefixes. Route-flap dampening 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 dampening mechanism is basically the same: If a threshold of the number of pairs of withdrawals/announcements (=flap) is exceeded in a given timeframe (cutoff threshold) the prefix is held down for a calculated period (penalty) which is further incremented with every subsequent flap. The penalty is then decremented by using a half-life parameter until the penalty is below a reuse threshold. Therefore, after beeing stable up for a certain period the hold-down is released from the prefix and it is re-used and re-advertised. Pointers to some more detailed and vendor specific documents: Cisco BGP Case Studies: Route Flap Dampening http://www.cisco.com/warp/public/459/16.html ISI/RSd Configuration: Route Flap Dampening http://www.isi.edu/div7/ra/RSd/doc/dampen.html GateD Configuration: Weighted Route Dampening Statement http://www.gated.org/new_web/code/doc/gated-uni/config_guide/wrd.html See also "4. 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 effect more users. Another aspect is that progressive dampening 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. Because a significant number of important services is sitting in long prefixes (e.g. root nameservers) the progressive approach has to exclude the strong penalisation for those long but "golden" prefixes. With this recommendation we are trying to make a compromise and call it therefore "graded dampening". 1.4 Motivation for coordinated parameters There is a strong need for the coordinated use of dampening parameters because of several reasons: Coordination of "progressiveness": If the boundaries for different treatment of longer prefixes and the penalties are not coordinated throughout the Internet, route-flap dampening could even 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-thershold parameters: If an upstream or peering provider would be dampening 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 hotline 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-dampening for his customer on his local router instead of needing to contact upstream NOCs all over the Internet to get the dampening cleared. 1.5 Aggregation versus dampening Of course, if a customer is just using Provider Aggregated addresses, the aggregating upstream provider doesn't need to apply dampening on these prefixes towards his customer, because instabilities of such prefixes wouldn't propagate into the Internet. However, if a customer insists to announce prefixes which can't be aggregated by its provider dampening should be applied for the reasons given in 1.4. Reasons might be dual-homing (to different providers) of a customer or customers reluctance to renumber into the providers aggregated address range. 2. Recommended dampening 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 dampening in some upstream and peering ISPs routers for all his and his customers /24 prefixes for more than 3 hours because of too "aggressive" paramters: 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 dampening scenario at some boundaries with progressive route-flap dampening 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 dampening does (see: 2.3). Those suggestions in mind Tony Barber designed the following set of route-flap dampening parameters which have prooved to work smoothly in his environment for a couple of months. 2.2 Description of recommended dampening parameters Basically the recommended values do the following with harsher treatment for /24 and longer prefixes: - don't start dampening before the 4th flap in a row (suppress-value = 3000) - /24 and longer prefixes: max=min outage 60 minutes - /22 and /23 prefixes: max outage 45 minutes but potential for less because of half life value - minimum of 30 minutes outage - all else prefixes: max outage 30 minutes min outage 10 minutes 2.3 Example configuration for Cisco IOS ! Parameters are : ! set dampening <half life> <reuse-at> <supress-at> <max suppress time> ! There is a 1000 penalty for each flap ! Penalty decays at granularity of 5 seconds ! Unsuppressed at granularity of 10 seconds ! Dampening info kept until penalty becomes < half of reuse limit. ! ! current Cisco/IOS value-ranges and defaults: ! ! <half-life-time> (range is 1-45 min, current default is 15 min). ! <reuse-value> (range is 1-20000, default is 750). ! <suppress-value> (range is 1-20000, default is 2000). ! <max-suppress-time> (maximum duration a route can be suppressed, range ! is 1-255 min, default is 30 min ). ! router bgp 65500 !no bgp damp bgp damp route-map graded-flap-dampening ! ! don't dampen candidate default routes ! OPTIONAL (not part of recommendation) ! access-list 189 is the candidate default routes ! no route-map graded-flap-dampening deny 5 route-map graded-flap-dampening deny 5 match ip address 189 ! ! don't dampen root nameserver nets ! no route-map graded-flap-dampening deny 7 route-map graded-flap-dampening deny 7 match ip address 180 ! ! - /24 and longer prefixes: max=min outage 60 minutes ! no route-map graded-flap-dampening permit 10 route-map graded-flap-dampening permit 10 match ip address 181 set dampening 30 750 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 ! no route-map graded-flap-dampening permit 20 route-map graded-flap-dampening permit 20 match ip address 182 set dampening 15 750 3000 45 ! ! - all else prefixes: max outage 30 minutes min outage 10 minutes ! no route-map graded-flap-dampening permit 40 route-map graded-flap-dampening permit 40 set dampening 10 1500 3000 30 ! !----------------------------------------------------------------------- ! ACCESS LISTS 180-189 GO BELOW !----------------------------------------------------------------------- ! access-lists 180 to 189 used or reserved for progressive route flap dampening ! ! 180 - BGP dampening - root-nameservers.net networks are NOT dampened ! This filter stops these networks being dampened. ! Also DONT dampen routes used to derive default (see list 7) ! but this is handled in a separate route-map statement. ! in the file dampening-confg. ! Route map uses DENY to drop out of map on matching. ! no access-list 180 ! ! A.ROOT-SERVERS.NET. access-list 180 permit ip 198.41.0.0 0.0.0.0 255.255.252.0 0.0.0.0 ! ! B.ROOT-SERVERS.NET. access-list 180 permit ip 128.9.0.0 0.0.0.0 255.255.0.0 0.0.0.0 ! ! C.ROOT-SERVERS.NET. access-list 180 permit ip 192.33.4.0 0.0.0.0 255.255.255.0 0.0.0.0 ! ! D.ROOT-SERVERS.NET. access-list 180 permit ip 128.8.0.0 0.0.0.0 255.255.0.0 0.0.0.0 ! ! E.ROOT-SERVERS.NET. access-list 180 permit ip 192.203.230.0 0.0.0.0 255.255.255.0 0.0.0.0 ! ! F.ROOT-SERVERS.NET. access-list 180 permit ip 192.5.4.0 0.0.0.0 255.255.254.0 0.0.0.0 ! ! G.ROOT-SERVERS.NET. access-list 180 permit ip 192.112.36.0 0.0.0.0 255.255.255.0 0.0.0.0 ! ! H.ROOT-SERVERS.NET. access-list 180 permit ip 128.63.0.0 0.0.0.0 255.255.0.0 0.0.0.0 ! ! I.ROOT-SERVERS.NET. access-list 180 permit ip 192.36.148.0 0.0.0.0 255.255.255.0 0.0.0.0 ! ! J.ROOT-SERVERS.NET. 198.41.0.10 same net as A ! ! K.ROOT-SERVERS.NET. access-list 180 permit ip 193.0.14.0 0.0.0.0 255.255.255.0 0.0.0.0 ! ! L.ROOT-SERVERS.NET. 198.32.64.12 access-list 180 permit ip 198.32.64.0 0.0.0.255 255.255.255.0 0.0.0.255 ! ! M.ROOT-SERVERS.NET. 198.32.65.12 access-list 180 permit ip 198.32.65.0 0.0.0.255 255.255.255.0 0.0.0.255 ! ! ! - 181 - dampens /24 and greater prefixes ! no access-list 181 ! access-list 181 permit ip 0.0.0.0 255.255.255.255 255.255.255.0 0.0.0.255 access-list 181 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 ! ! - 182 - dampens /23 /22 and above ! no access-list 182 ! access-list 182 permit ip 0.0.0.0 255.255.255.255 255.255.252.0 0.0.3.255 access-list 182 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 ! ! - 189 - Candidate default networks used in some customer bgp implementations ! no access-list 189 ! access-list 189 permit ip !!! put your defaults in here access-list 189 deny ip any any ! 2.4 No BGP fast-external-fallover (Cisco IOS) In Cisco IOS there is a BGP configuration parameter "fast-external-fallover" which when on (default) leads to an immediate clearing of a BGP neighbor whenever the line-protocol to this external neighbor goes down. If it is turned off the BGP sessions will survive short line-flaps as they 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 switchover to an alternative path will take longer. We are recommending to turn off fast-external-fallover whenever possible: ! router bgp 65501 no bgp fast-external-fallover ! 2.5 Clear IP BGP soft (Cisco IOS) There is a new "soft" mechanism for the clearing of BGP sessions available with newer versions of Cisco IOS. For beeing able to make use of the "clear ip bgp x.x.x.x soft inbound" command the router which should support it needs to be configured for additional data structures: ! 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 neighbor 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 neighbor against locally configured inbound route-maps and filter-lists. 3. Open problems 3.1 Multiplication of flaps through multiply interconnected ASes Christian Panigl recently made the following experience with a line upgrade of an Ebone customer: - It is absolutely positive that through the upgrade process just ONE flap was generated (disconnect router-port from modem A reconnect to modem B), nevertheless the customers prefix was dampened in all ICM routers (ICM/AS1800 is US upstream for Ebone). - 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 paths). - This would then potentially hold true for any meshed topology because of the propagation delays of advertisements/withdrawals. - Workaround for scheduled actions like with the given example: Schedule a downtime for at least 3-5 minutes which should be enough for the prefix withdrawals to have propagated through all paths before reconnection and re-advertisement of the prefix. Avoid clearing BGP sessions as this is usually generating a 30" outage which might easily give the same result. - A solution has to be provided by the vendors ! 3.2 Software bug counts flaps twice A bug was identified in the dampening code of of some Cisco IOS releases where a penalty is assigned and the flap counter is incremented even when a withdrawn prefix is re-announced. This bug is said to be fixed in the following IOS versions and above: 11.1(16)CA 11.2(10)* 11.3(0.6) Everybody who has dampening enabled should verify to have a corrected IOS version running. 4. References RIPE/Routing-WG Minutes dealing with Route Flap Dampening: ftp://ftp.ripe.net/ripe/minutes/ripe-m-24.ps ftp://ftp.ripe.net/ripe/minutes/ripe-m-25.ps 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 Internet-Draft: BGP Route Flap Dampening ftp://ietf.org/internet-drafts/draft-ietf-idr-route-damp-01.txt (Expires July 8, 1998) Curtis Villamizar, ANS: Controlling BGP/IDRP Routing Overhead http://engr.ans.net/route-dampen/ NANOG-Feb-1995 Route Flap Dampening Presentation (slides): ftp://engr.ans.net/pub/papers/slides/nanog-feb-1995-route-dampen.ps Merit/IPMA: Internet Routing Recommendations http://www.merit.edu/~ipma/docs/help.html Cisco BGP Case Studies: Route Flap Dampening http://www.cisco.com/warp/public/459/16.html ISI/RSd Configuration: Route Flap Dampening http://www.isi.edu/div7/ra/RSd/doc/dampen.html GateD Configuration: Weighted Route Dampening Statement http://www.gated.org/new_web/code/doc/gated-uni/config_guide/wrd.html

2 1

The Cidr Report
by Tony Bates 23 Jan '98

23 Jan '98

This is an auto-generated mail on Fri Jan 23 12:00:00 PST 1998 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 23Jan98 0) General Status Table History ------------- Date Prefixes 160198 48136 170198 47944 180198 47971 190198 48017 200198 48183 210198 48498 220198 48637 230198 48658 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 212.192.0.0/16 from AS5568 *** Bogus 212.255.0.0/16 from AS2871 AS Summary ---------- Number of ASes in routing system: 3149 Number of ASes announcing only one prefix: 1462 (756 cidr, 706 classful) Largest number of cidr routes: 450 announced by AS3561 Largest number of classful routes: 1005 announced by AS701 1) Gains by aggregating at the origin AS level --- 23Jan98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 705 396 309 43.8% iSTAR Internet, Inc. AS6235 489 254 235 48.1% Intermedia Communications, Inc. AS4293 425 211 214 50.4% IMCI AS174 875 671 204 23.3% Performance Systems International AS816 581 404 177 30.5% UUNET Canada (ASN-UUNETCA-AS4) AS3602 453 301 152 33.6% Sprint Canada Inc. AS3749 201 60 141 70.1% TECNET AS701 1005 896 109 10.8% Alternet AS3751 123 47 76 61.8% SNET-AS AS2048 161 91 70 43.5% LaNet AS5668 106 40 66 62.3% Century Telephone Inc. AS3804 203 141 62 30.5% Bell Solutions AS1 846 787 59 7.0% BBNPLANET AS549 216 159 57 26.4% ONet Backbone AS271 111 56 55 49.5% BCnet Backbone AS3464 116 63 53 45.7% Alabama Research and Education Ne AS1239 578 526 52 9.0% SprintLink Backbone AS7545 114 66 48 42.1% TPG Internet Pty Ltd AS72 84 36 48 57.1% Schlumberger Information Network AS4763 127 79 48 37.8% Telstra New Zealand AS719 507 461 46 9.1% LANLINK autonomous system AS684 84 39 45 53.6% Manitoba Regional Network Backbon AS1221 257 212 45 17.5% AARNET-AS AS2711 97 55 42 43.3% SUNBELT-AS AS3561 922 881 41 4.4% MCI AS6335 62 24 38 61.3% NTRNET AS4740 333 295 38 11.4% ASN-OZEMAIL (Ozemail Pty Ltd) AS4682 62 24 38 61.3% ITJ Intelligent Telecom Inc., AS1691 161 123 38 23.6% BCTEL AS6332 83 46 37 44.6% TELNOR For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

New european "looking glass" !
by Poul-Henning Kamp 22 Jan '98

22 Jan '98

Cybercity Internet Denmark has made available a "looking glass" which can be used to determine if BGP routing does what you expect it to. http://stat.cybercity.dk/lg -- Poul-Henning Kamp FreeBSD coreteam member phk(a)FreeBSD.ORG "Real hackers run -current on their laptop."

1 0

Draft Agenda RIPE 29 Routing WG
by SchmitzJo 19 Jan '98

19 Jan '98

Dear all, please find enclosed the draft agenda for the Routing WG session at RIPE 29. It will be held on Wednesday, 28.1.98, 9:00am. For the location see the RIPE web server http://www.ripe.net/meetings/ripe/mtg.html Regards Joachim ---- R I P E 2 9 A M S T E R D A M Routing Working Group Session 28-Jan-98 Draft Agenda A. Preliminaries (Joachim Schmitz) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 28 minutes - actions from earlier meetings B. Current Developments - RIPE document on route flap dampening (Christian Panigl) - progress on rpsl implementation (Carol Orange) C. Using Internet Routing Announcements to Identify Incorrect IRR Data (Gerald Winters) - progress on PAIR - indentifying incorrect IRR data - examples of "interesting" IRR usage - role of the IRR D. IRR Authorization (Carol Orange) Y. General Input from Other WGs Z. AOB ----

1 0