Can anyone explain the logic of this traceroute command, what do you learn from this command?
- Thread starter Brief-Wishbone9091
- Start date
Can you be more specific about where you are confused or what you do not understand?
I am struggling with several things I see here myself, especially the entries at the end (entries 10-13).
The last two IP addresses in the traceroute are not globally routable from the internet, so I cannot explain how your traceroute got ping returns from them.
The "invlogic.com" reverse lookup isn't adding up. The invlogic.com domain appears to be affiliated with the same people around Linux.org. I wonder if Rob or the people who own Linux.org own invlogic.com too. Previous versions of the www.invlogic.com website had a link to www.linux.org on the Contact Us page.
The IP address for "www.linux.org" is incorrect. You got "198.182.196.56". The correct addresses are: 104.26.14.72, 104.26.15.72, and 172.67.73.26. I checked from multiple DNS sources around the world - same results every time.
-> Can you please explain your DNS configuration?
-> Could you have some old "hardwired" DNS entries in a server or hosts file somewhere?
-> Is this traceroute from a long time ago?
Late Edit: I noticed an autocorrection typo and fixed it. No content changes.
I am struggling with several things I see here myself, especially the entries at the end (entries 10-13).
The last two IP addresses in the traceroute are not globally routable from the internet, so I cannot explain how your traceroute got ping returns from them.
The "invlogic.com" reverse lookup isn't adding up. The invlogic.com domain appears to be affiliated with the same people around Linux.org. I wonder if Rob or the people who own Linux.org own invlogic.com too. Previous versions of the www.invlogic.com website had a link to www.linux.org on the Contact Us page.
The IP address for "www.linux.org" is incorrect. You got "198.182.196.56". The correct addresses are: 104.26.14.72, 104.26.15.72, and 172.67.73.26. I checked from multiple DNS sources around the world - same results every time.
-> Can you please explain your DNS configuration?
-> Could you have some old "hardwired" DNS entries in a server or hosts file somewhere?
-> Is this traceroute from a long time ago?
Late Edit: I noticed an autocorrection typo and fixed it. No content changes.
Last edited:
Your home computer isn't connected to the same switch or router as... well, the entire internet.
google.com, linux.org, youtube.com, wikipedia.com, etc...
You usually have to go through dozens of switches and routers to get where you are wanting to be.
Usually you'll have a wifi router or something local in your house, which talks to internet providers
router ( xfinity, at&t, spectrum, comcast, etc... ) which then talks to yet another router, which then goes to a regional
router, usually to a backbone router, and then the process kind of reverses itself, from the backbone, back to a regional
router, back to an ISP router, and eventually to the destination subnet router ( probably in a data-center hundreds of
miles from your house ).
traceroute shows you all of the "hops" along the way. The IP address of the switch or router, and how long
( in milliseconds ) it took to traverse each hop along the way.
You can use traceroute to troubleshoot things, for example if linux.org is unreachable, run traceroute
and it will tell you where along the trail the path is broken.
Sometimes, companies and ISPs block broadcasting their addresses, especially at firewalls.
Then you'll just see something like * * * * * * instead of addresses.
google.com, linux.org, youtube.com, wikipedia.com, etc...
You usually have to go through dozens of switches and routers to get where you are wanting to be.
Usually you'll have a wifi router or something local in your house, which talks to internet providers
router ( xfinity, at&t, spectrum, comcast, etc... ) which then talks to yet another router, which then goes to a regional
router, usually to a backbone router, and then the process kind of reverses itself, from the backbone, back to a regional
router, back to an ISP router, and eventually to the destination subnet router ( probably in a data-center hundreds of
miles from your house ).
traceroute shows you all of the "hops" along the way. The IP address of the switch or router, and how long
( in milliseconds ) it took to traverse each hop along the way.
You can use traceroute to troubleshoot things, for example if linux.org is unreachable, run traceroute
and it will tell you where along the trail the path is broken.
Sometimes, companies and ISPs block broadcasting their addresses, especially at firewalls.
Then you'll just see something like * * * * * * instead of addresses.
traceroute www.linux.org
traceroute to www.linux.org (104.26.14.72), 30 hops max, 60 byte packets
1 _gateway (10.0.0.1) 13.157 ms 13.127 ms 13.113 ms
2 96.120.60.97 (96.120.60.97) 22.451 ms 27.010 ms 27.176 ms
3 ae-253-1210-rur02.longview.wa.bverton.comcast.net (162.151.214.181) 29.379 ms 30.001 ms 29.475 ms
4 ae-58-ar01.troutdale.or.bverton.comcast.net (68.87.216.193) 35.180 ms 35.006 ms 35.272 ms
5 be-36231-cs03.seattle.wa.ibone.comcast.net (68.86.93.57) 35.793 ms be-36211-cs01.seattle.wa.ibone.comcast.net (68.86.93.49) 35.590 ms be-36241-cs04.seattle.wa.ibone.comcast.net (68.86.93.61) 35.362 ms
6 be-2112-pe12.seattle.wa.ibone.comcast.net (96.110.34.130) 35.962 ms 22.395 ms 21.974 ms
7 50.208.235.222 (50.208.235.222) 20.131 ms 16.125 ms 27.725 ms
8 172.71.140.3 (172.71.140.3) 18.245 ms 108.162.243.11 (108.162.243.11) 53.433 ms 172.71.148.3 (172.71.148.3) 23.834 ms
9 104.26.14.72 (104.26.14.72) 30.638 ms 30.590 ms 30.475 ms
The first hop... ( 10.0.0.1 ) is my local router in my house.
I live in Southwest Washington state. I recognize that longview, beaverton, and troutdale
are all towns around where I live ( near Vancouver WA )
I see that the Seatlle ibone is the backbone for most of the traffic.
It appears the majority of this traffic goes through comcast owned devices.
traceroute to www.linux.org (104.26.14.72), 30 hops max, 60 byte packets
1 _gateway (10.0.0.1) 13.157 ms 13.127 ms 13.113 ms
2 96.120.60.97 (96.120.60.97) 22.451 ms 27.010 ms 27.176 ms
3 ae-253-1210-rur02.longview.wa.bverton.comcast.net (162.151.214.181) 29.379 ms 30.001 ms 29.475 ms
4 ae-58-ar01.troutdale.or.bverton.comcast.net (68.87.216.193) 35.180 ms 35.006 ms 35.272 ms
5 be-36231-cs03.seattle.wa.ibone.comcast.net (68.86.93.57) 35.793 ms be-36211-cs01.seattle.wa.ibone.comcast.net (68.86.93.49) 35.590 ms be-36241-cs04.seattle.wa.ibone.comcast.net (68.86.93.61) 35.362 ms
6 be-2112-pe12.seattle.wa.ibone.comcast.net (96.110.34.130) 35.962 ms 22.395 ms 21.974 ms
7 50.208.235.222 (50.208.235.222) 20.131 ms 16.125 ms 27.725 ms
8 172.71.140.3 (172.71.140.3) 18.245 ms 108.162.243.11 (108.162.243.11) 53.433 ms 172.71.148.3 (172.71.148.3) 23.834 ms
9 104.26.14.72 (104.26.14.72) 30.638 ms 30.590 ms 30.475 ms
The first hop... ( 10.0.0.1 ) is my local router in my house.
I live in Southwest Washington state. I recognize that longview, beaverton, and troutdale
are all towns around where I live ( near Vancouver WA )
I see that the Seatlle ibone is the backbone for most of the traffic.
It appears the majority of this traffic goes through comcast owned devices.
Yup. It looks pretty normal to me. You'll be resolving to a CloudFlare IP address as that's the CDN in use here. The rest is bog standard stuff - unless I'm missing something.
I just read @dos2unix post and it made me look again at the original post.
-> Is the original question asking for help to understand traceroute and how to interpret the output? (That's how @dos2unix' responded.)
... or ...
-> Is @Brief-Wishbone9091 asking about the actual traceroute results in their example in the original post? That's the question I answered in post #2 above. As I said above, I found some strangeness in the traceroute results. The most salient points are:
-> Is the original question asking for help to understand traceroute and how to interpret the output? (That's how @dos2unix' responded.)
... or ...
-> Is @Brief-Wishbone9091 asking about the actual traceroute results in their example in the original post? That's the question I answered in post #2 above. As I said above, I found some strangeness in the traceroute results. The most salient points are:
- The IP address for www.linux.org is incorrect or possibly old in that original traceroute output.
- The IP addresses in the last two entries are inaccessible from the internet. Those addresses are not in the global routing tables.
Did you check the IP address for "www.linux.org" in the original traceroute output? When I did DNS lookups from several sources, that IP address (198.182.196.56) was never returned.
Last edited:
The IP should vary based on your geographical location. It's a CDN. It may well not respond to queries. Cloudflare does some strange stuff behind the scenes.
I have to agree with @sphen
the dns in the OP here looks weird.
~]$ dig www.linux.org
; <<>> DiG 9.18.14 <<>> www.linux.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41972
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.linux.org. IN A
;; ANSWER SECTION:
www.linux.org. 300 IN A 172.67.73.26
www.linux.org. 300 IN A 104.26.14.72
www.linux.org. 300 IN A 104.26.15.72
;; Query time: 18 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue May 16 11:19:15 PDT 2023
;; MSG SIZE rcvd: 90
the dns in the OP here looks weird.
~]$ dig www.linux.org
; <<>> DiG 9.18.14 <<>> www.linux.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41972
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.linux.org. IN A
;; ANSWER SECTION:
www.linux.org. 300 IN A 172.67.73.26
www.linux.org. 300 IN A 104.26.14.72
www.linux.org. 300 IN A 104.26.15.72
;; Query time: 18 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue May 16 11:19:15 PDT 2023
;; MSG SIZE rcvd: 90
That's true, I have seen that before. World wide providers such as AWS, Azure, GoDaddy, and likely Cloudflare
( I am less familiar with cloudflare than the others ) often have geographically diverse mirror sites.
But still usually they show up in a DNS query. Youtube for example is notorious for this.
; <<>> DiG 9.18.14 <<>> www.youtube.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35847
;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.youtube.com. IN A
;; ANSWER SECTION:
www.youtube.com. 23896 IN CNAME youtube-ui.l.google.com.
youtube-ui.l.google.com. 196 IN A 142.251.211.238
youtube-ui.l.google.com. 196 IN A 142.251.33.78
youtube-ui.l.google.com. 196 IN A 142.250.217.78
youtube-ui.l.google.com. 196 IN A 142.250.217.110
youtube-ui.l.google.com. 196 IN A 142.251.215.238
youtube-ui.l.google.com. 196 IN A 172.217.14.206
youtube-ui.l.google.com. 196 IN A 172.217.14.238
youtube-ui.l.google.com. 196 IN A 142.250.69.206
youtube-ui.l.google.com. 196 IN A 142.251.33.110
There are nine different IPs for the same website.
If you do a traceroute, you should get to one of these. There are technically only 13 DNS root server.
Root Servers
But some foreign countries diverge and have their own internal root DNS servers that either block or
re-route certain domains.
You guys are on the right track, but observe that the public IP address for "www.linux.org" shows up as "198.182.196.56" in that example traceroute in the original post.
The 198.182.196.56 IP address is a valid public IP address. It is not in a reserved range like 10-net or 192-168-net.
-> The interesting point is that 198.182.196.56 is not in the internet routing tables, nor does there seem to be an AS number for it. I can't ping it or see a website from anywhere I have servers because there is no route to it. Logic dictates that it must be a publicly accessible server with a route to it if it serves "www.linux.org", right?
How did the DNS lookup return "www.linux.org" for that IP address? How did it respond to the traceroute ping if you can't route to it? Something is fishy.
The 198.182.196.56 IP address is a valid public IP address. It is not in a reserved range like 10-net or 192-168-net.
-> The interesting point is that 198.182.196.56 is not in the internet routing tables, nor does there seem to be an AS number for it. I can't ping it or see a website from anywhere I have servers because there is no route to it. Logic dictates that it must be a publicly accessible server with a route to it if it serves "www.linux.org", right?
How did the DNS lookup return "www.linux.org" for that IP address? How did it respond to the traceroute ping if you can't route to it? Something is fishy.
Last edited:
I get an IP address for linux.org as:
Which will be what CloudFlare provided.
You'll see the same thing (with a different CDN) if you check linux-tips.us. You'll see various addresses, as discussed here previously.
104.26.14.72Which will be what CloudFlare provided.
You'll see the same thing (with a different CDN) if you check linux-tips.us. You'll see various addresses, as discussed here previously.
Yes, the IP address in your post is one of the three IP addresses that is returned from a DNS lookup of "www.linux.org". Both @dos2unix and I mentioned the same three IP addresses in our posts above. All three IP addresses respond to pings, by the way.
I understand that Cloudflare's CDN could be dynamic and swap the servers that respond to www.linux.org browser requests, but I would expect Cloudflare to update the DNS entries to return the new public IP addresses accordingly. (True, there are potential DNS caching issues if you are not paying attention while testing.)
The IP address for "www.linux.org" in the OP's original post traceroute went to a different IP address, 198.182.196.56. I cannot explain it. It does not respond to pings because there is no way to route a packet to it.
I am repeating myself and have little to add. I hope that @Brief-Wishbone9091 jumps in to tell us more.
Yeah, that's why I figure it's just Cloudflare doing Cloudfare things. You don't get to route a packet to it nor does it respond to pings. The latter is pretty easy (as I recall it's just disabling ICMP echo requests), the former may be because of all sorts of things such as simply not responding to any of your requests because you're not on a specific subnet or have the 'wrong' IP address. I had a VPS at one point that had a popular/short domain name and ended up disabling ping responses. I wouldn't care so much today, but the overhead was measurable back then. The site still worked just fine, it just didn't respond if you pinged it.
So, that's my official guess - unless I'm missing something. It's CF doing CF things 'cause they're CF. Frankly, they control a disturbingly large amount of internet traffic.
Code:
[flip@flop ~]$ whois 198.182.196.56
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2023, American Registry for Internet Numbers, Ltd.
#
NetRange: 198.182.196.0 - 198.182.196.255
CIDR: 198.182.196.0/24
NetName: INVLOGICCORP
NetHandle: NET-198-182-196-0-1
Parent: NET198 (NET-198-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: Innovative Logic Corp (ILC-4)
RegDate: 1993-08-25
Updated: 2021-12-14
Ref: https://rdap.arin.net/registry/ip/198.182.196.0
OrgName: Innovative Logic Corp
OrgId: ILC-4
Address: P.O. Box 1068
City: Laurel
StateProv: MD
PostalCode: 20725-1068
Country: US
RegDate: 1993-08-25
Updated: 2011-09-24
Ref: https://rdap.arin.net/registry/entity/ILC-4
OrgAbuseHandle: MM141-ARIN
OrgAbuseName: McLagan, Michael
OrgAbusePhone: +1-315-393-1978
OrgAbuseEmail: [email protected]
OrgAbuseRef: https://rdap.arin.net/registry/entity/MM141-ARIN
OrgTechHandle: MM141-ARIN
OrgTechName: McLagan, Michael
OrgTechPhone: +1-315-393-1978
OrgTechEmail: [email protected]
OrgTechRef: https://rdap.arin.net/registry/entity/MM141-ARIN
RTechHandle: MM141-ARIN
RTechName: McLagan, Michael
RTechPhone: +1-315-393-1978
RTechEmail: [email protected]
RTechRef: https://rdap.arin.net/registry/entity/MM141-ARIN
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2023, American Registry for Internet Numbers, Ltd.
#Is that CloudFare?
A quick look says it's an HE.com domain, a pretty large company controlling the actual hardware (the lines themselves) as far as I know. So, it may be HE pairing (peering? I'm not sure which word would be right) with CF or something else entirely. I don't think CF owns sizable chunks of the infrastructure, where HE does.
(whois the invlogic.com.)
I would quit putting effort into this topic since OP hasn't responded since any of you have responded.
OP
Brief-Wishbone9091
Member
I'm in office rn. I'll respond soon.
Condobloke
Well-Known Member
Take your time, @Brief-Wishbone9091 , there is no hurry.
