Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Looking Glass Client Configuration #127

Open
tbaschak opened this issue Dec 12, 2023 · 1 comment
Open

Looking Glass Client Configuration #127

tbaschak opened this issue Dec 12, 2023 · 1 comment

Comments

@tbaschak
Copy link

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
Copy link
Owner

pierky commented Dec 13, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants