- routing-wg - mailman.ripe.net

Re: Minutes of the Routing WG session (first draft)
by Brian Renaud 17 Oct '95

17 Oct '95

> A C T I O N on Brian Renaud: Making the transparencies of his presentation > of the RA Project publicly available (both on the Merit and the RIPE FTP/ > WWW servers) The postscript is now available at: ftp://ftp.ra.net/routing.arbiter/radb/presentations/RIPE-22_renaud_routing.… the compressed version is at: ftp://ftp.ra.net/routing.arbiter/radb/presentations/RIPE-22_renaud_routing.… z -Brian

1 0

Server updates for WWWhois
by Paolo Bevilacqua 16 Oct '95

16 Oct '95

Hello, As requested at the last WG meeting, i'm going to complete the list of the whois servers supported by the Web interface that is available at: http://black.uni.net/cgi-bin/whois After this step you're welcome to install this script at your site. Please mail me about the known servers and the associated email address for updates.

1 0

Minutes of the Routing WG session (first draft)
by Schmitz＠RUS.Uni-Stuttgart.DE 16 Oct '95

16 Oct '95

Routing WG M I N U T E S Thursday, 12-10-95, 9:00 - D R A F T - (additions/corrections welcome) Chairman Jan Willem Scheun was ill. Rob Blockzijl volunteered as temporary chairman for this specific session. There was no draft agenda. It was set up on the fly with three topics 1. The RA Project a presentation by Brian Renaud (Merit) 2. The RIPE Routing Registry an overview by Daniel Karrenberg (RIPE NCC) 3. RIPE Routing Registry, R & D overview by Daniel Karrenberg (RIPE NCC) There were no additions from the audience. 1. The Routing Arbiter Project presentation by Brian Renaud (Merit) After filling in the historical background an overview was given of the transition from the old NSFNET PRDB to the new RADB and a description of the current situation including Route Servers and some current data from the present RADB. Then the current initiatives were presented, e.g. continued clean-up of the database, generation of usage and analytical reports, support for RSPL extensions, and support for PGP authentication (with a trial setup running at the moment). Afterwards, Brian Renaud gave a review of the tools recently developed at the RA Project. There are several tools which handle, e.g. configuration from the database policy generator from configuration monitoring of running networks These tools are now not only developed for the Router Servers (which are Sun Workstations) but also for Cisco Routers. There are also various tools under development which among other things feature a GUI for selected tasks. Brian Renaud wants input on the tools from anybody who wants to use them or has contributions/suggestions. Mail addresses are on the transparencies which will be made available soon. A C T I O N on Brian Renaud: Making the transparencies of his presentation of the RA Project publicly available (both on the Merit and the RIPE FTP/ WWW servers) 2. The RIPE Routing Registry Daniel Karrenberg only had a few remarks - The RIPE database is cleaned up from obsolete data. In most cases the responsible persons are directly contacted - The data in the registry are compared to the real world - Tools for the router configuration from the database are most valuable. The NCC wants to make the Merit tools better known in Europe and wants to participate in their development (see below) and immediately opened the discussion. The topis were: - How to handle changes with large numbers of objects (both RADB, RIPE)? They may be done using the automatical machine interface or by submission to the human interface by personal mail (especially for global changes). - Is the RADB publicly available like the RIPE database? It may be fetched via FTP from the Merit server. However, it may be made available on the RIPE server. They mirror it anyway. A C T I O N on the RIPE NCC and Merit: making the RADB publicly available on the the RIPE FTP server (if Merit concords) - What is the status of the advisory tag? The advisory is not yet obsolete. ANS still needs it for operation. For European ISPs advisories are only necessary in the RIPE database. There is no encouragement to register in more than one registry because of the planned GRR which is under construction. A C T I O N on the RIPE NCC: find a FINAL date together with ANS when to give up advisory tags. This was especially stressed by Daniel Karrenberg. - Do ISPs register in the RIPE database? They do not only register but surprisingly many also maintain their data. This is enforced by the RIPE NCC a bit which makes registration of a routing policy mandatory when registering a new AS. There is a general feeling that many more will register and maintain data if proper tools exist to make it easier. Data on the database population will be made available again (as it was done in the PRIDE project). The quality of the data will be checked by RIPE NCC (whether data are updated, consistent, correct...) - There was some discussion on authentication, PGP, and cryptography, mostly related to the RADB as first implementation and future ideas for the RIPE database. PGP authentication by signature is formally a simple new value of the "auth"-tag in the maintainer object (RADB test suite). However, the PGP keys must be savely stored at the database site. There was some discussion on how to do this (in or out of the database). From the experience of both RIPE NCC and Merit there were only very few attempts to willingly change objects of other parties when not being allowed to. They were all detected through the notification facility (which is the same for RADB and RIPE database because the same database manager code is used). Therefore, it does not seem to be necessary to have strong authentication (or even cryptography). However, some organisations like PTTs have stronger security demands and ask for it. They would not register without. 3. RIPE Routing Registry, R & D Rob Blockzijl points out that the RIPE NCC wants to enforce R & D again. Daniel Karrenberg states that the RA people do more for the progress than the RIPE NCC. The RIPE NCC and the Routing WG should/want to do more. A focus should be found to make information in the routing databases significantly more useful. A first step had been taken by development of diagnostic tools in the PRIDE project. This effort should be extended not only on diagnose but also on tools for configuration and real time analysis and monitoring. There are other fields which should be considered but these are the most important. More useful architectural work should be done and one area should be chosen to join the efforts of the RA project group. The following discussion in the audience did not lead to a final conclusion on which area to chose. Therefore, two actions are placed on the RIPE NCC: A C T I O N on the RIPE NCC (Daniel Karrenberg): to trigger the discussion on the mailing list of the Routing WG, which focus to choose for a future tool development project and to come to concensus on it. A C T I O N on the RIPE NCC (Daniel Karrenberg): based upon the focus found in the Routing WG to prepare a draft paper for the new project and to present it at the next RIPE meeting in January. Scribe: Joachim Schmitz, DFN-NOC ---------- If I forgot anything or did not record something correctly just send me your additions/corrections. Thank You! Regards Joachim Schmitz _______________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)rus.uni-stuttgart.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5576 voice Allmandring 30 ++ 711 678 7626 FAX D-70550 Stuttgart FRG (Germany) _______________________________________________________________________________

