Find all IP blocks used by an ISP

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.

and

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
81.180.25.6
$ whois3 80.96.125.6
% 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 '80.96.125.0 - 80.96.125.255'

inetnum:      80.96.125.0 - 80.96.125.255
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 '80.96.125.0/24AS34283'

route:        80.96.125.0/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 '80.96.125.0/24AS34283'

route:        80.96.125.0/24
descr:        SC Kepler-Rominfo SA
origin:       AS34283
mnt-by:       KEPLER-MNT
source:       RIPE # Filtered

% Information related to '81.180.25.0/24AS34283'

route:          81.180.25.0/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 81.180.25.6 | grep origin: | sed "s/origin:\ *//g"` | grep route: | sed "s/route:\ */route add /g;s/$/ 81.180.25.6/g"
route add 80.96.125.0/24 81.180.25.6
route add 81.180.25.0/24 81.180.25.6

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.