- routing-wg - mailman.ripe.net

draft minutes RIPE 35 Routing WG session
by SchmitzJo＠aol.com 17 May '00

17 May '00

Minutes Routing-wg @ RIPE 35 Chair : Joachim Schmitz (JS395-RIPE) Scribe : Emil Gorter (EMIL-RIPE) Attenders: 92 A. Preliminaries (Joachim Schmitz) Joachim welcomed the participants, passed around the participants' list, and asked for a volunteer scribe. Emil Gorter volunteered to take the minutes. The working group agreed upon the minutes of the previous meeting, and accepted the agenda circulated earlier on the mailing list. Review of previous actions: o 31.R1 RIPE NCC, D.Kessens, J.Schmitz Basic design for an IPv6 IRR -postponed- Even though this topic is still considered important, there had been not enough input to continue o 32.R1 RIPE NCC, JLS.Damas Prepare draft document on RIPE-181 -> RPSL transition issues -in progress- The draft document is prepared, but not yet publicly available o 34.R1 C.Panigl Provide updates to RIPE-178 -to be closed- Needs to be published B. Report from the RIPE NCC (JLS Damas) The report consisted of two parts: - transition to RPSL - consistency checking of the IRR which were discussed in a combined presentation - Transition to RPSL RPSL will be implemented in the RIPE database software v3.0 which is nearly complete and beta code is available for downloading. The new db can be tested at reimp.ripe.net:43 It will accept no updates, only queries on an almost real time mirror of the current database. It will be tested for 2 months (already started), so testers are welcome to try. Any RPSL object stored in the test database will not be mirrored back into the RIPE-181 production database. Thus, we are still in step one of a three step process: 1. Mirror current db in RPSL 2. Accept updates in RPSL and RIPE-181, RIPE-181 will be converted to RPSL 3. Only accept updates in RPSL For details more information may be found at www.ripe.net/ripencc/pub-services/db/reimp/index.html If there are concerns about the procedures, RIPE NCC would appreciate input to be incorporated in the reimplementation document (action 32.R1). The question arose what happens with any RPSL update done today. They are definitely not visible on the current database. However, it is obvious that during the transition process any test objects in the RPSL part must not be moved into the new RPSL production database. - Consistency Checking of the IRR The goal of the project is to compare BGP data from life Internet to routing information stored in the RIPE IRR, and analyze the results. The input gathered so far will be incorporated in a draft document. This document is expected to become available around RIPE 36. However, it is important to note that the reimplementation effort and the transition to RPSL is run at a higher priority, and this project will only be worked on fully after the reimplementation has been finished. C. RADB/IRRd Update (Gerald Winters) http://www.ripe.net/ripe/meetings/archive/ripe-35/presentations/ripe35-radb… /index.html Gerald gave an overview of the topics presented - recent developments - IRRj - scaling issues - on the horizon which were then discussed in detail. * Recent developments Probably the most important item with regard to the database was that Merit/RADB converted to RPSL which was completed in Nov-99. For two months, in parallel any RIPE-181 updates would overwrite existing RPSL objects. On 1-Jan-2000, RIPE-181 was discontinued, meaning that RADB is now fully and only accepting RPSL. The experience with RPSL is that most users are satisfied, but only very few users actually make use of advanced RPSL features. In a whole it seems that the community still becomes used to RPSL. The second very important topic relates to the organizational structure of RADB. In the past it has been fully subsidized by Merit. Now, Merit is completing the transition to a commercial funding model, which charges a yearly fee to all maintainers registered in RADB. The consequence is that maintainers who do not pay the yearly fee, in the end may be removed from RADB, including all their objects. However, RADB is important, and nobody shall be excluded. People, who do not want to pay fees are therefore encouraged by Merit to open and run their own registries, which is supported by Merit to publish the code of the db software. There is already some interest for this, and Merit will then mirror those who request it. Actually, Merit expects to reduce its role as a database administrator. This statement caused a lot of discussion. Concerns uttered covered - do ISPs need to register in all databases? the answer is no - "private" registries will be mirrored at RADB - how to avoid duplicates then, or correct references (Christian Panigl) this is likely to be a problem; there are some measures taken or under consideration. Merit will definitely start removing old duplicates themselves. It is strongly recommended that when a company starts its own mirrored registry, they should remove their object from RADB. - the existence of duplicates actually is not a new problem, but it will be more difficult to handle if the number of registries explodes? in principle this could be solved by prioritizing registries, which may be difficult thinking of which criteria to use. Therefore, clear criteria must be defined for the "private" registries where to query, and what to store - while prioritization probably solves the question of retrieving data, it does not solve the question of consistency; does the IRR consistency project help here? probably yes, at least as a supportive action; however, getting registry data is also a matter of completeness - who is allowed to open a registry, and who is then allowed to insert, delete, manipulate copies of objects in which registry? in principle, any body may open a registry; however, ownership of objects should not change in this process (AS, route objects). Actually, nobody should be allowed to delete or work on these objects. This may really become a problem if upstream providers decide to set up their own registries, even more for multihomed services. This would require multiple registrations, not necessarily transparent for downstreams. The general feeling was that this development should be very closely observed. - is Merit acting here a bit early with RPS Dist not yet in place? actually, we are currently on the move, starting to develop procedures. It is quite obvious, that someone running a registry being disjoint from the others, the data may not be used for configurations on the Internet, meaning that the corresponding networks will not or will only be reachable partly. This will generate peer pressure to at least mirror each other properly. Nonetheless, at least for small registries, there is a definite need for central support, and most likely also for a resolution authority in cases of dispute. As a general bottom line, it became very much obvious that the Internet is very much differently organized in the US compared to Europe. Much of the problem for Merit is posed by introducing its new funding model, where for RIPE it already exists and is accepted in the community. In the US, the community is much more heterogeneous than in Europe. * Scaling issues Funding is not the only issue, Merit has been working on. The demand of users of the database has risen that much, that scaling has become an issue. The load on the production server has increased that much, that a second one had been introduced, where requests are distributed applying a DNS round robin mechanism. Updates are only done on one machine, requests are handled by both. To handle slow connections, small pipes, or large queries, parts of the software have been adapted to speed up processing. * IRRj A new development is the routing registry tool IRRj, opening another interface to the database. It is programmed in Java, and connection based, in contrast to the usual e-mail interface. It allows fast updates and features a graphical interface, which works more efficiently than updates by e-mail. It is obvious that IRRj can not make use of the "mail from" authentication method, which should be eliminated anyway because it does not supply real authentication (easily forged). The idea is to move to PGP in general. * On the horizon With the projects running and new developments, a list of action items results. Most pressing is an implementation of RPS Dist, allowing distributed databases. Merit is working to get an RPS Dist prototype built which also depends on progress of the corresponding Internet draft. However, it have already been decided that for authentication between the distributed databases, PGP certificates will be used. Another demand from the community is strong authentication/authorization in the database. Accordingly, Merit is considering implementation of the RPS Auth draft. Depending on resources work may commence around mid-summer. Finally, there is some new development on the database software itself. With the help of Global Crossing, a relational database backend is developed, where the TimesTen relational database is used. The work will integrate IRRd in the backend. Resulting code from this project will be open source. The expected advantage of the project consists in higher performance (due to structures intrinsic to the relational database software), allowing relational queries, and better support for the allocation registry functions. D. Routing Information Service Status and Plans (Ripe NCC) Henk Uijterwaal http://www.ripe.net/ripe/meetings/archive/ripe-35/presentations/ripe35-ris-… k/ Details of this report are available at the url specified above. In addition the RIS project has its own web pages at http://www.ripe.net/ripencc/pub-services/np/ris-index.html The goal of RIS is to collect default-free BGP data with timestamps, to give a current and historical view of the Internet routing table. The user interface will have the feel of a looking-glass "with memory". Once deployed, RIS will also be used for consistency checking of the routing registry. The setup consists of major data collectors at major exchange points, which transmit the data to a central collector and database at the RIPE NCC. Since Oct-99 the first test version is in use. However, there are still a few items which need to be taken care of like - open questions in the draft RIS document (RIPE-200) - the hardware for the final setup must still be ordered - consider process of data collection and storage, especially with regard to the high data volume The prototype currently implemented is available at http://abcoude.ripe.net/ris/risalpha.cgi A demonstration was available in the terminal room. The current setup consists of one collector at AMSIX, and one machine for storage and running the database. At AMSIX, currently 12 peering relationships are active. Data volume collected is around 40 MBytes per peer and per day. The total peering relationships are probably going to be increased to around 70. Collected are BGP IPv4 announcements and withdrawals with all BGP attributes. The collector sends updates to the central collector daily - this frequency may be increased in the future. Some results derived so far show - there is a very high number of updates per day, which seems to indicate a high level of instability; however at the same time the number of withdrawals is very low - the more peers we are looking at, the more prefixes are visible which is interesting because we expect that some upper limit of prefixes should be reached relatively fast (the full Internet routing table); since they do not appear on the Internet routing table, these addtl prefixes are called "dark prefixes"; the question is whether this effect results just from more specifics being visible which are otherwise simply aggregated - this statement is supported by the finding that more than 50% of the prefixes are /24 Besides these statistics, RIS will enable to find out who routes what when. On top of this, flap-statistics may be generated. Suggestions on additional usage is very much welcome from the audience. The development is on schedule, a demo is available. Plans are built on the actions indicated above, comprising implementation details, and including more peerings. The basic question in the end how to turn this into a regular service will be answered after these preliminaries are resolved. There was input from the audience, that similar things have already been done in other areas of the world (e.g. a project at Merit). Results and experience will be shared. With these presentations the first slot of the meeting was closed. E. Multicast Routing The second slot of the Routing WG meeting was dedicated to Multicast Routing, more precisely to show how providers have deployed it or are planning to do it. This includes both backbone and Internet service providers, and public exchange points. Not all of the presentations are available yet, but will become available on the RIPE NCC web server soon. * Reports from Backbones There are two prominent pan-European backbone providers: TEN-155 for the education/research community, and the commercial Ebone network. For both the current status, experience, and some plans were presented. The TEN-155 multicast setup was presented by Jan Nowak. Due to the different demands, levels of development, or specific implementations, the network structure is highly heterogeneous. Quite a lot of problems result from this. It was also recognized that some elements of multicast are very sensitive to frame/cell/packet loss (depending on the under lying carrier protocol). In contrast, Peter Lothberg showed that Ebone is using native multicast (avoiding any tunnels), only employing sparse mode, avoiding MHRSP which removes problems like ghosting issues. MSDP is very much favored. The result is a very clearly structured homogeneous network, which is easy to manage and configure. The design includes backup scenarios with redundant RPs to circumvent router failures. * Reports from Public Exchange Points Peter Lothberg immediately continued with his presentation on multicast routing on the Stockholm DGIX. He gave some general design rules, and shared his thoughts and experience. It was interesting to note that DPT rings based on dark fiber are used for both unicast and multicast. Niels den Otter followed with his presentation on the plans, AMSIX has to add multicast (Amsterdam Internet Exchange). They are still in the planning phase. According to Steve Walker, the LINX (London Internet Exchange) is already a step further down the road: even though they are still in the developing phase, they already have a testbed running with several multicast feeds. On the one hand, more multicast feeds are expected, and the LINX wants to switch to production sometime during year 2000. It is interesting to note that both AMSIX and LINX are deploying multicast on separate hardware, keeping it away from their unicast exchange infrastructure. However, on the Stockholm DGIX unicast and multicast are run on a common shared infrastructure. * Reports from Active ISP Networks Originally, there were reports planned from three networks. Unfortunately, Peter Heiligers on very short notice could not join the meeting, and thus the report from DFN was dropped. The two remaining reports from Renater by Bernard Tuy and on Surfnet by Niels den Otter showed the same situation like described for the backbone networks. Renater has started relatively early with the French Multicast Backbone (FMbone), and thus for historical reasons there are still various protocols in use, and the network has been running on dense mode. When the network grew, configuration with all the filters required became just too complex. Therefore, Renater is now moving to sparse mode, and will reduce the number of protocols used in their network. Surfnet has also tested a few protocols, but for final implemenation is adopting a model similar to Ebone, with PIM sparse mode throughout, MSDP with backup RPs etc. The Surfnet multicast backbone will be congruent to the unicast network, using the same routers. Y. General I/O with other WGs There has been no immediate I/O with other WGs. Z. AOB There was no AOB for this working group session. Joachim announced that there will be held a multicast tutorial during the next RIPE meeting in Budapest. --- Agenda ------ R I P E 3 5 A M S T E R D A M Routing Working Group Session 24-February-2000 Draft Agenda A. Preliminaries (Joachim Schmitz) (5min) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 34 minutes - actions from earlier meetings B. Report from the RIPE NCC (JLS Damas) - transition to RPSL (15min) - consistency checking of the IRR (5min) C. Report on the IRR at RADB (Gerald Winters) (20min) D. Report on RIS (RIPE NCC) (20min) E. Multicast Routing - reports from backbones * TEN-155 * Ebone - reports from exchange points (15min each) * Stockholm D-GIX * AMS-IX * LINX - reports from active networks (15min each) * Renater * DFN (skipped) * SURFnet Y. General I/O with Other WGs Z. AOB Summary of open Action Points ----------------------------- 31.R1 on RIPE NCC, D.Kessens, J.Schmitz Basic design for an IPv6 IRR - postponed - 32.R1 on RIPE NCC, JLS.Damas Prepare draft document on issues of RIPE-181 to RPSL transition - in progress - 34.R1 on C.Panigl Provide update to RIPE-178 - in progress - Emil Gorter, Joachim Schmitz, May-2000

