企业官网建设流程全解析

1. 为什么OSPF基础要拆成“02”来讲：先搞清楚这一层到底在解决什么问题

很多人学OSPF，第一遍看完Hello包、邻居状态机、LSA类型，感觉自己已经懂了，结果一上设备配完区域，邻居卡在ExStart不动，或者邻居起来了路由表里却什么都没有。这种“看着会、上手废”的状态，几乎每个做数通的人都经历过。我当年第一次在模拟环境里配OSPF，两台设备背靠背，接口地址都通，ping得通，OSPF邻居就是起不来，排查了快两个小时才发现是两边Hello/Dead定时器不一致。这件事让我意识到，OSPF的“基础”其实分两层：第一层是概念层，知道它是什么、有哪些报文和状态；第二层是行为层，知道它在什么条件下会做什么、不做什么。这篇“OSPF基础02”要聊的，就是第二层——把那些概念落到设备行为上，搞清楚邻居怎么建立、区域怎么划分、开销怎么算、路由怎么选。

如果你已经看过OSPF的第一篇基础内容，对Hello报文、邻居状态、LSA类型有大致印象，那这篇正好接上。如果你是完全新手，也没关系，我会在关键地方把前置概念补回来，但重点始终放在“设备实际怎么跑”上。适合的人群很明确：刚接触动态路由协议的网络运维、备考相关认证的学员、以及那些配过OSPF但总在细节上翻车的老手。核心关键词OSPF、邻居建立、区域划分、开销计算、路由优选，会贯穿全文，但我不会堆砌它们，而是让它们出现在该出现的地方。

先说清楚这一篇的定位。OSPF基础01讲的是“是什么”，这一篇讲的是“怎么动”。邻居状态机从Down到Full，每一步的触发条件是什么；区域划分为什么要有骨干区域，ABR到底做了什么；Cost的计算公式里那个参考带宽为什么默认是100M，改它会影响什么；SPF算法算出来的路由，为什么有时候不如预期。这些问题不搞清楚，配出来的OSPF就是“能通但不知道为什么通”，出了故障也定位不了。我见过太多人把OSPF当静态路由用，配完能通就再也不看了，等到网络扩容或者链路抖动，问题全冒出来。

所以这篇的结构是这样：先把整体设计思路拆开，讲清楚OSPF的行为逻辑为什么这么设计；然后逐个抠核心细节，邻居建立、区域与LSA、开销与选路，每个都配上实操要点；接着给一套完整的实操流程，从零配到一个多区域OSPF网络，把关键命令和验证方法都列出来；最后是常见问题排查，把我踩过的坑和见过的问题整理成速查表。全程用从业者的口吻，不绕弯子，能直接抄的配置我会给出来，需要理解的地方我会把“为什么”讲透。

2. 整体设计思路拆解：OSPF的行为逻辑为什么长这样

2.1 从“邻居”到“路由”的两段式设计

OSPF最核心的设计思想，是把“建立信任”和“交换信息”拆成两个独立阶段。你先通过Hello报文确认对方是不是自己人（区域ID、认证、定时器、网络类型都得对得上），确认之后才进入数据库同步阶段，把各自的链路状态信息交换完整，最后各自跑SPF算路由。这个两段式设计的好处是：信任关系没建立之前，不浪费资源去同步大量数据；信任建立之后，同步过程有明确的阶段划分，出问题容易定位。

对比一下距离矢量协议就明白了。RIP那种“邻居直接发整张路由表”的模式，信任和信息是混在一起的，你收到更新就得信，不信就没法用。OSPF这种链路状态协议，邻居关系是前提，数据库同步是过程，SPF计算是结果，三层分离，每一层都有独立的状态机。这也是为什么OSPF排障时第一步永远是看邻居状态——邻居没到Full，后面的事都不用谈。

这个设计带来的一个直接后果是：OSPF对“邻居”的定义比很多人想象的严格。两台设备接口能互相ping通，不代表能建立OSPF邻居。区域ID必须一致（特殊区域除外），Hello和Dead定时器必须一致，认证方式和密钥必须一致，MTU在特定状态下必须一致，网络类型要匹配。任何一个不满足，邻居就卡在某个中间状态。我见过有人把两台设备接在不同VLAN里，三层能通，但OSPF邻居死活起不来，最后发现是两边接口的OSPF网络类型一个是广播一个是点对点，Hello报文里的参数对不上。