1 0

PGP authentication for the RADB (fwd)
by Elise Gerich 07 Sep '95

07 Sep '95

several folks have asked me to forward information from the routing arbiter project that would be of broader interest. thought you all might like to know about our pgp key plans (i think that jean-michel asked about this at the last ripe meeting.) --elise >Brian Renaud writes: > From nanog-request(a)MERIT.EDU Thu Sep 7 11:52:50 1995 > Resent-Date: Thu, 7 Sep 1995 11:52:39 -0400 > Message-Id: <199509071552.LAA21225(a)home.merit.edu> > From: Brian Renaud <renaud(a)MERIT.EDU> > To: nanog(a)MERIT.EDU > Subject: PGP authentication for the RADB > Reply-To: renaud(a)MERIT.EDU > Date: Thu, 07 Sep 1995 11:52:31 -0400 > Sender: renaud(a)MERIT.EDU > Resent-Message-ID: <"obcC1.0.5z.2LnJm"@merit.edu> > Resent-From: nanog(a)MERIT.EDU > X-Mailing-List: <nanog(a)MERIT.EDU> archive/latest/24 > X-Loop: nanog(a)MERIT.EDU > Precedence: list > Resent-Sender: nanog-request(a)MERIT.EDU > > > The RADB now supports authentication using PGP-based digital signatures. > If you want to use this feature, there are three things you must do: > > * Register your public key with the RA. > > * Modify your maintainer object to reflect your use of digital > signatures > > * Sign (via PGP) your RADB transactions. > > > 1. Registering your public key with the RA. > > You must send your public key to the RA for inclusion onto our PGP > keyring. Use the "pgp -kxa" command to generate a copy of your public > key suitable for mailing, then mail the resultant file to > db-admin(a)ra.net. > > For example: > > % pgp -kxa smith(a)ra.net pubkey > ... > % mail -s 'please register my public key' db-admin(a)ra.net < pubkey.asc > > > > You may use one of two methods of verification: > > * Fax a copy of a photographic identification (passport or drivers license) > to: > > RADB public key verification > +1 313 747 3185 > > please write your PGP fingerprint and email address on the fax > > * Attend an RA sponsored key signing session at NANOG or IETF. You > will need to bring a copy of your public key with a PGP fingerprint > and photo identification. (This will be verification via the > identification you bring, rather than having two other people agree > that you are who you say you are.) > > We will be holding a key signing at NANOG on Monday, September 11 at > 5:00. If that time is not convenient, you can also accost RA team > members at random and present them with with the appropriate > information. > > > 2. Modifications to the maintainer object > > There is a new authentication option for the maintainer object. The > syntax for it is: > > auth: PGP-FROM {PGP User Id} > > For example, > > auth: PGP-FROM John Smith <smith(a)ra.net> > > > 3. Signing your RADB transactions > > You will need to PGP-sign each transaction you send to > auto-dbm(a)ra.net. Use the "pgp -sta" command to do this. > > For example: > > % pgp -sta -u smith(a)ra.net routes > ... > % mail -s 'route updates' auto-dbm(a)ra.net < routes.asc > >

1 0

RA Service at Sprint Nap
by Elise Gerich 18 Aug '95

18 Aug '95

The Routing Arbiter Service is pleased to announce it is fully in production at the Sprint NAP. Two route servers are installed at the Sprint Nap to provide redundancy, and the route servers are configured daily. The route server configurations are based on the routing policy information stored in the Internet Routing Registry. The IRR contains the full set of data from five databases: Routing Arbiter Database, RIPE Database, internetMCI Database, CA*net Database, and ANSnet Database. For more information about the RA Service check http://www.ra.net or to use the RA Service at the Sprint Nap, send mail to ra-peer(a)ra.net --Elise

1 0

routing minutes - draft - ripe21
by Willem van der Scheun 31 May '95

