Overview
This article guides you on how to run a TCP dump - Packet Capture.
Process
- Steps to Run (Quick) - UI
- Steps to Run (Quick) - CLI
- Steps to Run (Quick) - Shell
- Packet Captures
- TCP Dump
- Generation
- Cases Where We Use This
Steps to Run (Quick) - UI
- Navigate to Configuration > System > Diagnostics > TCP Dump.
- Choose the bridge to run the capture on.
- Choose a time for the capture to run.
- Optionally provide a filter for the capture.
- Finish the capture, download it and analyze in Wireshark.
Steps to Run (Quick) - CLI
- SSH to the Exinda.
- Go to Enable mode.
- Run the command:
debug generate capture timeout [time] interface [interface] filter [filter]
- Navigate to Web UI Configuration > System > Diagnostics > TCP Dump to download the file.
- If cannot get to web UI, install a restricted license key. Navigate to /var/opt/tms/tcpdumps and FTP/SCP the file.
- Analyze in Wireshark.
Steps to Run (Quick) - Shell
- SSH to the Exinda.
- Go into the shell
_shell
. - Make the device writable by
remountrw
. - Run the command:
tcpdump -i [interface name] -w /var/opt/tms/tcpdumps/conn.pcap -C 100 "[filter]"
- Go to the Web UI Configuration > System > Diagnostics > TCP Dump to download the file.
- Analyze in Wireshark.
Packet Captures
- Are useful tools to determine how network traffic is flowing in the network. It can give an end-to-end picture of every packet and every conversation flowing to/from a host.
- Used on an End Client machine, it can show all the traffic the host takes part in - whether or not it is directly involved or is receiving broadcast or layer two requests that are shuttled through the network.
- Good packet capture allows an administrator to look at information and troubleshoot various networking problems such as dropped packets, lost connections and whether or not traffic is actually being received at the destination with the correct information that is expected.
TCP Dump
- A built-in tool in Exinda to perform packet capture.
- This is a Linux library that is available for any distribution and is installed by default on the Exinda.
- TCP Dump is a specific implementation of packet capture, built upon the common packet capture library libpcap.
- libpcap is what actually captures the packets, while TCP Dump is what organizes, filters and displays the packets as they come in.
- The Exinda has a command to invoke TCP Dump and generate, store and zip a packet capture. All of it is done with options and arguments for the Linux command line for TCP Dump, though it is hidden behind the Exinda UI.
Generation
- Generating can be done through the Web UI, under Configuration > System > Diagnostics > TCP Dumps.
- It can also be generated through the CLI command:
debug generate capture [options]
. - In both cases, the capture is taken, saved and zipped up as a .tar.gz file in /var/opt/tms/tcpdumps. This location is accessible by the Web UI on the TCP Dumps page, or in the shell. Before it is zipped up, it is saved as a standard .pcap file which can be read by any major packet capture analysis software.
- While generating the packet capture, there are three different options that are allowed to be configured.
- Interface - The choice of what interface the capture is run on. Any known interface is allowed - that is, both bridges and individual interfaces e.g., when a bridge is broken up, or a management interface. If the capture is run on the bridge, the capture will actually be run on both the LAN and WAN ports simultaneously.
- Filter - When packet capture is run, by default it captures all packets. By putting a filter on the capture, it will only record the packets that match the filter. Note that TCP Dump in fact differs from Wireshark's built-in packet capture, so any filters that are put on differ from Wireshark's filters in the application. For example, to filter by an IP in TCP dump, the filter is
host [IP]
, but in Wireshark, it isip.addr == [IP]
. - Timeout - How long the capture is set to run. On the web UI, there are specific increments - 10s, 30s, 60s, 5m, 10m, 20m that can be selected. If done via the CLI, any time can be entered in seconds.
- The captures, by definition, are split into 50Mb files. If a capture exceeds 50Mb, a new file will be created, and again, until the capture timeout is over. These files can be merged using Wireshark - File > Merge into a single file for ease of reading and for following conversation flow; versus having to traverse multiple files.
Command Line Generation
The full command that is done to generate the file through the CLI is the following:
debug generate capture filter [filter] interface [interface] timeout [time]
The three options below are optional.
Filter | Needs to be in the style of TCP Dump and not Wireshark. |
Interface | Needs to be a recognized interface on the device e.g., eth0, br2, ie. |
Timeout | Is in seconds. |
- No filter will capture all traffic.
- No interface will capture all interfaces.
- No timeout will run indefinitely until the process is terminated by Ctrl+C in the terminal.
Cases Where We Use This
- Any case where traffic is appearing different in the Exinda than it should be; by all accounts. If IP addresses are not matching, or there seem to be missing parts of conversations.
- Packet capture on the management interface; if the Web UI is behaving strangely e.g., inaccessible and typical methods of bringing it back - process restarts, database restarts, reboots haven't worked.
- Packet capture on the management interface; if the Exinda cannot contact the License or Update server even though all DNS information is set up properly.
- Any acceleration case where acceleration is misbehaving - a packet capture will show TCP options and will show the full flows between the Exinda.
- Cases where traffic is coming in or out of multiple bridges e.g., cases where dual bridge bypass might not be working to follow the traffic flows.
- Any case involving any type of broken connections.
- Edge cache cases were determining if edge cache is working as intended.