从RIP到OSPF：自治系统内部路由协议原理、配置与排错

1. 先把自治系统这层皮剥开看清楚

刚接触路由协议那会儿，我对"AS"这个词一直没什么实感，直到第一次参与一个跨园区、跨运营商的网络割接，才真正明白它的分量。AS，自治系统（Autonomous System），说白了就是"一块由同一个管理机构说了算、内部路由策略自洽的网络集合"。它不是一个物理概念，不是一栋楼、一个机房，而是一个管理边界。边界之内，路由怎么走，各家自己拍板；边界之外，只对外宣告"我这儿有哪些网段可达"。而支撑这套逻辑运转的，就是AS内部的路由协议RIP、OSPF，以及AS之间的BGP。这几个词经常被一起提，很多人一上来就想学BGP，其实没有扎实的IGP打底，BGP学起来就是空中楼阁。这篇文章我打算把RIP和OSPF这两套IGP协议从设计动机、报文细节、配置落地到故障排查，完整拆一遍，适合刚入行做网络运维的朋友，也适合那些日常在云上配路由表、但没系统学过底层协议的人，看完至少能自己动手搭一套跑得起来的实验环境，出了故障知道往哪个方向摸。

1.1 AS不是一个网络，是一块被统一管理的路由域

要理解AS，最容易犯的错是把它和"一个子网""一个VLAN"混为一谈。子网是三层编址单位，VLAN是二层隔离单位，而AS是路由策略的管理单位。同一个AS内部，可以包含成百上千个子网、几十个区域、多台出口设备；反过来，一个子网也绝不会跨越两个AS。判定标准很朴素：这些设备是不是由同一个团队在维护、用同一套地址规划、遵循同一套选路原则？如果是，那它们大概率就属于同一个AS。

从协议视角看，AS的边界就是IGP泛洪的边界。OSPF的LSA不会跑到AS外面去，RIP的路由表也不会。边界路由器（通常叫ASBR，自治系统边界路由器）做两件事：把内部网段通过BGP宣告给外部，把外部学来的路由通过重分发（redistribute）注入内部IGP。这中间有一个非常容易出事的点——重分发忘了打度量值或者忘了做路由过滤，外部几万条路由灌进IGP，直接把内部设备的CPU和内存打满。我见过一次就是因为一台边界设备把全表重分发进了OSPF，核心交换机重启了两回，最后靠加route-map才压住。

所以我把AS理解为三层结构：最外层是管理边界，中间层是IGP负责的内部可达性，最内层是每台设备自己的路由表和转发表。RIP和OSPF解决的是中间层的问题，它们不关心业务，只关心"到我这儿怎么走最短、最稳、最不容易环路"。把这一层想清楚了，后面所有的协议细节、参数设计，其实都是围绕"如何在有限的开销下算出无环的最短路径"这个核心命题展开的。

1.2 IGP管内、EGP管外，两条腿走路

网络界的分工向来清晰：IGP（Interior Gateway Protocol，内部网关协议）负责AS内部，EGP（Exterior Gateway Protocol，外部网关协议，如今实际上就是BGP一家独大）负责AS之间。这个分工不是为了炫技，而是由两种协议面对的问题本质决定的。AS内部的特点是拓扑可控、规模有限、目标是快速收敛和最短路径；AS之间的特点是拓扑不可控、规模巨大、目标是策略可控和稳定性优先。你要让BGP去算最短路径，它连全网拓扑都看不全；你要让OSPF去承载几十万条路由，它的SPF计算和LSA泛洪会把设备压垮。

所以你会看到一个很典型的格局：园区网、数据中心内部跑OSPF，出口跑BGP；小型分支或者老设备跑RIP，往上汇聚进OSPF。IGP像小区里的路，讲究的是从A栋到B栋怎么走最近；BGP像城市之间的高速，讲究的是这条路谁让走、谁不让走、走哪条更划算。两者不是替代关系，是接力关系。

