好的，我的情况如下。
这是互联网上的信息。6224 是这张图片中的路由器，实际位于 Kanata。
VLAN 1697 和 3994 均由互联网服务提供商提供。这些 VLAN 通过一条 1Gb 以太网线提供。
Kanata 主机直接连接到 6224；另外两个站点位于远程。
VLAN 3994 是单个 IP 地址空间，因此理论上该子网上的主机的物理位置并不重要。
这就是问题所在。
我有一个进一步连接到互联网的监控系统，因此来自监控器的探测将进入 1697 VLAN 上的这个图表。
当我从互联网 ping Albert 或 Bells Corners 的主机时，没有任何丢失。连接看起来很完美。
当我 ping Kanata 的主机时，我会丢失 10% 到 40% 的 ping。丢失的 ping 次数是无法预测的，但是：当我丢失 ping 次数时，我总是会丢失至少 3 次，通常是 4 次，很少会丢失更多。
我已将显示器直接连接到 3994 上的 Kanata 的 6224。
当监视器 ping 6224 路由接口时，我看到完全相同的丢失模式 - 但与远程系统的丢失时间不同。 ping 时间约为 1ms。
当监视器 ping 另一个直接连接到 6224 的系统时，没有任何丢失。ping 时间约为 0.1ms，是 ping 路由器时间的十分之一。
有人知道这里发生了什么事吗？
更新可能会让事情变得不那么清楚
似乎发生的情况是，进出 ISP 连接的流量没有问题。从路由器大脑到交换大脑（或可能返回）的流量才是问题所在。
我不能责怪 ISP，因为两个远程站点的互联网访问都很稳定。只有直接连接到 6224 的主机有问题。
更新 2
好的，经过大量时间盯着痕迹之后，我发现了更具体的症状。
我对 ISP 上行链路的 3994 号 vlan 执行了 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 链路故障状态”，并据此调整其交换表。
对这个问题的描述有没有给你一些提示？
答案1
好的，我找到了答案，我会在这里写出来。这个解决方案不太可能对任何人有帮助，因为它是一个极端情况。
回顾与该提供商建立链接的早期历史，我们在主 VLAN 中添加了第二个 VLAN。当时，提供商将此 VLAN 连接为两个标记和他们的交换机将标记和未标记的连接视为单独的连接。
那么，会发生什么呢？我的系统连接到戴尔，发出一个 arp 广播（这台电脑的管理接口每半秒发出一次 arp 数据包，原因很愚蠢），交换机会沿着链路转发到远程站点。提供商的交换机在未标记的接口上听到广播——并通过标记接口将其发回给我交换机听到这个消息后，得出结论：发出广播的 MAC 地址确实可以通过提供商的链路访问。因此，后续数据包会被误导。
解决方案是让提供商更改其配置，使其与戴尔的配置一致。所有常规连接问题都已解决。