That would be nice indeed, but needs a bit of work to do it properly:
- Opening up a web interface to our routers directly like many others do is a bad idea IMO, as it opens up an attack vector.
- We could set up a BGP instance in a separated server (e.g. using bird-lg) and peer with our routers. *However*, due to the fact that we span over two ASNs one of which is a confederation withs 2-3 subASes, we'd need to set up multiple instances which I'm guessing it complicates things. It needs further research to see how easy it would be (help welcome :))
In the meantime, unlike most ASNs, we are generally responsive, reachable over IRC (both on our channels and other well-known networker channels) and we have a public bug tracker ;)
After looking at the various looking glass, bird-lg seems indeed the best option (doesn't need ssh access to the routers, open-source, user-friendly, supports multiple regions).
That's why I setup a POC at https://af-lg.wmflabs.org/ This only includes esams.
It consists of 4 main parts:
- cr2-esams peering with bird (with next hop self)
- A bird daemon receiving the full BGP view
- lgproxy.py that talks to a single bird daemon, each "region" needs its own lgproxy.py. It's also the script than runs the traceroutes.
- lg.py the web interface that relays queries to lgproxy.py
A few current caveats:
- As bird/bird-lg is running in eqiad, the traceroutes originate from eqiad. For an optimal deployment, we would need to have a bird/lgproxy.py instance in each region. Is there a host we could use for that?
- The routes add the mention "via 10.68.16.1 on eth0"as it's the route bird uses to reach the next hop "BGP.next_hop: 126.96.36.199" as it adds confusion, we could remove it from the code, like what other do: http://lg.as5580.net/prefix_detail/all/ipv4?q=188.8.131.52
Following steps if we want to move forward would be to write init scripts for lg.py and lgproxy.py, puppetize bird/birdlg/apache, and have all routers peer with it.
The amount of work required to properly deploy a (muti-dc) looking glass is, so far, not worth the benefits of having and maintaining one.
- Peering with the RIPE RIS provides a looking glass for 3 of our 5 DCs
- As said by Faidon, we're very quick to reply to NOC email and IRC messages (usually less than 24h)
- No routing issue would have been resolved faster with a looking glass (as far as I know)