自治系统内RIP与OSPF路由协议：原理、配置、收敛对比与排障实践

1. 自治系统内部的路由，先把边界和分工想明白

自治系统这个词，第一次接触的人容易把它想成一个抽象的管理概念，但它其实是路由协议设计里最实际的一条分界线。简单说，一个自治系统就是由同一个管理主体运营、使用统一路由策略的一批网络和路由器的集合，对外用同一个编号标识自己，编号范围里 64512 到 65534 这一段是留给大家在实验和内部环境里随便用的私有号。这个编号在实验环境里随手写一个就行，比如我习惯用 65001 起步。为什么要划这条线？因为自治系统内部的路由协议（RIP、OSPF 这一类，统称 IGP）和自治系统之间的路由协议（BGP）解决的根本不是同一个问题，把它们混在一起谈，配置和排障的思路就会全乱。这篇东西我想把 IGP 这一层拆开讲透，重点落在 RIP 和 OSPF 两个协议上：它们各自怎么工作、度量怎么算、环路怎么防、区域怎么划、实际敲命令的时候哪些参数必须对齐、出问题了从哪儿下手。

1.1 从"一张网"到"多个域"：分层带来的实际收益

单台路由器管自己的直连网段，这件事没什么难度，接口配上地址、打开协议，直连路由自然就有了。麻烦的是当设备数量涨到几十台、上百台，网络从一条线变成一张网、再变成一张带环的网，每台设备都需要知道"去某个远端网段该往哪个口发"。如果所有路由器都维护一张完整的全网拓扑图，那么任何一根线抖动一下，全网设备都要重新算一遍，这个代价在小网络里看不出来，在几百台设备的环境里就是灾难。分层的思路正是从这里来的：把大网切成若干区域，每个区域只维护自己区域内的精确拓扑，跨区域的部分只保留"方向 + 距离"这种粗略信息。这样一处链路故障的影响范围被限制在区域内部，其他区域甚至感知不到。

这个收益是实打实的，但代价也得说清楚。区域边界上的路由器（负责把一个区域的明细转成汇总路由丢给其他区域的那台设备）会把原本精确的拓扑信息压缩成一条条汇总条目，压缩就意味着信息丢失，丢失就意味着可能出现次优路径——明明有一条更近的路，但因为汇总之后只看到一个方向，流量绕远了。这是所有分层路由设计的通病，OSPF 有，其他链路状态协议也有。我在做区域规划的时候通常会想清楚一件事：哪些网段之间的流量是高频的、对时延敏感的，这些网段尽量放在同一个区域里，不要让它们跨边界走汇总路由。区域划分的第一原则不是"按部门分""按楼层分"，而是按流量模式分。

1.2 IGP 和 EGP 的分工：RIP 与 OSPF 各自站的位置

自治系统内部跑的是 IGP，目标是快速收敛、无环、路径可度量；自治系统之间跑的是 EGP（实际上就是 BGP），目标是策略可控、规模可扩展、连接稳定。这两个目标几乎是对立的：快速收敛要求协议对任何变化都立刻反应，而稳定性要求协议对抖动要克制，不要一有风吹草动就重新选路。所以 BGP 的收敛时间是分钟级的，IGP 的收敛时间是秒级的，谁也不能替代谁。有些人会问，为什么不能全网只用一种协议？答案很直接：IGP 撑不住几十万条路由的规模，BGP 也扛不住高频的拓扑变化。

在 IGP 这个候选池里，RIP 和 OSPF 代表了两种完全不同的设计哲学。RIP 是距离矢量协议，它只知道自己"到某个网段有多远、下一跳是谁"，不知道中间经过了哪些设备，靠邻居之间互相"听说"来传播信息；OSPF 是链路状态协议，它要求每台设备都收集全区域的链路状态，自己跑一遍最短路径算法算出整张路由表。前者实现简单、资源占用低、配置几行就完事，后者实现复杂、要维护数据库、要做区域划分，但能撑起大型网络。这两个协议我都用过，说实话 RIP 在今天的生产环境里已经很少见了，但它作为一个理解距离矢量思想的样本，价值依然在——很多 OSPF 里看起来莫名其妙的机制，追根溯源都能在 RIP 踩过的坑里找到对应。