这里顺便说一句组织架构上的事：AS号在全球范围内是有限资源，2字节的AS号早就分完了，现在普遍用4字节。私有AS号段（类似私有IP）可以在内部随便用，只要不出公网就行。这个设计思路跟私有地址是一个逻辑——边界上做NAT或者做转换，内部怎么方便怎么来。

1.3 为什么今天还要回头看RIP

每次聊到RIP，总有人问：这协议都被淘汰了吧，还学它干什么。我的答案是：生产环境里确实少见，但它是理解距离矢量思想最干净的样本。RIP的逻辑简单到可以在纸上推演，你花两个小时把它吃透，再去理解EIGRP的DUAL算法、BGP的路径矢量，会发现底层是同一套思维方式——只相信邻居告诉我的信息，不自己算拓扑。

而且RIP并没有死透。一些老旧的工业设备、嵌入式模块、小规模的分支互联，还在用它，因为实现简单、资源占用低、配置几行就完事。我在一个十几台设备的小型仓储网络里就用过RIPv2，配置量比OSPF少一半，维护成本极低。当然，一旦超过十几跳、或者需要快速收敛，RIP就完全不够看了。

OSPF则是另一回事，它是目前企业网和数据中心内部最主流的IGP之一，你打开任何一台中高端路由设备的配置手册，OSPF永远排在前几章。它的设计复杂度比RIP高一个数量级，但换来的收敛速度、扩展能力和对VLSM的支持，是完全值得的。接下来的内容我会按"思想—机制—配置—排错"的顺序，把这两个协议拆开讲，中间穿插我自己踩过的坑。

2. RIP：用跳数说话的极简主义

RIP全称Routing Information Protocol，中文一般叫路由信息协议。它的核心度量只有一个——跳数（hop count），也就是数据包要经过几台路由器。最多15跳，16跳视为不可达。这个上限决定了RIP只适合小型网络，因为一旦网络直径超过15，某些网段就永远学不到了。很多人觉得这是个"缺陷"，但从设计者的角度想，这其实是一个安全阀：在一个规模受控的网络里，任何跳数异常增长的路由，大概率就是出环了，直接判死比慢慢收敛更安全。

2.1 距离矢量思想：只信邻居的嘴

RIP属于典型的距离矢量协议（Distance Vector）。这个"矢量"指的是方向和距离的组合——邻居告诉我"到X网段距离是3跳，方向是我这边"，我收到之后加上自己到邻居的1跳，就变成4跳，方向指向那个邻居。整个过程里，路由器从来不知道全网的拓扑长什么样，它只知道"从哪个口出去、要几跳"。

这种设计的好处是极其省资源：每台设备只需要维护一张路由表，不需要存拓扑图，也不需要跑复杂的算法。坏处也很明显——信息是"二手"的，邻居说的未必对，而且邻居可能说的是过时的、甚至是它自己搞错的信息。这就引出了距离矢量协议的两个经典问题：收敛慢和计数到无穷。

我常用一个类比来解释：村口老王告诉你"去镇上走东边那条路，20分钟到"。你不知道东边那条路是不是真的通，也不知道老王是不是三小时前听到的消息。你只知道老王平时靠谱，就信了。等哪天东边修路封了，老王要等到下一次有人告诉他，他才知道，然后再告诉你。这中间的延迟，就是收敛时间。

RIP的收敛慢到什么程度呢，默认拓扑变化后要等30秒的更新周期才能传出去，每经过一跳再等30秒，网络直径一大，分钟级别的收敛都是正常的。所以它只适合那种拓扑基本不变、偶尔断一下也能忍的环境。

2.2 四个定时器撑起整个收敛过程

RIP的行为几乎完全由四个定时器定义，这四个数字背下来，很多故障现象就能解释通了。

