企业官网建设流程全解析

简介：OSPF细节汇总是一份面向网络工程师、HCIP备考者及需要排查OSPF路由故障的运维人员的系统梳理型笔记，完整覆盖OSPF协议原理、7类LSA特性、区域划分与设计原则、虚链路、不同OSPF进程相互导入、Stub与NSSA特殊区域、网络类型、汇总及安全认证、route-policy路由过滤等核心内容。打包为单个PDF文档，压缩包仅2.88MB，排版较紧凑，适合作为复习提纲随身查阅。目前已有669人学习下载，被不少路由方向学习者当作查漏补缺的参考。文档从Hello、DBD、LSR、LSU、LSACK等消息包和邻居状态机、DR/BDR选举等基础机制讲起，深入展开虚链路解决非直连骨干区域、多进程导入处理不连续区域、route-policy控制路由发布与接收等进阶场景，既有理论框架又有配置思路，能够帮助读者快速建立OSPF全景图，备考HCIP或排查实际网络问题时反复查阅。

1. OSPF细节汇总：凌晨两点邻居起不来时，你缺的是这套语法

调OSPF的人通常有个错觉：配置敲得滚瓜烂熟，邻居显示Full就以为万事大吉。可一旦现网凌晨两点邻居起不来，display ospf peer卡在Init，或者区域间路由通了、外部路由整段消失，那些背过的命令就不够用了。真正缺的是把七类LSA的洪泛边界、Stub/NSSA区域的进出口规则、虚链路与多进程导入的防环、网络类型和DR选举这些细节串成一张能跟着走的排查地图。这篇笔记就把这张地图铺开，适合准备HCIP或者正在扛现网割接的人，也适合在eNSP里模拟到怀疑人生的新手。地图不是背给考官看的，是出问题时照着查的。

2. 先把理论立住：七类LSA和区域划分的对应关系

2.1 七类LSA的出身表：谁生成、往哪传、能干什么用

一上来先把LSA的账算清楚。OSPF的链路状态数据库不是路由器凭空脑补出来的，LSDB里每一条记录都是一张有身份标签的LSA。平时在display ospf lsdb里看到的Type 1、Type 2编号，就是它们的身份证。

Type 1和Type 2只在同一个区域内泛洪，所以普通路由器上的LSDB其实只有自己区域的完整拓扑，外加一堆其他区域的摘要。Type 3就是ABR跨区域生成的摘要，不了解远方拓扑也能知道怎么去。Type 4容易被忽略，它描述的是"ASBR这台设备在哪里"，跨区域计算时没有Type 4索引，路由器根本找不到外部路由的源头。Type 5是ASBR引入外部路由之后的全域广播，默认传遍整个OSPF域，但会被Stub和NSSA边界拦下来。Type 7只在NSSA区域内部存在，出了NSSA会被ABR翻译成Type 5继续传，翻译这件事下文专门讲。

排障时有一条LSA细节很值钱：正常LSA会被源路由器周期性刷新，默认刷新周期是1800秒，所以你在display ospf lsdb里看到Age字段不断滚动是正常的。如果某条LSA的Age整天卡在3600附近反复横跳，或者要靠reset ospf process才能清掉，说明源端和这个区域之间出现了DB失步，常见诱因就是Hello定时器不一致或者网络类型不匹配导致的邻居闪断。这条经验能帮你省掉一轮抓包。

2.2 区域划分的本质：把LSA洪泛拦在边界上

OSPF分区域的目的有两条：缩小洪泛范围、缩小SPF计算范围。单区域网络里一条链路up/down，全网所有路由器都要重算SPF；划分区域后，抖动被ABR挡在本地，其他区域的路由表完全不受影响。你观察到的"PING通但路由偶尔抖"的现场，多半就是区域边界没有做汇总，或者特殊区域选型选错了。

ABR是跨区域的关口，它同时维护多份LSDB。ABR不会把区域内的Type 1/Type 2拓扑转发给另一个区域，而是把它们计算成Type 3路由通告出去。这个机制让ABR天然成为区域间的防火墙，但也意味着区域间路由质量完全依赖ABR计算能力，ABR挂了，这个区域对外就断了。

给ABR做区域汇总的常见配置如下，这条命令在ABR的area视图下执行，只影响该ABR对外发布的Type 3路由：

ospf 1 area 1 abr-summary 10.1.0.0 255.255.0.0