2. RIP：拿跳数当尺子，简单到有点固执

RIP 的历史比我入行的时间长得多，它诞生在一个处理器算力极其有限、链路带宽普遍只有几十 K 的年代，那个年代的设计约束造就了它今天看起来所有"不合理"的地方。理解这些约束，比背它的配置命令有用得多。

2.1 报文格式、四个定时器和"听说"式的路由学习

RIP 的报文封装在 UDP 里，端口 520，这个设计本身就说明了它的年代感——把路由协议跑在传输层之上，意味着它要依赖 UDP 的校验和与复用机制，但也带来了一点开销和一点安全隐患。版本上，RIPv1 用广播（255.255.255.255）发更新，报文里不带子网掩码，属于有类路由协议，也就是它认为 10.0.0.0/8 下面所有网段都必须是 /8；RIPv2 改成组播 224.0.0.9，报文里带上子网掩码，支持 VLSM 和 CIDR，还加了 MD5 明文认证的选项。今天要上 RIP，一定是 v2，v1 除了在老设备兼容场景下基本没有讨论价值。

RIP 靠四个定时器维持整个状态机，这几个数字必须记牢，因为排障的时候大部分现象都能用它们解释：

度量就是跳数，最大 15 跳，16 表示不可达。这个上限直接决定了 RIP 能撑的网络直径不超过 15 台路由器，超过就废了。为什么用跳数而不是带宽？因为在它设计的年代，让每台路由器去感知链路带宽并做加权计算，成本太高，而跳数是唯一一个不需要额外状态就能比较的量。缺点也明显：一条 2M 的窄带链路和一条 10G 的骨干链路，在 RIP 眼里都是 1 跳，选路的时候完全平等，这在今天几乎不可接受。

2.2 一个能跑起来的最小实验拓扑与配置

我在实验环境里习惯用一个三角形拓扑来验证 RIP，因为三角形天然带环，能直接观察到水平分割和毒性逆转的效果。三台虚拟路由器 R1、R2、R3，R1-R2 用 10.0.12.0/24，R2-R3 用 10.0.23.0/24，R1-R3 用 10.0.13.0/24，各自再挂一个环回口模拟业务网段。

! R1 配置 interface GigabitEthernet0/0 ip address 10.0.12.1 255.255.255.0 ! interface GigabitEthernet0/1 ip address 10.0.13.1 255.255.255.0 ! interface Loopback0 ip address 172.16.1.1 255.255.255.255 ! router rip version 2 no auto-summary network 10.0.0.0 network 172.16.0.0 passive-interface Loopback0

no auto-summary这行是必须加的，不加会出问题。RIP 默认会在有类边界上做自动汇总，比如把 172.16.1.0/24 汇总成 172.16.0.0/16 再发出去，如果网络里存在子网不连续的划分（一边是 172.16.1.0/24，另一边是 172.16.2.0/24，中间隔着别的网段），汇总之后两边都会认为对方是本地直连，路由就错了。这个坑在混合地址规划的老网络里特别常见。passive-interface用来把不需要跑协议的接口静默掉，环回口、用户接入口都应该加，既省资源又减少被探测面。

验证的时候三条命令够用：

show ip route rip ! 看 RIP 学到的路由 show ip rip database ! 看 RIP 自己的数据库，包括还没进路由表的 show ip protocols ! 看当前定时器、版本、汇总状态

show ip rip database这条容易被忽略，但它很有用——抑制中的路由、刚失效还没刷新的路由都会在这里显示，路由表里看不到的东西这里能看到。

2.3 环路从哪来：水平分割、毒性逆转和触发更新的组合拳

距离矢量协议最经典的病就是计数到无穷。场景是这样的：R1 挂的业务网段 172.16.1.0/24 断了，R1 把这条路由标记成 16 跳；但 R2 手里还有一条"经 R1 到 172.16.1.0，2 跳"的旧信息，它会把这个信息又发给 R1；R1 一看，哦，从 R2 走要 2 跳，那我自己走就是 3 跳，于是改成 3 跳……然后 R2 从 R1 那里学到 3 跳，改成 4 跳，两边互相抬价，一路加到 16 才停。这就是计数到无穷，收敛慢得离谱。

对付它有三招，通常是组合使用：

