- routing-wg - mailman.ripe.net

Re-homing of RAToolSet to RIPE NCC
by Andrei Robachevsky 04 Oct '01

04 Oct '01

Dear Colleagues, [sorry for duplicate messages] Following Cengiz Alaettinoglu's message on this subject on the ratoolset(a)isi.edu mailing list (please find the original message attached below) it is our pleasure to announce that RAToolSet project has moved from ISI to the RIPE NCC. Starting from now the RIPE NCC will take on support and development of these tools. As a part of this move, RAToolSet will be called IRRToolSet. A new web page http://www.ripe.net/ripencc/pub-services/db/irrtoolset/index.html and a mailing list irrtoolset(a)ripe.net have been established. We have subscribed all of the members of ratoolset(a)isi.edu to this mailing list. The original list will be phased out, but will forward any email to the new address. If you would like to subscribe to the IRRToolSet mailing list, put the line "subscribe irrtoolset" in the body of the message to add your address to the list, and send it to majordomo(a)ripe.net. We rely on your feedback and hope to provide the level of support you received from Cengiz and the ISI team. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC

6 9

nearly too late: minutes of Routing WG RIPE 39(!)
by SchmitzJo＠aol.com 02 Oct '01

02 Oct '01

Dear colleagues, please find below the minutes of our last session during the previous RIPE meeting. Delay in delivering is solely up to myself - I had receive more than enough input from the two scribes Bill Woodcock and Shane Kerr already shortly after the meeting - thanks a lot again to both! Thanks Joachim ----- R I P E 3 9 B O L O G N A Routing Working Group Session 2-May-2001 Draft Minutes Chair: Joachim Schmitz (JS395-RIPE) Scribe: Bill Woodcock, Shane Kerr -- thank you!!! Participants: 111 Prior to the Routing WG two tutorials were given which have a relationship to Routing Monday, 30-Apr, 9:00: Clarence Filsfils, John Evans (Cisco) Full day tutorial on MPLS Tuesday, 1-May, 9:00: Cengiz Allaettinoglu (Packetdesign) Half day tutorial on the RAToolSet The Routing WG session itself was held on Wednesday, 2-May, 14:00. A. Preliminaries (Joachim Schmitz) The chair man welcomed the participants, and distributed the participants' list to sign in. Bill Woodcock volunteered to take the minutes, Shane Kerr also provided them in parallel. Regarding the WG agenda Bernard Tuy asked about the status of the the IPv6 routing registry and whether some presentation would be given. Joachim explained that no action had been taken yet, because the first step is development of RPSLv6. However, this is part of the NCC activity plan. Joachim suggested to initiate a corresponding task force to assist the NCC in that work -> action 39.R1 on Joachim: initiate RPSLv6 task force Following that the WG agenda was accepted without changes. The minutes of the previous meeting at RIPE38 were accepted by the participants, and are thus declared final. Actions from earlier meetings 36.R1 on RIPE NCC RADB coordination for RPSL transition This has been done as part of the RPSL transition at RIPE *close* 37.R1 on C.Panigl, P.Smith, D.Karrenberg, J.Schmitz Updates to RIPE-210 *ongoing* 37.R2 on RIS team, Henk Uijterwall Route flap analysis from RIS data *ongoing* 38.R1 on J.Schmitz, W.Woeber Organize RaToolSet tutorial at RIPE 39 The tutorial has been held this meeting as part of the RPSL transition *close* 38.R2 on J.Schmitz, W.Woeber Collect final community input on database migration dates This had happened according to schedule and recognized for the transition *close* B. Cengiz Allaettinoglu: Observations on IGP Convergence http://www.packetdesign.com/Docs/draft-alaettinoglu-ISIS-convergence-00.ps Towards sub-second IGP convergence: Today, we are typically in the area of tens of seconds or up to several minutes which comes from the process of 1. detect (link up/down or peer reachability) 2. distribute info (flooding) with LSP packets (link state packets) 3. determine new path: shortest path first (SPF) computation Experiments were conducted to analyze this in more detail. Looking closer at the individual steps: 1. Detect Hello packets are sent at a fixed interval of 10secs, with a timeout of 30secs (default value) where the timeout gives a lower bound for cenvergence. In priniple, the hello interval can be reduced. Bandwidth consumption is not necessarily an issue today anymore, and analysis shows that up to 10% of traffic may consist of hello packets if they are treated preferred to data packets. Essentially, allowing sub-second intervals leads to sub-second detection. However, this is hard for "run-to-complete" router OSs which could be mended by employing real time OSs. Still, the hello interval is limited due to physical constraints (bandwidth, error spectrum, propagation delay). Moreover, there are stability issues, if routing follows rapid link transients which would call for some damping mechanism and treating "bad news" differently from "good news". 2. LSP propagation In theory, propagation should not matter (essentially at the speed of light, plus store&forward time per hop) but practice shows difference. In particular, the SPF computation is done before forwarding LSPs, and normally a delay of 5secs is usually set by default, adding to propagation delays. If set to zero, still the SPF computation is done before. 3. SPF calculation Each node must calculate the new SPF topology. For a given number of n nodes and a change in topology the time was measured which is required to calculate SPF. Depending on router vendor, the effort grows by n^2 or n*log(n). For larger network, even on high end routers, the calculation then lasts for seconds. However, new dynamic algorithms exist which scale like log(n) which for large networks improves performance easily 10k times. This is now newly implemented in vendor's codes. Topologies up to 90k edges were tested and no instability was found. There were a few questions on that presentation Q: What happens if an incremental update is lost A: LSPs are already split-horizon Q: What kind of topology had been simulated A: A flat one Q: What if nodes fail which drastically change the shape of the graph A: those have been included, and results are an average of all different kinds of failures Q: Has this been shown and discussed anywhere else A: Yes, at IETF working groups, where the only objection against rapid hello packets was on run-to-completion architectures Q: Topologies can be envisioned where this does not work A: In theory yes, but for practice these would be pathological cases C. Philip Smith: Revision to RIPE-210 (Route Flap Damping) - update Philip first dealt with the question why RIPE-210 should be revised. This is due to several drawbacks: . parameters for /24 damping are virtually unfeasible . "golden networks" are changing . remaining open issues are long solved . restructuring and updating is necessary and discussed these items Parameters for /24 damping specified would never lead to damping as shown by simple discussion of the values. Instead the correct values bgp dampening 30 820 3000 60 with a maximum possible penalty of 3280 leads to suppression of prefixes and the original design intentions are achieved. The "golden networks" according to definition should not be dampened, however the list given in RIPE-210 was outdated, and contrary to the original intention to only list root nameservers, consisted partly of those (incomplete) and some gTLD servers. In the revision "golden networks" are defined to be those which an operator does not want to dampen for whatever reason. It is suggested to move a template list into an appendix, also to reduce the effect that the list is just included unchanged in router configurations by cut&paste. The question is considered solved that updates from a router arrive at a peer at different times through different paths which could be understood as multiple flaps. This has been included in OS codes now. In addition, route refresh is now RFC2918, a proposed standard. Regarding restructuring the following items were changed . moved data to appendices . changed document from Cisco only to general doc (allowing other router vendor implementations), so far received exmaples for Juniper's JunOS Philip also asks for others like gated, Foundry, Redback, Extreme... . show what is not recommended . appendix of study of flap damping operation intended to help for port configs The new draft has been posted to several mailing lists at NANOG, APOPS, AfNOG, and received some input which will be included in a refined version. Joachim thanked Philip for his contribution to the document and the work he put into it. Daniel suggested that the golden networks are excluded from the document itself for the simple reason that they are likely to change more rapidly than the document itself. To have a reference, he suggests to put a reference in which points to a web page on the RIPE NCC web server. This was accepted by the audience. -> action 39.R2 on Daniel Karrenberg: Provide "Golden Network" web page D. Henk Uijterwaal: RIS - Status and Plans There are a few changes to the team, with two people leaving and two new ones joining. In addition, they are looking for a student intern for the 2001-2002 term. Expected total FTE for 2001 is 2.1 FTE with 0.3...0.7 student. Currently, route collectors exist at - RIPE-NCC - LINX and new ones to come up or in the process of being deployed - SFINX - AMS-IX - CIXP If you would want to provide feeds to the route collectors, write e-mail to ris-peerings(a)ripe.net Beyond that additional route collectors are suggested for - JP/Asian region - US - DE, SE in discussion However, before those are considered more closely, investigate what we can do with existing RRCs first, and determine added value of installing more RRCs. The data of all of these can be handled. Already we have results and displays which for the most part come from Thomas Franchetti's thesis: fully automated setup to produce daily updated plots of the RIS data. This is fully documented and currently generates 4 different plots; current plots are - BGP updates/minute - Prefix distribution - BGP distribution of types (announcements, withdrawals) - BGP unique announcements More plots and stats can be easily added, and will be added. Beyond these generic plots, those parties with a peering session can get a personalized view. Before putting this to true production, two more tasks must be done - security review of cgi-code - apply NCC layout Plans for the next months include - transitioning with new people - RIS reports will go online - move to regular service From the audience the question was posed about data volume. This is 14 MB per peer per day, and 4 GB raw data per month. Due to a scaling problem with the database, active data in the database is currently limited to 3 months worth of data. Older data is kept gzipped. [break] After the break, a joint session with the Database WG was held, to wrap up on the transition to the RPSL database. E. Andrei Robachevsky: New Version of the RIPE Database http://www.ripe.net/rpsl The database has migrated and is now running RPSL. There is no other production database anymore, in particular no test or RIPE-181 databases. About one week after the migration (happened on 23-April), already 56k objects have been processed. The query rate with an average of 8.7 queries/sec is the same, and so far 17M objects have been downloaded. Currently, there are 6 active mirrors (there had been 12 before). The new RIPE database software code had been completely rewritten to improve performance and managability. It now supports RPSL, extended syntax and objects (RFC2622), RPSS (RFC2725), and the RAToolSet (v.4.7.0, ftp:/ftp.isi.edu/ra/RAToolSet) There are plans to move development and maintenance of the RAToolSet over to the RIPE NCC. In addition, a new whois client has been developed (ftp://ftp.ripe.net/ripe/dbase/reimp/whoisRIP-1.0.tar.gz) Andrei then gave an overview of features of the new database software with regard to RPSL, in particular - modified objects: mntnr, route, aut-num, inetnum, as-set (was as-macro), route-set (was community), inet-rtr. Non-affected objects: person, role, domain, limerick. - new objects: as-block, rtr-set, peering-set, filter-set - new attributes: member-of, mbrs-by-ref, mnt-routes, referral-by, auth-override - new query flags: -l <ip-range>, -x <ip-range>, -K, -d, -q sources, -q version - new version of the mirroring protocol The team involved in development and transition of the new database software is Daniele Arena Marek Bukowy Joao Damas Engin Gunduz Roman Karpiuk Shane Kerr Ambrose Magee Chris Ottrey Filippo Portera Andrei Robachevsky reachable at dbrip(a)ripe.net. Many thanks go to this team and anybody who has helped to make it happen! This was very much supported by the audience! Prior to the transition (on the test database) and right after, a few issues had been discovered and resolved - PGP updates failed at <auto-rpsl(a)ripe.net> o solved 24 April o use ONLY RPSL path for PGP signed updates - Conversion problems of updates at <auto-dbm(a)ripe.net> o incorrect or misleading replies o solved 26 April o please use RPSL path <auto-rpsl(a)ripe.net> - Acknowledgement problems o sometimes were not sent or were misleading o solved 26 April - Acknowledgement problems(2) o authentication does not give proper responses - Some filaed updates were not processed o might have happened 23-27 April o please re-send them if you didn't receive a reply from DB and the objects are not updated - Indentation difference o will be solved ASAP - DB accepts mirror's requests with protocol #1 o "compatability" mode o deadline: [15.10 | until sorted out with RADB/iRRd] - Routing Policy System Security (RFC2725) o authorisation rules for route creation need mntner authorization for inetnum, (parent) route, aut-num, a route itself problem with MAIL-FROM, because can only have 1 mail-from! problem with CRYPT-PW because you have to share password o need to duplicate objects in the RIPE DB origin or address from non-RIPE space currently have inetnum with NONE auth for mnt-routes as-blocks for RIPE space with NONE auth for mnt-lower o possible better solution perform checks on mirrored sources - which sources contain authoritative data for an IP/ASN space? implement some of RFC2769 (rps-dist) features - integrity attribute? requires good coordination and understanding between RIR's, IRR's To finalize the transition, the mail addresses to send updates to will be changed over time as announced: - 1st (current) <auto-dbm(a)ripe.net> -> <auto-181(a)ripe.net> 23rd April - 2nd (next) <auto-dbm(a)ripe.net> -> <auto-rpsl(a)ripe.net> 14th May - 3rd no <auto-181(a)ripe.net> There was a set of questions on the transition and the presentation Q: the keyword "password" must be written all in lowercase in contrast to RPSL definition? A: this has been fixed Q: after migration import/export attributes often extended over several lines, while one liners with updates were correctly returned which caused problems with scripts processing data A: line continuation is a feature of RPSL and described in the standard; accordingly scripts must be capable of handling them; for the auto conversion during migration it was not the rule to break single lines into multiples, but could also not be excluded Q: when querying an encompassing AS block you get "?" as ARIN number, and ARIN1-RIPE with a wrong address A: this will be fixed Q: a provider asked that they have C&W as upstream which reads their AS-macros and was wondering whether C&W was ready to read AS-sets A: C&W participated explicitely in the transition process, and a representative of C&W confirmed that they have already made the conversion G. Rob Evans: Operational Experience with RtConfig <rhe(a)noc.ten-155.net> <rhe(a)nosc.ja.net> Rob introduced himself as working for the University of London Computer Centre, running JANET (UK education and research network) and TEN-155 (pan-European counterpart). While JANET applies fairly loose filtering, TEN-155 generates filters based on policies in IRR (RIPE). Therefore, all networks routing on TEN-155 must have a corresponding entry in the RIPE Database. They are using RtConfig, a program from the RAToolSet to generate parts of their router configurations, because people make mistakes. Using RtConfig limits their impact. Rob then showed several examples of common user mistakes like - redistributing IGP routes into BGP - unintentionally announcing full routing tables - ordering a filter wrongly - typing errors in filters and continued on how they are employing RtConfig - to generate filters - interprets policies - generates BGP configs - in formats for all our favorite routers accompanied by an example on how to generate filter lists. Gotchas To use RtConfig a few things should be considered - adds latency between a customer being allocated addresses and the route being accepted which can be reduced to a minium if updates are run regularly - filters can be very large (by route), which can be circumvented by just filter on AS path (which unfortunately does not protect against redistribution of IGP) - which db to query? for us in the European, RIPE will usually do Rob also thinks that they have room for improvements, because so far they do not use use many features of RPSL and RtConfig - peering sessions are still configured manually - many options that can be expressed in RPSL are still configured manually (eg route preferences) All of this can be done by a combination of RPSL database entries and RtConfig. F. Cengiz Allaettinoglu: Overview of the RAToolSet This was essentially a small recap from the RAToolSet tutorial from the beginning of the RIPE meeting covering RtConfig router configuration tool peval policy calculator/evaluator roe route object editor prtraceroute traceroute with policy no assumptions - only concerns YOUR part of IRRd CIDRAdvisor safe aggregations (for your routes) prpath paths to different location these two tools assumed that many people would register in IRR this assumption has not been true aoe aut-num editor (no longer available, not RPSL capable) Pointers to this are o http://www.isi.edu/ra/rps/training o http:/www.isis.edu/ra/RAToolSet Mailing lists o <rps(a)isi.edu> o <ratoolset(a)isi.edu> Cengiz Alaettinoglu <cengiz(a)packetdesign.com> Just prior to the RIPE40 meeting, it was announced that maintenance and development of the RAToolSet has moved to the RIPE NCC. As a part of this move, RAToolSet will be called IRRToolSet. A new web page http://www.ripe.net/ripencc/pub-services/db/irrtoolset/index.html and a mailing list irrtoolset(a)ripe.net have been established. Y. Input from other WGs Combining the 2nd slot with the Database WG covered the transition of the RIPE database to RPSL. In addition, reference was made to the IPv6 RR which needs to be taken up for further development. Z. AOB none Summary of Open Action Points from the Routing WG 37.R1 on C.Panigl, P.Smith, D.Karrenberg, J.Schmitz Provide updates to RIPE-210 - ongoing - 37.R2 on RIS team, Henk Uijterwaal Implement route flap analysis from RIS data - ongoing - 39.R1 on J.Schmitz, D.Kessens Initiate IPv6 IRR taskforce - new - 39.R2 on D.Karrenberg Provide "Golden Network" web page - new - Bill Woodcock, Shane Kerr, May 2001 Joachim Schmitz, September 2001 -----

