- routing-wg - mailman.ripe.net

Invalid data in the RIPE database
by Laurent Joncheray 26 Apr '94

26 Apr '94

Dear database managers, i had a look at some entries in the RIPE database and at the 'nsf-in' network attribute. For a lot of them the value in the RIPE db is inconsistant with the Merit (NSF) database. Moreover some networks in the RIPE DB have this attribute but are not routed by NSF (for instance 193.128.12/24). It is usefull to keep such data when it can mislead people who use your DB to generate configuration files or aggregate lists? Or can you automaticly generate those values from the NSF database so they will be consistant? Thanks for your answer, Laurent -- Laurent Joncheray, E-Mail: lpj(a)merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM

7 6

Whois database and list of networks
by Daniele Vannozzi 22 Apr '94

22 Apr '94

We would like to know your opinion about this problem and our proposal. The GARR-NIS manages a whois database (whois.nis.garr.it) where each network is described with the RIPE database format plus other "italian GARR-NIS" tags. We produce the access lists for the GARR border routers starting from GARR-NIS whois database (we use the nlc tool). In addition to that we are requested to produce the "aggregate" networks list (CIDR) from GARR-NIS database as well. In our opinion it is difficult to get the right information about network blocks from the whois database as it is currently managed because many network blocks are splitted in smaller blocks (usually corresponding to the really announced networks or because of different contact point). We would like to announce the whole original block while maintaining into the GARR-NIS database the splitted blocks. An additional gain using this scheme would be to store different rev-srv: server for each block for example). We have thought the following solution: add a new tag inet-block: into the network object which describes the original block size. In this way it is possible to store in the same object entry both the information for route aggregates (inet-block:) and other data we need (like rev-srv:, contact people, etc). This is a example: inetnum: 193.204.160.0 - 193.204.161.0 netname: ROMA3-NET inet-block: 193.204.160.0 - 193.204.167.0 country: IT admin-c: Fabio Martinelli tech-c: Aldo Altamore connect: GARR aut-sys: AS137 bdrygw-l: INFN-MIL INFN-CNAF rev-srv: decsrv.caspur.it rev-srv: dns.nis.garr.it rev-srv: matrm3.mat.uniroma3.it ...... ...... inetnum: 193.204.162.0 - 193.204.167.0 netname: ROMA3-NET inet-block: 193.204.160.0 - 193.204.167.0 country: IT admin-c: Fabio Martinelli tech-c: Aldo Altamore connect: LOCAL ....... ....... Please let us know your opinion. The GARR-NIS Staff Daniele Vannozzi Phone: +39 50 593280 GARR-NIS Phone NIS: +39 50 593360 c/o CNUCE - Istituto del CNR Fax: +39 50 904052 Via Santa Maria 36 Telex: 500371 - CNUCE 56100 Pisa - Italy E-mail: vannozzi(a)nis.garr.it

2 1

Re: 20402 routing entries
by Peter Lothberg 22 Apr '94

22 Apr '94

> Peter, > > >We are at the point where action has to be taken, either to get > >CIDR the "proper way", or by forced proxy aggregation at some > >places in the Internet. > > Let me suggest to pursue a combination of both. Folks > who are willing and able to cooperate should pursue the "proper way", > and the rest may be subject of proxy aggregation (which may be "forced"). > Yakov. Fine with me, but WHO does the pushing? People that already have all thedata and are registring routes like Merit? -Peter

9 14

RE: 20402 routing entries
by Tony Hain 21 Apr '94

21 Apr '94

Peter & Yakov, >>We are at the point where action has to be taken, either to get >>CIDR the "proper way", or by forced proxy aggregation at some >>places in the Internet. > >Let me suggest to pursue a combination of both. Folks >who are willing and able to cooperate should pursue the "proper way", >and the rest may be subject of proxy aggregation (which may be "forced"). You can't do proxy aggrigation without consent!!! You WILL create policy violations as well as destablizing global routing. Forget any concept of 'forced proxy aggregation'!!!! Tony

8 11

Effect of CIDR?!
by Erik-Jan Bos 21 Apr '94

21 Apr '94

BGPD, from my historical data on the size of the routing table present in Amsterdam1.dante.net I created yet another picture. IMHO, we can see some CIDR effects now, but please continue to withdraw explicits :-). The graph is available both as a GIF picture as well as a postscript file. This picture is available using gopher to gopher.nic.surfnet.nl [192.87.46.3]. Please find it at: 2. SURFnet information/ 4. SURFnet FTP Archive/ 2. net-management/ 5. ip/ 5. nets.gif <Picture> or 6. nets.ps. I will generate these pictures on a regular basis for the period to come. __ Erik-Jan. P.S. Please be aware of the fact that the x-axis of the graph is a little weird. The numbers on the x-axis are sample points since January 1, 1994 in stead of the absolute date. Sorry for this.

1 0

CIDR state
by Erik-Jan Bos 20 Apr '94

20 Apr '94

BGPD, at the CIDRD meeting in Seattle I showed some statistics on the current state of CIDR Deployment. Just for your information, here are the stats again. Sorry to bother you with stats, anyhow, since more people are doing this, but it shows IMHO that we can do better :-). At the moment (at 16:00 hrs UTC+0200 today) there are 20274 routed in the Internet. These nets are announced by 340 Autonomous Systems. The are currently 154 CIDR routes, which are announced by 43 Autonomous Systems. This means that 297 Autonomous Systems are not announcing any CIDR route yet. However, 70 Autonomous Systems consists of 1 net only, which means that a possible 227 ASs could start to CIDRize. Futhermore, I have some historical data on the total number of routes in the Amsterdam1.dante.net router, from January, 1st on. I created a simple graph using this data. This picture is available using gopher to gopher.nic.surfnet.nl [192.87.46.3]. Go to: 2. SURFnet information/ 4. SURFnet FTP Archive/ 2. net-management/ 5. ip/ 5. nets.gif <Picture> FYI. __ Erik-Jan.

