無法從直接連接的系統可靠地 ping 6224 路由 器
好的，這是我的情況。
這是在網際網路上。6224 是這張圖片中的路由器，物理上位於 Kanata。
VLAN 1697 和 3994 均由 Internet 服務提供商提供。這些 VLAN 通過單個 1Gb 乙太網線提供。
Kanata 主機直接連接到 6224；其他兩個站點是遠端的。
VLAN 3994 是一個單一的 IP 地址空間，因此理論上該子網上的主機的物理位置並不重要。
這就是問題所在。
我有一個進一步連接到 Internet 的監控系統，因此來自監控器的探測將進入 1697 VLAN 上的此圖表。
當我從 Internet ping Albert 或 Bells Corners 的主機時，失去率為 0。連接看起來很完美。
當我在 Kanata ping 主機時，我會失去 10% 到 40% 的 ping。損失是不可預測的，但是：當我真的輸掉它們時，我總是輸掉至少 3 個，通常是 4 個，很少更多，一堆 ping。
我已在 3994 上將顯示器直接連接到 Kanata 的 6224 ..
當監視器 ping 6224 路由介面時，我看到了完全相同的失去模式——但與遠端系統的失去不同。Ping時間約為1ms。
當監視器 ping 另一個直接連接到 6224 的系統時，失去為 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 秒左右執行一次）。
這意味著 Bells Corners 或 Albert 有一個系統正在收聽我的廣播，並出於某種原因將其回顯。所以 6224 去啊，這個 mac 肯定是在 TLS 鏈路上，並相應地調整它的交換錶。
這個問題的描述是否敲響了警鐘？
好的，我想通了，我會在這裡寫出來。這個特殊的解決方案不太可能幫助任何人，因為它是一個邊緣案例。
回到與該提供商連結的古老歷史中，我們在主 VLAN 中添加了第二個 VLAN。當時，提供商隨後將這個 VLAN 連接為在他們的連接端標記和未標記的。他們的開關將標記和未標記的連接視為單獨的連接。
所以發生的事情是我的系統連接到戴爾發出 arp 廣播（這台電腦上的管理界面每半秒發出一次 arp 數據包，原因很愚蠢），交換機將連結轉發到遠端站點。提供商處的交換機在未標記介面上聽到廣播，然後在標記介面上將其發回給我。交換機聽到這一點，然後得出結論，發起廣播的 MAC 地址確實可以通過提供商的連結訪問。因此，後續數據包會被誤導。
解決方案是讓提供商更改他們的配置，使其與戴爾的配置一致。所有一般的連接問題都已停止。