• 水平分割（Split Horizon）：从某个接口学到的路由，不再从这个接口发回去。这是最基本的一招，直接掐断了"把信息还给我的老师"这条路径。
• 毒性逆转（Poison Reverse）：水平分割的变种，反过来——从某接口学到的路由，主动从这个接口发回去，但跳数置为 16。好处是邻居能立刻知道这条路不通了，不用等定时器。代价是更新报文变大。
• 触发更新（Triggered Update）：拓扑一变立刻发更新，不等 30 秒周期。这一招对收敛速度提升最明显。
• 抑制计时器（Holddown）：收到"某路由变远了"的信息后，先冻结 180 秒，期间不接受这条路由的更差度量。这一招是防抖动的，但也会拖慢正常收敛，是把双刃剑。

注意事项：在部分网状或者点对多点的链路上，水平分割可能会误伤——因为从 A 分支学到的路由，本来是需要通过同一个物理接口转发给 B 分支的，水平分割一拦，B 分支就学不到了。老式帧中继环境里这个坑特别经典，解决办法是在该接口下关掉水平分割（no ip split-horizon），代价是环路防护弱了一层。

我个人对 RIP 的态度是：理解它的机制很有价值，但真要在生产里用它，必须先确认网络直径不超过 10 跳（留点余量）、拓扑是简单的树形或星形、链路带宽基本一致。只要有一条不满足，就该考虑换协议了。

3. OSPF：把全网地图摊开，每台设备自己算最短路

OSPF 的设计思路和 RIP 完全相反：它不靠邻居"口口相传"，而是要求每台路由器把"我和谁相连、连接的开销是多少"这些本地信息打包成链路状态通告（LSA），泛洪到整个区域，最终每台设备手里都有一份完全一致的链路状态数据库（LSDB）。有了这张完整的地图，每台设备独立跑一遍 Dijkstra 最短路径算法，算出以自己为根的最短路径树，再转成路由表。

这个设计的好处是不可能出现计数到无穷，因为每台设备都是基于完整地图自己算，不存在"信任邻居的二手信息"这回事。代价是资源消耗高——每台设备要存一份数据库、要跑算法、要维护邻居状态机。区域划分就是为了把这个代价控制住。

3.1 邻居状态机：从 Down 到 Full 的七个台阶

OSPF 排障有八成的功夫在邻居状态上，这套状态机必须烂熟于心。两台路由器要成为邻居，先要过 Hello 这一关。Hello 报文默认 10 秒发一次（广播网络和点对点网络），Dead 时间是 Hello 的 4 倍，也就是 40 秒；在非广播多路访问网络里 Hello 是 30 秒、Dead 是 120 秒。Hello 报文发到 224.0.0.5 这个组播地址，DR 和 BDR 额外监听 224.0.0.6。

Hello 报文里携带的字段，任何一项不一致，邻居就起不来：

还要注意 Router ID 不能重复，重复的话双方都起不来，日志里会明确提示。

状态机依次是 Down → Init → 2-Way → ExStart → Exchange → Loading → Full。几个关键节点的含义：

• Init：我收到了你的 Hello，但你的 Hello 里没有我的 Router ID，说明你还没听到我。这个状态通常意味着单向通信，检查链路方向、ACL、或者一端配了另一端没配。
• 2-Way：双方 Hello 里都看到了对方。在广播网络上，非 DR/BDR 之间的邻居关系正常就停在 2-Way，这是终态，不是故障。很多人第一次看到 2-Way 就慌，其实完全正常。
• ExStart / Exchange：开始交换数据库摘要（DBD 报文），协商主从关系。卡在这一步最常见的原因就是 MTU 不一致——DBD 报文比较大，MTU 小的一端会丢弃。解决办法要么把两端 MTU 调一致，要么在接口下加ip ospf mtu-ignore忽略检查。
• Loading：向邻居请求自己缺的 LSA 明细。卡在这里说明 LSA 传输有问题，通常是 MTU 或者链路质量导致的丢包重传。
• Full：数据库同步完成，邻居关系建立，开始参与 SPF 计算。

3.2 LSA 类型、区域划分与 DR/BDR 选举

OSPF 有六种常用 LSA，各自负责什么，必须分清楚，否则看数据库就是一团乱麻：

