为什么你的 VPN 备份不是 EIGRP 的可行后继

第二条隧道建立起来，路由表仍然只显示一条路径，显而易见的结论是协议没有注意到。通常它注意到了并拒绝了。EIGRP 只有在通过特定的无环测试时才安装备份，而隧道处于活动状态并不能说明邻居的报告距离是否通过该测试。这个区别就是全部答案，它是算术而不是计时器。

条件，准确表述

RFC 7868 将可行性条件定义为对邻居无环路径的充分检查：邻居到某个目的地的报告距离必须严格小于本地可行距离。严格。不是小于或等于。

正是这一个不等式使备选路径成为可行后继。这里的其他一切都是围绕它的记账。

两种用途不同的距离

报告距离是邻居为目的地通告的值。可行距离是自上次 ACTIVE–PASSIVE 转换以来已知最小总度量的记录，因此它可能不同于当前最佳路径的度量。把两者混为一谈会产生自信的错误结论。

在运行显示中，几个看起来像距离的列并排出现。请阅读你正在使用的那一列的表头，并记住邻居的完整计算路径度量与它报告给你的距离不是同一个量。

一个具体比较

举一个声明的例子，可行距离为 1000。报告 900 的邻居通过测试，可以成为可行后继。报告 1000 的邻居不通过，因为条件是严格不等式，相等还不够。

那些数字是算术，不是链路速度。不要把它们读成对某个特定路由器的预测，也不要当作推荐度量。

检测不等于资格

一种机制可以迅速发现对端已死，而 EIGRP 仍然没有合格替代。发现是一个阶段；协调的路由计算是另一个阶段，它只在不存在可行后继时才开始。不满足条件并不能证明备选路径存在物理环路。它意味着本地捷径测试没有建立保证，因此计算必须处理结果。

缩短存活计时器不能创造从未存在过的可达性，而更改已配置的带宽或延迟值也不是对容量的测量。

读取字段，然后测试应用

记录目的地、当前后继、候选邻居、其报告距离、可行距离以及结果路由状态。 show ip eigrp topology 10.10.10.0/24 能为单个前缀提供其中的大部分信息。然后把决策与实际承载下一跳的隧道路径联系起来，因为路由表和隧道表可能对正在使用哪个接口存在分歧。

在经批准的观察下，分别跟踪三件事：检测、路由选择以及应用自身的恢复。这个顺序告诉你缺失的部分是合格备份、下面的 VPN 路径，还是工作负载正在重新连接，而不是假设每次缓慢恢复都需要另一个计时器。

有用的习惯是在碰其他任何东西之前先检查不等式。它只需要一条命令，就能结束争论。