1 0

draft agenda (v1) of Routing WG, RIPE 40, Prague
by SchmitzJo＠aol.com 01 Oct '01

01 Oct '01

Dear colleagues, please find enclosed the first draft of the agenda for the session of the routing working group at RIPE 40, Prague. The session will be held Wednesday, 3-Oct, 14:00 Routing WG session, just one slot I would also like to direct your attention to several other interesting presentations (for more information on those, please refer to the RIPE meeting web pages): Thursday, 4-Oct, 14:00 Plenary Abha Ahuja (Update on routing developments in the IETF/IRTF) Randy Bush (Measuring Routing Table Growth) Please note that unfortunately this time I will not be able to participate myself. Joao LS Damas of the RIPE NCC will take over for the Routing WG session at RIPE 40. I would want to thank him for replacing me this week. I myself will be back for RIPE 41. As usual comments, additions, changes to the agenda of the Routing WG welcome! ---- R I P E 4 0 P R A G U E Routing Working Group Session A. Preliminaries (Joao L.S. Damas) (5min) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 39 minutes - actions from earlier meetings B. Philip Smith: Route Flapping (20min) - route flap data analysis - update on RIPE-210 C. Philip Smith: BGP Multihoming (10min) D. Roger Gottsponer: How to secure your job: Implement MPLS VPNs (60min) Y. Input from other WGs Z. AOB ---- Thanks Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

Update to RIPE-210 - final draft
by Philip Smith 29 Sep '01

29 Sep '01

