OSPF 和 RIP 这两个词放在一起,很多人脑子里立刻跳出两句背了无数遍的口诀:一个是链路状态,一个是距离矢量;一个用 SPF 算法,一个用贝尔曼-福特;一个管理距离 110,一个 120。面试能答,考试能过,可真到了要把一张网从 RIP 换成 OSPF,或者反过来在某个边缘节点留着 RIP 的时候,光靠这几句口诀是撑不住的。我自己就经历过一次,某公司的园区网从早期的 RIP 环境往 OSPF 迁移,前期规划得挺漂亮,结果割接当晚被一个十五跳以外的网段卡了三个小时,最后发现根因是 RIP 的跳数上限把一条本来能走通的路径直接判死了。这篇就围绕 OSPF 与 RIP 的实际差异展开,把两种路由协议在度量、报文、收敛、资源占用、选型判断和排错链路上的真实表现拆开讲清楚。适合刚接触动态路由、正在做协议选型,或者手里有存量 RIP 网络不知道怎么处理的朋友参考。

1. 别再从"距离矢量与链路状态"这句标签开始理解

1.1 两个协议对"网络拓扑"这件事的假设完全不同

标签之所以没什么用,是因为它只告诉你结论,不告诉你这个结论是从什么假设推出来的。RIP 的核心假设是:我不用知道整张网长什么样,我只要知道"去某个目的地,从哪个邻居走、大概几步能到"就够了。它像一个在小巷子里问路的人,每遇到一个人就问一句"去那个地方怎么走",对方只会告诉你"往东走,再问三个人就到了"。至于东边那条路是高速还是泥巴路,问路的人不知道,也不关心。

OSPF 的假设完全相反:每个路由器都必须先把"我周边长什么样"这件事描述出来,广播给同一个区域里的所有同伴,所有人手里的拼图凑齐了,再各自用同一套算法算一遍最短路径树。这样一来,每台设备对整个区域的拓扑认知是一致的,谁连谁、链路代价多少、哪里断了,都在拼图里。代价是每台设备都要存一份拓扑数据库,还要跑一遍 SPF 计算,内存和 CPU 的消耗比 RIP 高一个量级。

这个假设差异直接决定了后面所有行为:为什么 RIP 只能撑十五跳,为什么 OSPF 要分区域,为什么 RIP 收敛慢而 OSPF 快,为什么 OSPF 出问题时往往要先看邻居状态而 RIP 出问题时先看路由表有没有超时。理解这一层,再去记那些参数才有落脚点。

1.2 一个反直觉的事实:RIP 并不是"淘汰了的 OSPF"

很多资料把 RIP 写成历史包袱,暗示只要有得选就一定要上 OSPF。这个说法在大型网络上基本成立,但放到实际场景里就未必。我见过一个很小的分支办公点,出口设备就五台,网段加起来不到十个,拓扑是标准的星型,几年都不会动一次。这种环境下上 OSPF,除了多占一点内存、多几个需要维护的邻居关系之外,收益几乎为零;而 RIP 配置三行就能跑,写进交接文档里任何人都能看懂。

真正该被淘汰的不是 RIP 这个协议,而是"在规模和复杂度已经超出 RIP 承受范围时还硬用 RIP"这种做法。反过来说,在规模足够小、拓扑足够简单、变更频率足够低的环境里,选 RIP 是一种务实的偷懒,而且这种偷懒是有道理的。判断标准应该落在规模、收敛要求、拓扑复杂度、运维能力这几个维度上,而不是落在"哪个更新"上。把这一点想明白,选型的时候就不会被"新的一定更好"这种直觉带偏。

1.3 管理距离这个数字,只是厂商给的一个偏好权重

先把这个容易误导人的东西说清楚。管理距离并不是协议本身的属性,而是设备在"多条不同来源的路由指向同一个目的地"时,用来决定相信谁的优先级数值,数值越小越优先。常见取值里,RIP 是 120,OSPF 是 110。这意味着同一台设备同时从 RIP 和 OSPF 学到同一条路由时,默认相信 OSPF。

但这个数值是可改的,而且改它不会改变协议的任何一个行为。我在做双协议共存迁移的时候,曾经故意把静态路由的管理距离调到比 OSPF 还小,用来在主链路切换前做流量兜底,严格说这属于一种"非常规操作",但确实管用。要提醒的是,不同厂商对同一种协议的默认管理距离取值可能不完全一致,做跨厂商组网时最好先确认一遍,别拿一个厂家的默认值去套另一家的设备,否则路由选出来跟你预期的不一样,排查起来非常费劲。