这四个数字之间的关系很重要：失效180秒、抑制180秒、清除240秒。注意抑制期是从失效那一刻开始算的，不是从最后一次收到更新算。所以一条路由从"邻居不说话"到"彻底消失"，最长要经历240秒左右，四分钟。这在现代网络里几乎是不可接受的，一次链路抖动，四分钟内流量可能一直在黑洞里转。

还有一个细节很多人不知道：触发更新（Triggered Update）。RIP并不是完全靠30秒周期，一旦检测到路由变化，会立即发一次更新，但会加一个随机延迟（1到5秒），避免多台设备同时发包造成拥塞。这个随机延迟是个很聪明的设计，在多路互联的拓扑里能明显降低风暴概率。

注意：如果你在实验环境里调大了Update周期，一定要同步检查Timeout和Flush，否则会出现路由已经不可用但表里还在的情况。四个定时器是一套联动参数，不能单独改一个。

2.3 环路的五种治法，我只常用三种

距离矢量协议最怕的就是环路。举个最常见的场景：A和B互相连接，A有一条到10.0.0.0/8的路由，下一跳是C。C挂了，A把这条路由标记为16跳不可达，但在它把更新发出去之前，B先把"我到10.0.0.0/8是2跳，走A"发过来了。A一看，2跳比16跳好，立刻改成走B，3跳。B再收到A的更新，发现A变成3跳，自己改成4跳……两个路由器就这么互相"喂"着，跳数一路涨到16才算完。这段期间，去往10.0.0.0/8的流量全在A和B之间来回弹，这就是计数到无穷（Counting to Infinity）。

RIP对付这个问题有几种手段，我实际配得最多的是前三种：

水平分割（Split Horizon）：从某个接口学来的路由，不再从这个接口发回去。道理很简单——你告诉我的路，我再告诉你一遍没有意义，只会制造回路。这是最基础也最有效的一条，绝大多数实现默认开启。

毒性逆转（Poison Reverse）：水平分割的加强版，从某接口学来的路由，从这个接口发回去时把跳数设为16（不可达）。跟水平分割的区别是，它明确告诉邻居"这条路从我这儿走不通"，而不是干脆不说。好处是能加速邻居的收敛，坏处是更新包变大了。

路由毒化（Route Poisoning）：当一条路由失效时，不是悄悄删掉，而是主动发一条跳数16的更新出去，告诉所有人这条路断了。配合触发更新使用，能显著缩短收敛时间。

另外两种是抑制时间（Hold-down）和触发更新，前面提过了。这五种机制组合起来，能把环路的影响控制在一个可接受的范围内，但不能彻底消除，这也是距离矢量协议的天花板所在。

实测下来的经验：在一个星型或者简单树状拓扑里，光靠水平分割就够了；一旦出现多路互联或者环形拓扑，必须要靠路由毒化加触发更新，否则收敛时间里必然出现短暂环路，业务侧能感知到丢包。

2.4 RIPv2配置实操与验证

RIP有两个版本。RIPv1是有类路由，更新包里不带子网掩码，不支持VLSM，用广播发送（255.255.255.255）。RIPv2是无类路由，带掩码，支持VLSM和CIDR，用组播224.0.0.9发送，还支持明文和MD5认证。现在配RIP，基本不会有人用v1了，除非对方是古董设备。

下面是一段典型的RIPv2配置，语法用业界通用的CLI风格，各家设备大同小异：

router rip version 2 no auto-summary network 192.168.10.0 network 10.1.1.0 passive-interface GigabitEthernet0/1

几个关键点逐条解释：

version 2必须显式声明，很多设备默认还是v1，不写就会和邻居版本不匹配，两边互相收不到更新。no auto-summary是关掉自动汇总，这个在无类环境下是必须的，否则192.168.10.0/24和192.168.11.0/24会被汇总成192.168.0.0/16发出去，导致明细路由丢失。