bcc: nanog, apops Hi, Please find attached the final draft of the document which will replace RIPE-210, the RIPE Routing WG recommendation for coordinated route flap damping parameters. The authors would welcome any further comments between now and the meeting of the Routing WG on Wednesday 3rd October at the RIPE Meeting in Prague. thanks! philip -- RIPE Routing-WG Recommendation for coordinated route-flap damping parameters Philip Smith Cristina Vistoli Christian Panigl Joachim Schmitz This document Obsoletes: ripe-210, ripe-178 ----------------------------------------------------------------- Document status Version 2.0, September 28th, 2001 Abstract This paper recommends a set of route-flap damping parameters which should be applied by all ISPs in the Internet and should be deployed as default values by BGP router vendors. Table of Contents 1. Introduction 1.1 Motivation for route-flap damping 1.2 What is route-flap damping ? 1.3 "Progressive" versus "flat&gentle" approach 1.4 Motivation for coordinated parameters 1.5 Aggregation versus damping 1.6 "Golden Networks" 2. Recommended damping parameters 2.1 Motivation for recommendation 2.2 Description of recommended damping parameters 3. Other Features contributing to Internet Stability 3.1 BGP Route Refresh 3.2 Soft Reconfiguration 3.3 Tuning External BGP Failover 4. Potential problems 4.1 Multiplication of flaps between ASes with multiple interconnections 4.2 Non-recommended flap damping parameters 5. References 6. Acknowledgements 7. Changes over Previous Versions 8. Authors Appendices A.1 "Golden Networks" Reference A.2 Sample Configurations Reference A.3 Study of Flap Damping Operation 1. Introduction Route-flap damping is a mechanism for (BGP) routers which is aimed at improving the overall stability of the Internet routing table and reducing the load on the CPUs of the core routers. 1.1 Motivation for route-flap damping In the early 1990s the accelerating growth in the number of prefixes being announced to the Internet (often due to inadequate prefix-aggregation), the denser meshing through multiple inter-provider paths, and increased instabilities started to cause significant impact on the performance and efficiency of the Internet backbone routers. Every time a routing prefix becomes unreachable because of a single line-flap, the withdrawal has to be advertised to the whole core Internet and dealt with by every single router which is carrying the full Internet routing table. To overcome this situation a route-flap damping mechanism was invented in 1993 and has been integrated into several router software implementations since 1995 (for example, Cisco, Merit/RSd, GateD Consortium). The implementation is described in detail in RFC2439. The flap damping mechanism is now widely used to help keep severe instabilities under control and more localised in the Internet. And there is a second benefit: it is raising the awareness of the existence of instabilities because severe route/line-flapping problems lead to permanent suppression of the unstable area by means of holding down the flapping prefixes. Route-flap damping has its greatest and most consistent value if it is applied as near to the source of the problem as possible. Therefore flap-damping should be applied both at peering and upstream boundaries, as well as at customer boundaries (see 1.4 and 1.5 for details). 1.2 What is route-flap damping ? When BGP route-flap damping is enabled in a router the router starts to collect statistics about the announcement and withdrawal of prefixes. Route-flap damping is governed by a set of parameters with vendor-supplied default values which may be modified by the router manager. The names, semantic and syntax of these parameters differ between the various implementations; however, the behaviour of the damping mechanism is basically the same. Each time a prefix is withdrawn, the router will increment the damping penalty by a fixed amount. When the number of withdrawals/announcements (=flap) is exceeded in a given time frame (cutoff threshold) the path is no longer used and not advertised to any BGP neighbour for a predetermined period starting from when the prefix stops flapping. Any more flaps happening after the prefix enters suppressed state will attract additional penalty. Once the prefix stops flapping, the penalty is decremented over time using a half-life parameter until the penalty is below a reuse threshold. Once below this reuse threshold the suppressed path is then re-used and re-advertised to BGP neighbours. Pointers to some more detailed and vendor specific documents are listed in "5. References". 1.3 "Progressive" versus "flat&gentle" approach One easy approach would be to just apply the current default-parameters which are treating all prefixes equally ("flat&gentle") everywhere. However, there is a major concern to penalise longer prefixes (=smaller aggregates) more than well aggregated short prefixes ("progressive"), because the number of short prefixes in the routing table is significantly lower and it seems in general that those are tending to be more stable and also are tending to affect more users. Another aspect is that progressive damping might increase the awareness of aggregation needs. However, it has to be accompanied by a careful design which doesn't force a rush to request and assign more address space than needed. A significant number of important services is sitting in long prefixes (e.g. root name servers), so the progressive approach has to exclude the strong penalisation for these so-called "golden" prefixes. With this recommendation we are trying to make a compromise and it is therefore called "graded damping". 1.4 Motivation for coordinated parameters There is a strong need for the coordinated use of damping parameters for several reasons: Coordination of "progressiveness": If penalties are not coordinated throughout the Internet, route-flap damping could lead to additional flapping or inconsistent routing because longer prefixes might already be re-announced through some parts of the Internet where shorter prefixes are still held down through other paths. Coordination of hold-down and reuse-threshold parameters between ISPs: If an upstream or peering provider would be damping more aggressively (e.g. triggered by less flaps or applying longer hold-down timers) than an access-provider towards his customers it will lead to a very inconsistent situation, where a flapping network might still be able to reach "near-line" parts of the Internet. Debugging of such instabilities is then much harder because the effect for the customer leads to the assumption that there is a problem "somewhere" in the "upstream" Internet instead of making him just call his ISPs hot-line and complain that he can't get out any longer. Further, after successful repair of the problem the access-provider can easily clear the flap-damping for his customer on his local router instead of needing to contact upstream NOCs all over the Internet to get the damping cleared. Vendor Defaults: As with most software implementations, there need to be some default values set when route-flap damping is enabled on routers. Vendors choosing different default values will result in a similar situation to that described above, where the more aggressive values will result in "black spots" in the Internet. Coordinated values will ensure consistency in dealing with instabilities. 1.5 Aggregation versus damping If a customer of an ISP is only using Provider Aggregated addresses, the aggregating upstream provider doesn't need to apply damping on these prefixes towards his customer, because instabilities of such prefixes will not propagate into the Internet. However, if a customer insists on announcing prefixes which can't be aggregated by its provider, damping should be applied. Reasons for leaking prefixes might include dual-homing (to different providers) of a customer, or customer's reluctance to renumber into the provider's aggregated address range. 1.6 "Golden Networks" Even though damping is strongly recommended, in some cases it may make sense to exclude certain networks or even individual hosts from damping. This is especially true if damping would cut off the access to vital infrastructure elements of the Internet. A most prominent example are the root name servers. At least in principle, there should be enough redundancy for root name servers. However we are still facing a situation where, at least outside USA, large parts of the Internet are seeing all of them through the same one or two backbone/upstream links (undersea cable) and any instability of those links which is triggering damping would unnecessarily prolong the inaccessibility of the root name servers for an hour (at least those sitting in a /24 or longer prefix). Other examples of inclusions in the "Golden Networks" might be the Global Top Level Domain (gTLD) name servers, and possibly overseas or "special" networks the local ISP wishes to have continued connectivity to regardless of the instability of the infrastructure inbetween. Appendix A.1 references a website which the authors believe represent an example of suitable Golden Networks. While the authors will endeavour to keep the website current, network managers are strongly encouraged to check that the networks listed are indeed still being announced and the hosts therein are still being used before implementation of route flap damping using the quoted Golden Networks. This can be done by matching BGP table announcements with the published addresses for the listed servers. These exceptions must only be made if there are strong and identifiable needs for them - the rule should be to apply coordinated route flap damping throughout. 2. Recommended damping parameters 2.1 Motivation for recommendation At RIPE26 and 27 Christian Panigl presented the following network backbone maintenance example from his own experience, which was triggering flap damping in some upstream and peering ISPs routers for all his and his customers /24 prefixes for more than 3 hours because of too "aggressive" parameters: scheduled SW upgrade of backbone router failed: - reload after SW upgrade 1 flap - new SW crashed 1 flap - reload with old SW 1 flap ------ 3 flaps within 10 minutes which resulted in the following damping scenario at some boundaries with progressive route-flap damping enabled: Prefix length: /24 /19 /16 suppress time: ~3h 45-60' <30' Therefore, in the Routing-WG session at RIPE27, it was agreed that suppression should not start until the 4th flap in a row and that the maximum suppression should in no case last longer than 1 hour from the last flap. It was agreed that a recommendation from RIPE would be desirable. Given that the current allocation policies are expected to hold for the foreseeable future, it was suggested that all /19's or shorter prefixes are not penalised harder (longer) than current Cisco default damping does. More recently, this recommendation has been altered so that only prefixes longer than a /21 are now damped more aggresively. The registries' minimum allocation is currently a /20, and a /21 announcement is quite feasible for a multihoming situation. With these suggestions in mind, Tony Barber (UUNET) designed the following set of route-flap damping parameters which have proved to work smoothly in his environment for a couple of months prior to the publication of RIPE-178 (the original version of this document). 2.2 Description of recommended damping parameters Basically the recommended values do the following with harsher treatment for /24 and longer prefixes: * don't start damping until the 4th flap * /24 and longer prefixes: max=min outage 60 minutes * /22 and /23 prefixes: max outage 45 minutes; min outage of 30 minutes * all other prefix lengths: max outage 30 minutes; min outage 10 minutes If a specific damping implementation does not allow configuration of prefix-dependent parameters the least aggressive set should be used: * don't start damping before the 4th flap in a row * max outage 30 minutes; min outage 10 minutes Sample configurations for different vendors are referenced in Appendix A.2. These samples can be used as a basis for a configuration on other router platforms not listed there. 3. Other Features contributing to Internet Stability 3.1 BGP Route refresh RFC2918 describes a Route Refresh Capability for BGP-4. Prior to this, there was no mechanism to reset or refresh a BGP peering session without tearing it down and waiting for it to re-establish. This process is destructive - prefixes being exchanged between the two peering routers are withdrawn from their respective ASes, and this withdrawal can potentially pass through the whole Internet causing the burden and increased instability discussed earlier. Usually all that an ISP wishes when reseting a BGP session is to implement new or revised policy - destroying a BGP session carrying a large or the full routing table has severe impact on the ISP and his neighbours on the Internet. Furthermore, reset of a BGP session means the withdrawal of reachability information from the ISP's customers, and they have the perception that the Internet has "vanished" - the impression left with the end-user is that of an unreliable network. Route Refresh implements a messaging system whereby a router wishing to refresh or reset its BGP peering with its neighbour simply has to send the notification. When the neighbour receives the notification, it will send its entire announcement to its peer (obtained from BGP best path table and applicable outbound policy). To find out if your neighbour supports Route Refresh, using Cisco IOS as an example, enter: Router# sho ip bgp neigh w.x.y.c | include refresh Received route refresh capability(new) from peer Route refresh request: received 0, sent 0 If your router and your peer router support Route Refresh, you can use: Router# clear ip bgp w.x.y.c in for requesting a route refresh without clearing the BGP session. For an outbound route refresh without clearing the BGP session use Router# clear ip bgp w.x.y.c out It is recommended that all users of BGP use the route refresh capability when implementing new BGP policy. 3.2 Soft-Reconfiguration Where the neighbour does not support RFC 2918 Route Refresh, router vendors have implemented functionality to all the alternatiom of BGP policy without resetting the BGP session. In Cisco IOS this functionality is called "Soft Reconfiguration". This reserves additional memory in the router to store the BGP table exactly as it was received from the peer, prior to any inbound policy being applied. The advantage of this is that the ISP can then change any inbound policy on the router without reseting the BGP session - the router simply uses the "raw" BGP table it has received from its peer. Disadvantage is that this functionality could potentially consume almost twice the amount of memory required for the BGP table heard from the peer. To configure soft-reconfiguration in IOS, simply add the extra line to the BGP peer configuration as below. Soft-reconfiguration is configured on a per-neighbour basis. ! router bgp 65501 neighbor 10.0.0.2 remote-as 65502 neighbor 10.0.0.2 soft-reconfiguration inbound ! Without the keyword "soft" a "clear ip bgp x.x.x.x" will completely reset the BGP session and therefore always withdraw all announced prefixes from/to neighbour x.x.x.x and re-advertise them (= route-flap for all prefixes which are available before and after the clear). With "clear ip bgp x.x.x.x soft out" the router doesn't reset the BGP session itself but sends an update for all its advertised prefixes. With "clear ip bgp x.x.x.x soft in" the router just compares the already received routes (stored in the "received" data structures) from the neighbour against locally configured inbound policy statements. In Juniper's JunOS software, all the prefixes advertised by a peer are stored on the router, allowing the router to re-evaluate new policies on the set of routes advertised by the peer. So in the event of a peer not supporting the route-refresh capability, JunOS default configuration will compensate for this in the same way the optional "soft-reconfiguration" support in IOS. It is recommended to use soft-reconfiguration with all peers which do not support RFC2918 Route Refresh Capability to avoid tearing down and restarting BGP peerings when new BGP policies need to be implemented. 3.3 Tuning External BGP Failover Cisco IOS by default implements a feature known as "fast-external-fallover". This feature immediately clears the BGP session whenever the line-protocol to the external neighbour goes down. This feature is desirable so that there is fast failover in case of link failures - the router can withdraw paths as soon as the line goes down, rather than waiting for BGP keepalive timers. The drawback of this, however, is that circuits which are prone to unreliability will cause BGP sessions to drop and return (i.e. flap), resulting in instability within the ISP's network, and the potential for flap damping by upstreams or peers. If fast-external-fallover is turned off, the BGP sessions will survive these short line-flaps as it will use the longer BGP keepalive/hold timers (default 60/180 seconds). The drawback of turning it off - and currently it has to be done for a whole router and can not be selected peer-by-peer - is that the switch-over to an alternative path will take longer. We recommend turning off fast-external-fallover whenever possible: ! router bgp 65501 no bgp fast-external-fallover ! Alternatively it might be considered acceptable to retain "fast-external-fallover" and to turn off "interface keepalives" on unreliable circuits to overcome the immediate BGP resets on any significant CRC error period. Another potentially more satisfactory alternative would be to use a shorter per-neighbour BGP keepalive timer which has to be applied on both routers (e.g. 10 seconds which gives a hold-timer of 30 seconds): ! router bgp 65501 neighbor w.x.y.z timers 10 ! In JunOS, this instability can be avoided by using the following commands: - out-delay <second>; applicable to all BGP peers, all peers in a group, or an individual peer. This implements a delay between when the routing table receives the routing information and when the information is exported to BGP peers. - hold-time sec; applicable to all BGP peers, all peers in a group or an individual peer. This allows a shorter per neighbor holdtimer to be applied on both routers (30 sec will gives keepalives of 10 sec). - hold-time msec; to be configured in the router interfaces where the BGP peering wil be established. This delays the propagation of the interfaces-down events to the routing protocol. 4. Potential problems 4.1 Multiplication of flaps between ASes with multiple interconnections Christian Panigl experienced the following during a circuit upgrade of an Ebone customer: - Only ONE flap was generated as a result of the upgrade process (disconnect router-port from modem A, reconnect to modem B). Nevertheless the customer's prefix was damped in all ICM routers. - The flap statistics in the ICM routers stated *4* flaps !!! - The only explanation would be that the multiple interconnections between Ebone/AS1755 and ICM/AS1800 did multiply the flaps (advertisements/withdrawals arrived time-shifted at ICM routers through the multiple circuits). - This would then potentially hold true for any meshed topology because of the propagation delays of advertisements/withdrawals. There are two potential solutions to workaround this problem. The first one is operational, the second one is a software configuration feature (for Cisco IOS and possibly other implementations as well). * Schedule a downtime for at least 3-5 minutes which should be enough time for the prefix withdrawals to have propagated through all paths before reconnection and re-advertisement of the prefix. Avoid clearing BGP sessions as this also could generate a 30 minute outage through flap damping! * Configure a permanent static route pointing to the customer interface. Even if the interface goes down, there is still an entry in the routing table for the customer network, and BGP will therefore still announce the prefix. Example, using Cisco IOS: ! router bgp 65500 network 169.254.0.0 mask 255.255.0.0 ip route 169.254.0.0 255.255.0.0 serial 5/0 permanent ! If migrating the customer from one router port to another, simply enter the second static route pointing to the new interface. Move the cable between ports - BGP continues to announce the prefix as the entry is still in the routing table. Note: this solution only applies to customers who connect using static routes. If the customer connects using BGP, first disable fast-external-fallover on both the customer and ISP router, and then move the cable in a time period less than the BGP hold-timer. 4.2 Non-recommended flap damping parameters There are situations where service providers would like to design their own route flap damping parameters for local needs or conditions. If this is really desired, then it is important to pay attention to how flap damping parameters are configured, whether the values are feasible or not, etc. For example, in Cisco IOS, it is perfectly possible to configure flap damping parameters which do nothing, with IOS not giving any warning about them being "unfeasible" parameters. * One example might be the configuration "set dampening 15 500 3000 30". Here the reuse limit is 500, maximum suppress time is 30 minutes and the half life is 15 minutes. Using these three parameters gives a maximum possible penalty value of 2000, well below the suppress limit of 3000. So even though this can be successfully configured on the router, no damping will take place. * Another example might be the configuration "set dampening 15 750 3000 30". Here the reuse limit is 750, maximum suppress time is 30 minutes and the half life is 15 minutes. Using these three parameters gives a maximum possible penalty of 3000, exactly the same as the suppress-limit. In Cisco IOS, the penalty is decayed every 5 seconds, so flap damping will only be take place if the update follows the withdraw within that 5 second time frame. 99% of the time no flap damping will take place. 5. References RIPE/Routing-WG Minutes dealing with Route Flap Damping: http://www.ripe.net/ripe/meetings/archive/ripe-24/ripe-m-24.txt http://www.ripe.net/ripe/meetings/archive/ripe-25/ripe-m-25.txt http://www.ripe.net/wg/routing/r25-routing.html http://www.ripe.net/wg/routing/r26-routing.html http://www.ripe.net/wg/routing/r27-routing.html Curtis Villamizar, Ravi Chandra, Ramesh Govindan RFC2439: BGP Route Flap Damping (Proposed Standard) ftp://ftp.ietf.org/rfc/rfc2439.txt Enke Chen RFC2918: Route Refresh Capability for BGP-4 (Proposed Standard) ftp://ftp.ietf.org/rfc/rfc2918.txt Merit/IPMA: Internet Routing Recommendations http://www.merit.edu/ipma/docs/help.html Cisco BGP Case Studies: Route Flap Damping http://www.cisco.com/warp/public/459/16.html Cisco Documentation: Configuring BGP / Route Damping / Soft Reset http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/ 122cgcr/fipr_c/ipcprt2/1cfbgp.htm ISI/RSd Configuration: Route Flap Damping http://www.isi.edu/div7/ra/RSd/doc/dampen.html GateD Configuration: Weighted Route Damping Statement http://www.nexthop.com/techinfo/manuals/o_config_guide/bgp/ weighted_route_dampening.shtml Juniper Configuration: Configuring Dumping parameters http://www.juniper.net/techpubs/software/junos44/swconfig44- routing/html/policy-damping-config.html 6. Acknowledgements Thanks go to all the contributors to this updated version and to the RIPE NCC for hosting the "Golden Networks" web-site. 7. Changes over previous versions This document is a significant rewrite and update of RIPE-210. The "Golden Networks" have now been moved from this document on to a website dedicated to listing them as they are frequently changing. The authors have come across several instances of providers implementing the recommendations without actually checking that the Root Nameserver networks were still as listed in the document. Updates to the Cisco IOS configuration have been made, and the parameters chosen for /24 networks have been corrected to make them feasible. Juniper JunOS configuration samples have been added to this document. Examples of flap damping in operation have been added to Appendix 3. Router configurations for the recommended route flap damping parameters have been moved out of this document to the web-site. 8. Authors The authors can be contacted as follows: Philip Smith <pfs(a)cisco.com> Cristina Vistoli <cvistoli(a)juniper.net> Christian Panigl <panigl(a)cc.univie.ac.at> Joachim Schmitz <schmitzjo(a)aol.com> Appendices A.1 "Golden Networks" Examples of Golden Networks can be found on a website which has been set up specifically for them. Please consult http://www.golden-networks.net for a sample list of current golden networks and the equivalent router configuration for these networks. A.2 Sample Configurations Sample Router configurations which have been contributed to this project can be found at the http://www.golden-networks.net website. Contributions of working configurations from other routing software should be sent to the authors for inclusion in the website. A.3 Study of Flap Damping Operation It is instructive to observe how route flap damping actually works on a router - doing so will help the reader understand how the particular values described in Section 2.2 were chosen. The tests were carried out using both Cisco IOS and JunOS. A.3.1 Cisco IOS The test bed had two Cisco routers connected to each other. One router originated prefixes, the other one had the flap damping parameters described above in the text. The router originating the prefixes would withdraw a prefix, then reannounce, then withdraw, reannounce, etc. The BGP process in IOS checks every 60 seconds for any new or withdrawn prefixes in the local configuration - so on the source router, the withdraw and announce was done by removing and adding the BGP network statement for the prefix in question. The router monitoring the flaps would see the prefix being withdrawn and then announced 60s later. A.3.1.1 For /24s Parameters used are "set dampening 15 820 3000 30" 1st flap 1000 decay to 966, 982 at update 2nd flap 1966 decay to 1894, 1926 at update 3rd flap 2894 decay to 2787, 2846 at update 4th flap 3280 decay to 3165, 3226 at update Maximum possible penalty is 3280 as defined by the flap parameters, so the penalty at the 4th flap was only incremented from 2787 to 3280, not 3787 as might have been expected. At the 4th flap the prefix was marked as being suppressed for 59 minutes when the update message was received. If the update after the 4th flap was not received within 4 minutes and 20 seconds, the penalty dropped below 3000, and the prefix was not suppressed. A.3.1.2 For /22s, /23s Parameters used are "set dampening 15 750 3000 45" 1st flap 1000 decay to 921, 960 at update 2nd flap 1921 decay to 1777, 1850 at update 3rd flap 2777 decay to 2583, 2671 at update 4th flap 3583 decay to 3311, 3451 at update Maximum possible penalty is 6000. At the 4th flap the prefix was marked as being suppressed for 33 minutes when the update message was received. If the update after the 4th flap was not received within 4 minutes and 40 seconds, the penalty dropped below 3000, and the prefix was not suppressed. A.3.1.3 For remaining prefixes Parameters used are "set dampening 10 1500 3000 30" 1st flap 1000 decay to 889, 946 at update 2nd flap 1889 decay to 1679, 1781 at update 3rd flap 2679 decay to 2367, 2526 at update 4th flap 3367 decay to 3019, 3176 at update Maximum possible penalty is 12000. At the 4th flap the prefix was marked as being suppressed for 10 minutes when the update message was received. If the update after the 4th flap was not received within 2 minutes and 5 seconds, the penalty dropped below 3000, and the prefix was not suppressed. A.3.2 JunOS A similar test bed with two Juniper routers was set up using the damping parameters described in Appendix A.2.2 above. One router originated prefixes, the other router implemented the flap damping parameters. The router originating the prefixes would withdraw a prefix, then reannounce, then withdraw, reannounce, etc, with the effects being monitored on the second router. A.3.2.1 For /24s Parameters used are "set-high policy" half-life 30; reuse 1640; suppress 6000; max-suppress 60; 1 up/down: decay to 1946 2 up/down: decay to 3723 3 up/down: decay to 5575 4 up/down: decay to 6577 At the 4th flap the prefix was marked as being suppressed for 1 hour when the update message was received. A.3.2.2 For /22s, /23s Parameters used are "set-medium policy" half-life 15; reuse 1500; suppress 6000; max-suppress 45; 1 up/down: decay to 1939 2 up/down: decay to 3269 3 up/down: decay to 3733 4 up/down: decay to 4944 5 up/down: decay to 6032 At the 5th flap the prefix was marked as being suppressed for 30 min when the update message was received A.3.2.3 For remaining prefixes Parameters used are "set-normal policy" half-life 10; reuse 3000; suppress 6000; max-suppress 30; 1 up/down: decay to 1909 2 up/down: decay to 3503 3 up/down: decay to 5065 4 up/down: decay to 6556 At the 4th flap the prefix was marked as being suppressed for 10 min when the update message was received A.3.3 Summary When analysing flap damping performance on the router or across the network, network managers should compare with the above lab tests. Note especially that slowly flapping prefixes are unlikely to be suppressed even though they show significant flapping history. A future version of this document may consider what to do in this instance.