1 0

The Cidr Report
by Tony Bates 12 May '00

12 May '00

This is an auto-generated mail on Fri May 12 12:00:00 PDT 2000 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 12May00 0) General Status Table History ------------- Date Prefixes 080400 75151 090400 75137 100400 75215 110400 75403 120400 75730 130400 75919 010500 76182 020500 76265 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: 5027 Number of ASes announcing only one prefix: 1865 (0 cidr, 1865 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 1002 announced by AS701 1) Gains by aggregating at the origin AS level --- 12May00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 437 152 285 65.2% BCnet Backbone AS7046 500 336 164 32.8% COQUI-NET PRTC Internet AS9269 167 29 138 82.6% Hong Kong CTI AS9706 153 26 127 83.0% Pusan Metropolitan City Office of AS1221 529 408 121 22.9% TELSTRA-AS AS2609 123 18 105 85.4% EUnet-TN AS7545 164 66 98 59.8% TPG Internet Pty Ltd AS7657 264 168 96 36.4% The Internet Group Limited AS174 552 464 88 15.9% Performance Systems International AS7496 126 39 87 69.0% Power Up AS9304 109 24 85 78.0% Hutchcity AS9557 100 17 83 83.0% Pakistan Telecommunication Compan AS6429 204 121 83 40.7% RDC-INTERNET AS577 248 172 76 30.6% Bell Backbone AS7029 146 71 75 51.4% ALLTELNET AS209 463 392 71 15.3% Qwest Communications AS7018 529 463 66 12.5% AT&T WorldNet Service Backbone AS1727 162 98 64 39.5% MRMS-WEST AS4293 253 190 63 24.9% Internal ASN for C&W AS724 205 143 62 30.2% DLA-ASNBLOCK-AS AS7260 111 50 61 55.0% NORLIGHT AS705 270 209 61 22.6% ALTERNET-AS AS3749 121 61 60 49.6% TECNET AS3602 307 249 58 18.9% Sprint Canada Inc. AS6595 107 50 57 53.3% DODDSEUR AS4740 336 279 57 17.0% Ozemail Pty Ltd (ASN-OZEMAIL) AS5106 81 29 52 64.2% AADS-COLUMBUS AS7568 63 18 45 71.4% C.S. Communications Co., Ltd. AS816 308 266 42 13.6% UUNET Canada (ASN-UUNETCA-AS4) AS6528 48 6 42 87.5% WORLD-LYNX 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