逻辑说明：abr-summary把区域1内多个精确网段汇总成一条10.1.0.0/16对外发布，其他区域的LSDB变小、对外隐藏区域内拓扑波动。参数说明：后面跟的是网络地址和点分十进制掩码，不支持前缀长度写法；可以追加cost 100控制其他区域访问该区域的开销。注意，如果区域1内还有落在10.2.x.x的网段没有被汇总进这条路由，其他区域会同时看到汇总和明细两条前缀，选路反而出现歧义。所以做abr-summary之前先确认区域内的地址是连续的，不满足就别开。

区域划分常被误当成VLAN隔离。OSPF区域本质是SPF域，不是二层隔离域，两个区域可以在同一台ABR上共享物理链路，甚至同一接口可以属于不同区域。但掩码规划必须收敛，否则Type 3汇总后会出现路由残缺。

2.3 区域0为什么必须是连续骨干：断一下路由就抖给你看

OSPF之所以强制所有非骨干区域挂到Area 0，本质是防环。区域间路由全部经过骨干中转，非骨干之间不直接传递路由，这样ABR之间不会出现环路。如果Area 0被断开，分居两端的ABR各自认为自己是骨干的一部分，同时又都想把对方的区域路由当外部路由学进来，结果就是非骨干区域之间的路由忽通忽断，SPF反复重算。

华为里可以用display ospf backbone查看骨干成员。如果发现骨干成员缺失，典型现象是：区域A到区域B的流量大面积丢包而不是完全不通，因为路由表里还有一条残存的区域间路由在超时边缘反复挣扎。

怎么续？常见做法就是第4章讲的虚链路。虚链路的逻辑是把一台ABR通过某个非骨干区域拉进Area 0，让骨干在拓扑上恢复连续。注意它只能穿越普通非骨干区域，Stub和NSSA都不能穿。原因也简单：特殊区域对LSA类型做了限制，虚链路建立虚拟邻接需要依赖完整的区域LSDB，限制LSA就等于拆桥。

3. Stub与NSSA区域落地：最小配置和选型边界

3.1 Stub/Totally Stub配置：把外部路由换成默认路由

Stub区域的意图很直白：区域内部只跑OSPF自身，不需要接收外部AS路由，那就让ABR不要向这个区域通告Type 4和Type 5，并代替它们下发一条默认路由。区域内路由器的LSDB小了一大截，外部路由抖动也不会传导进来。

华为配置时，先进入OSPF进程再进入区域视图：

[核心-A] ospf 1 router-id 1.1.1.1 [核心-A-ospf-1] area 1 [核心-A-ospf-1-area-0.0.0.1] stub

逻辑说明：stub命令告诉路由器这个区域是末梢区域，ABR不再向区域内通告Type 4/5，同时自动生成一条Type 3默认路由代替外部路由。参数说明：区域内所有路由器都必须配置同一属性，只要有一台没配，Hello报文里的Option字段E位不一致，邻居就会起不来或路由不全。如果你把区域1的两台设备都配成Stub，命令完全一样，没有主从之分。

Totally Stub则是在ABR侧追加no-summary：

[核心-A-ospf-1-area-0.0.0.1] stub no-summary

逻辑说明：no-summary表示连Type 3区域间路由都不通告，区域内只剩一条ABR生成的默认路由，路由表最干净，SPF计算量也最小。参数说明：这个参数只需要在ABR上配置，区域内其他路由器配置普通stub即可。验证时执行display ospf lsdb，应该只看到Type 1、Type 2以及ABR注入的那条默认路由，再看不到Type 4和Type 5。

Stub区域有个硬性底线：区域内不能存在ASBR。因为ASBR要在区域里生成Type 5，而Stub区域禁止Type 5进入。如果你在Stub区域内的设备上配了import-route static，外部路由不会被通告进这个区域，属于配了也白配的典型坑。

3.2 NSSA配置：7类转5类，谁来做、谁来传

NSSA的出发点是：既要享受Stub区域"不接收外部Type 5"的好处，又允许自己区域内引入外部路由。NSSA允许区域内出现ASBR，但这个ASBR生成的是Type 7而不是Type 5。Type 7只能在NSSA区域内洪泛，到了ABR那里由ABR翻译成Type 5再向骨干区域通告。

华为配置：

[核心-B] ospf 1 router-id 2.2.2.2 [核心-B-ospf-1] area 2 [核心-B-ospf-1-area-0.0.0.2] nssa