2. 度量方式决定了它们能覆盖多大的网

2.1 跳数上限十五这件事,限制的到底是什么

RIP 用跳数(metric)衡量距离,直连为 0,每经过一台路由器加 1,最大值 15,16 被视为不可达。这个设计在当年是有道理的:那时候网络规模小,跳数少,简单计数足够用;而且"16 等于无穷大"这个约定让计数到无穷的问题有了一个终止点。但它带来的副作用非常硬:任何一条路径只要超过 15 跳,不管实际链路多快多可靠,都会被判为不可达。

这就导致了一个很尴尬的现象——网络直径成了硬约束。所谓网络直径,指的是从任意一台设备到任意另一台设备最多要经过几跳。RIP 要求整张网的直径不能超过 15,还得留出余量,实际规划时一般控制在 10 跳以内比较稳。超过这个规模怎么办?只能靠划分多个 RIP 域,或者在中间插入静态路由做隔离,把大网切成几个小网。这种切法非常不优雅,而且每切一刀就多一处需要手工维护的边界。

我遇到的那次割接事故就是这个原因:某公司的老网络是历史遗留的 RIP 环境,核心到最远的一个仓库要经过 14 跳,中间有几台设备在割接时被临时旁路了,路径多绕了两跳,直接变成 16,那个仓库的网段瞬间从路由表里消失,业务侧的表现就是"整个仓库断网"。当时先怀疑是链路问题,查了半天接口状态全是 up,最后才想起来数跳数。

2.2 OSPF 的 cost 怎么算,默认值为什么经常要改

OSPF 用开销(cost)衡量距离,默认算法是参考带宽除以接口带宽。参考带宽默认 100 Mbps,所以:

问题一眼就能看出来:百兆、千兆、万兆在默认配置下算出来的 cost 全是 1,也就是说 OSPF 认为这三种链路完全一样好。在一个千兆和万兆混跑的机房里,SPF 算出来的最优路径可能是走千兆那条,因为它到目的地的总 cost 恰好更小,而实际带宽差了十倍。这种选路结果业务上不一定马上出问题,但一旦流量大起来,拥塞就会出现在不该出现的那条线上。

解决办法是放大参考带宽,比如调成 10000 Mbps,那么算出来千兆是 10、万兆是 1、百兆是 100,区分度就有了。但这里有个坑必须提醒:参考带宽是全局参数,一台设备上所有 OSPF 进程共用,改动之后该设备上所有接口的 cost 会一起重算,SPF 会重跑,全区域的路由可能发生大面积变化。所以这个参数要在网络规划阶段就定好,不要等跑起来几个月了才想起来改。

还有一种更稳妥的做法:不动参考带宽,直接手工给关键接口指定 cost。这样只影响那几条链路,影响面可控。我在做数据中心互联的时候习惯用这种方式,把跨机房的两条链路 cost 设成 10 和 100,主备关系一目了然,以后想调整优先级只改一个数字就行,不用动全局参数。

2.3 带宽与延迟:同样一张拓扑会算出不同结果

举一个具体的小例子来说明两种协议选路的差异。假设有四台设备:A 连 B(百兆),B 连 D(千兆);A 连 C(千兆),C 连 D(百兆)。如果 A 要去 D:

• RIP 看跳数:A→B→D 是 2 跳,A→C→D 也是 2 跳,两条一模一样,RIP 通常只会保留其中一条(取决于更新到达顺序),另一条闲置,没有任何负载分担。这就是"等价路径只能选一条"的典型局面。
• OSPF 看 cost:假设参考带宽已调到 10000 Mbps,A→B 是 100,A→C 是 10,B→D 是 10,C→D 是 100。那么 A→B→D 总 cost 是 110,A→C→D 也是 110,依然等价。

这个例子说明,如果拓扑本身是对称的,两种协议算出来的结果可能一样。差异体现在非对称拓扑上:只要把上面任意一条链路改成万兆,RIP 的结果完全不变(还是 2 跳),而 OSPF 的结果立刻偏向那条大带宽路径。所以 OSPF 的优势不在于"算法更高级",而在于它的度量维度里包含了你真正关心的东西——链路能力。

