企业官网建设流程全解析

IP 转发和路由选择是两件完全不同的事。很多人把网络层学完，能背出 IP 报文头每个字段的含义，能画 ARP 的交互时序，可一旦被问到“路由表里那条 10.20.0.0/16 的条目是谁放进去的、它凭什么相信这条路径比另一条更好”，回答就开始含糊了。这中间的空白，正是内部路由选择协议要填的坑。它解决的是自治系统内部成千上万台路由器如何自动、动态、可收敛地达成一张一致的拓扑视图——不是靠人手工写静态路由，而是靠协议之间互相“说话”。

这篇内容面向三类人：正在啃计算机网络教材但卡在协议细节的同学、准备网络方向面试或认证的从业者、以及手里有几台设备想搭个实验环境把 OSPF 和 RIP 真正跑一遍的运维。我会从“为什么需要它”讲到“两种技术路线的机制差异”，再落到“配置怎么下、邻居起不来怎么查、路由表空了怎么定位”，最后给一份选型判断的依据。全文尽量不写教科书式的定义堆砌，重点放在机制背后的动机和我实际排查问题时用到的那几条思路上，因为这些才是文档里通常不写、但现场最管用的东西。

1. 从“下一跳填什么”倒推：内部路由协议存在的理由

路由器收到一个包，拆开目的 IP，拿它去查转发表，命中前缀，取出下一跳和出接口，重新封装二层头再发出去。整条链路里，真正“动脑子”的只有查表那一步，其余都是机械动作。所以网络层的性能瓶颈和正确性风险，几乎全部集中在这张表上——表怎么来、准不准、变化多快能同步。

1.1 转发表、路由表、控制平面：三层职责别混着说

初学者最容易把“路由表”和“转发表”当成同一个东西。实际设备里它们通常是分开的：控制平面运行路由协议，收集信息，算出最优路径，把结果写进路由表（RIB）；然后路由表里优选出来的条目被下发到数据平面，形成转发表（FIB），FIB 才是每个包到达时被查询的那张表。FIB 的查找必须是硬件线速的，所以它结构简单、条目直接；RIB 则可以包含协议优先级、度量值、下一跳递归解析结果这些“决策过程”的信息。

这个分层解释了一个很常见的困惑：为什么邻居已经 Full，show ip route里却看不到路由？因为邻居关系只是控制平面“握手成功”，LSDB 同步完成之后还要经过 SPF 计算、路由优选、下发 FIB 三个阶段，任何一环出问题，路由都不会出现。反过来说，为什么有时候路由表里有条目但 ping 不通？那大概率是 FIB 下发正常但二层解析失败、或者反向路径没有回程路由，问题出在别处。分清楚这三层，排查时才能快速缩小范围。

静态路由当然也能填这张表，而且在小规模、拓扑固定的场景下它更可控——没有协议报文开销，没有收敛过程，也不会被别人的错误配置带偏。但静态路由的两个致命短板决定了它撑不起稍大的网络：一是无法感知拓扑变化，链路断了它不知道，只能靠浮动静态路由做有限备份；二是维护成本随节点数平方增长，N 台路由器两两互联，人工维护的条目量级会迅速失控。内部路由选择协议的核心价值，就是用自动化的信息交换替代人工计算。

1.2 自治系统边界：为什么内部和外部必须用两套协议

互联网的规模决定了不可能让所有路由器跑同一个协议、维护同一份拓扑。于是有了自治系统的划分：一个自治系统内部由单一管理机构控制，路由策略统一，可以使用任意内部协议；自治系统之间则通过外部网关协议交换可达性信息。这个划分不是为了好看，而是因为两类场景的优化目标根本不同。

内部协议追求的是最优路径和快速收敛，它假设所有路由器受同一套策略约束，可以放心地把完整拓扑或距离向量告诉邻居。外部协议追求的是策略控制与规模可扩展，它不关心对方内部怎么走，只关心“哪些前缀可达、经过哪些自治系统、我愿不愿意走这条路”。把这两个目标塞进一个协议里，结果就是两边都做不好。

