January 1998 - routing-wg - mailman.ripe.net

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

minutes of the RIPE 28 session
by SchmitzJo 19 Jan '98

19 Jan '98

Dear all, at last - the minutes of our last session at the RIPE 28 meeting are available. Obviously, I did not yet distribute them (shame on me). The responsibility for late delivery is on me alone. Please compile your additions or comments and distribute them to the mailing list before our session next week. Thanks Joachim ---- Minutes Routing WG ------------------ Chair: Joachim Schmitz (JS395-RIPE) Minutes: Julia Edwards (JE316-RIPE) Attenders: 75 A. Preliminaries Joachim Schmitz opened the working group, introduced himself, passed the attenders' list around, and asked for a volunteer scribe. Julia Edwards volunteered as scribe. The working group agreed upon the minutes of the previous meeting, and accepted the draft agenda earlier circulated on the mailing list. Review of actions RIPE 27 Action 26.R3: J. Schmitz - open. To finalize the hierarchical authorization for route objects together with the Routing WG Action 27.R1: Carol Orange, RIPE NCC - suggested to be closed. To implement cross notification in the RR with modifications as agreed at the meeting of the 27th RIPE Routing WG. Action 27.R2: Carol Orange, RIPE NCC - suggested to be closed. To implement aut-num authorisation in the RR Action 27.R3: RIPE NCC - closed. To ask Tony Bates to send a copy of his regular CIDR report to the general RIPE mailing list as well. Action 27.R4: Task Force (Tony Barber, Sean Doran, Daniel Karrenberg and Christian Panigl) - suggested to be closed. To write proposal document and circulate to the RIPE Routing WG mailing list for discussion as soon as possible. B. Current developments A glance at IETF activities shows two important groups RIDE - Registry Information Data Exchange Chairs: David Kessens, Dhaval Shah http://www.isi.edu/~davidk/ride There have been 2 BOF sessions up to now, and it will become an IETF working group soon. Major objective of the group is how registries can exchange data from their databases. RPS - Routing Policy Systems Chairs: Daniel Karrenberg, Cengiz Allaettinoglu http://www.ietf.org/html.charters/rps-charter.html This is already a working group with considerable work being done. Major objective is a formalized and extensible description of routing policies on the Internet. One of the results from the RPS working group is RPSL, the Routing Policy Specification Language. It goes far beyond the possibilities offered by RIPE-181, and it is planned to implement it at RIPE. To give the RIPE community an overview of the current situation and of planned activities a joint session of the Routing and DB working groups will be held this RIPE meeting. RPSL Transition Session Featuring issues around RPSL and its implementation 25 September 1997, 9:00am C. Report from RIPE NCC (Carol Orange) There are currently two important topics regarding routing issues the RIPE NCC is working on. On the one hand RPSL has a lot of attention where the RPSL Transition Session is meant to give an overview. Work on this field at the current stage consists of coordination for the most part, but in the near future database coding will be the most important item. On the other hand the notification schemes discussed with the Routing WG are currently implemented. D. Authorisation/Notification with Route Objects in the RIPE DB * Cross Notification (Carol Orange) Cross notification got approval to be implemented at the last RIPE meeting. Implementation has actually started but has not yet finished due to restricted manpower. Chris Fletcher has been working on it and cross notification will be available on the RIPE Test DB in October. * Aut-num Authorization revisited (Joachim Schmitz) Joachim Schmitz again summarized several questions on aut-num authorization. Some of those had already been decided in a previous wg session but the discussion led to final consensus in all points. The results summarized are - If aut-num objects carry "mnt-route" attributes specifying maintainers, *only those listed* are allowed to *add* route objects of same origin - If *no* "mnt-route" attributes are present, *anybody* may *add* route objects of same origin - Independently from "mnt-route" attributes, maintainers of route objects may *always delete* them However, these rules at this time can only be enforced for one single registry. There is no mechanism in place which prevents someone to register the routes he wants with another registry if it does not work for the one he originally intended to use. This again triggered some discussion and the results are - aut-num authorization will not be delayed because of this issue - coordination among registries is vital The RIPE NCC was asked to approach the other registries to discuss this item. Action 28.R1: Carol Orange, RIPE NCC Contact other RR on the topic of distributed authorization * Hierarchical Authorization revisited (Joachim Schmitz) The current state is that anybody may add route objects for any origin, except for control by aut-num authorization. A second hierarchy may be applied as well, based on IP prefixes like it exists for inetnum objects. This would mean that route objects of different origins for given IP address ranges could only be handled if properly authorized. However, authorization only makes sense if it is enforced. As a consequence, additional restrictions are imposed. The question now is whether these can be accepted. Cons: - Restrictions hinder current practice. Why should route objects be registered by anyone if the administrative effort is too high? Routers in real life do not depend on registration. Going this way leads to a weakened IRR. - Domains and IP address space (inetnum objects) are tied to ownership immediately calling for control. Yet, who "owns" routes? Pros: - Routing and filters may be built from registry data calling for a tighter control of route objects because invalid registry data directly impacts real world routing if router configs are generated from them. - Owning address space is worthless if it is not used. Usage is reflected in route objects making them important beyond mere technical operation. Unfortunately, even though there was some discussion on this topic, no real consensus was found. The general idea is that for the time being there is no demand to implement a hierarchical scheme based upon IP prefixes. E. Route Flap Dampening (Christian Panigl) Christian Panigl had sent out the paper from the task force on route flap dampening the week before. It had been read by many people. To summarize, he gave an overview of the current dampening parameters and recommendations - never start dampening before the 4th flap in a row - /24 will then be dampened for 1 hour - /22 and /23 : max: 45 min and min: 30 min - all else: max:30min, min: 10min - exceptions: 'golden networks': root dns He then added some related recommendations with regard to configurations of Cisco routers - no ip bgp fast-external-fallover - clear ip bgp soft He had some feedback on this first version of the paper. He then asked on how to proceed, especially on the idea to present this as a RIPE document. Daniel Karrenberg offered his editorial help, after the feedback received was incorporated in the paper. As a RIPE document it will be an official RIPE recommendation, and as such may lead to further development, e.g. to place it as an informational RFC. F. PAIR: Policy Analysis of Internet Routing (Jake Khuon) http://www.rsng.net/presentations/ripe28/pair/ PAIR consists of a series of web based tools to help understand and diagnose problems with IRR policy and announcements seen at the RSng Route Servers. It is built upon route servers, and users may see routing problems as they appear at the route servers. Other tools exist which partly have the functionality of PAIR. However, PAIR is more and comprises various functions in one shell providing a simple and uniform interface. Some of the functions include - compare announced route AS origins to register route objects - compare route announcements to registered routes - suggest route aggregation Routes are classified according to a color scheme - green: registered in the IRR and announced - red: registered but not announced - grey: announced but not registered Work has been in progress for 5 months now. Much of proposed functionality is not yet implemented but will be done in the near future. PAIR will be continuously developed. For further reference see Homepage: http://www.rsng.net/pair/ RSCV: http://www.rsng.net/rs-views/ G. Reports from other WGs There was no current input from other WGs. H. AOB Since there was no AOB the meeting was closed. Agenda ------ R I P E 2 8 A M S T E R D A M Routing Working Group Session 24-Sep-97 Draft Agenda A. Preliminaries (Joachim Schmitz) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 27 minutes - actions from earlier meetings B. Current Developments (Joachim Schmitz) - ietf - rpsl - rpsl transition session C. Report from the RIPE NCC (Daniel Karrenberg) D. Authorisation/Notification with Route Objects - implementations in database software (Carol Orange) - aut-num authorisation revisited (Joachim Schmitz) - hierarchical authorisation of route objects revisited (Joachim Schmitz) - discussion E. Route Flap Dampening Parameters (Christian Panigl) - report from the task force - the route flap dampening paper F. PAIR - Overview and Introduction (Jake Khuon) Y. General Input from Other WGs Z. AOB Summary of Actions ------------------ Action 26.R3: J. Schmitz To finalize the hierarchical authorization for route objects together with the Routing WG Action 27.R1: Carol Orange, RIPE NCC To implement cross notification in the RR with modifications as agreed at the meeting of the 27th RIPE Routing WG. Action 27.R2: Carol Orange, RIPE NCC To implement aut-num authorisation in the RR Action 27.R4: Task Force (Tony Barber, Sean Doran, Daniel Karrenberg and Christian Panigl). To write up the results on route flap dampening in a RIPE document Action 28.R1: Carol Orange, RIPE NCC Contact other RR on the topic of distributed authorization Julia Edwards, Joachim Schmitz, 01/18/98 ----

