Wireshark Traceroute – No Response to ICMP

traceroutewireshark

192.168.1.37 can ping 192.168.0.22,
but can't ping 192.168.0.240

subnet masks are 255.255.255.0 on all hosts in question

Switch/gateway in the middle (192.168.1.253) can ping both of these addresses, and it also contains a correct ARP entry for 192.168.0.240

When I run tracert on 192.168.1.37, pointing to 192.168.0.22 I get a tracert response:

1 1 ms <1 ms <1 ms 192.168.1.253

2 <1ms <1 ms <1 ms 192.168.0.22

But there is no tracert response when I point it to 192.168.0.240.
When I check the wireshark trace for ICMP responses – there are none!
Looks like the gateway is not responding to ICMP packet sent to that remote address at all.

What else can I check? Any ideas?

UPDATE:
Both 192.168.0.22 and 192.168.0.240 have the same default gateway defined.
I can ping 192.168.1.37 from 192.168.0.22 but not from 192.168.0.240

UPDATE 2:
When I change IP address on the 'difficult' host from 192.168.0.240 to 192.168.0.34 everything works well! When I change it back to .240 it stops responding to pings from the other subnet. What is causing it? We are running a bit short on IP addresses, so it would be good to know why .240 doesn't work.

Best Answer

We have cleared ARP table on both hosts and the switch. That has somehow resolved the problem, despite the fact that we have previously manually checked that the ARP table on the switch contains a correct entry:

show ip arp | grep 0.240

Related Solutions

How to trace outgoing interfaces

I's not exactly the answer at your question, but that a simple (but limited) way to do (in certain case) what you want. I'm coping-post the option -R of ping man page:

-R Record route. Includes the RECORD_ROUTE option in the ECHO_REQUEST packet and displays the route buffer on returned packets. Note that the IP header is only large enough for nine such routes. Many hosts ignore or discard this option.

So you can see also the return path of the ECHO_REQUEST, that is not the exit interface (that you are asking about) unless the outgoing path is the same of the come back path. Only in this case, the returning path is the IP address of the outgoing interface you are asking for.

That's an real example on my internet provider net, maybe not so clear, but I don't have just now some router to link each other :) dest 10.2.105.178

traceroute 10.2.105.178
traceroute to 10.2.105.178 (10.2.105.178), 30 hops max, 60 byte packets
 1  192.168.1.254 (192.168.1.254)  3.418 ms  3.575 ms  4.021 ms
 2  10.189.48.1 (10.189.48.1)  11.237 ms * *
 3  10.2.105.178 (10.2.105.178)  15.235 ms * *

ping -R 10.2.105.178 PING 10.2.105.178 (10.2.105.178) 56(124) bytes of data.

64 bytes from 10.2.105.178: icmp_req=5 ttl=253 time=74.1 ms NOP RR:

192.168.1.133

10.189.51.61

10.2.105.177

10.2.105.178

10.2.105.178

10.189.48.1

192.168.1.254

192.168.1.133

----omitted----

64 bytes from 10.2.105.178: icmp_req=6 ttl=253 time=13.0 ms NOP RR:

192.168.1.133

10.189.51.61

10.2.105.177

10.2.105.178

10.2.105.218 ##change every time, Idon't know why##

10.189.48.1

192.168.1.254

192.168.1.133

Routing – Route does not work / LAN port not reachable

first of all your topology seams to be as following

following your description

pc2 could reach PC1 cause the pc2 GW (which is R2) can reach PC1 (cause it is directly connected to the both network).

so same way let us ask a very importent question . what is the PC1 GW and do PC1 GW know about subnet 192.168.2.X or not ?????????

if PC1 GW is the modem so you must add static route on the modem tell it if you want to reach 192.168.2.X you should go to 192.168.1.2 . otherwise you need to set the GW of PC1 to be 192.168.1.2

Related Topic

Cisco – Why Does Ping Work When Traceroute Fails?