June 1993 - db-wg - mailman.ripe.net

New database software update
by Marten Terpstra 24 Jun '93

24 Jun '93

all, It's time to let you know what has happened wth RIPE database software development. After some more experimenting to check feasibility we have progressed quite far into a complete rewrite of the database software. We have completed the system design and started to implement various modules. The new design has the following features - fully (and we *mean* fully!) configurable from a config file - separate files (and indices) to store different databases - dynamic updates and deletes as opposed to batch only - possibility for update protocol other than e-mail - guarded fields designed in - dynamic update of secondary databases possible Features which have been requested but are not designed in: - preserve the order of tags within object - preserve the position of remark or comment lines within objects These two features turned out to be hard to specify in the light of updates and even harder to implement. They might go in the next release if someone can come up with a consistent and intuitive spec. The new software will be implemented in the perl language. So those of you who do not have it installed and want to use the RIPE database software should plan to install perl. Of course you won't need perl if you just want to use a whois client and send in updates by mail. Implementing in perl instead of shell, awk and C has three benefits: coding in perl ist fast, subroutines can be used (missing from std awk) and the result is portable. We have a copy of the alpha software running on a PC under UNIX. Together with a notebook this gives you a "portable" RIPE database. The first module completed is the whois server (net.c and netdbm.c replacement). This server runs as its own daemon process rather than under inetd. The measured performance on a SUN ELC before optimising is 5 queries/s on average and the server can sustain peaks of 50 queries arriving in parallel. The new server is compatible with the current one and has some added features: the source databases (RIPE, MERIT, NIC etc.) can be selected individually rather than either RIPE or all, the same connection can be used for multiple queries (nice for tools like prtraceroute), a grep type query as well as nice logging. We have an alpha version of the whois server and the database indexing tool running. The next part to be tackled is the update procedure including the guarded attributes. The last part will be the current mail interface for the update procedure. Impact: Sometime in the next few weeks (after another announcement) we will start using the new server on whois.ripe.net. This should be transparent. Once this is running we will implement the backlogged new tags such as the DMZ specifics in the network and the operatinal contacts. Sometime later we will start using the new update procedures. This will mean that updates mailed in will appear in the database more quickly. It will also mean that we will be more stringent in checking updates, because there will be less human intervention from NCC staff. So you should expect more bounced updates, but they will also happen much more quickly. Diagnostics will be better because the dynamic update procedure will have access to the current database. This will mean that heuristic checks of updates can be better. If you have any questions, please do not hesitate to ask them either puclicly for the benefit of all or privately. The NCC people working on this are me (design, coding and testing) and Daniel (design and testing). Cheers, -Marten

1 0

RIPE whois server
by Marten Terpstra 16 Jun '93

16 Jun '93

