- routing-wg - mailman.ripe.net

(no subject)
by ipopov 05 Jan '98

05 Jan '98

Dear sirs, chiefs of the enterprises! Our company "Talan" offers cooperation and services on conditions very favourable to you. The company "Talan" is engaged in the real estate (purshase, sale and rent of apartments, houses, offices, factories, shops etc.) in St.-Petersburg, Leningrad area, other regions of Russia. The firm "Talan" is large, stable and reliable real estate company of St.-Petersburg with the ramified network of branches, has high reputation at the clients, gives attention qualitative complex to service. The especial attention is given to marketing of the market of the real estate and effective advertising. The company has an opportunity decrement of legislative and tax policy, has experience of work in the international market of the real estate. The company "Talan" is situated at historical centre of St.-Petersburg, - first on beauty and in the second-largest city of Russia. Incorporated by Peter The Greate as "window in Europe", St.-Petersburg remains large cultural, scientific and technical, port and industrial, trade and business centre of Russia with the population more than 5 mln persons. Annually St.-Petersburg is visited by millions tourists and visitors from the whole world. We agree to carry sufficient expenses for search in our country of the buyer of your real estate. In case of fulfilment of the joint bargain the unit of the commission is made in a proportion 50/50%. In other cases the size of agency fee is stipulated in the contract. For operative communication and transfer of the information about the characteristics of objects, offered you, it is convenient to use channels of a network INTERNET. Vizit our site www.real.spb.ru/index_en.htm and answer us if you are interested in business in Russia. Yours faithfully General Director Kuzmin Serge Nik.

1 0

The Cidr Report
by Tony Bates 02 Jan '98

02 Jan '98

This is an auto-generated mail on Fri Jan 2 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 02Jan98 0) General Status Table History ------------- Date Prefixes 261297 47433 271297 47424 281297 47380 291297 47497 301297 47601 311297 47560 010198 47266 020198 47531 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 3075 Number of ASes announcing only one prefix: 1452 (758 cidr, 694 classful) Largest number of cidr routes: 521 announced by AS3561 Largest number of classful routes: 973 announced by AS701 1) Gains by aggregating at the origin AS level --- 02Jan98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 698 391 307 44.0% iSTAR Internet, Inc. AS4293 417 199 218 52.3% IMCI AS174 882 675 207 23.5% Performance Systems International AS816 571 399 172 30.1% UUNET Canada (ASN-UUNETCA-AS4) AS3602 457 300 157 34.4% Sprint Canada Inc. AS3749 190 54 136 71.6% TECNET AS701 973 878 95 9.8% Alternet AS839 123 31 92 74.8% North West Territories Regional N AS3751 119 46 73 61.3% SNET-AS AS5668 102 37 65 63.7% Century Telephone Inc. AS2048 153 88 65 42.5% LaNet AS3804 202 140 62 30.7% Bell Solutions AS1 869 808 61 7.0% BBNPLANET AS549 218 161 57 26.1% ONet Backbone AS271 111 56 55 49.5% BCnet Backbone AS7545 115 63 52 45.2% TPG Internet Pty Ltd AS3464 119 67 52 43.7% Alabama Research and Education Ne AS1239 580 528 52 9.0% SprintLink Backbone AS4763 126 75 51 40.5% Telstra New Zealand AS4747 114 64 50 43.9% Taiwan Telecommunication Network AS4648 190 140 50 26.3% NZIX 2 AS72 84 36 48 57.1% Schlumberger Information Network AS719 505 460 45 8.9% LANLINK autonomous system AS3561 936 894 42 4.5% MCI AS1221 256 215 41 16.0% AARNET-AS AS684 82 43 39 47.6% Manitoba Regional Network Backbon AS6181 60 21 39 65.0% FUSE-NET AS4740 330 291 39 11.8% ASN-OZEMAIL (Ozemail Pty Ltd) AS2711 96 57 39 40.6% SUNBELT-AS AS1691 164 125 39 23.8% 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 0

The Cidr Report
by Tony Bates 26 Dec '97

26 Dec '97