1 0

The Cidr Report
by CIDR Report 29 Sep '01

29 Sep '01

This is an auto-generated mail on Fri Sep 28 23:00:00 PDT 2001 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. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. 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 GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 28Sep01 0) General Status Table History ------------- Date Prefixes 210901 103625 220901 103684 230901 103666 240901 103680 250901 103629 260901 103632 270901 104968 280901 104483 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 82.105.0.0/16 from AS3269 *** Bogus 82.105.128.0/17 from AS3269 AS Summary ---------- Number of ASes in routing system: 11715 Number of ASes announcing only one prefix: 6979 (3955 cidr, 3024 classful) Largest number of cidr routes: 855 announced by AS701 Largest number of classful routes: 1389 announced by AS701 1) Gains by aggregating at the origin AS level --- 28Sep01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1262 961 301 23.9% Telstra Pty Ltd AS4151 299 171 128 42.8% USDA AS16473 201 76 125 62.2% Bell South AS577 306 187 119 38.9% Bell Advanced Communications Inc. AS13999 132 16 116 87.9% Mega Cable S.A. de C.V. AS6595 170 60 110 64.7% DoD Education Activity Network As AS4293 376 267 109 29.0% Cable & Wireless USA AS2048 209 115 94 45.0% State of Louisiana AS6429 195 102 93 47.7% AT&T Chile Internet S.A. AS4755 213 131 82 38.5% Videsh Sanchar Nigam Ltd. Autonom AS12302 98 28 70 71.4% MobiFon S.A. AS1239 471 402 69 14.6% Sprint AS4200 142 74 68 47.9% Apex Global Information Services, AS6471 128 63 65 50.8% ENTEL CHILE S.A. AS17557 128 65 63 49.2% Pakistan Telecom AS3464 157 96 61 38.9% Alabama SuperComputer Network AS19632 67 9 58 86.6% Metropolis Intercom S.A. AS16758 63 6 57 90.5% IKON Office Solutions AS209 303 248 55 18.2% Qwest AS3908 283 230 53 18.7% Supernet, Inc. AS11686 160 107 53 33.1% Education Networks of America AS226 145 93 52 35.9% Los Nettos AS17561 113 62 51 45.1% Internet service provision to Wes AS1 533 482 51 9.6% BBN Planet AS4323 247 197 50 20.2% Time Warner Communications, Inc. AS306 59 10 49 83.1% National Guard Bureau AS637 104 56 48 46.2% Department of Navy AS10620 68 21 47 69.1% TVCABLE BOGOTA AS1913 151 105 46 30.5% Defense Logistics Agency AS15290 244 199 45 18.4% AT&T Canada IES 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

