好的，這是我的情況。
這是在網路上的。 6224 是圖中的路由器，物理駐留在 Kanata 中。
VLAN 1697 和 3994 皆由網際網路服務供應商提供。這些 VLAN 透過單一 1Gb 乙太網路線提供。
Kanata 主機直接連接到 6224；另外兩個站點位置偏遠。
VLAN 3994 是單一 IP 位址空間，因此理論上該子網路上的主機在實體上的位置並不重要。
問題就在這裡。
我有一個監控系統，它進一步連接到互聯網，因此來自監控器的探測將進入 1697 VLAN 上的此圖。
當我從網際網路 ping Albert 或 Bells Corners 的主機時，遺失率為 0。連接看起來很完美。
當我 ping Kanata 的主機時，我丟失了 10% 到 40% 的 ping。損失是不可預測的，但是：當我確實丟失它們時，我總是會丟失至少 3 個（通常是 4 個，很少更多）一堆 ping。
我已將監視器直接連接到 3994 上 Kanata 的 6224 上。
當監視器 ping 6224 路由介面時，我看到完全相同的遺失模式 - 但與遠端系統的遺失不同時。 Ping 時間約 1ms。
當監視器對直接連接到 6224 的另一個系統執行 ping 操作時，遺失率為 0。 Ping 時間約 0.1ms，是 ping 路由器時間的十分之一。
有人知道這是怎麼回事嗎？
更新也許會讓事情變得不那麼清楚
似乎發生的情況是，傳入和傳出 ISP 連線的流量都正常。從路由器大腦到交換大腦（或可能返回）的流量才是問題所在。
我不能怪 ISP，因為兩個遠端站點的網路存取是可靠的。只有直接連接到 6224 的主機才會出現問題。
更新2
好吧，在長時間盯著痕跡之後，我有了一個更具體的症狀。
我在 ISP 上行鏈路的 vlan 3994 上進行了 tcpdump 查找我自己的位址，理論上我應該看到的是前往遠端站點的廣播流量。相反，我看到了我希望在系統介面上看到的資料包，透過該 VLAN 上的 TLS 進行傳輸。
所以：
由於某種原因，6224 經常認為我的系統位於 TLS 的遠端。
當我在工作正常時檢查切換表時，我的條目如下所示：
3994 0007.E924.F714 2/g16 Dynamic
……這是有道理的，因為它插入連接埠 16。
3994 0007.E924.F714 2/g22 Dynamic
錯誤定向的資料包流似乎是由我的系統的廣播引導的。但是，我看到一個廣播離開我的系統，兩個廣播在 3994 VLAN 上發送到 TLS。通常它是 IGMP V2 成員報告/加入組 224.0.0.251，但有時它是我係統上的管理晶片為自己進行 arping（它每 2 秒左右執行一次，原因很愚蠢）。
這意味著貝爾斯角或阿爾伯特有一個系統正在收聽我的廣播，並出於某種原因迴響它。所以 6224 啊，這台 mac 必須確實關閉了 TLS 鏈路，並相應地調整其交換錶。
這個問題的描述是否引起了任何共鳴？
答案1
好吧，我已經弄清楚了，我會把它寫在這裡。這個特定的解決方案不太可能對任何人有幫助，因為它是一種邊緣情況。
回顧與該提供者的連結的古老歷史，我們在主 VLAN 的基礎上新增了第二個 VLAN。當時，提供者將這個 VLAN 連接為兩個標記和在他們的連接端未標記。他們的交換器將標記和未標記的連接視為單獨的連接。
因此，發生的情況是，連接到戴爾的我的系統發出arp 廣播（這台電腦上的管理介面出於愚蠢的原因每半秒發出arp 封包），交換器將其沿著鏈路轉發到遠端站點。提供者處的交換器聽到未標記介面上的廣播—並在標記的介面上將其發送回給我。交換器聽到此訊息後得出結論：確實可以透過提供者的連結存取發起廣播的 MAC 位址。因此後續資料包會被誤導。
解決方案是讓提供者更改其配置，使其與戴爾的配置一致。所有一般連線問題都已停止。