Why am I getting different results from two servers that located in the same destination network?

Question

There's two servers with the same network IP, and the only difference between them is the last two numbers like: 37.211.15.247 and 37.211.166.178. The Hosting Provider claims that the subnet mask for both networks is 255.254.0.0

When I try the command Tracert (Traceroute) to test the ping and to see what hops does it take to reach the destination server, I get different ping times and different forward path results which is strange because they are all located in the same company host.

Is there something wrong? Shouldn’t it take the same path too?

I have added the the full IP addresses to both servers as requested by some commenters. Well the two servers aren’t “International” anyways, so as far as I know, the only thing that comes to mind is the possibility that the two are configured on different subnetworks just like what “joeqwerty” states in his answer. Though it’s suspicious.

UPDATE: After doing so much research, I found out the Subnet of these two hosts. They are on a /15 (255.254.0.0) subnet mask. Unfortunately, this is what that hosting provider claimed to me which is not true, and the true Subnet they apparently use is a /17 (255.255.128.0) Subnet mask. It turns out that they were definitely on different Subnets. That's why I got different traceroutes when I tested these two IPs 37.211.15.247 and 37.211.166.178 because they are clearly on different Subnets. Thank you everyone for these good answers, especially joeqwerty his answer helped me a lot.

Solution 1

You're leaving out a crucial piece of information, which is the subnet mask. You're making an incorrect assumption that these two hosts are in the same network/subnet based solely on the octet values without considering the subnet mask that each host is using. They could very well be in different networks.

Think of a house address. If I told you that I lived at 123 Smith Street would you know where my house is? No, you wouldn't. If I told you that I lived at 123 Smith Street in Smithtown would you know where my house is? No, you wouldn't. If I told you that John Smith also lives on Smith Street would you know if he and I are neighbors? No, you wouldn't. Even if I told you that John Smith also lives in Smithtown it's not possible for you to know if we're neighbors. If I told you that I lived at 123 Smith Street in Smithtown, Michigan 46123 would you know where my house is? Yes, you would. If I then told you that John Smith lives at 361 Smith Street in Smithtown, Michigan 46123 would you know if we're neighbors? Yes, you would know that we are in fact neighbors and live in the same neighborhood.

Knowing the IP address without knowing the subnet mask is like knowing my house address and street name without knowing the city, state and zip code. It's incomplete and doesn't give you enough information to know where my house is, or if a particular person also lives in my neighborhood.

Solution 2

The same company host doesn't means that they are on the same network architecture... so route and ping might be different if they are connected to different network elements (proxy, firewall, loadbalancers...). As they are on different subnetworks, they also might be in different Datacenters which means different physical location, so the ping time might be different

Solution 3

Shorter answer:

Thanks for providing the actual IP addresses. This helps us see what you are seeing to an extent. And here is what I am seeing.

37.211.166.178 appears to be unreachable while 37.211.15.247 is fine. So the difference in ping times you initially saw could be due to an outage on that hosting provider’s network associated with that address. It does seem like both IP addresses are being managed by different networks and different equipment; meaning they might be in the same physical location but are very clearly managed by different equipment on wholly different subnets. For example:

• It looks like 37.211.166.178 is connecting to the outside world via qatar-ic-305455-ffm-b2.c.telia.net (80.239.135.22).
• It looks like 37.211.15.247 is connecting via 80.231.60.98.

Meaning, 37.211.166.x is clearly not the same subnet as 37.211.15.x; these machines are not on the same shared network.

Past that, nobody here can help you understand why an IP you believe should be active would suddenly just be dead or why your hosting provider would assign/arrange IPs and servers in such a way. You would need to contact your hosting provider to ask them to investigate this. Not much else we can do here except provide more confirmation to what you can see yourself. More details below.

Longer answer:

37.211.166.178 seems to be dead to the world.

For example, attempting to ping 37.211.166.178 results in a dead end with no ping responses; I had to Ctrl+C to get out of ping:

ping 37.211.166.178
PING 37.211.166.178 (37.211.166.178) 56(84) bytes of data.
^C
--- 37.211.166.178 ping statistics ---
30 packets transmitted, 0 received, 100% packet loss, time 31628ms

Doing a test of that IP via Pingdom Tools shows 100% packet loss as well.

Then running a test with MTR (My Traceroute) shows more details of the mess. The command would be:

mtr 37.211.166.178

And the output is this:

                                   My traceroute  [v0.80]