network后面跟的是主类网段，不是接口地址，也不是掩码。这一点新手最容易错，写成network 192.168.10.1会直接被拒绝或者行为异常。它的含义是"把属于这个主类网段的、处于up状态的接口，都加入RIP进程"。

passive-interface是把不想跑RIP的接口设为被动，被动接口只接收不发送。这个非常关键——面向用户终端的接口、面向外网的接口，都应该是被动的，否则你的路由表会莫名其妙地被广播出去，既浪费带宽又有安全隐患。

验证的话，几条命令足够：

show ip protocols show ip route show ip rip database debug ip rip

show ip protocols看的是当前跑的协议、版本、network宣告、被动接口列表、定时器；show ip route看学到的路由，RIP路由标记是R，管理距离120；debug ip rip会把收发的每一条更新都打出来，排查"邻居在但学不到路由"这类问题时非常有用，但生产环境慎用，日志量很大。

认证的配置我一般会加上，尤其是跨楼宇、跨部门的链路：

key chain RIPKEY key 1 key-string MyRipKey2024 interface GigabitEthernet0/0 ip rip authentication mode md5 ip rip authentication key-chain RIPKEY

认证不匹配的表现是：邻居关系看起来还行（因为RIP没有邻居状态机），但路由条目学不到。这种情况特别隐蔽，不看debug根本发现不了。

3. OSPF：每个路由器自己算最短路

OSPF（Open Shortest Path First，开放式最短路径优先）是完全不同的思路。它属于链路状态协议（Link State），每台路由器不再依赖邻居的口头描述，而是自己收集全网的拓扑信息，构建一张完整的拓扑图，然后用Dijkstra算法自己算最短路。这个转变是质的飞跃——因为每个人都有一份完整的、一致的地图，谁也不依赖谁的"二手消息"。

代价是资源消耗上去了：每台设备要维护链路状态数据库（LSDB），要跑SPF计算，要在拓扑变化时泛洪LSA。所以OSPF的设计重点全在"如何高效地同步和更新这份地图"上，区域划分、LSA类型、DR选举，本质上都是为了控制泛洪范围、减少计算量。

3.1 从"道听途说"到"人手一份地图"

用类比说，RIP像是问路，OSPF像是自己拿着地图走。问路的好处是省事，坏处是信息不可靠、可能过时；拿地图的好处是准确，坏处是地图本身要维护、要更新、要保持所有人手上的一致。

那OSPF怎么保证大家的地图一致呢？靠三样东西：Hello报文、LSA交换、可靠泛洪。

Hello报文是邻居之间的"握手"，用来发现邻居、协商参数、维持关系。两台路由器要成为邻居，Hello报文里几个字段必须完全一致：Hello间隔、Dead间隔、区域ID、认证信息、Stub区域标志。只要有一项不一致，邻居就起不来。这也是排查OSPF故障时第一个要看的地方。

LSA是链路状态通告（Link State Advertisement），每台路由器把自己的接口、邻居、开销等信息封装成LSA发出去。泛洪是有确认机制的，收到LSA要回ACK，发出去的没确认会重传，这样就保证了可靠传输。每台设备把所有收到的LSA存进LSDB，最终大家的数据库趋同，算出来的最短路径树也就一致。

这里有个细节值得说：LSA是有序列号的，从0x80000001开始，每次更新递增，越大越新。如果一台设备重启，序列号会从头开始，邻居就会认为收到的是旧消息而丢弃。解决方式是重启后先发一个序列号跳到最大值的LSA（所谓"序列号跳变"），把旧信息冲刷掉。这个机制在早期的实现里出过不少问题，现在已经很成熟了。

3.2 LSA类型一张表说清

OSPF的LSA类型是学习重点，也是面试高频考点。我把常用的几种整理成表，重点看产生者和作用范围：

真正需要理解的是Type 1和Type 2。Type 1描述的是路由器的"点"——我有哪些接口、连了哪些邻居、每个接口的出方向开销是多少。Type 2描述的是广播网段这个"面"——这个网段上有哪些路由器（只列Full状态的），由DR负责产生。SPF算法就是拿这些点和面，构建出一张图，然后以自己为根算最短路树。

