[ixpmanager] question re: compare-route-server-prefixes.pl

[Barry O'Donovan]

Athanasios Douitsis wrote:
> We were having a discussion with Andreas, which boiled down to the
> question of why the
> tools/runtime/route-servers/compare-route-server-prefixes.pl script
> needs to access the Bird configuration file instead of querying the Bird
> daemon directly. What we mean is that, since the configuration dictates
> which prefix is eventually accepted or not, one might as well query the
> master routing table directly from Bird and see which prefixes present
> in the t_$vliidhash{ $asn } made it through. The rest of the logic
> remains more or less the same, prefixes not accepted have irrdb 0,
> accepted have 1, etc.

There are three data points we are interested in:

1) advertised and accepted
2) advertised and not accepted
3) not advertised but acceptable

(1) is easy as we learn from Bird if the prefix is advertised and based
on config will know that it's accepted.

NB: presence in the master table is not an indication of (1) for the
peer under consideration. Larger members can and often do transit for
smaller members.

(2) is identified the same way as one but by omission from the
configuration.

(3) is identified based on presence in the configuration but absence
from the member's advertised routes.

So, to answer you specific question: (1) and (2) need access to the
configuration.

> If there are any comments on this (Barry?), we would be delighted to
> hear, er, read them. At GR-IX we use a slightly modified version of that
> script, but we could conceivably make some contribution back to the
> original one. But we'd like some opinions on whether this makes sense or
> if there's something we are missing.

The medium term plan is to lose this script as there are a number of
issues with it:

1) using this, the Route Server Prefix Analysis Tool is limited to a
single route server (we have three peering LANs with two route servers
each);

2) the validity of the tool is for a state 'sometime in the past ~6
hours'; i.e. whenever the tool last ran. This sometimes leads to
confusion for diagnosing real time issues.

Now that we have Birdseye, we can make this tool realtime and against
any of the targeted six route servers.

The main issue we need to bear in mind (note to self) is what happens if
the configuration is out of sync with the database as a tool using
Birdseye will not have access to the config. However, it will know the
last time a route server was updated.

 - Barry