情境
有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）時，我看到兩台伺服器上的預設 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 位址。
當我強制 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.101on server1 直接詢問核心它將如何發送您的流量。根據您發布的路由表，透過 eth0.2 發送顯然是正確的行為，如果ip route get返回不同的答案，您可能正在查看核心錯誤。如果它返回正確的答案，那arping就是罪魁禍首，但這似乎不太可能。
該(incomplete)條目不需要刪除；它是一個佔位符，讓核心知道它確實嘗試了 ARP 該 IP，因此 ARP 回應應被視為有效而不是無效。ARP 中毒攻擊，但沒有得到答案。就會超時了