Dear people, I am currently working on a new whois server and update procedure and would like to know if there are any additional features you would like to see in the server (I'll leave the update procedure for now, still too early to talk about features). I have rewritten de whois server and the index program in Perl, and have a prototype running (not the production server). I have made the following changes: - database objects are *completely* configurable from a configuration file - this means the indexer follows this file to look for keys - the server follows this file for recursive lookups - multiple databases can be served, all seperately indexed, and kept in seperate files (with the same object structure though) - databases can be indexed at different times - all configurable from config file. - additional functionality in the server - "-s SOURCE" flag to ask the data from specific source (in the prototype "RIPE", "MERIT" and "INTERNIC") - default SOURCE configurable in config file - all SOURCES ("-a" flag) configurable in config file - "-g" option to indicate an object "grep" for a certain string, in stead of the normal key lookup (running low priority - slow) - able to handle more queries/sec (no longer running out of inetd) - an option to keep a connection to the server open, for multiple queries fast after each other. (esp useful for applications like prtraceroute) Any other features you always wanted to have in the server ? Now is the time to make them known, so that we could incorporate them. If you want to have a go at the new server, it is running on rijp.ripe.net on the normal whois port (no uptime guarentees). One thing is that the new flags (-g and -s) do not work with the RIPE whois client ;-( An old client with the flags inside quotes should work. Oh, just remembered, -g is not implemented yet ;-) The data in the prototype server is a bit outdated (last weeks databases or so). so, with an old client you should be able to say: whois -h rijp.ripe.net "-s ripe marten" whois -h rijp.ripe.net "-s merit 192.87.45" whois -h rijp.ripe.net "-s internic mt2" whois -h rijp.ripe.net "-a 192.87.45" You can give it a stress test if you wish, we have done the same, and could not make it crash yet (we did 50 parallel sessions of 10 sequential queries each) A little bit on the update procedure, we are implementing an "on-the-fly" update procedure, that is, no "once-a-day" updates, but updates are processed and incorporated in the running database (and whois server) immediately when they come in. This would mean that (because there will be no manual intervention any longer) that more updates will be bounced because of syntax errors, but you get the bounces fast ;-) Then once a day the guarded tags will be added at a set time. They will be ignored during the normal updates. Please do not nag too much on the update procedure yet, it is still in a "pre-pre-pre-prototype" stage. So, so much for a quick update, if you have suggestions, please let me know. -Marten

1 0

Description of Inter-AS Networks in the RIPE Routing Registry
by Daniel Karrenberg 08 Jun '93

08 Jun '93

Friends, here is the proposal on how to solve the prtraceroute problem as discussed in the last routing-WG meeting. Could we have comments until May 17th please! I'll circulate new versions as substantive comments are incorporated. The goal is to have the database capable of storing this a.s.a.p. and have some data in there quickly as prtraceroute is released. Note that this is not only useful for prtraceroute but much more generally. It could also be the start of the local inter-AS connection information dicussed in the last routing-wg meeting too. As such this addendum could be extended. Proposals ? Cheers Daniel Description of Inter-AS Networks in the RIPE Routing Registry Tony Bates Daniel Karrenberg Addendum to Representation of IP Routing Policies in the RIPE Database (ripe-81) What is an Inter-AS Network ? Inter-AS IP networks are those networks which connect multi- ple autonomous systems (1). An inter-AS network exists for the purpose of passing traffic and routing information between different autonomous systems. The most simple exam- ple of an inter-AS network is a point-to-point link, con- necting exactly two ASes. Each end of such a link is con- nected to an interface of router living in each of the auto- nomous systems. More complex examples are broadcast type networks with multiple interfaces connecting multiple ASes with the possibility of more than one connection per AS. Which additional information is needed? Consider the following example of three routers 1, 2 and 3 with interfaces a through f connected by two inter-AS net- works X and Y: X Y a1b --- c2d --- e3f _________________________ (1) Inter-AS networks are currently called FIXes, IXFs, DMZs, NAPs, GIX and other names. - 2 - Suppose that network X is registered in the routing registry as part of AS1 and net Y as part of AS3. If traffic passes from left to right prtraceroute will report the following sequence of interfaces and ASes: a in AS1 c in AS1 e in AS3 The traceroute algorithm enumerates only the receiving interfaces on the way to the destination. In the example this leads to the passage of AS2 going unnoticed. This is confusing to the user and will also generate exceptions when the path found is checked against the routing registry. For operational monitoring tools such as prtraceroute it is necessary to know which interface on an inter-AS network belongs to which AS. If AS information is not known about interfaces on an inter-AS network, tools like prtraceroute cannot determine correctly which ASes are being traversed. Proposed Format All interfaces on inter-AS networks will be described in a new ias-int attribute of the corresponding network object in the RIPE database. The ias-int attribute has the following syntax: ias-int: <interface-address> <autonomous-system> The <interface-address> must be an address within the corresponding intenum and <autonomous-system> must be of the form AS<number> refering to an aut-num object in the data- base. - 3 - For example: inetnum: 193.193.193.0 netname: INTER-AS-EXAMPLE descr: This is a hypothetical inter-as network. descr: It might be called a NAP, FIX, GIX, IXF, DMZ, descr: Mehrfachdienstanbieterkommunikationseinrichtung or ... country: DE admin-c: Werner Mueller tech-c: Paul Schmitz tech-c: Hans Meier changed: ripe-dbm(a)ripe.net 920714 aut-sys: AS4711 ias-int: 193.193.193.1 AS123 ias-int: 193.193.193.3 AS4711 ias-int: 193.193.193.9 AS789 source: RIPE Note that the interface 193.193.193.3 is described although it is in the same AS as the network. This is recommended practice. The update procedure for the ias-int attribute will be the normal update procedure for network objects. The attribute does not need to be guarded because it does not influence routing policy of operational traffic. In which AS does an Inter-AS Network belong? Only one AS announces an inter-AS network externally. The other ASes connected to the inter-AS network will probably carry this network in their internal routing for redundancy but will not announce it to other ASes. In exceptional cases more than one AS may need to originate external routing information about the inter-AS network, This kind of routing setup cannot be described within the framework of ripe-81 and is generally discouraged. Tools using a ripe-81 type registry could take heuristic hints from the ias-int attributes when they encounter such situa- tions.

3 6