RtConfig feature

Nick Hilliard nick at inex.ie
Sun Jun 21 13:52:54 UTC 2009

> The current setup is based on the idea that RtConfig connects to a
> single server which has multiple sources. I've got a situation where I
> have a local database for the NZ Route Registry - NZRR (running on an
> IRRd server) which I want to consult first and then connect to the APNIC
> server to get APNIC and possibly other objects.
> So I might call a suitably modified RtConfig like:
> RtConfig -h whois.nzix.net:NZRR -h whois.apnic.net:APNIC,RADB .....
> or
> RtConfig -h whois.nzix.net,whois.apnic.net -s NZRR,APNIC,RADB .....
> This is an extension of the mechanism that the IRR cache file allows but
>   is much more scalable and allows route objects.

This would be very messy to implement.  Part of the problem is that there 
are two major irrdb server types out there (irrd and ripedb; there are also 
other older versions of each, and some companies still run the old ripe 
server software, which is unhelpful), so in order to manage this at all, it 
would be necessary to:

  - implement a whois server autodetection system, so that the correct 
querytypes could be issued to the correct servers on-the-fly. This would be 
a pain because irrtoolset is coded to handle this statically.

  - vectorize all irr queries

  - do some really funky stuff in terms of tagging each cache entry with a 
preferred source list.

  - hope that the data returned from each source is consistent

If you need to do this, it may be better to run a local whois server.  The 
RIPE whois server is messy to set up, but irrd is quite easy.

I ran into the same problem some while ago when managing router 
configuration for clients who used lots of different sources.  My configs 
were managed using Template::Toolkit, so it turned out to be really easy to 
put each @rtconfig directive into a FILTER block like this:

> [% FILTER $IRRToolSetDispatch irrdb = entries.$vid.irrdb -%]
> @RtConfig set cisco_map_name = "inex-rsclient-as[% entries.$vid.autsys %]-[% protocol %]-export"
> @RtConfig set cisco_access_list_no = [% count %]
> @RtConfig import AS[% inex_rs_asn %] [% inex_rs_address %] AS[% entries.$vid.autsys %] [% entries.$vid.address %]
> [% END -%]

Then the irrtoolset dispatcher would execute rtconfig with the specified 
whois server and source list.  This has the disadvantage that you lose the 
cache support in rtconfig, but as far as I can tell, this is the only 
disadvantage: it's a lot more flexible in other ways.


More information about the irrtoolset mailing list