Reply to: Tracing an internet connection

[Lance]

Yes I read this. But I also hadn't realised that the TTL varies depending on the OS of the target host.

BTW, do you know if there is any way of discovering the IP addresses of the hops which appear as "* * *" in traceroute? Or would I need to consult a hacker for that?

there is no way to get the IP address, or even to know if it exists.
The TTL might be being decremented by more than one by a device. What will show as a 'missing' hop.

All you know is that the ICMP packet that was sent with a TTL for that hop number didn't get a response.

this explains it quite well Traceroute (networklessons.com)

[woody1]

only if you assume that every router decrements the TTL by 1. Which is a fair assumption on business LAN/WAN., but not on an internet provider who want their network obscure. If they block the ICMP response to stop you trace routing, why would they play nicely with the TTL?
I've seen some ISPs actually add numbers to the TTL

Yes I read this. But I also hadn't realised that the TTL varies depending on the OS of the target host.

BTW, do you know if there is any way of discovering the IP addresses of the hops which appear as "* * *" in traceroute? Or would I need to consult a hacker for that?

[Lance]

I'm only using latency (ping) as a measure of the health of the connection. I now know that 40ms is v.good.

BTW, I learned something new the other day; that you can deduce quite a lot from the TTL in the ping output.

only if you assume that every router decrements the TTL by 1. Which is a fair assumption on business LAN/WAN., but not on an internet provider who want their network obscure. If they block the ICMP response to stop you trace routing, why would they play nicely with the TTL?
I've seen some ISPs actually add numbers to the TTL

[woody1]

latency isn't an issue unless you have particularly time sensitive apps. And even if you do, 250ms is generally considered acceptable for a worst case scenario.

I'm only using latency (ping) as a measure of the health of the connection. I now know that 40ms is v.good.

BTW, I learned something new the other day; that you can deduce quite a lot from the TTL in the ping output.

[Lance]

According to this, the <40ms average ping times I'm currently getting do appear to be at the limits of what is achievable with 4G.

https://www.4g.co.uk/news/4g-injecti...#Lower_latency

Hopefully, it continues like this.

latency isn't an issue unless you have particularly time sensitive apps. And even if you do, 250ms is generally considered acceptable for a worst case scenario.

TCP/IP was designed to cope with packet loss and variable latencies. It's why you have TCP sliding windows. It's why you can have large bandwidths with high latency (the two are not directly related).

When using voice, jitter is a bigger problem than latency.

You youngsters have been spoiled. A reliable, low jitter, 2Mb/s connection is bloody amazing. I'd rather have that than a Talktalk 70Mb/s lossy, unreliable bag of sh1te.

If you want to learn some more read up about TCP sliding windows, and QoS. All QoS does is determine which packets get dropped in a congested network (it's nothing fancy, but is very effective).

[woody1]

According to this, the <40ms average ping times I'm currently getting do appear to be at the limits of what is achievable with 4G.

https://www.4g.co.uk/news/4g-injecti...#Lower_latency

Hopefully, it continues like this.

[woody1]

Have you logged a ticket yet?

It hasn't played up for the past week or so. I have bought another router, which I'd been meaning to do anyway, so I can at least rule this out if the problem reoccurs.

[Lance]

This wasn't what I was expecting.

I ran concurrent "ping -t" tests to the following addresses, and the average round trip times were always practically identical (typically just under 40ms).

ISP's DNS server............(4 hops from my router with tracert)
bbc.com...............................(11 hops)
8.8.8.8..................................(12 hops)

Obviously most of the latency will be between my router and the ISP, however I had thought that the round trip time would be less for a server on the ISP's network, with far fewer hops, but clearly not.

why would you think that? The latency from provider network to BBC or Google is likely in the 1-3 ms range. The 4g network is at least one order of magnitude greater.

And as the service uses a proxy, ping latency times aren't in the slightest bit helpful for what you're trying to diagnose.

Have you logged a ticket yet?

[woody1]

This wasn't what I was expecting.

I ran concurrent "ping -t" tests to the following addresses, and the average round trip times were always practically identical (typically just under 40ms).

ISP's DNS server............(4 hops from my router with tracert)
bbc.com...............................(11 hops)
8.8.8.8..................................(12 hops)

Obviously most of the latency will be between my router and the ISP, however I had thought that the round trip time would be less for a server on the ISP's network, with far fewer hops, but clearly not.

[Lance]

The router came included when I signed up for mobile broadband. It's basically a black box, and there's bugger all diagnostic capability. It doesn't even tell me the ISP's gateway IP address.

I may upgrade to something better. However, I suspect that most of the ISP's network is configured not to respond to traceroute or ping. I read that many ISPs do this for security reasons to prevent hackers mapping out their network.

so log a ticket with the provider. It's their problem to solve. You are just the customer.

[woody1]

Have you tried logging onto the router's admin console and trace route from there?

Virgin's routers support this function, but I've not tried those from other providers.

The router came included when I signed up for mobile broadband. It's basically a black box, and there's bugger all diagnostic capability. It doesn't even tell me the ISP's gateway IP address.

I may upgrade to something better. However, I suspect that most of the ISP's network is configured not to respond to traceroute or ping. I read that many ISPs do this for security reasons to prevent hackers mapping out their network.

[wattaj]

******* Cloudflare.... It's sh1te.... I hate it....

DNS is a great example of something so well designed it will last for centuries. No issues with scale like IPv4
Cloudflare is snake oil at best, or at worst a proxy service that fails too frequently (Cloudflare gateway timeout today ruined my registration with a cloud service as it timed out as I was doing the final MFA verification so now I have to ring a fecking call centre to do the registration)..

Horses for courses.

[Lance]

1.1.1.1 and 1.0.0.1 are the DNS IPs provided by Cloudflare. Supposedly faster that the other DNS providers as they do not log unnecessary information. Hence its other uses.

******* Cloudflare.... It's sh1te.... I hate it....

DNS is a great example of something so well designed it will last for centuries. No issues with scale like IPv4
Cloudflare is snake oil at best, or at worst a proxy service that fails too frequently (Cloudflare gateway timeout today ruined my registration with a cloud service as it timed out as I was doing the final MFA verification so now I have to ring a fecking call centre to do the registration)..

[wattaj]

I've been having intermittent problems with my mobile broadband (no internet, slow speed). I wanted to try and trace the route end-to-end but unfortunately tracert returns mostly "* * *". I also tried a 3rd party tool tracetcp which uses TCP packets, instead of tracert's ICMP, but it was the same. Increasing the tracert timeout doesn't make any difference either.

Have you tried logging onto the router's admin console and trace route from there?

Virgin's routers support this function, but I've not tried those from other providers.

[wattaj]

1.1.1.1 is not a Google IP.
In fact neither is 8.8.8.8 It's a Level 3 IP that Google uses for DNS

At least 8.8.8.8 is a genuine one for Google though.
1.1.1.1 is not something I'd use as it's used by anonymization services and has multiple malware threats associated. It's registered to Cloudflare.
1.1.1.1 IP Address Report (ibmcloud.com)



Some further reading in IP address space at IANA Internet Assigned Numbers Authority (iana.org) They manage the address space (delegated to authorities in each region).

1.1.1.1 and 1.0.0.1 are the DNS IPs provided by Cloudflare. Supposedly faster that the other DNS providers as they do not log unnecessary information. Hence its other uses.