This is an auto-generated mail on Fri Dec 26 12:00:00 PST 1997 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 26Dec97 0) General Status Table History ------------- Date Prefixes 191297 46949 201297 46969 211297 46910 221297 46996 231297 47516 241297 47566 251297 47463 261297 47433 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 1662 Number of ASes announcing only one prefix: 778 (143 cidr, 635 classful) Largest number of cidr routes: 121 announced by AS3561 Largest number of classful routes: 583 announced by AS1 1) Gains by aggregating at the origin AS level --- 26Dec97 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS4293 201 102 99 49.3% IMCI AS72 84 36 48 57.1% Schlumberger Information Network AS719 505 460 45 8.9% LANLINK autonomous system AS174 298 258 40 13.4% Performance Systems International AS271 80 46 34 42.5% BCnet Backbone AS1 583 551 32 5.5% BBNPLANET AS1257 296 265 31 10.5% SWIPnet Swedish IP Network AS701 473 443 30 6.3% Alternet AS2493 97 73 24 24.7% iSTAR Internet, Inc. AS5381 58 36 22 37.9% PowerTech Information Systems AS AS8517 75 55 20 26.7% ULAKNET-ASN AS6822 37 19 18 48.6% SuperOnline autonomous system AS6663 35 17 18 51.4% InterComp Bucharest AS3663 25 7 18 72.0% NETNET-NET AS3563 59 41 18 30.5% Pilot Network Services, Inc. AS2048 45 28 17 37.8% LaNet AS2561 36 20 16 44.4% Egyptian Networks AS6897 32 17 15 46.9% Global-One Spain AS3564 29 15 14 48.3% Microserve Infromation Systems In AS2907 110 96 14 12.7% SINET AS1239 268 254 14 5.2% SprintLink Backbone AS6846 30 17 13 43.3% UKRPACK.NET AS1785 162 149 13 8.0% NYSERNet Backbone AS5666 35 23 12 34.3% Omnes - A Schlumberger and Cable AS4000 74 62 12 16.2% Global IP AS2752 38 26 12 31.6% THOMSONCA-AS AS549 93 82 11 11.8% ONet Backbone AS3577 30 19 11 36.7% PREPnet-WEST AS2686 46 35 11 23.9% Autonomous System number for IBM AS816 54 44 10 18.5% UUNET Canada (ASN-UUNETCA-AS4) 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

how to distinguish european routes from others
by Mart Norman 22 Dec '97

22 Dec '97

Hi! I'm not sure is this the right list for this question but what is the easiest way to distinguish european routes from others? Is anywhere a list of European AS-s? The reason I need this is that in nearest future we will have SAT channel to US and I would like to direct US traffic via SAT and European traffic via other channel. So I probably need to have as much as possible European routes in my box and point default to US. The problem is which nets are European and which are not. Thanks in advance, Mart =========================================================================== Mart Norman Technical Manager Esdata Ltd. Tel. +372 6 300 042 Akadeemia tee 21 GSM: +372 5 079 595 EE0026 Tallinn Fax +372 6 300 020 ESTONIA E-mail: mart(a)estnet.ee

2 1

(no subject)
by Thomas Groß 25 Nov '97

25 Nov '97

help

1 0

RIPE-168, Installing and hosting a test-box
by Henk Uijterwaal (RIPE-NCC) 17 Nov '97

17 Nov '97

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-168 Title: Internet delay measurements using test-traffic Installing and hosting a test-box Author: Henk Uijterwaal Date: 17 November 1997 Format: PS=2820818, TXT=13840 Obsoletes: Obsoleted by: Updates: Updated by: See also: Short content description ------------------------- In RIPE-158, we presented a proposal to do Internet performance measurements using test traffic generated by test-boxes. This document is intended for ISP's interested in hosting a test-box. It describes the requirements for hosting a test-box at an ISP. It also describes the installation and day-to-day management of such a test-box. After reading this document, one should be able to judge if one can successfully host a test-box at a site. This document is not a formal request asking which sites are interested in hosting a test-box. Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-168.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-168.txt plain text version You can also access the RIPE documents in HTML format via WWW, at the following URL: http://www.ripe.net/test-traffic/ Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to <mail-server(a)ripe.net> with "send HELP" in the body text. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(a)ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.6651962 The Netherlands Pager: +6.57626855 ------------------------------------------------------------------------------ %DCL-E-NOCFFE, unable to locate coffee - keyboard input suspended.

1 0

Is Your Web Site A Secret?
by owl＠secretwebsite.com 06 Nov '97

