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 ----- Original Message ----- From: "Randy Bush" <randy@psg.com> To: <nanog@nanog.org> Sent: Monday, April 14, 2003 3:01 PM Subject: whois for just prefix list
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
!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
On Mon, 14 Apr 2003, Randy Bush wrote:
!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.
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
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 At 6:27 -0700 14/4/03, Randy Bush wrote:
!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
On Mon, Apr 14, 2003 at 04:02:06PM +0200, Joao Luis Silva Damas wrote:
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
Well ... this only seems to work with clients being aware of the "-k" option whereas the !... approach is transparent for all clients. -- Arnold
On Mon, Apr 14, 2003 at 04:23:45PM +0200, Arnold Nipper wrote:
On Mon, Apr 14, 2003 at 04:02:06PM +0200, Joao Luis Silva Damas wrote:
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
Well ... this only seems to work with clients being aware of the "-k" option whereas the !... approach is transparent for all clients.
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". -- Russell Heilling http://www.ccie.org.uk/ PGP: finger russellh@bela.homeunix.net
On Mon, Apr 14, 2003 at 04:23:45PM +0200, Arnold Nipper wrote:
On Mon, Apr 14, 2003 at 04:02:06PM +0200, Joao Luis Silva Damas wrote:
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
Well ... this only seems to work with clients being aware of the "-k" optio
n
whereas the !... approach is transparent for all clients.
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".
Yes, but I think Joao meant to the use the -K flag (keywords only), rather than -k (keep connection open). Further, quoting the query string unfortunately does not work with every whois client. Notably, the whois client (jwhois) that comes with RedHat requires the use of a '--' flag to get it to transparently pass subsequent flags. So the following is required: whois -h whois.ripe.net -- -K -iorigin AS3130 I would also like to add that we are updating the IRRd software to support a number of the RIPE flags (notably: -K, -iorigin, and -imember-of). This should help standardize the query syntax between different versions of IRR software and simplify the development of tools such as peval. Finally, as a followup to Joao's comment concerning server internal macro expansion bugs (the '!i' query command in IRRd). We believe that all such expansion bugs have been fixed as of the 2.1.5 release of IRRd. -Larry
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 On Mon, Apr 14, 2003 at 06:01:07AM -0700, Randy Bush wrote:
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
-- Russell Heilling http://www.ccie.org.uk PGP: finger russellh@bela.homeunix.net
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
On Mon, Apr 14, 2003 at 06:47:43AM -0700, Randy Bush wrote:
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?
There is also a "light" version, peval. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
On Mon, Apr 14, 2003 at 06:47:43AM -0700, Randy Bush wrote:
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?
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 ;) -- Russell Heilling http://www.ccie.org.uk/ PGP: finger russellh@bela.homeunix.net
At 15:38 +0100 14/4/03, Russell Heilling wrote:
On Mon, Apr 14, 2003 at 06:47:43AM -0700, Randy Bush wrote:
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?
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
On Mon, Apr 14, 2003 at 05:05:36PM +0200, Joao Luis Silva Damas wrote:
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 date ;)
How 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... -- Russell Heilling http://www.ccie.org.uk/ PGP: finger russellh@bela.homeunix.net
On Monday, Apr 14, 2003, at 11:31 Canada/Eastern, Russell Heilling wrote:
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.
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
participants (9)
-
Arnold Nipper -
Joao Luis Silva Damas -
Joe Abley -
Larry J. Blunk -
Nipper, Arnold
-
Randy Bush -
Richard A Steenbergen -
Russell Heilling -
Stephen J. Wilcox