I have two operating systems on my computer, in one TCP normally finds the path to the host, and in the other traceroute breaks off halfway. Is it possible that the route is somehow cached? If so, is it possible to reset this cache? The OS in which the KDE Neon problem is observed is the latest version.
Asked
Active
Viewed 2,919 times
2 Answers
29
Is it possible that the route is somehow cached? If so, is it possible to reset this cache?
No, only the first hop (i.e. the route to your local gateway) is under control of the OS, but you have no control over what paths are taken outside of your network.
Keep in mind that the Windows 'tracert.exe' tool always sends ICMP probes (not TCP), while Linux 'traceroute' prefers sending UDP probes by default (also not TCP, though it's an option) – sometimes those will give different results purely because of a firewall configuration near the target host; the UDP probes are more likely to be quietly discarded.
Use traceroute -I to force ICMP usage on Linux and see if it has any effect on the traceroute results. (Try also mtr.)
Is it possible to force TCP to find another path to the host?
TCP doesn't know anything about paths or routing1 – it just asks IP to deliver packets to a specific address, while route selection is exclusively IP's job.
However, IP routing is normally done hop-by-hop, i.e. each gateway individually decides which "next hop" to forward a packet to, and the sending host has no way to influence the entire path2 (and therefore cannot have the entire path cached, either).
To answer the question in the title: no, you cannot force IP to find another path if the problem occurs outside of your network – you would need to contact the operator of the last reachable network to do that.
The only way you can influence routing is by using a tunnel through another cooperating host elsewhere – a VPN, in other words. Even if you don't have a working direct path to the host, it's likely that a VPN server still does, and will let you reach the host as a workaround until the real problem is fixed.
1 (The predecesor of IPv4 – TCPv3 – did handle both tasks at once, but that only lasted a short while in 1978. By the end of the year, the two functions were split.)
2 (IPv4 did have the "Source Route" option which would allow the sending host to request specific forwarding steps to be taken, and similarly IPv6 did have the "Routing Header Type 0" aka RH0, but both have been removed from the specifications due to being a security risk and you won't find any network operators that recognize these options anymore. So even though you still see the --gateway= option in Linux traceroute, or the -j option in Windows tracert, they no longer have any effect.)
grawity
- 501,077
4
To extend the footnote in @user1686's answer: https://superuser.com/a/1760203/374853
IPv4 did have the "Source Route" ...
IPv6 SRH (Segment Routing Header) allows the sender to specify a list of "waypoints" (other IPv6 addresses), through which a packet should travel. Your route will then be "segments" composed of the path between each waypoint.
So, yes, you can direct IP (IPv6, anyway) to take a specific route, if your network supports it.
I have no idea how widely supported the SRH is. The Cisco website on Segment Routing suggests several uses in private networks. I imagine most ISPs would ignore or drop the header.
More reading:
The Wikipedia article is a bit of a stub but gives a good elevator pitch.
https://segment-routing.org has a huge amount of information on the nuts and bolts of IPv6 segment routing, including a nice description of the packet format.
Sompom
- 186