31 May '95

Here are the draft minutes of the routing WG held at the 21th RIPE meeting in Rome. Please give your comments, if any, before June 9. DRAFT -- DRAFT -- DRAFT -- DRAFT -- DRAFT -- DRAFT -- DRAFT -- DRAFT -- Routing Working Group Minutes RIPE 21 Rome, May 8, 1995 Chairman: Willem v.d. Scheun ---------------------------- 1. Opening and agenda bashing Willem v.d. Scheun opened the session and welcomed everyone to the meeting. The agenda was agreed with some scheduling changes which will be reflected in the minutes. 2. Minutetaker Anne Lord volunteered to take the minutes. 3. Status of the Route Arbiter project, Elise Gerich, Merit 3.1 PRDB -> RADB transition. There was much discussion during and following Elise's presentation. The main points are: - May 8th (day of WG meeting) is the last day that NACR's will be accepted by Merit. After this date, old style NACR's will automatically be translated into ripe-181 compliant route objects. Objects should be sent to : <auto-dbm(a)ra.net> - If you have registrations in the PRDB your data will automatically be converted. - If you require connectivity to AS690 you will need to register your route in the RADB using the "advisory" tag. As AS690 config files are currently generated from the RADB only. - The "advisory" tag replaces the old-style NACRS but will be short term only The end of May was mentioned as the "short-term". - Global IRR schema means that registering in one RR should be sufficient. However, registering in more than one database will be allowed but not encouraged. Problem of determining priority when there are conflicts in RR data is still not solved. Question was asked concerning how to remove duplicates once priority issue was resolved? There was some discussion, but the problem has yet to be resolved. 3.2 RA Project Project began on July 1st, 1994 as collaboration between Merit, ISI (and IBM). ISI and IBM are responsible for the software development of the Route Server and advanced protocol development. Merit is responsible for development and maintenance of the RADB, network management and routing engineering. Current status: - 6 route servers (RS) are deployed: o 2 Mae East o Sprint NAP o Ameritech o PacBell o Mae West (not fully operational) - Main interconnection-point effort is focussed on Mae East. o 15 ISP's present o 11 peering with primary RS and backup o 6 import and exporting routes from RS. o none is yet fully dependant on RS. o only problems reported have been from Sprint. Elise reported that for the last 10 months RSes have been operational, although the fact has not been communicated since more network management tools were needed and the NOC does not yet have out of band access to the RSes. - Network Management Area development o deployed bi-lingual SNMP agent v.2 o Discovery Rover code - reports on state and topology of net. - NOC formerly ANS, now Merit, University of Michigan. - RADB is implementation of ripe-181. Some extensions to the syntax were necessary. Specifically there are now attributes: o extended-interas-in o entended-interas-out - PGP v.2.6 email authentication added. Development work done by Laurent Joncheray. Description of the mechanism can be found at: o http://www.ra.net o ftp://ftp.ra.net/routing-arbiter/tools/RAToolSet - Software development by Cengiz Alaettinoglu on tools that generate config files for ripe-181 policy expressions. Tools are (available from above URL's): o rtconfig o toolkit There was a question concering duration of project and available resources. The RA project is a 5 year project which will terminate in 1999. 14 people are working on the project. All the software is public domain. 4. Report on the population and usage of the routing registry - RIPE NCC - Maintainence of the RR is a RIPE NCC core activity. - Little time for actual work to date - current resources are 1 hour per day from Mirjam Kuehne and Anne Lord. - 3 stage workplan developed based on BGP dump of amsterdam.ripe.net o chase non-registrations of ripe-181 policy of EU ASes -> nag. o extract AS path and compare with registered policy -> nag. o develop tools to do above work auto-magically Comments: - Question concerning the consistency of route objects and the home AS. Is this part of the RR activity? Answer was yes, but focus of effort prioritised to above. - Registering in the RIPE RR is vital. When "advisory" tag goes away, some EU networks not registered may lose some connectivity. - Ideal end state is to register in one RR only. This should be sufficient for full connectivity. - Should be free (but not encouraged) to make multiple registrations. Currently some RR's require this (MCI & RADB). Seen as short-term (+/- 2 weeks). Advice for now is to make multiple registrations. - Currently RR's mirror each others databases. RIPE NCC will monitor dual registrations. 5. Routing Policy System (RPS) - Importance of ripe-181 acknowledged as document has become rfcxxxx standards track document. - IETF working group formed o rps - Charter o to develop a routing policy description language based on ripe-181. o co-ordinate efforts of various RR's - Co-chaired o Cengiz Alaettinoglu o Daniel Karrenberg. - Mailing list establised. To subscribe send mail to o <rps(a)isi.edu> o <rps-request(a)isi.edu> 6. CIDRD wg report (Danvers IETF) - ALE wg merged with CIDRD - ALE is now 2018 +/- 8 years - Analysis of address space utilisation was presented. Stats were taken from amsterdam1.dante.net. Figures showed that in 193/194 blocks there was an average of 4,000 hosts per route. CIDR works! - Routing table growth slowing down. Chief problems now seen to be route update processing and flapping. - Yakov Rekter presented paper which will soon become Internet Draft o "Address Ownership Considered Fatal" Paper discusses problems arising from portable address space. All ISP's encouraged to assign only "provider aggregatable" address space. "Provider independant" address space assigned by Regional Registries will offer no guarantee of routability. (will be determined by ISP's - some of whom claim to be filtering on longer prefixes.) Trade off between renumbering to ISP block when you move provider or paying for ISP to route your prefix. Uncertain how this will develop. Daniel Karrenberg asked for European input to document, which is vitally important. - rfc1597 stands and is on standards track. Comments in rfc1627 will be incorporated. 7. AOB Nothing was reported under AOB so the session was formally closed.