逻辑说明：nssa把区域2定义成NSSA，区域内允许Type 7存在但拒绝外部Type 5进入。NSSA区域内所有路由器也要保持一致，否则Option字段N位不一致，邻居关系会异常。

如果区域2里有一台设备要引入外部路由，比如引入静态路由：

[边界-C] ospf 1 [边界-C-ospf-1] import-route static

逻辑说明：import-route static在OSPF进程视图下执行，把静态路由以ASBR身份引入OSPF。因为该区域是NSSA，这些外部路由会以Type 7形式存在于区域2的LSDB中。此时在ABR上执行display ospf lsdb nssa能看到Type 7条目，再到骨干区域的设备上执行display ospf lsdb ase，能看到这条外部路由已经变成Type 5，且Translator字段指向ABR的Router ID。

如果想让ABR自动向NSSA区域内下发默认路由，必须显式配置：

[核心-B-ospf-1-area-0.0.0.2] nssa default-route-advertise

逻辑说明：这条命令让ABR向NSSA区域生成一条Type 7默认路由。很多人在NSSA里等默认路由等不到，就是少了这一步。普通OSPF区域的默认路由靠Stub自动产生，NSSA不会。

3.3 选型边界：什么场景上Stub，什么场景必须NSSA

实际选型我按三步判断。第一步，区域内有没有外部路由引入需求：没有就Stub，有就必须NSSA，没有商量余地。第二步，想不想让区域内路由表更小：能接受一条默认路由代替所有外部路由，就用Totally Stub或Totally NSSA，即stub no-summary或nssa no-summary。第三步，确认这个区域不会被用作虚链路穿越区，Stub和NSSA都不能作为虚链路的transit区域。

再提醒一句，搜索"stud区域"的人大多在找Stub区域。stub是"末梢"的意思，华为和eNSP里敲的是stub，不是stud，拼错命令敲不下去，别在这个字上浪费时间。

4. 虚链路与多进程导入：跨区域、跨进程的两种补救

4.1 虚链路配置：物理上不连续时把区域0续上

虚链路解决两个典型问题：新增区域没法直接物理挂到Area 0，只能经一个非骨干区域中转；或者骨干区域被横向切成了两段，需要逻辑上把骨干续上。无论哪种，虚链路只存在于两台ABR之间，且传输通道必须是一个非骨干的普通区域，不能是Stub或NSSA。

华为配置是固定套路。假定ABR-1的Router ID是1.1.1.1，ABR-2是2.2.2.2，两台设备借道区域1建立虚链路：

ABR-1上配置：

[ABR-1] ospf 1 router-id 1.1.1.1 [ABR-1-ospf-1] area 1 [ABR-1-ospf-1-area-0.0.0.1] vlink-peer 2.2.2.2

ABR-2上配置：

[ABR-2] ospf 1 router-id 2.2.2.2 [ABR-2-ospf-1] area 1 [ABR-2-ospf-1-area-0.0.0.1] vlink-peer 1.1.1.1

逻辑说明：vlink-peer后跟的是对端ABR的Router ID，不是接口IP，也不是进程号。命令在area 1视图下配置，因为虚链路要借道区域1建立，但建立成功后这条虚拟链路属于Area 0，参与骨干区域的SPF计算。配置完成后用display ospf vlink查看状态，State为Full表示虚链路建立成功。

参数说明：如果对端Router ID写错、中间区域有一台路由器做了过滤、或中间区域被配成Stub/NSSA，虚链路都无法Full。排障顺序永远是先看中间区域的两台ABR之间是否已有Full邻居，再看虚链路状态。思科系命令是area 1 virtual-link 2.2.2.2，华为和eNSP里是vlink-peer 2.2.2.2，跨厂商排障时别把两条命令的视图搞混。

4.2 多进程相互导入：import-route ospf x 的防环要点

一台设备上跑多个OSPF进程的场景，主要出现在业务吞并和部门网络合并阶段。OSPF进程之间各自维护独立的LSDB，互不感知，想让进程1学到进程2的路由，唯一办法是显式路由引入。

华为命令在进程视图下执行：

[边界-1] ospf 1 router-id 3.3.3.3 [边界-1-ospf-1] import-route ospf 2 [边界-1-ospf-1] area 0 [边界-1-ospf-1-area-0.0.0.0] network 10.0.0.0 0.0.0.255

