經驗分享

PVE VM 全部不通：節點接到 Mirror Port

Jason Cheng 發布 2025.11.07 瀏覽 1 次

Linux Proxmox VE 系統管理網路裝置管理

本文目錄

環境
症狀
追查過程
原因
處理方式
類似症狀的其他原因
結論
參考資料

這是一次很少見、但很難查的網路問題：一台新上線的 Proxmox VE 節點，VM 完全連不到外面，連同一台節點上的 VM 彼此都 ping 不通，節點本身卻還連得到。PVE 的網路設定看起來完全正常，換了幾種設定都一樣。

最後的答案在交換器上：這台節點的網路線，被接到了交換器的 mirror port（連接埠鏡像的目的端）。這篇記錄從症狀一路追到原因的過程。

環境

網路設定很單純，一張實體網路卡橋接到 vmbr0：

auto lo
iface lo inet loopback

iface eno8303 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.10.11/24
        gateway 192.168.10.254
        bridge-ports eno8303
        bridge-stp off
        bridge-fd 0

iface eno8403 inet manual
iface eno12399np0 inet manual
iface eno12409np1 inet manual

症狀

VM 對外完全不通，同一台節點上的 VM 之間也 ping 不通
節點本身可以連線，網頁管理介面也開得起來，但有時候很慢
從節點對外 ping，回應會出現 DUP!

64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=0.412 ms
64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=0.425 ms (DUP!)

DUP! 代表同一個 ping 收到了兩份回應，這是第一個很明顯的線索：網路上有東西在複製封包。

追查過程

核心記錄

dmesg -T | tail -30

畫面被同一行洗版：

vmbr0: received packet on eno8303 with own address as source address (addr:aa:bb:cc:dd:ee:01, vlan:0)
net_ratelimit: 236 callbacks suppressed

意思是：橋接器從實體網路卡收到了來源 MAC 是自己的封包。正常情況下，自己送出去的封包不可能從外面再收回來，除非外面有東西把它送了回來。

確認橋接器的 MAC 表

bridge fdb show br vmbr0 | grep aa:bb:cc:dd:ee:01

aa:bb:cc:dd:ee:01 dev eno8303 vlan 1 master vmbr0 permanent
aa:bb:cc:dd:ee:01 dev eno8303 master vmbr0 permanent

節點自己的 MAC 是 permanent，不會被改掉，所以節點本身還能勉強通訊，只是核心一直在警告。

再看 VM 的 MAC（在 VM 的硬體設定裡可以看到）：

bridge fdb show br vmbr0 | grep -i bc:24:11

正常情況下，VM 的 MAC 應該記在它自己的 tapXXXi0 介面上；這次卻被記到了實體網路卡 eno8303 上。橋接器以為 VM 在交換器那一端，要送給 VM 的封包全部往實體網路卡丟，VM 當然收不到，同一台節點上的 VM 互 ping 也就跟著不通。

抓封包

tcpdump -i eno8303 -n -e ether src aa:bb:cc:dd:ee:01

11:45:01.421735 IP 192.168.10.11.8006 > 192.168.20.50.3670: Flags [P.], seq 2346474713:2346474895, length 182
11:45:01.421952 IP 192.168.10.11.8006 > 192.168.20.50.3670: Flags [P.], seq 0:182, length 182
11:45:01.508698 IP 192.168.10.11.8006 > 192.168.20.50.3670: Flags [P.], seq 182:452, length 270
11:45:01.508775 IP 192.168.10.11.8006 > 192.168.20.50.3670: Flags [P.], seq 182:452, length 270

節點送出的每一個封包，相隔不到 0.1 毫秒又出現一次，內容完全一樣。一份是自己送出去的，另一份是被交換器送回來的。

到這一步可以確定：問題不在 PVE，而是交換器把這個連接埠上的流量複製了一份送回來。

查交換器的連接埠

請網路管理人員檢查這台節點接的交換器連接埠，結果發現那個連接埠被設定成連接埠鏡像（port mirroring / SPAN）的目的端，原本是給流量分析設備用的，後來設備撤掉，連接埠被當成一般連接埠拿來接新的伺服器。

如果節點上有裝 lldpd，可以直接看到自己接在交換器的哪個連接埠，跟網路管理人員溝通會快很多：

apt install lldpd
lldpctl

原因

現象	原因
ping 出現 `DUP!`	鏡像目的端會收到被鏡像的流量，自己送出的封包也被複製一份送回來
`received packet ... with own address as source address`	橋接器收到來源是自己 MAC 的封包
VM 對外不通	多數交換器的鏡像目的端不會轉送一般流量，也不學習 MAC，VM 的封包出不去
同一台節點上的 VM 互 ping 不通	被送回來的封包帶著 VM 的來源 MAC，橋接器把 VM 的 MAC 學到實體網路卡上，給 VM 的封包都被送錯方向
節點本身還勉強能通	節點自己的 MAC 在橋接器裡是 `permanent`，不會被覆蓋

處理方式

把交換器連接埠從鏡像設定中移除，恢復成一般的 access 或 trunk 連接埠，或是把網路線改接到正常的連接埠。以常見設備為例：

! Cisco：查看與移除鏡像設定
show monitor session all
no monitor session 1

! HPE/Aruba
show mirroring

交換器改好之後，在 PVE 上清掉橋接器學錯的 MAC（或直接等它逾時更新），VM 馬上就恢復正常：

ip link set vmbr0 down && ip link set vmbr0 up

注意：重新啟動 vmbr0 會讓節點與所有 VM 短暫斷線，如果是透過這個介面連進節點的，可能會被中斷，建議從主控台或 iDRAC/iLO 這類管理介面操作。不想重新啟動介面的話，等 MAC 表逾時（預設約 5 分鐘）也會自動更新。

類似症狀的其他原因

DUP! 和「收到自己的封包」不一定都是 mirror port，遇到時也可以檢查：

網路迴圈：兩條線接到同一台交換器又沒有 STP，或 PVE 上兩張網路卡被橋接到同一個 vmbr。PVE 的橋接預設 bridge-stp off，不會幫你擋迴圈
Bond 設定與交換器不一致：PVE 用 balance-rr、balance-alb，交換器卻沒有對應設定，封包會從另一條線繞回來
虛擬化或雲端環境的網路卡 hairpin、反射設定：巢狀虛擬化時偶爾會遇到

結論

這次查了不少時間在 PVE 的網路設定上，事後回想，DUP! 加上 received packet with own address 這兩個訊號，其實已經直接指向交換器端在複製封包。下次遇到 VM 莫名其妙全部不通、節點本身卻還能連，先抓封包看看有沒有重複，比反覆改 PVE 設定有效率。

另外也提醒：交換器上撤掉的流量分析設備，連接埠的鏡像設定要一起清掉，不然下一個接上來的人就會遇到這個問題。