1 0

The Cidr Report
by Tony Bates 16 Jan '98

16 Jan '98

This is an auto-generated mail on Fri Jan 16 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 16Jan98 0) General Status Table History ------------- Date Prefixes 090198 47514 100198 47408 110198 47661 120198 47816 130198 47654 140198 47809 150198 47905 160198 48136 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 98.6.10.0/24 from AS701 AS Summary ---------- Number of ASes in routing system: 3118 Number of ASes announcing only one prefix: 1448 (743 cidr, 705 classful) Largest number of cidr routes: 458 announced by AS3561 Largest number of classful routes: 991 announced by AS701 1) Gains by aggregating at the origin AS level --- 16Jan98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 696 390 306 44.0% iSTAR Internet, Inc. AS4293 417 205 212 50.8% IMCI AS174 880 675 205 23.3% Performance Systems International AS816 577 406 171 29.6% UUNET Canada (ASN-UUNETCA-AS4) AS3602 450 300 150 33.3% Sprint Canada Inc. AS3749 201 60 141 70.1% TECNET AS701 991 888 103 10.4% Alternet AS3751 122 46 76 62.3% SNET-AS AS721 352 278 74 21.0% DLA-ASNBLOCK-AS AS2048 162 90 72 44.4% LaNet AS5668 103 36 67 65.0% Century Telephone Inc. AS3804 203 141 62 30.5% Bell Solutions AS1 852 791 61 7.2% BBNPLANET AS549 217 162 55 25.3% ONet Backbone AS3464 120 65 55 45.8% Alabama Research and Education Ne AS271 111 56 55 49.5% BCnet Backbone AS7545 115 63 52 45.2% TPG Internet Pty Ltd AS1239 578 526 52 9.0% SprintLink Backbone AS72 84 36 48 57.1% Schlumberger Information Network AS4763 127 79 48 37.8% Telstra New Zealand AS719 502 457 45 9.0% LANLINK autonomous system AS1221 261 216 45 17.2% AARNET-AS AS4648 194 150 44 22.7% NZIX 2 AS684 84 42 42 50.0% Manitoba Regional Network Backbon AS3561 927 885 42 4.5% MCI AS3493 194 154 40 20.6% INTERLINK AS4740 331 292 39 11.8% ASN-OZEMAIL (Ozemail Pty Ltd) AS2711 93 54 39 41.9% SUNBELT-AS AS1691 161 123 38 23.6% BCTEL AS6332 81 44 37 45.7% 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