这个边界对实际配置有直接影响：内部协议的重分发必须小心。把外部路由引入内部时，如果不做过滤和度量调整，很容易把几十万条前缀灌进内部路由器，直接把内存和 CPU 打满。我在实验环境里见过有人图省事，在边界设备上双向重分发且不加任何 route-map，结果两台设备之间形成了路由反馈环，CPU 瞬间跑满，控制平面直接失联，只能靠带外管理口进去断链恢复。这类问题的根源，就是把“内部协议假设全网策略一致”这个前提用错了地方。

1.3 距离向量与链路状态：两条路线，两种世界观

内部路由协议按信息传播方式分成两大流派，这个分野贯穿了整个网络层的学习。

这个表格背后的本质差异是信息视角：距离向量协议里的路由器像是一个只听过邻居口述的旅人，“往东走三天能到，邻居说的”，它不知道东边到底有几条路；链路状态协议里的路由器则拿到了一张完整地图，自己算最短路径。前者简单但容易被错误信息误导，后者复杂但决策依据充分。

理解这一点，后面所有的机制细节都能串起来：RIP 的水平分割、毒性逆转是在补“口述信息可能失真”的洞；OSPF 的区域划分、DR/BDR 选举是在控“地图太大、交换太吵”的成本。补丁和优化都是围绕各自的先天缺陷长出来的。

2. RIP：简单协议的简单陷阱

RIP 是最容易上手的内部路由协议，配置三五条命令就能跑起来，很多人因此觉得它“没啥可讲的”。恰恰相反，RIP 是理解距离向量思想最好的样本，它把这类协议的优点和缺陷都暴露得很彻底。

2.1 跳数度量与四个计时器：30 秒的代价

RIP 用跳数作为度量，直连网络为 0，每经过一台路由器加 1，最大值 15，16 被视为不可达。选跳数而不是带宽或延迟，理由是简单——不需要在报文里携带链路速率信息，也不需要在拓扑变化时重新计算。代价是它完全无视链路质量：一条经过两跳的千兆链路，在 RIP 眼里比一条经过一跳的 64K 链路还要差。在今天这个带宽差异巨大的环境里，这个度量基本没有工程意义。

计时器体系是 RIP 的第二个特点。默认更新周期 30 秒，意味着即使拓扑毫无变化，每台路由器也会周期性地把路由表广播出去；无效计时器 180 秒，也就是连续 6 个更新周期没收到某条路由的更新，就判定它失效；抑制计时器同样是 180 秒，用来在路由失效后的一段时间内不接受同一网络的替代信息，防止抖动；刷新计时器 240 秒，到时彻底从表中删除。

这套计时器组合的直接后果是收敛慢。一条链路断开，最快也要等 180 秒才会被判定失效，如果下游还有多台路由器，逐跳传播的时间还要叠加。对于今天要求秒级甚至亚秒级切换的业务，这个量级显然不能接受。所以 RIP 的适用场景非常明确：拓扑稳定、节点数少、对收敛时间不敏感的小型网络，或者作为教学和实验协议的入门练习。

2.2 计数到无穷：环路是怎么一步步长出来的

这是距离向量协议最经典的缺陷，值得把过程完整走一遍，因为后面 OSPF 的很多设计都是为了绕开它。

设想一条链 A—B—C—D，D 上挂着一个网络 10.1.0.0/24。正常情况下，A 看到 10.1.0.0 的度量是 3（经过 B、C、D）。现在 D 到 10.1.0.0 的链路断了，D 把这条路由的度量改成 16。但在 D 把这个消息传出去之前，B 的周期性更新先到了——B 说“我到 10.1.0.0 的距离是 2”。D 一听，邻居说 2，那我通过 B 走过去就是 3，于是 D 把路由改成“经 B，度量 3”，并把这条信息发出去。C 收到后算出来是 4，发回给 B；B 算出来是 5，再发回给 D……度量在 D、C、B 之间来回加 1，直到全部撞到 16 才算终止。

整个过程没有任何一台路由器“撒谎”，每一台都是根据邻居给的信息做局部最优决策，但全局结果是错的。这就是分布式算法的固有问题：局部最优不保证全局一致。如果链路上还有别的路由竞争，环路期间数据包会在几台路由器之间来回打转，TTL 耗尽后被丢弃，表现为一段时间内到该网络的访问完全中断。

2.3 三个补丁：水平分割、毒性逆转、触发更新

针对环路，RIP 打了几个补丁，每个补丁都解决一部分问题，但都不能根治。