另一台设备反向引入：

[边界-2] ospf 2 router-id 4.4.4.4 [边界-2-ospf-2] import-route ospf 1 [边界-2-ospf-2] area 0 [边界-2-ospf-2-area-0.0.0.0] network 20.0.0.0 0.0.0.255

逻辑说明：import-route ospf 2表示把进程2的OSPF路由作为外部路由引入到进程1中。被引入的路由在进程1的LSDB里以Type 5存在，路由优先级从OSPF内部路由的10变成外部路由的150。你如果看到路由表里目标网段的协议标记变成O_ASE，说明它已经被当成外部路由处理，不是OSPF内部路由了。

参数说明：可以追加cost、tag、type控制这条外部路由的行为，比如：

[边界-1-ospf-1] import-route ospf 2 cost 20 tag 200 type 1

type 1是外部cost加内部cost逐跳累加，type 2只算外部cost，华为默认type 2。做选路控制时，type 1更贴近物理链路质量，type 2更适合表达"这是一个固定的外部代价"。

双进程互导最要命的是环路和次优路径。进程1把路由导入进程2，进程2又把路由导回进程1，一旦中间还有第三台设备同时学到了两边的路由，选路就会来回跳跃。我的做法是：在边界设备上只保留一个方向导入，或者给路由打tag做单向闸门。比如进程1导入时带tag 200，再在进程2的入口用filter-policy ip-prefix XXX deny拒绝带该tag的路由，环路就在边界被切断了。

4.3 两种手段的取舍：虚链路不该滥用，进程导入要注意次优路径

虚链路是弥补物理拓扑不足的补救方案，尽量少用。原因有三：虚链路把中间区域变成骨干的承载通道，中间区域任何一条链路抖动都会影响骨干稳定性；虚链路上难以做精细的cost控制，也不好监控；排障链路变长，很多人看到虚链路Full就以为万事大吉，其实路由计算还是在依赖中间区域。我的习惯是：能拉新链路、能调整物理组网，就不要用虚链路，它只当过渡方案。

进程导入则更像路由域之间的翻译机制，不会改变区域拓扑，只影响控制平面交互，可控性更高，适合跨域合并的过渡期。但如果两个OSPF进程跑在同一台设备上而它们又连接同一片物理区域，更优方案是合并进程或重新划分区域，而不是长期维持互导。进程互导解决了"有点通"的燃眉之急，后期要把路由收敛到单一进程。

5. OSPF排障避坑：邻居翻车、路由黑洞和网络类型不匹配

先铺垫网络类型这个变量。华为默认：以太网接口是Broadcast，选举DR/BDR，Hello 10秒；串口是P2P，不选举DR，Hello 10秒；帧中继接口是NBMA，选举DR，Hello 30秒，还要手动指定邻居。P2MP一般用于把NBMA当作一组点对点链路处理，不选举DR，Hello 30秒。改网络类型用接口命令：

interface GigabitEthernet0/0/0 ospf network-type p2p

逻辑说明：这条命令把接口网络类型从Broadcast改成P2P，接口不再参与DR选举，Hello报文结构也变化。参数说明：网络类型是接口级属性，必须保证链路两端一致，否则就会卡出下面第一个坑。

5.1 邻居永远停在Init：Hello定时器与区域不匹配

现象：display ospf peer显示邻居状态一直停留在Init，或者反复出现又消失，路由表里时有时无。

原因：最常见的三种诱因是区域ID不一致、认证失败、Hello/Dead定时器不一致。在广播网络中，如果一端是Broadcast另一端被改成了P2P，双方虽然都在发Hello，但Hello报文里的网络掩码和Option字段处理不一致，邻居就卡在Init。还有一种隐蔽情况：Hello定时器两端分别是10秒和30秒，短的等不到长的，状态就永远Init。

解决：先看display ospf error的错误统计，OSPF错误表会直接给出增量计数，比抓包还直观。看到Hello Timer Mismatch就改两端定时器，看到Area Mismatch就核对区域ID，看到Auth Failure就查认证配置。注意改完参数后要等一到两个Hello周期，别改完就盯着屏幕催。

提示：display ospf error 是先于抓包的第一排查入口。计数不涨但状态不变化时，才需要去抓包看报文细节。

5.2 邻居卡住ExStart/Exchange：MTU和Router ID在作祟

