Strange Ping Problem

2) asymmetric routing or similar routing table anomaly at one end or the other

Bishop, can ya expand on that one for me please ?

If you've got the wrong subnet mask on the node at the distant end then that end might make a bad decision on whether to forward the packet to the router or not, or it might also pick the 'wrong' router. Hence the ping might not get routed correctly when it originates at the distant end and appears not to work. But from the local end to the distant end it works fine. I've also seen a similar effect with asymmetric routing, where the packets take a different path from B to A than they do from A to B. All it takes is for one bit of the routing not to quite line up and your traffic can end up in the wrong place and never arrive where it should. For example, a network only ever has one default gateway but if you have two or more routers (load-balanced links perhaps) connecting out into the same routing cloud you can get traffic going out of one but perhaps coming back in the other. This can confuse ARP caches and also leaves you at the mercy of odd routing rules out in the cloud. Do some traceroutes from each end and you'll soon see whether my suggestions are relevant or not to your situation

Cheers Bishop, i see what ya mean. Basically what i was trying to explain in this thread to someone else (didn't fully understand the wording) www.firewall.cx/ftopict-4641.html

Oh, BTW. This issue wasn't actually there. I was going of third hand information and when i have come to check this myself, they were trying to ping the wrong thing and getting their IP's mixed up on what they could/couldn't reach.

Thanks for replying anyway everyone

If you've got the wrong subnet mask on the node at the distant end then that end might make a bad decision on whether to forward the packet to the router or not, or it might also pick the 'wrong' router. Hence the ping might not get routed correctly when it originates at the distant end and appears not to work. But from the local end to the distant end it works fine. I've also seen a similar effect with asymmetric routing, where the packets take a different path from B to A than they do from A to B. All it takes is for one bit of the routing not to quite line up and your traffic can end up in the wrong place and never arrive where it should. For example, a network only ever has one default gateway but if you have two or more routers (load-balanced links perhaps) connecting out into the same routing cloud you can get traffic going out of one but perhaps coming back in the other. This can confuse ARP caches and also leaves you at the mercy of odd routing rules out in the cloud. Do some traceroutes from each end and you'll soon see whether my suggestions are relevant or not to your situation

The confusing thing to me here (in both cases) is that each ping is a send and reply. So if a send always works when pinging A to B then a reply should always work when pinging B to A. And vise versa.

In other words, If we assume that the problem was in sending packets when pinging B to A. Then the replied packets when pinging A to B should not have worked. similarly, If we assume that the problem was in replying packets when pinging B to A. Then the sent packets when pinging A to B should not have worked.

This is true but if you take a look at the other thread where i discussed this with someone else, i think its to do with the way Microsoft works.

I think it gets strange during the following;

Host A = 10.1.0.8/8
Host B = 10.10.10.1/24

I think, if Host A pings Host be, because Host A is Class A, it will think that host B is on the same subnet and will just do a streight ARP. ARP is broadcast and will not route, therefore Host B would reply with its MAC entry. Then the two will be able to talk without any issues because they both have MAC to IP entries.

If, on the other hand, Host B tries to talk to Host A, then since its a Class C it will then try to route the traffic and thus get into issues.

This is what i think anyway

Yes, it's the difference in the subnet mask coupled with where the ping originates from that makes the difference