peeringtraceroute
How does the traceroute -A command work? How does the program look up the ASN? On which protocols or databases does the query depend? Can I recreate the -A option?
I am using this version: Modern traceroute for Linux, version 2.0.18, Jun 30 2012.
I's not exactly the answer at your question, but that a simple (but limited) way to do (in certain case) what you want. I'm coping-post the option -R of ping man page:
-R Record route. Includes the RECORD_ROUTE option in the ECHO_REQUEST packet and displays the route buffer on returned packets. Note that the IP header is only large enough for nine such routes. Many hosts ignore or discard this option.
So you can see also the return path of the ECHO_REQUEST, that is not the exit interface (that you are asking about) unless the outgoing path is the same of the come back path. Only in this case, the returning path is the IP address of the outgoing interface you are asking for.
That's an real example on my internet provider net, maybe not so clear, but I don't have just now some router to link each other :)
traceroute 10.2.105.178
traceroute to 10.2.105.178 (10.2.105.178), 30 hops max, 60 byte packets
1 192.168.1.254 (192.168.1.254) 3.418 ms 3.575 ms 4.021 ms
2 10.189.48.1 (10.189.48.1) 11.237 ms * *
3 10.2.105.178 (10.2.105.178) 15.235 ms * *
ping -R 10.2.105.178 PING 10.2.105.178 (10.2.105.178) 56(124) bytes of data.
64 bytes from 10.2.105.178: icmp_req=5 ttl=253 time=74.1 ms NOP RR:
192.168.1.133
10.189.51.61
10.2.105.177
10.2.105.178
10.2.105.178
10.189.48.1
192.168.1.254
192.168.1.133
----omitted----
64 bytes from 10.2.105.178: icmp_req=6 ttl=253 time=13.0 ms NOP RR:
192.168.1.133
10.189.51.61
10.2.105.177
10.2.105.178
10.2.105.218 ##change every time, Idon't know why##
10.189.48.1
192.168.1.254
192.168.1.133
Let me try to answer this, because it's a little more complicated that it may look initially.
It seems that you already know the basic operation of traceroute but before anything else here is a very small recap:
traceroute tries to determine all the in-between steps from your host to a destination host, or just the distance, i.e. number of hops, from your host to a destination host. To do that it starts sending packets to the destination host with a "random" destination port number and a TTL that starts from 1 and keeps increasing.
The idea is that each router in between decreases the TTL by 1. Thus, if TTL reaches 0 (in reality it never does since the router that is about to decrease it to 0 produces an error before that), the router will return an ICMP "Time-to-live exceeded" error message, e.g. packet number 24 in your capture file. What you get from that is that your destination is further away and this is why you keep increasing the TTL.
When your packet has a TTL that is big enough to reach the destination, you will get a different ICMP error message: "Destination Unreachable (Port Unreachable)", e.g. packet number 208 in your capture file. What you get from that is that the last used TTL is indeed the number of hops between you and the destination node. The reason that you get an error is simply because you are sending a message to a "random" port that the destination node (hopefully) is not listening to.
Now going into specifics for your capture file:
From the manual page of traceroute we can see that each TTL is used 3 times (option '-q') and the default protocol used is UDP (option '-P'). By examining the first 3 UDP packets, i.e. packets 8-9-10, we can see indeed that the TTL is 1. The next 3, i.e. 11-12-13, have a TTL 2 and so on. So from the source perspective everything seems to go fine.
Then, after some time dependent on the delay of the network, we start getting the anticipated error messages. Thus we can see that packets 24-25-26 are "Time to live exceeded" error packets and thus meaning that the destination is further away.
This back-and-forth of attempts and errors continues, until, finally, packet 208 and on you can see "Port Unreachable" error messages, meaning that your destination has been reached.
By counting the packets you send and the responses you can actually find out even from the trace which TTL actually worked but its a tedious task :)
Hope that helped
Best Answer
A whois query is made for every IP returend.
Here is a manual example. Get one of the IPs of networkengineering.stackexchange.com
And check which AS the IP belongs to:
Whois outpus way more information. The protocol ist specified in RFC3912
Note that whois output of the regional registries differ and not all will provide the origin as. So traceroute -A will not provide AS informations for all addresses.