06 Nov '97

Is your web site the best kept secret on the Internet? We'll promote it to 50 search engines and indexes for $85 and complete the job in 2 business days. Satisfaction is guaranteed! If you have a great product, but are not getting many inquiries from your Web site, you may not be adequately listed on the Web's search engines and indexes. Millions of viewers daily use these facilities to find the products and services they are looking for. But if your site is not listed, no one will see it. Listings on most of these services are free. However, locating and filling out the forms required to get a listing can take several days, and most people just don't have the time to do it. That is why we offer a web site promotion service. WHAT'S THE DEAL? We will submit your site to 50 indexes and search engines for $85. We will accept the return of this E-mail, with the form below filled out, as an order. We will bill you upon completion of the promotion. Our terms are net 15 days from date of invoice. Satisfaction guaranteed! HOW LONG WILL IT TAKE? Generally, we complete the submissions within 48 hours of receiving your order. It can take any individual search engine or index up to three weeks to process your submission, although most are much faster. WHAT SEARCH ENGINES AND INDEXES ARE INCLUDED IN THE PROMOTION? The list changes from time to time. This is our current list: Alta Vista, BC Internet, BizCardz Business Directory, BizWeb, Excite, Galaxy, HotBot, Infoseek, InfoSpace, Jayde Online Directory, JumpCity JumpLink, Linkcentre Directory, LinkMonster, Lycos, Magellan, Manufacturers Information Network, Net Happenings, Net Mall, Net-Announce, New Page List, New Riders WWW Yellow Pages, Northern Light, One World Plaza, Open Text Web Index, PageHost A-Z, PeekABoo, Project Cool, Scrub The Web, Seven Wonders, Sserv, Starting Point, The Galactic Galaxy, The Weekly Bookmark, True North,TurnPike, Unlock:The Information Exchange, Web 100, Web Crawler, Web Walker, Web World Internet Directory, WebVenture Hotlist, What's New, WhatUSeek, Where2Go, World Wide Business Yellow Pages, Wow! Web Wonders!, WWW Worm, YelloWWWeb, Your WebScout HOW WILL I KNOW THAT YOU HAVE PROMOTED MY SITE? When we have completed the promotion, we will send you an HTML file as an attachment to your E-mail bill. Save this file to your disk, and view it through your Web browser. It provides links to the search engine we submitted your site to, plus any comments we received from them when we did it. ARE THERE ANY GUARANTEES? We do not require prepayment. Your satisfaction is guaranteed or you don't pay the bill. WHO IS OWL'S EYE PRODUCTIONS? We are a web site promotion company located at: Owl's Eye Productions, Inc. 260 E. Main Street Brewster, NY 10509 Phone: (914) 278-4933 Fax: (914) 278-4507 Email: owl(a)secretwebsite.com HOW DO I ORDER? The easiest way to order is by e-mail. Just 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): Your name: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: URL: http:// Site Title: Description (about 25 words): Key words (maximum of 25, in descending order of importance): Proofs (Where shall we e-mail proofs): If billing a different address, please complete the following: Addressee: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: We will bill via Email. (SE7O22) Terms: By returning this document via Email, you agree as follows: You have the authority to purchase this service on behalf of your company. Terms are net 15 days. Accounts sent to collections will be liable for collection costs. You agree to protect and indemnify Owl's Eye Productions, Inc. in any claim for libel, copyright violations, plagiarism, or privacy and other suits or claims based on the content or subject matter of your site. WHAT HAPPENS NEXT? When we receive your order, we will input the information into our system, and send you a proof. After we process any corrections, we will run your promotion, capturing any comments from search engines as we go. We will incorporate these into an HTML-formatted report to you, which we will attach to your bill. ===Web Promotions=====Press Releases=====Link Exchanges========= Owl's Eye Productions, Inc. 260 E. Main Street Brewster, NY 10509 Ph: 914-278-4933 Fx: 914-278-4507 E-mail: owlseye(a)secretwebsite.com

1 0

Draft of Route-Flap Dampening Paper
by Christian Panigl, ACOnet/UniVie 25 Sep '97

25 Sep '97