Your Search Engine Listing
by list＠LISTME.COM 15 Jan '98

15 Jan '98

To: routing-wg(a)ripe.net Is your site listed with the top search engines? ListMe will list you with 50 search engines and indexes for $90. Satisfaction guaranteed! Search engines are the only way most people have to find internet sites. But if your site is not listed, no one will find it. ListMe will submit your site for listing in the top 50 search engines for $90. Here's how it works: 1. Complete and return the form below. 2. We'll post your site to 50 search engines within two business days, and we'll send you a submission report when we're finished. 3. Pay nothing now. We'll send you an invoice after we've completed the posting. Your satisfaction is guaranteed! These are permanent listings. The $90 is a one-time fee. WHICH SEARCH ENGINES? Here's the list: Infoseek, Lycos, Excite, Alta Vista, Galaxy, HotBot, Magellan, Open Text Web Index, Web Crawler, BizWeb, New Riders WWW Yellow Pages, YelloWWWeb, True North, Northern Light, LinkMonster, The Weekly Bookmark, Seven Wonders, Jayde Online Directory, Starting Point, Web 100, Web Walker, New Page List, PeekABoo, One World Plaza, PageHost A-Z, Net-Announce, Project Cool, Where2Go, World Wide Business Yellow Pages, Sserv, Wow! Web Wonders!, WWW Worm, JumpCity, The Galactic Galaxy, TurnPike, Unlock:The Information Exchange, Your WebScout, Manufacturers Information Network, Net Happenings, Net Mall, Web World Internet Directory, InfoSpace, BC Internet, BizCardz Business Directory, Scrub The Web, WebVenture, Hotlist, What's New, WhatUSeek, JumpLink, Linkcentre Directory. ORDER FORM Hit the REPLY button on your e-mail program and fill out the following information. (This information will be posted to the search engines/indexes): Contact name: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: Contact e-mail address (in case we have questions about this order): URL: http:// Site Title: Description (250 characters): Key words (250 characters, in descending order of importance): If billing a different address, please complete the following: Addressee: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: TERMS Terms are net 15 days from date of invoice. ______________________________________________________________________ ListMe, Inc. 1127 High Ridge Road - Suite 184 Stamford CT 06905 Phone: (203) 326-8519 Fax: (203) 322-4505 E-mail: list(a)listme.com

1 0