我想就我可以改进 BGP 双供应商、双路由器设计的方法获得一些意见。每个提供程序提供一个 /24 公共子网。我将路由器、电路、子网、HSRP 组和提供商分别称为 A 和 B。每个电路的带宽足以满足整个负载的需求。
当前设计
当前的设计试图实现每个提供者的对称性。在稳定状态下,预期的路由逻辑是进/出子网 A 的流量仅通过电路 A,进/出子网 B 的流量仅通过电路 B。这些电路将在故障状态下相互备份。
提供者只通告默认路由。出站路由需要混合使用 PBR 和 HSRP。路由器之间没有路由:没有 iBGP、没有 OSPF、没有静态路由。相反,有两个 HSRP 组跟踪默认路由。路由器 A 是 HSRP 组 A 的主要路由器,路由器 B 是 HSRP 组 B 的主要设备。下游设备有一条指向 HSRP 组 A 的默认路由和 PBR,它将来自子网 B 的流量定向到 HSRP 组 B。入站路由受前置和社区。子网 A 在电路 B 上预置和共享,子网 B 在电路 A 上预置和共享。
我看到这个设计有很大的改进空间。互联网拓扑意识的缺乏与电路亲和力的结合完全消除了最佳路径选择。对供应商的层级指定存在担忧,并且设计已被合理化为提供“可接受的性能”并且更易于排除故障。事实上,设计不可能变得更简单。我已经证明传输额外的 AS 会为 RTT 增加 6 跳和 63 毫秒(+421%)。我宁愿不满足于可接受。
更好的设计
更好的设计为路由器提供尽可能多的 Internet 拓扑感知。最佳路径算法用于确定入站和出站路由逻辑。电路会在故障状态下相互支持。
提供商宣传完整视图。路由器运行 iBGP 和 OSPF。HSRP 被淘汰。出站路由将是纯粹基于目的地的最佳路径,入站路由将留给最佳路径算法和中转提供商的奇思妙想。
现在我把它打出来,看起来确实更简单了。至少,解释的字数少了。有人担心不对称,但我在当前的设计中看到了很多不对称。我认为它们可能同样容易出现不对称,我真的不担心。我们从未见过因此出现问题。目前它被降级为 ifs 的领域,“如果我们必须解决某些问题怎么办?”
我在这里离基地很远还是我撞到了头上?其他人是如何解决这个问题的?谷歌会怎么做?