VSAN-Troubleshooting-Reference-Manual

Diagnostics and Troubleshooting Reference Manual – Virtual SAN
While this output might seem a little confusing, suffice to say that the output shown
here indicates that this host is indeed receiving a heartbeat from the master. This
tcpdump-uw command would have to be run on every host to verify that they are all
receiving the heartbeat. This will verify that the master is sending the heartbeats,
and every other host in the cluster is receiving them, indicating multicast is working.
To get rid of the annoying “IP truncated-ip - XX byes missing” messages, one can
simply add a –s0 at the end. –s0 will not truncate the packet.
# tcpdump-uw -i vmk2 udp port 23451 -v -s0
tcpdump-uw: listening on vmk2, link-type EN10MB (Ethernet), capture size 65535 bytes
21:14:09.093549 IP (tos 0x0, ttl 5, id 61778, offset 0, flags [none], proto UDP (17),
length 228)
172.32.0.3.20522 > 224.2.3.4.23451: UDP, length 200
21:14:09.617485 IP (tos 0x0, ttl 5, id 46668, offset 0, flags [none], proto UDP (17),
length 316)
172.32.0.4.16431 > 224.2.3.4.23451: UDP, length 288
21:14:10.093543 IP (tos 0x0, ttl 5, id 61797, offset 0, flags [none], proto UDP (17),
length 228)
If some of the Virtual SAN hosts are not able to pick up the one-second heartbeats
from the master, the network admin needs to check the multicast configuration of
their switches.
The next multicast checking command is related to IGMP (Internet Group
Management Protocol) membership. Hosts (and network devices) use IGMP to
establish multicast group membership.
tcpdump-uw –i vmk2 igmp
Each ESXi node in the Virtual SAN cluster will send out IGMP “membership reports”
(aka ‘join’) every 90-300 seconds. This tcpdump command will show igmp member
reports from a host:
~ # tcpdump-uw -i vmk2 igmp
tcpdump-uw: verbose output suppressed, use -v or -vv for full protocol decode
listening on vmk2, link-type EN10MB (Ethernet), capture size 96 bytes
14:35:32.846558 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2 [max resp time 1]
14:35:32.926337 IP 172.32.0.3 > 224.1.2.3: igmp v2 report 224.1.2.3
14:35:32.928899 IP 172.32.0.3 > 224.2.3.4: igmp v2 report 224.2.3.4
14:35:45.757769 IP 172.32.1.253 > all-systems.mcast.net: igmp query v2
14:35:47.528132 IP 172.32.0.3 > 224.2.3.4: igmp v2 report 224.2.3.4
14:35:47.738076 IP 172.32.0.3 > 224.1.2.3: igmp v2 report 224.1.2.3
14:36:45.762795 IP 172.32.1.253 > all-systems.mcast.net: igmp query v2
14:36:51.887170 IP 172.32.0.3 > 224.2.3.4: igmp v2 report 224.2.3.4
14:36:56.207235 IP 172.32.0.3 > 224.1.2.3: igmp v2 report 224.1.2.3
14:37:02.846211 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2 [max resp time 1]
The output shows “igmp v2 reports” are taking place, indicating that the ESXi host is
regularly updating its membership. If a network administrator has any doubts
whether or not Virtual SAN ESXi nodes are doing IGMP correctly, running this
command on each ESXi host in the cluster and showing this trace can be used to
verify that this is indeed the case.
V M W A R E S T O R A G E B U D O C U M E N T A T I O N / 1 0 7