All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Network detour: Phoenix to Houston via Newark?
Here's some mtr output from my Chromebook's Linux container. May I please have some help with the questions below? Additional comments and suggestions also appreciated! Thanks!
chronos@penguin:~/servers/redacted$ mtr -brzw xxx.xxx.xxx.xxx
Start: 2024-08-28T22:12:06-0700
HOST: penguin Loss% Snt Last Avg Best Wrst StDev
[ . . . ]
8. AS6461 0.lag-58.ter1.phx2.us.zip.zayo.com (208.185.98.117) 70.0% 10 24.6 25.2 24.6 25.7 0.6
9. AS3356 4.68.68.41 0.0% 10 40.7 43.1 24.7 143.7 36.2
10. AS3356 ae7.3601.bear2.Houston1.net.lumen.tech (4.69.216.209) 80.0% 10 52.1 52.1 52.0 52.1 0.1
[ . . . ]
Why is the loss so high in Hop 8 and Hop 10? I hear that packets are moving through the router's forwarding plane but that the traceroute is being handled by the router's control plane. Therefore, supposedly, the Loss % reported by
mtris not related to actual packet loss. Is what I have heard actually correct?As can be inferred from the "phx" in the Hop 8 output, Hop 8 probably is in Phoenix. And as can be inferred from the "Houston1" in the Hop 10 output, Hop 10 probably is in Houston. However, according to https://www.ip2location.com/4.68.68.41, Hop 9 is in Newark. Is 4.68.68.41 really in Newark?
How does it make sense for Zayo in Phoenix to route packets intended for an AS that peers with Lumen in Houston through Newark? It is Zayo in Phoenix which is setting the next step in the route beyond Phoenix, right?
What explains why 4.68.68.41 (also AS3356, Lumen) doesn't seem to have a reverse IP address? Is there some benefit or other reason that could explain why Lumen doesn't have a reverse IP address set on 4.68.68.41 but does have a reverse IP address set on 4.69.216.209?
Is there something special, different, or interesting about 4.68.68.41 within Lumen's overall network structure?
Thanks!
Comments
You cannot trust any geolocation database.
Look at the best ping. with a 0.1 difference, the correct assumption is that 4.68.68.41 is also in pheonix. If it was actually in newark, you'd see a ping of 80.
The best ping is usually immune to ICMP de-prioritization issues.
Wouldn't give any attention to the loss in the middle of a MTR. You only care what the end point looks like. However if loss is present at the end point then it will show up on the points before that and that's when you can start to care.
Here's a great example of an MTR I would be complaining about (Telia "planned works")
The end point was sitting at around 15-30% so yeah this would be something you could raise.
https://archive.nanog.org/sites/default/files/10_Roisman_Traceroute.pdf is a good read for understanding traceroutes/mtrs, talks about your #1 and lots of other good information.
This is what https://ipinfo.io/4.68.68.41 shows and they also have proof.
When I went to https://ipinfo.io/4.68.68.41, it said Phoenix. Copy and paste from the page:
IP address details
4.68.68.41
Phoenix, Arizona, United States
Other providers place this IP in New York, New York, US, 3,177.6 kms away from its actual location. We're confident we have it right. See our evidence.
Summary
ASN AS3356 - Level 3 Parent, LLC
Hostname No Hostname
Range 4.0.0.0/9
Company Level 3 Parent, LLC
Hosted domains 0
Privacy False
Anycast False
ASN type ISP
Abuse contact [email protected]
IP Geolocation
City Phoenix
State Arizona
Country United States
Postal 85001
Local time 10:46 PM, Friday, August 30, 2024
Timezone America/Phoenix
Coordinates 33.4484,-112.0740
When I went to https://ipinfo.info/html/ip_checker.php and input 4.68.68.41, it said the location was Pittsburgh. Copy and paste from the ip_checker.php link:
ip: "4.68.68.41"
type: "ipv4"
continent_code: "NA"
continent_name: "North America"
country_code: "US"
country_name: "United States"
region_code: "PA"
region_name: "Pennsylvania"
city: "Pittsburgh"
zip: 15222
latitude: 40.44779968261719
longitude: -79.9935531616211
location: Object {}
geoname_id: 5206379
capital: "Washington D.C."
languages: Object {}
code: "en"
name: "English"
native: ""English""
country_flag: "https://assets.ipstack.com/flags/us.svg"
country_flag_emoji: "🇺🇸"
country_flag_emoji_unicode: "U+1F1FA U+1F1F8"
calling_code: "1"
is_eu: false
time_zone: Object{}
id: "America/New_York"
current_time: "2024-08-30T23:43:37-04:00"
gmt_offset: -14400
code: "EDT"
is_daylight_saving: true
currency: Object{}
code: "USD"
name: "US Dollar"
plural: "US dollars"
symbol: "$"
symbol_native: "$"
connection: Object{}
asn: 3356
isp: "Level 3 Parent LLC"
security: Object{}
is_proxy: false
proxy_type: null
is_crawler: false
crawler_name: null
crawler_type: null
is_tor: false
threat_level: "low"
threat_types: null
Phoenix it is, I think, as @bobert said.
That's ICMP filtering
@Not_Oles : ipinfo.io != ipinfo.info
for those not looking too closely, this might be confusing.
two different sites show two different results.
and the comment/criticism about various geolocation sites it resoundingly true!
(but yes, it's clearly in phx. prolly in the same datacenter)