语境
有 2 个服务器：
服务器1-eth0 10.129.76.16 eth0.2 192.168.0.103
服务器2-eth0 10.129.79.1 eth0.2 192.168.62.101
192.xxx 地址连接到同一个 vlan（vlan2），并且能够互相看到。10.xxx 地址连接到不同的 vlan，彼此之间无法看到。
根据 David Swartz 的要求：服务器 1 上的路由表是：
~$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.129.76.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.192.0 U 0 0 0 eth0.2
0.0.0.0 192.168.61.254 0.0.0.0 UG 100 0 0 eth0.2
服务器2上的路由表是：
~$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 <public IP gw> 0.0.0.0 UG 100 0 0 eth0.11
10.129.79.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
<public IP> 0.0.0.0 255.255.255.128 U 0 0 0 eth0.11
192.168.0.0 0.0.0.0 255.255.192.0 U 0 0 0 eth0.2
问题：
当我从服务器 1 ping 到服务器 2 时，似乎没有数据包到达，反之亦然。当我检查路由 (route -n) 时，我看到默认网关在两台服务器上都使用 eth0.2。但是当我使用 arping 时，我得到了单向响应（从服务器 2 到服务器 1），但反之亦然。
arping 192.168.62.101
ARPING 192.168.62.101 from 10.129.76.16 eth0
^CSent 2 probes (2 broadcast(s))
Received 0 response(s)
正如您所看到的，它使用 10.xxx 地址而不是 192.xxx，而且正如我之前所说，10.xxx 地址无法从其他服务器访问。
当我强制 arping 使用 eth0.2 时，它确实有效。
从这两台服务器中的任何一台 ping 其他服务器都没有遇到任何问题。
我确实在 arp 表中看到了这一点：
~# arp -n | grep 192.168.0.103
192.168.0.103 (incomplete) eth0
和
~# arp -n | grep 192.168.62.101
问题
很明显...我怎样才能让这些服务器再次互相看到？
我绑的东西
清除 arptable 中的适当条目并尝试摆脱（不完整）但我认为最大的问题是，对于从服务器 1 到服务器 2 的数据包，使用 eth0 而不是 eth0.2
由于 David Swartz 对路由表的评论，我在其中添加了一条定义主机的路由。我添加了
192.168.0.103 0.0.0.0 255.255.255.255 UH 0 0 0 eth0.2
和
192.168.62.101 0.0.0.0 255.255.255.255 UH 0 0 0 eth0.2
到适当的服务器，但这并没有解决问题，所以我推测问题不在于路由。
我猜
我猜测问题出在以下几点。
~$ arp -n | grep 192.168.0.103
192.168.0.103 (incomplete) eth0
但我无法删除此条目。（arp -d 192.168.0.103 没有效果）
感谢您的阅读，更感谢您的回答！
答案1
以下是一段代码：
arpping 不尊重本地路由表：
== mbrownnyc [gateway/web/freenode] has joined ##networking
[10:14] <mbrownnyc> mAniAk-_-: any idea why, if his routing table reflects the proper interface to route 192.168.0.0/18 packets, why when he `arping 192.168.62.101` the kernel would think to make the source address that of the other interface?
[10:14] <mbrownnyc> it's very very weird to me
[10:16] <mbrownnyc> tafelpoot: unless arping has a bug in the code or something?
[10:17] <mbrownnyc> can you use another piece of software? like hping?
[10:17] <catphish> mbrownnyc: arping doesn't respect the routing table
[10:17] <catphish> you have to specify the interface manually
[10:17] <mbrownnyc> catphish: voila!
[10:18] <catphish> no idea why, it's just never been a feature of it, it seems to use the first ethernet interface unless you tell it otherwise
[10:19] <mbrownnyc> catphish: interesting catphish that's the whole "problem" here, the testing mechanism, I guess
使用icmp测试：
[10:25] <catphish> mbrownnyc: that guy is testing with arping which makes no sense since arping doesn't use the routing table
[10:26] <catphish> it should be ping
[10:26] <catphish> and if ping fails, arping with an interface specified
[10:26] <mAniAk-_-> GG
[10:26] <catphish> oh, it does work when forcing arping to use the right address
[10:27] <catphish> so im not sure what the problem might be
[10:27] <mAniAk-_-> ARPING 192.168.62.101 from 10.129.76.16 eth0
[10:27] <mAniAk-_-> not eth0.2
[10:28] <catphish> indeed
[10:28] <catphish> because the interface wasn't specified
[10:28] <catphish> apparantly it works when the interface is specified
[10:28] <catphish> so i don't see the problem
你的 VLAN 还好吗？
[10:29] <catphish> it's also possible the the vlan config is messed up, i don't like mixing native and tagged vlans like that
[10:29] <mAniAk-_-> yeah i thought so too
答案2
您没有提到您使用的是什么内核或哪个版本的arping，并且其中一个或另一个可能存在错误。arping当您指定子接口时您可以成功执行这一事实确实表明您的所有第 2 层网络都正常运行。
尝试ip route get 192.168.62.101在 server1 上使用 直接询问内核如何发送您的流量。根据您发布的路由表，通过 eth0.2 发送显然是正确的行为，如果ip route get返回不同的答案，则可能是内核错误。如果它返回正确的答案，那么arping就是罪魁祸首，但这似乎不太可能。
该(incomplete)条目不需要删除；它是一个占位符，让内核知道它确实尝试过 ARP 该 IP，因此 ARP 回复应该被视为有效，而不是ARP 毒药攻击，但未收到答复。它会超时。