[db-wg] NOC / Lookinglass Information in the RIPE DB

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 311 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/db-wg/attachments/20070328/36cc73da/attachment.sig>