Weekly Routing Table Report
by Routing Analysis 27 Sep '01

27 Sep '01

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats(a)lists.apnic.net For a graphical representation, please see http://www.apnic.net/stats/bgp. If you have any comments please contact Philip Smith <pfs(a)cisco.com>. Routing Table Report 28 Sep, 2001 Analysis Summary ---------------- BGP routing table entries examined: 108349 Origin ASes present in the Internet Routing Table: 11800 Origin ASes announcing only one prefix: 4354 Transit ASes present in the Internet Routing Table: 1502 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 23 Illegal AS announcements present in the Routing Table: 58 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 14 Number of addresses announced to Internet: 1231864162 Equivalent to 73 /8s, 108 /16s and 193 /24s Percentage of available address space announced: 33.2 Percentage of allocated address space announced: 64.0 Percentage of available address space allocated: 51.9 Total number of prefixes smaller than registry allocations: 73435 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 16348 Prefixes being announced from the APNIC address blocks: 14759 APNIC Region origin ASes present in the Internet Routing Table: 1376 APNIC Region origin ASes announcing only one prefix: 461 APNIC Region transit ASes present in the Internet Routing Table: 227 Average APNIC Region AS path length visible: 5.1 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 80539954 Equivalent to 4 /8s, 204 /16s and 241 /24s Percentage of available APNIC address space announced: 79.2 APNIC AS Blocks 4608 - 4864, 7467 - 7722, 9216 - 10239, 17408 - 18431 APNIC Address Blocks 61/8, 202/7, 210/7 and 218/8 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 74504 Prefixes being announced from the ARIN address blocks: 52998 ARIN Region origin ASes present in the Internet Routing Table: 7110 ARIN Region origin ASes announcing only one prefix: 2139 ARIN Region transit ASes present in the Internet Routing Table: 709 Average ARIN Region AS path length visible: 5.2 Max ARIN Region AS path length visible: 19 Number of ARIN addresses announced to Internet: 208629299 Equivalent to 12 /8s, 111 /16s and 110 /24s Percentage of available ARIN address space announced: 77.7 ARIN AS Blocks 1 - 1876, 1902 - 2042, 2044 - 2046, 2048 - 2106 2138 - 2584, 2615 - 2772, 2823 - 2829, 2880 - 3153 3354 - 4607, 4865 - 5119, 5632 - 6655, 6912 - 7466 7723 - 8191, 10240 - 12287, 13312 - 15359 16384 - 17407, 18432 - 20479, 21504 - 22527 ARIN Address Blocks 24/8, 63/8, 64/6, 68/8, 199/8, 200/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 17486 Prefixes being announced from the RIPE address blocks: 13906 RIPE Region origin ASes present in the Internet Routing Table: 3323 RIPE Region origin ASes announcing only one prefix: 1754 RIPE Region transit ASes present in the Internet Routing Table: 568 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 23 Number of RIPE addresses announced to Internet: 107522335 Equivalent to 6 /8s, 104 /16s and 169 /24s Percentage of available RIPE address space announced: 71.2 RIPE AS Blocks 1877 - 1901, 2043, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 20480 - 21503 RIPE Address Blocks 62/8, 80/7, 193/8, 194/7, 212/7 and 217/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv Description 1221 1612 1313 Telstra Pty Ltd 2764 418 374 connect.com.au pty ltd 703 410 372 UUNET Technologies, Inc. 2907 369 1847 SINET Japan 4755 297 162 Videsh Sanchar Nigam Ltd. Aut 7474 241 274 Optus Communications Pty Ltd 4134 239 1808 Data Communications Bureau 7539 209 190 TANet2, sponsored by NSC, TAI 4740 183 23 OzEmail ISP 4766 181 1338 Korea Internet Exchange for " 9443 153 50 Primus Telecommunications 4786 127 17 NetConnect Communications Pty 17557 127 8 Pakistan Telecom 7545 125 23 TPG Internet Pty Ltd 9768 125 378 Korea Telecom 4763 122 69 Telstra New Zealand 9583 119 60 Satyam Infoway Ltd., 4713 117 885 NTT Communications Corporatio 17561 116 167 Internet service provision to 4808 105 192 CHINANET core WAN North RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv Description 702 903 1955 UUNET Technologies, Inc. 3301 444 935 TeliaNet Sweden 1257 271 512 SWIPnet Swedish IP Network 680 242 2340 DFN-IP service G-WiN 3215 229 515 France Telecom / &Equant 5515 193 687 Sonera Finland Autonomous Sys 3320 188 1942 Deutsche Telekom AG 786 185 1890 The JANET IP Service 8708 158 16 Romania Data Systems S.A. 15870 149 11 Global Center Frankfurt 1270 147 734 UUNET Germany 719 137 288 LANLINK autonomous system 5400 137 64 Concert European Core Network 3303 130 560 Swisscom Ltd 15878 129 9 Global Center Paris 2856 126 774 BTnet UK Regional network 5549 126 67 Nextra Deutschland GmbH + Co. 517 111 253 KPNQwest Germany GmbH 1267 103 1988 Infostrada S.p.A. 12302 101 6 MobiFon S.A. ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv Description 701 2252 8126 UUNET Technologies, Inc. 7018 1048 7150 AT&T 1 866 8638 BBN Planet 7046 816 1007 UUNET Technologies, Inc. 1239 735 3375 Sprint 3908 634 1380 Supernet, Inc. 3967 598 468 Exodus Communication 209 535 2216 Qwest 690 516 97 Merit Network 2914 500 2287 Verio, Inc. 4293 451 112 Cable & Wireless USA 3561 406 2326 Cable & Wireless USA 721 388 4422 DLA Systems Automation Center 2548 374 1005 Business Internet, Inc. 3549 371 820 Global Crossing 4323 362 361 Time Warner Communications, I 2149 358 246 Performance Systems, Inc. 577 354 636 Bell Advanced Communications 3741 352 776 The Internet Solution 705 350 71 UUNET Technologies, Inc. Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv Description 701 2252 8126 UUNET Technologies, Inc. 1221 1612 1313 Telstra Pty Ltd 7018 1048 7150 AT&T 702 903 1955 UUNET Technologies, Inc. 1 866 8638 BBN Planet 7046 816 1007 UUNET Technologies, Inc. 1239 735 3375 Sprint 3908 634 1380 Supernet, Inc. 3967 598 468 Exodus Communication 209 535 2216 Qwest 690 516 97 Merit Network 2914 500 2287 Verio, Inc. 4293 451 112 Cable & Wireless USA 3301 444 935 TeliaNet Sweden 2764 418 374 connect.com.au pty ltd 703 410 372 UUNET Technologies, Inc. 3561 406 2326 Cable & Wireless USA 721 388 4422 DLA Systems Automation Center 2548 374 1005 Business Internet, Inc. 3549 371 820 Global Crossing List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 65530 PRIVATE 63.178.38.0/24 4999 Sprint 65530 PRIVATE 63.178.42.0/24 4999 Sprint 65530 PRIVATE 63.178.44.0/24 4999 Sprint 65530 PRIVATE 63.178.58.0/24 4999 Sprint 65530 PRIVATE 63.178.60.0/24 4999 Sprint 65530 PRIVATE 63.178.63.0/24 4999 Sprint 6971 UNALLOCATED 64.42.0.0/18 2516 Kokusai Denshin Denw 6971 UNALLOCATED 64.42.0.0/17 2516 Kokusai Denshin Denw 6971 UNALLOCATED 64.42.32.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.40.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.48.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.60.0/22 2914 Verio, Inc. 6971 UNALLOCATED 64.42.72.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.80.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.112.0/20 2914 Verio, Inc. 6971 UNALLOCATED 64.87.64.0/19 2516 Kokusai Denshin Denw 578 UNALLOCATED 64.230.242.16/28 577 Bell Advanced Commun 65000 PRIVATE 138.163.4.0/24 665 Department of Navy 2027 UNALLOCATED 150.185.128.0/18 8143 Publicom Corp. 6971 UNALLOCATED 192.103.229.0/24 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.230.0/23 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.232.0/22 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.236.0/23 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.237.0/24 2516 Kokusai Denshin Denw 1877 UNALLOCATED 192.108.201.0/24 1880 Stupi, house man's p 5555 UNALLOCATED 192.156.8.0/24 721 DLA Systems Automati 5555 UNALLOCATED 192.156.41.0/24 721 DLA Systems Automati 65460 PRIVATE 192.231.11.0/24 7018 AT&T 5555 UNALLOCATED 199.10.190.0/24 721 DLA Systems Automati 22290 UNALLOCATED 199.217.152.0/24 1239 Sprint 22290 UNALLOCATED 199.217.187.0/24 1239 Sprint 6971 UNALLOCATED 199.249.223.0/24 2516 Kokusai Denshin Denw 6971 UNALLOCATED 206.58.248.0/22 2516 Kokusai Denshin Denw 6971 UNALLOCATED 206.58.248.0/21 2516 Kokusai Denshin Denw 6971 UNALLOCATED 206.58.252.0/23 2914 Verio, Inc. 6971 UNALLOCATED 206.58.254.0/23 2914 Verio, Inc. 64803 PRIVATE 206.81.213.0/24 6225 US West Communicatio 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, 22290 UNALLOCATED 207.150.139.0/24 1239 Sprint 22075 UNALLOCATED 209.39.134.0/24 209 Qwest 65515 PRIVATE 212.110.142.0/24 5593 CRIS-AS 6971 UNALLOCATED 216.105.192.0/20 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.121.224.0/19 2516 Kokusai Denshin Denw 64803 PRIVATE 216.160.71.0/24 6225 US West Communicatio 6971 UNALLOCATED 216.174.192.0/21 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.192.0/18 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.200.0/23 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.200.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.174.208.0/20 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.232.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.210.128.0/18 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.210.128.0/17 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.210.144.0/20 2914 Verio, Inc. 6971 UNALLOCATED 216.210.176.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.210.184.0/22 2914 Verio, Inc. 6971 UNALLOCATED 216.210.216.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.210.224.0/20 2914 Verio, Inc. 6971 UNALLOCATED 216.229.96.0/20 2516 Kokusai Denshin Denw Advertised Unregistered Addresses --------------------------------- Network Origin AS Description 128.65.0.0/16 3463 ACES Research Inc 132.0.0.0/10 568 DISO-UNRRA 134.137.0.0/16 400 Headquarters Standard Systems 135.0.0.0/13 10455 Lucent Technologies 137.0.0.0/13 568 DISO-UNRRA 138.94.0.0/16 1 BBN Planet 144.7.0.0/16 701 UUNET Technologies, Inc. 153.34.0.0/15 701 UUNET Technologies, Inc. 153.36.0.0/14 701 UUNET Technologies, Inc. 154.150.0.0/16 6494 IDCI 158.0.0.0/13 568 DISO-UNRRA 164.233.0.0/16 6020 DISA NETWORK SERVICES 164.235.0.0/16 6025 US DOD NIC Unregistered 201.115.100.0/24 7018 AT&T Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:17 /9:5 /10:7 /11:12 /12:33 /13:86 /14:226 /15:386 /16:7074 /17:1239 /18:2345 /19:6934 /20:5827 /21:4746 /22:6976 /23:8882 /24:62009 /25:311 /26:326 /27:254 /28:254 /29:148 /30:183 /31:1 /32:68 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 1221 1465 1612 Telstra Pty Ltd 701 1421 2252 UUNET Technologies, Inc. 7046 639 816 UUNET Technologies, Inc. 702 615 903 UUNET Technologies, Inc. 7018 555 1048 AT&T 690 512 516 Merit Network 4293 437 451 Cable & Wireless USA 1 423 866 BBN Planet 3967 419 598 Exodus Communication 3908 417 634 Supernet, Inc. 1239 407 735 Sprint 209 374 535 Qwest 2764 372 418 connect.com.au pty ltd 703 339 410 UUNET Technologies, Inc. 5106 321 341 Ameritech Advanced Data Servi 6995 308 319 Bell Atlantic Internet Soluti 705 304 350 UUNET Technologies, Inc. 4323 303 362 Time Warner Communications, I 11371 301 313 Rhythms NetConnections 4151 279 321 USDA Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:6 9:1 12:419 13:10 15:1 17:5 20:1 24:817 25:1 26:1 32:73 38:12 43:3 44:2 53:2 55:1 57:15 61:92 62:144 63:1879 64:1325 65:740 66:466 67:2 80:60 128:50 129:108 130:19 131:51 132:39 133:2 134:139 135:10 136:93 137:92 138:217 139:45 140:197 141:198 142:57 143:39 144:152 145:13 146:146 147:129 148:83 149:87 150:37 151:324 152:372 153:45 154:16 155:85 156:92 157:111 158:74 159:68 160:48 161:60 162:67 163:148 164:100 165:98 166:193 167:150 168:118 169:40 170:280 171:2 192:5595 193:1960 194:2029 195:816 196:453 198:4058 199:3822 200:2530 201:1 202:2814 203:4558 204:3361 205:2209 206:2891 207:2588 208:3154 209:3096 210:559 211:143 212:856 213:514 214:8 215:13 216:3005 217:402 218:2 End of report

