两张加密映射，一条流量：后加入的条目不是备份

为同一对地址再加一条加密映射条目，把它指向另一个对等体，你就写好了一份故障转移方案。这就是那个迷思，它之所以存在，是因为它看起来和你配置过的其他任何有序列表一样。加密映射中的顺序决定哪条条目占用新流量，而不是对等体停止响应时哪条条目接管。那个列表里没有任何东西监视远端，所以第二条条目只是坐在那里，什么也没有占用。

迷思：顺序意味着回退

一个有序列表，两条条目共用一个定义，感觉就像主用和备用。这种相似在语法处就结束了。Cisco 的 ASA 文档把加密映射描述为匹配受保护流量的策略模型，并为它指定对等体安排，而匹配是针对最先占用流量的那条条目进行的。远端对等体是否可用并不属于这项评估。

你构建的是一条永远不会为该流量被查询的策略，外加变更记录里一句声称冗余的注释。

顺序占用流量，而且只有一次

每条条目持有一个访问控制列表或一个受保护流量定义，新的出站数据包按顺序与这些定义比较。定义匹配的第一条条目拥有该流量及其对等体。定义完全相同的第二条条目永远轮不到，因为第一条已经匹配了；定义更窄的第二条条目只服务于第一条没有占用的流量。

当你有意从宽泛策略中切出例外时，这种行为很有用，而作为故障转移机制它毫无用处。用 show crypto map 和 show crypto ipsec sa peer 检查实际发生了什么，然后沿着你认为它会走的路径跟踪一个合成数据包。跟踪会指出占用它的那条条目，而这是唯一重要的答案。

路由选择与策略归属是两回事

路由表回答数据包被转发到哪里。加密策略回答所选流量适用哪种保护、哪个对等体。在另一个对等体下复制同一对源和目的，改变的是第二个决定，第一个丝毫未动，所以回复可能仍走旧网关，而出站数据包却走新对等体。这种不对称造出一条报告已启动却什么也通不过的隧道。

也要让远端的合同保持对等： 可接受的身份、受保护的地址范围、相关前缀的返回路由以及服务许可。对方并不期待的出站替代选择不是替代路径，而是它的一半。

真正的替代路径需要什么

选择为这项任务设计的机制：受支持的对等体候选组、带浮动静态路由或动态路由邻居的已路由隧道，或者你的平台为该服务记录的任何冗余设计。然后写下哪个组件检测故障、哪个组件选择替代，因为这是两个不同的功能，往往也是两个不同的团队。

地址转换也能给站点第二个呈现地址，但它同时改变选择器、日志和基于源的访问规则。把它当作明确需求，而不是两条含糊条目的变通办法。

测试三种状态，而不是一种

只有当配置对正常运行、主用故障状态和回到主用都有站得住脚的答案时，它才算完成。测试全部三种，并记录每条策略条目和每个对等体各自服务了哪一种。在第一种状态后就停止的测试，只证明了设计在一切正常时可用，而那正是你不需要检查的状态。

还要把配置的重叠与密钥重生成期间新旧关联的合法共存区分开。多个活动 SA 是正常且临时的；两条条目争抢同一条流量则是永久且看不见的。