RIPE NCC Region Weekly Routing Report
by Routing Analysis 11 May '00

11 May '00

This is an automated weekly mailing sent to the RIPE Routing WG e-mail list describing the state of the Internet Routing Table in Europe, Middle East and North Africa. 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>. Europe, Middle East, North Africa Report 12 May, 2000 Analysis Summary ---------------- BGP routing table entries examined: 78765 Origin ASes present in the Internet Routing Table: 7433 Origin ASes announcing only one prefix: 2419 Transit ASes present in the Internet Routing Table: 1044 Average AS path length visible in the Internet Routing Table: 5.2 Max AS path length visible: 13 Illegal AS announcements present in the Routing Table: 9 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 4 Number of addresses announced to Internet: 1156696982 Equivalent to 68 /8s, 241 /16s and 203 /24s Percentage of available address space announced: 31.2 Percentage of allocated address space announced: 62.9 Percentage of available address space allocated: 49.6 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 12630 Prefixes being announced from the RIPE address blocks: 9690 RIPE Region origin ASes present in the Internet Routing Table: 1982 RIPE Region origin ASes announcing only one prefix: 929 RIPE Region transit ASes present in the Internet Routing Table: 382 Average RIPE Region AS path length visible: 5.8 Max RIPE Region AS path length visible: 13 Number of RIPE addresses announced to Internet: 69512741 Equivalent to 4 /8s, 36 /16s and 174 /24s Percentage of available RIPE address space announced: 69.1 RIPE AS Blocks 1877 - 1901, 2042, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 RIPE Address Blocks 62/8, 193/8, 194/7 and 212/7 RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 3301 381 272 TeliaNet Sweden 1257 330 267 Swipnet AB 1270 258 411 UUNET Germany 1275 236 1149 DFN IP Service 1849 236 484 PIPEX 786 181 959 JANET IP Service 719 179 145 LANLINK 5515 167 355 Sonera Finland 517 163 200 Xlink 3320 153 245 Deutsche Telekom AG 2609 127 4 EUnet-TN 3303 126 303 Swisscom 2856 125 271 BTnet UK Regional network 13019 119 20 RR-BRETAGNE Autonomous System 1267 109 819 IUnet S.p.A 9057 90 26 Level 3 public IP n 1901 88 74 EUnet Austria 3215 88 118 RAIN 1290 85 195 PSINet UK Ltd. Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 1921 3302 UUNET Technologies, Inc. 7018 1163 3032 AT&T 1 867 4615 BBN Planet 7046 804 459 UUNET Technologies, Inc. 1221 802 975 Telstra 1239 732 1633 Sprint ICM-Inria 2914 732 1239 Verio, Inc. 3561 691 1601 Cable & Wireless USA 174 653 2842 PSINet Inc. 209 650 698 Qwest 271 469 411 BCnet Backbone 2764 452 112 connect.com.au pty ltd 705 449 24 UUNET Technologies, Inc. 3549 435 340 Frontier GlobalCenter 3602 435 77 Sprint Canada 1785 404 848 Sprint ICM 4740 402 83 Ozemail 1740 398 625 CERFnet 3301 381 272 TeliaNet Sweden List of Illegal AS's (Global) ----------------------------- Bad AS Designation Network Transit AS Description 64512 PRIVATE 62.31.0.0/19 5462 Cable Internet Ltd 65530 PRIVATE 63.179.128.0/24 4999 Sprint 65530 PRIVATE 63.179.142.0/24 4999 Sprint 65530 PRIVATE 63.179.190.0/24 4999 Sprint 65530 PRIVATE 63.179.191.0/24 4999 Sprint 65530 PRIVATE 63.179.230.0/24 4999 Sprint 65530 PRIVATE 63.179.249.0/24 4999 Sprint 64602 PRIVATE 63.236.57.0/24 209 Qwest 64601 PRIVATE 63.236.90.0/24 209 Qwest Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 39.96.40.224/30 14408 iCAIR 109.177.9.0/24 1785 Sprint ICM 219.91.160.0/22 7742 InternetNow, Inc. 219.91.164.0/23 7742 InternetNow, Inc. Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:23 /9:5 /10:5 /11:9 /12:26 /13:48 /14:162 /15:278 /16:6447 /17:814 /18:1612 /19:5204 /20:3043 /21:3348 /22:4920 /23:6690 /24:45536 /25:129 /26:165 /27:67 /28:38 /29:48 /30:86 /31:0 /32:62 End of report