Type 3是ABR（区域边界路由器）的活儿。它把本区域的Type 1和Type 2算完之后，把结果汇总成Type 3，发给其他区域。注意，Type 3描述的是"网段"而不是"拓扑"，其他区域的路由器只知道"通过这个ABR能到这个网段"，但不知道这个区域内部长什么样。这也是OSPF区域设计的精髓——用信息抽象换规模化能力。

Type 5和Type 7的区别在于NSSA（Not-So-Stubby Area）。普通Stub区域不允许Type 5进入，完全隔离外部路由；但有些场景下，区域内又确实有设备需要引入外部路由（比如连了个小分支），这时候就用NSSA，允许用Type 7在区域内传，到ABR处再转成Type 5发给其他区域。

提示：看到路由表里有O E1、O E2的标记，就是Type 5或Type 7引入的外部路由。E1的开销会累加内部路径开销，E2默认不累加（固定为外部开销），这个区别在做选路控制的时候经常用到。

3.3 区域划分与骨干区域的硬约束

OSPF的区域设计有一条铁律：所有非骨干区域必须直接连接到骨干区域（Area 0）。这是因为OSPF的区域间路由是"星型"结构，区域间的流量必须经过骨干区域中转，ABR把本区域的信息汇总成Type 3发给骨干，骨干再分发给其他区域。如果两个非骨干区域直接相连，它们之间的路由是学不通的——因为互相之间不产生Type 3。

我见过不少人在实验环境里直接把Area 1和Area 2连起来，然后纳闷为什么路由不通。原因就在这里。这种情况下有两种解法：一是用虚链路（Virtual Link）把Area 1"挂"到Area 0上，相当于在逻辑上延长骨干区域；二是重新规划，把该区域直接接到Area 0。

虚链路的配置大概长这样：

router ospf 1 area 1 virtual-link 10.0.0.2

注意虚链路两端必须是同一个区域的ABR，而且要能互相到达。虚链路本质上是两台ABR之间建一条逻辑的点对点连接，让LSA能跨区域传递。我的经验是：虚链路能不用就不用。它是补救手段，不是设计手段，一旦网络规模扩大，虚链路的维护成本会非常高，出了故障定位也困难。

区域划分的实际原则，我是这么把握的：按地理位置分、按管理边界分、按规模分。单个区域内的路由器数量控制在50台以内比较稳妥，超过100台就要考虑拆了，因为SPF计算和LSA泛洪的压力会明显上升。核心层和汇聚层放Area 0，各个分支或者楼层放独立区域，这样某个区域的拓扑抖动被限制在区域内部，不会影响全局。

3.4 DR/BDR选举，40秒等待是坑

在广播型网络（比如以太网）上，如果每台路由器都和其他所有路由器建邻居、互发LSA，n台设备就要建n(n-1)/2个邻接关系，泛洪量会爆炸。OSPF的解法是选出一个DR（指定路由器）和一个BDR（备份指定路由器），所有其他路由器（DROther）只和DR/BDR建立Full状态的邻接，互相之间只停留在2-Way。LSA先发给DR，DR再统一泛洪。

选举规则不复杂：先比优先级（0-255，默认1），优先级高的当选；优先级相同，比Router ID，大的当选。优先级设为0表示不参与选举。BDR是优先级第二高的。

但真正容易踩的不是规则，是等待时间。DR选举不是邻居一建立就立刻进行的，要等一个Wait Timer（等于Dead间隔，广播网络默认40秒）。这40秒里，路由器把收到的Hello里的DR字段都记下来，等时间到了才统一选举。所以如果你刚配完OSPF就去看邻居状态，会发现全是2-Way，等40秒之后才有一个变成Full，这是正常的，不是故障。