水平分割的规则是：从某个接口学到的路由，不再从同一个接口通告回去。上面那个例子里，D 到 10.1.0.0 的路由本来就不是从 B 学来的，所以水平分割救不了这个场景；但如果反过来是 B 从 D 学到的这条路由，水平分割就能阻止 B 把它再告诉 D，避免 D 产生“我可以从 B 绕回去”的错觉。这个补丁对两节点互指的场景有效，对环形拓扑效果有限。

毒性逆转比水平分割更狠一点：从某接口学到的路由，要从同一接口通告回去，但度量设为 16，明确告诉对方“这条路从我这儿走不通”。它比水平分割多打了报文，但抑制环路的时效性更好。实践中毒性逆转和水平分割通常不会同时开，因为毒性逆转本身已经隐含了水平分割的效果，同时开会造成不必要的报文开销。

触发更新解决的是“等 30 秒太慢”的问题：拓扑一变就立刻发更新，不等周期。这确实能大幅缩短收敛时间，但引入了新风险——如果链路反复抖动，每次抖动都触发一轮全网更新，报文量会瞬间暴涨，反而把网络打瘫。所以触发更新通常要配合抑制计时器，在变化后的一段时间内不响应同类事件，把抖动吸收掉。

这三个补丁合起来的实际效果是：中小规模的链式或树状拓扑基本不会出环路，复杂环形拓扑仍有残留风险。这也是为什么后来的链路状态协议要从根本上换思路，而不是继续在距离向量上打补丁。

2.4 RIPv2 的三个改进与一份可跑的配置

RIPv1 是有类协议，通告路由时不带子网掩码，因此不支持 VLSM，也不支持认证，更新用广播发送。RIPv2 在这三点上都做了改进：携带子网掩码实现无类路由、支持明文和 MD5 认证、改用组播 224.0.0.9 发送以减少无关主机的处理开销。另外 v2 还支持下一跳字段和路由标记，便于和外部协议衔接。

一段典型配置如下，语法用通用示意，不同厂商设备的命令风格有差异，思路是一致的：

router rip version 2 no auto-summary network 10.10.0.0 network 192.168.50.0 passive-interface GigabitEthernet0/1

几个参数值得解释。no auto-summary在主类网络边界不连续的场景下必须关掉，否则 10.10.1.0/24 和 10.10.2.0/24 会被自动汇总成 10.0.0.0/8 发出去，对端收到的路由和实际拓扑对不上，回程流量就会走错方向。passive-interface用在连接终端的接口上，让这个接口不发送更新，但该网段仍然会被通告出去——这是一个很实用的细节，很多人忘了配，结果更新报文一直往接入终端的口上发，既浪费带宽又是不必要的暴露面。

注意：RIP 的 network 命令和 OSPF 的 network 命令语义完全不同。RIP 里它是“在匹配这个网段的接口上启用协议并通告该网段”，OSPF 里它是“把匹配这个网段的接口纳入某个区域”。配置时混用两套心智模型，是新手最常见的错误来源之一。

实测下来，RIP 在十台以内路由器、拓扑基本不变的实验环境里非常稳，配置量小、排错直观，抓包看报文一目了然。但一旦超过这个规模，或者链路上有频繁变化的备份路径，它的收敛速度和环路风险就会变成实实在在的运维负担。

3. OSPF：把拓扑拼成一张图再自己算

OSPF 的设计思路和 RIP 完全相反：不传递“到某地多远”，而是传递“我身边有哪些链路、它们通向谁”。每台路由器收集齐整个区域内的链路状态通告，在本地构建一个带权有向图，然后跑 Dijkstra 算法算出以自己为根的最短路径树。这个思路的好处是每台路由器都有完整信息，决策依据充分，收敛也更快。

3.1 五种报文与邻居状态机：握手过程到底在交换什么

OSPF 用五种报文完成从“发现邻居”到“数据库同步”的全过程，每种报文对应状态机上的一个阶段，理解这个映射关系，排错时就能直接从状态判断卡在哪一步。

Hello 报文里携带的参数必须双向匹配才能建立邻居：区域 ID、Hello/Dead 间隔、认证类型与密钥、区域类型（普通/末梢/NSSA）、MTU（部分实现会在 DBD 阶段校验）。任何一项不匹配，邻居就停在 Init 状态——意思是“我收到了你的 Hello，但你的 Hello 里没有我的 Router ID”，通常就是单向通信或者参数不一致。