1 0

RE:Help me please !
by Luiz Eduardo 24 Sep '01

24 Sep '01

Hello! for who didn't understand I only need a log of the messages rip changed among gateways. I don't have a router CISCO, I only have a linux server runing NAT. could you arrange a log of these for me? please thanks

2 1

The Cidr Report
by CIDR Report 22 Sep '01

22 Sep '01

This is an auto-generated mail on Fri Sep 21 23:00:01 PDT 2001 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. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. 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 GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 21Sep01 0) General Status Table History ------------- Date Prefixes 140901 102582 150901 102950 160901 102809 170901 103092 180901 103047 190901 102981 200901 103292 210901 103625 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: 11609 Number of ASes announcing only one prefix: 6928 (3946 cidr, 2982 classful) Largest number of cidr routes: 854 announced by AS701 Largest number of classful routes: 1379 announced by AS701 1) Gains by aggregating at the origin AS level --- 21Sep01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1259 956 303 24.1% Telstra Pty Ltd AS701 1379 1176 203 14.7% UUNET Technologies, Inc. AS4151 296 169 127 42.9% USDA AS577 314 193 121 38.5% Bell Advanced Communications Inc. AS4293 379 270 109 28.8% Cable & Wireless USA AS6595 166 59 107 64.5% DoD Education Activity Network As AS705 249 152 97 39.0% UUNET Technologies, Inc. AS7018 769 672 97 12.6% AT&T AS6429 196 101 95 48.5% AT&T Chile Internet S.A. AS13999 109 15 94 86.2% Mega Cable S.A. de C.V. AS2048 212 120 92 43.4% State of Louisiana AS16473 154 65 89 57.8% Bell South AS4755 210 124 86 41.0% Videsh Sanchar Nigam Ltd. Autonom AS12302 98 28 70 71.4% MobiFon S.A. AS4200 142 74 68 47.9% Apex Global Information Services, AS1239 465 398 67 14.4% Sprint AS7046 317 252 65 20.5% UUNET Technologies, Inc. AS6471 127 62 65 51.2% ENTEL CHILE S.A. AS724 218 155 63 28.9% DLA Systems Automation Center AS17557 125 65 60 48.0% Pakistan Telecom AS19632 67 9 58 86.6% Metropolis Intercom S.A. AS16758 63 6 57 90.5% IKON Office Solutions AS209 313 258 55 17.6% Qwest AS703 301 249 52 17.3% UUNET Technologies, Inc. AS3464 147 95 52 35.4% Alabama SuperComputer Network AS226 145 93 52 35.9% Los Nettos AS17561 113 62 51 45.1% Internet service provision to Wes AS1 535 484 51 9.5% BBN Planet AS4323 249 199 50 20.1% Time Warner Communications, Inc. AS10620 67 20 47 70.1% TVCABLE BOGOTA 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

