The tcpdump command is used to:
- Verify connectivity issues with various network nodes (for example, latency, session, and packet dropping)
- Verify TCP/IP communication between network applications
- Intermediate TCP/IP stack issues
Ping is an easy way to tell if an interface is functioning. While the ping command executes, run tcpdump to sniff ICMP messages. There are two parts to an ICMP sequence: echo and reply. For every ICMP request, there is a reply from the destination host to the target host. Failure to see the ICMP messages when there is active ping between two nodes is indicative of IP configuration issues. IP implementations are required to support ICMP (which provides error reporting, flow control and first-hop gateway redirection).
Note: Many firewalls block IP ICMP. Use the telnet command to see if a firewall is blocking the connection.
To use the tcpdump command to verify gateway IP connectivity:
-
Ping the desired host. Use a command similar to:
ping -I vswif1 <10.10.10.1>
where <10.10.10.1> is the IP address of the gateway
If the ping is successful, the output looks similar to:
PING 10.10.10.1 (10.10.10.1) from 10.10.10.20 vswif1: 56(84) bytes of data.
64 bytes from 10.10.10.1: icmp_seq=0 ttl=255 time=0.611 ms
64 bytes from 10.10.10.1: icmp_seq=1 ttl=255 time=0.374 ms
64 bytes from 10.10.10.1: icmp_seq=2 ttl=255 time=0.334 ms
64 bytes from 10.10.10.1: icmp_seq=3 ttl=255 time=0.311 ms
If the ping is unsuccessful, the output looks similar to:
ping -I vswif1 10.10.10.1
From 10.10.10.20 icmp_seq=91 Destination Host Unreachable
From 10.10.10.20 icmp_seq=92 Destination Host Unreachable
From 10.10.10.20 icmp_seq=93 Destination Host Unreachable
From 10.10.10.20 icmp_seq=94 Destination Host Unreachable
From 10.10.10.20 icmp_seq=95 Destination Host Unreachable
-
While the ping command executes, run the tcpdump command:
tcpdump -i vswif1 -n -vvv ether proto <IP>
If the command is successful, the output looks similar to:
tcpdump: listening on vswif1
03:34:45.742359 10.10.10.20 > 10.10.10.1: icmp: echo request (DF) (ttl 64, id 0, len 84)
03:34:45.742649 10.10.10.1 > 10.10.10.20: icmp: echo reply (DF) (ttl 255, id 0, len 84)
03:34:46.587244 10.10.10.51.32768 > 10.10.10.220.902: udp 66 (DF) (ttl 64, id 0, len 94)
03:34:46.742345 10.10.10.20 > 10.10.10.1: icmp: echo request (DF) (ttl 64, id 0, len 84)
03:34:46.742668 10.10.10.1 > 10.10.10.20: icmp: echo reply (DF) (ttl 255, id 0, len 84)
If the command is unsuccessful, the output looks similar to:
06:13:19.852336 10.10.10.20 > 10.10.10.1: icmp: echo request (DF) (ttl 64, id 0, len 84)
06:13:20.852339 10.10.10.20 > 10.10.10.1: icmp: echo request (DF) (ttl 64, id 0, len 84)
06:13:21.852337 10.10.10.20 > 10.10.10.1: icmp: echo request (DF) (ttl 64, id 0, len 84)
06:13:22.852368 10.10.10.20 > 10.10.10.1: icmp: echo request (DF) (ttl 64, id 0, len 84)
06:13:23.852375 10.10.10.20 > 10.10.10.1: icmp: echo request (DF) (ttl 64, id 0, len 84)
06:13:24.882561 10.10.10.20 > 10.10.10.1: icmp: echo request (DF) (ttl 64, id 0, len 84)
Note: The output for the unsuccessful tcpdump command indicates that gateway interface 10.10.10.1 is not replying to the echo request.
-
Repeat steps 1 and 2 with the arping commands:
arping -I vswif0(eth0) <10.10.10.1<SPAN style="COLOR: #000000">>
where <10.10.10.1> is the IP address of the gateway
arp -a (to view arp list)
-
While the arping command executes, run the tcpdump command and look for an echo reply.
-
If there is no echo reply, check gateway interface configuration and reset by disabling and re-enabling.
For more information, see Resolving virtual machine IP address conflicts issues (1008177).