![隧道上的 RSTP?](https://linux22.com/image/673628/%E9%9A%A7%E9%81%93%E4%B8%8A%E7%9A%84%20RSTP%EF%BC%9F.png)
tl;dr:是否可以在 l2tp 或 MPLS 上运行 RSTP?
我们从服务提供商的网络租用了 1G 容量,并通过该网络发送了 UDP 多播流量。提供商为我们提供了位于不同位置的 PoP 的下线,我们在每个 PoP 的交换机中终止了链接。提供商使用环形拓扑,如果出现任何电缆切断或类似问题,流量将通过另一条路径路由。但有时环中会出现多个切断,我们会完全失去连接。
我们还从另一家供应商租用了另一条暗光纤,它没有第一家供应商的覆盖范围,但仍然可以到达主要的 PoP,并且在与第一家供应商相同的交换机中终止。
目前,如果第一个提供商网络出现故障,我们会手动切换到第二个提供商。显然这不是最理想的。我们需要的是,如果第一个提供商环出现故障,流量会自动切换到第二个提供商。挑战在于,第一个提供商正在运行自己的交换机,并且运行某种冗余协议进行环管理。他们不愿意向我们提供有关其网络配置的信息,也不愿意与我们合作配置 RSTP。
在这种情况下,我们有什么选择?我想象我们在连接到第一个提供商的交换机之间运行隧道(l2tp/mpls)?所有流量都通过隧道,并在交换机上配置 RSTP。这样的事情可能吗?我们还有其他替代解决方案吗?
我们现在在 PoP 使用低端交换机,如果有解决方案,我们可以购买必要的设备。
答案1
除非绝对必要(我对此表示怀疑),否则在 WAN 上运行第 2 层绝对不是一个好主意。STP 需要进行各种调整才能在增加的延迟下正常工作。您需要测量延迟并将其应用于所有 STP 计算。广播、多播和未知单播需要端到端传输到第 2 层域中的每个交换机端口,这会占用昂贵的 WAN 带宽。第 3 层将控制广播和未知单播流量,PIM 和 IGMP 将确保多播仅传送到请求多播组流量的路由器、交换机和交换机端口。
您可能认为多播流量需要全程通过第 2 层,但事实并非如此。您可以使用第 3 层和多播路由来实现更稳定的情况。
如今,几乎没有任何东西需要端到端的第 2 层;我们生活在一个第 3 层的世界。“在可以的地方进行交换,在必须的地方进行路由”这句老话已经完全被颠覆了。现在甚至建议将第 3 层一直运行到接入交换机。第 3 层交换机现在相当先进,而且比以前便宜。
您确实应该考虑使用三层隧道而不是二层隧道。