更麻烦的是抢占问题：OSPF的DR选举是非抢占的。也就是说，如果一台高优先级的设备晚于DR上线，它不会把现任DR踢掉，一直要等到DR失效或者重启才会重新选举。这个设计是为了稳定性，但对运维来说是个坑——你改完优先级，发现没生效，重启一下邻居才生效。所以我的习惯是：所有设备的接口优先级在初期就规划好，别等上线了再改。

在点对点网络（比如串口、隧道接口）上不存在DR/BDR，两边直接建Full邻接，这是两种网络类型的本质区别。配置时可以用ip ospf network point-to-point显式指定，避免在点到点链路上浪费40秒选举时间。

3.5 邻居状态机八步走

OSPF的邻居状态机是排查问题的核心工具。状态从低到高依次是：

这套状态机的价值在于：你看到卡在哪个状态，基本就能锁定问题类型。卡在Init，八成是单向通信——比如一边的ACL把组播224.0.0.5挡了，或者一边是广播网络一边是点对点；卡在ExStart，九成是MTU不一致或者Router ID重复；卡在2-Way，如果是DROther之间那是正常的，如果是DR/BDR之间那就有问题。

我自己遇到过最坑的一次是：两台设备通过中间的二层设备互联，邻居一直卡在ExStart，查了半天MTU都是1500，最后发现是中间的二层设备做了MTU裁剪，实际路径MTU只有1400。这种问题只能靠逐段ping大包来定位。

3.6 开销计算与参考带宽

OSPF的度量叫Cost（开销），计算方式是参考带宽除以接口带宽，默认参考带宽是100Mbps：

Cost = 100,000,000 / 接口带宽(bps)

所以10M接口是10，100M接口是1，1000M接口……也是1。这就出问题了——千兆和百兆的开销一样，OSPF认为它们等价，会做负载均衡，但实际上带宽差了十倍。这是默认参考带宽设置留下的历史包袱，早年100M就是天花板，现在万兆都普及了。

解法是修改参考带宽，把它调到一个能覆盖当前所有链路速率的量级：

router ospf 1 auto-cost reference-bandwidth 100000

这里单位是Mbps，100000就是100Gbps。改完之后，千兆是100，万兆是10，百兆是1000，比例关系就对了。

注意：同一个OSPF域内所有路由器的参考带宽必须一致，否则算出来的开销没有可比性，会导致非预期的选路。改之前一定要全网统一规划，别一台一台改。

除了改参考带宽，也可以直接在接口上手工指定开销：

interface GigabitEthernet0/0 ip ospf cost 50

手工指定适合需要精确控制选路的场景，比如链路做了流量工程、或者两条链路带宽相同但希望主备明确。缺点是维护成本高，链路一调整就要改配置，容易漏。

还有一个容易忽略的点：开销是累加的。从源到目的的整条路径，开销是每一跳出接口开销之和。所以选路结果不一定是"经过带宽最大的那一段"，而是"总开销最小的一条路"。做流量规划的时候，一定要按整条路径算，不能只看单段。

3.7 配置实操与关键参数

下面是一段典型的多区域OSPF配置：

router ospf 1 router-id 10.0.0.1 auto-cost reference-bandwidth 100000 network 10.0.1.0 0.0.0.255 area 0 network 10.0.2.0 0.0.0.255 area 1 passive-interface GigabitEthernet0/3 area 1 stub

router-id建议手工指定，不要依赖自动选举。自动选举的规则是：优先选最大的Loopback地址，没有Loopback就选最大的物理接口地址。问题在于，如果那个接口down了，Router ID会变，OSPF进程会重启，全网震荡。手工指定一个稳定的Loopback地址是最稳的做法。

network后面跟的是反掩码（wildcard mask），不是子网掩码。这点和RIP不同，写错了会宣告错误的网段。0.0.0.255对应/24，0.0.0.0对应精确匹配一个地址。