顺带说一句,OSPF 默认不看延迟,只看带宽。如果业务对延迟敏感,比如某些实时性要求高的场景,带宽大但延迟高的链路反而会被选中,这时候要么手工调 cost,要么上更复杂的方案。这一点在选型时经常被忽略,以为"OSPF 会自动最优",其实它只在你告诉它的那个维度上最优。

3. 邻居关系与更新机制:日常运维中最常打交道的地方

3.1 OSPF 建立邻接要经过的状态机

OSPF 的邻居建立不是一步到位的,中间要经过一串状态,每个状态卡住都对应不同的根因。这在排错时非常有用,因为状态本身就是线索。

这里有两个点值得单独说。第一,2-Way 状态对非 DR/BDR 的邻居来说是正常的稳定状态,不需要惊慌。很多人第一次看邻居表发现一堆 2-Way,以为出故障了,实际上那是广播网络里的正常现象,只有 DR 和 BDR 之间、以及它们与所有其他路由器之间才需要到 Full。

第二,ExStart 卡住最常见的原因是 MTU 不一致。两台设备接口 MTU 一个 1500 一个 9000,Hello 阶段能通,到了交换数据库描述报文这一步就崩,表现为反复在 ExStart 和 Exchange 之间跳。这种故障非常隐蔽,因为 ping 是通的,甚至小包业务也是通的,只有 OSPF 建不起来。解决办法要么统一 MTU,要么在接口上配置忽略 MTU 检查(各厂商关键字不同,开启前要确认对业务没有副作用)。

3.2 为什么要分区域,以及 Area 0 的特殊地位

OSPF 用区域(Area)来限制拓扑信息的传播范围。所有非骨干区域都必须直接连到骨干区域 Area 0,区域之间的路由由区域边界路由器(ABR)做汇总和转发。这个设计的目的很直接:如果整张网只有一个区域,任何一条链路抖动都会让所有路由器的 SPF 重算一遍,规模一大就顶不住。分区域之后,一个区域内部的拓扑变化只影响本区域,其他区域只看到汇总后的一条路由,抖动被隔离了。

实际操作中有几个经验点。第一,Area 0 必须是连续的。如果因为历史原因骨干区域被切成了两块,需要用虚连接打通,但虚连接是临时手段,长期依赖它会埋隐患,因为虚连接依赖底层路由可达,底层一断虚连接就断,而且它的行为不如物理链路直观。第二,区域划分不要过碎,一个区域里就两三台设备也单独划一个区,收益不明显反而增加了 ABR 的负担。第三,ABR 上的汇总要在规划时就设计好,事后补做往往需要重新梳理地址规划。

3.3 RIP 的周期更新和一堆定时器

RIP 的机制朴素得多:默认每 30 秒把整张路由表发给邻居,邻居收到后更新自己的表,再等下一个周期继续传。除此之外还有几个定时器需要记住:

这几个定时器叠在一起,决定了 RIP 的收敛是以"分钟"为单位的。一条链路断了,邻居要等到超时才标记不可达,再经过抑制期才可能接受替代路径,整个过程几十秒到几分钟不等。对现在的业务来说这个时间基本不能接受,这也是 RIP 在核心网络上越来越少见的直接原因。

RIP 也确实做了一些防环努力,包括水平分割(从某个接口学到的路由不再从这个接口发回去)、毒性逆转(把从某接口学到的路由标记为不可达再发回去)、触发更新(拓扑变化时不等 30 秒立刻发)。这几个机制要分清:水平分割和毒性逆转是互补的,有些场景下必须关掉水平分割,比如中心-分支的星型结构里,分支之间要互通就必须让中心把路由原路发回去。我见过有人为了"防环"把水平分割开得死死的,结果分支之间完全不通,查了半天。防环机制不是越多越好,要看拓扑。

4. 收敛速度和资源消耗:真正影响体验的两个指标

4.1 收敛时间到底由什么决定

很多人说 OSPF 收敛快、RIP 收敛慢,这个结论对,但原因值得掰开。OSPF 快的原因有三层:一是链路状态变化会立刻触发 LSA 泛洪,不需要等周期;二是每台设备收到 LSA 后独立算 SPF,不需要等邻居逐个传话;三是 SPF 算法本身在区域内是确定性的,不存在"计数到无穷"的过程。

