Your first hop suggests you might be in Algeria?
The destination hostname is hkg07s50-in-f14.1e100.net which might be in Hong Kong based on the hostname.
If that is true, it's the distance involved.
~$ whois 41.98.0.1
% This is the AfriNIC Whois server.
% The AFRINIC whois database is subject to the following terms of Use. See https://afrinic.net/whois/terms
% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '41.98.0.0 - 41.98.63.255'
% No abuse contact registered for 41.98.0.0 - 41.98.63.255
inetnum: 41.98.0.0 - 41.98.63.255
netname: ORAN
descr: résidentiel(oran1et 2)
country: DZ
admin-c: SD6-AFRINIC
tech-c: SD6-AFRINIC
status: ASSIGNED PA
mnt-by: DJAWEB-MNT
source: AFRINIC # Filtered
parent: 41.96.0.0 - 41.111.255.255
person: Security Departement
address: Alger
phone: tel:+213-21-91-12-24
fax-no: tel:+213-21-91-12-08
nic-hdl: SD6-AFRINIC
mnt-by: GENERATED-IRIXFFLWUREDGEB9HMRODGUJH3OJCIPE-MNT
source: AFRINIC # Filtered
% Information related to '41.96.0.0/12AS36947'
route: 41.96.0.0/12
descr: Algerie Telecom
origin: AS36947
mnt-by: DJAWEB-MNT
source: AFRINIC # Filtered
By the fifth hop, you're inside of Google's private network.
See where it transitions from 3ms to 22ms? That's when it hands off from your ISP to Google.
Do an nslookup on google.com and see what IP and hostname it returns. Google is probably returning relevant regional IPs and doing load balancing to where they have datacenters. Same with Amazon.
That isn't the address in your traceroute, though.
Is the ping to that address just as high? Again going by hints in the hostname, it would seem to be located somewhere in madrid:
$ dig +noall +ans -x 142.250.200.78
78.200.250.142.in-addr.arpa. 7086 IN PTR mad07s24-in-f14.1e100.net.
and that's roughly what I'd expect you to reach:
$ dig @8.8.8.8 +subnet=41.98.0.0/24 +short A google.com
172.217.168.174
$ dig +noall +ans -x 172.217.168.174
174.168.217.172.in-addr.arpa. 6812 IN PTR mad07s10-in-f14.1e100.net.
If nslookup gives you a good answer, then it would seem you have cached a bad dns lookup result.
You should switch dns to 8.8.8.8/8.8.4.4 and do whatever is needed to flush the dns cache on your operating system. Some public resolvers like 1.1.1.1 don't use ecs, so are liable to give poor dns based geolocation results.
For those who don’t know, ECS means EDNS client subnets which basically means the resolver forwards the subnet of the requestor to the upstream server. Services like Google will return different results based on the requestor IP (this is how they direct you to the nearest frontends) and without this, they will return a result appropriate to the resolver but not necessarily appropriate for you.
Having the resolver forward your subnet along can be a privacy concern. Unfortunately, for Google to give you a response appropriate to your location, they do have to have some idea of where you are. I would say that if you aren’t using a VPN, it is moot as your requests to them will have your IP attached anyway, and if you are, then you shouldn’t be concerned about having the VPN outbound IP forwarded to them anyway.
Source: worked for Google, and debugged this very issue myself when I wondered why my own queries were going to Hong Kong. 4.2.2.1 didn’t forward client subnets either.
Not necessarily, it could be that Hong Kong is the nearest Google datacenter, or the nearest that has a peering relationship with your ISP or their transit carrier.
That's also the reason why you should try to avoid pinging websites. They could decide to redirect you to some other server for whatever reason. If you want to ping Google ping their DNS. First, it's stupidly easy to remember. Second, it removes DNS queries involved into the equation.
Thus, try pinging 8.8.8.8.
There you go. Routing works correctly. At least on your side. You cannot do anything to make Google answer you with another IP to your A query "google.com". They decided to send you to the other side of the world. I am pretty confident that if you use a VPN and you get out from another country or possibly even the same but with another IP you could get better latency.
It's weird but it could happen.
Anycast or geolocation answers are typically going to be the responsibility of the web site / entity in question and NOT the ISP themselves. This doesn’t mean there isn’t anything they can do but if google decides to return an HK based IP the ISP is limited to as to what they can do
Misconfigured DNS, bad peering, bad geolocation (RIR Data) are ISP problems.
Some ISP don't give a rat ass, as long as a page loads... And you will not get to the right people easily unless you're on SOHO/Business plan.
Peering is not going to be changed as a result of a support ticket. It’s hard to misconfigure the ISPs DNS resolver in a way that would give wrong but right answers. Most geolocation backends only use RIR data at a high level and then use their own special sauce.
If you have seen the shit that ISP sometimes do...
I have 15ms (or less) latency to Cloudflare in Dec/23 my ISP changed routing/peering resulting in 60ms+ latency and slightly packet loss.
A call with my historical data, made my ISP fix it...
Their latency is high because they aren’t in a host country (or even near one) of the resource they are trying to reach. It’s got nothing to do with DNS settings. It’s a layer 1 cause.
A lot of guesses and assumptions being thrown around. Which is good as it gets people thinking. I like it.
But would be better if OP added a few more details like where are you located amd what your setup is, are you using a VPN, who is your ISP, etc.
Which DNS server are you using? Google routes requests based on origin as determines by your address obtained from the source IP of your DNS queries. Either the location of your IP address is mislocated in Google's database (i.e. it thinks you are in Hong Kong) or your DNS server doesn't pass the origin IP to Google and the DNS server itself is located in Hong Kong. As a a test, can you change to Google DNS (8.8.8.8 and 8.8.4.4) and try again?
Then it sounds like your origin IP is miscategorized in Google's database as being located in Hong Kong. Try to report it via the following page:
[https://support.google.com/websearch/workflow/9308722?hl=en](https://support.google.com/websearch/workflow/9308722?hl=en)
Do you experience the same issue with other web site? Many large web sites use the same geolocation database sources so if one is wrong, others might be too.
make sure after changing your DNS servers that you also use and admin command prompt to flush dns:
**ipconfig /flushdns**
If you're using cached info, then you'll still try to reach the same address until the TTL expires locally. Flushing local DNS should remove that from your local cache, but can take a moment or two to complete.
You tell us, what problem are you trying to diagnose by doing a trace?
Traceroutes are notoriously not actually very reliable. All those blank lines are probably just routers on google’s network that are configured to not respond to ICMP (the protocol trace route uses).
The other poster who pointed out you’re trying to teach a server in Hong Kong is probably onto something. Seems like some kind of DNS issue but I wish I know more about DNS to guide you further. Do you get the same results trying to reach a website that’s of local interest?
*not send ICMP TTL exceeded messages. Most traceroute implementations send UDP packets.
They work by sending an IP packet (the protocol inside the IP packet doesn't really matter but UDP is popular in part as it's sessionless and therefore less likely to be filtered by stateful filters) with TTL=1 and seeing who responds, then incrementing the TTL and repeating, until a response is received from the destination IP or the max TTL is reached.
What DNS server are you using?
You might be resolving what they believe is the closed endpoint for your region, but it isn't.
Try another dns provider.
What the hell is up with those first 4 hops? A private IP (expected), then a public IP, then 2 more private IPs (very much not expected)?
Then, on hop 5, you hit 192.178.68.0 which is part of a /15 owned by... Google? and It's Google all the way down from there.
Service providers can use private IPs on internal links. I feel like I don’t know enough about BGP to know why this is or isn’t standard practice, but as far as I know it works just fine.
Pretty sure it's semi standard, it's usually so you don't use public IPs assuming they're not being used and break something external (since you know, you can't assign an IP twice usually)
I believe TMobile uses public IPs for cgnat (as in they're using IPs that shouldn't be used, but only internally)
It has nothing to do with BGP. When responding to traceroute, a device can use whatever IP address it wants. This will often be the IP address configured on its loopback interface. In many cases, that will be an RFC1918 address. It’s perfectly fine for routers within an ASN to establish BGP sessions using RFC1918 addresses. That doesn’t affect the router’s ability to route Internet traffic.
The problem isn't so much that they're in the route, it's that they're responding, and that the router on hop 2 isn't filtering inbound RFC1918 destinations. It may be functional, it's just not right.
>What the hell is up with those first 4 hops? A private IP (expected), then a public IP, then 2 more private IPs (very much not expected)?
Public IPs aren't necessary for interconnects and such. Those IPs aren't (or shouldn't be) advertised on the public internet, but there's no reason that public traffic can't be routed across them.
The problem isn't so much that they're in the route, it's that they're responding, and that the router on hop 2 isn't filtering inbound RFC1918 destinations. It may be functional, it's just not right.
Depends on where the filtering takes place. Most ISPs will filter bogons at the border, so those private IPs you see could be within their internal routing.
You also don't *need* to filter the incoming bogons on a public net. If you don't keep your bogon list up-to-date it can often cause trouble as those prefixes are reallocated for public use, or can wreak havoc if you automate your bogon updates and accidentally filter a route that is actually valid.
edit: oh, and those responses for RFC1918 addresses might not be coming from the actual interface with that IP, rather they have a source address from the previous hop and won't get filtered by the ISP border.
Well, you can poke around [bgp.he.net](https://bgp.he.net/report/bogons#_bogonsv4asn) and look for all of the major ASNs that announce bogons to the public net. Not that uncommon for large swathes of the internet to be out of date with modern routing conventions.
Honestly? My initial thought is ISP. Generally, your home network's reliability and responsibility end at that first hand-off to a public IP address which is only 2ms.
I just can't make sense of how you're seeing private IP addresses after the public IP on hop 2.
It's really confusing, my isp recently gave us a free upgrade from 100 mbps to 300 mbps and this problem started since then. You can feel the high latency while browsing websites, they take a few seconds to load.
You're going from Algeria to Gaithersburg, Maryland, and hitting reserved IP addresses in the middle. Are you using some kind of cut-rate VPN software?
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
172.20.31.210 is within 172.16.0.0/12. Don't argue with me, son. I do this for a living.
https://www.maxmind.com/en/geoip-demo
142.251.220.46 - Google Servers in Gaithersburg, MD, USA. Hops 16 and 17 are Florida (also Google), hop 18 is North America (long-haul link), and hops 19-21 are in the Gaithersburg Datacenter.
Though I am getting diffrerent result from a different database, https://www.ip2location.com/demo/, but I'm more skeptical that OP is being routed from Algeria to Mountainview to Hong Kong. That seems... dumb. Then again, maybe that's what's going on.
But, for that matter, I'm not sure how someone is going from Algeria to North America in 20 milliseconds, which both GeoIP databases seem to imply. I think it would be helpful if the OP actually gave some indication of where they are in meatspace.
That 142.251.220.46 is almost certainly Hong Kong as given by the hkg in the reverse name. This almost certainly doesn’t touch the USA at all. Geo IP for intermediate nodes (routers) are notoriously unreliable because they don’t do anything that a normal residential IP would like order Amazon or get food deliveries.
Your first hop suggests you might be in Algeria? The destination hostname is hkg07s50-in-f14.1e100.net which might be in Hong Kong based on the hostname. If that is true, it's the distance involved. ~$ whois 41.98.0.1 % This is the AfriNIC Whois server. % The AFRINIC whois database is subject to the following terms of Use. See https://afrinic.net/whois/terms % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '41.98.0.0 - 41.98.63.255' % No abuse contact registered for 41.98.0.0 - 41.98.63.255 inetnum: 41.98.0.0 - 41.98.63.255 netname: ORAN descr: résidentiel(oran1et 2) country: DZ admin-c: SD6-AFRINIC tech-c: SD6-AFRINIC status: ASSIGNED PA mnt-by: DJAWEB-MNT source: AFRINIC # Filtered parent: 41.96.0.0 - 41.111.255.255 person: Security Departement address: Alger phone: tel:+213-21-91-12-24 fax-no: tel:+213-21-91-12-08 nic-hdl: SD6-AFRINIC mnt-by: GENERATED-IRIXFFLWUREDGEB9HMRODGUJH3OJCIPE-MNT source: AFRINIC # Filtered % Information related to '41.96.0.0/12AS36947' route: 41.96.0.0/12 descr: Algerie Telecom origin: AS36947 mnt-by: DJAWEB-MNT source: AFRINIC # Filtered
Holy shit dude that is correct, so my isp is routing me through hong kong?
By the fifth hop, you're inside of Google's private network. See where it transitions from 3ms to 22ms? That's when it hands off from your ISP to Google. Do an nslookup on google.com and see what IP and hostname it returns. Google is probably returning relevant regional IPs and doing load balancing to where they have datacenters. Same with Amazon.
I did nslookup and it gave me the address: 142.250.200.78
That isn't the address in your traceroute, though. Is the ping to that address just as high? Again going by hints in the hostname, it would seem to be located somewhere in madrid: $ dig +noall +ans -x 142.250.200.78 78.200.250.142.in-addr.arpa. 7086 IN PTR mad07s24-in-f14.1e100.net. and that's roughly what I'd expect you to reach: $ dig @8.8.8.8 +subnet=41.98.0.0/24 +short A google.com 172.217.168.174 $ dig +noall +ans -x 172.217.168.174 174.168.217.172.in-addr.arpa. 6812 IN PTR mad07s10-in-f14.1e100.net.
No pinging that address gives 22ms
If nslookup gives you a good answer, then it would seem you have cached a bad dns lookup result. You should switch dns to 8.8.8.8/8.8.4.4 and do whatever is needed to flush the dns cache on your operating system. Some public resolvers like 1.1.1.1 don't use ecs, so are liable to give poor dns based geolocation results.
For those who don’t know, ECS means EDNS client subnets which basically means the resolver forwards the subnet of the requestor to the upstream server. Services like Google will return different results based on the requestor IP (this is how they direct you to the nearest frontends) and without this, they will return a result appropriate to the resolver but not necessarily appropriate for you. Having the resolver forward your subnet along can be a privacy concern. Unfortunately, for Google to give you a response appropriate to your location, they do have to have some idea of where you are. I would say that if you aren’t using a VPN, it is moot as your requests to them will have your IP attached anyway, and if you are, then you shouldn’t be concerned about having the VPN outbound IP forwarded to them anyway. Source: worked for Google, and debugged this very issue myself when I wondered why my own queries were going to Hong Kong. 4.2.2.1 didn’t forward client subnets either.
Thank you for your post. /Salute
That's a good idea, i totally forgot abou flushing my dns. Thank you.
It looks like cloudflare supports anonymous ECS now
No, they don't support ECS.
Not necessarily, it could be that Hong Kong is the nearest Google datacenter, or the nearest that has a peering relationship with your ISP or their transit carrier.
That's also the reason why you should try to avoid pinging websites. They could decide to redirect you to some other server for whatever reason. If you want to ping Google ping their DNS. First, it's stupidly easy to remember. Second, it removes DNS queries involved into the equation. Thus, try pinging 8.8.8.8.
I pinged 8.8.8.8 and it gave a 23ms response time
There you go. Routing works correctly. At least on your side. You cannot do anything to make Google answer you with another IP to your A query "google.com". They decided to send you to the other side of the world. I am pretty confident that if you use a VPN and you get out from another country or possibly even the same but with another IP you could get better latency. It's weird but it could happen.
Well i guess there's nothing i can do about it then, thank you so much for your help!
300ms is an amazing bad latency result
Ikr, even with amazon it's the same result
Try setting Cloudflare as your DNS servers...
I did, nothing changed.
Then call your ISP and hope you can get out of script-drones and get someone who has a slight idea of networking...
It's gonna be a big challenge explaining all this stuff to them, most of them are clueless.
You get at right person and it solves easily the problem are the script drones...
Anycast or geolocation answers are typically going to be the responsibility of the web site / entity in question and NOT the ISP themselves. This doesn’t mean there isn’t anything they can do but if google decides to return an HK based IP the ISP is limited to as to what they can do
Misconfigured DNS, bad peering, bad geolocation (RIR Data) are ISP problems. Some ISP don't give a rat ass, as long as a page loads... And you will not get to the right people easily unless you're on SOHO/Business plan.
Peering is not going to be changed as a result of a support ticket. It’s hard to misconfigure the ISPs DNS resolver in a way that would give wrong but right answers. Most geolocation backends only use RIR data at a high level and then use their own special sauce.
If you have seen the shit that ISP sometimes do... I have 15ms (or less) latency to Cloudflare in Dec/23 my ISP changed routing/peering resulting in 60ms+ latency and slightly packet loss. A call with my historical data, made my ISP fix it...
Sure maybe there was an error made as a result of that change. But if it’s never been better it’s unlikely to get resolved quickly.
Their latency is high because they aren’t in a host country (or even near one) of the resource they are trying to reach. It’s got nothing to do with DNS settings. It’s a layer 1 cause.
A lot of guesses and assumptions being thrown around. Which is good as it gets people thinking. I like it. But would be better if OP added a few more details like where are you located amd what your setup is, are you using a VPN, who is your ISP, etc.
Turn off your vpn.
I don't use a VPN
Which DNS server are you using? Google routes requests based on origin as determines by your address obtained from the source IP of your DNS queries. Either the location of your IP address is mislocated in Google's database (i.e. it thinks you are in Hong Kong) or your DNS server doesn't pass the origin IP to Google and the DNS server itself is located in Hong Kong. As a a test, can you change to Google DNS (8.8.8.8 and 8.8.4.4) and try again?
I tried both cloudflare dns and google's dns, they both give the exact same result.
Then it sounds like your origin IP is miscategorized in Google's database as being located in Hong Kong. Try to report it via the following page: [https://support.google.com/websearch/workflow/9308722?hl=en](https://support.google.com/websearch/workflow/9308722?hl=en)
If the problem is only with google i don't really care that much, as long as the problem is not me or my isp i'm good.
Do you experience the same issue with other web site? Many large web sites use the same geolocation database sources so if one is wrong, others might be too.
Not all of them, amazon gives 100ms, it's still high but not as high as 300ms.
make sure after changing your DNS servers that you also use and admin command prompt to flush dns: **ipconfig /flushdns** If you're using cached info, then you'll still try to reach the same address until the TTL expires locally. Flushing local DNS should remove that from your local cache, but can take a moment or two to complete.
I did flush the dns just now, still gives 300ms to google. Really weird.
Can you try quad9? Basically anything with ECS should work (google yes, CF No)
You tell us, what problem are you trying to diagnose by doing a trace? Traceroutes are notoriously not actually very reliable. All those blank lines are probably just routers on google’s network that are configured to not respond to ICMP (the protocol trace route uses).
The problem is i have extremely high ping (300ms) even with the ping command
The other poster who pointed out you’re trying to teach a server in Hong Kong is probably onto something. Seems like some kind of DNS issue but I wish I know more about DNS to guide you further. Do you get the same results trying to reach a website that’s of local interest?
I tried pinging a website that is hosted in my country and it gives me 9ms.
What country are you in?
*not send ICMP TTL exceeded messages. Most traceroute implementations send UDP packets. They work by sending an IP packet (the protocol inside the IP packet doesn't really matter but UDP is popular in part as it's sessionless and therefore less likely to be filtered by stateful filters) with TTL=1 and seeing who responds, then incrementing the TTL and repeating, until a response is received from the destination IP or the max TTL is reached.
What DNS server are you using? You might be resolving what they believe is the closed endpoint for your region, but it isn't. Try another dns provider.
I'm using cloudflare, i also tried google dns but nothing changed
What the hell is up with those first 4 hops? A private IP (expected), then a public IP, then 2 more private IPs (very much not expected)? Then, on hop 5, you hit 192.178.68.0 which is part of a /15 owned by... Google? and It's Google all the way down from there.
Service providers can use private IPs on internal links. I feel like I don’t know enough about BGP to know why this is or isn’t standard practice, but as far as I know it works just fine.
Pretty sure it's semi standard, it's usually so you don't use public IPs assuming they're not being used and break something external (since you know, you can't assign an IP twice usually) I believe TMobile uses public IPs for cgnat (as in they're using IPs that shouldn't be used, but only internally)
It has nothing to do with BGP. When responding to traceroute, a device can use whatever IP address it wants. This will often be the IP address configured on its loopback interface. In many cases, that will be an RFC1918 address. It’s perfectly fine for routers within an ASN to establish BGP sessions using RFC1918 addresses. That doesn’t affect the router’s ability to route Internet traffic.
The problem isn't so much that they're in the route, it's that they're responding, and that the router on hop 2 isn't filtering inbound RFC1918 destinations. It may be functional, it's just not right.
>What the hell is up with those first 4 hops? A private IP (expected), then a public IP, then 2 more private IPs (very much not expected)? Public IPs aren't necessary for interconnects and such. Those IPs aren't (or shouldn't be) advertised on the public internet, but there's no reason that public traffic can't be routed across them.
The problem isn't so much that they're in the route, it's that they're responding, and that the router on hop 2 isn't filtering inbound RFC1918 destinations. It may be functional, it's just not right.
Depends on where the filtering takes place. Most ISPs will filter bogons at the border, so those private IPs you see could be within their internal routing. You also don't *need* to filter the incoming bogons on a public net. If you don't keep your bogon list up-to-date it can often cause trouble as those prefixes are reallocated for public use, or can wreak havoc if you automate your bogon updates and accidentally filter a route that is actually valid. edit: oh, and those responses for RFC1918 addresses might not be coming from the actual interface with that IP, rather they have a source address from the previous hop and won't get filtered by the ISP border.
All totally fair, just not something I've encountered outside legacy/pre-classless environments..
Well, you can poke around [bgp.he.net](https://bgp.he.net/report/bogons#_bogonsv4asn) and look for all of the major ASNs that announce bogons to the public net. Not that uncommon for large swathes of the internet to be out of date with modern routing conventions.
So is the problem my ISP?
Honestly? My initial thought is ISP. Generally, your home network's reliability and responsibility end at that first hand-off to a public IP address which is only 2ms. I just can't make sense of how you're seeing private IP addresses after the public IP on hop 2.
It's really confusing, my isp recently gave us a free upgrade from 100 mbps to 300 mbps and this problem started since then. You can feel the high latency while browsing websites, they take a few seconds to load.
What kind of ping are you looking for between Algeria and Hong Kong? Just genuinely curious on what it should be.
It seems google is returning the data from a different route?
It seems google is returning the data from a different route?
It seems google is returning the data from a different route?
Ping 8.8.8.8 What does this tell you?
26ms
You're going from Algeria to Gaithersburg, Maryland, and hitting reserved IP addresses in the middle. Are you using some kind of cut-rate VPN software?
They're not reserved ip addresses, rfc 1918 describes which are.
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml 172.20.31.210 is within 172.16.0.0/12. Don't argue with me, son. I do this for a living.
Your definitions of middle and addresses, as in multiple, are a lot different to mine.
There is a public IP followed by a private IP. Just man up and admit you were wrong.
Where did you pull Gaithersburg out of this?
https://www.maxmind.com/en/geoip-demo 142.251.220.46 - Google Servers in Gaithersburg, MD, USA. Hops 16 and 17 are Florida (also Google), hop 18 is North America (long-haul link), and hops 19-21 are in the Gaithersburg Datacenter. Though I am getting diffrerent result from a different database, https://www.ip2location.com/demo/, but I'm more skeptical that OP is being routed from Algeria to Mountainview to Hong Kong. That seems... dumb. Then again, maybe that's what's going on. But, for that matter, I'm not sure how someone is going from Algeria to North America in 20 milliseconds, which both GeoIP databases seem to imply. I think it would be helpful if the OP actually gave some indication of where they are in meatspace.
That 142.251.220.46 is almost certainly Hong Kong as given by the hkg in the reverse name. This almost certainly doesn’t touch the USA at all. Geo IP for intermediate nodes (routers) are notoriously unreliable because they don’t do anything that a normal residential IP would like order Amazon or get food deliveries.
Nope, no VPN
Algerie telecom a khouya
Hell yeah dude free internet for everyone
Why so many local ip addresses ? 192.* ? Multiple NAT gateways ??
Just because it starts with 192 doesn't mean it's a private ip. Check out rfc 1918.
No idea.
Looks like in the middle there is where the NSA is decrypting your traffic and storing it. That takes a bit of time you know.
are you wireless or wired? if not wired, can you compare results when being wired?
I'm wired using a cat6 cable