2.2 区域划分：为什么要人为切一刀

OSPF引入区域（Area）这个概念，本质上是为了控制链路状态信息的传播范围。所有区域必须直接或间接连到骨干区域Area 0，区域间的路由必须经过骨干区域转发。这个“星型”拓扑不是随便定的，而是为了保证区域间路由无环——ABR从非骨干区域学到的路由不会回传给骨干区域，骨干区域的路由也不会从非骨干区域绕回来。

为什么要有这个限制？想象一个不分区域的OSPF网络，所有路由器的LSDB完全一致，任何一条链路抖动都会触发全网SPF重算。网络规模小的时候没问题，几十台设备以上，SPF计算和LSA泛洪的开销就很可观了。区域划分把LSDB限制在区域内，区域内的拓扑变化只影响本区域，区域间只传递汇总后的路由，骨干区域负责中转。这个设计思路和“分治”是一个道理，把大问题拆成小问题，每个区域内部自己消化。

但区域划分有个硬约束：所有非骨干区域必须连到Area 0。如果物理上连不上，就得用虚链路（Virtual Link）打通，或者重新规划。虚链路这东西我一般不建议用，它本质上是把骨干区域的逻辑延伸过去，配置复杂且容易出环，能重新规划物理连接就别用虚链路。实际项目中，我见过因为历史原因区域规划混乱，最后靠虚链路硬撑的，维护起来非常痛苦，每次扩容都要重新算一遍虚链路路径。

2.3 开销计算：一条链路“值多少钱”由谁决定

OSPF的Cost计算看起来简单：接口Cost = 参考带宽 / 接口带宽，取整，最小为1。默认参考带宽100Mbps，所以100M接口Cost是1，1000M接口Cost也是1（因为100/1000小于1，取整后按1算），10M接口Cost是10。这里就埋了一个坑：千兆和百兆接口Cost一样，SPF算路时分不出优劣，可能选了一条百兆链路而不是千兆链路。

解决办法是改参考带宽，比如改成10000Mbps（10G），这样千兆接口Cost是10，百兆接口Cost是100，区分度就出来了。但改参考带宽有个前提：全网所有OSPF路由器的参考带宽必须一致，否则Cost计算标准不统一，选路会出问题。我一般建议在项目规划阶段就把参考带宽定下来，写进配置规范，别等到网络跑起来再改，改的时候要全网一起改，风险不小。

另一个容易忽略的点是Cost的方向性。OSPF的接口Cost是出接口方向的，A到B的路径Cost是A出接口Cost加上沿途各跳的出接口Cost，B到A是另一套计算。所以路由表里看到去程和回程走不同路径是正常的，只要两边都通就行。但如果是双向业务，去程回程路径差异太大，延迟和抖动可能不一致，这时候就要用接口Cost手动调整，把路径掰到一致。手动调Cost的命令很简单，ospf cost后面跟数值，但调之前一定要算清楚，别调完发现绕了更远的路。

3. 核心细节解析与实操要点：邻居、区域、开销逐个抠

3.1 邻居建立全过程：从Down到Full每一步在干什么

OSPF邻居状态机有七个状态，但实际排障时真正需要关注的是几个关键转折点。Down状态是初始状态，接口刚启用OSPF，还没收到任何Hello。Init状态是收到了对方的Hello，但Hello里的邻居列表中没有自己的Router ID，说明对方还没认出我。2-Way状态是双方Hello里都包含了对方的Router ID，双向确认完成。这两个状态在广播网络里很常见，非DR/BDR路由器之间会稳定在2-Way，这是正常现象，不是故障。

从2-Way往上走，DR/BDR选举完成后，非DR/BDR之间就不再继续建立邻接关系了，只有DR/BDR和其他路由器进入ExStart。ExStart状态是主从关系协商，双方比较Router ID，大的当Master，小的当Slave，协商MTU（如果开启了MTU检查）。这里是最容易卡住的地方：MTU不一致会导致双方一直停留在ExStart，因为数据库描述报文（DBD）发不过去。我遇到过好几次，一边接口MTU是1500，另一边是9000，邻居卡在ExStart，日志里能看到MTU不匹配的提示，但如果不看日志只盯状态，很难想到是MTU的问题。