4 3

AS690 advisories
by Daniel Karrenberg 29 May '95

29 May '95

We have met with both the RA team and ANS last Tuesday. The message below is the result of these discussions. The upshot is: If you want your routes imported by ANS (AS690) you need to now: make sure you have route objects with correct advisory attruibutes in the RADB. Put those advisories in the RIPE RR. after Friday: European route objects can be removed from the RADB. AS690 advisories in the RIPE RR are sufficient to talk to ANS. July: advisory attributes will no longer be needed. This is a little easier as we expected at the RIPE meeting, so I hope everyone is happy. Daniel ------- Forwarded Message Date: Fri, 26 May 1995 16:44:47 -0400 From: Steve Heimlich <heimlich(a)ans.net> To: nanog(a)merit.edu Subject: AS690 use of multiple routing registries Folks, This note outlines changes to the ANS AS690 use of various registries which comprise the Internet Routing Registry (IRR). [RIPE gang, please forward to your mailing lists as appropriate]. Currently, the IRR consists of the following four well-known registries: the RADB, the CA*Net registry, the MCI registry, and the RIPE registry. AS690, to date, has relied exclusively on the RADB for generation of its configurations. As a result, those organizations which would naturally register in the MCI, CA*Net, or RIPE registries have been making redundant registrations in the RADB to ensure connectivity with ANS. This redundant registration has been inconvenient for many, and leads to multiple copies of route objects with inconsistent attributes. As of next week, ANS will begin to use route objects from the CA*Net, MCI, and RIPE routing registries. In order to do this, we will first create an ANS registry (containing customers of ANS) with "source: ANS" as its distinguishing attribute. Beginning with next Wednesday's AS690 config run (changed from Tuesday due to the U.S. Memorial Day holiday), we will prefer routes with AS690 advisories from these registries in the following order: ANS, CA*Net, MCI, and the RADB. Once we verify that this has succeeded, we will include the RIPE registry ahead of the RADB on next Friday's config run (i.e., ANS, CA*Net, MCI, RIPE, RADB). This method for config generation will eliminate the need for multiple registrations of singly-homed routes. Toward the end of June, we expect to have software running which will eliminate the use of AS690 advisories. This software generates an initial policy first by using registered advisories (a one-time operation). Currently, this results in a 16,000 line aut-num object for AS690. As this is somewhat unreasonable, we will be reducing the number of per-network exceptions in favor of one policy per home AS. As we approach the deployment of this capability, we will be working with peer providers on arranging mutually acceptable policies with AS690. Steve ------- End of Forwarded Message

1 0

Conflit between ICMP redirect code and default route dissemination
by Jean-Luc Richier 19 May '95

19 May '95