但 OSPF 也不是无脑快。影响它收敛时间的因素包括:Hello 和 Dead 定时器的设置(默认 10 秒 / 40 秒,也就是说链路断了最多要 40 秒才判定邻居失效,除非链路层能立刻上报)、SPF 计算的规模、LSA 泛洪的范围、以及是否有路由汇总在收敛。真正要做到亚秒级收敛,需要配合快速检测机制(比如链路层的快速故障检测)和定时器调优,单靠 OSPF 本身不够。

RIP 慢的根源在于它的信息传播是"逐跳接力"的。A 发现链路断了,要等到下一个更新周期才能告诉 B,B 再等下一个周期告诉 C,一跳一跳往外传,每跳至少 30 秒。触发更新能缓解这个问题,但它只能加速第一跳,后面的传播仍然是接力式的。所以 RIP 的收敛时间大致和网络直径成正比,直径越大越慢。

4.2 小设备上的内存和 CPU 是硬约束

这一点在选型时经常被忽略。OSPF 要维护链路状态数据库,还要跑 SPF,对内存和 CPU 的要求明显高于 RIP。在一台低端设备上,如果区域规模大、LSA 数量多,可能出现 SPF 反复重算、CPU 占用居高不下的情况。我见过一个场景,某分支机构的接入设备性能有限,被误配进了一个几百台设备的大区域,结果那台设备的 CPU 长期在 70% 以上,业务转发时延抖动明显,后来把它单独划到一个小区域并做汇总,才恢复正常。

RIP 的资源占用就低得多,它只维护一张路由表,不需要拓扑数据库,计算量也小。所以在资源受限的设备上,RIP 反而是一个合理选择,前提是规模在它的承受范围内。判断规模不能只看设备数量,还要看网段数量、拓扑变化频率、以及是否有大量等价路径。

还有一个容易被忽略的点:OSPF 的 SPF 计算是有抑制机制的,短时间内多次拓扑变化不会每次都触发全量计算,而是会延迟合并。但如果拓扑持续抖动,抑制机制反而会让收敛变慢。所以在链路质量差的环境里,先解决链路问题,别指望协议能兜住。

5. 什么情况下选 RIP 反而是对的

5.1 规模阈值和运维能力的匹配

我一般用几个维度来判断。设备数量在十台以内、网段数量在二十个以内、网络直径不超过五跳、拓扑基本是星型或简单树型、年变更次数屈指可数——这种环境下 RIP 完全够用,而且配置简单、排错直观、交接容易。反过来,只要出现下面任意一条,就该考虑 OSPF:网络直径接近或超过十跳、需要多路径负载分担、需要区域化来隔离抖动、有大量非对称链路需要按带宽选路、拓扑变更频繁。

还有一条很现实的因素是运维能力。RIP 的排错逻辑非常线性:看路由表有没有、看定时器有没有超时、看水平分割有没有配错,基本上半小时能定位。OSPF 的排错需要理解状态机、LSA 类型、区域关系,门槛明显更高。如果团队里没人熟悉 OSPF,硬上之后出故障的恢复时间可能比 RIP 更长。这不是说不要学 OSPF,而是说选型要考虑团队的实际情况。

5.2 迁移路径和双协议共存的注意事项

从 RIP 迁到 OSPF,常见做法是先在核心层启用 OSPF,边缘保留 RIP,在边界设备上做双向重分发,然后把边缘逐片切过来,最后撤掉 RIP。这个过程中有几个坑。

第一个坑是重分发环路。双向重分发如果没有做过滤,从 RIP 学到的路由重分发进 OSPF,又从 OSPF 重分发回 RIP,路由的来源信息就丢了,可能形成环路或者次优路径。常规做法是在重分发点用路由策略做标记和过滤,确保每条路由只在它该在的协议里存在。

第二个坑是管理距离导致的不对称。迁移期间,边界设备可能同时从两个协议学到同一条路由,默认相信 OSPF,但如果 OSPF 那边的路径实际更差,流量就会走错。这时候需要临时调整管理距离或者用路由策略控制,等迁移完成再恢复。

第三个坑是汇总点没规划好。RIP 没有区域概念,OSPF 有,迁移时如果没提前规划汇总,会出现大量明细路由在两个协议之间来回传,路由表膨胀得很快。我的经验是迁移前先把地址规划重新梳理一遍,把可以汇总的段落标出来,迁移时同步做汇总,而不是等迁完再补。