4 3

Re: BGP 4 (fwd)
by Dave Morton 19 Apr '94

19 Apr '94

>This has nothing to do with BGP at all, rather we fixed a bug in 9.21 that we >left alone in 9.1, and it triggered some weirdness in ANSs's setup (they are >playing games with netmasks and their nameserver host ended up being on an >'all zeros broadcast address' and when we cleaned up some of the directed >broadcast code in 9.21, it blew things up for them. > >This shouldn't affect anyone else. Well is sort of does (not the NS stuff) since AS517 don't use ANS's NS but Arnold would like to do BGP4/CIDR to ANS same as he's doing with AS1273 and this prevents him. Judging by Tony's stats there a good gain to be achieved here. Seems it'll just take a little longer that's all. Dave

2 1

BGP 4 (fwd)
by Arnold Nipper 19 Apr '94

19 Apr '94

Does anyone know more about this problem. Regards, Arnold Serpil Bayraktar wrote: > Message-Id: <199404190507.AA76544(a)knock.aa.ans.net> > To: nipper(a)xlink.net > Cc: vimal(a)ans.net, db3l(a)ans.net, sbb(a)noc.ans.net > Subject: BGP 4 > Date: Tue, 19 Apr 1994 05:07:13 UTC > From: Serpil Bayraktar <sbb(a)noc.ans.net> > > > I know this is getting very confusing, but.. we really need to > switch back to old version soon. Basically all our customers > connected to New York are having name service problems and it > would be wonderful if we could take care of this today. > Our NOC is going to get in touch with you around 8 AM your > time (or 07:00 GMT). If you can change your configuration > to let your router negotiate or do v3, we will reload our New > York router. If you want me to be on the phone with you during > these changes please let our NOC know, but basically as soon > as you modify your config file all it takes is to reload our > Cisco. > > Serpil > -- Arnold Nipper / email: nipper(a)xlink.net NTG Netzwerk und Telematic GmbH \/ phone: +49 721 9652 0 Geschaeftsbereich XLINK /\ LINK fax: +49 721 9652 210 Vincenz-Priessnitz-Str. 3 /_______ D-76131 Karlsruhe, Germany

4 3

Merit Routing Registry
by epg＠merit.edu 18 Apr '94

18 Apr '94

Merit is happy to announce the Merit Routing Registry. Whereas Merit designed and manages the PRDB (Policy Routing Data Base) for the NSFNET service, RIPE pioneered a policy routing registry for the European community. The RIPE Routing Registry is based on the document, RIPE-81. With RIPE's collaboration, Merit installed RIPE-81 software and then extended the policy descriptions in order to realize more complex policies. The Merit Routing Registry will be a companion registry to the RIPE Routing Registry and is intended to serve the community that is not served by RIPE. This is a new service and we consider ourselves still in the beta phase. Registrations may be basic policy descriptions defined in RIPE-81 or complex routing policy descriptions defined in the Extended Policy Syntax document by Chen, Gerich, Joncheray, and Yu. The Extended Policy Syntax document may be found on rrdb.merit.edu:pub/meritrr/policy_syntax.txt. Documentation for using the MeritRR can be found on rrdb.merit.edu:pub/meritrr. Merit and RIPE anticipate that the combined registries will provide a more comprehensive picture of the routing interactions in the Internet. We are working together to allow the two registries to appear like one virtual registry to the various tools that are developed. We welcome your comments on all aspects of this project. For more information, please respond to rradmin(a)rrdb.merit.edu. Elise Gerich, Merit Network, Inc. Daniel Karrenberg, RIPE NCC

1 0

Re: 20402 routing entries
by Steven J. Richardson 18 Apr '94

18 Apr '94

>Date: Fri, 15 Apr 1994 14:56:24 -0700 >From: Paul Traina <pst(a)cisco.com> >Status: RO > >> To: Paul Traina <pst(a)cisco.com> >> Cc: Peter Lothberg <roll(a)stupi.se>, David R Conrad <davidc(a)terminus.iij.ad.jp>, >> Vadim Antonov <avg(a)sprint.net>, ALH(a)eagle.es.net, bgpd(a)merit.edu, >> eowg(a)fnc.gov, routing-wg(a)ripe.net, yakov(a)watson.ibm.com >> Subject: Re: 20402 routing entries >> Date: Fri, 15 Apr 94 13:15:20 -0700 >> From: "Milo S. Medin" (NASA ARC NSI Office) <medin(a)nsipo.nasa.gov> >> >> >> That's all fine and good, however it has little to do with the issue >> of reducing the number of routes. Your worst case of 500 staying >> 500 is more likely due to problems in getting BGP4 deployed than any >> AUP issue. > >> You hurt your credibility when you try and blame all the world's problems >> on AUP's. >My point is the same one that Andrew was making -- right now, he's got >customers randomly scatters as AUP and non-AUP. For every non-AUP net, >he's got, we end up poking serious holes into CIDR efficiency. All it takes >is, say, 30 randomly scattered holes to make a complete mess of the 500 to 2 argument. Excuse me, but it seems as though 500 -> 31 (30 more-specific routes + 1 CIDR block) is still a significant savings. >Best regards, > >Paul Steve Richardson/Merit

1 0