localhost (0.0.0.0)                                               Sat Oct 17 15:22:01 2015
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                    Packets               Pings
 Host                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. ???
 2. ???
 3. ???
 4. 100.64.16.77                                   0.0%     7    0.4   0.4   0.4   0.5   0.0
 5. 54.239.48.194                                  0.0%     7    1.3   2.0   1.1   5.0   1.5
 6. 205.251.232.214                                0.0%     7    1.1   1.4   1.1   2.2   0.4
 7. 205.251.232.78                                 0.0%     7   61.5  14.8   6.4  61.5  20.6
 8. 205.251.226.184                                0.0%     7    6.5   6.6   6.4   7.3   0.3
 9. sea-b1-link.telia.net                          0.0%     7    7.5   7.5   7.4   7.5   0.0
10. chi-b21-link.telia.net                         0.0%     7   50.8  51.2  50.7  52.1   0.6
11. nyk-bb2-link.telia.net                         0.0%     7   99.9  91.0  72.6 134.0  23.0
12. ffm-bb2-link.telia.net                         0.0%     7  199.2 207.3 199.2 216.1   6.6
13. ffm-b2-link.telia.net                          0.0%     7  201.4 207.3 199.4 222.8   8.7
    ffm-b2-link.telia.net
    ffm-b2-link.telia.net
    ffm-b2-link.telia.net
14. qatar-ic-305455-ffm-b2.c.telia.net             0.0%     7  304.4 311.1 302.9 323.8   7.8
    qatar-ic-305457-ffm-b2.c.telia.net
    qatar-ic-305456-ffm-b2.c.telia.net
15. 89.211.2.229                                   0.0%     7  300.2 305.4 300.2 310.6   3.7
16. 89.211.4.130                                   0.0%     7  300.9 308.9 300.9 329.7   9.6
17. ???

Ping times become abysmal and the host itself does not respond once the trace is completed. Is this server and IP address fully setup and running?

37.211.15.247 seems fine.

In contrast, attempting to ping 37.211.15.247 works as expected:

ping 37.211.15.247
PING 37.211.15.247 (37.211.15.247) 56(84) bytes of data.
64 bytes from 37.211.15.247: icmp_req=1 ttl=45 time=259 ms
64 bytes from 37.211.15.247: icmp_req=2 ttl=45 time=258 ms
64 bytes from 37.211.15.247: icmp_req=3 ttl=45 time=258 ms
64 bytes from 37.211.15.247: icmp_req=4 ttl=45 time=259 ms
64 bytes from 37.211.15.247: icmp_req=5 ttl=45 time=258 ms
64 bytes from 37.211.15.247: icmp_req=6 ttl=45 time=258 ms
64 bytes from 37.211.15.247: icmp_req=7 ttl=45 time=258 ms
64 bytes from 37.211.15.247: icmp_req=8 ttl=45 time=259 ms

And a test of that IP via Pingdom Tools shows 0% packet loss; which is great!

Similarly MTR (My Traceroute) shows a nice, clean trace to the target IP address. The command would be:

mtr 37.211.15.247

And the output is this:

                                   My traceroute  [v0.80]
localhost (0.0.0.0)                                               Sat Oct 17 15:21:21 2015
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                    Packets               Pings
 Host                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. ???
 2. ???
 3. ???
 4. 100.64.16.35                                   0.0%     7    0.4   0.4   0.4   0.4   0.0
 5. 54.239.48.192                                  0.0%     7    1.8   1.3   1.0   1.8   0.4
 6. 205.251.232.196                                0.0%     7    1.1   1.7   1.1   4.7   1.3
 7. 205.251.232.73                                 0.0%     7    6.3   7.7   6.3  13.7   2.8
 8. 205.251.225.179                                0.0%     7    7.4   7.0   6.5   7.4   0.4
 9. ae-9.r05.sttlwa01.us.bb.gin.ntt.net            0.0%     7    7.7  29.2   7.4 159.0  57.2
10. ix-10-0.tcore1.00S-Seattle.as6453.net          0.0%     7    7.2   7.2   7.2   7.3   0.0
11. if-1-0-0.core1.00S-Seattle.as6453.net          0.0%     7    7.3   7.3   7.3   7.4   0.1
12. if-8-2-3-0.tcore2.CT8-Chicago.as6453.net       0.0%     6  155.4 155.4 155.3 155.5   0.1
13. if-22-2.tcore1.CT8-Chicago.as6453.net          0.0%     6  145.1 145.5 145.1 146.7   0.6
14. if-12-6.tcore2.NYY-New-York.as6453.net        16.7%     6  151.7 154.3 151.6 163.7   5.3
15. if-20-2.tcore2.L78-London.as6453.net           0.0%     6  144.4 151.4 144.4 183.6  15.8
16. if-2-2.tcore1.L78-London.as6453.net            0.0%     6  145.1 173.1 144.8 314.3  69.1
17. if-17-2.tcore1.LDN-London.as6453.net           0.0%     6  150.7 170.1 150.6 266.4  47.2
18. 80.231.60.98                                   0.0%     6  257.6 256.1 254.7 257.8   1.4
19. 89.211.5.37                                    0.0%     6  463.8 290.3 254.6 463.8  85.0
20. 89.211.3.146                                   0.0%     6  415.9 283.7 256.4 415.9  64.8
21. 37.211.15.247                                  0.0%     6  367.9 277.0 258.4 367.9  44.5

