网络改造收尾那几天我盯着一台区域边界设备刷了半宿的日志邻居关系全 Full链路一条没断偏偏某一段办公楼的网段在另外几个区域里怎么都看不到。抓包、看接口、查掩码折腾了两个小时才把矛头指向一句话区域间那条本该存在的汇总通告压根没生成。那一刻我特别想跟刚接触这套协议的新人说一句——邻居起得来只代表双方能聊天LSA 达不达得到该去的地方才代表路由能不能算出来。这篇内容就围绕 LSA 这个核心命题展开把不同类型的 LSA 分别管什么、为什么必须由某类设备产生、它们之间是怎么层层接力拼出一张可用拓扑的一层一层拆开讲。关键词就一个方向LSA 类型与作用域。内容偏实战适合已经能配出邻居关系、但一遇到“路由缺失”“路由次优”“双点重分发环路”就卡壳的朋友纯小白也能看懂因为我会把每个字段的用途都翻译成人话。1. 先把 LSA 的定位讲透否则后面全是死记硬背1.1 为什么这套协议要用“链路状态”而不是“距离矢量”要理解 LSALink State Advertisement链路状态通告得先理解它服务的算法。新一代网络工程师很容易把 LSA 当成“另一种路由更新包”这个理解会带来一堆错误。距离矢量协议传的是“我到 X 网段的距离是多少”收到消息的设备只是把数字加一然后再传出去全程没见过完整地图所以天生会出环路、天生收敛慢。链路状态这套模型反过来每台设备把自己身上有几条接口、连着谁、网段掩码多少、开销多大打包成一条通告泛洪出去所有人把收到的碎片攒在本地数据库里攒齐之后各自用 SPF 算法算出一棵树。LSA 不是“路由更新”它是“原始情报”路由是每台设备拿情报自己算的结论。这个区别至关重要因为它决定了排查思路。距离矢量协议出问题要问“谁没把更新传给你”链路状态协议出问题要问“你的数据库里缺了哪张卡片还是卡片有了但算法没用它”。我在现场遇到过太多次“路由表里没有某个网段”配置查了三遍都对最后一条show命令打开数据库一看那块地方的条目压根没进数据库——问题根本不在计算而在通告的传播环节。所以把 LSA 想成情报卡更贴切。每张卡有固定格式的卡头写着“我是谁发的”“我是第几版”“我有多新”卡身才是内容。每台路由器收到卡后先比卡头版本旧了直接丢弃与已有的一致就回个确认没见过就存档并继续转发给邻居。整张地图就是这样一张卡一张卡堆出来的。1.2 一张 LSA 的“身份证”由哪三个字段决定这是很多人记不清但极其关键的一点。路由器区分两张 LSA 是否“同一张”看的不是内容而是三个字段的组合LS Type类型、Link State ID链路状态标识、Advertising Router通告者。三者合起来构成全球唯一标识缺一不可。为什么会这样设计因为同一个通告者可能发很多张同类型卡比如一台有二十个接口的路由器只发一条 Type 1但区域边界设备可能发几十条 Type 3每条描述一个不同的网段。靠 Link State ID 区分具体对象靠 Advertising Router 区分来源靠 Type 区分语义。同一个 Type、同一个 Link State ID、但不同通告者产生的那是两条不同的 LSA数据库里是并存的两条。这个细节在双点重分发场景里非常致命两台边界设备同时把同一条外部路由引进来数据库里就会出现两条看上去“重复”的条目而路由表里到底选哪条取决于外部开销和转发地址的比较。除了这三个身份字段还有个“版本号”体系要记住LS Sequence Number、LS Age、LS Checksum三者共同判断新旧。序列号从初始值开始线性递增数值越大越新老化时间表示这条卡在数据库里躺了多久正常刷新周期是 1800 秒超过 3600 秒就判定失效并删除。现场经常出现的一种怪现象是“一条路由消失了又出现反复抖动”多半是序列号空间被耗尽的迹象那条 LSA 被提前老化又重新以初始序列号生成这种问题光看路由表永远看不出来必须看数据库里那条记录的序列号有没有反复回环。1.3 泛洪域是怎么把 LSA 分成“本地货”和“进口货”的LSA 的传播边界跟区域强绑定这是理解整套体系的主线。我习惯用一个比喻骨干区域是中心仓库普通区域是分店分店内部的货架摆放Type 1、Type 2只有本店员工关心压根不需要贴到别的分店墙上分店之间要交换的只是“我这里有什么货”Type 3至于从体系外部采购进来的东西Type 5得单独贴一张总表。谁负责把本地货翻译成对外通告谁来当这个翻译官就是各类 LSA 存在的根本理由。类型名称产生者泛洪范围主要职责Type 1路由器 LSA区域内每台设备单个区域描述本机接口与链路Type 2网络 LSADR单个区域描述广播网段的成员Type 3汇总 LSAABR单个区域向区域内注入描述区域间网段Type 4ASBR 汇总 LSAABR单个区域指出外部引入者位置Type 5外部 LSAASBR整个自治系统描述外部路由Type 7NSSA 外部 LSANSSA 内 ASBR单个 NSSA 区域受限环境下的外部通告这张表我建议先背下来但更重要的是理解每一行的“产生者”和“范围”为什么必须这么限定。Type 1 只能在本区域因为跨区域传原始链路信息会导致 SPF 计算范围无限膨胀一个大型网络几千条链路全塞进一棵树谁都算不动Type 3 只能由 ABR 产生因为只有 ABR 同时握着两个区域的信息有资格做“翻译”Type 5 由 ASBR 产生并全网泛洪因为外部路由的目的地在体系之外任何区域都需要知道怎么出去。把这些“为什么”想通剩下就是细节。2. 六类 LSA 逐个拆开看清楚每张卡在说什么2.1 Type 1每台设备的自拍照SPF 计算的唯一原料Type 1 是整套体系的基石每台设备在区域内有且仅有一条Link State ID 就是自己的 Router ID通告者也是自己。内容是一串“链路描述”每条描述都带四个参数链路类型、链路标识、链路数据、链路开销。链路类型有四种我直接列出来这个表在现场翻数据库的时候用得最多链路类型名称链路标识含义链路数据含义典型场景1点到点邻居的 Router ID本接口地址或接口索引两台设备直连2传输网络DR 的接口地址本接口地址广播网段上非 DR 的设备3末梢网络网段地址网段掩码直连业务网段4虚连接虚连接对端 Router ID本接口地址骨干区域逻辑补全这里有个新手最容易栽的坑只有类型 3 的末梢网络条目才会直接产生直连路由。类型 1 和类型 2 描述的是设备之间怎么连不产生网段路由。所以在广播网段上如果两台设备之间只互相描述了“点到点”关系没有描述末梢网段你看路由表会发现网段没出来原因就在这里。我见过有人手工调整接口类型后忘了恢复本来该是传输网络的段被当成了点到点结果同网段的另外几台设备直接连不上。另一个容易被忽略的字段是能力位。Type 1 里有 E 位和 B 位E 位表示“我是外部引入者”B 位表示“我是区域边界设备”。这两个位就是 Type 4 和 Type 3 存在的前提——区域内的其他设备靠这两个位知道区域里有没有翻译官。一旦某台 ABR 的 B 位因为配置问题没能正确置位本区域内部的路由照常但跨区域路由全线失效而且邻居关系一切正常非常难发现。还有开销字段。每条链路的开销跟接口带宽挂钩全网所有设备都得用同一套换算标准否则算出来的路径会莫名其妙。我在一个多厂商设备混跑的环境里吃过这个亏不同实现对默认开销的取值方式不一样同一个千兆口一边算 1 一边算 10结果流量全部走了一条实际带宽更小的备线而且从路由表看“开销更小”的逻辑天衣无缝。后来统一在每个接口上显式写死开销值才彻底稳住。2.2 Type 2广播网段的“发言人”解决 N 方关系爆炸为什么需要 Type 2这是很多人的疑问。在一个有十台设备的广播网段上如果只靠 Type 1每台设备都得描述“我和其他九台的连接”十条链路描述乘以十台设备数据库里就是一百条条目冗余得离谱。而且每台设备之间是否真能直达靠这种描述根本判断不准。解决方案是选举选一个指定路由器DR当发言人网段上所有设备只跟 DR 建立完全邻接非 DR 之间停留在双向状态。于是每台非 DR 的 Type 1 里只需要一条“传输网络”类型的链路指向 DR 的接口地址DR 则发一条 Type 2Link State ID 是自己的接口地址内容很简单——网段掩码加上所有完全邻接成员的 Router ID 列表。这条 LSA 的作用就是让所有人知道“这个网段上有谁”。SPF 计算时设备会先通过 Type 1 找到自己到 DR 的连接再通过 Type 2 得知网段上的其他成员从而算出经过 DR 到达其他成员的路径。注意这里的计算开销非 DR 之间互相访问开销是各自到 DR 的开销之和而不是零。这一点解释了一个长期存在的现场困惑——同网段两台设备互 ping 延迟比直连理论值高一点点有时还出现绕行根因就在这里。注意网段上只有一台设备时它仍然会被选为 DR但它不发 Type 2因为 Type 1 里的末梢网络条目已经足够描述这个网段。初学者翻数据库看不到 Type 2 就开始怀疑配置其实是正常现象。DR 选举本身有一套规则优先级高的当优先级相同比 Router ID且有抢占延迟不会立刻抢占这块我在第 4 节用实验演示。这里先记住结论Type 2 只会由 DR 产生非 DR 一条都不发少数特殊网段类型例外。所以换个角度看某网段上数据库里出现两条 Type 2、通告者不同说明那里曾经发生过 DR 变更只是旧的那条还没老化掉。2.3 Type 3区域之间的外交官本质上是距离矢量行为Type 3 是 ABR 产生的用来告诉其他区域“我这里能到某个网段距离我有多远”。关键点务必记牢它携带的开销是 ABR 自己到目的网段的开销不含接收方到 ABR 的那一段。接收方收到后会把这个开销加上自己到 ABR 的开销得到总开销。这种“只报自己这一段的距离让对端累加”的做法是典型的距离矢量思路。这就引出一个非常重要但常被忽略的结论这套协议在区域之间并不是纯粹的链路状态而是退化成了距离矢量行为。这也是为什么规范要求所有普通区域必须与骨干区域直接相连形成星型结构。如果允许区域之间随意互连距离矢量的环路问题就会原封不动地搬进来。有些现场为了“优化路径”硬把两个普通区域直连起来还配了虚连接补全网状短期看着能通长期一旦某条链路抖动路由环路和次优路径就全出来了。还有一条铁律必须记ABR 只从骨干区域学习区域间路由用在计算上从普通区域收到的 Type 3 只保存不用于计算也不向其他普通区域转发。这条规则就是区域间水平分割专门用来堵环路。我在现场排查过一例“某个网段明明有通告却进不了路由表”最后发现那台设备是非骨干区域的 ABR它从侧边收到的 Type 3 因为这条规则被丢弃了。Type 3 还有个常见变体默认路由。完全末梢区域里ABR 会向区域内注入一条目的为全零的 Type 3把区域内所有的出区流量都指向自己。这条默认路由的 Link State ID 是全零网段通告者是 ABR跟普通的 Type 3 结构完全一样只是语义特殊。理解这一点就能解释“为什么完全末梢区域里的路由表特别短但外网照样通”。2.4 Type 4专门给外部引入者指路的那张卡Type 4 的处理对象是 ASBR 的位置。为什么需要它因为 Type 5 只说了“某个外部网段挂在某台 ASBR 后面”但没说你该怎么去那台 ASBR。如果 ASBR 和你在同一个区域区域内的 Type 1 已经包含了它压根不需要 Type 4一旦 ASBR 在别的区域你就需要一张专门的地图指向它这就是 Type 4 的全部职责。它的格式特别容易和 Type 1 混Link State ID 就是 ASBR 的 Router ID通告者是 ABR。初看数据库的人经常把 Type 4 当成 Type 1 的重复条目因为两者的标识字段一模一样。区分方法只有一个——看 LS Type 字段。Type 1 的通告者等于标识本身自拍Type 4 的通告者是 ABR他拍。一个反向推导技巧很实用你在数据库里看到某台设备的 Type 1 里 E 位被置位说明它自报是 ASBR但在其他区域里你看到的 Type 4 里指向的那个 Router ID必须和那台 ASBR 的 Router ID 完全一致。如果两边对不上通常是 Router ID 手工配置不一致或者重分发域内路由导致的“伪 E 位”后者是很多莫名其妙故障的源头——设备被误认为外部引入者周边设备为它生成 Type 4然后为了到达它而算出一些根本不该存在的路径。2.5 Type 5外部路由的总表E1 和 E2 差在哪Type 5 由 ASBR 产生泛洪范围是整个自治系统但末梢区域和 NSSA 区域除外。它的核心内容是外部目的网段、外部开销、开销类型E1 或 E2、转发地址、路由标记。这几个字段决定了很多现场问题。E1 和 E2 的区别是面试常客但真正在运维中理解它的人不多。E1 在计算时会把外部开销和内部到达 ASBR 的开销累加等于把外部网段当成自家网段一样参与选路E2 只比较外部开销不累加内部开销。默认是 E2这也解释了一个现象同一个外部网段从两条不同路径引入外部开销配成一样此时路由表的选择取决于到 ASBR 的内部开销——虽然 E2 不把内部开销计入度量但当外部开销打平时仍会用内部开销做打破平局。这个细节量不少资料都没写清楚我在一次多点引入选址实验里验证过。转发地址是另一个深坑。当地址为 0 时说明“要到达这个外部网段必须经过我这个 ASBR”当它非 0 时说明“这个外部网段其实可以从那个地址直达不必绕我”。后者在双出口环境里非常有用可以让流量直接走另一条路径进核心而不是绕回 ASBR。但前提是那个转发地址必须被内部路由覆盖否则整条外部路由会被直接丢弃因为它无法判断怎么过去。我遇到过一次“外部路由存在但路由表里没有”查了半天是转发地址所在网段被汇总掉了覆盖不到整批路由集体失效。路由标记是纯管理字段不参与选路但它的价值在路由策略里。多台边界设备双向引入时用标记识别“这条路由是我的邻居引入进来的”再配过滤规则拒绝回灌能干净地切断环路。这比单纯靠开销值打压制要稳得多。2.6 Type 7受限区域里的变通方案P 位是它的命门NSSA 区域的设计初衷是“我不想接收外部路由但我自己需要引入外部路由”。这就出现矛盾外部路由由 Type 5 承载可这个区域偏偏不允许 Type 5 进来。解决办法就是专为它设计一个 Type 7格式跟 Type 5 几乎完全一样但只在本区域泛洪不跨区。那区域外的设备怎么知道这些外部路由靠 ABR 做转换ABR 收到 Type 7 后把它翻译成 Type 5 再向其他区域泛洪。翻译的开关就是 P 位Propagate传播位它藏在 Type 7 的选项字段里。P 位为 1 才翻译为 0 就留在本区域自娱自乐。这个位最典型的用途是“只给本区域用的特殊路由”比如某台设备引进来一条仅供本地使用的管理网段不希望它污染整个网络把 P 位置 0 就行。转换过程里还有个非常讲究的处理如果原 Type 7 的转发地址是 0ABR 在转换时会用自己的接口地址填充转发地址避免其他区域的流量先绕到 ASBR 再折回来造成次优。如果原 Type 7 的转发地址非 0那就原样保留前提是那个地址在其他区域也可见。这两种情况在数据库里看起来差别微妙实际路径可能差好几跳我在一个双出口机房里量过绕行和直连的时延差别接近一倍。提示NSSA 区域内不要同时存在多台 ABR 都做转换否则同一条外部路由会有多条 Type 5 并存在数据库里。这种情况下路由选择依赖外部开销和转发地址比较容易产生次优路径。常见做法是只让一台 ABR 承担转换或者用 Router ID 大小来协调选举。3. 它们之间怎么接力还原一次端到端的计算全过程3.1 数据库同步为什么只交换卡头先把“为什么邻居起来之后数据库能一致”这件事说清楚。两台设备建立邻接时中间会经过一个交换阶段这个阶段双方互发的报文中只包含 LSA 的头部信息——类型、标识、通告者、序列号不包含内容本体。为什么要这样设计因为内容可能很大而绝大多数情况下两边的数据库是一致的只需要比对身份和版本。比对下来如果对方有一条我没有、或者对方的版本更新我才在后续阶段用专门的请求和更新报文把完整内容拉过来。这个设计节省了大量带宽也是整套协议能在大网络上稳定运行的重要原因。所以现场排查“数据库不一致”第一步不是抓完整报文而是看头部比对是否正常完成。如果对方一直卡在交换阶段通常是最大传输单元不一致导致的双方对报文大小的期待不同反复重传却收不到回应。这种情况在跨设备、跨厂商互通时特别常见现象是邻居关系反复在一个中间状态来回跳路由一直学不过来。3.2 SPF 树只吃 Type 1 和 Type 2这里要点破一个认知误区很多人以为 SPF 计算用上了所有 LSA其实不是。真正的 SPF 计算只使用本区域的 Type 1 和 Type 2算出来是一棵区域内最短路树。Type 3、Type 4、Type 5 都是在这棵树搭好之后作为“叶子节点”或“附加路由”追加进去的它们不参与树的构建。这个分工解释了很多现象。为什么区域内路由收敛快、区域间收敛慢因为区域内一旦有链路变化Type 1 更新触发重新算树几秒钟就能完成而区域间的 Type 3 需要 ABR 重新生成、泛洪、对端再追加链路更长。为什么某个区域内部环路不会直接影响另一个区域因为树是各算各的边界上由 ABR 做隔离。理解这一点之后排查思路就清晰了。路由表里区域内的网段缺失去查 Type 1 和 Type 2区域间的网段缺失去查 Type 3 有没有到、通告者是不是正确的 ABR外部网段缺失先查 Type 5 有没有再查有没有对应的 Type 4或者区域内有没有到 ASBR 的条目。这三层递进关系是我最常用的排障骨架。3.3 从最末端设备到外部目的地的一次完整推演假设一个场景某普通区域里的一台接入设备要访问一个外部网段。它的数据库里会有哪些东西先看本区域自己和其他设备的 Type 1广播网段的 Type 2构成区域的完整拓扑SPF 算出到本区域边界设备的路径。然后看区域间ABR 注入的 Type 3描述骨干区域和其他区域的网段以及一条 Type 4 指向那台外部引入者。最后看外部ASBR 产生的 Type 5描述目的网段、开销、转发地址。计算过程是这样的先用 SPF 树算出到 ABR 的开销加上 Type 3 里携带的开销得到区域间路由再用 SPF 树算出到 ASBR 的开销如果 ASBR 不在本区域则是到 ABR 的开销加上 Type 4 里携带的开销加上 Type 5 里的外部开销E1 情况得到外部路由如果外部开销类型是 E2则直接使用外部开销仅在平局时才比较内部那一段。把这条链路走通你就明白为什么“邻居全满但路由不全”几乎必然出在 Type 3、Type 4、Type 5 这三个环节。它们不像 Type 1 那样由本地设备天然生成而是依赖角色设备ABR、ASBR主动产生一旦角色没建立、能力位没置上、或者区域类型不匹配通告就不会出现。我在现场最常用的判断方法是在 ABR 上查数据库看它有没有为对端区域生成对应的 Type 3在对端设备上查看它有没有收到。如果 ABR 上都没有问题在产生端如果 ABR 上有但对端没有问题在传播端通常是区域类型或过滤策略。4. 动手验证几组实验把 LSA 的边界条件试出来4.1 实验拓扑与基础配置讲理论不如自己搭一遍。我常用的最小实验拓扑是三台设备串成一条线中间那台同时属于两个区域充当区域边界角色再在末端挂一台设备做外部引入。这样能同时观察 Type 1、2、3、4、5 的产生和传播。配置片段示意如下具体语法各实现略有差异思路是一致的! 中间设备区域边界角色 router ospf 1 router-id 10.0.0.2 network 10.0.0.0 0.0.0.255 area 0 network 10.0.1.0 0.0.0.255 area 1 ! ! 末端设备外部引入角色 router ospf 1 router-id 10.0.0.3 network 10.0.1.0 0.0.0.255 area 1 redistribute static subnets ! ip route 172.16.0.0 255.255.0.0 192.168.1.1配完之后第一件事不是看路由表而是看数据库。数据库里的条目数量、每条的类型和通告者才是判断“通告有没有产生、有没有传到位”的直接证据。我的习惯是先在被观察设备上把数据库完整拉一遍再逐个区域核对比凭路由表反推高效得多。4.2 观察 Type 1 和 Type 2 怎么随网段类型变化把两台设备之间的接口从广播类型改成点到点类型然后再看数据库你会发现那个网段的 Type 2 消失了取而代之的是两台设备各自的 Type 1 里出现了“点到点”类型的链路描述指向对端的 Router ID。这个变化非常直观地说明了 Type 2 存在的意义它只是广播网段这种“一对多”拓扑的压缩表达拓扑变了表达方式就变了。再看路由表的变化。改成点到点之后网段路由依然存在因为 Type 1 里新出现了末梢网络条目描述这个网段。但如果你只改了其中一端另一端还认为是广播类型两边对拓扑的认知就分裂了一端发 Type 2一端发点到点描述邻居关系可能还能维持但路由计算结果会完全错乱。这个坑我踩过原因是模板批量下发时漏了一台最后表现为“部分网段可通、部分不通”排查成本极高。4.3 观察 Type 3 的产生条件和过滤效果在区域边界角色上把某个网段从区域 0 里摘掉再挂到区域 1观察另一端数据库里的 Type 3 变化。正常情况下只要有网段从一个区域出现在另一个区域的通告里就应该看到对应的 Type 3通告者是边界角色的 Router IDLink State ID 是网段地址。然后做过滤实验在边界角色上配置对某个网段的区域间过滤再看对端数据库。过滤生效的层级是“不产生或不泛洪”而不是“产生了但不计算”这一点很多人搞错。结果是那台设备数据库里对应的 Type 3 直接消失路由表里那条路由也随之消失但区域内的 Type 1 完全不受影响。如果你配置了过滤却发现对端数据库里还有条目说明过滤没生效或者加错了方向。还有一个容易混淆的场景完全末梢区域。把某个区域配成完全末梢之后区域内的设备数据库里除了 Type 1、2 和一条默认的 Type 3其余的 Type 3 全部消失。这个效果是 ABR 主动过滤产生的不是设备自身行为。我在一个现场遇到“某个区域里怎么突然看不到明细路由了”追溯下来是前人把区域类型改成了完全末梢配置注释都没留接手的人一头雾水。4.4 观察 Type 5 和 Type 7 的互相转换在普通区域里做外部引入看数据库会有 Type 5通告者是引入者的 Router ID同时在其他区域里会出现指向它的 Type 4。然后把那个区域改成 NSSA 类型再看Type 5 消失取而代之的是 Type 7直接由区域内的引入者产生泛洪范围被限制在区域内。此时区域外的设备数据库里会出现由 ABR 转换出来的 Type 5通告者是 ABR 而不是原始引入者。这个转换过程里要重点观察两件事P 位有没有置上、转发地址是怎么填的。如果 P 位为 0区域外就完全看不到这条外部路由如果转发地址被填成 ABR 自己的地址说明原始通告里转发地址是 0。把这两种情况都试一遍你会对“为什么有些外部路由会绕路”有直观认识。提示做这类实验时务必先把数据库清空或重启进程因为 LSA 有老化周期旧条目可能残留十几分钟看起来像是“配置没生效”。用数据库里的老化时间字段确认条目是新鲜的还是残留的能省掉大量自我怀疑。5. 踩坑记录与速查思路5.1 常见现象与对应方向的速查表现象优先怀疑核查方向邻居停在双向状态广播网段非 DR 设备之间正常确认是否需要完全邻接邻居在交换阶段反复跳最大传输单元不一致两端接口参数是否一致区域内网段缺失Type 1 末梢网络条目未生成接口掩码、类型是否被改区域间网段缺失Type 3 未产生或被过滤边界角色是否存在、区域类型外部路由有但不通转发地址无法覆盖内部是否有到转发地址的路由外部路由时有时无序列号反复、双点来源冲突数据库序列号、通告者数量同一外部网段两条条目多点引入未做区分外部开销、标记、过滤策略这张表我建议打印贴在工位上比翻手册快得多。但要提醒一句表里给的是“方向”不是“结论”每条都还需要实际打开数据库确认。5.2 三个我印象最深的坑第一个坑是“区域类型不匹配静默失效”。两个区域边界设备对同一个区域的类型认知不一致一个认为是普通区域一个认为是末梢区域邻居能起来区域内路由正常但外部路由在两台设备上表现完全不同。这种问题没有任何报错只能靠核对配置发现。我现在的习惯是每台边界设备的区域类型配置单独记录一遍改完必须对账。第二个坑是“双点双向引入的回灌”。两台边界设备互相引入对方学来的路由如果不加标记和过滤一条外部路由会在两边来回被引入度量值越变越小最后形成环路。解决思路是做标记然后在引入时按标记拒绝或者用路由映射做单向引入。纯粹靠调整开销值打压制短期能用但一旦外部拓扑变化又会复发。第三个坑是“汇总掩码算错”。区域间汇总时如果掩码范围没覆盖住所有明细网段一部分网段会在某个方向上凭空消失另一部分还能通。这类问题最迷惑人因为不是全通也不是全不通。经验做法是汇总前先列出所有明细网段算好最小覆盖范围并且要意识到汇总只会影响通告不会影响本地路由表本地照样能看到明细对端才看不到。5.3 我平时看数据库的几个习惯第一永远先看类型分布再看具体内容。一个区域的数据库里 Type 1 的数量应该等于该区域内设备数量每台一条Type 2 的数量应该等于有完全邻接成员的广播网段数。数量对不上先查数量而不是逐条比对内容。第二养成核对通告者的习惯。同一条 Type 3通告者不同意味着来源不同这对判断“路由是不是从正确的边界设备来的”极其关键。遇到过太多次“路由能通但绕了远路”最后发现是另一台边界设备也发了同样的通告而对端恰好选了那一条。第三关注老化时间。老化时间接近最大值3600 秒的条目意味着它即将被清除可能是设备已经不再刷新这条通告了。这在排查“路由马上要消失”的预警场景里很有用比等它消失了再查要主动得多。第四改动前先存一份数据库快照。很多问题的成因是“改动之前就存在”没有基线对比根本说不清是自己改坏还是本来如此。这个习惯我用了很多年收益远超投入。最后分享一个实操体会。刚接触这套体系时我总想找一张完美的对照表把所有类型、字段、场景一一对应上然后背下来。后来发现真正让人从“会配”变成“会排”的不是记住有多少种类型而是脑子里有一张“谁负责产生、传播范围到哪、接收方怎么用”的三段式流程。任何一条路由异常都按这三段走一遍绝大多数问题在第二段就能定位。至于那些字段细节用一次查一次自然就记住了硬背反而记不牢。