1 0

Top 100 Maintainers List 20000509
by RIPE Database Administration 09 May '00

09 May '00

1 0

1st draft agenda routing wg session RIPE36
by SchmitzJo＠aol.com 08 May '00

08 May '00

Dear colleagues, please find enclosed the first draft of the agenda for the session of the routing working group at RIPE 36, Budapest. The session will be held Wednesday, 17-May, 14:00 Routing WG session As announced previously, I would also like to point out that this time we have organized a tutorial on multicast, which will be held Tuesday, 16-May, 10:00 multicast tutorial Details of this tutorial will become available shortly. As usual comments, additions, welcome! --- R I P E 3 6 B U D A P E S T Routing Working Group Session 17-May-2000 Draft Agenda A. Preliminaries (Joachim Schmitz) (5min) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 35 minutes - actions from earlier meetings B. Transition to RPSL (Andrei Robachevski, Joao Luis Silva Damas) (20min) C. RIS, Status and Plans (Antony Antony, Henk Uijterwaal) (20min) D. The Problem with BGP Convergence (Abha Ahuja, Craig Labovitz) (20min) E. A New Network Pathology Study (Avi Freedman) (20min) (to be confirmed) F. Some Words on Multicast Experience (Steve Noble) (20min) (to be confirmed) Y. General I/O with Other WGs Z. AOB --- Regards Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

