- db-wg - mailman.ripe.net

Re: AS690 advisory update
by ser-rr＠ser.bbnplanet.net 14 Nov '95

14 Nov '95

What happens if policy changes for those AS'es? i.e., AS279 decides to no longer route to AS690 via AS3561, but changes to route through AS701. (*grin*) How is new policy to be determined, either for new ASes, or for existing ones that drastically change their routing policies? _k > Elliot, > > Ignore the advisory. If AS2 is the origin, we will route traffic > for that particular prefix/masklen using the most common policy > already in place for routes in AS2. > > If the common policy is for us to send traffic destined for AS2 > via our peer AS1, we will continue to do so for the new prefix/masklen. > > Steve > > > > > > After this time, AS690 advisories will be ignored. Policy toward > > > routes registered in the IRR will be based solely on origin AS. > > > The origin AS will be expanded to the set of route objects registered > > > for that origin AS; the resulting list of prefixes will be used in > > > generating router configurations, as today. > > > > in the case of AS#1 routing AS#2, suppose AS#2 sent in the route object > > and list themselves as the origin, and put AS#1 in the advisory. in the > > new scenario, will ANS now only allow routes coming via the ASN in the > > ORIGIN field? i.e. will AS#2 have to change the ANS in the origin field > > to AS#1 so ANS knows where to look for for the routes? > > > > - elliot alby/sprintlink implementation > >

2 1

Re: too many hits?
by Christian Panigl, ACOnet/UniVie +43 1 4065822-383 06 Nov '95

06 Nov '95

>So, no it's not an error or indexing problem. It is an design issue. >Changing this behavior can be done but might cause other unwanted effects >for people (or tools) that make use of this feature that look for more >objects at the same time. Dear David, if this is a design issue why doesn't give whois -h whois.ripe.net "panigl woeber" a result ? Both are valid person objects ! Or do I need a special whois client for this multi-object behaviour ? If it is a design issue (restricted by some DBM implementation) could you then please give us a hint how to specify in a whois query, that "Stefan Anders" isn't meant as multi-object but as single-object lookup (perhaps there is or could be a switch for running such a request in slow-mode without using the incomplete index) ? Daniel's suggestion "Please use handles" is nice but should we now go into querying for "SAn-RIPE" (for n=1..10000) and collect all "Stefan Anders" out of the result if we don't know the handle for a given person ? Doesn't sound very healthy ... Kind regards Christian --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet : -------------------------------------------- --- --- Universitaetsstrasse 7 : Internet: Christian.Panigl(a)CC.UniVie.ac.at --- --- A-1010 Vienna / Austria : Tel: +43 1 4065822-383 (Fax: -170) ---

2 1

too many hits?
by Schmitz＠rus.uni-stuttgart.de 06 Nov '95

06 Nov '95

Dear all, lately I get messages from the RIPE database when querying it with whois that there are too many hits, e.g: jade$ whois -h whois.ripe.net "Stefan Anders" The index search returned too many hits. Please refine your search key. I had a look at the database and there are exactly three entries which contain the string "Stefan Anders": jade$ grep "Stefan Anders" ripe.db.pn *pn: Stefan Andersson *pn: Stefan Anders *pn: K A Stefan Andersson Does not seem to be a lot, does it? Is this an error of the database software or is it an indexing problem (there have been other problems reported on the indexing software in the last weeks...)? Regards Joachim _______________________________________________________________________________ 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) _______________________________________________________________________________

3 2

Re: Modification of RIPE-181's as-in/as-out attributes
by Curtis Villamizar 01 Nov '95

01 Nov '95

In message <199510311942.AA07667(a)cat.isi.edu>, Cengiz Alaettinoglu writes: > > I like this idea. There is only one problem that I see with it. The > as numbers in as-in and as-out lines are often used (by tools like > prpath and prtraceroute) to deduce the topology of the Internet. If an > AS only specifies a policy like: > > aut-num: AS2 > as-in: from (NOT AS1) 5 accept ANY > > then prpath has no way of deducing the neighbors of AS2. Doesn't that deduction belong in the inet-rtr ifaddr and peer lines? > aut-num: AS2 > neighbor-list: AS3, AS4, AS5, AS1 # pehaps with router addresses? This is reasonable for AS that don't provide inet-rtr records for their routers (I suspect most). Curtis

1 0

Draft minutes, DB-WG at RIPE #22
by Wilfried Woeber, UniVie/ACOnet 30 Oct '95

30 Oct '95

This is the draft minutes of the RIPE-DB - WG meeting. Many thanks to Hans Petter Holen for taking notes (any typos are mine :-)! Any additions, clarifications appreciated! Wilfried. ________________________________________________________________________________ Draft Minutes: Database-WG, RIPE 22, Amsterdam, NL ------------------------------------------------------ 0. Administrative stuff Hans Petter Holen, Oslonett AS, volunteered to take notes. 37 people subscribed to the circulated list of attenders. The proposed WG-agenda was accepted. 1. DB-SW review David Kessens went through the Database Development Report, covering new functionality that is either being proposed or already in test. As usaul the slides for this presentation are available at ftp://ftp.ripe.net/ripe/presentations/ripe-m22-david-DB-REPORT.ps.gz David reported that the NCC currently works towards making the RIPE-DB more reliable. On the hardware aspect the DB-machine is being fitted with a RAID system (to guard against single disk drives failures). At the same time a "shadow server" for the database is being implemented and tests have already begun. Some problems with portability and scaling of the database software have been reported recently. It was pointed out that the RIPE-NCC version of the database software is tested and supported for Perl4. There is a couple of known (minor) problems in trying to port the software to Perl5 (and to Solaris). Resolving of these problems is not the top priority, but will be tackled as soon as possible. In order to avoid the scaling problems David recommended to *not* use the -P option of netdbm and to eventually move to the Berkley db package. Tests are on-going. New functionality worth noting (for a comprehensive list please refer to the presentation slides): - Hierarchial authorisation schemes to be implemented - Referral mechanisms to be implemented, first tests with domain: objects - -t option plus -v should give more elaborate descriptive text for objects - The NOC-Object to be implemented soon, according to proposal from Havard Eidnes, as circulated shortly after RIPE-21 - "Synchronized DB" is running in test environment - There is a proposal to automate and inter-lock the assignment of RIPE-Handles. This should eventually remove the need to manually obtain unique handles (with the finger mechanism) and the potential race condition due to the delay between assignment of a handle and submitting/referencing the objects. - Inverse lookup, initially for person: objects The same functionality was requested for other object types during the discussion specifically to get better selection criteria for entries in the routing registry. While part of this functionality is available by accessing the data through wais, this was seen as not really adequate. Still this method should be improved as much as possible! - Authentication and Security This is currently under active consideration. In particular both PGP and MD5 should be available. There are both legal/logistic issues (see below) as well as software issues. In particular we have to decide on the method for registering keys and whether to use a "standard package" or to move functionality into the database software itself. During the discussion it was suggested to stick with "standard packages" because things are not yet stable. (Merit is using the "standard package" as well.) The RIPE-NCC is probably following the same path. 2. User interface(s) Encryption is probably going to be a legal problem in (at least) France. In addition to that there was a comment that part of the technology has recently been submitted for patent protection. Probably the first thing to be available shall be PGP protection for signing messages. The details to guard against snooping and re-play of updates are currently be solved. (Detailled input has been received after the WG meeting). A couple of WWW interfaces to the various databases have been made available recently. There is not yet consensus whether this is the right way to go, especially for submitting updates. The RIPE NCC thinks that the DB is not focussed toward the "end user" but towards ISPs. Other comments indicated that the WWW interface could be useful for all sorts of operational people as a well-known user interface. Both Brian Renaud <renaud@meritedu> as well as Paolo Bevilacqua <pab(a)uni.net> have recently made implementations available: - http://black.uni.net/cgi-bin/whois - http://www.ra.net/cgi-bin/ra/query-radb.pl 3. External interfaces Exchange of data with the InetNIC is still not happening. All the necessary agreements and good intentions are in place, still the InterNIC seems to regard it as a low priority issue. European ISPs want this to work really soon and regard it as *urgent*. There is not much the NCC can do right now. The different functionality of the auto-assign vs. auto-dbm mailboxes was briefly reviewed. The differences as not widely known, and the interlocks could be improved. The NCC thinks about moving towards keywords on the subject line, similar to "LONGACK". 4. Input from other WGs - MBone The expansion of the inet-rtr: object to cover multicast functionality is to be progressed now. - IPv6 There is a discussion going on how to handle and possibly abbreviate things for IPv6 (macros?). Input welcome. There was a comment that similar ideas are being (or have been) discussed in the RPS environment. 5. AOB None, thus the meeting was closed. ________________________________________________________________________________ List of new actions: David Kessens: To work with A. Blasco Bonito to improve the WAIS functionality for access to the database information on info.ripe.net. Geert-Jan de Groot: To try to follow up with the InterNIC about accepting person objects with RIPE-Handles. RIPE-NCC: To circulate a proposal how to progress the authentication (and encryption) method for the RIPE Database. RIPE-NCC: To analize the merits of implementing special keywords for the subject line of update messages, like ADD, MOD, DELETE, to possibly replace the functionality of special mailbox names (e.g. auto-assign). RIPE-NCC: To follow up on and implement the NOC-Object. WW, 27.10.95, yes I know, much too late...

