Merit Routing Registry questions...
Dale S. Johnson
Wed Apr 27 23:52:42 CEST 1994
Jamshid, Glad to have you using the RRDB! We're still building production infrastructure for this, so its a really good time to let us know what we can build in to make you life easier. (Like you've done, below). > I believe that I can do all of the pieces necessary for this audit, > except the first step of listing out all of the networks registered > to our AS in the RRDB. (Currently, we grab the whole file from the > PRDB and do what amounts to a grep... This does not scale well!) What kinds of solution would you like to see for this? (We also generate many of the PRDB reports by "grep'ing" nets.unl.now; it takes 6 seconds with a C program, and 90 seconds with Perl.) The Routing Registry database files are less terse than nets.unl.now, so they could take a bit longer. > Can anyone comment on when this sort of functionality will be available > in the RRDB? Also, is there anything else we should be doing to get > our nets into the RRDB? We currently assume that the PRDB copies are > transferred in. Ok; we've just put the system in place to post the parts of the MERITRR for anonymous ftp: pick up rrdb.merit.edu:pub/meritrr/dbase/meritrr.db.Z and prdb.db.Z . You can pick up the most current RIPE db from ftp.ripe.net . To get the home ASs associated with AS204, look for records (blocks of lines) that include the line "*as: AS204", then print out the previous line that begins with "*in:" to get the IP address: *in: 161.224/16 <------------------------- print out this. *na: BUCKEYEPTR *de: Buckeye Pipe Line Company *de: 5002 Buckeye Road PO Box 368 *de: Emmaus *de: PA 18049, USA *cy: US *ni: 1=204 2=1206 *as: AS204 <------------------------- look for this *ch: skw at merit.edu 931113 *so: PRDB I could send a tiny perl program to do this, if it would help. > Can anyone comment on when this sort of functionality will be available > in the RRDB? Also, is there anything else we should be doing to get > our nets into the RRDB? We currently assume that the PRDB copies are > transferred in. You don't need to do anything, though you are free to add more information to the RRDB or to take control of the information that is there yourself. (Actually, we'd really appreciate your entering your AS policy information, to help us figure whether we're supporting enough syntax to describe your policy). The way we are handling this is that the MERITRR tools look at three "databases": meritrr.db (which is where all direct MERITRR updates take place), ripe.db (ftp'd from RIPE each morning), and prdb.db (a dump of a subset of the PRDB information in Routing Registry format, updated with each PRDB config run). Handling the PRDB data this way makes it automatically available to the new MERITRR tools. It also allows us to update that data regularly from the PRDB, without interfering with data that users have entered directly. If you do nothing about updating your own data, a minimum subset of your data from the PRDB will appear automatically to the MERITRR tools because of the MERITRR prdb.db database. If you would like to take more control of your registrations, you can control your own information by submitting templates (like NACRs) to auto-dbm at rrdb.merit.edu. All of the information you submit will be kept in the meritrr.db, and will be used in preference to any information that is there because it has been copied from the PRDB. (Every time that the tools look for any attribute, they look for it first in the meritrr.db, then in the ripe.db, then in the prdb.db). Because of this you could, for instance, enter network descriptions in the meritrr.db that just had administrative contact info, and let the PRDB process automatically update other information about those networks. Once you enter such data, it stays there until you change it. No automatic update process will change what you entered. Does description make sense? (Does the system, too?) Does this answer your questions? If we could interest you in entering some data into the new registry, the file rrdb.merit.edu:pub/meritrr/rr_user_doc.txt gives an overview of the process. Let us know any way we can help. --Dale ============================================ > All, > > PSC & PREPnet are in a position of needing to upgrade our configuration > software. We have automated mechanism to generate gated.conf files which > are similar to those used by ANS to generate configs from the PRDB. > The advent of CIDR has made our current mechanisms a bit unstable, so we > need to bring things up to date. > > The basics steps in our configuration are (1) do a policy audit, > (2) analyze our policy data-base and (3) write the configuration files. > The policy audit step is the part which is relevant to this list. > > Our audit consists basically of determining that our locally configured > policy for each net in each of our AS's matches the PRDB (currently) > policy for that net. Nets which do not match are flagged and corrected > either locally or in the PRDB. Since we need to rewrite this software, > and we only want to do it once, we want to move to using the RRDB instead. > > The basic thing we need to be able to do is get the list of all of the > networks registered to each of our AS's. We then look for three cases: > 1) We list the net in our policy, but the RRDB does not. > 2) The RRDB has the net with one of our AS's, but we do not. > 3) Both databases have the net, but the policies are different. > > I believe that I can do all of the pieces necessary for this audit, > except the first step of listing out all of the networks registered > to our AS in the RRDB. (Currently, we grab the whole file from the > PRDB and do what amounts to a grep... This does not scale well!) > > Can anyone comment on when this sort of functionality will be available > in the RRDB? Also, is there anything else we should be doing to get > our nets into the RRDB? We currently assume that the PRDB copies are > transferred in. > > Thanks, > > --Jamshid > > PS. We aren't yet on the rr-disc mail list, so please cc responses > to everyone until tomorrow. > -------- Logged at Wed Apr 27 23:54:54 MET DST 1994 ---------
[ rr-impl Archive ]