将HSRP与ECMP一起使用以防止未知单播泛滥的最佳实践是什么？
详细信息/背景
我们的许多工厂都有类似于下图的HSRP拓扑。我们的Cisco WAN路由器具有到所有其他站点的等价路由；因此我们可以一直看到不对称的路由效应。通常，我们将R1分配为HSRP主节点，但是ECMP允许通过R1或R2返回流量。
问题在于，当PC1通过WAN装载远程iSCSI驱动器时，流量通过R1，但可以通过R2返回。只要iSCSI流量通过R1返回，就没有问题。
当PC1的流量通过R2返回时，就会出现此问题。假设iSCSI会话从8:00:00开始，并且两个路由器和两个交换机同时学习PC1的mac。在8:00:00到8:00:05之间，没有洪泛问题，因为两个交换机的CAM表中仍具有PC1的mac地址。
5在iSCSI会话开始后的几分钟，PC2的Mac的S2的CAM条目从CAM表中过期，并且S2的PC1的流量泛洪到所有端口（在本例中为Po1，Gi0 / 3和Gi0 / 4）。如果PC1的iSCSI会话占用大量带宽，则这种未知的单播洪泛会从到PC3和PC4的链接中吸收不小的容量。
S2# show mac address-table aging-time
Vlan Aging Time
---- ----------
1 300
17 300
但是，Cisco IOS的默认接口ARP计时器为4小时...
R2# show interface gi0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is AmdP2, address is 000a.dead.beef (bia 000a.dead.beef)
Internet address is 172.17.1.252/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00 <--------------
因此，S2将在五分钟后开始泛洪PC1的iSCSI流量。
#1 楼
简单的答案是使CAM计时器等于或稍长于相应的接口ARP计时器，但是至少有三个不同的选项可供选择...选项1：降低所有接口ARP计时器
如果您拥有一个像样的Layer2交换网络，合理数量的ARP条目和少量路由接口，则此选项最有效。如果您希望看到PC Mac条目快速从拓扑中淘汰，则此方法也是可取的。
在面向以太网交换机的所有IOS以太网接口上： >在所有面向以太网交换机的IOS以太网接口上：
arp timeout 240和hold-queue 200 in以避免在定期ARP刷新期间丢弃ARP数据包（这些限制可能更高或更低，具体取决于您认为需要立即处理的ARP刷新次数） ）。如果要调整“选择性数据包丢弃”值，则应遵循我链接的论文中的指导原则。这将迫使Cisco IOS在四分钟内刷新ARP表，如果未发生，则为给定的ARP条目。明显的缺点是，如果您有很多ARP条目，这种扩展就无法很好地进行...限制因平台而异。我已经在Catalyst 4500/6500（第3层SVI）上的每个路由器上使用了数百个ARP，而没有任何问题。
选项2：增加交换机CAM计时器如果您有大量的ARP条目（即成千上万个，例如在激烈的VMWare环境下可以看到），则该选项最有效。在所有IOS交换机上：
hold-queue 200 out或mac address-table aging-time 14400（对于任何Vlan） 此更改将调整大多数人认为固定为300秒的计时器（在Cisco IOS上），因此请确保在连续性文档中包括此计时器。这样做的副作用是，在删除PC后，CAM表条目会停留4个小时（取决于您的PoV，它可能是好是坏）。如果4小时太长，请参阅下一个选项...
选项3：更改接口ARP计时器和开关CAM计时器
此选项可避免在选项2中使用冗长的CAM计时器，但需要更多配置。您可以选择需要900秒，1800秒还是其他时间……只要确保您的CAM和ARP计时器匹配即可。因此，您将需要在拓扑中同时配置选项1和选项2。
评论
我们选择了第一个提出的解决方案对这个问题进行了排序，但是我们不确定IOS清理表的顺序，然后将ARP超时设置为293s（mac-address表timeout下方最接近的质数）。仍然不知道这是否是一个不错的选择
– Marco Marzetti
13年7月3日在12:09
从技术上讲，Cisco IOS每60秒触发一次ARP Walker，因此您应该使用240。。。
–迈克·彭宁顿
13年7月3日在12:36
确认小于或等于MAC超时的ARP超时应为BCP。甚至不需要HSRP，即使有两个路由器也可能会咬住您并造成环路。
–ytti
13年7月3日在12:39
不知道所以我们的把戏完全没用。我们选择了一个质数以最大程度地减少计时器的重叠时间。
– Marco Marzetti
13年7月3日在15:03
@MikePennington，谢谢。无论如何，您只需几分钟即可实现ARP超时解析
– Marco Marzetti
13年7月3日在15:44
#2 楼
对我而言，ECMP是这里的真正问题-因此，除了上述限制未知单播洪泛的步骤之外，您还可以调整指向WAN的路由指标，以便R1优先于R2优先处理返回流量。实现此目的的一种方法是通过R2上的分发列表，如下所示：（仅用于示例的EIGRP，使用OSPF或BGP以及其他命令也可以实现同样的目的） >
这将导致WAN将172.17.1.0的所有流量转发到R1。如果R1 Se1 / 0发生故障，则将路由安装到R2。您可以进一步调整这些指标，以便到R2的备份路由实际上是可行的后继者，以实现更快的故障转移。 HSRP和跟踪将照顾出口流量。
评论
本质上是您在回答您想要的问题，而不是我的问题...这需要fhrp和ecmp
–迈克·彭宁顿
13年7月3日在16:16
对不起，我已经习惯了这个论坛，错过了这个要求！
–smoothbSE
13年7月3日在16:53
没问题...欢迎来到NE :)
–迈克·彭宁顿
13年7月3日在17:04
#3 楼
对于PC，在一般情况下，来自WAN的入口流量（响应）高于出口流量（进入）的情况下，对于服务器来说，如果入口流量可能高于出口流量，则如果使用HSRP，则不使用ECMP的想法可能是可行的。我们喜欢大多数人只是设置ARP计时器。如果您说一个带有第3层交换机的MDF和一个带有2个采集交换机和5个访问交换机的IDF，则可以与CAM定时器一争高下，在L3 SVI上配置它比处理所有访问交换机要容易得多。#4 楼
可以使用一堆交换机来缓解此问题，即第二个交换机中的MAC地址条目即将过期。#5 楼
啊，我记得这个。几周前，解决这个问题已经花费了数周的时间。一种麻烦是STP事件会使VLAN处于快速老化模式，因此将MAC计时器设置为比ARP计时器更长的时间无济于事。通过创建两个浮动HSRP网关，每个路由器上有一个主网关。然后，我们在每个主机上配置了两个网关。通过以这种方式强制向R1和R2传输主机流量，我们可以确保R2永远不会老化MAC地址。与老化的MAC地址关联的ARP条目。然后，下一个发送到IP的数据包将导致一个新的ARP请求，同时填充ARP缓存和MAC表。我认为思科最终实现了这一目标，但我不能肯定地说。#6 楼
摘要：MC-LAG或HSRP GARP我从来都不喜欢调整计时器。通常出于许多原因，通常以某种方式设置计时器。更改它们：
在任何地方都可能需要维护大量的操作
，如最近的评论员所示，这会使事情变得更加复杂且难以排除故障
效果
可能无法与将来的思科增强功能“很好地发挥作用”。
在Cisco文档中）。这是您最好的选择，尽管您应该了解可以使用MC-LAG的部署方案（它不是通用解决方案，仅应在进行适当的研究和测试后才进行部署）。 MC-LAG变体取决于硬件。例如：
a。堆叠（Cat 3k）
b。 VSS（Cat4k / 6k）
c。 VPC（Nexus）
e。 MC-LAG（ASR9k）
f。群集（ASA）
使HSRP能够定期发送免费ARP数据包。当然，这类似于更改计时器，但是比操纵CAM表和ARP计时器要宽容得多。 （请注意，尽管这取决于您的硬件和软件组合，但并非所有HSRP实施方案都提供此功能。）
默认情况下，HSRP在路由器成为路由器的0、2和4秒后发送3个GARP。转发网关。但是，有一个配置参数可让您选择GARP的数量（包括“无限”）和间隔。
我广泛使用MC-LAG，尤其是VSS，VPC和群集（我不喜欢堆栈）。
在无法使用MC-LAG或GLBP的地方，这就是我适用于我的园区L2 / L3边界路由器（一个拥有350栋建筑的校园，所以我大量使用Cat6k）：信誉”以发布两个以上的网址。）
评论
您所说的MC-LAG当然是一种选择，但在经典IOS平台上的可用性却参差不齐。我也缺少HSRP免费ARP如何帮助解决此问题。使用我问题中的示例，您能否详细说明HSRP免费ARP如何解决172.17.1.1的ARP输入超时？请注意，默认GW为172.17.1.254
–迈克·彭宁顿
17年6月29日在10:15
好答案，所以让我分为两部分。第1部分... HSRP的问题是路由器使用虚拟MAC响应ARP查询。但是，当路由器将数据报转发到主机时，它将使用物理MAC地址。交换机可以相当快地清除其转发表（通常为300秒，即5分钟），但是ARP条目的停留时间通常要长得多（通常8小时）。
– Weylin Piegorsch
17-10-9在5:00
第2部分...交换机使转发表中的虚拟MAC地址超时后，从服务器到虚拟MAC的流量将变为“未知单播”，其中交换机默认为类似集线器的行为，并将流量泛洪端口。通过定期发送GARP，路由器将刷新交换机转发表。此外，通过发送GARP，服务器上的ARP表将被刷新，从而无需发送ARP查询。
– Weylin Piegorsch
17年10月9日，下午5:01
在我的两部分答案中，我刚意识到问题是从相反的方向提出的：服务器的MAC地址是从交换机而不是路由器的虚拟MAC刷新的。我们遇到了这个特定问题，最终通过MC-LAG（特别是VPC）解决了这个问题，后来由于我们已经在使用Nexus，我们改用FabricPath aka TRILL，这使问题消失了。但是，这两者都是与硬件和拓扑相关的。
– Weylin Piegorsch
17-10-9在5:14
我刚刚意识到我的原始评论是正确的-但可悲的是不完整。不仅是MC-LAG，还包括两层的MC-LAG。然后，您在交换机级别和路由器级别都处理一个共享CAM表。
– Weylin Piegorsch
19/12/16在19:08
#7 楼
我刚刚意识到我的原始评论是正确的-但可悲的是不完整。与供应商无关的设计建议是构建三角形，而不是矩形。因此：不仅是MC-LAG，而且还在两层。然后，您要在交换机级别和路由器级别都处理一个共享的CAM表。带有附加链接（即路由器和交换机之间的全网状）。 STP将确保无环路的拓扑。 STP将确保无环拓扑，并且交换机CAM表仍将知道所有适当的MAC转发规则。服务器将始终发送其MAC，并且如果您以1分钟的间隔配置HSRP GARP，则交换机也不会忘记HSRP vMAC。首选选项按该顺序排列。但至少要安装额外的一对链接。
评论
人们为什么总是不断发布问题，然后自己回答？不像是，搜索并找到答案，他们已经知道了吗？这是一个问答网站，而不是博客（不是您没有提供很好的文章！）@javano：SE明确鼓励自我回答。 refmeta.networkengineering.stackexchange.com/questions/4/…
@CraigConstantine是的，我知道，但是我敢肯定，人们会在发布问题然后回答海峡问题，而不是在一段时间后，当他们弄清楚问题的答案时（即使只是5分钟后），他们也会回答海峡问题。因为他们在发布问题之前已经知道答案了。我觉得这有点奇怪。
但是事实仍然存在，明确鼓励写Q和立即答案。
@javano，如果您解决了您认为其他人将要面对的问题，则SE希望搜索引擎的流量来解决该问题...他们不在乎我是否同时发布答案...实际上，问题网络表单的底部有一个小复选框，用于“回答您自己的问题–以问答形式分享您的知识”