这里有个容易踩的细节：2-Way 状态在广播网络上不一定是故障。两台都是 DROther 的路由器之间本来就不会建立 Full 邻接，它们只需要保持 2-Way 即可，因为它们的 LSA 是通过 DR 中转的。看到 2-Way 就慌着去查配置，是新手常见的误判。真正需要关注的是本该 Full 的邻居卡在 2-Way，那才说明 DR/BDR 选举或者网络类型有问题。

3.2 DR/BDR 选举：广播网络里的发言人去中心化

在一个有多台路由器的广播网段（比如一台交换机上挂五台路由器）上，如果两两建立 Full 邻接，邻接关系数是 n(n-1)/2，五台就是十条，每台都要向其余四台泛洪 LSA，报文量随规模平方增长。OSPF 的解法是在网段上选出一个指定路由器（DR）和一个备份指定路由器（BDR），所有 DROther 只和 DR、BDR 建立 Full，LSA 先发给 DR，由 DR 统一向网段外泛洪。这样邻接关系降到 2(n-2)+1，报文量线性化。

选举规则分两步：先比接口优先级，默认值是 1，范围 0 到 255，配成 0 表示不参与选举；优先级相同时比 Router ID，数值大的胜出。BDR 就是得票第二的那台。这里有个非常有迷惑性的行为：选举不抢占。一台路由器启动时如果发现已经有 DR 和 BDR，它就老老实实当 DROther，即使它的优先级更高也不会把现任 DR 挤下去。只有 DR 失效，BDR 才会接替，然后重新选一个 BDR。

这个“不抢占”特性在实际运维里是双刃剑。好处是稳定，不会因为一台设备重启就引发全网重新选举；坏处是如果你后来把一台性能更强的设备接进来，希望它当 DR，光改优先级没用，必须把原来的 DR 重启或者把接口临时 shutdown 再 no shutdown，才能触发重新选举。我在实验环境里为了验证这个行为，专门把三台设备的优先级改成 200/100/1，然后依次重启，观察 DR 的接替顺序，确认了“BDR 平滑接替、DROther 重新竞选”的完整过程。

手工指定 DR 优先级是个值得养成的习惯。生产环境里如果不指定，DR 很可能落在一台性能一般或者位置不佳的设备上，等出了问题再调整就要中断业务。配置方式很简单，在接口下设置优先级，配合清晰的规划文档，能省掉很多麻烦。

3.3 SPF 计算与度量：为什么参考带宽必须改

OSPF 的接口度量叫开销（cost），计算公式是参考带宽 ÷ 接口带宽，默认参考带宽 100 Mbps。这个默认值是上世纪的经验，在今天完全不够用：百兆接口开销是 1，千兆接口开销也是 1，万兆接口还是 1。也就是说，从百兆升级到万兆，在 OSPF 眼里路径没有任何变化，选路依然按老样子走，这显然是荒谬的。

解决办法是调整参考带宽，把它设成当前网络中的最高带宽量级，比如 10000 Mbps，这样百兆是 100、千兆是 10、万兆是 1，层次就出来了。注意这个值必须在区域内所有路由器上保持一致，否则不同设备算出的路径开销不可比，会出现次优路由甚至环路。修改时要全网统一操作，不能只改一台。

router ospf 1 router-id 10.0.0.1 auto-cost reference-bandwidth 10000 network 10.10.1.0 0.0.0.255 area 0 network 10.10.2.0 0.0.0.255 area 0

Router ID 的选择也值得说一句。它优先取手工配置的值，没配就取所有 Loopback 接口里最大的 IP，再没有就取所有物理接口里最大的 IP。靠自动选举是有风险的：一台设备的某个接口 IP 变了，Router ID 可能跟着变，邻居关系全部重建。所以规范做法是显式配置 Loopback 接口并手工指定 Router ID，让它不依赖任何物理接口的状态。

3.4 区域划分与 LSA 类型：规模化的必要之恶

单区域 OSPF 的问题是 LSDB 太大、SPF 计算太频繁。每台路由器都要维护全网的链路状态，任何一条链路抖动都会触发所有路由器重算。区域划分就是把这个大图切成若干小块，区域内的路由器只维护本区域的完整拓扑，区域间的路由通过 ABR（区域边界路由器）用汇总 LSA 传递。

