|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Operational question: Building filters from IRRdbs
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...]
|