I have discovered a problem with the implementation of ICMP redirect in the BSD code: Due to interaction between this code and the router discovery protocol, stations may receive and keep a wrong default route, and the routers will not correct this wrong route. This leads to excessive traffic on Ethernet cables. I wish to have opinions on this problem. Which is wrong, automatic configuration of router discovery (and of any method of distributing defult routes which can be sub optimal), or the BSD routing code ? The problem was discovered with Solaris 2 staions, as they use the router discovery by default, but the Solaris system is not the cause of the problem. Description: 1/ Configuration Ethernet R1 +---+ ---------------------------------------| R | --> + connexion to station D | | +---+ using the default route +---+ +---+ + connexion to station C | A | | B | using an explicit net route +---+ +---+ | ------------ Ethernet R2 - A is a Sun station (1 Ethernet card), system Solaris 2.3 or 2.4, automatic configuration (no explicit routing information configured) - B is a Sun server (2 Ethernet cards), system Solaris 2.3 or 2.4, automatic configuration (no explicit routing information configured) - R is a router (not a Sun) running RIP but not running the Router Discovery protocol. R is connected to cable R1, and connect the site to outside. It gives access to machine C (using an explicit net route), and to machine D, using the defaut route. 2/ The problem All the packets from A to D are routed through B. Therefore each packet appears twice on the ethernet cable R1. Using snoop and netstat -r on A one can see: - A has received a default route to B. - Packets sent from A to D are sent by A to B on Ethernet, and then are sent by B to R on Ethernet. - No ICMP redirect is sent by B to A to correct the routing information. On the opposite, packets from A to C behave correctly: - the first packet from A to C is forwarded to B, then to R - On this first packet, B sends a ICMP redirect to A (redirect C through R). - the following packets from A to C are directly forwarded to R. So in this configuration, a station acquires a wrong default route, and routers fail to generate ICMP redirects to correct it. 3/ Discussion The fact that A acquires a wrong default route comes from the default configuration of both A and B (use of in.rdisc): - At boot time, B starts the in.rdisc -r daemon. (and also in.routed -s, so B receives all routes of R, including a default route) - At boot time, A starts the in.rdisc -s daemon. As B's in.rdisc daemon is active, A will use in.rdisc information and will not start in.routed. - But as R is not using the router discovery protocol, A will not discover the router R, and so will install a poor default route. One should note that : - If B sends ICMP redirects, the problem is solved : the ICMP redirect will correct the wrong route. But B does not send ICMP redirects for messages forwarded by the default route. - B knows all the correct routes received from R through RIP. It also receives the correct default routel to Internet. - Even if R is a router using rdisc protocol, there is still a problem: with standard configuration, the rdisc messages sent by R and B will have the same preference, and so there is a chance that A chooses B as default routeur. The decision not to send ICMP redirects for default routes is explicit in all the BSD codes. For example here is the comment and test in the bsd.networking code (file ip_input.c): /* * If forwarding packet using same interface that it came in on, * perhaps should send a redirect to sender to shortcut a hop. * Only send redirect if source is sending directly to us, * and if packet was not source routed (or has any options). * Also, don't send redirect if forwarding using a default route * or a route modfied by a redirect. */ #define satosin(sa) ((struct sockaddr_in *)(sa)) if (ipforward_rt.ro_rt && ipforward_rt.ro_rt->rt_ifp == ifp && (ipforward_rt.ro_rt->rt_flags & (RTF_DYNAMIC|RTF_MODIFIED)) == 0 && >>>>>> satosin(&ipforward_rt.ro_rt->rt_dst)->sin_addr.s_addr != 0 && ipsendredirects && ip->ip_hl == (sizeof(struct ip) >> 2)) { struct in_ifaddr *ia; My opinion is that ``don't send redirect if forwarding using a default route'' is a wrong decision and should be suppressed. This contradicts the RFCs on ``gateway requirements'', which do not suggest that a default route is something special. It also contradicts the philosophy of Router discovery ICMP. In order to use efficiently the net when using default routes on hosts, routers must be able to correct all routes. Default routes for a router are normal, they are a mean to lower the route information exchanged and stored. In a hierarchic routing domain, the default route is simply ``let the upper domain do the correct thing''. The problem can also appear in a site which use static default routes on hosts, when the topology changes. Suppose stations are manually configured with a default route pointing on a router B (the default router of the site). Some time after a new default router R is installed. With the current code for ICMP redirect all stations must be modified in order to correct the default route. Here are some parts of relevant RFCs: RFC1009 (Gateway requirements) A gateway will generate an ICMP Redirect if and only if the destination IP address is reachable from the gateway (as determined by the routing algorithm) and the next-hop gateway is on the same (sub-)network as the source host. Redirects must not be sent in response to an IP network or subnet broadcast address or in response to a Class D or Class E IP address. RFC1716 (Gateway requirements) Routers MUST be able to generate the Redirect for Host message (Code 1) and SHOULD be able to generate the Redirect for Type of Service and Host message (Code 3) specified in [INTERNET:8]. Routers MUST NOT generate a Redirect Message unless all of the following conditions are met: o The packet is being forwarded out the same physical interface that it was received from, o The IP source address in the packet is on the same Logical IP (sub)network as the next-hop IP address, and o The packet does not contain an IP source route option. The source address used in the ICMP Redirect MUST belong to the same logical (sub)net as the destination address. A router using a routing protocol (other than static routes) MUST NOT consider paths learned from ICMP Redirects when forwarding a packet. RFC 1256 (ICMP outer discovery message) The router discovery messages do not constitute a routing protocol: they enable hosts to discover the existence of neighboring routers, but not which router is best to reach a particular destination. If a host chooses a poor first-hop router for a particular destination, it should receive an ICMP Redirect from that router, identifying a better one. It has been suggested that, when the preference level of an address has not been explicitly configured, a router could set it according to the metric of the router's "default route" (if it has one), rather than defaulting it to zero as suggested above. ...... ....... Such a strategy might reduce the amount of ICMP Redirect traffic on some links by making it more likely that a host's first choice router for reaching an arbitrary destination is also the best choice. On the other hand, Redirect traffic is rarely a significant load on a link, and there are some cases where such a strategy would result in more Redirect traffic, not less (for example, on links from -- Jean-Luc RICHIER (Jean-Luc.Richier(a)Imag.Fr richier(a)imag.fr) LGI, IMAG-CAMPUS, BP 53, F-38041 GRENOBLE Cedex 9 Tel : (33) 76 82 72 32 Fax : (33) 76 44 66 75

1 0

Draft agenda WG meeting ROME
by Willem van der Scheun 04 May '95

04 May '95