Dear members of the Routing-WG, here is the final draft version of the "Route Flap Dampening" paper as it came out of our task-force. Please, if possible, have a look at it before the WG meeting on Wednesday morning and bring your comments to the meeting and/or post them to the list. See you Christian --- ---------------------------------------------------------------------- --- --- 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) --- --- ---------------------------------------------------------------------- --- =============================================================================== RIPE Routing-WG Recommendation for coordinated route-flap dampening paramters Tony Barber Sean Doran Daniel Karrenberg Christian Panigl Joachim Schmitz Document status: DRAFT 1.2 22-SEP-1997 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 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. Open problems 3.1 Multiplication of flaps through multiply interconnected ASes 3.2 Is dampening of customer route-flaps a good idea ? 4. References 1. Introduction 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 About 1993/94 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. 1.2 What is route-flap dampening ? 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. 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 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 whenever the prefix is visible 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 much more stable. 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 for higher than required IP address-range allocations. 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 therefor "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 temporary routing-loops 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 "aggressiveness": 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. 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 than current Cisco default dampening does. 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 - /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. ! 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 ! ! Heavy dampening of all networks which have a mask of ! /24 and above. These are supressed into a datastructure ! with a half life of 30 minutes, only re-use when reaches 750 ! Max outage of 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 ! ! dampen /23 /22 ! half life is now 15 minutes and reuse at 1000 ! 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 ! ! default dampening on all less than /22 defaults to this ! different to CISCO defaults which are 15 750 2000 30 ! bgp dampening command ! 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 is that the switchover to an alternative path will take longer. It is recommendet to turn off fast-external-fallover: ! 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 Cisco IOS. For beeing able to make use of the "clear ip bgp x.x.x.x soft" command both sides must support it and need to be configured to accept it from the neighbor: ! 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 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" only those prefixes will be withdrawn which are no longer available with the new update and only those prefixes will be re-advertised which haven't been known before (no route-flap). 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 Is dampening of customer route-flaps a good idea ? As already explained in section 1.3 flap-dampening is at its best value and most consistent and helpful if applied as near to the source of the problem as possible. Therefore flap-dampening should not only be applied at peering boundaries but even more at customer boundaries ! 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, ANS: Controlling BGP/IDRP Routing Overhead http://figaro.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

4 5

rpsl transition session
by SchmitzJo＠aol.com 22 Sep '97

22 Sep '97

Dear all, one topic which has been lurking in the back for quite some time for the IRR is a more elaborate description of routing policies than offered by RIPE-181. In the past months it has more and more emerged, become mature, and is now on the standards track of IETF: RPSL, the routing policy structured language. For future development of the Internet world it needs to be incorporated into the registries. Some preliminary work has already been done to include RPSL into the RIPE database software. But we are still in the beginning. We want to show you which work was done up to now, which work is currently done, and which work there is still to be done in the future. We also want your input to allow a smooth transition from the current version of the database to its future implementation. RPSL is a topic which is important both for routing issues, and for database evolution. Therefore, the chairmen of database wg and routing wg, Wilfried Woeber and Joachim Schmitz, decided to have a joint session of both working groups in addition to their individual wg sessions, on this special topic, the RPSL transition. The individual wg sessions (routing and db) are held on Wednesday. The RPSL transition session is prepared with the help of the RIPE NCC and RPSL developers. It will be held on Thursday at 9:00am (see meeting schedule). Its major goal is *not* to teach RPSL but to give an overview of the current situation and planned developments. Please find enclosed the draft agenda for this session. Regards Wilfried Woeber and Joachim Schmitz Draft Agenda RPSL Transition Session 1. Preliminaries (Joachim Schmitz, Wilfried Woeber) - participants' list - volunteering of scribe - questions to the audience, part one - introduction 2. Short Introduction to RPSL (Daniel Karrenberg) 3. RPSL Planned Development (David Kessens) - RaToolSet - Status of the DB code - conversion tools 4. Changes in RIPE Database Software Behaviour (David Kessens) 5. Outline of a Transition Plan for RIPE (Carol Orange) 6. AOB - questions to the audience, part two - Tutorial at next RIPE meeting ---

1 0

2nd draft agenda routing wg session
by SchmitzJo＠aol.com 22 Sep '97

22 Sep '97

Dear colleagues, there is a new topic on the agenda and I did not want to keep it from you ;-) Regards Joachim 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) - 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

1 0