F5作为骨干路由器

网络工程 路由器 网络核心 设计 f5
2021-07-15 22:38:17

我们使用 LTM 和 ZebOS 已经有一段时间了。我们一次又一次地遇到 OSPF 错误,升级通常可以解决这些错误。ZebOS的BGP在这方面一直比较稳定。

我们计划扩展我们的站点(将有自己的 DC),并且需要一个(运营商级)路由器,它可能有一个 100G 的互联网管道(和内部的 10/40G 连接)。Viprion 4800 机箱是路由器的糟糕选择吗?

我们想要一些支持 MPLS L3/L2VPN 的东西,但 F5 尚不支持。另一方面,未来可能会有负载平衡要求,在这种情况下,我们必须在上游 Cisco/Juniper 路由器后面放置一个 F5。通过将 F5 作为该站点的路由器,我们取消了 SNAT(因为它将内联所有流量),并利用其 ADC 功能。

由于我没有遇到任何供应商文档,因此我担心的其他事情是 F5 是否可以在其转发表中保存互联网路由表(超过 50 万条路由),以及我们的性能是否受到使用通配符转发虚拟服务器而不是路由器上的硬件转发。

非常感谢关于 F5 是否应该/不应该是一个选择,或者这里是否有人使用 F5 作为骨干路由器的任何意见。蒂亚!

2个回答

将完整路由推入负载均衡器与您所能获得的最佳实践相差甚远。给它一个到实际路由器的默认路由和一个返回你子网的静态路由,它应该能够做你想做的任何事情。这也让您可以自由地使用该实际路由器来终止多个连接以获得多样性/最佳路径选项,而不必现在担心包含数百万个 RIB负载均衡器中的路由。如果你真的想扩展典型的设计,实际上会有一对路由器充当负载平衡器的出站网关,然后,一系列的边界路由器终止多个 ISP 连接。在专门为此设计的平台/操作系统上管理繁重的 BGP 工作,您不会陷入困境,试图诊断应用程序缓慢是服务器、负载平衡器、搅动路由表的功能还是只是怪异在仅被勉强支持的路由协议实现中。

如果设计得当(阅读:在模块化的基础上),这也会让您处于水平扩展负载均衡器成为可能真正达到高速、改进故障转移等的位置。它还开辟了一系列可能性可扩展的跨站点多租户(这与您关于 MPLS 功能的观点有关 - 同样,绝对不是一组可以从开源中删除的功能)以及为各种覆盖网络拓扑开辟了可能性(阅读:SDN ,等)。

我很确定如果你问 F5 人员他们是否建议携带完整的视图,他们会倾向于阻止它。它们是负载平衡、L4-L7 安全等应用级功能的绝佳设备。这是一个与可扩展 L2/L3 非常非常不同的问题。在许多方面,这类似于询问我可以在 Cisco 交换机 (ITD) 上的硬件中运行的超级基本负载平衡器是否是 F5 前端复杂网站的恰当替代品(阅读:)。它可以处理一些功能吗?当然。它是否旨在运行您实际需要大规模运行的所有花哨功能?绝对不。同样的原理适用于使用 LB/ADC 作为核心路由器。

还没有足够的点数来同意 mxrx 的评论,或者投票给他的答案,所以我会同意回答。

BIG-IP 可以很好地进行路由,是的,但支持应用程序交付。但是,如果您遵循“适合工作的正确工具”的原则,尽管我希望我们的销售人员为此向您出售 Viprion,但这样做对您不利。对于安全性和应用程序交付,硬件和软件是从头开始设计的。路由不是这种情况,而是包含在包装中以扩展 BIG-IP 核心功能的第 3 方许可。