区域划分的硬规则只有一条：所有非骨干区域必须直接连到骨干区域 0，非骨干区域之间不能直接交换 Type 3 LSA，必须绕道区域 0 中转。这条规则听起来死板，背后有它的道理——它保证了区域间的无环性。两个非骨干区域如果直连，就可能形成区域间的环路，而 Type 3 LSA 只是"距离 + 方向"，不像 Type 1 那样带完整拓扑，没法靠 SPF 算法自动破环。所以要打通两个非骨干区域，要么把它们合并，要么拉一条虚链路穿过区域 0。

DR/BDR 选举是广播网络（以太网）特有的机制。一个网段上如果有 N 台路由器，两两建邻居就是 N×(N-1)/2 条邻接关系，泛洪的报文量爆炸。DR 的作用是把这个网状结构变成星形：所有路由器只和 DR/BDR 建立 Full 关系，非 DR/BDR 之间只停在 2-Way。选举规则是按优先级（默认 1，范围 0-255，0 表示不参选）先比，优先级相同再比 Router ID，数值大的胜。关键点在于这个选举不抢占——选举完成后，新加入的高优先级路由器不会抢走 DR 位置，除非原 DR 挂了。所以规划的时候要提前把优先级定好，别指望后来加台设备就能顶上。

3.3 多区域配置实操与开销调优

拓扑设计成：R1 在区域 0，R2 是 ABR，同时连区域 0 和区域 1，R3 在区域 1。

! R2（ABR）配置 interface GigabitEthernet0/0 ip address 10.0.12.2 255.255.255.0 ip ospf 1 area 0 ! interface GigabitEthernet0/1 ip address 10.0.23.2 255.255.255.0 ip ospf 1 area 1 ! interface Loopback0 ip address 10.0.0.2 255.255.255.255 ip ospf 1 area 0 ! router ospf 1 router-id 10.0.0.2 auto-cost reference-bandwidth 10000 area 1 range 172.16.0.0 255.255.0.0

area 1 range是做区域间汇总，把区域 1 里所有 172.16.x.0/24 压成一条 172.16.0.0/16 发到区域 0，能显著缩小其他区域的 LSDB 和路由表规模。汇总的前提是地址规划本身是连续的，如果地址乱分，汇总就无从做起——这也是为什么我一再强调地址规划要在上协议之前就定好。

auto-cost reference-bandwidth 10000这行是重点，它涉及到 OSPF 开销的计算逻辑。默认参考带宽是 100 Mbps，接口开销 = 参考带宽 / 接口带宽，取整且最小为 1。算一下就发现问题了：

• 100M 接口：100 / 100 = 1
• 10M 接口：100 / 10 = 10
• 1000M 接口：100 / 1000 = 0.1，取整后是 1

百兆口和千兆口的开销完全一样，都是 1。这意味着 OSPF 在默认配置下分不出百兆和千兆的优劣，选路的时候会"视而不见"。解决办法就是把参考带宽调大，比如调到 10000（10 Gbps），那么千兆口开销是 10、百兆口是 100、十兆口是 1000，区分度就出来了。

关键注意：auto-cost reference-bandwidth这个值必须全网所有路由器一致。如果一半设备用默认 100、一半用 10000，同一段链路在两端算出的开销不同，路由计算会彻底乱套，出现单向路由、路由环路这类恶性问题。上线之前一定要逐台确认。

除了改参考带宽，也可以直接在接口上写死ip ospf cost 10，这种方式更精确，适合需要对某条链路做特殊偏好的场景，比如有一条备份链路不希望它被选中，就把开销调到很大。

4. 收敛、开销、规模：两个协议的实测对比与选型

理论讲完，落到选型上必须拿数据说话。我在虚拟化实验环境里用一个线性拓扑做过几组对照测试，R1-R2-R3 三台设备串联，中间断开 R2-R3 之间的链路，测量路由收敛到稳定的时间。需要说明的是，这些数字是实验环境下的观察值，真实设备、真实流量负载下会有差异，重点看数量级和规律。

4.1 三个维度的实测数据与背后原因

收敛速度这一项要分情况讨论，很多人只看一个总数，其实两种故障类型的表现完全不同：