Exchange状态是互相发送DBD报文，描述各自的LSDB摘要。Loading状态是发送LSR请求缺失的LSA，对方用LSU回应。Full状态是双方LSDB完全同步，邻接关系建立完成。整个过程在正常网络里几秒钟就完成了，如果卡在某个状态超过30秒，基本可以判定有问题。排障时我的习惯是先看邻居状态，再看邻居上的Dead定时器还剩多少，如果Dead时间在正常递减但状态不动，说明Hello还在收，问题出在后续阶段；如果Dead时间不递减或者直接归零，说明Hello都收不到了，问题在底层连通性或参数匹配上。

3.2 区域与LSA：不同类型的LSA到底谁在发、发给谁

OSPF的LSA类型是很多人头疼的地方，其实抓住“谁产生、传播范围、作用”三个维度就清楚了。Type 1 Router LSA由每台路由器产生，描述自己的接口和链路状态，只在区域内传播。Type 2 Network LSA由DR产生，描述广播网络上的路由器列表，也只在区域内传播。这两类是区域内拓扑的基础，SPF算路主要靠它们。

Type 3 Summary LSA由ABR产生，把区域内的路由汇总后发给其他区域，描述的是“到我这个ABR有多远”，而不是完整拓扑。Type 4 ASBR Summary LSA也是ABR产生，告诉其他区域“ASBR在哪里”。Type 5 External LSA由ASBR产生，描述外部路由，泛洪到整个OSPF域（特殊区域除外）。Type 7 NSSA External LSA是NSSA区域里ASBR产生的，在NSSA区域内传播，到ABR时转换成Type 5。

实际排障时，display ospf lsdb看LSDB，重点看Type 3和Type 5的数量和内容。如果区域间路由缺失，先查ABR上有没有产生对应的Type 3；如果外部路由缺失，查ASBR有没有产生Type 5，以及中间有没有特殊区域把Type 5过滤掉了。Stub区域不接收Type 5，NSSA区域不接收Type 5但可以自己产生Type 7，Totally Stub区域连Type 3都不接收（除默认路由外）。这些特殊区域的设计初衷是减少LSDB规模，但配置时要清楚哪些LSA被过滤了，否则路由缺失时容易懵。

3.3 开销与选路：SPF算出来的路径为什么和你想的不一样

SPF算法的核心是以自己为根，算到每个目标的最短路径树。路径的“短”是按Cost累加判断的，不是按跳数。所以一条两跳的千兆链路（Cost 1+1=2）可能比一条一跳的百兆链路（Cost 10）更优。这个逻辑和RIP按跳数算完全不同，也是OSPF选路经常出人意料的原因。

选路时的优先级顺序是：区域内路由 > 区域间路由 > Type 5外部路由 > Type 7外部路由。同一类路由里比Cost，Cost相同则负载均衡（默认最多等价路径数取决于设备平台）。外部路由还有个特殊规则：Type 1外部路由的Cost是外部Cost加上内部到达ASBR的Cost，Type 2外部路由的Cost只看外部Cost（除非外部Cost相同才比较内部Cost）。这个区别在引入外部路由时很关键，Type 1适合需要精确反映内部路径开销的场景，Type 2适合外部Cost主导的场景。

手动调Cost的实操要点：接口下ospf cost直接改接口Cost，影响该接口发出的所有路径计算；auto-cost reference-bandwidth改参考带宽，影响所有接口的Cost计算，必须全网一致。我一般优先用接口Cost微调特定链路，参考带宽只在规划阶段统一设定。调完Cost一定要看路由表验证，display ospf routing和display ip routing-table对照着看，确认选路符合预期。

4. 实操过程与核心环节实现：从零搭一个多区域OSPF网络

4.1 环境规划与基础配置

假设一个典型的三区域场景：Area 0作为骨干区域，连接两台核心路由器；Area 1和Area 2分别挂在一台ABR下面，各有一台接入路由器。接口地址规划如下表，这个规划思路是每个区域用独立的地址段，区域间通过ABR汇总，避免明细路由泛洪。

基础配置以R1为例，先配接口地址和OSPF进程。Router ID手动指定，别依赖自动选举，自动选举在接口地址变化时可能变，导致邻居重建。参考带宽在进程里统一设定为10000，为后续千兆链路区分度做准备。