passive-interface在OSPF里同样重要，用户接入口不跑OSPF，避免无谓的Hello报文和潜在的安全风险。

area 1 stub把区域1配成末梢区域，拒绝Type 5进入，ABR会自动下发一条默认路由。这个在分支场景非常实用，分支只需要一条默认路由，不需要知道总部的所有明细，既省资源又稳定。

验证命令：

show ip ospf neighbor show ip ospf database show ip ospf interface show ip route ospf

show ip ospf neighbor看邻居状态和角色，重点看State列是不是Full、Dead Time是不是在倒计时；show ip ospf database看LSDB，能看出各类LSA的数量和内容；show ip ospf interface看接口的开销、网络类型、定时器、DR/BDR信息，排查接口级问题必看；show ip route ospf看学到的路由，O标记是区域内，O IA是区域间，O E1/E2是外部。

4. 排错实录：邻居起不来、路由有了不通

协议原理看懂了，配置也写完了，真正的考验才刚开始。OSPF的故障排查我总结成一句话：先看邻居，再看数据库，最后看路由表。这个顺序不能乱，因为后一步的正确性依赖前一步。

4.1 卡在某个状态的对照表

前面列过状态机，这里展开说具体的排查动作：

卡在Down：先ping对端接口地址，通不通？不通就是二层或者三层链路问题，跟OSPF没关系。通了再看接口有没有启用OSPF（show ip ospf interface能不能看到这个接口），有没有被passive掉。

卡在Init：说明我收到了对方的Hello，但对方没收到我的。典型原因是单向可达——可能是ACL挡了组播、可能是NAT设备把224.0.0.5转掉了、也可能是一边的接口网络类型不匹配。还有一个隐蔽原因：两边Router ID相同，OSPF会把对方的Hello当成自己的，直接丢弃。

卡在2-Way：如果双方都是DROther，这是正常的，不用管。如果一方应该是DR/BDR却卡在2-Way，检查优先级配置、检查是不是有设备的接口优先级被设成了0。

卡在ExStart：教科书答案就是MTU不一致。因为DBD报文里带了MTU字段，两边不一致会一直重传。可以用ip ospf mtu-ignore临时绕过，但这只是掩盖问题，实际传输大包时还是会丢。正确的做法是统一MTU。除此之外，Router ID冲突也会卡在这里。

卡在Exchange/Loading：通常是LSA请求超时，或者数据库里有损坏的LSA。可以尝试清进程（clear ip ospf process），但生产环境慎用，会导致短暂中断。

4.2 路由有了但不通

这是另一类高频问题：邻居是Full，show ip route里也能看到路由，但业务就是不通。这种情况我会按四步走：

第一步，确认双向。路由是单向学到的还是双向都有？只有去程没有回程，业务照样不通。用traceroute从两端各测一次，看路径是不是对称。

第二步，确认下一跳可达。有时候路由表里的下一跳是递归查出来的，中间某一跳断了，路由还挂着但实际不可达。

第三步，确认过滤和策略。有没有在ABR上做了路由过滤、有没有在接口上做了ACL、有没有做重分发时的route-map把路挡了。这些策略类的配置最容易在交接的时候被遗漏。

第四步，确认转发面。控制面路由正确，不代表转发面正确。有些设备的硬件转发表更新滞后，或者有流表把流量导向了错误的方向。

我印象最深的一次故障：核心和汇聚之间OSPF邻居Full，路由也对，但部分网段不通。查了两个小时，发现是汇聚设备上有一条静态路由，管理距离比OSPF小，把OSPF学来的路由覆盖了。show ip route看的时候只看了O的条目，没注意到还有一条S的。这个教训让我养成了一个习惯：排查路由问题，先看完整路由表，不要只看某种协议学来的。

4.3 速查表与几个不说没人告诉你的细节

几个细节，都是踩过坑才知道的：