这个差异很有讲头。RIP 在链路物理断开时表现其实不差，因为接口 down 会立刻触发更新，1-3 秒就能把路由置为 16 跳传播出去；但如果是对端设备整机失联、接口还保持着 up 状态，RIP 只能干等 180 秒的失效定时器。OSPF 在这方面好很多，因为 Hello 是 10 秒一次、Dead 是 40 秒，40 秒内就能判定邻居失效。

OSPF 的收敛时间还可以进一步压缩，把接口下的 Hello 和 Dead 调小：

interface GigabitEthernet0/0 ip ospf hello-interval 2 ip ospf dead-interval 8

这样对端失联的检测时间能压到 8 秒以内，配合 SPF 计算，整体收敛可以做到 10 秒左右。但这招有代价：Hello 报文频率提高 5 倍，CPU 和带宽开销上升，而且必须两端配置一致，一端改了另一端没改，邻居直接起不来。我一般只在对时延特别敏感的链路上下这个手，不做全局配置。

资源开销这一项，OSPF 明显重于 RIP。RIP 的路由表就是一张扁平列表，内存占用和路由条数成正比，CPU 几乎不用算什么；OSPF 要维护 LSDB、邻居状态机、SPF 计算任务，内存占用和 CPU 峰值都高一个量级。在低端设备上这个差异会很明显，我见过配置较低的设备跑 OSPF 时 CPU 长期在 30% 以上，换成 RIP 立刻降到个位数。

规模上限决定了选型的边界。RIP 的 15 跳上限是硬约束，网络直径超过 15 台路由器就根本不能用，没有商量的余地。OSPF 通过区域划分可以撑到几百上千台，区域内的路由器数量建议控制在 50 台以内（这是经验值，不是标准），超过之后 LSDB 规模、SPF 计算频率、泛洪开销都会变得难以控制。

4.2 选型决策与混合部署的坑

选型其实没那么纠结，几条判断标准过一遍就清楚了：

• 网络直径小于 10 台路由器、拓扑是简单的星形或树形、链路带宽基本一致、对收敛速度没有严格要求 → RIP 能用，配置简单、维护成本低，小分支机构之间互联是个合理场景。
• 网络规模超过 15 跳、存在带宽差异大的链路、需要快速收敛、需要分区管理 → 只能用 OSPF。
• 网络里有大量外部路由要引入、需要做路由汇总 → OSPF 的汇总能力和 LSA 机制明显更强。

真正麻烦的是混合部署，也就是一部分区域跑 RIP、一部分跑 OSPF，在边界设备上做双向重分发。这里有几个坑必须提前防：

第一个坑是度量不可比。OSPF 的 cost 和 RIP 的跳数是两套完全不同的尺度，重分发的时候不能自动映射，必须手工指定种子度量。把 RIP 重分发进 OSPF 时，如果不指定，默认 cost 是 20；把 OSPF 重分发进 RIP 时，如果不指定，默认跳数是无穷大（也就是不重分发），这条路由直接丢失。所以必须显式写：

router ospf 1 redistribute rip subnets metric 100 metric-type 2 ! router rip version 2 redistribute ospf 1 metric 3

subnets这个关键字千万别漏，漏了之后所有子网路由都不会被重分发进去，只重分发有类主网路由，这是新手最常踩的一个坑。

第二个坑是路由回环。A 协议的路由重分发进 B，B 又重分发回 A，如果不加控制，一条路由会在两个协议之间来回弹跳，度量越滚越大。解决办法是用 route-map 打标签（tag），重分发进来的时候打上标记，往回重分发的时候把带标记的过滤掉：

route-map FROM_RIP deny 10 match tag 100 route-map FROM_RIP permit 20 set tag 200 ! router ospf 1 redistribute rip subnets route-map FROM_RIP

第三个坑是管理距离（优先级）。同一台设备从两个协议学到同一条路由时，靠管理距离决定信谁。默认值通常是：直连 0、静态 1、OSPF 110、RIP 120。数字小的优先。这个顺序意味着 OSPF 总是压过 RIP，如果实际希望走 RIP 那边，就必须手工调管理距离，但这会引入新的不一致风险，改之前想清楚。

5. 排障实录：这些状态和日志到底在说什么

配置敲完不通，这时候最忌讳的是瞎改。我的习惯是先看现象归类，再按层级往下钻：先看邻居状态，再看数据库，最后看路由表，一层一层排除。

