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)
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 (amb@gxn.net) 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 (amb@gxn.net) 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