RIPE NCC Region Weekly Routing Report
by Routing Analysis 04 May '00

04 May '00

This is an automated weekly mailing sent to the RIPE Routing WG e-mail list describing the state of the Internet Routing Table in Europe, Middle East and North Africa. 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>. Europe, Middle East, North Africa Report 05 May, 2000 Analysis Summary ---------------- BGP routing table entries examined: 77213 Origin ASes present in the Internet Routing Table: 7325 Origin ASes announcing only one prefix: 2386 Transit ASes present in the Internet Routing Table: 1031 Average AS path length visible in the Internet Routing Table: 5.2 Max AS path length visible: 13 Illegal AS announcements present in the Routing Table: 7 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 5 Number of addresses announced to Internet: 1155938913 Equivalent to 68 /8s, 230 /16s and 58 /24s Percentage of available address space announced: 31.2 Percentage of allocated address space announced: 62.8 Percentage of available address space allocated: 49.6 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 12593 Prefixes being announced from the RIPE address blocks: 9656 RIPE Region origin ASes present in the Internet Routing Table: 1963 RIPE Region origin ASes announcing only one prefix: 924 RIPE Region transit ASes present in the Internet Routing Table: 379 Average RIPE Region AS path length visible: 5.8 Max RIPE Region AS path length visible: 13 Number of RIPE addresses announced to Internet: 68448848 Equivalent to 4 /8s, 20 /16s and 114 /24s Percentage of available RIPE address space announced: 68.0 RIPE AS Blocks 1877 - 1901, 2042, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 RIPE Address Blocks 62/8, 193/8, 194/7 and 212/7 RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 3301 378 272 TeliaNet Sweden 1257 329 266 Swipnet AB 1270 257 410 UUNET Germany 1275 233 1140 DFN IP Service 1849 232 483 PIPEX 5515 188 311 Sonera Finland 719 178 129 LANLINK 786 176 911 JANET IP Service 517 162 200 Xlink 3320 150 229 Deutsche Telekom AG 3303 126 303 Swisscom 2609 125 4 EUnet-TN 2856 120 255 BTnet UK Regional network 13019 119 20 RR-BRETAGNE Autonomous System 1267 109 819 IUnet S.p.A 3215 89 118 RAIN 9057 89 26 Level 3 public IP n 1901 88 74 EUnet Austria 2874 84 84 Global One Services Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 1885 3286 UUNET Technologies, Inc. 7018 1141 3039 AT&T 1 850 4575 BBN Planet 1221 800 975 Telstra 7046 791 434 UUNET Technologies, Inc. 2914 771 1268 Verio, Inc. 1239 729 1625 Sprint ICM-Inria 3561 683 1598 Cable & Wireless USA 209 659 692 Qwest 174 652 2834 PSINet Inc. 271 469 411 BCnet Backbone 2764 450 112 connect.com.au pty ltd 3549 434 342 Frontier GlobalCenter 3602 423 77 Sprint Canada 705 410 22 UUNET Technologies, Inc. 1785 404 848 Sprint ICM 1740 394 607 CERFnet 4740 392 82 Ozemail 3301 378 272 TeliaNet Sweden List of Illegal AS's (Global) ----------------------------- Bad AS Designation Network Transit AS Description 65530 PRIVATE 63.179.128.0/24 4999 Sprint 65530 PRIVATE 63.179.142.0/24 4999 Sprint 65530 PRIVATE 63.179.190.0/24 4999 Sprint 65530 PRIVATE 63.179.191.0/24 4999 Sprint 65530 PRIVATE 63.179.249.0/24 4999 Sprint 64602 PRIVATE 63.236.57.0/24 209 Qwest 64601 PRIVATE 63.236.90.0/24 209 Qwest Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 39.96.40.224/30 14408 iCAIR 109.177.9.0/24 1785 Sprint ICM 197.138.137.0/24 2914 Verio, Inc. 219.91.160.0/22 7742 InternetNow, Inc. 219.91.164.0/23 7742 InternetNow, Inc. Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:24 /9:4 /10:5 /11:9 /12:27 /13:47 /14:160 /15:272 /16:6355 /17:803 /18:1571 /19:5128 /20:2995 /21:3308 /22:4837 /23:6599 /24:44501 /25:126 /26:158 /27:61 /28:36 /29:47 /30:84 /31:1 /32:55 End of report

