tcpdump本身不执行vxlan解封装，抓取的是内核实际流经接口的原始字节流；所谓“解封装流量”仅出现在bridge设备（如br0）或veth host端（如vethabc123）上，此时包已剥离udp/ip/vxlan头，呈现为纯内层ip/icmp/tcp等业务报文。
tcpdump 本身不执行 VXLAN 解封装，它抓的是内核网络栈中实际流经某接口的原始字节流。所谓“抓取 VXLAN 解封装流量”，本质是抓取 已经由内核完成 VXLAN 解封装后、进入协议栈上层（如 bridge 或 veth 设备）的数据包，而不是在物理网卡或 vxlan 设备上看到的带外层 UDP/IP/VXLAN 头的隧道包。
关键：选对抓包位置
解封装后的流量只出现在以下两类接口上：
- VXLAN 对应的 bridge 设备（如 br0），当 VXLAN 设备配置为学习 MAC 并桥接时，解封装后的以太网帧会注入 bridge；
- 容器或虚拟机直连的 veth pair 的 host 端（如 vethabc123），这是内层报文真正交付给上层协议栈（IP 层）前的最后一跳。
在物理网卡（如 eth0）、vxlan 设备（如 vxlan0）或 bond 接口上抓到的，全是带 VXLAN 封装的外层包，不是“解封装流量”。
确认解封装已发生
运行以下命令检查内核是否已将 VXLAN 包正确解封装并注入上层：
-
ip -d link show vxlan0—— 查看 vxlan0 是否 UP，且dstport 4789（或你配置的端口）匹配； -
bridge fdb show dev vxlan0 | grep self—— 若有 self 条目，说明 FDB 已学习，解封装路径通常已就绪； -
cat /proc/net/vxlan/（若存在）或ip -d link | grep vxlan—— 验证 vxlan_sock 是否绑定成功。
如果 FDB 为空、vxlan_sock 未注册或 VNI 不匹配，解封装根本不会触发，此时在 bridge 或 veth 上也抓不到内层包。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
针对性抓取解封装后的真实业务流量
假设你的容器 IP 是 172.16.0.28，对应 host 端 veth 名为 vethabc123：
- 抓该容器发出的所有 IP 流量：
sudo tcpdump -i vethabc123 -n 'ip src 172.16.0.28'； - 抓该容器收发的 ICMP：
sudo tcpdump -i vethabc123 -n icmp； - 抓容器间 TCP 通信（如 80 端口）：
sudo tcpdump -i vethabc123 -n 'tcp and (src 172.16.0.28 or dst 172.16.0.42) and port 80'。
这些包的源/目的 IP 就是容器真实地址，没有 VXLAN 头，才是真正的“解封装流量”。
对比验证：同一场景下不同接口抓包差异
仍以容器 172.16.0.28 → 172.16.0.42 的 ping 为例：
- 在
vethabc123上抓到：ICMP echo request, src=172.16.0.28, dst=172.16.0.42（干净内层包）； - 在
vxlan0上抓到：UDP src=10.211.55.10:52132 dst=10.211.55.18:4789，后面跟着 8 字节 VXLAN 头 + 完整以太网帧； - 在
eth0上抓到：和vxlan0内容一致（因为 vxlan0 发包走 eth0），只是链路层头变为物理 MAC。
只有第一个才是你要的解封装结果。