6. 配置落地与排错链路

6.1 基础配置的对照写法

下面用通用命令行风格示意,各厂商关键字会有差异,思路是通用的。

RIP 部分:

# 启用 RIP 进程,使用版本 2(支持子网掩码和认证) router rip version 2 no auto-summary # 关闭自动汇总,否则跨网段会出问题 network 10.1.0.0 # 宣告主网段 network 10.2.0.0 passive-interface Gi0/1 # 面向终端的接口设为被动,不发更新

OSPF 部分:

router ospf 1 router-id 10.0.0.1 # 强烈建议手工指定 network 10.1.0.0 0.0.0.255 area 0 network 10.2.0.0 0.0.0.255 area 1 passive-interface Gi0/1

几个必须注意的点。第一,RIP 的no auto-summary在做不连续子网时是必须的,不关的话设备会把 10.1.x.x 和 10.2.x.x 汇总成 10.0.0.0/8 发出去,对端收到后可能把本该走别的路径的流量吸过来。第二,OSPF 的router-id一定要手工指定,不指定的话设备会用某个接口地址自动选,接口一变动 Router ID 就可能变,邻居关系会中断重建立。第三,OSPF 的 network 命令后面跟的是反掩码,不是子网掩码,写错的话接口不会被纳入 OSPF,表现为邻居建不起来,这个错误新手非常容易犯。

6.2 六个高频故障的排查顺序

按我自己的习惯,排错遵循"从下往上、从局部到全局"的顺序,不要一上来就怀疑协议。

举一个具体例子。有次 OSPF 邻居一直停在 Init,接口状态正常,ping 得通。先查认证,两边配置一致;再查区域 ID,一致;最后抓包发现一端发的 Hello 里邻居列表是空的,另一端收到的 Hello 里也看不到对方,说明是单向的。顺着查下去发现中间有一台二层设备做了组播过滤,把 224.0.0.5 的单向流量拦了。这种问题光看配置永远看不出来,必须抓包。

再举一个 RIP 的例子。某分支网络里两个下级站点之间不通,但都能通总部。检查路由表发现总部设备上两条明细路由都在,分支设备上也有。最后定位到总部面向分支的接口开了水平分割,从这个接口学到的路由不会再从这个接口发回去,所以分支 A 的路由传不到分支 B。关掉该接口的水平分割后立刻恢复。这个坑在星型结构里非常经典,记住一条:水平分割在点到点链路和环状拓扑里是防环利器,在星型汇聚点上是拦路虎。

6.3 几个只有踩过才知道的细节

第一个细节,OSPF 的 DR/BDR 选举是非抢占的。也就是说,如果一台优先级更高的设备后来加入,它不会把现有的 DR 顶掉,除非现有的 DR 失效或者进程重启。这意味着你调整了优先级之后,如果不重启进程,选举结果不会变。我在做设备替换时吃过这个亏,新设备优先级配得更高,结果老设备一直是 DR,新设备只是 DROther,白白多绕一跳。

第二个细节,修改接口带宽参数会影响 OSPF 的 cost 计算,但这个参数在很多设备上是一个"逻辑值",不改变物理速率。也就是说你把它改成 1000,实际链路还是百兆,cost 却按千兆算。这种做法在链路实际速率和协商速率不一致时有用,但一定要记得在文档里标注,否则接手的人会被误导。更推荐的做法是直接改 cost,意图更明确。

第三个细节,RIP 的定时器可以调,但不要随便调。把更新周期从 30 秒改到 5 秒能加快收敛,但代价是更新报文密度提高六倍,在广播网络上会明显增加带宽和 CPU 开销,而且不同设备定时器不一致会导致路由震荡。除非有明确的必要性,否则保持默认。

第四个细节,做双向重分发时,一定要给重分发进来的路由打标记(tag),再用路由策略按标记过滤,防止路由回灌。这是标准操作,但很多简化教程里直接省略了,照着配很容易出环路。

最后分享一个我自己的习惯:不管是 RIP 还是 OSPF,上线前先把"预期路由表"写出来,包括每条路由的来源协议、下一跳、度量值,然后拿实际路由表去逐条比对。这个方法看起来笨,但比在故障发生后再去反推要快得多。尤其是做协议迁移的时候,有了这份对照表,能立刻发现哪条路由走错了或者压根没出现,定位效率提高非常明显。