# R1 基础配置 system-view sysname R1 interface GigabitEthernet0/0/0 ip address 10.0.0.1 30 interface GigabitEthernet0/0/1 ip address 10.0.1.1 24 quit ospf 1 router-id 1.1.1.1 auto-cost reference-bandwidth 10000 area 0 network 10.0.0.0 0.0.0.3 area 1 network 10.0.1.0 0.0.0.255 quit

R2的配置对称，Router ID用2.2.2.2，Area 0的network写10.0.0.0/30，Area 2写10.0.2.0/24。R3和R4分别配在Area 1和Area 2，Router ID用3.3.3.3和4.4.4.4。这里有个细节：network命令后面的掩码是反掩码，0.0.0.3对应/30，0.0.0.255对应/24，写错了接口就进不了OSPF。我见过有人把/24写成0.0.0.0，结果只匹配了一个地址，其他接口没进OSPF，邻居起不来还找不到原因。

4.2 邻居验证与区域间路由检查

配完基础OSPF，第一步验证邻居。在R1上执行display ospf peer brief，应该能看到和R2的邻居状态是Full，和R3的邻居状态也是Full。如果R1和R3之间是广播网络且有多台设备，非DR/BDR之间可能是2-Way，这是正常的。验证完邻居，看LSDB：display ospf lsdb，Area 0里应该有R1和R2的Type 1 LSA，Area 1里应该有R1和R3的Type 1 LSA，R1作为ABR还会产生Type 3 LSA把Area 1的路由通告到Area 0。

路由表验证是关键一步。在R3上看display ip routing-table，应该能看到10.0.0.0/30（Area 0的网段）和10.0.2.0/24（Area 2的网段），下一跳指向R1。这两条路由在R3的LSDB里是以Type 3 LSA形式存在的，R3不知道Area 0和Area 2的内部拓扑，只知道“通过R1能到”。这就是区域划分的效果：R3的LSDB里只有Area 1的完整拓扑和区域间的汇总路由，规模可控。

如果R3上看不到10.0.2.0/24，排查顺序是：先看R1有没有产生对应的Type 3（display ospf lsdb summary），再看R2有没有把Area 2的路由通告给Area 0（R2作为ABR，Area 2的Type 1会转成Type 3发到Area 0），最后看R1有没有把从Area 0学到的Type 3再发给Area 1。这个链条上任何一环断了，路由就缺失。我遇到过R2的Area 2接口没进OSPF的情况，R2上Area 2的Type 1 LSA只有自己，自然产生不了正确的Type 3，R3上就看不到Area 2的路由。

4.3 开销调整与选路验证

假设R1和R2之间除了G0/0/0直连，还有一条备份路径经过一台中间设备（模拟场景），两条路径的Cost需要手动调整让主路径优先。直连链路Cost按参考带宽10000算，千兆接口Cost是10。备份路径如果经过两个千兆接口，Cost是20，直连自然优先。但如果备份路径也是千兆直连（比如通过交换机），Cost相同就会负载均衡，这时候需要手动把备份路径的接口Cost调大。

# 在备份路径的接口上调整Cost interface GigabitEthernet0/0/2 ospf cost 100 quit

调完在R1上看display ospf routing，确认去往R2侧网段的路径走的是G0/0/0而不是G0/0/2。再看display ip routing-table，确认路由表里只有一条最优路径（或者等价路径符合预期）。这里要注意，调Cost只影响本设备发出的路径计算，对端设备如果也有多条路径，需要在对端同样调整，否则可能出现去程走主路径、回程走备份路径的情况。双向业务场景下，两边都要检查。

4.4 特殊区域配置与验证

如果Area 2是个末梢区域，不需要接收外部路由，可以配成Stub区域。Stub区域的ABR（R2）会向Area 2发一条默认路由，Area 2内部路由器不接收Type 5 LSA，LSDB规模减小。配置很简单，R2和R4的Area 2下都加stub命令，两边必须一致，否则邻居起不来。

# R2 和 R4 的 Area 2 配置 ospf 1 area 2 stub quit

配完在R4上看display ospf lsdb，确认没有Type 5 LSA，路由表里有一条默认路由指向R2。如果R4上还能看到Type 5，说明Stub配置没生效或者两边不一致。NSSA区域类似，但允许自己产生Type 7 LSA引入外部路由，配置命令是nssa，ABR上还要加nssa default-route-advertise才会下发默认路由。特殊区域的配置不难，难的是规划阶段想清楚哪些区域该用哪种类型，配错了要么路由缺失要么LSDB没减下来。

