- db-wg - mailman.ripe.net

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