骨干区域（Area 0）是所有区域的中心，非骨干区域必须直接或通过虚链路连接到它。这个星型结构是为了防止区域间的路由环路——所有区域间流量都必须经过骨干区域中转，路径唯一，环路无从产生。代价是如果骨干区域被切分，网络就分裂了。

LSA 类型是理解 OSPF 区域机制的钥匙，六种常见类型各有明确分工：

这里最值得留意的是 Type 3 和 Type 5 的区别：Type 3 描述的是“到我这个区域的某个前缀怎么走”，由 ABR 汇总产生，让其他区域的路由器不必知道本区域内部的具体拓扑；Type 5 描述的是“AS 外的某个前缀”，由 ASBR 产生，全网泛洪。如果一个区域被配置成完全末梢区域（Totally Stubby），它会连 Type 3 的明细都不接收，只靠一条默认路由出网——这是大规模网络里减少 LSDB 体积的常用手段。

3.5 网络类型与邻居建立：那几种“看起来一样”的坑

OSPF 定义了五种网络类型：广播、非广播多路访问（NBMA）、点到点、点到多点、虚链路。类型决定了是否选举 DR/BDR、Hello 间隔是多少、报文用组播还是单播发送。默认情况下，以太网接口被识别为广播类型，串行接口被识别为点到点（部分实现里是 NBMA）。

问题出在两端网络类型不一致的时候。一边是广播类型，会选举 DR 并等待 DBD 里的 DR 字段；另一边是点到点类型，压根不选 DR。两边对 Hello 报文的期待不同，邻居会卡在 ExStart 状态，反复重传 DBD 却永远无法推进。这个现象非常迷惑，因为 Hello 阶段是通的，说明底层连通性和认证都没问题，只有把两端的网络类型改成一致才能解决。

另一个坑是 Hello 和 Dead 间隔。广播网络默认 10 秒和 40 秒，NBMA 和点到多点默认 30 秒和 120 秒。这两个值必须在邻居之间严格匹配，差一秒都建不起来。有人为了加快收敛把 Hello 改成 1 秒，只改了一端，结果邻居直接不通，还以为是链路问题查了半天。Dead 间隔通常是 Hello 的 4 倍，这个比例不要随意打破。

4. 排错链路：邻居起不来和路由不通的完整排查顺序

协议机制讲得再清楚，真正让人头大的还是现场排错。我总结了一条从下往上、逐步收窄的排查路径，基本能覆盖八成以上的 OSPF 故障。

4.1 卡在 INIT 或 2-WAY：从参数匹配查起

邻居状态停在 INIT，含义是“我收到了你的 Hello，但你的 Hello 里没有我的 Router ID”。这通常指向三种情况：一是单向通信，我发给你的报文你能收到，你发给我我收不到；二是 Hello 参数不匹配，对方根本没把我的 Hello 当成有效邻居；三是认证失败，报文被丢弃但没有明确提示。

排查顺序应该是：先看接口状态和二层连通性，确认双向可达；再看两端的区域 ID、Hello/Dead 间隔、认证配置是否逐项一致；最后看是否有 ACL 或者防火墙规则把 OSPF 的协议报文（IP 协议号 89）给拦了。组播地址 224.0.0.5 和 224.0.0.6 也需要放行，如果中间有设备做组播抑制，邻居同样起不来。

卡在 2-WAY 则要分情况。前面说过，DROther 之间停在 2-WAY 是正常的。但如果两台设备中至少有一台应该是 DR 或 BDR，却停在 2-WAY，那就要查优先级配置和网络类型了。还有一种少见情况：两台设备的 Router ID 冲突。Router ID 相同会被视为同一台路由器，邻居关系无法正常建立，状态会反复跳变。这种情况在批量配置、复制粘贴模板的时候特别容易发生。

4.2 卡在 EXSTART 或 EXCHANGE：MTU 与网络类型是重点嫌疑

EXSTART 阶段的核心动作是协商主从关系，靠的是 DBD 报文里的 Router ID 和接口 MTU。如果两端 MTU 不一致，一方发出的 DBD 超过对方接口能接收的长度，报文被丢弃，状态就永远停在 EXSTART，表现为双方反复发送 DBD、序列号却推不动。

