当前设计
当前设计试图实现每个提供商的对称性。在稳定状态下，预期的路由逻辑是去往/来自子网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的前面并进行通信。
我认为该设计还有很多改进的余地。缺乏Internet拓扑意识以及电路亲和力完全消除了最佳路径选择。人们对提供商的级别指定表示担忧，并且该设计已被合理化为提供“可接受的性能”并且更易于排除故障。确实，设计不可能再简单了。我已经证明，过渡额外的AS会给RTT增加6跳和63ms（+ 421％）。我宁愿不接受可接受的解决方案。
更好的设计
更好的设计为路由器提供了尽可能多的Internet拓扑意识。剩下的最佳路径算法是确定入站和出站路由逻辑。电路将在故障状态下互相备份。
提供者公布完整视图。路由器运行iBGP和OSPF。消除了HSRP。出站路由将纯粹是基于目标的最佳路径，而入站路由将留给最佳路径算法和中转服务提供商的心血来潮。至少，用更少的词来解释。人们担心不对称性，但是我在当前设计中已经看到很多不对称性。我认为他们可能同样容易出现不对称现象，这真的让我不担心。结果，我们从未见过问题。目前，它已经降级到ifs的境界，“如果要解决某些'if'问题，我们该怎么办？”
我离开这里了吗？别人如何解决这个问题？ Google会做什么？
#1 楼
是的，您确实触手可及。改进的设计中会出现不对称现象，但是不对称现象在Internet上已成事实，并且确实没有充分的理由期望对称布线往返的流量。射击，数据包路由的整个概念是，单独的数据包彼此独立地路由，并且可能采用不同的路径，即使数据包沿相同方向运行。它是其中的一项技术，当我决定为问题提供最佳解决方案时，我会停下来并退后一步，看看我是否真的了解问题的真正本质，甚至还可以找出要解决的业务问题。是。当我这样做时，我几乎总会发现有一种无需使用类似技术即可解决问题的方法。
在路由器中拥有完整的Internet路由将需要一些时间来适应，但是一旦您习惯了，确实很容易理解和排除故障。当然，不用担心不同协议的“活动部分”。
您不想在OSPF数据库中拥有完整的Internet路由，因此您希望通过OSPF将默认值发布到网络的内部（或者也许是静态默认值...就我个人而言，我更喜欢OSPF中的默认值）。这样会将流量移向使用BGP的Internet路由器，从而可以更充分地决策拥有完整的Internet路由。
这将使您接近“基于目标的最佳路径”。在某些情况下，流量还会执行您并不期望的事情，因此您需要熟悉BGP路由选择过程。
评论
谢谢，杰夫。我同意您对PBR的态度。我已经看到它以噩梦般的方式实现。我从网络中窃取了更多的PBR，这比我想记住的要多。我曾经管理过一个分层的环境，其中将PBR部署为虚拟路由机制，每个SVI（100个）具有唯一的路由映射。 PBR还包含允许/不设置条款，导致流程切换。在硬拷贝中，它就像60页的配置。不用说，我把破坏球带到了上面。将其替换为VRF。
–丹尼斯·奥尔瓦尼（Dennis Olvany）
13年5月9日，0：35
#2 楼
为已经给出的其他方案提供不同的方法，该方法可能会或可能不会优于现有的想法，但主要是要通过一些额外的想法；我想说，您可以采取两个简单的步骤改善当前状况的方法如下：
步骤1；
从两个提供商那里获取完整的BGP表-现在，您将拥有更多的最佳出站路由，因为通过具有最小AS路径到您的目的地的运输提供商进行路由。如您所说，您可以删除HSRP并简单地在OSPF中发布默认路由，并在两个边缘路由器之间运行iBGP。
步骤2;
设置AS准备和社区等在您的两个边缘路由器上，以根据需要精确地控制出站流量。因此，ISP B可能具有通往某些子网的更好的路由，但是您可以从ISP A购买更多的传输，而通过它们时则需要购买更多，依此类推。由于具有独立于PI的地址空间，因此您要通过两家提供商来宣布它们，或者两家提供商都同意为您宣布相同的IP地址空间，您现在可以从两台路由器向这两个ISP宣布两个前缀，而无需添加前缀或社区。以及入站路由（当然，除非您有一些CDR，否则您需要先熟悉或类似，在这种情况下，您可以根据需要进行调整）。
评论
谢谢，javano。我认为我们同意入站和出站路由策略是有害的。我完全想取消PBR，前置和社区！
–丹尼斯·奥尔瓦尼（Dennis Olvany）
13年5月9日，0：27
#3 楼
从简单开始，然后仅在需要时才添加复杂性。我会问是否甚至需要在您的Internet边缘路由器上运行OSPF。将PBR引导到路边，并且只能在您的内部网络上使用。如果路由器有内存，请采用完整的Internet路由，但要进行过滤！ gt / 24扔任何东西。如果计划将A和B的/ 24都与两个提供商一起使用，则可以通过在B的网络上添加A的/ 24来更好地影响入站流量，反之亦然。两个/ 24都必须做广告！请与您的ISP联系以了解他们的社区，以便为您设置前缀。
使用两个不同的HSRP组来处理来自防火墙的出站流量；您可以将ECLB设置为共享负载到两个路由器。等价负载均衡。
如果只使用一个同时向A和B宣传的/ 24，则可以简化所有操作。
以后，请研究更多的复杂性为更好地进行流量工程和保护：
熟悉A和B的社区，因为您可能更喜欢使用对等路由映射来设置localpref来确定使用A对B的路由。 br />
在两个路由器上都设置一条浮动静态默认路由，作为对其他所有路由的紧急备份，以防您的BGP崩溃。
ip route 0.0.0.0 0.0.0.0 a.b.c.d 254
研究更复杂的广告方式来控制入站策略，例如一半IP空间通过A，另一半通过B。对于给定的/ 24 ，您可以将/ 24宣传给A和B，但将其分成两个/ 25，然后将较低的/ 25宣传给A，将较高的/ 25宣传给B。并在BGP会话上进行软重置，因此，如果您完全重置（或清除）该会话，则不会在另一侧造成前缀衰减。政策变更需要重设。
#4 楼
因此，从本文中我了解到，您实际上并不需要根据AS路径来决定是否可以到达外部子网，并且双归到两个ISP的唯一目的是购买冗余以到达Internet。如果是这样，那么您实际上就不需要运行BGP。您可以只接受已经从两个服务提供商处接收到的相同默认路由。现在，对于网络的本地端，在面向LAN的接口上连接到ISP的路由器上运行单个ospf区域（此过程中不要包括ISP接口），具体取决于设计的简单程度您可以在不同区域中添加路由器并在网络边界处汇总子网，但是对于两个子网，我认为OSPF数据库的大小或LSA泛洪的数量不是一个大问题，因此可以将所有节点放在一个OSPF区域中并随着您的成长将其分为不同的区域。在连接到ISP的每个OSPF路由器上，使用“ default-information origin”语句将学习到的默认路由重新分配到OSPF中。
优势：
通过这种设计，当您扩展网络时，可以与服务提供商一起启用BGP，并且只接受默认路由而无需动手下游设备。在您确认从BGP收到默认路由之前，还不错。
每当需要将流量从ISP路由出去进行维护时，只需从该路由器上OSPF进程下面删除“默认信息来源”，然后继续进行维护即可。不需要什么了。
我同意前面的回答，即对称路由被高估了，我宁愿追求可扩展性和易于维护。
评论
如果我了解@ user161的计划，则目标是更智能的出站路径选择。您如何在基于OSPF的解决方案中实现这一目标？
– Paul Gear
13年5月8日在7:51
谢谢，温尼。出故障流量的故障转移不是问题，但是我不需要BGP对入站进行故障转移吗？如果这只是用户将PAT接入互联网，那可能是可行的，但这是一个Web托管环境。
–丹尼斯·奥尔瓦尼（Dennis Olvany）
13年5月9日，0：21
@ user161：绝对，如果我们需要对原始子网进行入站故障转移，那么您确实需要运行BGP。请与您的ISP一起检查它们是否支持BGP对等的ORF功能，以便您可以通过BGP在边界路由器上使用入站筛选器通过BGP通告本地起源的子网，以接受默认路由和/或从ISP路由器中选择的几个子网。如果ISP不支持ORF，那么没有比购买具有更多功能的路由器更好的选择了。
– Vinny
13年5月9日，1：14
#5 楼
如果完整的BGP表对您来说太多了，我认为您可以考虑只接收一部分。提供商A和提供商B可能各自发布一条默认路由及其本地AS路由。您将需要在内部运行iBGP。这样一来，对于直接连接到提供程序的任何内容，您将拥有最短的路由，而对于下游AS路由，则将采用其中的一条。评论
谢谢，凯利。更好的设计将运行iBGP。硬件更新正在推动体系结构审查，因此我不太担心路由器能够处理该体系结构。销售团队说，从IOS过渡到JUNOS是一个轻而易举的事。到目前为止，我不确定我是否同意。
–丹尼斯·奥尔瓦尼（Dennis Olvany）
13年9月9日，0：15
我不知道我会说这是步履蹒跚...学习艰巨，不仅是新语法，而且是语法新概念。我要说的是，我认为这是值得的。 JunOS会让您有些挠头，但是在某些时候，它将单击并开始变得有意义。当然，您仍然必须查找内容（知道某种语言的语法与了解词汇是不一样的），但是总的来说，这是有道理的。
–杰夫·麦克亚当斯
13年5月9日，0：50
评论
很大的细节和解释。欢迎！传统上，“我想对设计提出一些意见”问题并不是很好的SE问题...但是可以在meta
上进行讨论