Draft agenda for the routing WG meeting RIPE 21, Rome 1. Opening and agenda bashing 2. Minutetaker 3. Report on the population and usage of the routing registry RIPE NCC 4. Report from the CIDRD working group at the Danvers IETF RIPE NCC 5. Status of the Route Arbiter project Elise Gerich, Merit 6. Routing Policy System Daniel Karrenberg, RIPE NCC 7. AoB 8. Closing -- Willem

1 0

The Top 20 and some deltas
by Tony Bates 25 Jan '95

25 Jan '95

This is an auto-generated mail on Wed Jan 25 21:10:00 MET 1995 As stated above this is auto-generated so it is not checked before it leaves my workstation. This is a list of the "Top 20" players who if CIDRizing at the AS level could make a significant gain in the size of Internet routing tables. This may be an over-estimation but it is hoped that this can act as an incentive for the "Top 20" and others to look at their CIDR capability. This report is available as: ftp://ftp.ripe.net/cidr/stats/Top-20.25Jan95 The current (and of course this one today) report is always accessible as: ftp://ftp.ripe.net/cidr/stats/Top-20 A full summary of all the ASes seen in the Internet can be seen by looking in: ftp://ftp.ripe.net/cidr/stats/AS* Please also find a summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does some indication of ASes participating in CIDR. More information can be found in: ftp://ftp.ripe.net/cidr/stats/Delta.* Also, for a short time this gives details of any possibly interesting aggregates currently seen in the routing. Interesting here means not a aggregate made as a set of classful routes. This a daily snapshot of changes in classfull routes being withdrawn and added. the deltas are calculated over a rolling 7 day period. Please bear in mind this is purely a "snapshot" and a large flucuation could be caused by a connectivity problem for example. However, this does give some indication of service providers that are moving to classless routing. Top 20 Withdrawn Routes from 18Jan95 to 25Jan95 -70 AS1334 NSFNETTEST39-AS -59 AS2605 CESNET backbone B - EMPB -46 AS1740 CERFNET -45 AS1902 CESNET backbone A - EBONE -38 AS668 ASN-ASNET-NET-AS -20 AS2149 PSINET-2 -16 AS701 ALTERNET-AS -13 AS297 NSN-UMD-AS -7 AS2651 CDAGOVN -6 AS4174 CONNECT-COM -5 AS2513 JNIC-ASN -4 AS2504 JNIC-ASN -3 AS2277 ECUANET -2 AS2108 Croatian Academic and Research Ne -1 AS1103 SURFnet IP Top 20 Added Routes from 18Jan95 to 25Jan95 38 AS2899 WN-ID 34 AS22 NOSC 31 AS174 NYSERNET-AS 25 AS2901 WN-NM 23 AS200 BARRNET-AS 19 AS1822 NEARNET-1 17 AS2493 FONOROLA-EAST 16 AS1662 ANS-BLK1 14 AS1225 CICNET3-AS 13 AS279 SURANET-AS-2 11 AS549 ONET-AS 9 AS2607 Slovak technical university 8 AS271 BCNET-AS 7 AS175 AFWL-AS 6 AS2704 HOOKUP-NET-A 5 AS3111 DIRECT 4 AS1967 TR-NET 3 AS1327 NSFNETTEST32-AS 2 AS3720 TIMS-AS 1 AS2914 LITTLE-GARDEN List of possibly interesting aggregates --------------------------------------- aggregate origin-AS AS Description 128.138.213.0/24 AS3908 WNBLK-AS 131.119.246.0/24 AS200 BARRNET-AS 138.108.70.0/23 AS1849 PIPEX, Public IP EXchange 138.108.72.0/21 AS1849 PIPEX, Public IP EXchange 138.108.80.0/20 AS1849 PIPEX, Public IP EXchange 138.108.96.0/22 AS1849 PIPEX, Public IP EXchange 144.223.240.0/26 AS1793 SPRINTLINK5 148.252.1.0/24 AS1849 PIPEX, Public IP EXchange 157.166.145.0/24 AS1686 ANS-BLK1 157.166.228.0/24 AS1686 ANS-BLK1 157.166.229.0/24 AS1686 ANS-BLK1 157.166.230.0/24 AS1686 ANS-BLK1 157.166.235.0/24 AS1686 ANS-BLK1 157.166.238.0/24 AS1686 ANS-BLK1 170.91.1.0/24 AS3734 SJEN 170.91.2.0/24 AS3734 SJEN 170.91.3.0/24 AS3734 SJEN 170.91.4.0/24 AS3734 SJEN 170.91.8.0/24 AS3734 SJEN 170.91.10.16/28 AS3734 SJEN 170.91.10.32/28 AS3734 SJEN 170.91.10.49/32 AS3734 SJEN 170.91.10.50/32 AS3734 SJEN 170.91.10.65/32 AS3734 SJEN 170.91.10.66/32 AS3734 SJEN 170.91.10.81/32 AS3734 SJEN 170.91.10.82/32 AS3734 SJEN 170.91.10.97/32 AS3734 SJEN 170.91.10.98/32 AS3734 SJEN 170.91.10.113/32 AS3734 SJEN 170.91.10.114/32 AS3734 SJEN 193.107.196.0/25 AS1899 Fnet, EUnet-France 193.107.196.128/25 AS1899 Fnet, EUnet-France 193.107.199.32/27 AS1899 Fnet, EUnet-France 193.107.199.96/27 AS1899 Fnet, EUnet-France 193.232.88.16/28 AS2854 RoSprint AS 193.233.1.4/30 AS2895 FREEnet Autonomous System 193.233.1.8/30 AS2895 FREEnet Autonomous System 198.133.25.64/26 AS2685 IBM-MMD-AS 198.133.25.128/26 AS2685 IBM-MMD-AS 199.203.4.16/28 AS1680 ANS-BLK1 199.203.4.32/28 AS1680 ANS-BLK1 199.203.4.48/28 AS1680 ANS-BLK1 199.203.4.64/28 AS1680 ANS-BLK1 204.88.159.32/27 AS3734 SJEN Here follows the last weeks "Top 20" list with the corresponding date. --- 25Jan95 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1845 867 978 53.0% ALTERNET-AS AS2149 1448 1019 429 29.6% PSINET-2 AS174 1094 803 291 26.6% NYSERNET-AS AS560 777 496 281 36.2% NEARNET-EXT-AS AS97 583 365 218 37.4% JVNC-AS AS2493 388 182 206 53.1% FONOROLA-EAST AS279 582 427 155 26.6% SURANET-AS-2 AS86 528 388 140 26.5% SURANET-AS AS1982 277 153 124 44.8% ASN-NWNEXUS AS271 266 143 123 46.2% BCNET-AS AS1257 287 188 99 34.5% SWIPnet Swedish IP Network AS2150 165 78 87 52.7% CSUNET-SW AS807 160 79 81 50.6% CANET-ASN AS568 499 421 78 15.6% SUMNET-AS AS549 291 213 78 26.8% ONET-AS AS542 144 70 74 51.4% ARNET AS376 145 71 74 51.0% RISQ-AS AS200 374 303 71 19.0% BARRNET-AS AS137 187 116 71 38.0% GARR AS1270 185 114 71 38.4% EUnet/DE --- 24Jan95 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1850 865 985 53.2% ALTERNET-AS AS2149 1402 1008 394 28.1% PSINET-2 AS174 1037 761 276 26.6% NYSERNET-AS AS560 771 497 274 35.5% NEARNET-EXT-AS AS97 585 357 228 39.0% JVNC-AS AS2493 380 175 205 53.9% FONOROLA-EAST AS279 574 414 160 27.9% SURANET-AS-2 AS86 536 395 141 26.3% SURANET-AS AS1982 276 152 124 44.9% ASN-NWNEXUS AS271 266 143 123 46.2% BCNET-AS AS1257 287 188 99 34.5% SWIPnet Swedish IP Network AS1955 194 103 91 46.9% HUNGARNET AS2150 165 78 87 52.7% CSUNET-SW AS807 160 79 81 50.6% CANET-ASN AS568 499 422 77 15.4% SUMNET-AS AS549 289 212 77 26.6% ONET-AS AS542 143 69 74 51.7% ARNET AS376 145 71 74 51.0% RISQ-AS AS1740 365 292 73 20.0% CERFNET AS200 373 301 72 19.3% BARRNET-AS --- 23Jan95 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1847 867 980 53.1% ALTERNET-AS AS2149 1414 1013 401 28.4% PSINET-2 AS560 773 495 278 36.0% NEARNET-EXT-AS AS174 1041 765 276 26.5% NYSERNET-AS AS97 582 356 226 38.8% JVNC-AS AS2493 340 158 182 53.5% FONOROLA-EAST AS279 572 414 158 27.6% SURANET-AS-2 AS86 535 395 140 26.2% SURANET-AS AS1982 281 155 126 44.8% ASN-NWNEXUS AS271 266 143 123 46.2% BCNET-AS AS1257 287 188 99 34.5% SWIPnet Swedish IP Network AS1955 188 100 88 46.8% HUNGARNET AS2150 165 78 87 52.7% CSUNET-SW AS807 157 78 79 50.3% CANET-ASN AS549 291 214 77 26.5% ONET-AS AS568 495 419 76 15.4% SUMNET-AS AS1740 363 287 76 20.9% CERFNET AS542 143 69 74 51.7% ARNET AS376 145 71 74 51.0% RISQ-AS AS200 375 302 73 19.5% BARRNET-AS --- 22Jan95 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1847 867 980 53.1% ALTERNET-AS AS2149 1399 1013 386 27.6% PSINET-2 AS560 774 496 278 35.9% NEARNET-EXT-AS AS174 1035 763 272 26.3% NYSERNET-AS AS2493 377 173 204 54.1% FONOROLA-EAST AS97 560 365 195 34.8% JVNC-AS AS279 570 412 158 27.7% SURANET-AS-2 AS86 536 396 140 26.1% SURANET-AS AS1982 280 154 126 45.0% ASN-NWNEXUS AS271 266 143 123 46.2% BCNET-AS AS1257 287 188 99 34.5% SWIPnet Swedish IP Network AS1955 193 102 91 47.2% HUNGARNET AS2150 165 78 87 52.7% CSUNET-SW AS807 154 77 77 50.0% CANET-ASN AS549 291 214 77 26.5% ONET-AS AS568 498 422 76 15.3% SUMNET-AS AS1740 360 285 75 20.8% CERFNET AS542 143 69 74 51.7% ARNET AS376 145 71 74 51.0% RISQ-AS AS200 373 302 71 19.0% BARRNET-AS --- 21Jan95 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1847 867 980 53.1% ALTERNET-AS AS2149 1418 1018 400 28.2% PSINET-2 AS174 1083 791 292 27.0% NYSERNET-AS AS560 774 496 278 35.9% NEARNET-EXT-AS AS2493 375 174 201 53.6% FONOROLA-EAST AS97 555 356 199 35.9% JVNC-AS AS279 573 414 159 27.7% SURANET-AS-2 AS86 534 395 139 26.0% SURANET-AS AS1982 281 155 126 44.8% ASN-NWNEXUS AS271 266 143 123 46.2% BCNET-AS AS1257 287 188 99 34.5% SWIPnet Swedish IP Network AS1955 193 102 91 47.2% HUNGARNET AS2150 165 78 87 52.7% CSUNET-SW AS807 157 78 79 50.3% CANET-ASN AS568 501 422 79 15.8% SUMNET-AS AS549 291 214 77 26.5% ONET-AS AS1740 362 287 75 20.7% CERFNET AS542 143 69 74 51.7% ARNET AS376 145 71 74 51.0% RISQ-AS AS1270 182 111 71 39.0% EUnet/DE --- 20Jan95 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1844 866 978 53.0% ALTERNET-AS AS2149 1442 1005 437 30.3% PSINET-2 AS174 1052 754 298 28.3% NYSERNET-AS AS560 767 494 273 35.6% NEARNET-EXT-AS AS97 578 359 219 37.9% JVNC-AS AS2493 372 171 201 54.0% FONOROLA-EAST AS279 574 411 163 28.4% SURANET-AS-2 AS86 530 389 141 26.6% SURANET-AS AS1982 281 155 126 44.8% ASN-NWNEXUS AS271 259 139 120 46.3% BCNET-AS AS1257 288 189 99 34.4% SWIPnet Swedish IP Network AS1955 189 100 89 47.1% HUNGARNET AS2150 158 73 85 53.8% CSUNET-SW AS807 154 75 79 51.3% CANET-ASN AS568 500 421 79 15.8% SUMNET-AS AS549 284 209 75 26.4% ONET-AS AS1740 356 281 75 21.1% CERFNET AS542 141 67 74 52.5% ARNET AS376 144 70 74 51.4% RISQ-AS AS137 189 118 71 37.6% GARR --- 19Jan95 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1858 870 988 53.2% ALTERNET-AS AS174 1507 1064 443 29.4% NYSERNET-AS AS560 764 491 273 35.7% NEARNET-EXT-AS AS97 587 359 228 38.8% JVNC-AS AS2493 370 170 200 54.1% FONOROLA-EAST AS279 573 416 157 27.4% SURANET-AS-2 AS86 537 395 142 26.4% SURANET-AS AS1982 280 155 125 44.6% ASN-NWNEXUS AS271 259 139 120 46.3% BCNET-AS AS1257 289 193 96 33.2% SWIPnet Swedish IP Network AS1955 187 98 89 47.6% HUNGARNET AS2150 162 75 87 53.7% CSUNET-SW AS568 507 426 81 16.0% SUMNET-AS AS807 150 75 75 50.0% CANET-ASN AS376 146 71 75 51.4% RISQ-AS AS549 283 209 74 26.1% ONET-AS AS542 141 67 74 52.5% ARNET AS1740 353 281 72 20.4% CERFNET AS137 193 121 72 37.3% GARR AS1270 182 111 71 39.0% EUnet/DE --- 18Jan95 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1861 870 991 53.3% ALTERNET-AS AS2149 1468 1030 438 29.8% PSINET-2 AS174 1063 775 288 27.1% NYSERNET-AS AS560 764 490 274 35.9% NEARNET-EXT-AS AS97 578 361 217 37.5% JVNC-AS AS2493 371 171 200 53.9% FONOROLA-EAST AS279 569 411 158 27.8% SURANET-AS-2 AS86 527 387 140 26.6% SURANET-AS AS1982 280 155 125 44.6% ASN-NWNEXUS AS271 258 138 120 46.5% BCNET-AS AS1257 287 193 94 32.8% SWIPnet Swedish IP Network AS2150 162 75 87 53.7% CSUNET-SW AS807 151 72 79 52.3% CANET-ASN AS568 492 417 75 15.2% SUMNET-AS AS376 146 71 75 51.4% RISQ-AS AS1740 396 321 75 18.9% CERFNET AS542 141 67 74 52.5% ARNET AS549 280 207 73 26.1% ONET-AS AS137 193 121 72 37.3% GARR AS1270 184 113 71 38.6% EUnet/DE

1 0