Shane Kerr wrote: [..]

I like the "reachable:" idea. It seems like a good debugging tool.

But I think the looking glass idea is kind of backwards. Looking glasses know which routes they track, not the other way around, right?

The reachable: is $you -> $them Lookingglasses in general provide a traceroute[6] and a ping[6] facility and maybe, if one is lucky also a BGP view. This provides one with a view from $them -> $you. Having both of these thus enables one to do what Randy shows in his presentation, from another reply: Randy Bush wrote:

...

(I love BGPPlay btw :) and the debogon projects. The latter project can be used by a network admin to check if that, to be debogonized network, is reachable. This does not help with network problems that might occur at other places.

you may find the work of olaf, steve, james, and i, presented at the recent apops meeting, intersesting

http://rip.psg.com/~randy/070228.apnic-bogons.pdf

Indeed it is very interesting, thanks, that probably involved a lot of work. I guess that to be able to do that study you had to contact the ISP's directly or ask people to participate in your query to figure out where the problem might be (it notes asking on NANOG and I recall seeing that mail). If the information on where to find a reachable address in a prefix was available then one could at test anchor <-> reachable already, doing a traceroute where needed. When a lookingglass is available one could do a traceroute/ping from their site to you. With a BGP interface then one can of course also debug where the problem might further be. That all without any further human intervention which can save quite some time. Thinking of that, but that would be a bit tougher to get implemented I guess, to automate it, one could maybe even have: lg-traceroute4: http://lg.as23456.net/auto/traceroute/?target=<target> lg-traceroute6: http://lg.as23456.net/auto/traceroute6/?target=<target> The ISP, thus can define where the webinterface for a certain tool is. We would have to define what parameters are possible, for traceroute4/6 that would be easy, as target is enough. Maybe a second parameter 'src' could be added to specify which source, as from the 'reachable' header could be used to trace from, that way ISP's with a lot of netblocks could have 1 'lg' object (the ASN object comes to mind) with the lg-traceroute[4|6] headers in it and point inet(6)num's there, ASN's are already coupled then. In the inet(6)num we could then add a 'lg-source' attribute that is a specific source in that block that people can traceroute from. The lg-source parameter can be optional, to avoid having a dedicated address in every block one has; usually the network is behind the same location anyway and it is wasteful to allocate an IP for that purpose from every /24 or so. Being able to reach the border router of a network is usually good enough to test connectivity. This comes a bit into the area of TTM too then I guess, but then not having the machine watch networks 24/7 and at a considerable lower cost. Then again, if there would be tarball/deb/rpm etc of this setup, or at least the tools and the cgi, then I guess quite some ISP's might want to make this available for their network. The big problem remains then though that the ISP's who participate are usually the ones who also configure their networks correctly and keep filters in sync etc, the ones who then don't have these facilities tend to also slack off a bit in maintaining those things unfortunately. Of course, it is easy to ratelimit these tools by allowing only X queries per Y minutes over all IP's globally, just in case some kid would think that it is fun to do traceroutes all over the place from his/her botnet. Greets, Jeroen