我有一台 Linux 機器，有一個我可以使用的真實（與虛擬，又名別名）乙太網路介面（eth0 用於其他目的 - 不能使用它，也不能添加更多網卡）。說是eth1
我需要透過 SNMP 控制一些物件/實體，因此我為每個物件設定了一個虛擬乙太網路介面及其對應的 MAC 位址。我透過以下方式執行此操作（例如 vif1）：
ip -family inet link add link eth1 name vif1 address <the MAC addr> type macvlan
ip link set vif1 up multicast on
ip route del default dev vif1 table main /* enable the pings/TFTP going out! */
ip route add default via 192.168.1.1 table main proto static metric /* restore orig */
eth1、vif1、vif2...全部從單一（遠端）DHCP 伺服器取得 IP 位址。當然，所有這些 IP 位址都位於同一 IP 子網路中，例如 10.11.1.0/24
問題：從 Linux 機器 ping 到 DHCP 伺服器（例如 10.11.1.1）機器正常。從 DHCP 伺服器電腦 ping 到 eth1 IP 或任何 vif#X IP 都有效，但（這問題，我想...）只有 eth1 回應 ICMP 封包（透過 ifconfig 計數器和wireshark 嗅探驗證）此問題導致無法連接到與 vif 介面的 IP 位址關聯的 SNMP 代理程式。
我猜我需要設定內部路由，以便 IP 封包到達目的地 vif#X。我嘗試過使用新的 ip 路由表添加 ip 規則，但可能沒有正確設定它（新表）...任何人都可以告訴我如何（最好為什麼）執行此操作？
Linux 機器運行 Ubuntu9.04，DHCP 伺服器運行 Windows XP SP3
答案1
終於解決了：這是一個與ARP相關的問題。
- DHCP 伺服器將 IP 位址指派給虛擬介面 MAC 位址，並將該對設定到伺服器的本機 ARP 表中
- Linux 機器將新的 IP 位址綁定到請求它的虛擬介面。
- PING 的工作方式有兩種：
- 當 ping 時從Linux到伺服器，透過真實介面出去（在同一個IP子網路上）
- 從伺服器 ping 時到Linux，再次真正的介面回應，所以它似乎好像一切都好…
但
當伺服器發送 IP 封包（在我的例子中為 SNMP 訊息）時，它使用虛擬介面的 MAC 位址。當它到達 Linux 機器時，核心只是丟棄這些幀，因為它不知道如何轉送它們；執行 Wireshark 會顯示這些訊息，因為介面通常處於混雜模式
為了使 SNMP 訊息到達綁定到虛擬介面的 SNMP 代理，IP 封包必須具有真實介面的MAC位址（我認為只有這樣核心才會根據IP位址進行VLAN路由......）
實現這一目標的方法是發送一個免費ARP從 Linux 盒子真實介面向伺服器發出請求，表示新分配的 IP 位址（到虛擬介面之一...）由真實介面的 MAC 位址「擁有」。這會正確更新伺服器的 ARP 表。
順便說一句，這也解釋了為什麼在開始 SNMP 流量之前等待一段時間是有效的：伺服器的 ARP 表條目已過期，因此伺服器發送 ARP 請求並回應正確地由真實介面
答案2
為什麼不設置一個橋接設備？
brctl addbr bridge將實體設備的 IP 和 MAC 新增至該橋，將沒有 IP 的裝置移至該網橋，然後將您的 VIF 也連接到該網橋。