我正在尝试debuggingnetworking问题。 在这个过程中，我注意到当我尝试进行arping时，收到的arp包大于发送的arp包，由tcpdump输出。
（请注意，两端都有一个到eth1接口的br100桥）。
命令：
# arping 10.40.0.5 -I br100 -c1 ARPING 10.40.0.5 from 10.40.0.1 br100 Sent 1 probes (1 broadcast(s)) Received 0 response(s)
tcpdump（发件人）：
# tcpdump -nnvvXSs 1514 arp -i eth1 tcpdump: WARNING: eth1: no IPv4 address assigned tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 1514 bytes 21:32:29.529106 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.40.0.5 (ff:ff:ff:ff:ff:ff) tell 10.40.0.1, length 28 0x0000: 0001 0800 0604 0001 5478 1a86 50c9 0a28 ........Tx..P..( 0x0010: 0001 ffff ffff ffff 0a28 0005 .........(..
tcpdump（接收器）：
# tcpdump -nnvvXSs 1514 arp -i eth1 tcpdump: WARNING: eth1: no IPv4 address assigned tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 1514 bytes 21:32:29.532966 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.40.0.5 (ff:ff:ff:ff:ff:ff) tell 10.40.0.1, length 46 0x0000: 0001 0800 0604 0001 5478 1a86 50c9 0a28 ........Tx..P..( 0x0010: 0001 ffff ffff ffff 0a28 0005 0000 0000 .........(...... 0x0020: 0000 0000 0000 0000 0000 dac7 07ed ..............
收到的arp数据包比发送的arp数据包大18个字节。 我试图弄清楚这是否正常，或者是一个问题。 （这个数据包最终绑定到一个没有正确接收的虚拟机实例）。
谁在添加这18个字节，为什么？ 它是发送者，交换机还是接收者？ 他们是什么意思？
我怀疑是（Cisco Nexus 3000）交换机，它与802.1Q封装有关。
46字节是以太网数据包中允许的最小用户数据量。
有一个8字节的前导码，一个6字节的目标MAC，一个6字节的源MAC，一个2字节的types/长度，用户数据和一个4字节的帧校验序列。 由于最小包为64字节 ，这意味着用户数据不能小于46字节。
以太网上的每一个协议都必须处理这个问题。 ARP通过忽略数据后的“垃圾”来处理它。
只是想添加额外的信息（networking视angular），为什么路由器不接受在哪种情况下的数据包
如果数据包大小低于64字节，则路由器将假定数据包为RUNT并拒绝数据包
（数据包<= 64拒绝RUNT数据包）
因为在Packets中头的大小是64头，所以看起来数据包不包含数据包腐败的一些原因。
如果数据包大小高于端口（路由器）MTU（快速以太网默认1500，千兆以太网9000）然后数据包计为巨大数据包和拒绝数据包。 由于端口MTU是1500，它不会接受该数据包。
（数据包>端口MTU（1500）拒绝它为巨型）
如果数据包大小为1519-1564，则此数据包称为Jambo婴儿数据包，并仅接受端口MTU为9000的数据包
如果所有条件都通过，则路由器将执行循环冗余校验（CRC）