浮动路由这个东西，原理一句话能讲完：给备份路由配一个比主路由更大的管理距离，让它在路由表里“沉”下去，主路由一失效它就浮上来。但真到机房里配，坑远比这句话多——什么时候切、切得干不干净、切过去回不来怎么办、接口好好的业务其实已经断了怎么办，每一个都能让人半夜被电话叫起来。这篇就把浮动路由从思路到落地整个捋一遍，从管理距离为什么这么设计，到下一跳该写 IP 还是写出接口，再到只靠接口状态判断的致命缺陷和 NQA、BFD 联动的写法，配上一套可以直接照着抄的双出口备份配置和一份排障速查表，适合刚接触路由交换、正在做双线备份的新手，也适合已经配过但切换总是不干脆的老手对照着查漏。
1. 浮动路由到底在解决什么问题
1.1 从一次双出口切换说起
先说个我遇到过好几次的场景。某园区有两条出口链路，一条专线走核心业务，一条普通宽带做备用，两条都接到同一台出口路由器上。按最直白的思路，两条默认路由都配上，指向各自的下一跳，然后祈祷主链路别断。结果一上线就发现不对劲：内网访问外网的时候，一部分流量莫名其妙走了备用宽带，核心业务系统的访问时快时慢，用户投诉说系统“一阵一阵卡”。
原因很简单，两条默认路由的管理距离都是默认值 1，在路由表里就是等价路由，设备会做逐流或逐包的负载分担，一半流量被分到了那条本来只想让它待命的备用链路上。备用链路带宽小、时延高、质量不稳定，业务体感当然崩。
这时候需要的不是“两条都能走”，而是“一条正常走、另一条只在第一条挂了的时候才走”。这就是浮动路由要干的事。它的本质不是新增了一种路由协议，而是给静态路由加了一个“优先级数字”——管理距离（Administrative Distance，简称 AD），让备份路由在路由表竞争里天然处于劣势，平时根本不进路由表，主路由消失的瞬间它才补位。理解这一点很关键，后面所有的配置细节、切换行为、排障思路，都是从“AD 值大小决定谁进路由表”这一条推出来的。
很多新手会把它和“主备链路”这个概念混在一起，其实链路本身没有主备之分，是路由的主备决定了流量走哪条链路。链路一直是 up 的，只是没有路由指向它，所以流量过不去。这个认知差很重要，后面讲 BFD 联动的时候会再回到这里。
1.2 管理距离：浮动路由赖以实现的那把尺子
管理距离这个参数，说白了就是设备对“这条路由是谁告诉我的”这件事的信任程度打分，分值越小越可信，0 到 255，255 表示这条路由绝对不可信、永不采用。直连路由是设备自己感知到的，AD 为 0，最可信；静态路由是人手工敲进去的，AD 默认 1；各种动态路由协议各有各的默认值。
下面这张表是我自己整理常用的，配浮动路由的时候基本要背下来，因为浮动的 AD 值配多少，取决于你想让它排在谁后面。
| 路由来源 | 默认管理距离 | 说明 |
|---|---|---|
| 直连路由 | 0 | 接口 up 且配置了地址就自动产生 |
| 静态路由 | 1 | 手工配置，浮动路由就是把这个值改大 |
| EBGP | 20 | 外部边界网关协议 |
| 内部 EIGRP | 90 | 部分厂商私有协议 |
| OSPF | 110 | 开放最短路径优先 |
| IS-IS | 115 | 中间系统到中间系统 |
| RIP | 120 | 距离矢量老协议 |
| 外部 EIGRP | 170 | 重分发进来的路由 |
| IBGP | 200 | 内部边界网关协议 |
| 不可达 | 255 | 永不采用 |
有了这张表，浮动路由的设计逻辑就很清楚了。假设主路由是 OSPF 学来的，默认 AD 是 110，那备份的静态路由 AD 只要配到大于 110，比如 130，它就永远排在 OSPF 后面，OSPF 路由在的时候它不进表，OSPF 路由消失了它才顶上来。反过来，如果主路由本身就是静态路由（AD=1），那备份静态路由配个 60、70、80 都行，只要比 1 大，同时比你想让它压住的其它路由小。
注意：AD 值不是随便配个大数就完事。配得太大，万一中间插进来一个动态路由协议，浮动路由可能永远浮不上来；配得太小，又可能在主路由还活着的时候抢戏。这个值的选取，本质是在给整个网络的选路秩序排座次，得先想清楚这台设备上可能同时存在哪些路由来源。
我在实际项目里的习惯是：如果主路由是静态默认路由，浮动路由配 60 到 80 之间。为什么不配 2？因为 2 到 59 这一段留白，将来如果要做临时的手工覆盖路由、或者接入某个策略路由产生的临时路由，还有空间可以插，不用回头改。这种小习惯没什么技术含量，但能省掉后面很多返工。
1.3 浮动路由与负载分担、策略路由的边界在哪
这三个东西经常被混着问，我干脆一次说清楚。
负载分担要求多条路由的 AD 值相同、度量值也相同，设备认为是等价路径，于是把流量分摊到多条路上，提升总带宽和可靠性。它的前提是两条链路质量接近，都能扛业务。
策略路由（PBR）是按源地址、目的地址、端口号、协议类型这些五元组信息，强制把特定流量扔到指定出口，完全不看路由表怎么选。它的适用场景是“某些流量必须走某条线”，比如财务系统必须走专线、访客网络必须走宽带。
浮动路由是备份，平时不参与转发，只在主路由失效时接管。它不提升带宽，只提升可用性。
三者的选择用一句话概括：想两条一起用、带宽叠加，用负载分担；想按业务分流，用策略路由；想一条待命、故障切换，用浮动路由。
这里还有个容易忽略的点：浮动路由和负载分担是可以共存的，但得分层设计。比如主链路那边做了两条等价静态路由做负载分担，备份侧配一条 AD 更大的浮动路由，那么主侧两条同时失效时，浮动路由才接管。这个组合在实际组网里挺常见，尤其是核心设备有两条上行、再额外接一条备份链路的结构。
2. 配置前的关键决策：参数怎么定
2.1 下一跳写 IP 还是写出接口
这个问题我被问过不下几十次，答案取决于出接口的链路类型。
广播型网络（以太网），必须写下一跳 IP 地址。原因在于以太网是广播域，一条路由只指定出接口的话，设备会认为目的网段“直连”在这个接口上，转发时会对目的 IP 直接发 ARP 请求。如果目的地址不在这个广播域里，ARP 永远没人应答，缓存表建不起来，流量直接丢。更麻烦的是有些设备会开启代理 ARP 响应，导致路由表看起来正常但转发行为诡异，排障极其痛苦。
点对点网络（PPP、HDLC 封装的串口、部分隧道接口），可以只写出接口。因为点对点链路只有对端一个邻居，不存在“目的地址在不在这个广播域里”的疑问，从接口出去就必然到对端。
我个人的做法是：无论什么链路，优先写下一跳 IP。原因很实际，写出接口的配置在链路类型变化时会失效，比如串口改成了以太子接口，或者接入了二层传输设备，原来写出接口的静态路由会突然变得不可用，而且症状隐蔽——路由表里还显示着，但流量就是不通。写下一跳 IP 至少能通过 ping 下一跳来验证可达性。
还有一种写法是“出接口 + 下一跳 IP”都写，这种配置在以太网上会同时指定出接口和下一跳，转发行为最明确，缺点是一旦出接口变化就得改。我自己在核心出口设备上倾向用双写，因为出口接口很少变，确定性更重要；在接入侧用单写下一跳 IP，灵活一些。
2.2 浮动路由的 AD 值间隔留多少
前面提了留白的概念，这里展开讲讲怎么定这个数。
第一步，先盘清楚这台设备上现存的、未来可能出现的所有路由来源，查一下它们的 AD 默认值。这一步可以用命令直接看路由表里每条路由的来源和优先级，国产设备的display ip routing-table输出里有一列 Protocol，国际设备的show ip route每行开头有个字母代码，配合show ip protocols能确认。
第二步，主路由的 AD 记下来叫 A，浮动路由的 AD 记为 B，要求 B 大于 A。
第三步，在 A 和 B 之间，以及 B 之上，各留出一段空间。我的经验值是至少留 10 到 20 的间隔。比如主流做法是主静态路由 AD=1，浮动配 60；或者主 OSPF 的 110，浮动配 130 到 150。留出这 10 到 20，是为了将来插入中间层路由时有位置，不至于为了加一条路由把所有相关配置重排一遍。
顺便说个反直觉的点：浮动的 AD 值不是越大越好。有人图省事直接配 250，觉得反正只要比主路由大就行。问题在于，255 是不可达，250 离它太近了，某些设备在路由重分发或者路由汇总的时候，会对高 AD 值路由做特殊处理，甚至直接过滤掉。而且一旦将来引入一条 AD 为 200 的 IBGP 路由，250 的浮动路由就彻底没机会了。所以配 60 到 150 这个区间是最稳的。
2.3 双向备份与回程路由：最容易漏的一环
浮动路由的配置几乎总是成对出现的，但很多人只配了一半。
去程好理解，内网设备把包发到出口路由器，出口路由器按浮动路由选路出去。回程呢？如果对端设备不知道你的内网网段怎么走，回来的包就会丢在它对外的默认路由上，结果就是能出去、回不来，业务表现为“连接超时”或者“能 ping 通网关但打不开网页”。
解决办法是在对端也配一条指向你的静态路由，同样带浮动属性。举个例子，主链路的对端是运营商 A，备份对端是运营商 B，那么运营商 B 侧的设备上也得有一条指向你内网网段的路由，AD 值同样配大，让它平时待命。
如果对端设备你碰不到（比如运营商侧设备不归你管），那就得换思路，改用 NAT 让内网地址在出口就被转换掉，这样回程包的目的地址是转换后的公网地址，对端按默认路由就能回得来。这个方案在中小型网络里非常常见，也是我更推荐的做法，因为不需要协调第三方。
提示：判断回程问题有个很快的验证方法，在出口路由器上开启流日志或者抓包，看包出去之后有没有对端的回包。如果出去有、回来没有，八成是回程缺路由或者被上游过滤了，跟浮动路由本身的配置没关系。
3. 实操过程：一套可复现的双出口备份配置
3.1 拓扑与地址规划
为了讲得具体，我搭一个最常见的结构。内网侧一台终端网段，出口路由器 R1 接两个上游设备 ISP-A 和 ISP-B，R1 通过两个不同的物理接口分别连接，主链路走 A，备份链路走 B。
地址规划如下（用的是文档示例地址段和私网地址，照抄不会撞）：
| 设备 | 接口 | 地址 | 说明 |
|---|---|---|---|
| R1 | G0/0 | 10.10.1.1/24 | 内网侧网关 |
| R1 | G0/1 | 192.0.2.2/30 | 连接 ISP-A，主链路 |
| R1 | G0/2 | 198.51.100.2/30 | 连接 ISP-B，备份链路 |
| ISP-A | 对端接口 | 192.0.2.1/30 | 主链路上游网关 |
| ISP-B | 对端接口 | 198.51.100.1/30 | 备份链路上游网关 |
终端网段用 10.10.1.0/24，网关指到 R1 的 G0/0。上游两家各自提供一个对端地址作为默认路由的下一跳。
这个拓扑的关键特征是：两条链路都是以太链路，所以下一跳必须写 IP；两条链路物理上同时 up，但业务上只有一条在转发，另一条处于“链路通、路由不通”的待命状态。这正是浮动路由最典型的应用场景。
3.2 主链路与浮动路由的完整配置
先配接口地址，这部分跳过细节，直接给关键配置。
国产主流厂商（VRP 风格）的配置如下：
# 主默认路由，AD 默认 1 ip route-static 0.0.0.0 0.0.0.0 192.0.2.1 # 备份默认路由，AD 提到 70，形成浮动 ip route-static 0.0.0.0 0.0.0.0 198.51.100.1 preference 70国际主流厂商（IOS 风格）的配置如下：
# 主默认路由，AD 默认 1 ip route 0.0.0.0 0.0.0.0 192.0.2.1 # 备份默认路由，末尾的 70 就是管理距离 ip route 0.0.0.0 0.0.0.0 198.51.100.1 70两段配置的差别就在关键字，一个用preference，一个直接把 AD 值写在末尾。语义完全一致，都是告诉设备“这条路由的可信度打 70 分”。
如果内网还有多个网段，需要把明细路由也配上浮动，写法是一样的，把目的网段和掩码换掉就行。比如：
ip route-static 10.20.0.0 255.255.0.0 198.51.100.1 preference 70这里有个取舍：用默认路由（0.0.0.0/0）做浮动，配置最简洁，但粒度粗，所有未知流量都走备份；用明细路由做浮动，粒度细，可以只让某些网段走备份，其它网段主链路断了也不切。后者在“备份链路带宽很小、只能承载关键业务”的场景里很有用。我一般建议关键业务网段单独配明细浮动路由，其它走默认浮动路由兜底。
3.3 验证：怎么确认浮动路由真的“浮”起来了
配置敲完，第一步不是看业务通不通，而是看路由表里到底有几条默认路由。
display ip routing-table 0.0.0.0正常情况下，主路由在表里，浮动路由不在表里。这一步很多人第一次配完会慌，因为看不到备份路由的条目，以为没配上。其实这正说明浮动生效了——它被主路由压住了。想看它是否真的存在，用查静态路由配置的命令：
display ip routing-table protocol static或者直接看配置display current-configuration | include ip route-static，两条都在就是配对了。
第二步做切换测试。千万不要直接拔网线，拔网线测的是链路故障，测不出业务的真实表现。正确做法是断开主链路的物理接口，或者更彻底一点，在主链路对端设备上关掉接口。
# 在 R1 上关闭主链路接口 interface GigabitEthernet0/1 shutdown然后立刻观察路由表变化和业务连通性。我的经验是，静态路由的切换几乎是瞬时的，接口一 down，路由表里的主路由立即被撤销，浮动路由同一时刻进表，这个过程通常在毫秒到秒级。但如果用的是 BFD 或者 NQA 联动，切换时间还取决于探测周期，后面会讲。
第三步，恢复主链路，确认浮动路由退场。这一步同样重要，有些场景会因为路由抖动或者定时器问题导致备份路由一直不退，形成“主备同时存在”的异常状态。恢复后应该看到主路由重新进表，浮动路由退出。
interface GigabitEthernet0/1 undo shutdown display ip routing-table 0.0.0.03.4 配置回退与收尾：别在故障现场改配置
这部分是我吃过亏之后形成的习惯，值得单独说。
在故障现场改配置是很容易出事的行为。想象一下，主链路断了，业务正在走备份链路，你急着“优化”一下浮动路由的 AD 值，结果改错了一行，备份链路也断了，整个网络彻底失联。更麻烦的是远程改配置改到自己连不上设备，只能派人去机房。
我的做法是三个“先”：先在本地把配置写好并验证语法，先在测试环境（哪怕是模拟器）跑一遍切换流程，先准备好一条“救命”的定时回退命令。国产设备上可以用定时任务在执行后若干秒自动回滚，国际设备上可以用reload in 5类似机制，原理都是“如果我没能确认，设备自动回到旧配置”。
还有个好习惯：所有浮动路由的配置都加上注释，注明这条路由是给哪条链路做备份、AD 值为什么选这个数。三个月后你或者你的同事再来看，能省掉大量推理时间。
# 备份链路：ISP-B，AD=70，主链路 ISP-A 断时启用 ip route-static 0.0.0.0 0.0.0.0 198.51.100.1 preference 704. 只靠接口状态判断的致命缺陷：NQA 与 BFD 联动
4.1 物理链路 up 不等于业务通
这是我见过最多“配置明明对、切换就是不生效”的问题根源。
静态浮动路由的失效判断依据是出接口的物理和协议状态。接口 down 了，路由撤销，浮动路由接管。但现实中大量故障是接口还亮着、协议还 up，业务却已经断了。典型情况有几种：光缆在中间某个接头盒被挖断，两端的设备因为光模块还有信号或者有保护倒换机制，接口依然保持 up；中间的传输设备故障，两端路由器直连接口感知不到；上游设备的三层转发挂了但二层接口还活着；甚至接口被人工 shut 在远端，对端看起来一切正常。
这些情况下，主路由在路由表里稳稳当当，浮动路由永远浮不上来，业务已经断了几个小时，而你的网络监控只报了“丢包率高”。这个问题用“调 AD 值”是解决不了的，必须引入外部探测机制。
解决思路是：让设备主动去探测主链路的真实可达性，探测失败就主动把主路由撤销或者把浮动路由提上来。主流实现有两种，一种基于 ICMP 的 NQA（网络质量分析），一种基于快速探测的 BFD（双向转发检测）。前者配置简单，探测周期可以做到秒级；后者配置稍复杂，但能压到毫秒级，适合对切换时间有硬要求的场景。
4.2 NQA 联动静态路由的完整写法
NQA 的思路很朴素：定期 ping 主链路对端的一个地址，连续几次不通就认为链路失效，然后触发动作把静态路由撤掉。
国产主流厂商的配置分三段，我把关键的都写出来：
# 第一段：定义 NQA 探测实例 nqa test-instance admin isp_a test-type icmp destination-address ipv4 192.0.2.1 frequency 5 timeout 2 probe-count 3 start now # 第二段：把主静态路由和 NQA 实例绑定 ip route-static 0.0.0.0 0.0.0.0 192.0.2.1 track nqa admin isp_a # 第三段：备份路由保持原样，AD 加大 ip route-static 0.0.0.0 0.0.0.0 198.51.100.1 preference 70参数解释一下，frequency 5表示每 5 秒发一次探测，timeout 2表示单次等待 2 秒，probe-count 3表示连续 3 次失败判定为不可达。加起来最坏情况的检测时间是 5×3 + 2×3，大概 20 秒出头，实际通常更快。这个时间量级对大多数业务是可接受的，如果需要更快就得换 BFD。
探测目标地址的选择很讲究。不能随便填一个公网地址，因为那个地址可能因为策略过滤、目标设备限速等原因不回包，导致误判。最稳的是选主链路对端设备的直连接口地址，这个地址一定存在、一定是直达的、不受路由策略影响。如果对端不让你 ping，那就只能退而求其次，选主链路内部的、稳定的、可控的一个地址。
还有一个细节：track绑定之后，NQA 判失败的时候，主路由会被从路由表里移除，而不是改优先级。移除之后浮动路由自然进表，这个逻辑是清晰的。但恢复的时候要等一下，NQA 探测成功之后主路由才回来，中间会有一段备份链路在转发的窗口期。如果备份链路带宽小，这段时间业务质量会下降，这是正常的，不用慌。
4.3 BFD 联动与两种方案的取舍
BFD 的原理是两个设备之间建立会话，周期性互发极短的控制报文，几十毫秒到几百毫秒的间隔，连续若干次收不到就判定会话 down，然后联动路由切换。
# 使能 BFD 并配置会话 bfd # interface GigabitEthernet0/1 bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier 3 # 静态路由联动 BFD 会话 ip route-static 0.0.0.0 0.0.0.0 192.0.2.1 track bfd-session isp_a这里的min-tx-interval 100是 100 毫秒发送一次，detect-multiplier 3表示 3 次收不到判定失效，理论检测时间 300 毫秒，实际因为抖动通常在两三百到五百毫秒之间。相比 NQA 的 20 秒，差了两个数量级。
两种方案的取舍我总结成这样：
| 对比项 | NQA（ICMP 探测） | BFD |
|---|---|---|
| 检测周期 | 秒级（通常 3 到 10 秒） | 毫秒级（通常 100 到 500 毫秒） |
| 切换时间 | 十几秒到几十秒 | 亚秒级 |
| 对端要求 | 需要能响应 ICMP | 需要两端都支持并配置 BFD |
| 配置复杂度 | 较低，单侧可配 | 较高，需要两侧协商 |
| 业务影响 | 切换期间有秒级中断 | 几乎无感 |
| 适用场景 | 一般业务、中小网络 | 语音、视频、金融交易等实时业务 |
注意：BFD 需要在两端设备上都配置会话，单侧配是建立不起来的。如果对端是运营商设备且不配合配 BFD，那就只能用 NQA。这个限制在实际项目里经常卡住方案，选型前必须先确认对端能否配合。
还有一个折中做法：NQA 和 BFD 同时用，但监控不同层级。BFD 监控直连的对端设备，NQA 监控更远一点的业务可达性。两个探测都正常才认为主链路可用。这种“双保险”配置复杂一些，但在核心出口设备上我觉得是值得的，因为直连对端活着不代表后面整条路径都通。
5. 常见问题与排查技巧实录
5.1 问题速查表
下面这张表是我这几年遇到过的、和浮动路由相关的问题汇总，按出现频率排序：
| 现象 | 最可能的原因 | 排查动作 |
|---|---|---|
| 配了浮动路由但备份链路一直没流量 | 主路由正常，浮动本就不该进表 | 查路由表确认只有主路由，属正常现象 |
| 两条默认路由都在表里，流量被分走 | 浮动路由 AD 值配成了 1 或与主路由相同 | 查静态路由配置里的 preference，确认大于主路由 |
| 主链路断了但业务没切过去 | 接口仍 up，静态路由不撤销 | 登录设备看接口状态，考虑加 NQA 或 BFD |
| 切过去了但业务不通 | 回程路由缺失或 NAT 未覆盖备份线路 | 在备份线路上抓包，看有无回程流量 |
| 主链路恢复了但还在走备份 | 浮动路由的 AD 被手动改小，或 NQA 未恢复 | 查路由表和 NQA 探测状态，确认主路由已回表 |
| 切换后时通时断 | 两条链路同时存在等价路由，来回路径不一致 | 查双向路由表，确认只有一条有效路径 |
| 内网某些网段切换后不通 | 只配了默认路由浮动，明细网段未配 | 补齐明细网段的浮动静态路由 |
| NQA 探测一直失败但链路实际正常 | 探测目标地址不可达或被限速 | 换成对端直连接口地址重新测试 |
5.2 几个我踩过的坑
坑一：AD 值改完忘了看路由表有没有刷新。有些设备改静态路由的 AD 值之后，路由表不会立即重算，需要等一段时间或者手动触发。我在某次演练里改完 AD 值测了十分钟都没切换，以为是配置写错了，翻来覆去查了半天，最后重启路由进程才发现是刷新问题。后来养成的习惯是：每次改完 AD 值，主动触发一次路由重算或者直接看配置生效状态，不要盲等。
坑二：用 ping 测试切换，结果测了个寂寞。用 ping 测业务连通性，因为 ICMP 报文很短、重传快，经常在主备切换的几百毫秒窗口里刚好有一次成功，看起来“没断”。但实际上 TCP 业务在这个窗口里连接已经断了，只是 ping 没表现出来。后来我改用持续性的 TCP 连接测试工具，或者直接跑业务流量，才能真实反映切换对业务的影响。
坑三：浮动路由配了，但备份链路的 NAT 没配。这个特别常见。主链路做了地址转换，备份链路只配了路由没配转换规则，切过去之后内网地址直接暴露在上游，上游不认这个地址段，包全被丢弃。表现就是“路由切过去了、接口有流量、但业务不通”。排障的时候一定要顺着“包出去之后有没有被转换”这条线查。
坑四：在主链路还正常的时候做切换演练，把生产网络搞挂了。演练这件事必须在业务低峰期做，且要提前确认两条链路都能独立承载全部业务。有一次演练，备份链路带宽只有主链路的十分之一，切换过去之后核心业务直接把备份链路打满，丢包率飙到 60%，比不切还惨。这个教训让我在方案设计阶段就坚持一条原则：备份链路的带宽至少能承载核心业务峰值，否则要配明细浮动路由，只让关键业务切。
5.3 排障命令组合拳
排障的时候我喜欢按固定顺序敲命令，形成肌肉记忆，能少走弯路。
第一步，看路由表全貌，确认当前有几条默认路由、各自来源、优先级。
display ip routing-table display ip routing-table protocol static第二步，看接口状态，确认是物理 down 还是协议 down 还是都 up。
display interface GigabitEthernet0/1 display interface brief第三步，看探测状态，如果配了 NQA 或 BFD，这里能直接看出探测是否正常。
display nqa results test-instance admin isp_a display bfd session all第四步，看转发路径，用 traceroute 确认实际走的哪条链路，这一步能识破“路由表看起来对、转发实际不对”的诡异情况。
tracert -a 10.10.1.1 8.8.8.8第五步，抓包。到这一步基本就是疑难杂症了，抓包能看清楚包到底从哪个接口出去、源地址是什么、有没有回程。
# 国产设备常用的抓包命令 capture-packet interface GigabitEthernet0/1 destination file test.pcap这五步走完，90% 的浮动路由问题都能定位。剩下 10% 往往不是路由本身的问题，而是上下游设备的策略、防火墙规则、或者运营商侧的过滤，这时候就得把排查范围往外扩了。
我个人在实际操作中的体会是，浮动路由的技术门槛不高，真正难的是把这些细节串成一套可重复的流程。每次上新链路，我都会按同一套清单走一遍：确认链路类型决定下一跳写法、确认 AD 值间隔、确认回程路由或 NAT、确认探测机制、演练一次切换、写注释。这套清单做完，后面几个月基本不会再因为这个链路被叫起来。备份链路的价值不在于它多先进，而在于它在你最需要的时候，真的一次就能顶上。
