Looking Glass Client Configuration

[tbaschak]

Hi!

We're using arouteserver to manage our bird2 routeservers at the Manitoba Internet Exchange (MBIX.ca) and we've run into an issue after upgrading from bird1.x to bird2.x that our local additions aren't there anymore, which means we're probably using the product wrong.

We have an external looking glass which used to receive unfiltered routes from the route servers, so that members could troubleshoot networks not propagating thru MBIX. We use the arouteserver communities with OpenBSD's looking glass to provide views of routes that are being filtered for various reasons.

Since the looking glass is not connected to the peering LAN, we use multihop BGP across our own management network to get the routes from MBIX route servers to the looking glass which is hosted in our "services" ASN. We used to use a local4 and local6 but I think that got erased during an upgrade to bird2, and either way that wouldn't work for bird2.

So, the question is, should we be specifying the looking glass in the clients.yml file (and how would that be done for filter-free vs standard mode), or a template? I feel like this is a documentation/config question that other IXPs would benefit from having probably mentioned in the documentation somewhere.

Thanks! We very much appreciate this tool and how much time it saves our small volunteer IXP.

[pierky]

Hello @tbaschak,

I don't think that for your use case configuring the "special" client in clients.yml would be the best solution. I think that using the customization options of ARouteServer could be better: https://arouteserver.readthedocs.io/en/dev/CONFIG.html#customization

A combination of --use-local-files and BIRD hooks could be the most elegant and flexible way to achieve your goal.

I think this is what you described as "a local4 and local6". Not sure why you say that they won't work in BIRD2. Most likely they'll need some adjustments in terms of syntax and lines of configuration, but the overall idea should still be fine.

A side tool which I built and that is linked to ARouteServer could probably help you to see how a similar scenario can be implemented: https://invalidroutesreporter.readthedocs.io/en/latest/

Please let me know if this helps.

[bluikko]

Since the looking glass is not connected to the peering LAN, we use multihop BGP across our own management network to get the routes from MBIX route servers to the looking glass

I would like to add to this point that arouteserver currently uses the tables master4/master6 of type sorted.
Using multihop requires to use trie type tables so you'd need to add specific tables for the multihop peer with pipes, or change the master4/master6 tables to be trie type after generating bird.conf.

In the BIRD documentation it is stated that the trie tables might use more memory but might be faster in some cases.

I do not have data on whether it would be a good idea to change arouteserver to use trie tables instead, then those above listed workarounds would not be required.
Flowspec validation will also not work with sorted tables.

It might be a good idea to discuss whether the tables should stay sorted or not.