Packet Capture doesn't show packets for 'Destination host unreachable' and 'Response timed out'.

asked 2020-06-07 20:26:28 +0000

Somenath gravatar image

updated 2020-06-08 07:54:22 +0000

grahamb gravatar image

Hey guys..

I'm new to packet capturing using wireshark. I have a couple of VM nodes (that reside on different physical machines) that communicate to an Application server.

The Hyper-V VMs have a feature called live migrate, which switches the physical host on which the VMs are running on the fly. Both VMs are in bridged mode and have a connection to a physical switch over which this application server is accessible (within the same subnet).

Normally, both VMs are able to reach this application server, until live migration is done. Then the application stops responding till we shut and unshut (bounce) the port on the physical switch on which the VM is connected (the VM that was live-migrated).

I did a packet capture to troubleshoot the issue. I started a packet capture inside the VM on its interface, without any capture filter, and live-migrated the VM, hoping to catch the host unreachable and request timed out packets. I get the following output:

Reply from 192.168.0.242: bytes=32 time<1ms TTL=128
Reply from 192.168.0.242: bytes=32 time=2ms TTL=128
Reply from 192.168.0.182: Destination host unreachable.  
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.

PCAP files here Please take a look at the PCAP file : _filtered_FHDSAPP20042_PacketCapture_Appcheck.pcapng for the output below. The rest contain similar tests.

I can see the ICMP echo request for the last ping, and the reply, but after that --- I can't even see the ICMP echo requests from the freshly-migrated server. It's as if the server doesn't send out the ICMP echo requests.

Capture View

Is this because the migrated server no longer remembers the L2 header/MAC address of the destination (application) ?

Any ideas on how I can solve this, without boucing the port every time I live-migrate?

edit retag flag offensive close merge delete

Comments

I guess the two VM hosts are connected to different switches or at least to different ports on the same switch.

When you migrate the VM machine to the other VM host, the LAN adapter of the VM machine moves onto the other switch/port. Your VM 192.168.0.182 sends out an ARP request for 192.168.0.242 after the migration (#102), but it isn't receiving any answer until you have disabled/enabled the port (#121). That suggest that the ARP table was not updated before. So all answers to the mac address of your VM machine will probably still go to the old port after the migration.

As far as I know Hyper-V should send out an ARP update after the migration to update the ARP tables on the switch. But I'm not very familliar with Hyper-V. Otherwise you can try to lower the ...(more)

JasMan gravatar imageJasMan ( 2020-06-10 20:50:45 +0000 )edit