tcpdump (-i any) 与 vlan

网络工程 VLAN 转储
2021-07-27 17:40:17

我有一个关于 tcpdump（捕获所有接口）和我看到的奇怪捕获的问题。

环境：

2 台 Linux 设备连接并配置了 VLAN TAG (802.1q)。我正在 2 个设备 vlan 接口之间 ping，网络方面一切正常。当使用 tcpdump 捕获所有接口时tcpdump –i any –n –e。

我看到这个：

前 3 个数据包看起来不错

在主界面上接收（标记）：

-6:-45:-40.2216 In 00:11:22:33:44:56 ethertype 802.1Q (0x8100), length 104: vlan 10, p 0, ethertype IPv4, 10.0.0.10 > 10.0.0.1: ICMP echo request , id 2452, seq 487, 长度 64

在 vlan 接口上接收（未标记）：

-6:-45:-40.2217 在 00:11:22:33:44:56 以太网类型 IPv4 (0x0800)，长度 100：10.0.0.10 > 10.0.0.1：ICMP 回显请求，id 2452，seq 487，长度

从 vlan 接口发送（未标记）：

-6:-45:-40.2221 输出 00:11:22:33:44:55 以太网类型 IPv4 (0x0800)，长度 100：10.0.0.1 > 10.0.0.10：ICMP 回显回复，id 2452，seq 487，长度

但是从主界面发送的第四个看起来是错误的：

-6:-45:-40.2223 Out 00:11:22:33:44:55 ethertype 802.1Q (0x8100), length 100: vlan 1280, p 2, ethertype Unknown, LLC, dsap SNA (0x04) Group, ssap Unknown (0x3e) Response, ctrl 0x0000: Information, send seq 0, rcv seq 0, Flags [Response], length 80

在为 tcpdump 定义特定接口（eth0 或 eth0.10）时，它看起来不错：

“tcpdump -i usb0 -n -e”

-6:-13:00.40042 00:11:22:33:44:56 > 00:11:22:33:44:55, ethertype 802.1Q (0x8100), length 102: vlan 10, p 0, ethertype IPv4, 10.0.0.10 > 10.0.0.1：ICMP 回显请求，id 2452，seq 2442，长度 64 -6:-13:00.40100 00:11:22:33:44:55 > 00:11:22:363:44:44: , ethertype 802.1Q (0x8100), length 102: vlan 10, p 0, ethertype IPv4, 10.0.0.1 > 10.0.0.10: ICMP echo reply, id 2452, seq 2442, length 64

“tcpdump -i usb0.10 -n –e”

-6:-52:-14.5791 00:11:22:33:44:56 > 00:11:22:33:44:55，以太类型 IPv4 (0x0800)，长度 98：10.0.0.10 > 10.0.0.1：ICMP echo 请求，id 2452，seq 94，长度 64 -6:-52:-14.5795 00:11:22:33:44:55 > 00:11:22:33:44:56，以太类型 IPv4 (0x0800)，长度98：10.0.0.1 > 10.0.0.10：ICMP 回显回复，id 2452，seq 94，长度 64

目前，我使用 USB 网络接口，但以太网 (eth0 / eth0.10) 也是如此。

使用时多出的 2 个字节–i any是因为 Linux 添加了它的 Linux 熟 2 个字节。

任何想法，为什么 tcpdump 在使用时显示这一行–i any？

由于流量运行良好，我想这只是 tcpdump 的解析问题？？？

-6:-45:-40.2223 Out 00:11:22:33:44:55 ethertype 802.1Q (0x8100), length 100: vlan 1280, p 2, ethertype Unknown, LLC, dsap SNA (0x04) Group, ssap Unknown (0x3e) Response, ctrl 0x0000: Information, send seq 0, rcv seq 0, Flags [Response], length 80

2个回答

我认为 tshark 可以应付今天的熟捕获，我很少再使用 tcpdump 了。

回到当 tshark 无法处理这个问题（当我捕获 ERSPAN 时）时，我编写了可以从每帧中弹出 N 个字节的脚本，如果您在无法识别的东西上进行隧道传输，这也非常有用。

几年后....:D

我遇到了同样的问题。

经过数小时的 tcpdump 和wireshark，我已经弄清楚问题是什么，或者我做错了什么。

VLAN tagged（从这个角度来看，tag值并不重要）数据包被接收并发送后，我（我写的交换机程序）不小心忘记在数据包头中添加相应的VLAN头，但是Ethernet.etherType仍然是 0x8100（VLAN 的 ETHERTYPE）。这意味着在 Ethertype 之后，应用程序（在我们的例子中tcpdump/wireshark）需要一个 4 字节的 VLAN 标头，但 IPv4 标头即将到来。由于 IPv4 以 4 位的version（设置为 4）开始，因此 4 位的header length（如果考虑正常的 IPv4 数据包，例如 20 字节，则设置为 5），然后是 8 位的diffserv等，例如，IPv4 标头以0x4500...

这意味着前 4 位被认为是 3 位宽VLAN PCP和 1 位宽VLAN DEI（这是0x4在我们的简单 IP 数据包中），然后剩下的 12 位将是VLAN VID，这是0x500从简单 IP 数据包产生的在一个误会1280 VLAN VID (int('0x500',16) = 1280)。

我希望它有帮助。

其它你可能感兴趣的问题
上一篇河床广域网优化器未收到流量 下一篇Cisco 和 Nortel 交换机之间的 Etherchannel 连接