这个坑最阴险的地方在于，ping 是通的，甚至小包业务也能跑，因为 MTU 不匹配只影响超长报文。排查方法很直接：对比两端接口的 MTU 配置。以太网默认 1500，如果一端配了 9000 做巨型帧，另一端还是 1500，OSPF 邻居大概率起不来。解决办法要么统一 MTU，要么在接口下配置忽略 MTU 校验（这只是绕过校验，实际转发仍有问题，只适合临时排障）。

网络类型不一致也会卡在 EXSTART，原因前面讲过。判断依据是看两端的show ip ospf interface输出里的网络类型字段，不一致就改成一致。

4.3 邻居 FULL 但路由表空：掩码、被动接口与区域边界

这是最让人焦虑的一类问题：一切看起来都正常，邻居 Full，LSDB 也有条目，可路由表里就是没有目标前缀。

第一嫌疑是掩码不匹配。OSPF 要求同网段的两端接口掩码一致，否则虽然邻居可能建立（取决于实现版本），但 SPF 计算时会认为这是两个不同的网段，路由不会生成。这个错误在配置时特别容易犯，因为配 IP 时手滑把/24敲成/25，设备不会报错，只是协议层默默不干活。

第二嫌疑是网络类型为被动（passive）或者接口没被 network 命令覆盖到。检查方法是看show ip ospf interface brief，确认目标接口在列表里且状态正常。如果接口没在列表里，说明 network 命令的网段匹配写错了，或者被更精确的匹配规则覆盖了。

第三嫌疑是区域边界的问题。如果目标前缀在另一个区域，需要 ABR 正确地产生 Type 3 LSA。如果 ABR 上没有配置区域间路由的通告，或者配置了过滤规则把这个前缀挡掉了，那么本区域的路由器就看不到它。这时候要去看 ABR 的 LSDB 里有没有对应的 Type 3 条目。

4.4 路径不对：度量计算与路由优选的隐性规则

路由是通的，但走了一条明显绕远的路，这种问题比不通更难查，因为没有任何报错。

先算开销。如果参考带宽没有调整，千兆和万兆接口的开销都是 1，OSPF 会认为两条路等价，然后做等价多路径负载均衡——这在带宽不对称的网络里会导致一部分流量走了慢链路。调整参考带宽是根本解法。

再看路由优选顺序。OSPF 内部路由优先于区域间路由，区域间路由优先于外部路由（Type 5），这个顺序是固定的。如果你的流量本该走一条直连的外部路径，却发现走了绕远的内部路径，那不是度量算错了，而是协议优先级决定的。这时候需要用 route-map 调整外部路由的初始度量，或者用更精细的路径控制手段。

还有一个容易被忽视的点：接口开销的手工覆盖。某些场景下自动计算出的开销不符合业务意图，比如一条链路带宽很高但延迟很大，不适合承载实时流量。这时候可以在接口下手动设置 cost 值，把流量引导到另一条路径。这个操作很有效，但也容易留下隐患——如果文档没记录，半年后接手的人看到一条“莫名其妙”的路径，很难想到是有人手工改过开销。

5. 选型判断：什么时候 RIP 够用，什么时候必须上 OSPF

协议没有优劣，只有匹配与否。我把实际的判断依据整理成几个维度，供参考。

5.1 规模、收敛与可维护性的三角权衡

节点数是最直观的指标。十台以内、拓扑以星型或链型为主、没有复杂的冗余路径，RIP 完全够用，配置量小到可以手写，出了问题抓包一眼就能看懂。超过二十台、存在多路径冗余、需要快速切换，就得考虑 OSPF 了。这个分界线不是绝对的，但大致反映了两种协议的能力边界。

收敛时间的要求更关键。如果业务能容忍几十秒的中断，RIP 的 180 秒失效判定虽然慢，但可以接受；如果要求秒级切换，RIP 根本做不到，必须上链路状态协议。这里要提醒一句：OSPF 的“快速收敛”也不是免费的，默认的 SPF 计算有 5 秒的初始延迟和递增的抑制间隔，要真正做到亚秒级切换，还需要配置快速 Hello、SPF 调度优化、甚至 BFD 联动，这些都是额外的工作量。

可维护性方面，RIP 的优势在于简单，任何人接手都能看懂；OSPF 的优势在于结构清晰，区域划分、LSA 类型、Router ID 规划这些“规矩”一旦建立，长期维护反而更可控。一个没有规划、乱配一气的 OSPF 网络，维护难度可能比 RIP 还高。