Hello和Dead必须是整数倍关系。默认10和40，你改Hello为5，Dead也要相应改成20，而且链路上所有设备必须一致。有人只改了一端，邻居直接起不来，还找不到原因。

OSPF的组播地址有两个：224.0.0.5是AllSPFRouters，224.0.0.6是AllDRouters。DROther发给DR用.6，DR泛洪给所有人用.5。如果你的ACL只放行了.5，DR选举后的LSA同步会出问题。

LSA有老化时间，最大3600秒，每1800秒刷新一次。如果看到某条LSA的Age接近3600，说明它一直没被刷新，可能是源头设备出问题了。

清OSPF进程是个大杀器，会导致所有邻居重建、路由重新收敛，业务会短暂中断。能用clear ip ospf neighbor就别用clear ip ospf process，前者只影响单个邻居，后者是全进程重启。

5. 选型：什么场景该用哪个

RIP和OSPF不是简单的"新旧替代"关系，选型要看场景。我整理了一张对比表，覆盖我实际做决策时会看的几个维度：

管理距离这一栏值得多说一句：当同一台设备同时从RIP和OSPF学到同一条路由时，会优先选管理距离小的，也就是OSPF（110 < 120）。这个机制在做协议迁移的时候特别有用——你可以让两个协议并行跑一段时间，OSPF的路由自动优先生效，等确认稳定了再把RIP撤掉，实现平滑过渡。

5.1 我实际做过的两次选型

第一次是一个小型仓储网络，十几台接入交换机、两台核心，网段不多，拓扑是标准的星型。当时考虑过OSPF，但算了一下配置量：每台设备都要配router-id、network、区域，还要考虑DR选举，而RIP只需要三行命令。最终选了RIPv2，跑了大半年没出过问题，链路抖动的时候也就丢几秒包，业务能接受。这个案例说明：协议选型要匹配网络规模，不要为了"先进"而增加复杂度。

第二次是一个跨三个楼宇的园区网，四十多台设备，有多条冗余链路，需要快速收敛。这种场景RIP完全不够看，必然选OSPF。规划了Area 0做骨干，每个楼宇一个独立区域，核心做ABR。实际跑下来，链路切换的收敛时间在2秒以内，业务基本无感。这个案例的教训是：区域规划要在项目初期就定好，后期再拆成本极高，因为涉及地址重新规划和设备重启。

5.2 几个反直觉的经验

OSPF不是越快越好。有人把Hello调到1秒、Dead调到4秒，想追求极致收敛，结果链路上一点抖动就触发邻居重建，路由表反复震荡，反而更不稳定。默认的10/40是经过大量实践验证的平衡点，除非链路质量特别好且有明确需求，否则不要改。

RIP的15跳限制有时反而是优点。在一个受控的小网络里，任何跳数超过15的路由都意味着配置错误或者环路，协议自动把它判死，省去了人工排查。这个"失败即安全"的设计思路，在今天的很多系统里还能看到影子。

重分发是万恶之源。不管是RIP引入OSPF还是反过来，都要做三件事：打度量值、做路由过滤、防环（用tag或者distribute-list）。我见过太多因为重分发配置不当导致的路由环路和次优路径，一出问题就是全网级别的。

别迷信默认参数。参考带宽、定时器、优先级、管理距离，这些默认值都有其历史背景，放到今天的网络里未必合适。但改之前一定要清楚"为什么改"和"改了会影响什么"，并且全网统一。

最后分享一个小技巧：做OSPF实验的时候，用抓包工具过滤ospf协议，同时打开几台设备的debug，能非常直观地看到Hello、DBD、LSR、LSU、LSAck这五类报文是怎么交互的。看一遍抓包，比读十遍教材管用。我当初就是靠反复抓包，才把ExStart阶段的主从协商彻底搞明白的——DBD报文里的三个标志位（I、M、MS）分别代表初始、更多、主设备，这三个位的组合变化，就是整个协商过程的脉络。