1 0

Modification of RIPE-181's as-in/as-out attributes
by Steven J. Richardson 25 Oct '95

25 Oct '95

In the process of reviewing RIPE-181-represented policies, I've noticed an opportunity for what I think would be a useful modification of the as-in/as-out attributes of the aut-num object. Currently, the syntax for these attributes is given as: as-in: from <aut-num> <cost> accept <routing policy expression> as-out: to <aut-num> announce <routing policy expression> I see policies which would be usefully condensed via allowing the <aut-num> to be an AS *macro*, too. E.g.: aut-num: 99999 as-name: SOMEAS ... as-in: from AS10 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS20 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS30 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS40 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS50 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS60 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS70 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS110 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS120 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS130 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS140 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS150 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS160 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS170 150 accept ANY AND NOT {0.0.0.0/0} could be equivalent to: aut-num: 99999 ... as-in: from AS-SOMEAS-100-NO-DEFAULT 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS-SOMEAS-150-NO-DEFAULT 150 accept ANY AND NOT {0.0.0.0/0} with the macro definitions: as-macro: AS-SOMEAS-100-NO-DEFAULT descr: ASs which AS-99999 accepts at pref. 100 (any but descr: the default route) as-list: AS110 AS120 AS130 AS140 AS150 AS160 AS170 ... as-macro: AS-SOMEAS-150-NO-DEFAULT descr: ASs which AS-99999 accepts at pref. 150 (any but descr: the default route) as-list: AS10 AS20 AS30 AS40 AS50 AS60 AS70 ... (The same could be said of as-out lines.) What do you think? Steve Richardson/Merit

2 2

Re: Proposal on applying advisory attribute to "aut-num" object
by Christian Panigl, ACOnet/UniVie +43 1 4065822-383 24 Oct '95

24 Oct '95

>Date: Mon, 23 Oct 1995 15:19:25 -0400 >From: "Steven J. Richardson" <sjr(a)merit.edu> > > I think that this idea, while good, may be too restrictive unless > coupled with the ability to override this "global" advisory by > setting the "advisory" attribute of a specific prefix which originates > within the AS. Steve, I fully agree and I did mean and say this but didn't explicitely write it down in my proposal :-( Unfortunately the wording in RIPE-131 isn't that explicit either, because it was written before your comment has arrived (sometimes the RIPE-NCC is really too fast ;-) >Date: Tue, 24 Oct 1995 10:44:42 +0100 >From: Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> > >To sum up: > >ANS is not going to use advisories in aut-num since they will do away with >advisories in at most two weeks. > >The advisory attribute will stay in aut-num objects and we all hope noone >is going to use them again, ever. Daniel and David, is it worth the effort changing the one RIPE-131 paragraph to: The advisory attribute of a route object applies to the specific route. The advisory attribute of an aut-num object is intended to apply as default to all routes originated by the autonomous system in question providing a shorthand notation if the same advisory applies to most or all such routes. If both are present the advisory attribute of a route object takes precedence over the advisory attribute of the aut-num object. As with all advisories the specific semantics are defined by the 'target' AS. My feeling is, if you decided to keep it, it should be properly documented. Sorry for my incomplete proposal ! Regards Christian

2 1

Re: Proposal on applying advisory attribute to "aut-num" object
by zsako＠banknet.net 24 Oct '95

24 Oct '95

> From owner-db-wg(a)ripe.net Fri Oct 20 21:22:16 1995 Christian, > The famous "advisory" attribute which seems to be still needed by ANS to > get their routing done is especially cumbersome because it has to be > applied to and maintained for every single "route" object. If the > "advisory" attribute could be added to the "aut-num" object, entering an > "advisory" there could cover all routes originated by this AS. Of > course the ANS people will have to slightly modify their software. As far as I see David Kessens has already made the necessary changes in the DB software. :) zsako/banknet $ whois -h whois.ripe.net "-t aut-num" aut-num: [mandatory] [single] as-name: [optional] [single] descr: [mandatory] [multiple] as-in: [optional] [multiple] as-out: [optional] [multiple] advisory: [optional] [single] <<<<<<---------- interas-in: [optional] [multiple] interas-out: [optional] [multiple] as-exclude: [optional] [multiple] default: [optional] [multiple] guardian: [optional] [single] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [mandatory] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] > > Comments welcome ! I would like to make some comments on the above. First of all, with respect to the `[single]' qualifier. If we indeed allow only one such advisory attribute for the AS (aut-num), then the AS can express its advisory recommendations to only one other AS for ALL of it routes. I know that this is somewhat theoretical, since only ANS use the advisory... Nevertheless ripe-130 says it could be used by any other organisation, although *everybody* is discouraged from using it at all. An other approach to this problem would not need any change in the DB schema. We have the `remarks' attribute which can be used for any additional information related to the AS. I think it could also contain something like: "advisory: AS690 1:1800 2:1133 3:1239" which means, the aut-num would have the following remarks attribute: remarks: advisory: AS690 1:1800 2:1133 3:1239 In this case any AS could add as many remarks as needed for the advisories... This is true for the `route' object as well. I know it is not a good practice to use the attributes for other purpose than they are designed for, but in this case I feel the advisory is not more than a remark (actually an important one if you want to have NSFnet connectivity...). Two other arguments are in favour of this second solution: first is that RIPE descourages people from using the advisory, second is that ANS should be ready with the new software soon, and then nobody would (or at least should) use the advisory any more. As you said, ANS have to make some (probably minor) changes in their software in order to get the advisory from the aut-num for all the routes originating in the AS corresponding to the aut-num. I do not think these changes are significantly less in the case there is an `advisory' attribute in the aut-num object, than in the case they have to parse the `remarks' attributes of the aut-num. Further comments welcome! Best regards, Janos Janos Zsako zsako(a)banknet.net BankNet Tel: +36 1 160 16 42 Fax: +36 1 160 14 06

6 5

Re: Proposal on applying advisory attribute to "aut-num" object
by Steven J. Richardson 23 Oct '95

23 Oct '95

Christian: I think that this idea, while good, may be too restrictive unless coupled with the ability to override this "global" advisory by setting the "advisory" attribute of a specific prefix which originates within the AS. Steve Richardson/Merit >From owner-db-wg(a)ripe.net Fri Oct 20 16:13:34 1995 >Date: Fri, 20 Oct 1995 21:08:19 MET >From: "Christian Panigl, ACOnet/UniVie +43 1 4065822-383" > <panigl(a)cc.univie.ac.at> >To: db-wg(a)ripe.net >Cc: domain-admin(a)cc.univie.ac.at >Message-Id: <009982B8.A55165BA.3(a)cc.univie.ac.at> >Subject: Proposal on applying advisory attribute to "aut-num" object >Status: R > > Dear colleagues, > > at RIPE22 I made the following proposal which I would like to be built > into the RIPE-DB and other routing registry databases: > > The famous "advisory" attribute which seems to be still needed by ANS to > get their routing done is especially cumbersome because it has to be > applied to and maintained for every single "route" object. If the > "advisory" attribute could be added to the "aut-num" object, entering an > "advisory" there could cover all routes originated by this AS. Of > course the ANS people will have to slightly modify their software. > > Example: > >aut-num: AS760 >descr: University of Vienna, Austria >descr: AT >as-in: from AS679 100 accept AS679 >as-in: from AS1115 100 accept AS1115 >as-in: from AS1776 100 accept AS1776 AS1117 >as-in: from AS1853 100 accept ANY >as-in: from AS2494 100 accept AS2494 >as-out: to AS1853 announce AS-UDNVIE >as-out: to AS679 announce ANY >as-out: to AS1115 announce ANY >as-out: to AS1776 announce ANY >as-out: to AS2494 announce ANY >default: AS1853 100 >advisory: AS690 1:1800 2:1133 3:1239 <<<<<<<<<<<<<<< >guardian: domain-admin(a)univie.ac.at >admin-c: HS118 >tech-c: EJ63 >tech-c: FK17-RIPE >mnt-by: AS760-MNT >changed: panigl(a)univie.ac.at 951020 >source: RIPE > > Comments welcome ! > > Regards > Christian > > --- Christian Panigl : Vienna University Computer Center - ACOnet --- > --- VUCC - ACOnet : -------------------------------------------- --- > --- Universitaetsstrasse 7 : Internet: Christian.Panigl(a)CC.UniVie.ac.at --- > --- A-1010 Vienna / Austria : Tel: +43 1 4065822-383 (Fax: -170) ---

