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

[Barry O'Donovan]

Andreas Polyrakis wrote:
>>> 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.

Sorry, I take that back. Proper interrogation of the master table will
show all routes for a prefix, not just the 'winning' one.

> Can you elaborate a little bit on this? I cannot understand how
> something can be present in the master table but not "advertised and
> accepted".

Peer A peers directly with the route server.
Peer B peers directly with the route server.

Peer A and peer B both provide transit for an upstream network C who
does not peer at the exchange.

C prepends its adverts to A.

The route server thus choses C's routes via B as the best path.

> At some point we modified our (test) bird configuration to accept more
> specific prefixes. I.e, instead of 10.0.0/8, the configuration file
> contained 10.0.0.0/8+. After this change, the (unmodified) script would
> still categorize 10.0.0.8/24 as "advertised but not accepted"; although
> it was actually accepted.

Yip, noted in:

https://github.com/inex/IXP-Manager/issues/235

which has now been incorporated into:

https://github.com/inex/IXP-Manager/issues/329

> At that point we realized parsing the config files can sometimes be
> tricky and give results that differ from reality (eg the example already
> given, misconfiguration in filters (eg not correctly applied), route
> server bugs etc). It might make more sense to calculate this bases on
> queries on the route daemon.

Based on the above, it sounds like it may work but a few caveats:

- I haven't done any testing

- it will require a lot more parsing and more complex that what's
current there. E.g.: one prefix from two sessions:

bird> show route table master 178.167.128.0/17
178.167.128.0/17   via 185.6.36.58 on ens33 [pb_0100_as34218 2017-06-13]
* (100) [AS34218i]
                   via 185.6.36.17 on ens33 [pb_0034_as2110 2017-06-13]
(100) [AS34218i]

- the medium term plan is still to remove the perl script in favour of
Birdseye.


>>> 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.

> Ok, that makes sense. However it is not easy with birdseye to query for
> filtered prefixes. Do you plan to add such functionality?

I suspect we just need to query the protocol table and the master table
as you've suggested above.

If anything needs to be added, we'll add it :-D

 - Barry