有2台服务器：
server1 – eth0 10.129.76.16 eth0.2 192.168.0.103
server2 – 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）时，我看到默认的gw在两台服务器上都使用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地址是从其他服务器无法访问的。
当我强制使用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中合适的条目，并试图摆脱（不完整）但我认为最大的问题是eth0被用来代替eth0.2从服务器1到服务器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不起作用）
感谢阅读，更谢谢回答！
这是一个片段：
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来testing：
[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
你的vlans好吗？
[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
你没有提到你正在使用的是什么内核，或者是什么版本的arping ，并且在其中有一个bug的可能性。 当您指定子接口时，您可以成功进行arping ，这一事实表明您的所有二层networking都正常工作。
尝试在server1上使用ip route get 192.168.62.101直接询问内核将如何发送您的stream量。 根据你发布的路由表，通过eth0.2发送显然是正确的行为，如果ip route get返回一个不同的答案，你可能正在看一个内核错误。 如果它返回正确的答案，那么arping是责备，但这似乎不太可能。
(incomplete)条目不需要删除; 它是一个占位符，让内核知道它尝试了ARP的IP，以便ARP答复应该被认为是有效的，而不是一个ARP中毒的攻击 ，但它没有得到答案。 它会超时。