Help me please !
by Luiz Eduardo 22 Sep '01

22 Sep '01

hello. Good Morning friends of list Routing-wg. I need a log of the protocol rip or rip2 with the messages changed among the gateways, for a work in the university. Don't I have gateway and nor will a net to may capture this packages, be that anybody can help myself? Thanks Luiz Eduardo

1 0

Weekly Routing Table Report
by Routing Analysis 20 Sep '01

20 Sep '01

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats(a)lists.apnic.net For a graphical representation, please see http://www.apnic.net/stats/bgp. If you have any comments please contact Philip Smith <pfs(a)cisco.com>. Routing Table Report 21 Sep, 2001 Analysis Summary ---------------- BGP routing table entries examined: 107292 Origin ASes present in the Internet Routing Table: 11683 Origin ASes announcing only one prefix: 4306 Transit ASes present in the Internet Routing Table: 1506 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 23 Illegal AS announcements present in the Routing Table: 83 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 14 Number of addresses announced to Internet: 1220327874 Equivalent to 72 /8s, 188 /16s and 185 /24s Percentage of available address space announced: 32.9 Percentage of allocated address space announced: 63.4 Percentage of available address space allocated: 51.9 Total number of prefixes smaller than registry allocations: 73062 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 16244 Prefixes being announced from the APNIC address blocks: 14648 APNIC Region origin ASes present in the Internet Routing Table: 1372 APNIC Region origin ASes announcing only one prefix: 463 APNIC Region transit ASes present in the Internet Routing Table: 228 Average APNIC Region AS path length visible: 5.1 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 80353253 Equivalent to 4 /8s, 202 /16s and 23 /24s Percentage of available APNIC address space announced: 79.0 APNIC AS Blocks 4608 - 4864, 7467 - 7722, 9216 - 10239, 17408 - 18431 APNIC Address Blocks 61/8, 202/7, 210/7 and 218/8 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 73531 Prefixes being announced from the ARIN address blocks: 52976 ARIN Region origin ASes present in the Internet Routing Table: 7020 ARIN Region origin ASes announcing only one prefix: 2100 ARIN Region transit ASes present in the Internet Routing Table: 698 Average ARIN Region AS path length visible: 5.2 Max ARIN Region AS path length visible: 19 Number of ARIN addresses announced to Internet: 209398865 Equivalent to 12 /8s, 123 /16s and 44 /24s Percentage of available ARIN address space announced: 78.0 ARIN AS Blocks 1 - 1876, 1902 - 2042, 2044 - 2046, 2048 - 2106 2138 - 2584, 2615 - 2772, 2823 - 2829, 2880 - 3153 3354 - 4607, 4865 - 5119, 5632 - 6655, 6912 - 7466 7723 - 8191, 10240 - 12287, 13312 - 15359 16384 - 17407, 18432 - 20479, 21504 - 22527 ARIN Address Blocks 24/8, 63/8, 64/6, 68/8, 199/8, 200/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 17513 Prefixes being announced from the RIPE address blocks: 13863 RIPE Region origin ASes present in the Internet Routing Table: 3312 RIPE Region origin ASes announcing only one prefix: 1743 RIPE Region transit ASes present in the Internet Routing Table: 580 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 23 Number of RIPE addresses announced to Internet: 107384727 Equivalent to 6 /8s, 102 /16s and 143 /24s Percentage of available RIPE address space announced: 71.1 RIPE AS Blocks 1877 - 1901, 2043, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 20480 - 21503 RIPE Address Blocks 62/8, 80/7, 193/8, 194/7, 212/7 and 217/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv Description 1221 1608 1314 Telstra Pty Ltd 2764 420 377 connect.com.au pty ltd 703 418 375 UUNET Technologies, Inc. 2907 367 1831 SINET Japan 4755 287 158 Videsh Sanchar Nigam Ltd. Aut 7474 241 274 Optus Communications Pty Ltd 4134 238 1800 Data Communications Bureau 7539 211 199 TANet2, sponsored by NSC, TAI 4740 187 23 OzEmail ISP 4766 178 1336 Korea Internet Exchange for " 9443 150 50 Primus Telecommunications 17557 130 9 Pakistan Telecom 4786 127 17 NetConnect Communications Pty 7545 125 23 TPG Internet Pty Ltd 4763 119 69 Telstra New Zealand 9768 119 362 Korea Telecom 9583 117 60 Satyam Infoway Ltd., 4713 116 884 NTT Communications Corporatio 17561 116 167 Internet service provision to 7586 111 17 Paradox Digital Pty Ltd RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv Description 702 881 1965 UUNET Technologies, Inc. 3301 441 919 TeliaNet Sweden 1257 280 530 SWIPnet Swedish IP Network 680 237 2308 DFN-IP service G-WiN 3215 228 515 France Telecom / &Equant 5515 192 687 Sonera Finland Autonomous Sys 3320 186 1940 Deutsche Telekom AG 786 185 1890 The JANET IP Service 15870 179 11 Global Center Frankfurt 8708 156 16 Romania Data Systems S.A. 1270 146 734 UUNET Germany 15878 138 12 Global Center Paris 719 137 288 LANLINK autonomous system 5400 137 64 Concert European Core Network 3303 131 560 Swisscom Ltd 2856 126 774 BTnet UK Regional network 5549 126 67 Nextra Deutschland GmbH + Co. 517 116 270 KPNQwest Germany GmbH 1267 104 1990 Infostrada S.p.A. 12302 100 6 MobiFon S.A. ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv Description 701 2257 8309 UUNET Technologies, Inc. 7018 1055 7180 AT&T 3908 922 722 Supernet, Inc. 1 871 8638 BBN Planet 7046 801 989 UUNET Technologies, Inc. 1239 731 3326 Sprint 3967 602 473 Exodus Communication 209 537 2248 Qwest 690 502 80 Merit Network 2914 499 2240 Verio, Inc. 4293 466 113 Cable & Wireless USA 3561 407 2325 Cable & Wireless USA 2548 370 985 Business Internet, Inc. 3549 370 836 Global Crossing 2149 368 279 Performance Systems, Inc. 577 361 635 Bell Advanced Communications 4323 361 360 Time Warner Communications, I 2048 360 182 State of Louisiana 3741 352 776 The Internet Solution 705 341 55 UUNET Technologies, Inc. Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv Description 701 2257 8309 UUNET Technologies, Inc. 1221 1608 1314 Telstra Pty Ltd 7018 1055 7180 AT&T 3908 922 722 Supernet, Inc. 702 881 1965 UUNET Technologies, Inc. 1 871 8638 BBN Planet 7046 801 989 UUNET Technologies, Inc. 1239 731 3326 Sprint 3967 602 473 Exodus Communication 209 537 2248 Qwest 690 502 80 Merit Network 2914 499 2240 Verio, Inc. 4293 466 113 Cable & Wireless USA 3301 441 919 TeliaNet Sweden 2764 420 377 connect.com.au pty ltd 703 418 375 UUNET Technologies, Inc. 3561 407 2325 Cable & Wireless USA 2548 370 985 Business Internet, Inc. 3549 370 836 Global Crossing 2149 368 279 Performance Systems, Inc. List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 22130 UNALLOCATED 4.18.195.0/24 3561 Cable & Wireless USA 22242 UNALLOCATED 12.14.215.0/24 7222 Southwestern Bell In 21048 UNALLOCATED 62.16.96.0/19 3216 SOVAM Teleport, Mosc 65534 PRIVATE 62.23.176.0/24 6675 Colt Telecommunicati 65534 PRIVATE 62.23.177.0/24 6675 Colt Telecommunicati 22299 UNALLOCATED 63.81.99.0/24 701 UUNET Technologies, 22299 UNALLOCATED 63.124.154.0/24 701 UUNET Technologies, 6971 UNALLOCATED 64.42.0.0/18 2516 Kokusai Denshin Denw 6971 UNALLOCATED 64.42.0.0/17 2516 Kokusai Denshin Denw 6971 UNALLOCATED 64.42.40.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.48.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.60.0/22 2914 Verio, Inc. 6971 UNALLOCATED 64.42.72.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.108.0/22 2914 Verio, Inc. 6971 UNALLOCATED 64.42.112.0/20 2914 Verio, Inc. 6971 UNALLOCATED 64.87.64.0/19 2516 Kokusai Denshin Denw 578 UNALLOCATED 64.230.242.16/28 577 Bell Advanced Commun 22091 UNALLOCATED 65.113.20.0/24 209 Qwest 22195 UNALLOCATED 65.116.137.0/24 209 Qwest 22299 UNALLOCATED 65.161.22.0/24 701 UUNET Technologies, 22299 UNALLOCATED 65.161.22.0/23 701 UUNET Technologies, 22299 UNALLOCATED 65.161.23.0/24 701 UUNET Technologies, 22326 UNALLOCATED 65.170.47.0/24 209 Qwest 22313 UNALLOCATED 66.96.52.0/22 7927 Global One Venezuela 21127 UNALLOCATED 80.89.128.0/20 20485 JSC Transtelecom 21127 UNALLOCATED 80.89.130.0/23 20485 JSC Transtelecom 21127 UNALLOCATED 80.89.132.0/22 20485 JSC Transtelecom 21127 UNALLOCATED 80.89.137.0/24 20485 JSC Transtelecom 21127 UNALLOCATED 80.89.138.0/23 20485 JSC Transtelecom 21127 UNALLOCATED 80.89.143.0/24 20485 JSC Transtelecom 2027 UNALLOCATED 150.185.128.0/18 8143 Publicom Corp. 6971 UNALLOCATED 192.103.229.0/24 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.230.0/23 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.232.0/22 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.236.0/23 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.237.0/24 2516 Kokusai Denshin Denw 1877 UNALLOCATED 192.108.201.0/24 1880 Stupi, house man's p 65460 PRIVATE 192.231.11.0/24 7018 AT&T 22313 UNALLOCATED 196.27.8.0/22 7927 Global One Venezuela 22284 UNALLOCATED 198.183.146.0/23 701 UUNET Technologies, 22284 UNALLOCATED 198.246.64.0/19 701 UUNET Technologies, 22301 UNALLOCATED 199.171.142.0/24 6517 Yipes Communications 22284 UNALLOCATED 199.244.155.0/24 701 UUNET Technologies, 22284 UNALLOCATED 199.244.156.0/24 701 UUNET Technologies, 6971 UNALLOCATED 199.249.223.0/24 2516 Kokusai Denshin Denw 22313 UNALLOCATED 200.47.150.0/24 7927 Global One Venezuela 22303 UNALLOCATED 204.62.219.0/24 2914 Verio, Inc. 22303 UNALLOCATED 204.62.220.0/24 2914 Verio, Inc. 22303 UNALLOCATED 204.62.221.0/24 2914 Verio, Inc. 22303 UNALLOCATED 204.62.222.0/24 2914 Verio, Inc. 22130 UNALLOCATED 205.180.228.0/24 3561 Cable & Wireless USA 6971 UNALLOCATED 206.58.248.0/22 2516 Kokusai Denshin Denw 6971 UNALLOCATED 206.58.248.0/21 2516 Kokusai Denshin Denw 6971 UNALLOCATED 206.58.252.0/23 2914 Verio, Inc. 6971 UNALLOCATED 206.58.254.0/23 2914 Verio, Inc. 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, 22257 UNALLOCATED 207.176.8.0/21 3491 CAIS Internet 6971 UNALLOCATED 207.189.143.0/24 2516 Kokusai Denshin Denw 22179 UNALLOCATED 207.190.35.0/24 3549 Global Crossing 22326 UNALLOCATED 208.44.54.0/24 1239 Sprint 22091 UNALLOCATED 208.46.178.0/24 209 Qwest 22130 UNALLOCATED 208.131.122.0/24 3561 Cable & Wireless USA 22299 UNALLOCATED 208.249.71.0/24 701 UUNET Technologies, 22195 UNALLOCATED 208.252.244.0/24 209 Qwest 22259 UNALLOCATED 208.254.175.0/24 701 UUNET Technologies, 65515 PRIVATE 212.110.142.0/24 5593 CRIS-AS 21040 UNALLOCATED 213.196.128.0/18 702 UUNET Technologies, 22313 UNALLOCATED 216.72.155.0/24 7927 Global One Venezuela 6971 UNALLOCATED 216.105.192.0/20 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.121.224.0/19 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.192.0/21 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.192.0/18 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.200.0/23 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.202.0/23 2914 Verio, Inc. 6971 UNALLOCATED 216.174.204.0/22 2914 Verio, Inc. 6971 UNALLOCATED 216.174.208.0/20 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.232.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.174.240.0/22 2914 Verio, Inc. 22326 UNALLOCATED 216.207.88.0/24 1239 Sprint 22326 UNALLOCATED 216.207.89.0/24 1239 Sprint 6971 UNALLOCATED 216.210.128.0/18 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.210.128.0/17 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.229.96.0/20 2516 Kokusai Denshin Denw Advertised Unregistered Addresses --------------------------------- Network Origin AS Description 128.65.0.0/16 3463 ACES Research Inc 132.0.0.0/10 568 DISO-UNRRA 134.137.0.0/16 400 Headquarters Standard Systems 135.0.0.0/13 10455 Lucent Technologies 137.0.0.0/13 568 DISO-UNRRA 138.94.0.0/16 1 BBN Planet 144.7.0.0/16 701 UUNET Technologies, Inc. 153.34.0.0/15 701 UUNET Technologies, Inc. 153.36.0.0/14 701 UUNET Technologies, Inc. 154.150.0.0/16 6494 IDCI 158.0.0.0/13 568 DISO-UNRRA 164.233.0.0/16 6020 DISA NETWORK SERVICES 164.235.0.0/16 6025 US DOD NIC Unregistered 201.115.100.0/24 7018 AT&T Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:17 /9:5 /10:6 /11:12 /12:33 /13:85 /14:228 /15:383 /16:6972 /17:1231 /18:2347 /19:6950 /20:5822 /21:4773 /22:7029 /23:8963 /24:60843 /25:318 /26:341 /27:259 /28:257 /29:156 /30:185 /31:1 /32:76 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 1221 1459 1608 Telstra Pty Ltd 701 1422 2257 UUNET Technologies, Inc. 3908 771 922 Supernet, Inc. 7046 629 801 UUNET Technologies, Inc. 702 593 881 UUNET Technologies, Inc. 7018 553 1055 AT&T 690 499 502 Merit Network 4293 449 466 Cable & Wireless USA 3967 422 602 Exodus Communication 1 414 871 BBN Planet 1239 407 731 Sprint 2764 373 420 connect.com.au pty ltd 209 371 537 Qwest 703 347 418 UUNET Technologies, Inc. 2048 308 360 State of Louisiana 6995 308 320 Bell Atlantic Internet Soluti 4323 303 361 Time Warner Communications, I 11371 300 313 Rhythms NetConnections 5106 298 316 Ameritech Advanced Data Servi 705 297 341 UUNET Technologies, Inc. Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:6 9:1 12:407 13:10 15:1 17:5 20:1 24:801 25:1 26:1 32:72 33:6 38:10 43:3 44:2 53:2 55:1 57:15 61:77 62:141 63:1929 64:1357 65:712 66:480 67:2 80:51 128:49 129:107 130:18 131:42 132:11 133:2 134:139 135:10 136:21 137:98 138:206 139:45 140:197 141:199 142:56 143:39 144:145 145:13 146:147 147:129 148:130 149:89 150:37 151:323 152:367 153:43 154:16 155:83 156:89 157:73 158:74 159:67 160:48 161:91 162:65 163:145 164:95 165:103 166:188 167:143 168:117 169:39 170:291 171:2 192:5426 193:1953 194:2022 195:830 196:450 198:3638 199:3332 200:2505 201:1 202:2769 203:4574 204:3419 205:2199 206:2902 207:2579 208:3124 209:3132 210:550 211:136 212:859 213:506 214:8 215:13 216:3042 217:387 218:2 End of report

1 0