DMVPN WAN 故障切换：路由策略还是关闭隧道？

双 WAN 的 DMVPN 中心可以用两种方式之一完成故障切换，差别比看上去更大。一种改变路由策略选择哪条下一跳，因此报文继续流动，只是出口变了。另一种把隧道管理性关闭，这会连同该接口上的所有服务一起停掉。两者都可能是对的，因为它们回答的是不同的问题。

先做决定，再写配置

有三个条件替你决定。隧道接口保持 up 是否还被别的东西依赖，比如第二个 DMVPN 配置档或读取其状态的监控？需要切换的流量是自带策略，还是依赖全局路由表？再者，运维人员需要的是一个毫不含糊的状态变化，还是安静地切换路径就够？回答完这三点，选择通常自然浮现。

如果关闭会连带停掉本来正常工作的服务，那么路由策略是更小的动作。如果要求是主 WAN 断开期间隧道根本不能存在，那么任何策略条目都表达不了这一点。

把答案写下来，因为配置是最容易的部分。

路由策略究竟改变了什么

在基于策略的路由中，被跟踪对象可以控制下一跳。路由映射条目会指定候选下一跳，以及使用它时必须处于 up 状态的被跟踪对象，而这个跟踪状态来自 IP SLA 探测。对象 down 之后，该条目不再匹配，报文会交给下一条条目或普通路由表处理。

最后一个细节常让人意外：停止选择下一跳的策略通常会放行正常路由，而不是阻断流量。如果你需要故障时的黑洞，就得自己写一条。

语法因平台和版本而异，所以要查你实际运行的版本对应的指南。

关闭隧道改变了什么

关闭接口会改变管理状态。依赖它的每条隧道、路由和会话都会同时 down，如果隧道正是必须消失的东西，这恰好是你要的效果。EEM 小程序也正是这样把 WAN 问题变成一场波及无关服务的故障。

如果走这条路，把小程序限制在一个接口和一个触发条件上，保存之前的管理状态，定义恢复动作，并确保反复抖动不会把它带进循环。

硬编码的恢复命令还可能覆盖别人执行的维护性关闭。

让探针走你以为的那条路

跟随当前最优路由的探针会和其他一切一起转到备用 WAN，然后报告主链路健康，因为它已经不再使用主链路了。

把探针固定在你所测试路径的接口或源地址上。还要检查它探测的目标，因为能到运营商的下一跳，远不如能到隧道真正支撑的那个服务。要有意识地设置 up 和 down 延迟：短的 down 延迟反应快但会抖动，长的能扛住短暂波动却会掩盖真实故障。Cisco 的IOS XE 跟踪与策略路由指南记录了受支持的组合，而你平台上的功能集决定你能用其中哪些。

把两个延迟值都记在被跟踪对象旁边，否则没人知道它为什么那样表现。

先决定恢复，再验证

恢复值得单独做决定。频繁越过阈值的链路，可能比明确失效的链路更频繁地迁移会话，而每次迁移都要付出重新协商密钥和应用重试的代价。选一个稳定性要求，让延迟去表达它。然后在变更窗口里、让探针路径可见的情况下验证：选中的路由、外层对等路径，以及应用实际做了什么。

如果故障切换生效但应用仍然中断，问题在路由层之上，再多跟踪也修不好。

保留那次窗口里的证据，因为下一次变更会拿它作对比。