1 0

Re: Proposal on applying advisory attribute to "aut-num" object
by Wilfried Woeber, UniVie/ACOnet 23 Oct '95

23 Oct '95

>An other approach to this problem would not need any change in the DB schema. >We have the `remarks' attribute which can be used for any additional information >related to the AS. I think it could also contain something like: >"advisory: AS690 1:1800 2:1133 3:1239" which means, the aut-num would have >the following remarks attribute: >remarks: advisory: AS690 1:1800 2:1133 3:1239 >In this case any AS could add as many remarks as needed for the advisories... I think (mis-)using the remark: is a bad idea. It is already being used to e.g. describe DMZ configurations (ias-int:). It leaves too many things to bi-lateral agreements and there is just marginal syntax checking for the remark: attribute. A poor environment to base configuration decisions on.... But it might be appropriate to think about the advisory: as a remark, this might eventually discourage the use of it :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: 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 --------------------------------------------------------------------------

1 0

Proposal on applying advisory attribute to "aut-num" object
by Christian Panigl, ACOnet/UniVie +43 1 4065822-383 20 Oct '95

20 Oct '95

Dear colleagues, at RIPE22 I made the following proposal which I would like to be built into the RIPE-DB and other routing registry databases: The famous "advisory" attribute which seems to be still needed by ANS to get their routing done is especially cumbersome because it has to be applied to and maintained for every single "route" object. If the "advisory" attribute could be added to the "aut-num" object, entering an "advisory" there could cover all routes originated by this AS. Of course the ANS people will have to slightly modify their software. Example: aut-num: AS760 descr: University of Vienna, Austria descr: AT as-in: from AS679 100 accept AS679 as-in: from AS1115 100 accept AS1115 as-in: from AS1776 100 accept AS1776 AS1117 as-in: from AS1853 100 accept ANY as-in: from AS2494 100 accept AS2494 as-out: to AS1853 announce AS-UDNVIE as-out: to AS679 announce ANY as-out: to AS1115 announce ANY as-out: to AS1776 announce ANY as-out: to AS2494 announce ANY default: AS1853 100 advisory: AS690 1:1800 2:1133 3:1239 <<<<<<<<<<<<<<< guardian: domain-admin(a)univie.ac.at admin-c: HS118 tech-c: EJ63 tech-c: FK17-RIPE mnt-by: AS760-MNT changed: panigl(a)univie.ac.at 951020 source: RIPE Comments welcome ! Regards Christian --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet : -------------------------------------------- --- --- Universitaetsstrasse 7 : Internet: Christian.Panigl(a)CC.UniVie.ac.at --- --- A-1010 Vienna / Austria : Tel: +43 1 4065822-383 (Fax: -170) ---

1 0

Re: db under solaris
by Jose Sanchez-Seco. CSIC RedIRIS 19 Oct '95

19 Oct '95

Hi David, I use perl4 (GNU FSFperl package) on Solaris 2.4 and I have changed all the SOCK_STREAM's, but what's about the flock() function?? This function is available only on SunOS and BSD-style machines. At this moment, I am trying to emulate this function whith calls to fcntl(). Also, I have try to compile Perl4 whit /usr/ucblib/libucb but this an impossible task. I have read in the Perl4 FAQ's that it is better to forget about BSDism's like that :-(. If anyone know more about this matter, I will be happy to hear him. Regards, Jose Sanchez-Seco. On Oct 12, 18:12, RIPE Database Manager wrote: > Subject: Re: db under solaris > > Hi Tony, > > If you use perl4 and change the SOCK_STREAM variable to 2 instead of 1 > it should work. This value is used and hardcoded more then once in the > code. In the next distribution this will be handled from the Makefile but > that doesn't help you now ... > > Kind regards, > > David Kessens > RIPE NCC Database maintainer > -------- > > > > > tonyb <tonyb(a)pipex.net> writes: > * Hi, has anyone managed to tweak the perl whois server to run under > * Solaris ? Is it an easy fix ? > * > * Thanks > * > * > * ____ > * / \/ > * /<>/\// > * Tony Barber Phone : +44(0)1223 250122 > * Technical Support Email : support(a)pipex.net > * > * > * >-- End of excerpt from RIPE Database Manager -- __________________________ __ ________________________________________ /_/ Jose Sanchez-Seco __ __ Email: jose.sanchez(a)rediris.es RedIRIS/CSIC /_/ RedIRIS /_/ Tel: + 34 1 5854970 Serrano 142 __ Fax: + 34 1 5855146 E-28006 Madrid /_/ Centro de Gestion de RED de REDIRIS _____________ Spanish Academic & Research Network ___________________________

3 2

New RA Tools Announcement
by Brian Renaud 18 Oct '95

18 Oct '95

Here is some additional location information for a number of the tools I discussed at the last meeting. -Brian ------- Forwarded Message Date: Wed, 18 Oct 1995 13:34:21 -0400 From: labovit(a)merit.edu To: nanog(a)merit.edu Subject: New RA Tools Announcement New Routing Arbiter Tools Announce ---------------------------------- The Routing Arbiter welcomes comments, bug-reports and suggestions for new tools. Please direct email to ra-team(a)ra.net. Please feel free to redistribute this announcement. A web version of this page lives at http://www.ra.net/~ra/tools ------------------------ Online Tools and Reports ------------------------ IRRWeb This graphical interface into the Internet Routing Registry makes it possible to use the Web to query the IRR and update RADB AS objects, Route objects, and Maintainer objects. Users can enter any value that can be submitted through a whois query, such as an AS number, network IP address, or maintainer. IRRWeb then displays the corresponding AS objects, Route objects, or Maintainer objects from the various registries in the IRR. Authorized maintainers can edit the objects directly; IRRWeb performs a cursory pre-check and mails the revised object to auto-dbm(a)ra.net. The user then receives e-mail from auto-dbm confirming and displaying the revised object, or explaining why the object was rejected. See http://www.ra.net/cgi-bin/ra/query-radb.pl Source code is available at ftp://ftp.ra.net/routing.arbiter/tools/irrweb.tar.gz Daily NAP Route Flap Reports</A> This new tool set generates daily reports of route flaps (link failures at regular and short intervals) throughout the Internet. Modeled after the reports originally produced by Curtis Villamizar of ANS, the new reports are generated using tools packaged with Merit's Multi-Threaded Routing Toolkit. The data is obtained from peering sessions with Route Servers at the interconnection points. The reports note the last state of the route (up or down), the length of time that a route existed (or did not exist) for that prefix, and the number of times a route for the prefix transitioned from down to up, up to down, or was replaced by a new route with changed attribute information. AS-path-specific information is also provided for every path announced for the prefix. See http://www.ra.net/~ra/tools/flap.html Route History Server The Route History Server provides a mechanism for tracking the announce/withdraw history of a given prefix for the last 24 hours. The History Server peers with the route servers at each NAP and records all BGP updates in History Server/Route Server peering session. See http://www.ra.net/cgi-bin/ra/rshist.pl ----------------------- Tools Available for FTP ----------------------- RSd The Route Server daemon (RSd) is an enhanced version of the GateD routing software that provides multiples views of routing information. The software provides a mechanism for network service provides to off-load the computational complexity of routing policy calculations from their routers. RSd supports configuration and transparent passing of BGP MEDs. The software also supports BGP route flap dampening. Available at ftp://ftp.ra.net/routing.arbiter/tools/rsd.tar.gz Peval A policy evaluator that inputs a RIPE-181 policy expression, performs essential background calculations such as symbolic evaluations and expansions, and outputs another RIPE-181 policy expression that is used by other tools, such as RTConfig. Available as part of the RAToolSet at ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet RTConfig A router configuration tool that can be used by providers to generate router configs directly from the RADB or other IRR registries. Currently in production use for the RA Route Servers, ANSNET, and CA*net, RTConfig is a front-end tool that uses peval and radbserver transparently to users. Available as part of the RAToolSet at ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet rrc2r/rrmerge This Cisco-to-RIPE-181 conversion package makes it possible for users to convert Cisco router configuration files to RIPE-181 objects that can be submitted to the Internet Routing Registry (IRR). The Cisco access-list can be converted into an explicit set of nets embedded in an AS object or represented as a community. The RADBserver is queried for any missing or previously registered information. Available at ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet/rrc2r-0.2.tar.gz CiscoBGP IRR users have long recognized the need for tools that check the IRR against routes actually propagated in the Internet. CiscoBGP obtains and analyzes routing information from production Ciscos, and compares the data with routes in the IRR. The software also flags prefixes that are reserved by RFC 1597, Address Allocation for Private Internets. Available as part of the MRT software distribution at http://www.merit.edu/~mrt BGPCheck BGPCheck obtains and analyzes routing information from BGP4 peering sessions, and compares the data with routes in the IRR. The software also flags prefixes that are reserved by RFC 1597, <em>Address Allocation for Private Internets</em>. Available as part of the MRT software distribution at http://www.merit.edu/~mrt PRtraceroute The 'prtraceroute' tool is a powerful form of traceroute that displays the Autonomous Systems that a packet traverses. PRtraceroute was developed by the Pride project. A version of prtraceroute that queries the RADB is available at ftp://ftp.ra.net/routing.arbiter/pride/prtraceroute-2.0beta2.shar.gz ------------------ Tool Announcements ------------------ PGP-Based Radb Authentication Follow these steps to take advantage of the new RADB support for PGP-based digital signatures: 1. Register your public key with the Routing Arbiter Service. 2. Modify your Maintainer object to reflect your use of digital signatures. 3. Use PGP to sign your RADB transactions. For detailed instructions, see: http://www.ra.net/routing.arbiter/RA/RADB.tools.docs/pgp.html -- Craig Labovitz labovit(a)merit.edu Merit Network, Inc. 4251 Plymouth Road, Suite C. (313) 764-0252 (office) Ann Arbor, MI 48105 (313) 747-3745 (fax) ------- End of Forwarded Message

1 0

Re: db under solaris
by RIPE Database Manager 18 Oct '95

18 Oct '95

Dear All, First of all: thanks for all your reports! I am not sure what to believe now ... I did some further research. I got a report from Chua Koon Teck at 20 Apr 1995 that it was possible to run at least the whois daemon on Solaris 2.4 with perl5 (yes!): > Anyway, I am using perl5.001 and it seem to be fine so far. But you will > need to edit the defines.pl and defaults.pl file under the lib > directory. The newer version of perl require a backslash before the @ > symbol. So Tony please also look at the defines.pl and defaults.pl files for the @ signs (will of course be changed in the next distribution). If you still don't succeed I am happy to help you further but then I need some more details about error messages and of course I want to hear from Chua Koon Tek about the current state of their database. Kind regards, David Kessens RIPE NCC Database maintainer PS I don't think the db-wg is the platform for this kind of implementation detail questions. Let we first try to find out what happened and send a report to the db-wg when (un)successfull! -------- tonyb <tonyb(a)pipex.net> writes: * RIPE Database Manager wrote: * > * > * >Hi Tony, * > * >If you use perl4 and change the SOCK_STREAM variable to 2 instead of 1 * >it should work. This value is used and hardcoded more then once in the * >code. In the next distribution this will be handled from the Makefile but * >that doesn't help you now ... * > * Hi David, thanks for the reply, I had managed to find the cause of that * one. Unfortunately as guy davies has now confirmed the dbdoesn't work on * solaris :-( * * We will have to wait for the next version. Any idea of the expected date * or release ? * * Thansk * ____ * / \/ * /<>/\// * Tony Barber Phone : +44(0)1223 250122 * Technical Support Email : support(a)pipex.net * *

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

db under solaris
by tonyb 12 Oct '95

12 Oct '95

Hi, has anyone managed to tweak the perl whois server to run under Solaris ? Is it an easy fix ? Thanks ____ / \/ /<>/\// Tony Barber Phone : +44(0)1223 250122 Technical Support Email : support(a)pipex.net

2 1

RE: Inconsistent NIC handles
by Wilfried Woeber, UniVie/ACOnet 10 Oct '95

10 Oct '95

Dear Janos! >Theoretically the NIC handle is supposed to uniquely identify the person. More precisely: ... a uniquely assigned Handle is supposed to... >The problem I noticed is that somebody (inadvertently) registered a person >with an Internic-type NIC handle (i.e. without the "-RIPE" suffix) in the >RIPE database. This is a perfectly legal situation, as long as the person being described has a unique handle assigned already, probably from the InterNIC. Obtaining a unique handle from the RIPE-NCC (of the form xyz999-RIPE) and then registering the person object *without* the "-RIPE" suffix string is clearly an error. The overall scheme is that the InterNIC has in the past assigned, and continues to do so, handles of the form xyz999. Every other source of unique handles assignes strings of the form xyz999-suffix, the suffix being unique in itself. The string "-RIPE" is used for the RIPE Handles. Registries in the Asia/Pacific region are reported to use suffix strings derived from the ISO3166 country codes. >The result is an inconsistency between the two databases >(RIPE and Internic). One gets different answers, depending on whom one asks the >question. Not necessarily so! The IneterNIC is expected to accept handles assigned by other regsitries interchangably when importing data (objects) from other sources. Btw, has this been tried by anyone recently? Please feel free to ask more questions if this is still in the dark :-) Wilfried. PS: If you could point out the affected objects we could possibly find out what went wrong or if there is really a flaw in the logistics... -------------------------------------------------------------------------- Wilfried Woeber : e-mail: 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 --------------------------------------------------------------------------

3 3

RE: Inconsistent NIC handles
by zsako＠banknet.net 09 Oct '95

09 Oct '95

> From woeber(a)cc.univie.ac.at Mon Oct 9 11:39:50 1995 Dear Wilfried, > >The problem I noticed is that somebody (inadvertently) registered a person > >with an Internic-type NIC handle (i.e. without the "-RIPE" suffix) in the > >RIPE database. > > This is a perfectly legal situation, as long as the person being > described has a unique handle assigned already, probably from the > InterNIC. I know, this is how I am registered myself (JZ38). > >The result is an inconsistency between the two databases > >(RIPE and Internic). One gets different answers, depending on whom one asks the > >question. > > Not necessarily so! The IneterNIC is expected to accept handles > assigned by other regsitries interchangably when importing data > (objects) from other sources. I am sorry if I was not clear enough. This is not a theoretical question. A mistake had actually been made. I did not (and still do not) want to make public (to such a big audience) the concrete case, since I do not want to offend the person (and the registry in last instance) who made this mistake. I will let you know by private mail. (I had already notified David before I sent the original message). > PS: If you could point out the affected objects we could possibly find > out what went wrong or if there is really a flaw in the logistics... See above. Best regards, Janos

1 0

Inconsistent NIC handles
by zsako＠banknet.net 09 Oct '95

09 Oct '95

Dear all, I have just come accross a problem with the RIPE database. I am sorry to bother you if this has already been discussed. What I noticed is an inconsistency problem between the different databases that keep the same type of information (in this case _person_ objects). Theoretically the NIC handle is supposed to uniquely identify the person. The problem I noticed is that somebody (inadvertently) registered a person with an Internic-type NIC handle (i.e. without the "-RIPE" suffix) in the RIPE database. The result is an inconsistency between the two databases (RIPE and Internic). One gets different answers, depending on whom one asks the question. I can think of two approaches to solve this problem: - First is checking for the "-RIPE" suffix in the "nic-hdl" attribute when updating a person object (whenever nic-hdl is not empty) - Second is checking (whenever possible) for inconsistencies with the apporpriate database (in our case one could check the person object in the Internic database). I think the first approach can be too restrictive (it would not allow for redundant data between the databases, which otherwise can be useful for saving bandwidth on frequent queries). This would nevertheless have the benefit of preventing people from registering the same thing in several places (and forget to update some of them eventually). Probably the badwidth saving can be better addressed with the sites that keep the large databases 'mirroring' each other. The second approach can be too complicated in case one would like to check more than just the name of the person. There might be problems with the name as well in case of several 'first' names for example. Nevertheless I feel some basic check would be welcome... Best regards, Janos Zsako

1 0

Mailing List
by Sushant Pujari 04 Oct '95

04 Oct '95

Hi, I would appreciate if you could add me to the mailing list. I might be using the ripe code for my work. Thanks -pujari

1 0

(temorary) solution for the database index problems ?!?!
by RIPE Database Manager 02 Oct '95

02 Oct '95

Dear all, The last days I did some further research with Benoit Grange and Willi Huber (they both run SUN OS, so we could use each others binaries) on the recent indexing problems. This morning I found out that the problems disappear when you don't use the '-p' prime option in netdbm. This option adds dummy objects to the database to make the lookups faster. So for the temporary solution: Do *NOT* use the '-p' option in netdbm !!! I am not sure yet if there is a bug in the code or that certain 'dbm' versions cause the problems. I will investigate further ... Kind regards, David Kessens RIPE NCC Database software maintainer --------

4 7

RIPE22: proposal for draft agenda, DB-WG
by Wilfried Woeber, UniVie/ACOnet 02 Oct '95

02 Oct '95

This is the 1st proposal of a draft agenda for the DB-WG at RIPE 22 in Amsterdam. **Message to the NCC (automatic? :-) WG scheduling department: If at all possible - please have the DB-WG meeting scheduled in the streams as late as possible. Thank you! As always, additons, comments, etc. welcome! Apologies if I missed something obvious... Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Agenda: Database-WG, RIPE 22, Amsterdam, NL ------------------------------------------------------ 0. Administrative stuff . who's taking the minutes? . WG-agenda 1. DB-SW review . new or proposed functionality . recent bug fixes, scaling issues, portability . RIPE Handles 2. User interface(s) . stronger authentication of updates, e.g. PGP . Web interfaces for search and/or updates 3. External interfaces . DB-exchange . first steps towards distributing the database 4. Input from other WGs . extensions for the router object (input from Mbone WG?) Z. AOB WW, 28.9.1995 -------------------------------------------------------------------------- Wilfried Woeber : e-mail: 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 --------------------------------------------------------------------------

3 2

Unsubscribe
by Oliver Smith 02 Oct '95

02 Oct '95

Unsubscribe [Sorry if this hits the list by accident; the db-wg-list address didn't work for me?]

1 0

ripe.db.in.cl.* get large ....
by Arnold Nipper 26 Sep '95

26 Sep '95

Even 1G seems not to be enough. Any hints???? docldbm - inserted 41300 /db: write failed, file system is full dbm store returned -1, errno 28, key "3267231744/16" at /home/xladm/lib/cldb.pl line 134, <db> line 382118. docldbm - inserted 41400 docldbm - inserted 41500 .... docldbm - inserted 42100 xlink100# head -2 ripe.db.in # # 950920 04:00:01 xlink100# wc ripe.db.in 382118 980308 7111286 ripe.db.in xlink100# df . Filesystem kbytes used avail capacity Mounted on /dev/sd2h 1016506 1016467 0 111% /db xlink100# \rm ripe.db.in.cl.* xlink100# df . Filesystem kbytes used avail capacity Mounted on /dev/sd2h 1016506 32339 882517 4% /db Regards, Arnold -- 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

5 6

Re: ripe.db.in.cl.* get large
by Willi Huber 25 Sep '95

25 Sep '95

Hallo, SWITCH has been hit by the same problems, file system full while running the indexing. 85 MByte seems not to be enough. Here the info requested: > > 1. ls -ls of the files involved drwxr-xr-x 2 huber 10240 Sep 24 12:06 ./ drwxrwxr-x 11 huber 512 May 30 14:33 ../ -rw-r--r-- 1 huber 9507 Sep 24 09:03 ripe.db.am -rw-r--r-- 1 huber 0 Sep 24 09:04 ripe.db.am.dir -rw-r--r-- 1 huber 1024 Sep 24 09:04 ripe.db.am.pag -rw-r--r-- 1 huber 170007 Sep 24 09:03 ripe.db.an -rw-r--r-- 1 huber 4096 Sep 24 09:05 ripe.db.an.dir -rw-r--r-- 1 huber 32768 Sep 24 09:05 ripe.db.an.pag -rw-r--r-- 1 huber 2384 Sep 24 09:03 ripe.db.cm -rw-r--r-- 1 huber 0 Sep 24 09:05 ripe.db.cm.dir -rw-r--r-- 1 huber 1024 Sep 24 09:05 ripe.db.cm.pag -rw-r--r-- 1 huber 3614035 Sep 24 09:03 ripe.db.dn -rw-r--r-- 1 huber 4096 Sep 24 09:22 ripe.db.dn.dir -rw-r--r-- 1 huber 1047552 Sep 24 09:22 ripe.db.dn.pag -rw-r--r-- 1 huber 2978 Sep 24 09:03 ripe.db.dp -rw-r--r-- 1 huber 0 Sep 24 09:22 ripe.db.dp.dir -rw-r--r-- 1 huber 1024 Sep 24 09:22 ripe.db.dp.pag -rw-r--r-- 1 huber 7143967 Sep 24 09:03 ripe.db.in -rw-r--r-- 1 huber 0 Sep 24 11:35 ripe.db.in.0.0.0.0.0 -rw-r--r-- 1 huber 1728 Sep 24 10:23 ripe.db.in.141.0.0.0.8 -rw-r--r-- 1 huber 1840 Sep 24 10:23 ripe.db.in.145.0.0.0.8 -rw-r--r-- 1 huber 3614 Sep 24 10:23 ripe.db.in.192.0.0.0.8 -rw-r--r-- 1 huber 1210 Sep 24 11:22 ripe.db.in.192.102.0.0.16 -rw-r--r-- 1 huber 1980 Sep 24 11:31 ripe.db.in.192.106.0.0.16 -rw-r--r-- 1 huber 1770 Sep 24 11:24 ripe.db.in.192.108.0.0.16 -rw-r--r-- 1 huber 3350 Sep 24 11:31 ripe.db.in.192.109.0.0.16 -rw-r--r-- 1 huber 3492 Sep 24 11:31 ripe.db.in.192.114.0.0.16 -rw-r--r-- 1 huber 2470 Sep 24 11:32 ripe.db.in.192.115.0.0.16 -rw-r--r-- 1 huber 3044 Sep 24 11:26 ripe.db.in.192.121.0.0.16 -rw-r--r-- 1 huber 2960 Sep 24 11:32 ripe.db.in.192.134.0.0.16 -rw-r--r-- 1 huber 1266 Sep 24 11:20 ripe.db.in.192.163.0.0.16 -rw-r--r-- 1 huber 2314 Sep 24 11:03 ripe.db.in.192.164.0.0.16 -rw-r--r-- 1 huber 3252 Sep 24 11:14 ripe.db.in.192.165.0.0.16 -rw-r--r-- 1 huber 2848 Sep 24 11:10 ripe.db.in.192.176.0.0.16 -rw-r--r-- 1 huber 1588 Sep 24 11:32 ripe.db.in.192.33.0.0.16 -rw-r--r-- 1 huber 3268 Sep 24 11:18 ripe.db.in.192.36.0.0.16 -rw-r--r-- 1 huber 1084 Sep 24 11:28 ripe.db.in.192.44.0.0.16 -rw-r--r-- 1 huber 1868 Sep 24 11:28 ripe.db.in.192.54.0.0.16 -rw-r--r-- 1 huber 1672 Sep 24 11:31 ripe.db.in.192.70.0.0.16 -rw-r--r-- 1 huber 3212 Sep 24 11:26 ripe.db.in.192.71.0.0.16 -rw-r--r-- 1 huber 1070 Sep 24 11:28 ripe.db.in.192.76.0.0.16 -rw-r--r-- 1 huber 2834 Sep 24 11:28 ripe.db.in.192.87.0.0.16 -rw-r--r-- 1 huber 1350 Sep 24 11:24 ripe.db.in.192.89.0.0.16 -rw-r--r-- 1 huber 3478 Sep 24 11:32 ripe.db.in.192.93.0.0.16 -rw-r--r-- 1 huber 2830 Sep 24 10:24 ripe.db.in.193.0.0.0.8 -rw-r--r-- 1 huber 1294 Sep 24 11:32 ripe.db.in.193.100.0.0.16 -rw-r--r-- 1 huber 2078 Sep 24 11:31 ripe.db.in.193.101.0.0.16 -rw-r--r-- 1 huber 2300 Sep 24 11:31 ripe.db.in.193.102.0.0.16 -rw-r--r-- 1 huber 956 Sep 24 11:31 ripe.db.in.193.103.0.0.16 -rw-r--r-- 1 huber 3100 Sep 24 11:31 ripe.db.in.193.104.0.0.16 -rw-r--r-- 1 huber 2470 Sep 24 11:31 ripe.db.in.193.105.0.0.16 -rw-r--r-- 1 huber 1728 Sep 24 11:37 ripe.db.in.193.106.0.0.16 -rw-r--r-- 1 huber 2274 Sep 24 11:26 ripe.db.in.193.107.0.0.16 -rw-r--r-- 1 huber 1308 Sep 24 11:31 ripe.db.in.193.112.0.0.16 -rw-r--r-- 1 huber 1560 Sep 24 11:31 ripe.db.in.193.114.0.0.16 -rw-r--r-- 1 huber 1014 Sep 24 11:35 ripe.db.in.193.116.0.0.16 -rw-r--r-- 1 huber 1056 Sep 24 11:24 ripe.db.in.193.117.0.0.16 -rw-r--r-- 1 huber 1222 Sep 24 11:24 ripe.db.in.193.119.0.0.16 -rw-r--r-- 1 huber 2256 Sep 24 11:26 ripe.db.in.193.12.0.0.16 -rw-r--r-- 1 huber 1460 Sep 24 11:30 ripe.db.in.193.120.0.0.16 -rw-r--r-- 1 huber 1224 Sep 24 11:31 ripe.db.in.193.122.0.0.16 -rw-r--r-- 1 huber 1252 Sep 24 11:31 ripe.db.in.193.123.0.0.16 -rw-r--r-- 1 huber 2888 Sep 24 11:31 ripe.db.in.193.124.0.0.16 -rw-r--r-- 1 huber 1880 Sep 24 11:23 ripe.db.in.193.125.0.0.16 -rw-r--r-- 1 huber 1026 Sep 24 11:27 ripe.db.in.193.127.0.0.16 -rw-r--r-- 1 huber 1588 Sep 24 11:25 ripe.db.in.193.128.0.0.16 -rw-r--r-- 1 huber 1140 Sep 24 11:26 ripe.db.in.193.129.0.0.16 -rw-r--r-- 1 huber 1136 Sep 24 11:30 ripe.db.in.193.13.0.0.16 -rw-r--r-- 1 huber 1880 Sep 24 11:27 ripe.db.in.193.130.0.0.16 -rw-r--r-- 1 huber 984 Sep 24 11:25 ripe.db.in.193.131.0.0.16 -rw-r--r-- 1 huber 1418 Sep 24 11:36 ripe.db.in.193.132.0.0.16 -rw-r--r-- 1 huber 1404 Sep 24 11:25 ripe.db.in.193.133.0.0.16 -rw-r--r-- 1 huber 1026 Sep 24 11:30 ripe.db.in.193.135.0.0.16 -rw-r--r-- 1 huber 2692 Sep 24 11:30 ripe.db.in.193.136.0.0.16 -rw-r--r-- 1 huber 984 Sep 24 11:14 ripe.db.in.193.140.0.0.16 -rw-r--r-- 1 huber 2062 Sep 24 11:31 ripe.db.in.193.141.0.0.16 -rw-r--r-- 1 huber 1504 Sep 24 11:25 ripe.db.in.193.142.0.0.16 -rw-r--r-- 1 huber 0 Sep 24 11:36 ripe.db.in.193.143.0.0.16 -rw-r--r-- 1 huber 1028 Sep 24 11:32 ripe.db.in.193.156.0.0.16 -rw-r--r-- 1 huber 1350 Sep 24 11:27 ripe.db.in.193.160.0.0.16 -rw-r--r-- 1 huber 986 Sep 24 11:28 ripe.db.in.193.161.0.0.16 -rw-r--r-- 1 huber 1208 Sep 24 11:32 ripe.db.in.193.163.0.0.16 -rw-r--r-- 1 huber 1698 Sep 24 11:29 ripe.db.in.193.166.0.0.16 -rw-r--r-- 1 huber 1600 Sep 24 11:31 ripe.db.in.193.170.0.0.16 -rw-r--r-- 1 huber 2958 Sep 24 11:11 ripe.db.in.193.172.0.0.16 -rw-r--r-- 1 huber 1124 Sep 24 11:31 ripe.db.in.193.174.0.0.16 -rw-r--r-- 1 huber 1110 Sep 24 11:31 ripe.db.in.193.175.0.0.16 -rw-r--r-- 1 huber 1448 Sep 24 11:09 ripe.db.in.193.176.0.0.16 -rw-r--r-- 1 huber 1518 Sep 24 11:30 ripe.db.in.193.180.0.0.16 -rw-r--r-- 1 huber 1588 Sep 24 11:14 ripe.db.in.193.182.0.0.16 -rw-r--r-- 1 huber 1350 Sep 24 11:10 ripe.db.in.193.183.0.0.16 -rw-r--r-- 1 huber 3574 Sep 24 11:25 ripe.db.in.193.184.0.0.16 -rw-r--r-- 1 huber 3574 Sep 24 11:27 ripe.db.in.193.185.0.0.16 -rw-r--r-- 1 huber 2090 Sep 24 11:26 ripe.db.in.193.195.0.0.16 -rw-r--r-- 1 huber 1708 Sep 24 11:31 ripe.db.in.193.2.0.0.16 -rw-r--r-- 1 huber 1488 Sep 24 11:08 ripe.db.in.193.208.0.0.16 -rw-r--r-- 1 huber 2552 Sep 24 11:23 ripe.db.in.193.209.0.0.16 -rw-r--r-- 1 huber 1950 Sep 24 11:32 ripe.db.in.193.210.0.0.16 -rw-r--r-- 1 huber 1446 Sep 24 11:31 ripe.db.in.193.212.0.0.16 -rw-r--r-- 1 huber 1910 Sep 24 10:57 ripe.db.in.193.222.0.0.16 -rw-r--r-- 1 huber 1392 Sep 24 11:15 ripe.db.in.193.223.0.0.16 -rw-r--r-- 1 huber 2146 Sep 24 11:30 ripe.db.in.193.224.0.0.16 -rw-r--r-- 1 huber 1404 Sep 24 11:31 ripe.db.in.193.225.0.0.16 -rw-r--r-- 1 huber 1446 Sep 24 11:32 ripe.db.in.193.226.0.0.16 -rw-r--r-- 1 huber 1180 Sep 24 11:23 ripe.db.in.193.232.0.0.16 -rw-r--r-- 1 huber 1040 Sep 24 11:32 ripe.db.in.193.233.0.0.16 -rw-r--r-- 1 huber 984 Sep 24 11:16 ripe.db.in.193.234.0.0.16 -rw-r--r-- 1 huber 1642 Sep 24 11:11 ripe.db.in.193.235.0.0.16 -rw-r--r-- 1 huber 1390 Sep 24 11:27 ripe.db.in.193.236.0.0.16 -rw-r--r-- 1 huber 1138 Sep 24 11:31 ripe.db.in.193.246.0.0.16 -rw-r--r-- 1 huber 0 Sep 24 11:37 ripe.db.in.193.252.0.0.15 -rw-r--r-- 1 huber 1000 Sep 24 11:22 ripe.db.in.193.29.0.0.16 -rw-r--r-- 1 huber 1528 Sep 24 11:18 ripe.db.in.193.32.0.0.16 -rw-r--r-- 1 huber 1052 Sep 24 11:08 ripe.db.in.193.35.0.0.16 -rw-r--r-- 1 huber 1028 Sep 24 10:57 ripe.db.in.193.39.0.0.16 -rw-r--r-- 1 huber 2646 Sep 24 11:28 ripe.db.in.193.4.0.0.16 -rw-r--r-- 1 huber 2704 Sep 24 11:32 ripe.db.in.193.40.0.0.16 -rw-r--r-- 1 huber 1094 Sep 24 11:32 ripe.db.in.193.43.0.0.16 -rw-r--r-- 1 huber 2550 Sep 24 11:23 ripe.db.in.193.44.0.0.16 -rw-r--r-- 1 huber 1248 Sep 24 11:18 ripe.db.in.193.45.0.0.16 -rw-r--r-- 1 huber 3590 Sep 24 11:29 ripe.db.in.193.48.0.0.16 -rw-r--r-- 1 huber 3562 Sep 24 11:30 ripe.db.in.193.49.0.0.16 -rw-r--r-- 1 huber 1568 Sep 24 11:28 ripe.db.in.193.5.0.0.16 -rw-r--r-- 1 huber 3576 Sep 24 11:32 ripe.db.in.193.50.0.0.16 -rw-r--r-- 1 huber 3534 Sep 24 11:30 ripe.db.in.193.51.0.0.16 -rw-r--r-- 1 huber 3432 Sep 24 11:19 ripe.db.in.193.52.0.0.16 -rw-r--r-- 1 huber 1178 Sep 24 11:32 ripe.db.in.193.53.0.0.16 -rw-r--r-- 1 huber 3380 Sep 24 11:23 ripe.db.in.193.54.0.0.16 -rw-r--r-- 1 huber 3408 Sep 24 11:32 ripe.db.in.193.55.0.0.16 -rw-r--r-- 1 huber 3590 Sep 24 11:27 ripe.db.in.193.56.0.0.16 -rw-r--r-- 1 huber 3576 Sep 24 11:17 ripe.db.in.193.57.0.0.16 -rw-r--r-- 1 huber 1262 Sep 24 11:06 ripe.db.in.193.59.0.0.16 -rw-r--r-- 1 huber 1470 Sep 24 11:30 ripe.db.in.193.6.0.0.16 -rw-r--r-- 1 huber 986 Sep 24 11:11 ripe.db.in.193.61.0.0.16 -rw-r--r-- 1 huber 1322 Sep 24 11:16 ripe.db.in.193.62.0.0.16 -rw-r--r-- 1 huber 1826 Sep 24 11:24 ripe.db.in.193.63.0.0.16 -rw-r--r-- 1 huber 2596 Sep 24 11:23 ripe.db.in.193.64.0.0.16 -rw-r--r-- 1 huber 1868 Sep 24 11:28 ripe.db.in.193.65.0.0.16 -rw-r--r-- 1 huber 1388 Sep 24 11:32 ripe.db.in.193.66.0.0.16 -rw-r--r-- 1 huber 2018 Sep 24 11:28 ripe.db.in.193.67.0.0.16 -rw-r--r-- 1 huber 1962 Sep 24 11:32 ripe.db.in.193.69.0.0.16 -rw-r--r-- 1 huber 1738 Sep 24 11:31 ripe.db.in.193.71.0.0.16 -rw-r--r-- 1 huber 2634 Sep 24 11:30 ripe.db.in.193.72.0.0.16 -rw-r--r-- 1 huber 1836 Sep 24 11:29 ripe.db.in.193.73.0.0.16 -rw-r--r-- 1 huber 1570 Sep 24 11:28 ripe.db.in.193.74.0.0.16 -rw-r--r-- 1 huber 1318 Sep 24 11:18 ripe.db.in.193.77.0.0.16 -rw-r--r-- 1 huber 2974 Sep 24 11:26 ripe.db.in.193.78.0.0.16 -rw-r--r-- 1 huber 1336 Sep 24 11:29 ripe.db.in.193.79.0.0.16 -rw-r--r-- 1 huber 2912 Sep 24 11:29 ripe.db.in.193.8.0.0.16 -rw-r--r-- 1 huber 1472 Sep 24 11:21 ripe.db.in.193.80.0.0.16 -rw-r--r-- 1 huber 1892 Sep 24 11:24 ripe.db.in.193.81.0.0.16 -rw-r--r-- 1 huber 1122 Sep 24 11:32 ripe.db.in.193.82.0.0.16 -rw-r--r-- 1 huber 1598 Sep 24 11:23 ripe.db.in.193.84.0.0.16 -rw-r--r-- 1 huber 1584 Sep 24 11:26 ripe.db.in.193.87.0.0.16 -rw-r--r-- 1 huber 1476 Sep 24 11:31 ripe.db.in.193.88.0.0.16 -rw-r--r-- 1 huber 1476 Sep 24 11:32 ripe.db.in.193.89.0.0.16 -rw-r--r-- 1 huber 1476 Sep 24 11:32 ripe.db.in.193.90.0.0.16 -rw-r--r-- 1 huber 1444 Sep 24 11:32 ripe.db.in.193.92.0.0.16 -rw-r--r-- 1 huber 2148 Sep 24 11:31 ripe.db.in.193.96.0.0.16 -rw-r--r-- 1 huber 1700 Sep 24 11:31 ripe.db.in.193.98.0.0.16 -rw-r--r-- 1 huber 0 Sep 24 11:35 ripe.db.in.194.0.0.0.8 -rw-r--r-- 1 huber 1682 Sep 24 11:32 ripe.db.in.194.10.0.0.16 -rw-r--r-- 1 huber 1474 Sep 24 11:19 ripe.db.in.194.101.0.0.16 -rw-r--r-- 1 huber 1684 Sep 24 11:20 ripe.db.in.194.103.0.0.16 -rw-r--r-- 1 huber 1572 Sep 24 11:32 ripe.db.in.194.108.0.0.16 -rw-r--r-- 1 huber 1122 Sep 24 11:21 ripe.db.in.194.11.0.0.16 -rw-r--r-- 1 huber 1014 Sep 24 11:31 ripe.db.in.194.110.0.0.16 -rw-r--r-- 1 huber 1320 Sep 24 11:24 ripe.db.in.194.111.0.0.16 -rw-r--r-- 1 huber 1852 Sep 24 11:28 ripe.db.in.194.113.0.0.16 -rw-r--r-- 1 huber 2286 Sep 24 11:31 ripe.db.in.194.115.0.0.16 -rw-r--r-- 1 huber 2090 Sep 24 11:31 ripe.db.in.194.120.0.0.16 -rw-r--r-- 1 huber 1068 Sep 24 11:23 ripe.db.in.194.124.0.0.16 -rw-r--r-- 1 huber 1432 Sep 24 11:28 ripe.db.in.194.127.0.0.16 -rw-r--r-- 1 huber 2372 Sep 24 11:25 ripe.db.in.194.128.0.0.16 -rw-r--r-- 1 huber 1798 Sep 24 11:25 ripe.db.in.194.129.0.0.16 -rw-r--r-- 1 huber 1644 Sep 24 11:32 ripe.db.in.194.130.0.0.16 -rw-r--r-- 1 huber 2386 Sep 24 11:37 ripe.db.in.194.131.0.0.16 -rw-r--r-- 1 huber 1376 Sep 24 11:28 ripe.db.in.194.132.0.0.16 -rw-r--r-- 1 huber 2132 Sep 24 11:32 ripe.db.in.194.135.0.0.16 -rw-r--r-- 1 huber 3490 Sep 24 11:32 ripe.db.in.194.136.0.0.16 -rw-r--r-- 1 huber 2146 Sep 24 11:32 ripe.db.in.194.137.0.0.16 -rw-r--r-- 1 huber 1306 Sep 24 11:31 ripe.db.in.194.139.0.0.16 -rw-r--r-- 1 huber 2088 Sep 24 11:12 ripe.db.in.194.14.0.0.16 -rw-r--r-- 1 huber 1852 Sep 24 11:32 ripe.db.in.194.142.0.0.16 -rw-r--r-- 1 huber 1180 Sep 24 11:32 ripe.db.in.194.147.0.0.16 -rw-r--r-- 1 huber 996 Sep 24 11:29 ripe.db.in.194.15.0.0.16 -rw-r--r-- 1 huber 1502 Sep 24 11:25 ripe.db.in.194.156.0.0.16 -rw-r--r-- 1 huber 3406 Sep 24 11:32 ripe.db.in.194.157.0.0.16 -rw-r--r-- 1 huber 1432 Sep 24 11:32 ripe.db.in.194.159.0.0.16 -rw-r--r-- 1 huber 1392 Sep 24 11:31 ripe.db.in.194.16.0.0.16 -rw-r--r-- 1 huber 1460 Sep 24 11:36 ripe.db.in.194.161.0.0.16 -rw-r--r-- 1 huber 2580 Sep 24 11:32 ripe.db.in.194.163.0.0.16 -rw-r--r-- 1 huber 1922 Sep 24 11:32 ripe.db.in.194.167.0.0.16 -rw-r--r-- 1 huber 1700 Sep 24 11:31 ripe.db.in.194.17.0.0.16 -rw-r--r-- 1 huber 2216 Sep 24 11:31 ripe.db.in.194.172.0.0.16 -rw-r--r-- 1 huber 0 Sep 24 11:35 ripe.db.in.194.173.0.0.16 -rw-r--r-- 1 huber 998 Sep 24 11:36 ripe.db.in.194.178.0.0.16 -rw-r--r-- 1 huber 1686 Sep 24 11:31 ripe.db.in.194.18.0.0.16 -rw-r--r-- 1 huber 1250 Sep 24 11:32 ripe.db.in.194.180.0.0.16 -rw-r--r-- 1 huber 0 Sep 24 11:36 ripe.db.in.194.182.0.0.17 -rw-r--r-- 1 huber 998 Sep 24 11:32 ripe.db.in.194.188.0.0.16 -rw-r--r-- 1 huber 1560 Sep 24 11:32 ripe.db.in.194.2.0.0.16 -rw-r--r-- 1 huber 1504 Sep 24 11:32 ripe.db.in.194.20.0.0.16 -rw-r--r-- 1 huber 1182 Sep 24 11:37 ripe.db.in.194.21.0.0.16 -rw-r--r-- 1 huber 1094 Sep 24 11:31 ripe.db.in.194.27.0.0.16 -rw-r--r-- 1 huber 1094 Sep 24 11:24 ripe.db.in.194.31.0.0.16 -rw-r--r-- 1 huber 1014 Sep 24 11:23 ripe.db.in.194.32.0.0.16 -rw-r--r-- 1 huber 1252 Sep 24 11:15 ripe.db.in.194.35.0.0.16 -rw-r--r-- 1 huber 1108 Sep 24 11:19 ripe.db.in.194.36.0.0.16 -rw-r--r-- 1 huber 1234 Sep 24 11:37 ripe.db.in.194.39.0.0.16 -rw-r--r-- 1 huber 3304 Sep 24 11:09 ripe.db.in.194.4.0.0.16 -rw-r--r-- 1 huber 1500 Sep 24 11:32 ripe.db.in.194.44.0.0.16 -rw-r--r-- 1 huber 2242 Sep 24 11:31 ripe.db.in.194.45.0.0.16 -rw-r--r-- 1 huber 1052 Sep 24 11:31 ripe.db.in.194.49.0.0.16 -rw-r--r-- 1 huber 2744 Sep 24 11:26 ripe.db.in.194.5.0.0.16 -rw-r--r-- 1 huber 2298 Sep 24 11:32 ripe.db.in.194.51.0.0.16 -rw-r--r-- 1 huber 1654 Sep 24 11:32 ripe.db.in.194.52.0.0.16 -rw-r--r-- 1 huber 1332 Sep 24 11:25 ripe.db.in.194.55.0.0.16 -rw-r--r-- 1 huber 1024 Sep 24 11:16 ripe.db.in.194.56.0.0.16 -rw-r--r-- 1 huber 1486 Sep 24 11:21 ripe.db.in.194.57.0.0.16 -rw-r--r-- 1 huber 2158 Sep 24 11:28 ripe.db.in.194.58.0.0.16 -rw-r--r-- 1 huber 1416 Sep 24 11:28 ripe.db.in.194.59.0.0.16 -rw-r--r-- 1 huber 1290 Sep 24 11:09 ripe.db.in.194.62.0.0.16 -rw-r--r-- 1 huber 2662 Sep 24 11:32 ripe.db.in.194.64.0.0.16 -rw-r--r-- 1 huber 1724 Sep 24 11:11 ripe.db.in.194.66.0.0.16 -rw-r--r-- 1 huber 1976 Sep 24 11:05 ripe.db.in.194.68.0.0.16 -rw-r--r-- 1 huber 3054 Sep 24 11:27 ripe.db.in.194.70.0.0.16 -rw-r--r-- 1 huber 1976 Sep 24 11:11 ripe.db.in.194.71.0.0.16 -rw-r--r-- 1 huber 1892 Sep 24 11:32 ripe.db.in.194.72.0.0.16 -rw-r--r-- 1 huber 1962 Sep 24 11:26 ripe.db.in.194.76.0.0.16 -rw-r--r-- 1 huber 1784 Sep 24 11:32 ripe.db.in.194.77.0.0.16 -rw-r--r-- 1 huber 954 Sep 24 11:19 ripe.db.in.194.80.0.0.16 -rw-r--r-- 1 huber 1332 Sep 24 11:32 ripe.db.in.194.81.0.0.16 -rw-r--r-- 1 huber 1122 Sep 24 11:26 ripe.db.in.194.85.0.0.16 -rw-r--r-- 1 huber 3614 Sep 24 11:35 ripe.db.in.194.86.0.0.16 -rw-r--r-- 1 huber 1220 Sep 24 11:24 ripe.db.in.194.89.0.0.16 -rw-r--r-- 1 huber 1150 Sep 24 11:31 ripe.db.in.194.90.0.0.16 -rw-r--r-- 1 huber 1290 Sep 24 11:28 ripe.db.in.194.92.0.0.16 -rw-r--r-- 1 huber 1304 Sep 24 11:30 ripe.db.in.194.94.0.0.16 -rw-r--r-- 1 huber 1136 Sep 24 11:28 ripe.db.in.194.99.0.0.16 -rw-r--r-- 1 huber 3590 Sep 24 10:25 ripe.db.in.195.0.0.0.8 -rw-r--r-- 1 huber 3590 Sep 24 10:25 ripe.db.in.196.0.0.0.8 -rw-r--r-- 1 huber 3590 Sep 24 10:26 ripe.db.in.197.0.0.0.8 -rw-r--r-- 1 huber 3590 Sep 24 10:26 ripe.db.in.198.0.0.0.8 -rw-r--r-- 1 huber 3590 Sep 24 10:27 ripe.db.in.199.0.0.0.8 -rw-r--r-- 1 huber 3590 Sep 24 10:28 ripe.db.in.200.0.0.0.8 -rw-r--r-- 1 huber 3590 Sep 24 10:29 ripe.db.in.201.0.0.0.8 -rw-r--r-- 1 huber 3590 Sep 24 10:29 ripe.db.in.202.0.0.0.8 -rw-r--r-- 1 huber 3590 Sep 24 10:30 ripe.db.in.203.0.0.0.8 -rw-r--r-- 1 huber 3590 Sep 24 10:31 ripe.db.in.204.0.0.0.8 -rw-r--r-- 1 huber 3590 Sep 24 10:32 ripe.db.in.205.0.0.0.8 -rw-r--r-- 1 huber 3590 Sep 24 10:32 ripe.db.in.206.0.0.0.8 -rw-r--r-- 1 huber 3590 Sep 24 10:33 ripe.db.in.207.0.0.0.8 -rw-r--r-- 1 huber 3590 Sep 24 10:33 ripe.db.in.208.0.0.0.8 -rw-r--r-- 1 huber 3590 Sep 24 10:34 ripe.db.in.209.0.0.0.8 -rw-r--r-- 1 huber 3590 Sep 24 10:34 ripe.db.in.210.0.0.0.8 -rw-r--r-- 1 huber 222257152 Sep 24 11:37 ripe.db.in.cl.dir -rw-r--r-- 1 huber 1728317440 Sep 24 11:37 ripe.db.in.cl.pag -rw-r--r-- 1 huber 4096 Sep 24 09:44 ripe.db.in.dir -rw-r--r-- 1 huber 8349696 Sep 24 09:44 ripe.db.in.pag -rw-r--r-- 1 huber 36327 Sep 24 09:03 ripe.db.ir -rw-r--r-- 1 huber 0 Sep 24 11:38 ripe.db.ir.0.0.0.0.0 -rw-r--r-- 1 huber 0 Sep 24 11:37 ripe.db.ir.cl.dir -rw-r--r-- 1 huber 1024 Sep 24 11:38 ripe.db.ir.cl.pag -rw-r--r-- 1 huber 4096 Sep 24 09:44 ripe.db.ir.dir -rw-r--r-- 1 huber 8192 Sep 24 09:44 ripe.db.ir.pag -rw-r--r-- 1 huber 78895 Sep 24 09:03 ripe.db.mt -rw-r--r-- 1 huber 4096 Sep 24 09:44 ripe.db.mt.dir -rw-r--r-- 1 huber 19456 Sep 24 09:44 ripe.db.mt.pag -rw-r--r-- 1 huber 9440665 Sep 24 09:03 ripe.db.pn -rw-r--r-- 1 huber 4096 Sep 24 10:04 ripe.db.pn.dir -rw-r--r-- 1 huber 29942784 Sep 24 10:04 ripe.db.pn.pag -rw-r--r-- 1 huber 1408398 Sep 24 09:04 ripe.db.rt -rw-r--r-- 1 huber 0 Sep 24 11:49 ripe.db.rt.0.0.0.0.0 -rw-r--r-- 1 huber 0 Sep 24 11:46 ripe.db.rt.195.0.0.0.8 -rw-r--r-- 1 huber 0 Sep 24 11:50 ripe.db.rt.198.0.0.0.8 -rw-r--r-- 1 huber 0 Sep 24 11:52 ripe.db.rt.203.0.0.0.8 -rw-r--r-- 1 huber 0 Sep 24 11:52 ripe.db.rt.205.0.0.0.8 -rw-r--r-- 1 huber 0 Sep 24 11:53 ripe.db.rt.207.0.0.0.8 -rw-r--r-- 1 huber 0 Sep 24 11:54 ripe.db.rt.210.0.0.0.8 -rw-r--r-- 1 huber 0 Sep 24 11:38 ripe.db.rt.cl.dir -rw-r--r-- 1 huber 0 Sep 24 11:38 ripe.db.rt.cl.pag -rw-r--r-- 1 huber 4096 Sep 24 10:08 ripe.db.rt.dir -rw-r--r-- 1 huber 1021952 Sep 24 10:08 ripe.db.rt.pag > 2. Do you 'clean' the database frequently? We transfer the data and build the indexes once a week. We were hit by disk full on 18/09/95. > 3. perl -v? This is perl, version 4.0 $RCSfile: perl.c,v $$Revision: 4.0.1.8 $$Date: 1993/02/05 19:39:30 $ Patch level: 36 > 4. ls -ls of the bin directory of the database drwxr-xr-x 2 huber 512 Nov 14 1994 ./ drwxrwxr-x 11 huber 512 May 30 14:33 ../ -rwxr-xr-x 1 huber 14487 Nov 1 1994 cleandb* -rwxr-x--- 1 huber 2196 Nov 24 1994 cron_update* -rwxr-xr-x 1 huber 11583 Nov 1 1994 dbupdate* -rwxr-xr-x 1 huber 1536 Nov 1 1994 netdbm* -rwxr-xr-x 1 huber 1767 Nov 1 1994 newdb* -rwxr-xr-x 1 huber 304 Nov 1 1994 showdbm* -rwxr-xr-x 1 huber 1992 Nov 1 1994 sortdb* -rwxr-xr-x 1 huber 2031 Nov 22 1994 whois* -rwxr-xr-x 1 huber 14518 Nov 1 1994 whoisd* > 5. egrep $Id of the same bin directory ?? > 6. You OS & version number, patches? SunOS nic 4.1.3_U1 1 sun4m > 7. If you know, what dbm you are using with perl ?? > Help save the world & send us reports. > > Hope this helps, > > Geert Jan & David > As we use rather old whois software, I will first install the up-to-date version. Will this help? Regards, Willi Huber SWITCH

4 4