做网络这一行，凡是正经学过路由交换的，几乎都绕不开OSPF。但说实话，很多人做OSPF实验就是照着教程敲一遍命令，邻居起来了，路由学到了，就觉得完事了。等真到了项目上，拓扑一复杂，区域一多，各种奇奇怪怪的问题就冒出来了。这篇文章我不打算复述一遍命令手册，而是从一次完整的OSPF实验出发，把从规划、配置到排错的全过程掰开揉碎讲清楚。实验虽然是在模拟器里做的，但里面涉及的区域设计、参数调整、故障排查思路，放到真实企业网里一样适用。无论你是刚接触动态路由的新手，还是想补一补OSPF细节的老手，这篇内容应该都能给你一些参考。
1. 实验背景与目标设定
1.1 场景需求拆解
这次的实验背景设定成了一个典型的中型园区网络。整个网络按照功能划分为三个区域：核心区、办公区、服务器区。网络设备包括核心路由器、区域边界路由器、接入交换机（三层）和一台模拟外部网络的设备。业务需求是让所有区域之间能够互访，同时要求核心链路故障时能够快速切换到备用路径，整个网络不能出现环路和路由黑洞。
为什么选OSPF而不是RIP或者静态路由？原因很现实。RIP的收敛速度太慢，跳数限制又卡死了网络规模，现在稍微正规点的项目都不会拿它做核心路由协议。静态路由在小型网络里确实又稳又简单，但一旦拓扑出现冗余链路，静态路由的维护成本会成倍上升，新增一个网段就要跑到所有路由器上手动加一条。OSPF作为链路状态协议，每一台路由器都维护着全网的拓扑信息，通过SPF算法独立计算最优路径，既保证了无环，又能在链路状态变化时快速收敛。更重要的是，OSPF支持区域划分，把大型网络拆成多个区域后，可以显著减少链路状态数据库（LSDB）的规模，降低路由器CPU和内存的消耗。这种特性让它成为中大型网络的事实标准。
1.2 实验目标与验收标准
在动手敲配置之前，我先把这次实验的目标和验收标准列出来，避免做实验做到一半方向跑偏。
实验目标很明确：第一，完成OSPF多区域的基础部署，确保全网路由互通；第二，验证OSPF在不同网络类型下的邻居建立和DR/BDR选举机制；第三，调整HELLO计时器和认证配置，加强协议的安全性与收敛速度；第四，设计故障场景，验证路由切换和问题排查方法。
验收标准则包括：所有直连接口互通、ospf邻居状态稳定在Full、全网路由表完整且无路由环路、拔掉一条核心链路后在指定时间内完成路由收敛。为了量化标准，我们把收敛时间控制在10秒以内（包括故障感知和SPF重计算时间），这是一个比较务实的目标——真实项目里一般会根据SLA要求设定，有些核心网络甚至要求亚秒级收敛，但那需要依赖BFD等联动技术，不在这次实验范围内。
2. 实验环境准备与拓扑设计
2.1 设备选型与模拟环境搭建
我用的是模拟器环境，设备选型没有纠结太多，统一采用支持OSPFv2的设备镜像，所有设备的软件版本保持一致，避免因版本差异导致命令兼容性问题。在模拟器里规划了6台路由设备（R1到R6）和若干台PC终端。路由器之间通过千兆以太网口互联，同时设置了环回口（Loopback）来模拟业务网段和管理地址。
在实际项目中，设备选型要多考虑一个因素：硬件资源与OSPF进程的匹配。OSPF是非常吃CPU和内存的协议，尤其是区域边界路由器和ASBR，它们要维护的区域间路由和外部路由会消耗大量资源。如果设备转发能力很强但控制面性能不足，大流量场景下可能触发路由震荡。所以在真实环境里，核心设备建议选用控制面处理能力强的型号，而不是只看背板带宽和端口密度。
模拟器的选择上，我个人比较习惯用GNS3，原因在于它可以直接运行真实设备镜像，命令和真实设备完全一致，实验过程中的排错经验可以无缝迁移到生产环境。用模拟器还有一个好处：可以随时随地保存和恢复快照。我在每个关键阶段都会拍一个快照——基础配置完成存一个，多区域配置完成存一个，排错前后各存一个。这样万一操作失误导致全网断开，也不需要从头再敲一遍，恢复快照即可。
2.2 地址规划与区域架构设计
地址规划是实验中最容易被忽视但最重要的环节。好的规划能让后续排查事半功倍，甚至可以从IP地址直接判断出路由的来源区域和业务属性。
我采用了比较规范的规划方式。所有设备之间的互联网段使用10.0.xy.0/30的子网掩码——x和y分别代表互连的两台路由器编号，这样看到网段10.0.12.0/30就知道是R1和R2之间的链路，非常直观。回环口地址统一采用10.255.x.x/32的形式，x对应路由器编号，这样Router ID可以不额外配置，直接取回环口地址（最大回环口地址），既稳定又容易识别。业务网段按照区域统一规划，办公区使用192.168.10.0/24和192.168.20.0/24，服务器区使用172.16.10.0/24和172.16.20.0/24，每个网段的第三位表示区域归属，方便后期做路由汇总和策略控制。
区域架构方面，Area 0设计为核心区域，连接R1、R2、R3三台路由器，形成物理和逻辑上的双核心。Area 1接入办公区，通过R4作为区域边界路由器与骨干区域相连。Area 2接入服务器区，通过R5作为区域边界路由器接入。R6模拟外部网络，连接到R5上，用于验证外部路由的引入与传播。这种设计遵循了OSPF的强制性要求：所有非骨干区域必须直接连接到Area 0，否则区域间路由无法正常传播。如果某个非骨干区域无法物理连接到骨干区域，就必须配置虚链路（Virtual Link）来逻辑连接，但那属于特殊情况，而且虚链路本身不推荐长期使用，只能在过渡方案中临时顶一下。
区域划分表如下：
| 路由器 | 所在区域 | 回环口 | 主要作用 |
|---|---|---|---|
| R1 | Area 0 | 10.255.1.1/32 | 核心路由，连接R2、R3 |
| R2 | Area 0 | 10.255.2.2/32 | 核心路由，连接R1、R3、R4 |
| R3 | Area 0 | 10.255.3.3/32 | 核心路由，连接R1、R2、R5 |
| R4 | Area 1 | 10.255.4.4/32 | ABR，连接Area 0与Area 1，承载办公网段 |
| R5 | Area 2 | 10.255.5.5/32 | ABR兼ASBR，连接Area 0与Area 2，引入外部路由 |
| R6 | 外部网络 | 10.255.6.6/32 | 模拟外网，运行静态路由或OSPF |
提示：地址规划时尽量给未来扩容留出余地。比如办公网段如果现在只有两个C段，但未来可能要扩到四个，那么汇总时要提前设计成可以聚合的连续地址块。否则后期地址碎片化，OSPF路由汇总做不了，路由表膨胀，排查难度也会直线上升。
3. OSPF核心配置与邻居关系建立
3.1 基础配置：进程、区域与网段通告
配置OSPF的第一步不是敲router命令，而是先把接口IP配好并保证直连互通。我先把所有设备的物理接口和回环口地址都配置完成，再用ping验证直连链路连通性。这一步做好，后面的OSPF排错会轻松很多——至少可以排除底层链路故障。
R1的基础配置如下（以华为VRP为例）：
sysname R1 interface GigabitEthernet0/0/0 ip address 10.0.12.1 255.255.255.252 interface GigabitEthernet0/0/1 ip address 10.0.13.1 255.255.255.252 interface LoopBack0 ip address 10.255.1.1 255.255.255.255 ospf 1 router-id 10.255.1.1 area 0.0.0.0 network 10.0.12.0 0.0.0.3 network 10.0.13.0 0.0.0.3 network 10.255.1.1 0.0.0.0配置里有几个细节值得说明。进程号1在本地有效，邻居两端可以不用一致，只要区域ID、认证等参数匹配即可。router-id 10.255.1.1显式指定，不依赖接口地址自动选举，避免因接口down掉导致Router ID变化而引发邻居震荡。network命令后面的反掩码是通配符，0.0.0.3表示匹配前30位，也就是/30网段。回环口的通告为什么要单独写一条？因为如果不把回环口宣告进OSPF，其他设备就无法学习到这条/32路由，后续如果要基于Loopback地址建立BGP邻居或者做网管监控，就会因为没有路由而失败。
R4作为ABR，配置稍微复杂一点，需要同时加入Area 0和Area 1：
sysname R4 interface GigabitEthernet0/0/0 ip address 10.0.24.4 255.255.255.252 interface GigabitEthernet0/0/1 ip address 10.0.410.4 255.255.255.252 interface LoopBack0 ip address 10.255.4.4 255.255.255.255 ospf 1 router-id 10.255.4.4 area 0.0.0.0 network 10.0.24.0 0.0.0.3 network 10.255.4.4 0.0.0.0 area 0.0.0.1 network 10.0.410.0 0.0.0.3 network 192.168.10.0 0.0.0.255 network 192.168.20.0 0.0.0.255在这里可以看到，同一台路由器的不同接口宣告进了不同区域，这正是ABR的定义。注意区域ID的写法，我使用了带点格式0.0.0.1，也可以用十进制1表示，两者等价，但带点格式在排错时更直观，不至于把Area 1看成其他含义。
配置完成后，在R1上执行display ospf peer brief检查邻居状态，正常情况下每台路由器与直连邻居之间都应该看到Full状态。
3.2 邻居状态机与排错思路
OSPF邻居建立过程是一个状态机，从Down到Full一共经历七个状态：Down、Attempt（非广播多路访问网络特有）、Init、2-Way、Exstart、Exchange、Loading、Full。很多人背过这串状态名，但不知道每个状态卡住意味着什么。我在实验里特意把链路层协议改成不匹配，观察了邻居卡在不同状态的表现，经验如下：
如果邻居一直卡在Init，说明收到了对方的Hello报文，但对方没有收到自己的Hello报文。最常见的原因是区域ID不匹配或者接口认证失败。如果卡在Exstart/Exchange，说明双方在协商主从关系或交换DD报文时出了问题，比如接口MTU不匹配、OSPF网络类型不一致、或者DD报文中的Router ID重复导致选举无法完成。如果卡在Loading，说明路由器在请求链路状态通告时没有收到响应，常见原因是区域间的LSDB不同步，或者某台设备配置了静默接口把OSPF报文过滤掉了。
持续观察OSPF报文是定位问题的关键。在模拟器里可以这样操作：进入接口视图，执行traffic-filter或者直接在路由器上开启抓包，查看Hello报文的内容。真实设备上如果无法抓包，可以通过display ospf error命令查看接口收到的错误报文计数——如果计数持续增长，说明有报文被丢弃，需要结合认证、区域、MTU等参数逐一排查。
注意：很多人在做实验时，邻居状态还没到Full就急着看路由表，这是不对的。邻居稳定在Full只是第一步，接下来还要确认LSDB同步完成，接口上的OSPF开销（cost）合理，再检查路由表有没有学到预期的路由。整个过程要有条理，否则排错时容易顾此失彼。
3.3 DR/BDR选举原理与控制
在广播型网络中（比如以太网多路访问环境），如果每台路由器都与所有其他路由器建立邻接关系，那么链路状态通告的数量会呈指数级增长——n台路由器会产生n(n-1)/2个邻接关系。DR和BDR的引入就是为了解决这个问题：所有路由器只与DR和BDR建立完全邻接关系，DR负责收集和转发链路状态信息，其他路由器之间保持在2-Way状态即可。
实验中我把R1、R2、R3三台路由器接入同一个广播域，通过修改接口优先级来控制DR/BDR选举结果。默认情况下接口优先级是1，优先级最高的路由器成为DR，次高成为BDR。如果优先级相同，则比较Router ID，越大越优先。在OSPF中，DR是不可抢占的——即使后来加入一台优先级更高的路由器，它也不会取代现有DR，除非DR接口down掉重新选举。
控制DR/BDR的最直接方法：
interface GigabitEthernet0/0/0 ospf dr-priority 10想不让某台路由器参与DR/BDR选举，把优先级设为0即可。这个机制在真实网络里有重要意义：核心设备的DR优先级应该调高，避免因DR/BDR选举导致核心链路利用率不均衡。比如两台核心路由器之间做负载分担，如果其中一台是DR、另一台是BDR，那么所有非DR路由器都只与DR建立邻接，BDR只接收但不转发数据，链路利用率就会失衡。解决办法是让两台核心路由器都从DR选举中退出（优先级设为0），让接入层设备之间的某台路由器去当DR，但这需要结合具体拓扑来权衡。
4. 多区域设计与关键机制调优
4.1 多区域配置与路由汇总
多区域是OSPF区别于RIP等距离矢量协议的核心优势。在实验里，R4和R5分别作为Area 1和Area 2的ABR，它们的职责是把自己区域内的路由转换成三类LSA，通告到骨干区域，同时把骨干区域的路由转换成三类LSA，下发给本区域。这种设计把链路状态更新限制在区域内部，任何一个区域内的拓扑变化都不会触发全网所有路由器重新运行SPF算法。
区域归属确定后，路由汇总（Route Summarization）是必须做的优化。我在R4上配置了Area 1的路由汇总：
ospf 1 area 0.0.0.0 abr-summary 192.168.0.0 255.255.252.0注意，华为设备的ABR汇总命令是在area视图下执行的，作用是把该区域内的路由在注入骨干区域时进行聚合。如果办公区网段扩展到了192.168.3.0/24，四段地址可以聚合成192.168.0.0/22，骨干区域里只会看到一条汇总路由，而不是四条明细路由。这样带来的好处有三个：骨干区域的LSDB缩小、路由表条目减少、某个办公网段震荡时不会影响其他区域的SPF计算。
外部路由的汇总则需要在ASBR上配置。R5引入了模拟外网的172.16.10.0/24网段，可以这样汇总：
ospf 1 asbr-summary 172.16.0.0 255.255.248.0这个命令把R5通告到OSPF域内的外部路由聚合成一条172.16.0.0/21。但要注意，汇总只影响通告出去的路由，R5本地路由表里依然保留明细路由。另外，外部路由汇总只能在ASBR上做，普通ABR即使配置了asbr-summary也不生效。
4.2 网络类型与计时器调优
OSPF接口的网络类型决定了邻居发现和路由更新的机制。默认情况下，以太网接口的网络类型是广播（Broadcast），Serial等点对点接口是Point-to-Point。不同网络类型对应不同的Hello间隔、Dead间隔和邻居发现方式。这个参数必须严格匹配，否则邻居无法建立。
实验中我把R2和R3之间的链路改成了点对点模式：
interface GigabitEthernet0/0/1 ospf network-type p2p改成P2P后，接口上不再进行DR/BDR选举，Hello间隔从10秒变为10秒（华为广播和P2P默认都是10秒），但Dead间隔保持40秒不变。P2P模式最大的好处是没有DR/BDR选举过程，邻居建立更快，同时链路状态通告更精简，不需要处理多路访问网络的LSA。
计时器调整方面，很多项目里为了让链路故障能被更快感知，会缩短Hello/Dead间隔。比如核心设备之间把Hello间隔从10秒改为3秒，Dead间隔从40秒改为10秒，这样链路down掉的感知时间可以从秒级提升到毫秒级之前？实际上，缩短计时器确实能减少故障发现时间，但代价是协议报文占用带宽增加，而且对链路质量要求更高——如果链路本身不稳定，频繁丢包会导致邻居关系反复震荡。
我在实验中把核心区域的两台设备之间的Hello间隔调整为5秒做测试：
interface GigabitEthernet0/0/0 ospf timer hello 5 ospf timer dead 20调整后，display ospf interface看到的效果是R1的Hello间隔变为5秒，Dead间隔变为20秒。注意，同一链路上的邻居两端必须使用相同的计时器参数，否则邻居状态会不断翻转。如果Dead间隔设置过短，比如3秒，在链路拥塞时很容易出现误判——路由器在Dead计时器超时前没有收到Hello报文，就判定邻居失效，触发SPF重计算，导致全网路由动荡。所以调整计时器的原则是：取一个既能让故障快速感知、又不会因为网络抖动误判的值，一般不会把Hello间隔压到1秒以下。如果项目要求亚秒级收敛，正确做法是部署BFD进行快速故障检测，而不是盲目缩短OSPF计时器。
4.3 认证配置与防攻击
OSPF认证是经常被忽略但非常重要的安全功能。默认情况下OSPF不启用认证，任何人都能通过发送伪造的Hello报文干扰邻居关系建立，甚至构造虚假的LSA造成路由黑洞。在实验里，我为核心区域配置了区域级认证，并且使用了更安全的HMAC-SHA256算法。
区域配置如下：
ospf 1 area 0.0.0.0 authentication-mode hmac-sha256 256 plain Cipher@Key123另一端设备必须配置相同的区域认证，密钥和算法必须一致。区域认证启用后，该区域内的所有OSPF报文都会携带认证字段，不匹配的报文会被直接丢弃。配置完成后，在接口上执行display ospf peer，如果邻居保持Full，说明认证生效。我试过故意把区域0内的一台设备的密钥改成错误值，观察邻居状态在10秒内变成了Down——这正是认证的实际作用：在OSPF报文层面挡住了不合法的路由器。
还有一种更细粒度的做法是接口级认证，也就是不同接口使用不同的密钥。这种模式适合在不同安全级别的区域之间做区分，比如核心区域使用高强度的HMAC-SHA256，而分支区域的接口只配置MD5认证甚至明文认证。但接口级认证的管理成本更高，密钥轮换时容易遗漏某个接口导致故障，所以我一般只在安全要求极高的核心链路上用接口级认证，其他区域统一使用区域认证。
OSPF报文使用的组播地址是224.0.0.5（所有SPF路由器）和224.0.0.6（DR/BDR），如果网络中有其他主机也监听了这些组播地址并发送伪造OSPF报文，就能实施中间人攻击。除了启用认证，还可以配合接口下的报文过滤功能，只放行来自特定源IP的OSPF报文，进一步压缩攻击面。这些配置在模拟器里都能很方便地验证，建议大家在实验里都试一下。
5. 故障排查实战与经验分享
5.1 邻居状态异常排查清单
这次实验我特意埋了几个故障点，用来验证排查思路。第一个故障是R3与R5之间邻居始终卡在Exstart状态，R3一直显示为Slave/Exstart。我通过display ospf error查看错误信息，发现反复出现DD报文长度不一致的记录。原因很快定位到接口MTU不一致——R3的接口MTU是1500，而R5的接口MTU被改成了1400，导致DD报文在传输过程中被静默丢弃。
解决办法有两种：要么把接口MTU改为一致，要么在接口下忽略MTU检查：
interface GigabitEthernet0/0/0 ospf mtu-ignore但生产环境中我不推荐直接忽略MTU检查——MTU不一致会导致后续数据面转发异常，尤其是涉及IP分片和MPLS场景时问题更明显。最好还是统一两端MTU，这才是根治。
第二个故障是R4通告的192.168.10.0/24路由在R1上始终看不到。检查步骤是这样的：先在R4上确认接口宣告是否生效（display ospf interface），然后在R1上查看是否收到了三类LSA（display ospf lsdb），最后发现R4的Area 0接口配置中漏宣告了连接R2的物理网段，导致R4无法在骨干区域内建立邻居，自然无法生成三类LSA。这个故障说明一个问题：ABR上凡是接入骨干区域的物理接口，都必须宣告到Area 0中，漏掉一个就可能导致区域间路由丢失。
5.2 路由黑洞与环路问题
OSPF本身是无环协议，但配置不当一样会造成路由黑洞。实验中我模拟了一个典型的错误配置：在R4上做了静态路由指向R2，同时又通过OSPF学习到了到该网段的路由，并且静态路由管理距离更低，所以优先被写入路由表。此时R2上并没有对应的OSPF邻居或路由，就会出现数据包被路由到R2后又丢包的现象。
这种问题的排查思路是：先用display ip routing-table查看实际生效的路由及其下一跳，再用tracert（华为设备为tracert命令）检查数据包的转发路径。一旦发现数据包走向了意料之外的下一跳，优先检查是否存在静态路由与动态路由之间的优先级冲突。在真实项目里，这种冲突还经常出现在路由引入的边界——比如把静态路由重分发进OSPF时，如果没有写好过滤策略，很可能把本应该留在本地的默认路由也通告出去，造成全网路由扰动。
OSPF路由防环的核心机制是区域之间必须经过骨干区域传播，三类LSA只在区域边界生成，且路由器的SPF算法保证了区域内路径无环。但是当网络里同时存在其他动态路由协议或大量静态路由时，协议之间的路由优先级、度量值差异、过滤器配置都可能导致环路。所以我在实验里反复强调一个原则：协议迁移和路由引入必须搭配路由过滤策略，不能直接全部重分发。
5.3 收敛性能与SPF调优
收敛性能是OSPF在生产环境中最重要的指标之一。实验里我用关闭接口的方式模拟链路故障，观察路由切换到备用路径的时间。默认情况下，接口down掉后OSPF需要等到Dead计时器超时（40秒）才能感知故障，然后才开始SPF计算——这个收敛速度在核心网络里是完全不可接受的。
我做的第一个优化是把核心链路的Hello/Dead间隔缩短到了5秒/20秒，故障感知时间从40秒降到了20秒左右。第二个优化是调整SPF计算计时器：
ospf 1 spf-schedule-interval 1 lsa-arrival-interval 100这里的SPF调度间隔和LSA到达间隔分别控制了LSA变化后多久触发SPF计算、以及连续LSA到达的最小间隔。把调度间隔调小能让SPF更快运行，但要注意如果LSA不断变化，频繁的SPF计算会消耗大量CPU。现实环境中如果拓扑稳定，可以放心的把SPF调度间隔设置得很小，但如果网络经常震荡，反而需要给SPF计算加一点延迟，让多条LSA变化合并成一次计算，减少CPU占用。
实验里我还验证了BFD联动OSPF的效果。在R1和R2之间配置BFD会话后，再关闭接口，收敛时间从20秒直接降到了1秒以内。具体配置不展开，但我想强调一点：在核心组网中，OSPF加BFD联动已经成为标准配置，单纯调谎OSPF计时器的收益非常有限。如果你在生产网络中负责核心设备，BFD是必须掌握的技能。
用表格做个收敛效果对比：
| 配置方案 | 故障感知机制 | 实测收敛时间 |
|---|---|---|
| 默认OSPF（Hello 10s/Dead 40s） | Dead超时 | 约40秒 |
| 调优计时器（Hello 5s/Dead 20s） | Dead超时 | 约20秒 |
| BFD联动（默认参数） | BFD快速检测 | 小于1秒 |
5.4 协议报文分析与抓包技巧
排错时很多问题光看命令输出是不够的，比如为什么邻居卡在2-Way状态、为什么DR选举结果和预期不符，这些问题只有通过抓包看报文才能找到答案。在模拟器里抓包非常方便，把PC终端接到路由器镜像口上，抓取OSPF的组播报文即可。
我观察了几个典型报文特征。Hello报文中的Network Mask字段必须是全网段掩码，如果两端掩码不一致，邻居就会卡在Init状态。Hello报文中的Options字段包含E位（External capability）、N位（NSSA）等标志位，如果一端启用了特殊区域类型而另一端没有，邻居也会建立失败。DD报文的I、M、MS位决定了主从协商过程和数据库同步的进度，这一块是理解OSPF状态机的关键。
抓包时有一个技巧：协议分析工具里的OSPF解码会把地理解释得非常清晰，但前提是你要能看懂每一条LSA的含义。建议在熟悉报文结构之前，先对照LSDB命令输出来看报文，一边看一边验证，比单纯记忆状态迁移图要高效得多。
6. 实验心得与扩展建议
做完成整个实验下来，我最大的体会是：OSPF配置本身并不难，难的是理解每一层机制背后的设计逻辑。比如为什么骨干区域必须是Area 0、为什么DR/BDR不可抢占、为什么一定要求同一链路上的计时器和认证参数完全一致——这些规则在实验里看似简单，但在真实网络中一旦违背，就会以各种奇怪的方式爆发出来。
实验环境里遇到的MTU不匹配、区域宣告遗漏、路由汇总配置位置错误，很多都是真实项目中反复出现的高频问题。我建议大家在练习OSPF时，不要只满足于把配置敲通，而是人为制造几种故障——比如改掉一台设备的Router ID、把一台ABR的接口宣告进错误的区域、调整某条链路的Cost值——然后用排错命令逐步定位。这种主动训练的收益，远比被动跟随教程做实验要高得多。
另外一个实际建议是：模拟器实验和真实设备实验之间存在差别。模拟器不会模拟出硬件层面的拥塞、丢包和芯片转发表异常，所以你在模拟器里调好的计时器和SPF参数，在真实设备上不一定是最优值。上线前一定要在测试环境里用真实设备做一次压力和故障演练，确认收敛时间和稳定性满足要求，再推送到生产环境。
最后补充一个小技巧：OSPF排错时永远从接口开始检查，然后看邻居，再看LSDB，最后看路由表。按照这个顺序排查，通常能在几分钟内定位问题。千万不要一上来就翻路由表——路由表只是结果，LSDB才是原因，而邻居状态又是LSDB同步的前提。顺序搞对了，排错就是水到渠成的事。
