And by “all IP blocks used by an ISP” I mean “all routes operated by one or more network operators”. Close enough. And it’s only for RIPE, might be different for other registries. Still, it’s fun.
Point is, I’m doing load balancing on two links connected to different ISPs and I plan to use this info to set up some better routes to them, since BGP&co aren’t available.
First, get the RIPE whois client, on FreeBSD it’s in ports. The binary is whois3.
What we’re interested in is
The “aut-num” (Autonomous System, AS) object:
An Autonomous System (AS) is a group of IP networks operated by one or more network operators which has a single and clearly defined external routing policy.
An AS has a unique number associated with it which is used both in exchange of exterior routing information and as an identifier of the AS itself. Exterior routing protocols such as BGP and EGP are used to exchange routing information between AS’s.
The route object:
The route object is used to represent a single route injected into the Internet routing mesh.
The value of the origin attribute will be an AS reference of the form AS1234 referring to an aut-num object. It represents the AS injecting this route into the routing mesh. The “aut-num” object (see above) thus referenced provides all the contact information for this route.
So “origin”, which represents one or more network operators, ISPs or not, is something that looks like AS1234 and it has a bunch of routes associated to it that are basically IP addresses given to the operator(s) and it’s all neatly arranged. In an ideal world, but RIPE NCC Database Documentation, which is where those quotes are from, warns:
The term AS is often confused or even misused as a convenient way of grouping together a set of networks which belong under the same administrative umbrella even if within that group of networks there are various different routing policies. We provide the “community” concept for such use. AS’s can strictly have only one single external routing policy.
Special cases: There can only be a single originating AS in each route object. However in today’s Internet sometimes a route is injected by more than one AS. This situation is potentially dangerous as it can create conflicting routing policies for that route and requires coordination between the originating AS’s. In the routing registry this is represented by multiple route objects.
That’s what I’m talking about. Misusing. These aren’t the droids you’re looking for. Move along.
First, the AS of the ISP:
$ dig +short rds.ro 126.96.36.199 $ whois3 188.8.131.52 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '184.108.40.206 - 220.127.116.11' inetnum: 18.104.22.168 - 22.214.171.124 netname: KEPLER-ROMINFO-SA descr: Kepler ROMINFO SA descr: Bd Ghica Tei nr 108, sector2, descr: Buc, cod 72235 descr: Tel +40-1-2331080 descr: Fax +40-1-2331911 country: ro admin-c: DM3032-RIPE tech-c: DM3032-RIPE status: ASSIGNED PA mnt-by: AS3233-MNT mnt-lower: AS3233-MNT mnt-routes: KEPLER-MNT source: RIPE # Filtered person: Dan Millio address: SC Kepler-Rominfo SA address: Bucharest, Bd.Ghica Tei 108 address: Sector 2, 023708, Romania address: RO phone: +40-21-2331080 fax-no: +40-21-2331911 nic-hdl: DM3032-RIPE mnt-by: KEPLER-MNT source: RIPE # Filtered % Information related to '126.96.36.199/24AS34283' route: 188.8.131.52/24 descr: SC Kepler-Rominfo SA origin: AS34283 mnt-by: KEPLER-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1)
By the way, that’s not the droid I was looking for either, but it’ll do.
Now ask RIPE for all route objects associated with that origin:
$ whois3 -i or AS34283 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '184.108.40.206/24AS34283' route: 220.127.116.11/24 descr: SC Kepler-Rominfo SA origin: AS34283 mnt-by: KEPLER-MNT source: RIPE # Filtered % Information related to '18.104.22.168/24AS34283' route: 22.214.171.124/24 descr: SC Kepler-Rominfo SA origin: AS34283 mnt-by: KEPLER-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service (proxy) version 1.6.12 (WHOIS2) $
There. So this RDS KEPLER entity thing is managing two /24 classes.
Here’s a oneliner that will return all the routes associated to the owner of a given IP, let’s say our gateway for example, and present them in the form “route add
$ whois3 -i or `whois3 126.96.36.199 | grep origin: | sed "s/origin:\ *//g"` | grep route: | sed "s/route:\ */route add /g;s/$/ 188.8.131.52/g" route add 184.108.40.206/24 220.127.116.11 route add 18.104.22.168/24 22.214.171.124
WARNING (again): I’m hinting to the possibility of automating this, but IT WOULD BE A BAD IDEA, at least in this form. Routes get withdrawn (in which case they will have the “withdrawn” attribute), routes overlap, just because your ISP is managing a certain class doesn’t mean your gateway is the best point of exit, throwing something like this in the routing table without a third thought could screw things up royally.