1 0

Re: The Cidr Report
by brandon＠rd.bbc.co.uk 01 May '00

01 May '00

> over 2500 routes could be removed from the routing table or make room for 2500 of those long prefixes nobody wants to accept > this is pretty embarrassing for the operator community. Only when size of table is used as an excuse to not let longer prefixes be used, instead causing more address space to be used to get by those filters. regards brandon

5 4

RIPE NCC Region Weekly Routing Report
by Routing Analysis 27 Apr '00

27 Apr '00

This is an automated weekly mailing sent to the RIPE Routing WG e-mail list describing the state of the Internet Routing Table in Europe, Middle East and North Africa. 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>. Europe, Middle East, North Africa Report 28 Apr, 2000 Analysis Summary ---------------- BGP routing table entries examined: 77946 Origin ASes present in the Internet Routing Table: 7317 Origin ASes announcing only one prefix: 2382 Transit ASes present in the Internet Routing Table: 1028 Average AS path length visible in the Internet Routing Table: 5.2 Max AS path length visible: 13 Illegal AS announcements present in the Routing Table: 7 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 4 Number of addresses announced to Internet: 1131462760 Equivalent to 67 /8s, 112 /16s and 192 /24s Percentage of available address space announced: 30.5 Percentage of allocated address space announced: 61.5 Percentage of available address space allocated: 49.6 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 12569 Prefixes being announced from the RIPE address blocks: 9756 RIPE Region origin ASes present in the Internet Routing Table: 1971 RIPE Region origin ASes announcing only one prefix: 938 RIPE Region transit ASes present in the Internet Routing Table: 380 Average RIPE Region AS path length visible: 5.8 Max RIPE Region AS path length visible: 13 Number of RIPE addresses announced to Internet: 68970729 Equivalent to 4 /8s, 28 /16s and 104 /24s Percentage of available RIPE address space announced: 68.5 RIPE AS Blocks 1877 - 1901, 2042, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 RIPE Address Blocks 62/8, 193/8, 194/7 and 212/7 RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 3301 381 272 TeliaNet Sweden 1257 328 265 Swipnet AB 1270 251 401 UUNET Germany 1275 233 1140 DFN IP Service 1849 229 475 PIPEX 786 181 959 JANET IP Service 719 179 145 LANLINK 517 163 200 Xlink 5515 154 318 Sonera Finland 3320 147 241 Deutsche Telekom AG 3303 126 303 Swisscom 2609 124 4 EUnet-TN 2856 123 271 BTnet UK Regional network 1267 109 819 IUnet S.p.A 1901 88 74 EUnet Austria 3215 87 118 RAIN 9057 87 26 Level 3 public IP n 2874 84 84 Global One Services 1290 83 195 PSINet UK Ltd. Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 1866 3285 UUNET Technologies, Inc. 7018 1154 3063 AT&T 1 858 4584 BBN Planet 1221 779 1134 Telstra 209 774 709 Qwest 7046 769 425 UUNET Technologies, Inc. 1239 722 1647 Sprint ICM-Inria 2914 718 1146 Verio, Inc. 3561 680 1622 Cable & Wireless USA 174 640 2840 PSINet Inc. 271 470 411 BCnet Backbone 2764 450 112 connect.com.au pty ltd 3602 436 77 Sprint Canada 3549 431 342 Frontier GlobalCenter 1785 400 848 Sprint ICM 1740 399 631 CERFnet 4740 399 83 Ozemail 705 397 22 UUNET Technologies, Inc. 816 385 179 UUNET Canada4 List of Illegal AS's (Global) ----------------------------- Bad AS Designation Network Transit AS Description 65530 PRIVATE 63.179.128.0/24 4999 Sprint 65530 PRIVATE 63.179.142.0/24 4999 Sprint 65530 PRIVATE 63.179.190.0/24 4999 Sprint 65530 PRIVATE 63.179.191.0/24 4999 Sprint 65530 PRIVATE 63.179.249.0/24 4999 Sprint 64602 PRIVATE 63.236.57.0/24 209 Qwest 64601 PRIVATE 63.236.90.0/24 209 Qwest Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 39.96.40.224/30 14408 iCAIR 197.138.137.0/24 2914 Verio, Inc. 219.91.160.0/22 7742 InternetNow, Inc. 219.91.164.0/23 7742 InternetNow, Inc. Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:22 /9:4 /10:5 /11:9 /12:27 /13:49 /14:164 /15:275 /16:6448 /17:798 /18:1576 /19:5168 /20:3008 /21:3331 /22:4846 /23:6622 /24:44988 /25:131 /26:168 /27:58 /28:39 /29:46 /30:97 /31:1 /32:66 End of report

1 0

Top 100 Maintainers List 20000425
by RIPE Database Administration 25 Apr '00

25 Apr '00

1 0

Re: The Cidr Report
by Vince Fuller 21 Apr '00

21 Apr '00

> boys and girls, over 2500 routes could be removed from the routing > table just by a little cleanliness and responsibility. this is pretty > embarrassing for the operator community. Note also that the recent (say over the last year or so) trend in the graph sure looks to be super-linear, which should be cause for concern. --Vince

1 0