5.1 RIP 的常见故障速查

有一个细节值得单独说：RIP 的组播地址 224.0.0.9 是链路本地范围的，不会被路由转发，所以不存在"跨网段收到 RIP 更新"这种情况。如果抓包发现 Hello 类报文跨越了路由器，那一定是配置或者网络结构有问题。

5.2 OSPF 邻居卡在某个状态怎么查

这是 OSPF 排障的核心场景，我把常见状态和处理方式整理成一张表，遇到问题直接对号入座：

排障的时候我会按这个顺序敲命令，基本能定位到 90% 的问题：

show ip ospf neighbor ! 邻居状态和状态持续时长 show ip ospf interface brief ! 各接口的区域、开销、网络类型 show ip ospf interface GigabitEthernet0/0 ! 详细参数，包括定时器和 MTU show ip ospf database ! LSDB 概览，看各类 LSA 数量 show ip ospf database router 10.0.0.1 ! 看某台设备的 Type 1 明细 show ip ospf ! 当前 SPF 跑了多少次，最后运行时间

show ip ospf这条命令里的 SPF 运行次数很能说明问题。如果这个数字在短时间内快速增长，说明网络里有持续的拓扑震荡，得回头查链路稳定性，而不是纠结路由为什么不对。

5.3 路由有了但不通：往上一层查

邻居 Full、路由表里有条目、但 ping 不通，这时候问题已经不在路由协议层了，得往上走。我遇到过的情况大致这么几类：

第一类是单向路由。A 能到 B，B 回不来，ping 通才怪。用traceroute从两端各跑一次，对比路径，哪一端断了一目了然。这类问题在重分发边界上特别常见，因为重分发配置往往是单向写的，写了一半忘了另一半。

第二类是ACL 或防火墙拦截。路由协议本身跑在组播或者特定端口上，业务流量走的是另一套规则，路由通了不代表业务通。查的时候要区分"控制面通"和"数据面通"。

第三类是区域间次优路径导致的非对称转发。去程走区域 0 中转，回程走另一条路，两端的状态检测设备看到半连接就丢了。这类问题最隐蔽，得靠抓包看双向路径才能确认。

实操心得：排障的时候一定要养成"先确认现状再动手"的习惯。看到不通就急着改配置，很可能把原本正确的部分改坏了，最后问题越查越多。我的做法是先把当前的邻居表、路由表、接口状态全部导出存档，改一处验一处，出问题能立刻回退。

我在实际环境里踩过最深的一个坑，是在做区域间汇总的时候把汇总掩码写错了，本来应该是 /16 写成了 /24，结果区域内的明细路由被汇总条目覆盖，一部分网段直接黑洞。当时邻居全是 Full、数据库也正常，就是部分地址不通，查了很久才想到去看汇总配置。从那之后我形成了一个习惯：任何汇总配置上线前，先在一个网段上验证，确认汇总后的覆盖范围完全包含原有的明细，一条不多一条不少，再推广到全网。汇总本质上是做"信息压缩"，压缩必然有损，损掉的那部分如果正好是有用的，故障排查的难度会成倍上升，因为它不报错、不掉邻居，只是悄悄地把流量引到不存在的地方。

另外一个想分享的经验是关于参考带宽的。我在一个多厂商设备混跑的环境里遇到过，一部分设备默认参考带宽是 100M，另一部分出厂就设成了 10G，两边对同一条千兆链路的开销算出 1 和 10，结果流量全往一侧压，另一侧链路长期闲着。这个问题光看路由表看不出来，得逐台show ip ospf interface对比开销值才能发现。所以现在我做任何 OSPF 部署，第一步都是把所有设备的参考带宽统一写死，不依赖出厂默认值，这个动作花不了两分钟，能省掉后面几天的排查。

至于 RIP，最后再说一句实在话：如果今天要从零设计一个网络，我大概率不会选它。但如果接手的是一个已经跑了十几年的老网络，里面还有几台低端设备撑着边缘接入，那么在不动大结构的前提下，把 RIPv1 升到 RIPv2、把自动汇总关掉、把不需要跑协议的接口静默掉，这三件事做完就能消掉大部分莫名其妙的故障，成本极低，收益很直接。技术选型这件事，合适永远比先进重要。