5.2 边界衔接：重分发时最容易出事的地方

内部协议跑起来只是第一步，真正复杂的往往是和外部协议的衔接。重分发的基本原则是：永远不要无条件双向重分发。必须明确哪些路由允许进入、进入时度量设成多少、是否需要打标记以便后续过滤。

度量衔接是个技术细节。RIP 的跳数和 OSPF 的开销没有可比性，重分发时必须指定一个种子度量。比如把 OSPF 路由引入 RIP 时，如果不指定，默认跳数是 1 还是 16 取决于实现，设成 16 就等于告诉对方“这条路不可达”，路由直接丢失。反过来把 RIP 引入 OSPF，如果不指定开销，默认值可能让这些外部路由在选路时处于明显劣势或优势，都不是想要的结果。

还有一类问题来自路由反馈。A 把 OSPF 路由重分发进 RIP，B 又把 RIP 路由重分发回 OSPF，如果没有过滤，同一条路由会在两个协议之间来回传递，度量不断变化，路由表反复震荡。解决办法是用 route-map 给重分发进来的路由打上 tag，反向重分发时匹配 tag 并拒绝。这个技巧很实用，值得记下来。

5.3 我在实验环境里踩过的几个坑

第一个坑是忘记配被动接口。实验环境里路由器连着若干台测试主机，OSPF 在这些接口上一直发 Hello，主机不回应，但报文一直在发。虽然不影响功能，但抓包时满屏都是 Hello，干扰判断。后来养成了习惯：所有面向终端网段的接口一律配成被动，只保留路由器之间的互联接口参与邻居建立。

第二个坑是Router ID 冲突导致邻居反复断开。当时用模板批量配置了六台路由器，其中两台的 Loopback 地址复制时忘了改，结果这两台的 Router ID 相同，邻居状态在 FULL 和 DOWN 之间来回跳。日志里能看到大量邻居状态变化的记录，但如果不逐条看，很容易以为是链路不稳。教训是配置完成后一定要做一次全局的 Router ID 核对。

第三个坑是调整参考带宽只改了一端。当时为了验证开销计算，把一台设备的参考带宽改成 10000，另一台还是默认值，结果两端的路径开销完全不同，路由选了明显不合理的一条。查了半天以为是拓扑问题，最后对比配置才发现是参考带宽不一致。这件事之后，我把“参考带宽必须在区域内统一”写进了操作检查清单，每次变更都要核对。

第四个坑和虚链路有关。曾经设计了一个区域没有直接连到骨干区域，想通过虚链路接过去。配置本身没错，但虚链路依赖底层到达对端 ABR 的路由，而那条路由又需要通过 OSPF 学到——这形成了一个先有鸡还是先有蛋的循环。最后是通过在两端之间配一条静态路由打破循环才解决。虚链路这个东西，能不用就不用，它本质上是在给不规范的区域设计打补丁，维护成本很高。

6. 收尾的几句实在话

路由协议这块内容，光看文档很难真正掌握，因为文档写的是“协议应该怎么工作”，而现场遇到的是“它为什么不按预期工作”。我的建议是一定要动手搭环境，哪怕只是三台虚拟路由器加几台测试主机。把邻居建起来，然后故意改错一个参数，观察它卡在哪个状态，这个学习效率比读十遍理论高得多。

另外提醒一点：抓包是排查路由协议问题最有效的手段，没有之一。协议报文的结构、参数的匹配情况、重传的节奏，在抓包里全都看得见。花半个小时学会用抓包工具过滤特定协议、读懂报文里的关键字段，比背一百条命令有用。我在排查那个 EXSTART 卡死的问题时，就是靠抓包看到 DBD 报文长度超过对端接口 MTU 后被丢弃，才锁定了原因——如果只看配置和日志，那个 MTU 的差异根本不会引起注意。

最后一个体会是，协议设计里的每一个“奇怪”的机制，背后都对应着一类真实发生过的问题。水平分割对应的是环路，DR 选举对应的是泛洪风暴，区域划分对应的是规模爆炸，参考带宽对应的是链路速率的演进。学习的时候多问一句“这个机制在防什么”，比记住它“是什么”更有价值，因为这些设计思路在遇到新问题时同样适用。