Hi guys, just wondering if we have a network guru here who can illuminate an issue we are having.
We are accessing a service in the UK from Canada, so there is a transatlantic hop. Here we have a mixed network of Windows and one Linux server (OpenSUSE). When we do a traceroute from this network to the remote server we get two different results. The Windows machine goes one way and the Linux box goes another. It seems to be consistent.
The issue starts at step 12 from requests from Linux:
The question is, is it not unheard of for requests from Linux and Windows to take different routes from the same origin to the same destination, or do we have a problem that needs investigation?
It is not unheard of for any single packet to take a different route
from the previous packet. Consider this, though… the difference is
at hop 12 you said. You have NO control over that hop I am guessing
since typically you will only even know people who could potentially
touch the first three or four hops, and that’s only true if you count
knowing your (or your company’s) ISP. All your local computer knows
about (and can affect) is its own gateway, which would have been hop #1.
Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
On 12/13/2011 12:06 PM, colbec wrote:
> Linux and Windows to take different routes
i am no network guru and can’t answer your Qs, but:
it is an interesting question you pose!
-let me ask: does the routes consistently go though 69.63.248.89 (a cable.rogers.com node in/near Toronto) day after day?
-given that routes shift according to the traffic of the _instant, one
should generally expect routes actually traversed to vary from minute to
minute…with that in mind i find the more interesting question to be:
What is the difference in the traceroute output from the Win vs Linux
machine which causes (after being received by 69.63.248.89) it to be
routed differently depending entirely and only on the operating system
of the route request??
-another interesting (to me) question would be:
Is one route consistently faster than the other? And, by how many
milliseconds?
finally, i wonder if this might only be solved by the gurus who feed and
maintain the net routers of 69.63.248.89
Thanks for responses and suggestions.
It is true that at any time the next hop from any node can vary, that is the whole idea of the network, to repair itself and enable a working route.
However in practical terms my understanding is that routes remain pretty static. Indeed this is what we observe.
The difference appears to be consistent, Win goes this way, Linux goes the other way.
You would think that if the outgoing packet requests were identical then the intervening nodes would treat them identically.
But the observations indicate otherwise.
So there must be a fingerprint on the packet somewhere.
We will be looking at packet contents (Wireshark), but it is a time consuming process.
As for timing it is hard to say, times on identical routes vary according to conditions.
colbec wrote:
> The question is, is it not unheard of for requests from Linux and
> Windows to take different routes from the same origin to the same
> destination, or do we have a problem that needs investigation?
Do you have any reason to suppose it depends on the OS?
Might it not, just to give hypothetical examples, be routing based on
whether the IP address of the source machine is dd or even? Or how many
1 bits there are in the IP address?
But examining the packets looks like the next step to me.
Quite right, djh-novell, the OS is just a hypothesis, and the other hypotheses you suggest are equally plausible.
We can traceroute from other IPs to get more info on that aspect.
The possibility that it is purely the OS is non-existent, but perhaps
the tools on each platform does the route tracing slightly differently.
Have you tried also using tracepath on Linux?
/sbin/tracepath ipAddrHere
Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> Hi guys, just wondering if we have a network guru here who can
> illuminate an issue we are having.
>
> We are accessing a service in the UK from Canada, so there is a
> transatlantic hop. Here we have a mixed network of Windows and one Linux
> server (OpenSUSE). When we do a traceroute from this network to the
> remote server we get two different results. The Windows machine goes one
> way and the Linux box goes another. It seems to be consistent.
>
> The issue starts at step 12 from requests from Linux:
>
> 12 69.63.248.89
> 13 if-3-0.icore1.NTO-NewYork.as6453.net
>
> but the windows boxes go from
> 69.63.248.89 to
> if-9-0.icore2.NTO-NewYork.as6453.net
>
> and follow a different path from there.
>
> The question is, is it not unheard of for requests from Linux and
> Windows to take different routes from the same origin to the same
> destination, or do we have a problem that needs investigation?
>
>
Funny, I’ve had a similar bit of grief with DHCP.
SWMBO brought home the works windoze laptop which wouldn’t pick up DHCP from
the home server via wifi.
A home linux laptop and another linux box on wifi both worked perfectly Ok.
I ended up putting a second DHCP server on the wifi router to get her
machine going so she could work from home.
Later on I found that my windoze VMs were getting DHCP from the wifi router
rather than the home server - once I disabled the wifi DHCP server they went
back to the home server Ok.
I’ve never bothered to investigate and test everything in detail but …
happenstance, coincidence, enemy action
Windows “tracert” use icmp echo packets.
Unix “traceroute” normally use udp packets.
The difference you are seeing might be related.
With recent openSUSE versions, there should be a “-I” flag (upper case I) that forces traceroute to use icmp echo packets. You probably have to be root to use that option.
nrickert is correct. It is the UDP/ICMP/TCP thing at the root of it.
We were having some issues with the traceroute available being quite old and lacking some useful options.
Now we have installed a more recent version and it confirms the UDP/ICMP thing.
So in fact plain traceroutes without options might not give you a true indication of what route your packets are taking,
and might lead to blaming an innocent router for transmission issues.
On 2011-12-13 13:36, colbec wrote:
> You would think that if the outgoing packet requests were identical
> then the intervening nodes would treat them identically.
> But the observations indicate otherwise.
> So there must be a fingerprint on the packet somewhere.
Windows and Linux traceroute and ping use different packets types.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
