ASA VTI 上的 OSPF 与 EIGRP：你的版本支持哪一个
OSPFv2 与 EIGRP 只有从 9.19(1) 起才能跑在 ASA VTI 上，而且必须启用 multicast。先在你运行的版本上比较两者，再验证邻居。
大多数 OSPF 与 EIGRP 的争论都假定隧道已经能承载协议，而在 ASA 上，这个假定恰恰是最该先核查的部分。只有在镜像、VTI 类型和 multicast 路径都确认之后，比较才有意义。顺序弄反，你就会花一下午在一条永远不会形成邻接的隧道上调计时器。我每次做这类设计，都从版本说明和运行配置开始，而不是从协议偏好开始。
版本先于协议做出决定
Cisco 的 ASA 9.24 VTI 指南 是一个可用的文档基线：它描述了静态和动态 VTI，并列出了静态路由、BGP、OSPF 和 EIGRP。其功能历史把 VTI 上的 OSPFv2 和 EIGRP 支持定在 9.19(1)。任何更早的说法都是另一回事。
所以头两个问题枯燥却关键：
| Check | What decides it |
|---|---|
| Image and release | Whether the feature history lists OSPFv2 or EIGRP on VTI for the version you run |
| VTI type | Static or dynamic, and which routing context the platform permits |
| Multicast on the tunnel | Whether it is enabled, and whether the group limits are respected |
“ASA 不能用 VTI，或不能承载 IGP”的说法对某些旧镜像成立，并不是当前的受支持矩阵。同理，9.24 指南也不是让每台设备都升级的指令。它说明该版本支持什么，而你实际部署的版本必须自己给出答案。
unicast 能通，不代表 IGP 能建立
同一份指南指出，unicast 默认可以通过，而 VTI 上的 OSPFv2 或 EIGRP 必须启用 multicast，并对 multicast 组有文档化的限制。这一句话解释了我在这种设计里见到的大多数邻接失败。隧道里能通的 ping，或者绿色的 IPsec 状态，只证明了 unicast 路径。协议发现需要 multicast 路径，而两者是分开配置的。
在动 hello 或 hold 计时器之前，先检查隧道接口配置里有没有那项 multicast 设置。如果设置缺失，邻接不是慢，而是不可能。
在同一隧道上并排看 OSPF 和 EIGRP
在隧道本身上，两个协议看起来和其他地方一样。OSPF 需要 匹配的网络类型、区域、认证和邻居参数；EIGRP 需要自己的 AS 号以及相应的接口级设置。
陷阱在于从另一种隧道模型抄邻居语句。无 VTI 设计里关于静态邻居的建议，本意是绕开 multicast，它并不适用于应当原生承载该协议的 VTI。配置受支持的接口行为，然后让协议自己形成邻接。
接着按对你拓扑真正有区别的维度比较：与对端的互操作性、你能测试的收敛行为，以及团队里的运维知识。关于某个协议更快或更轻的历史轶事，并不是对你网络的测量。
邻居不等于已安装的路由
邻接建立之后，要把“产生”的和“接受”的分开看。看每一侧宣告哪些分支前缀、哪些被接收、哪些被选中、哪些真正进入路由表。导入、导出和重分发的范围应当是有意设计的，而不是把设备知道的一切统统通告出去。
show ospf neighbor 和 show eigrp neighbors 告诉你会话是活的。 show route 告诉你分支前缀是否到达，而这是两个不同的问题。
应用路径又是第三个问题。邻居关系分发的是可达性；它不授予穿过防火墙的许可，也不证明流量选择器和过滤规则一致。用经过批准的测试去验证被允许的流及其回程，而不是假定路由就代表策略。
完成的比较应当记录什么
写下隧道接口、支持它的版本、你验证过的控制交换，以及你划定的路由策略。再加上 multicast 设置，因为正是这个细节在悄悄决定其余部分是否成立。把这份记录放在已部署版本旁边，这样以后的功能变更可以在不重蹈已过期假设的前提下复核。
这四项里缺任何一项，你拥有的就是偏好而不是设计。先补上缺失的事实；协议选择是容易的部分。