Overlay networks, like those built with GRE or VXLAN, aren’t just a layer of abstraction; they’re actively rewriting your network packets, and tcpdump needs to know about it to show you anything useful.
Let’s see tcpdump in action with VXLAN. Imagine you have a virtual machine on host 192.168.1.10 with an IP address of 10.0.0.5. This VM is talking to another VM on host 192.168.1.20 with IP 10.0.0.6. The overlay network uses VXLAN, encapsulating the inner 10.0.0.0/24 traffic within UDP packets on the 192.168.1.0/24 network.
Here’s how you’d capture the VXLAN traffic on the host 192.168.1.10:
sudo tcpdump -i eth0 -vvv udp port 4789 -w vxlan_capture.pcap
This command captures traffic on the physical interface (eth0), showing verbose output (-vvv), looking for UDP packets on port 4789 (the standard VXLAN port), and saving it to vxlan_capture.pcap.
If you open vxlan_capture.pcap in Wireshark, you’ll see the outer UDP packets. To see the inner packet (the original VM-to-VM traffic), you need to tell Wireshark to dissect the VXLAN payload. In Wireshark, go to Analyze -> Decode As... and set the transport layer protocol for UDP port 4789 to VXLAN. Now you’ll see the 10.0.0.5 to 10.0.0.6 communication.
Now, what if you want to capture the GRE traffic? GRE (Generic Routing Encapsulation) is another common tunneling protocol, often identified by its IP protocol number 47. Suppose our VMs are using GRE, and the tunnel endpoints are 192.168.1.10 and 192.168.1.20.
To capture GRE traffic on 192.168.1.10:
sudo tcpdump -i eth0 -vvv ip proto 47 -w gre_capture.pcap
This captures traffic on eth0, verbosely, looking for IP packets with protocol number 47 (GRE), and saving to gre_capture.pcap.
When you open gre_capture.pcap in Wireshark, you’ll see the outer IP packets. Wireshark usually recognizes GRE automatically. You’ll see the inner packet headers, showing the original 10.0.0.5 to 10.0.0.6 traffic.
The key mental model to grasp is that tcpdump on the host sees the encapsulated packet. It doesn’t inherently know about your overlay network’s internal addressing or protocols. You’re capturing the carrier pigeon, not the message inside, unless you tell the mail carrier (Wireshark) how to open the envelope.
The surprise is that tcpdump often doesn’t show you the inner packet by default. It just shows you the raw bytes of the encapsulated tunnel. You have to explicitly tell your capture analysis tool (like Wireshark) to interpret specific UDP ports or IP protocol numbers as tunnel traffic. It’s like looking at a car driving down the road; tcpdump sees the car. You have to tell Wireshark that this particular car is a delivery van carrying a specific type of package (VXLAN or GRE).
Understanding the IP protocol numbers and UDP ports is crucial. VXLAN uses UDP port 4789 by default. GRE is IP protocol 47. Other tunneling technologies might use different ports or protocol numbers. Knowing these identifiers allows you to filter your tcpdump commands precisely.
For instance, if you want to see only the inner traffic destined for 10.0.0.5 within a VXLAN tunnel on host 192.168.1.10, and you know the outer source IP is 192.168.1.20, you could try:
sudo tcpdump -i eth0 -vvv 'udp port 4789 and host 192.168.1.20' -w specific_vxlan.pcap
This filters for VXLAN traffic coming from the specific tunnel endpoint. Once loaded into Wireshark and decoded as VXLAN, you can then filter by the inner IP address 10.0.0.5.
A common pitfall is capturing on the wrong interface. If you’re trying to see overlay traffic, you need to capture on the physical interface of the host acting as a tunnel endpoint, not a virtual interface within a VM that’s inside the overlay.
The real power comes when you combine these filters. To capture GRE traffic between two specific hosts, say 192.168.1.10 and 192.168.1.20:
sudo tcpdump -i eth0 -vvv 'host 192.168.1.10 and host 192.168.1.20 and ip proto 47' -w gre_between_hosts.pcap
This command captures packets on eth0 that are going between 192.168.1.10 and 192.168.1.20 and are identified as GRE.
Most network engineers think of tcpdump as a tool for raw IP traffic. But for overlay networks, it’s fundamentally about capturing the encapsulation protocol. You’re not just looking at packets; you’re looking at packets inside packets. This means your filtering and analysis needs to account for both the outer and inner layers of traffic.
The next step after successfully capturing and dissecting overlay traffic is understanding how to correlate packet timings between the inner and outer layers to diagnose latency issues within the tunnel.