From thk at nextra.com Fri Mar 3 12:42:00 2000 From: thk at nextra.com (Thor-Henrik Kvandahl) Date: Fri, 3 Mar 2000 12:42:00 +0100 (MET) Subject: DB consistancy checking tools In-Reply-To: <6BF1C330AF53D311BE5D00508B09081001E3FBFE@PLANET01> Message-ID: Hi Matthew. Can I congratulate with a son or daughter now ? Here are some ideas to a future Task Force. I have some ideas about consistency in the Ripe Whois DB and in the LIRs own assignment files/DB, and also in between them. If we want to come up with some tools/hints for LIR's to keep on top of their entries, I suggest that we also include tools/hints to check the consistency between the LIRs own assignment files/DB and the Ripe Whois DB. One way to do this is to download the inetnum db from ftp.ripe.net, extract the LIRs inetnums, do a consistency check of the inetnums, and finally do a consistency check between the inetnums and the assignment files/DB (and why not do a consistency check between the inetnums and all customer routes ?). I guess there are not many LIRs doing this today (except us). The drawback with this solution is that we have to download the whole inetnum db (12,5Mb) and extract all our inetnums. Here's an idea that belongs to the db-gw, but it is related to the idea described above: To ease the load on the RIPE NCC ftp/whois server and our servers, any LIR should be able to request an automatic extract every 24 hours of their allocated blocks. -- Regards Thor-Henrik Kvandahl Nextra AS Norway On Thu, 20 Jan 2000, Matthew Robinson wrote: > I won't be at RIPE-35 as my first child is due at the same time but I'll > definitely knock something together as a draft. If other people are > interested then things should go ahead at RIPE-35 otherwise I do have > permission from my wife to attend RIPE-36 ;-) > > Kind regards > > Matthew > > -----Original Message----- > From: Wilfried Woeber, UniVie/ACOnet [mailto:woeber at cc.univie.ac.at] > Sent: 20 January 2000 14:55 > To: matthew at planet.net.uk > Cc: lir-wg at ripe.net; db-wg at ripe.net; woeber at cc.univie.ac.at > Subject: RE: DB consistancy checking tools > > > Matthew, > > I think this is an interesting proposal: > > >I have been wondering recently whether a separate group should be set up > for > >the sole purpose of creating tools/advise/methods/hints 'n' tips for LIR's > >to keep on top of their entries and make management easier. A sort of RIPE > >users working group not concerned with designing objects for the database > >but how to put existing objects in it, remove them, manage them, etc. > > > >My 2c > > > >Matthew > > To start things moving, could you come up with a coarse draft of ideas > and short-term goals to take up? > > On the more formal side, one of the possible solutions to accomodate > that activity might be to create a TaskForce to work on well-defined > items during RIPE35 (do you intend to particpate?). > This TF might be supported by both LIR and DB, or sponsored by whichever > group is seen to be appropriate... > > Wilfried. > From robert at easynet.de Fri Mar 3 13:47:48 2000 From: robert at easynet.de (Robert Kiessling) Date: Fri, 3 Mar 2000 13:47:48 +0100 (MET) Subject: DB consistancy checking tools In-Reply-To: References: <6BF1C330AF53D311BE5D00508B09081001E3FBFE@PLANET01> Message-ID: <14527.46196.371171.868250@delphi.local.easynet.de> Thor-Henrik Kvandahl writes: > I guess there are not many LIRs doing this today (except us). You're not alone :) > The drawback > with this solution is that we have to download the whole inetnum db > (12,5Mb) and extract all our inetnums. Why does whois -M or whois -i mnt-by not work for you? Robert From thk at nextra.com Fri Mar 3 14:51:21 2000 From: thk at nextra.com (Thor-Henrik Kvandahl) Date: Fri, 3 Mar 2000 14:51:21 +0100 (MET) Subject: DB consistancy checking tools In-Reply-To: <14527.46196.371171.868250@delphi.local.easynet.de> Message-ID: On Fri, 3 Mar 2000, Robert Kiessling wrote: > Thor-Henrik Kvandahl writes: > > I guess there are not many LIRs doing this today (except us). > > You're not alone :) Good. > > > The drawback > > with this solution is that we have to download the whole inetnum db > > (12,5Mb) and extract all our inetnums. > > Why does > > whois -M > > or > > whois -i mnt-by > > not work for you? It does :-) I just thought getting a small compressed file with ftp would be better if many LIRs started to do this. Perhaps someone from the DBM group can comment on this ? -- Thor-Henrik > > Robert > From nerhus at norway.eu.net Fri Mar 3 17:02:01 2000 From: nerhus at norway.eu.net (Oystein Nerhus) Date: Fri, 3 Mar 2000 17:02:01 +0100 Subject: DB consistancy checking tools In-Reply-To: ; from thk@nextra.com on Fri, Mar 03, 2000 at 12:42:00PM +0100 References: <6BF1C330AF53D311BE5D00508B09081001E3FBFE@PLANET01> Message-ID: <20000303170201.B5233@polarlys.i.eunet.no> On Fri, Mar 03, 2000 at 12:42:00PM +0100, Thor-Henrik Kvandahl wrote: > > Hi Matthew. > > Can I congratulate with a son or daughter now ? > > Here are some ideas to a future Task Force. > > I have some ideas about consistency in the Ripe Whois DB and in the LIRs > own assignment files/DB, and also in between them. If we want to come up > with some tools/hints for LIR's to keep on top of their entries, I suggest > that we also include tools/hints to check the consistency between the LIRs > own assignment files/DB and the Ripe Whois DB. One way to do this is to > download the inetnum db from ftp.ripe.net, extract the LIRs inetnums, > do a consistency check of the inetnums, and finally do a consistency check > between the inetnums and the assignment files/DB (and why not do a > consistency check between the inetnums and all customer routes ?). > > I guess there are not many LIRs doing this today (except us). The drawback > with this solution is that we have to download the whole inetnum db > (12,5Mb) and extract all our inetnums. > > Here's an idea that belongs to the db-gw, but it is related to the idea > described above: To ease the load on the RIPE NCC ftp/whois server and our > servers, any LIR should be able to request an automatic extract every 24 > hours of their allocated blocks. This command will extract all more specific objects under 148.122/16: whois -h whois.ripe.net -F -r -T inetnum -M 148.122/16 Xystein Nerhus, KPNQwest Norway From andrei at ripe.net Fri Mar 3 18:38:08 2000 From: andrei at ripe.net (Andrei Robachevsky) Date: Fri, 03 Mar 2000 18:38:08 +0100 Subject: DB consistancy checking tools References: Message-ID: <38BFF880.D5AC2AF3@ripe.net> Deat Thor-Henrik, Thor-Henrik Kvandahl wrote: > > On Fri, 3 Mar 2000, Robert Kiessling wrote: > > > Thor-Henrik Kvandahl writes: > > > I guess there are not many LIRs doing this today (except us). > > > > You're not alone :) > Good. > > > > > > The drawback > > > with this solution is that we have to download the whole inetnum db > > > (12,5Mb) and extract all our inetnums. > > > > Why does > > > > whois -M > > > > or > > > > whois -i mnt-by > > > > not work for you? > > It does :-) I just thought getting a small compressed file with ftp would > be better if many LIRs started to do this. Perhaps someone from the DBM > group can comment on this ? the same. There should not be many cases when this extracted information could be re-used which may benefit the performance. Unless you have in mind some easy-to-use tool for LIR (with web interface, options, etc.) > > -- > Thor-Henrik > > > > > Robert > > Regards, -- Andrei Robachevsky DB Group RIPE NCC From hostmaster at mediaways.net Mon Mar 6 14:27:16 2000 From: hostmaster at mediaways.net (mediaWays Hostmaster) Date: Mon, 06 Mar 2000 14:27:16 +0100 Subject: DB consistancy checking tools Message-ID: <20000306132717.20285.qmail@demdwu24.mediaways.net> Hi, we do whois -h whois.ripe.net -r -m | grep inetnum | sed "s/inetnum: //" | sed "s/ - /./" > for our Allocations once a month and analyse this with awk script #!/usr/bin/sh nawk -F. 'BEGIN{summe=0} NF==8 { for(i=1; i<=NF; i++) byte[i]=$i; if(byte[3]!=byte[7]) { size=(byte[7]-byte[3])*256; if(byte[4]>byte[8]) size-=byte[8]-byte[4]; else size+=byte[8]+byte[4]; size++; } else { size=byte[8]-byte[4]+1; } summe+=size; printf("%s: %d IPs\n", $0, size); } END{printf("Summe %ld\n", summe);}' < so we could calculate the #IPs, check overlappings, check our own IP-DB against it ... and so on. We hope that this querys do not bother the RIPE-DB ;-) Kind Regards, _____________________________ Stephan Mankopf +49 5241 80 88729 stephan.mankopf at mediaways.net From stephenb at uk.uu.net Tue Mar 7 11:22:10 2000 From: stephenb at uk.uu.net (Stephen Burley) Date: Tue, 07 Mar 2000 10:22:10 GMT Subject: DB consistancy checking tools In-Reply-To: References: Message-ID: <20000307.10221000@merlin.cam.uk.internal> Hi I do not see what all the fuss is about, all i asked for was the access to the tool which the hostmasters use to audit the IP space for a given registry and range. I do not want to reinvent the wheel there is a perfectly usable tool we just need access to it. Regards, -- Stephen Burley Tel: +44 01223 581051 UUNET Fax: 330 Science Park, Cambridge eMail: stephenb at uk.uu.net From joshua at ip.versatel.net Thu Mar 9 12:42:41 2000 From: joshua at ip.versatel.net (Joshua Goodall) Date: Thu, 9 Mar 2000 12:42:41 +0100 (CET) Subject: Bad wording. In-Reply-To: <006b01bf7cd1$21075140$a9ec5c8b@asp.infostream.no> Message-ID: One of my colleagues recently received the following in reply to a 141: "If your customer still uses HTTP/1.0, we need a confirmation that he will return the addresses whenever a new policy set by the the LIR-working group requires so." Now this is often discussed, I know. The rightness of using HTTP/1.1 cannot be doubted. However this wording is awful, because it sounds like the RIPE NCC is dictating. In fact in this instance I was asked about the legal possibilities of what they saw as a "restraint of trade". Clearly, if clients respond like that, a better wording is required. Is the NCC considering it? Or should this list aim to standardise it? Regards, Joshua -- Joshua Goodall IP Systems Development Team Leader Tel: +31 20 711 3200 SpeedPort, Global Network Mob: +31 6 2859 3949 Infrastructure for the Internet Revolution http://www.speedport.net/ From nurani at ripe.net Thu Mar 9 12:54:32 2000 From: nurani at ripe.net (Nurani Nimpuno) Date: Thu, 09 Mar 2000 12:54:32 +0100 Subject: Bad wording. In-Reply-To: Your message of Thu, 09 Mar 2000 12:42:41 +0100. References: Message-ID: <200003091154.MAA19951@x7.ripe.net> Dear Joshua, Indeed we are reworking our drafts at the moment in order to find a better way of addressing this issue. This one in particular. I agree with you that we need to find a better way of wording this. However, this particular issue has been thoroughly discussed on this maillist and the RIPE NCC does not intend to change any policies without consensus within the community. I sent a mail out earlier this year to the lir-wg, stating that we would bring this feedback to the other RIRs and also gather their input. We did attend the APRICOT meeting last week where this issue was further discussed with representatives from all three RIRs present. We will shortly bring these conclusion to the LIR working group in order to move forward and reach a decision. Kind regards, Nurani Nimpuno Registration Service Manager RIPE NCC Joshua Goodall writes: * * One of my colleagues recently received the following in reply to a 141: * * "If your customer still uses HTTP/1.0, we need a confirmation that he will * return the addresses whenever a new policy set by the the LIR-working * group requires so." * * Now this is often discussed, I know. The rightness of using HTTP/1.1 * cannot be doubted. * * However this wording is awful, because it sounds like the RIPE NCC is * dictating. In fact in this instance I was asked about the legal * possibilities of what they saw as a "restraint of trade". * * Clearly, if clients respond like that, a better wording is required. Is * the NCC considering it? Or should this list aim to standardise it? * * Regards, * * Joshua * * -- * Joshua Goodall * IP Systems Development Team Leader Tel: +31 20 711 3200 * SpeedPort, Global Network Mob: +31 6 2859 3949 * Infrastructure for the Internet Revolution http://www.speedport.net/ * * From ripe-dbm at ripe.net Tue Mar 28 15:53:19 2000 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Tue, 28 Mar 2000 15:53:19 +0200 Subject: Whois service running on a backup server Message-ID: <200003281353.PAA04445@birch.ripe.net> Dear Colleagues, Unfortunately this morning the main RIPE Whois server experienced a hardware crash. We switched the service to a backup server; thus you may find that the response time for whois queries is longer than usual. The updates are currently not being processed, but they are queued; they will be processed as soon as the main server is up and running again. There is no need to resend your updates. We are currently working to repair the hardware damage on the main server, and we hope to return to the normal situation as soon as possible. Please accept our apologies for this inconvenience. If you have any questions, please don't hesitate to contact . Regards, Daniele Arena ____________________________ RIPE Database Administration. P.S.: Apologies if you receive this mail more than once. From ripe-dbm at ripe.net Tue Mar 28 15:53:19 2000 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Tue, 28 Mar 2000 15:53:19 +0200 Subject: Whois service running on a backup server Message-ID: <200003281353.PAA04445@birch.ripe.net> Dear Colleagues, Unfortunately this morning the main RIPE Whois server experienced a hardware crash. We switched the service to a backup server; thus you may find that the response time for whois queries is longer than usual. The updates are currently not being processed, but they are queued; they will be processed as soon as the main server is up and running again. There is no need to resend your updates. We are currently working to repair the hardware damage on the main server, and we hope to return to the normal situation as soon as possible. Please accept our apologies for this inconvenience. If you have any questions, please don't hesitate to contact . Regards, Daniele Arena ____________________________ RIPE Database Administration. P.S.: Apologies if you receive this mail more than once. From ripe-dbm at ripe.net Tue Mar 28 20:49:48 2000 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Tue, 28 Mar 2000 20:49:48 +0200 Subject: RIPE Database main server up and running again Message-ID: <200003281849.UAA10611@birch.ripe.net> Dear All, Thank you for your patience. The RIPE Database main server is now up and running again. The queue of updates is being processed, but please take into account that it will take several hours to clear the queue. Technical details: The failure of one of the memory modules of the server caused a parity error, thus forcing the kernel to panic. The memory module had to be replaced and tested. We are very sorry for the inconvenience caused. If you have any questions or comments, please don't hesitate to contact . Regards, Daniele Arena ____________________________ RIPE Database Administration. From ripe-dbm at ripe.net Tue Mar 28 20:49:48 2000 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Tue, 28 Mar 2000 20:49:48 +0200 Subject: RIPE Database main server up and running again Message-ID: <200003281849.UAA10611@birch.ripe.net> Dear All, Thank you for your patience. The RIPE Database main server is now up and running again. The queue of updates is being processed, but please take into account that it will take several hours to clear the queue. Technical details: The failure of one of the memory modules of the server caused a parity error, thus forcing the kernel to panic. The memory module had to be replaced and tested. We are very sorry for the inconvenience caused. If you have any questions or comments, please don't hesitate to contact . Regards, Daniele Arena ____________________________ RIPE Database Administration.