现象：邻居状态到了ExStart后不再前进，DD报文来回协商却对不上序列号，display ospf peer稳定在ExStart或Exchange。

原因：最经典的是两端接口MTU不一致。OSPF的DD报文里携带接口MTU字段，双方数值对不上，主从协商无法完成。另一个常见原因是两台路由器Router ID冲突，DD报文里的邻居Router ID互相不认，自然协商不下去。

解决：先把两端接口MTU改成一致，接口下mtu 1500，再重置OSPF进程或重启接口。然后核对display ospf peer里的Router ID与display ospf brief是否重复。华为部分版本默认不做MTU检查，但如果接口下开了ospf mtu-enable，MTU不一致就会立刻暴露。如果公司规范禁止改MTU，那就把两端设备的OSPF MTU检查统一关掉，保持行为一致。

5.3 广播网段DR频繁切换：优先级与Router ID的选择逻辑

现象：同一广播网段里DR角色频繁变动，邻居关系反复重建，外部路由时通时断，日志里全是邻接变化。

原因：DR/BDR选举不是抢占式的，正常情况下不会频繁切换。出现切换，通常是因为新上线一台DR优先级更高的设备，或者原DR接口重启导致整段重选。DR优先级默认1，范围0到255，优先级相同则比Router ID，数字大者当选。很多网工把同网段两台核心都配成优先级255，结果两台互不相让，一有抖动就重新选举。

解决：全段统一规划DR成员。核心设备DR优先级配成100，备份核心配成50，接入路由器和业务设备配成0不参与选举。注意DR other之间只保持2-Way状态，不建立Full，但它们的LSDB同步和路由计算完全正常，不要看到2-Way就以为出故障了。

5.4 虚链路/进程引入后路由不亮：过滤和次优路径

现象：虚链路已经Full，但通过虚链路连上骨干的区域路由迟迟不出现；或者进程互导后外部路由在路由表里时有时无。

原因：虚链路Full只说明虚拟邻居关系建立成功，不代表中间区域的路由策略放行。中间区域配了过滤策略、ABR做了汇总但汇总范围不对，都会导致区域路由在虚链路之后的通告中断。进程互导的时有时无，大概率是双向引入造成路由feedback，或者重叠网段让路由表在两条路径之间来回切换。

解决：在两台ABR上分别执行display ospf routing，看区域间路由是否出现。如果缺失，检查中间区域是否有filter-policy拒绝Type 3。进程互导先用tag标记来源，再在边界做单向过滤。最后观察display ospf lsdb ase里TYPE 5的老化时间是否在反复重置，如果Age一直滚动到接近3600又突然变年轻，说明这条LSA在被持续刷新，十有八九是环。所有修改后至少观察一个LSA刷新周期（默认1800秒）再确认结果。

6. 验证OSPF收敛状态：三条display命令加一个抓包习惯

6.1 先看表还是先看邻居：display ospf peer / error / lsdb 的用法

先看邻居还是先看LSDB？我的习惯是先display ospf peer brief快速确认邻居状态。如果全部Full，再调display ospf lsdb看LSA类型是否齐全。如果邻居不是Full，直接看display ospf error，错误表的计数器能直接指到协议层面的原因，不需要一上来就抓包。lsdb视图下重点看三件事：Type 5/Type 7外部路由是否存在；LSA老化年龄是否正常滚动；有没有Age=3600的MaxAge条目反复出现。MaxAge条目反复出现，说明某台设备在持续刷新一条老LSA，大概率是区域边界或网络类型不一致导致的失步。

6.2 抓包验证LSA洪泛：观察DR与邻居状态迁移

在eNSP里做一个小实验很值：三台路由器连同一个交换网段，把其中两台分别设为DR优先级100和50，第三台优先级0不参与选举。启动后抓OSPF Hello，能看到Hello报文里的DR/BDR字段从0.0.0.0慢慢变成两台核心的Router ID；再抓DD报文看主从协商、MTU字段和序列号变化。这个实验把"广播网段DR选举"从抽象概念变成肉眼可见的过程，比背十遍状态机都管用。

我每次改完OSPF参数，都会把display ospf error的计数清零，观察五分钟，再看LSDB里有没有MaxAge条目，最后确认业务路由。这套顺序帮我避开了很多"看起来通了其实在振荡"的局面。希望帮到你。

本文还有配套的精品资源，点击获取