Solution 4

If you are getting different traceroute results, it is because the routing is being handled differently. This could be because the hosts are not on the same network (as Paul's first comment under your question noted... I am agreeing with his comment... many companies these days are international, so being part of the same company doesn't necessarily mean that traffic will get routed to the same spot).

Another possible reason is a router might just be misconfigured. To really troubleshoot this might require having access to the routing tables of the router that provides the different route. If that is just some random ISP, you probably don't have access to that routing table.

View more solutions

Comments

[Paul]

While there is some correlation between IP address proximity and geographic proximity, it is not a rule. These servers could be on opposite side of the planet and still be in the same IP range. If you are getting different traceroute results, it is because they are not in the same network.

[John Hark]

@Paul No, actually it's located in the same company. The traceroute shows me the same end path too.

[Paul]

Please post the traceroutes.

[kasperd]

They might not be on the same network. Additionally if traffic is being balanced across multiple alternative routes, it is entirely possible that the least significant bits of the IP address is being used to choose which of the possible routes to the same destination network is being used.

[joeqwerty]

Based on your most recent edit, the two servers would be in the same network if they were using a /16 (255.255.0.0) subnet mask. It doesn't seem very likely that the network in question is that large and hasn't been subnetted further. If you know the subnet mask that each host is using that would tell you without a doubt whether or not they're in the same network. A /16 subnet mask (255.255.0.0) would allow for 65,534 hosts. I doubt very much that this is the case here.

[EEAA]

@JohnHark I would suggest that you start heeding the information and guidance given to you by the folks who have posted answers. Flagging comments as you've been doing and carrying on with unproductive behavior will quickly earn you a temporary ban.

[John Hark]

Like i said, the servers are located in the same location there's no doubt about it. This is a common problem though, i always encounter this kind of problem almost on any different ISP, if the two servers from the same network have different last intervals, i almost always get different ping times and hops, even though they are located in the same place.

[John Hark]

Like i said, the two servers are located exactly in the same place, there's no doubt about it.

[k4cy]

do you know the network architecture they're behind ? same location does not means nothing... If they are on different subnetwork they might not be behind the same firewall/loadbalancers & stuff...

[TOOGAM]

I currently stand by the last two sentences from my answer. The person who can configure one of the intermediate routers might have decided that a specific route is better for one portion of the addresses. Maybe that person was just wrong, or maybe the person was right (but didn't know to make a route that also helps another section of addresses). People who configure routers can make routing decisions, which might be right, or might not be. Without some more specific details, it's hard for me to disagree with the current setup or say that anything is actually wrong.

[joeqwerty]

@JohnHark: You keep saying that there's no doubt that these two hosts are in the same location and in the same network but you haven't given us enough information to know this without a doubt. How do you know this? What's your proof?

[Giacomo1968]

@JohnHark You could have two servers physically on top of each other but one cable connects to one switch and the other cable connects to another switch. Honestly your "no doubt about it" assertion is painfully naive.

[Michael Hampton]

I'm kind of surprised you didn't mention these IPs appear to be in different autonomous systems entirely.

[Giacomo1968]

@MichaelHampton I strongly imply that here don’t I? “It does seem like both IP addresses are being managed by different networks and different equipment.”

[Michael Hampton]

But you only strongly implied it. Demonstrating that they are on different ASes (which they are) would make it even more compelling.

[Giacomo1968]

@MichaelHampton Fair enough. Reworded that statement to now state, “It does seem like both IP addresses are being managed by different networks and different equipment; meaning they might be in the same physical location but are very clearly managed by different equipment on wholly different subnets.”

[Giacomo1968]

@JohnHark The subnet mask has little to do with your scenario. Also, this is not a comment on me losing the checkmark on my answer, but you then checked off this answer as the answer when you comment clearly indicates you still are confused. You should not check any answer as the answer until you are 100% positive you have an answer. This is not a chatroom site where you casually do things like this. I have added the subnet mask to the question but like I state in my answer, the issue is both of these servers are on 100% different networks. Subnet masks are irrelevant in a case like this.

[Giacomo1968]

@JohnHark Like I said, I really do not care about the checkmark. But I think you still are 100% unaware that the issue is still not subnet related but rather the whole architecture and path each network trace takes is 100% different because each server is managed by 100% different equipment. The subnet mask is not the key factor but just another indicator of the fact these are two machines on 100% different networks.