irr whois servers seem to vary a bit. is there one simple
query that, given an as-macro or aut-num, produces the list
of prefixes one should accept?
randy
AFAIK most you can get is a prefix-list per aut-num with the extended whois
server. E.g.
whois -h whois.radb.net \!gas2914
gives you all of the registered prefixes for AS 2914. If you want to have
the same data for a given macro you have to first resolve the macro. E.g.
whois-h whois.radb.net \iAS-VERIO,1
which recursively resolves all of the macros within AS-VERIO.
I do this for the DE-CIX routeservers once a day to compile as- and
prefix-lists. While as-lists may be useful I guess most of the prefix-lists
are more or less useless. E.g. prefix-list has 10k entries whereas the
actual announcement is about 1k prefixes.
Arnold
!gas does not even work for ripe server
% whois -h whois.ripe.net \!gas3130
% This is the RIPE Whois server.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/ripencc/pub-services/db/copyright.html
%ERROR:108: bad character in input
%
% An invalid character was passed in the query. Allowed
% characters are letters, numbers, and these: -_:+=.,@/?'.
as, imiho, the basic reason for all this irr stuff is to let
me build a peer filter, one would think that this sould be a
very simple thing, the thing for which all irr software would
optimize.
randy
Ripe's IRRToolSet (Formerly known as RAToolSet when developed as USC IS
Institute) contains tools to do exactly that.
http://www.ripe.net/ripencc/pub-services/db/irrtoolset/
The command:
echo @RtConfig printPrefixes "ip prefix-list peer-in permit %p/%l\n" \
filter AS-PEER | RtConfig
Will give output suitable for a simple cut&paste / tftp into the config of a
cisco router.
Regards,
Russell
altho ripe is mirrored to radb so you can query against radb, i build out of
ripe using a script, gettings the AS's by recursing on the Macro and then
running inverse origin queries on the AS's ... not tidy. and as Arnold says,
useless for anything but small peers.
Steve
Ripe's IRRToolSet (Formerly known as RAToolSet when developed as USC IS
Institute) contains tools to do exactly that.http://www.ripe.net/ripencc/pub-services/db/irrtoolset/
The command:
echo @RtConfig printPrefixes "ip prefix-list peer-in permit %p/%l\n" \
filter AS-PEER | RtConfig
let's see
o we have massive heavy servers
o the most basic/frequent operation requires a massive heavy client
what's wrong with this picture?
randy
The RIPE server uses a different syntax. The query language was not part of the RPSL specification and so different servers chose different paths inthis regard.
With the server you want to say
whois -h whois.ripe.net -k -iorigin AS3130
Another option is to use peval, which is lightweight, quick, knows about the different server syntaxes *and* expands macros recursively and correctly, which most server implementations do not.
Joao
There is also a "light" version, peval.
Another option is to use peval
that's the closest i have found so far.
randy
Well ... this only seems to work with clients being aware of the "-k" option
whereas the !... approach is transparent for all clients.
-- Arnold
You've hit the nail on the head there. The lack of a uniform query syntax
across the registries requires intelligence in the client that would
otherwise not be required.
Defining standard query language syntax / information presentation format
across the registries is exactly why the IETF CRISP working group exists.
Lets hope that as a few of their I-Ds get onto the RFC standards track we
can finally get a registry structure that is so easy to use that people
start keeping their objects up to date 
The '-k' is actually part of the query string rather than a client
option, if your client doesn't understand the option you can pass it on to
the server using quotes: whois -h whois.ripe.net "-k -iorigin AS3130".
let's see
o we have massive heavy servers
o the most basic/frequent operation requires a massive heavy clientwhat's wrong with this picture?
You've hit the nail on the head there. The lack of a uniform query syntax
across the registries requires intelligence in the client that would
otherwise not be required.
Some of us think that respecting the installed base and continuing with the same query syntax was the way to go. Others had different opinions.
Defining standard query language syntax / information presentation format
across the registries is exactly why the IETF CRISP working group exists. Lets hope that as a few of their I-Ds get onto the RFC standards track we
can finally get a registry structure that is so easy to use that people
start keeping their objects up to date
How you keep your objects up to date is actually standard.
Whether you keep your objects up to date or not has nothing to do with CRISP or any other standard but rather with perceived value, enforcement by your upstream and laziness (I won't detail the relative weight of the factors).
Joao
Some of us think that respecting the installed base and continuing
with the same query syntax was the way to go. Others had different
opinions.
I agree that the time to switch to a new syntax is not yet (the syntax
needs to it be defined, ratified and go through a long migration process
first). Compatibility with old syntax has to be high on the list of
considerations when defining a new standard, but it certainly shouldn't be a
show stopper. (It's always possible to leave the old syntax in for a few
revisions with a "This syntax is deprecated, use the new syntax" warning).
>Defining standard query language syntax / information presentation format
>across the registries is exactly why the IETF CRISP working group exists.
>Lets hope that as a few of their I-Ds get onto the RFC standards track we
>can finally get a registry structure that is so easy to use that people
>start keeping their objects up to dateHow you keep your objects up to date is actually standard.
True. Although RIPE allow multiple instances of the member: attribute in
as-sets, which breaks compatibility with RFC2622. Was needed to maintain
compatibility with the old as-macro object though.
Whether you keep your objects up to date or not has nothing to do
with CRISP or any other standard but rather with perceived value,
enforcement by your upstream and laziness (I won't detail the
relative weight of the factors).
Enforcement by upstream was actually what I meant here. Defined standards
and a good set of tools to build filters will lead to more people building
filters based on registered policy, which should force people to overcome
laziness and to keep things up to date.
Of course the other factor to be taken into account in all this is that old
Layer 8 chestnut "Finance". It's hard to convince the bean counters that
you should deny a customer's prefix when he hasn't registered it if it
means unpaid invoices...
Another option is to use peval
anyone can save me a half hour of hacking by sending the perl hack
to call
peval -s $IRR $OBJ
and return the array of prefixes?
randy
At the moment, if some customer wants to announce some non-PA block of addresses to their ISP they probably have some ISP-specific, manual, support-based procedure to wade through, during which there is at least a passing chance that some ISP engineer will check to see that the block to be announced looks plausibly legitimate. I have had dealings with a number of ISPs who do fairly exhaustive checking, down to requiring the RIR-tagged administrative contact to fax authorisation for them to accept and propagate the route.
On the other hand, if all ISPs blindly believe what customers tell them just because the customers are telling them via the IRR, there is a much greater chance of mess, both accidental and malicious.
I guess as an ISP you could accommodate both by using a customer import policy like
aut-num: AS9327
import: from AS9327:AS-CUST-SET action pref=100;
accept AS9327:AS-CUST-SET AND
(AS9327:AS-CUST-VERIFIED OR
AS9327:RS-CUST-VERIFIED);
to choose the intersection of whatever CUST thinks they should be able to announce with what you have verified CUST should be able to announce. But how many people do that? It seems more common for IRR-builders to say "what's your macro?" and blindly trust it.
Maybe I'm missing something.
Joe