How does Traceroute work?

[Wazoo]

Interesting ... but where does tracert get its IP address information? You do a tracert on any of those domains and of course it takes "forever" (>>500ms). But tracert converts the domain to an IP address before it starts looking for connections and that part of the process appears to be just about instantaneous. I suppose it could be in the order of 500ms but anything in excess of 20ms should be appreciable and there just doesn't seem to be an appreciable delay

One of those thngs that's not readily seen/found ... so, had to do it the hard way, which of course fell into that situation of where and when to find the time to locate the data, pick out enough to come up with at least a clue, then sort out how to write something up.

First of all ... seven different traceroute source code files located, exploded, analyzed ...

In a nutshell .... the first thing done is a lookup for the 'A Record' via a RADB listing .. this gets one that 'almost immediate" [traceroute to 100.100.1.100] message displayed .... Part of the 'secret' you're asking about is that the "A Record" is nothing but "Domain --> IP address" (the RADB thing is yet another whole different discussion)

Anyway, now that the 'source IP address' (typically 'your' computer) and the 'target IP address' has been found, the 'real' traceroute stuff starts. After sorting through all that source code, ths is another thing that is actually more amazing that it works as fast as it does (actually some of the thoughts were more like 'worked at all' .. <g>)

Example source available on-line ... ftp://ftp.login.com/pub/software/traceroute/traceroute.c

The tool-set offered at http://pwhois.org/lft/ looks pretty wild also ...

[Farelf]

One of those thngs that's not readily seen/found ... so, had to do it the hard way, which of course fell into that situation of where and when to find the time to locate the data, pick out enough to come up with at least a clue, then sort out how to write something up....

Thanks Wazoo! Noting RADB = Routing Arbiter Data Base - probably.

[dbiel]

Thanks Wazoo! Noting RADB = Routing Arbiter Data Base - probably.

Or possibly Routing Assets Database see http://en.wikipedia.org/wiki/RADB

Edit: trying to find the definition of Routing Arbiter Data Base has been very challenging.

There are lots of references to RADB = Routing Arbiter Data Base with maybe notes like:

Glossary - RADB

Routing Arbiter Data Base

No description available.

RFC2901 makes reference to it.

One reference I did find as part of a "Peering Agreement"

3. The participans agree to use the Routing Registry provided by the Routing Arbiter (RA) via the Routing Arbiter DataBase (RADB) - source: N/MCI Contract N00024-00-D-6000 Attachment #10 Interface Control Document

This Navy/Marine Corps contract document is huge, this attachement #10 is only 173 pages long. but when you note the size of the contract

Electronic Data Systems Corp., Herndon, Va., is being awarded a $1,916,000,000 modification to previously awarded contract (N00024-00-D-6000)

The lengthy contract does make sense. sorry, I got a bit off track

And finally something that looks like a definition

16. What is the Internet Routing Registry?

The IRR is a way for ASN's to publicize their own intended routing policies without having to request a change from a go-between.

The RADB which stands for the Routing Arbiter Data Base, which is part of the IRR, is part of a joint project between Merit and ISI. For full details contact: http://www.ra.net/routing.arbiter/RA/index.html.

The Routing Arbiter is a project of the US National Science Foundation. As part of that project, it runs a routing registry database.

That database (the RAdb) forms part of the IRR collection of databases. The RIPE database is not part of the RAdb but does participate in the IRR. At present, there are five entities that contribute to the IRR effort and more are expected. Today, all the contributing registries use the RIPE-181 database format.

The Routing Arbiter can be contacted via auto-mail handlers that accept batch updates via email. An example of a routing update appears below:

password: xxxxxxxx

*rt: 138.134.0.0/16

*de: NET-IEC

*or: AS378

*mb: AS378-MNT

*ch: 950724

*so: RIPE

The *rt: tag identifies the net and the routing policy is based on *or: tag. An example of a routing policy is presented below:

aut-num: AS378

descr: ILAN

descr: Israeli Academic and Research Network

as-in: from AS1755 100 accept ANY

as-in: from AS174 100 accept ANY

as-in: from AS3339 100 accept AS3339

as-out: to AS1755 announce AS378 AS3339

as-out: to AS174 announce AS378 AS3339

as-out: to AS3339 announce ANY

default: AS174 10

default: AS1755 20

default: AS3339 30

guardian:

mnt-by: AS378-MNT

admin-c: Hank Nussbacher

tech-c: Hank Nussbacher

changed: 950627

source: RIPE

Source: http://www.irbs.net/internet/nanog/9508/0050.html

[Farelf]

This seems to be an excellent resource, TraceRoute.org. Some of the traces are very rapid indeed. hazefoul.net still times out through dnsstuff (hazefoul currently residing in Poland) and tracert from my location times out too - but some of the traces available through the above are lightning fast (as they ought to be), which is beside the point in terms of this topic but a reminder perhaps (to self at least) about toolkit selections. And, indeed, with intermediary routing, just the thing to explore contentions of query blocking. I am starting to think that some of what might appear to be blocking is no such thing, just to stay O/T for a tick longer. Sorry.

[Wazoo]

This seems to be an excellent resource, TraceRoute.org.

Apologies .. I see now that I didn't post that link .. although that was one of my first stops for data .... been in my BookMarks for years ... I beleve the source code link I did reference is listed on this very page ....

Some of the traces are very rapid indeed. hazefoul.net still times out through dnsstuff (hazefoul currently residing in Poland) and tracert from my location times out too - but some of the traces available through the above are lightning fast (as they ought to be), which is beside the point in terms of this topic but a reminder perhaps (to self at least) about toolkit selections.

But also explains my comment about checking seven different code packages ... all a but different, flag switches to extend capabilities on some of them, the number of probes in an averaged output dsplay as compared to those that would only send a single probe .. oh yeah, viva le difference ... or thanks for the confusion ....???

And, indeed, with intermediary routing, just the thing to explore contentions of query blocking. I am starting to think that some of what might appear to be blocking is no such thing, just to stay O/T for a tick longer. Sorry.

UDP or not, Cisco router or not, IPTables or not, fancy scripting or not, screwball configuration or not .... yep, hard to tell at times

[Farelf]

... I beleve the source code link I did reference is listed on this very page ....

Ah, so it is - sorry, first time I clicked on that link I was left with a blank page. Maybe the connection was a little slow or maybe my PC was still a bit woozy after the last M$ update (the case where you get the dialog when you're shutting down - "Updates ready to install. Install first then automatically shut down?" OWTTE). Twice that's happened, twice I've agreed (diff configurations) twice my PCs didn't shut down at the end, wouldn't shut down normally, twice they (virtually) froze with errors¹ the first few times revisiting the scene of the crime (don't blame 'em myself), twice they took days to return to "normal" following the inevitable hard boot. Just as well they repair themselves , if only they'd do it more quickly and with less in the way of histrionics.

¹The instruction at "0x745f2780" referenced memory at "0x00000000". The memory could not be "read". Well, duh! This one appeard at odd times when shutting down too. Darn, O/T again.