- routing-wg - mailman.ripe.net

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

26 Apr '94

Why not deciding this by mail and doing it *now*? (since everybody seems to agree) 10 min to remove those lines from the DB file (grep -v is fine) 10 min to disable the nsf-in attribute in the conf file (or dbupdate.pl) 1h ? to rebuilt the index file. No big deal... > =I feel for Daniels and Jean-Michel's first option. They should > =definately be deprecated (although I have always viewed them as info > =only attibutes) and preferably removed. Although some people may find > > I agree with this point of view. > > I'm going to put it on the agenda for the DB-WG at the Amsterdam > RIPE-Meeting. We should have a *short* review and then agree on a > proposal and a *timeschedule* to remove this information from the > database. > > =this information useful currently, wrong information is worse than no > =information. I'd say obsolete. > > Agreed. > At the same time we should come up with a recommendation for new > ways of storing pieces of information that people maybe still want to > record in the DB. (Like connect, gateway, and the like). > > Wilfried. > -------------------------------------------------------------------------- > Wilfried Woeber : e-mail: Wilfried.Woeber(a)CC.UniVie.ac.at > Computer Center - ACOnet : > Vienna University : Tel: +43 1 4065822 355 > Universitaetsstrasse 7 : Fax: +43 1 4065822 170 > A-1010 Vienna, Austria, Europe : NIC: WW144 > -------------------------------------------------------------------------- > -- 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

2 1

Re: Invalid data in the RIPE database
by farrache＠ccpnxt5.in2p3.fr 26 Apr '94

26 Apr '94

Hello, I would prefer to obsolete this field. Gilles

2 1

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