|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Operational question: Building filters from IRRdbs
Version 3.5.8 or 3.5.7 works with radb. Please be aware, command line options have changed between version 3 and 4. Alex Bligh ([email protected]) on January 6: > Gerald, > > Oh OK - that explains it. > > Which version of peval do I have to run (3.xxx???) to work > with the production servers? 4.xxx doesn't work with RADB > etc. > > Alex Bligh > GX Networks (formerly Xara Networks) > > > Hello Alex, > > > > I have resynchronized the data on our experiemental/educational > > rpsl.merit.edu/43 server. As far as the server running at > > low priority goes, this has nothing to do with the 'up to dateness' > > of the data. Normally data is refreshed every 15 minutes > > with production server, whois.ra.net/43. However, this is > > a transitional period in which experimentation and code development > > are occuring. There is no stable RPSL database code distribution > > at this point in time and the effort to bring this code to prodcution > > status is still on-going. And as such, you can expect data staleness, > > outages, etc... occasionally as the bugs are finally ironed out. > > > > The situation on our production server is quite different. > > We are the authoritative source for the radb and ans db's > > and we mirror ripe @15mins. Bell Canada/canet and MCI/CW > > are non-mirrored db's and we download them @24hrs. However, > > our production server is RIPE181 compliant whereas rpsl.merit.edu > > is a playpen for the next db syntax, RPSL. > > > > regards, > > > > --jerry (Merit) > > > > Alex Bligh ([email protected]) on January 3: > > > Here's a couple of operational questions for those who build > > > filters from IRRdb's. > > > > > > Background: > > > > > > * peval / rpsl.merit.edu *may* be incorrectly evaluating > > > RIPE database entries currently - but this isn't my main > > > thrust. The scary thing is suddenly what I'm 99% sure used > > > to work (expanding AS Macros) now silently fails if they > > > are in RIPE. [for details see the end] > > > > > > * I'm not saying the server is broken (I guess it has something to > > > do with the 'server is running at low priority' line), but if I had > > > this in an automatic filter generating run, it would generate > > > the RADB stuff just fine, and silently filter out all RIPE based > > > peerings. Even if it's working perfectly correctly, the questions > > > are still interesting, at least to me. > > [snip...] > > Cengiz -- Cengiz Alaettinoglu Information Sciences Institute http://www.isi.edu/~cengiz University of Southern California
|