Merit Routing Registry questions...

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  ---------