5. 常见问题与排查技巧实录：那些文档里不写的坑

5.1 邻居卡在特定状态的排查速查表

邻居状态卡住是OSPF最高频的问题，我把常见状态和对应原因整理成表，排障时按表对照能省不少时间。

ExStart卡住是我遇到最多的，除了MTU，Router ID冲突也会导致主从协商失败。两台设备Router ID相同，比较大小分不出主从，就一直在ExStart循环。Router ID冲突在规划不规范的网络里很常见，尤其是自动选举Router ID时，设备重启后接口地址变化可能导致冲突。手动指定Router ID能避免这个问题，规划时把Router ID分配表列出来，别让设备自己选。

5.2 路由缺失的三层排查法

路由缺失的排查我习惯分三层：邻居层、LSDB层、路由表层。邻居层先确认相关邻居都是Full，邻居不全后面不用看。LSDB层确认对应的LSA存在且内容正确，比如区域间路由缺失就看ABR上有没有Type 3，外部路由缺失就看ASBR上有没有Type 5。路由表层确认SPF算出来的路由有没有进路由表，有时候LSA存在但被路由策略过滤了，或者被其他协议的路由优先级压住了。

这三层里最容易忽略的是LSDB层。很多人邻居Full了就以为万事大吉，直接看路由表，发现没有就懵了。其实邻居Full只代表LSDB同步完成，不代表LSA内容正确。我遇到过ABR上Type 3 LSA存在但掩码不对的情况，原因是ABR的接口地址配错了掩码，产生的Type 3自然不对。还有一次是ASBR引入了外部路由但没配import-route的过滤条件，引入了一堆不该引入的路由，把路由表撑爆了。LSDB层看仔细，能省掉很多瞎猜的时间。

5.3 实操心得：几条不写在文档里的经验

第一条，配OSPF之前先把Router ID规划好，写进配置模板，别依赖自动选举。自动选举的Router ID在接口地址变化或设备重启后可能变，一变邻居就重建，业务抖一下。手动指定Router ID是一劳永逸的事，成本极低。

第二条，参考带宽在项目初期就定下来，全网统一。后期改参考带宽要全网一起改，改的过程中选路可能短暂异常，风险不小。如果项目里千兆和百兆链路混用，参考带宽至少设到10000，让千兆和百兆的Cost有区分度。

第三条，特殊区域能不用就不用，用了就要清楚过滤了哪些LSA。Stub和NSSA在减少LSDB规模上确实有效，但配置不一致或规划不清时，路由缺失的排查难度比普通区域高得多。我一般只在明确不需要外部路由的末梢区域用Stub，其他场景优先用路由汇总来控制LSDB规模。

第四条，调Cost之前先算清楚，调完一定验证双向路径。OSPF的Cost是方向性的，只调一边可能导致去程回程路径不一致。双向业务对路径一致性有要求时，两边都要调，调完用tracert或者路由表对照验证。

第五条，邻居状态机卡住时先看日志。设备日志里通常有邻居状态变化的记录和原因提示，比如MTU不匹配、认证失败、区域ID不一致，日志里都有。盯着状态机看半天不如翻一眼日志，这个习惯能省大量时间。

6. 从基础02再往前走：这些细节值得继续深挖

OSPF基础02聊到这里，邻居建立、区域划分、开销选路这三块的行为逻辑基本讲透了。但OSPF的细节远不止这些，比如认证机制（明文和密文认证的配置差异和安全性考量）、路由汇总（区域间汇总和外部路由汇总的配置位置和效果）、SPF算法的具体计算过程（为什么有时候次优路径会被选中）、以及和BFD联动实现快速收敛。这些内容每一个都值得单独展开，但作为基础02，先把邻居、区域、开销这三根支柱立稳，后面的内容才有地方挂。

我个人在实际操作中的体会是，OSPF的坑大多不在配置命令上，而在规划和对协议行为的理解上。命令就那么几条，背都能背下来，但什么时候该用Stub、参考带宽设多少、Cost怎么调，这些决策依赖对网络整体架构的理解。配之前多想一步，配之后多验证一步，比出了故障再排查省事得多。最后分享一个小技巧：每次配完OSPF，把display ospf peer、display ospf lsdb、display ip routing-table三条命令的输出存一份基线，后续出问题时和基线对比，差异一目了然，比从头排查快得多。