企业官网建设流程全解析

1. 从一道经典面试题说起：OSPF到底按什么选路

前阵子帮朋友处理一个网络问题，两台核心交换机之间跑着OSPF，业务方反馈跨机房的流量总是绕路，明明有更短的链路不用。排查到最后，问题不在路由学到没有，也不是邻居关系抖动，而是OSPF的选路逻辑跟我们直觉里的“哪条路宽带大走哪条”完全不是一回事。折腾到半夜，朋友感叹了一句：OSPF这选路，说到底就是一套COST值的“算计”，不算带宽，算的是开销。

这句话基本就是OSPF选路的内核。很多人刚接触OSPF的时候，容易把它跟日常上网的“带宽越大越快”搞混，认为路由器会像地图导航一样，根据链路带宽自动选出最宽的那条路。实际运行OSPF的路由器，眼里根本没有带宽这个天然属性，它只看一个由公式算出来的数字，叫COST（开销）。这个数字越小，路径就越优，数据就走哪条。

这篇文章就专门拆解OSPF选路这件事：COST值是怎么来的、链路带宽在里边到底扮演什么角色、为什么有时候你改了半天带宽，路由死活不变，以及我在现网里踩过的选路相关的坑。无论是刚接触OSPF的入门读者，还是已经部署了OSPF、正在为次优路径头疼的运维同学，这篇内容都能给你一些可以直接抄作业的思路。先提个醒：搞懂OSPF选路，COST公式只是起点，真正的难点在于理解“算计”背后的那些隐藏参数和优先级关系。

2. COST的计算原理：OSPF的“算计”起点

2.1 官方定义：COST = 参考带宽 / 接口带宽

OSPF选路的基础很简单，RFC 2328里规定，每个接口都有一个COST值，路由经过某条链路时，把沿路所有接口的COST值累加起来，总和最小的路径就是最优路径。路由器的LSA（链路状态通告）里携带的就是这些COST值，而不是物理距离或者带宽数值。

接口的COST值怎么算？公式是：

接口COST = 参考带宽（Reference Bandwidth）/ 接口带宽（Interface Bandwidth）

默认情况下，参考带宽是100Mbps。所以算出来的结果就像这样：

看到问题了吧。千兆和万兆链路计算出来的COST值都是1，因为默认参考带宽只有100M，合着万兆的口跟百兆的口在OSPF眼里地位一样，都是1的花销。这就是很多人说的“OSPF不认万兆”的根源。

2.2 为什么参考带宽是100M：历史包袱与现实问题

这个100Mbps的默认值，是上世纪OSPF协议设计时的产物，那时候百兆链路已经是顶级配置了，以太网、快速以太网横行，100M当基准完全够用。到了千兆普及、万兆走进数据中心之后，这个默认值明显跟不上时代了，所有高速接口算出来的COST都一样，OSPF就丧失了在高速链路之间做差异化选路的能力。

那怎么办？改参考带宽。在接口上设置不同的cost太麻烦，更合理的做法是全局调整参考带宽，让公式在高速链路下依然能拉开差距。比如把参考带宽调到10Gbps，即10000Mbps，那一条千兆链路的COST就是10000/1000=10，万兆就是10000/10000=1，两者就分出了明显的高低。

注意：调整参考带宽时必须保证整个OSPF域内所有路由器保持一致。我在现网见过只改核心设备、没改接入设备的情况，结果就是区域内计算出来的路径开销不一致，出现环路和次优路由，排错排到怀疑人生。

2.3 带宽、COST和选路的实际关系：一个生活化类比

可以这么理解COST和带宽的关系：COST不是“速度值”，而是“花费值”。同样是去一个地方，打车（千兆链路）花10块钱，坐公交（百兆链路）花1块钱，如果不看体验只看价格，OSPF毫不犹豫选公交，哪怕公交绕路要坐两个小时，打车直线只要二十分钟。选路决策只认花费高低，不认到达速度。

所以在网络设计里，想用带宽大的链路承载更多流量，不能只把物理带宽提上去，还得动手把这条链路的COST值“教”给OSPF——要么改参考带宽，要么手动指定接口COST。否则路由器不会理睬你花了多少钱买的那根万兆光纤。

3. 选路博弈的关键参与者：COST之外还有哪些“裁判”

3.1 优先级第一关：OSPF外部路由跟内部路由不能只看COST

OSPF协议里，路由条目分了三六九等，不是所有路由都比COST。一条路由能不能进路由表、用哪条作为最优，首先要看它的路由类型优先级，然后才轮到COST值比大小。

拿华三的设备来说，路由表里有一个“Preference（路由优先级）”的概念，这是不同路由协议之间的比拼（比如静态路由优先还是OSPF优先，取决于厂商默认优先级的大小），范围是整个路由协议维度。在OSPF协议内部，又分为：

• 区域内路由（Intra-Area）
• 区域间路由（Inter-Area）
• 第一类外部路由（Type 1 External）
• 第二类外部路由（Type 2 External）

OSPF对这几类的偏好顺序是：区域内 > 区域间 > 第一类外部 > 第二类外部。这意味着哪怕第二类外部路由的COST总值再小，它也没资格替换一条区域内的高COST路径，协议就是这么规定的，先看“身份”再看“开销”。

3.2 等价路由ECMP：当COST相同时会发生什么

如果两条不同链路的COST值计算结果一样，比如两条千兆链路在默认参考带宽下都是1，OSPF会把它俩作为等价路由同时放进路由表，然后基于流（Per-flow）做负载分担。这本来是一个挺好的功能，业务流量能同时利用两条链路。

但这里有个经典坑：物理链路规格不同，默认COST却相同。比如一条是千兆专线，另一条是百兆专线，在没改参考带宽的情况下，COST都是1，流量就会均分到两条链路上。结果百兆链路瞬间拥塞，千兆链路却闲着，业务体验一落千丈。这就是我开篇提到的“脑子里的直觉跟协议实际行为不一致”的典型场景。

解决思路就是在链路接口上显式设置不同的COST值，打破等价的局面，让流量按预期比例走。比如千兆口设COST为1，百兆口设COST为10，这样OSPF就乖乖走千兆了。

3.3 汇总LSA和特殊区域对选路的隐形影响

热词里提到的“OSPF特殊区域”也跟选路有关系。比如stub区域和nssa区域内的路由器，对外部路由的处理方式不一样。ABR（区域边界路由器）在向这些特殊区域下发默认路由或汇总路由时，会生成一个类型3的LSA，它的COST值设置多少，直接决定了区域内路由器去往外网时首选哪台ABR。

两台ABR都连着骨干区域，一台的COST是10，另一台是20，区域内的路由器统一走COST小的那台ABR。这就是典型的“ABR冗余设计有时不生效”的原因——你以为两台都活着，流量就会自动分担，实际上一台被全部流量打死，另一台闲得发慌，因为OSPF只选最优COST，不做主备状态下的负载均衡。

4. 实操演练：亲手掌控OSPF的“算计”方向

4.1 场景设定：双链路冗余下的选路控制实验

我在实验室里搭了一套简单的拓扑：两台路由器R1和R2，之间拉两条链路，一条GE（千兆），一条10GE（万兆）。业务要求所有大流量走万兆口，千兆仅作备份。

默认情况下把两条链路都宣告进OSPF，然后观察R1的路由表——display ospf routing，会发现去往R2的直连网段显示两条等价路由，COST值都是1。物理上带宽差了10倍，OSPF就是不认。

4.2 方案一：手动修改接口COST值，简单粗暴有效

在R1的GE口和R2的GE口上手动设置COST，再把万兆口COST设小一点：

[R1] interface GigabitEthernet0/0/0 [R1-GigabitEthernet0/0/0] ospf cost 100 [R1] interface Ten-GigabitEthernet0/0/0 [R1-Ten-GigabitEthernet0/0/0] ospf cost 10

同样的操作在R2上重复一遍。等OSPF邻居重新收敛后，再看路由表，R1到R2的网段只剩下一跳，走的万兆口COST为10，GE口被当作次优路径藏在协议路由表里，路径生效顺序会优先走10。如果万兆断了，COST为100的GE路由立刻顶上来，主备切换逻辑就出来了。

这里要重点说明：接口COST值必须在链路两端同时设置。这是一个新手极易踩的坑——只改了R1，没改R2，R1发给R2的LSA携带了接口COST，R2收到的COST是10（万兆），但R2这边万兆接口的COST还是默认的1。这么一来，两条方向上计算的路由开销就不再对称，有可能出现R1走万兆到R2、R2却走GE到R1的“三角路由”现象，流量绕一圈才到达对端。正常情况下我们能忍一忍，但在讲究对称的冗余链路里，行为不对称会带来一堆不可控的隐患。

4.3 方案二：调整参考带宽，从全局统一视角改变“算计”基准

如果不想一个个接口地设COST，可以修改OSPF进程下的参考带宽：

[R1] ospf 1 [R1-ospf-1] bandwidth-reference 10000 [R2] ospf 1 [R2-ospf-1] bandwidth-reference 10000

参考带宽调到10000Mbps之后，千兆接口的COST自动变成10，万兆接口变成1。比手工方案更省心，也不容易出错，而且整个区域统一使用一个基准，选路逻辑非常清晰。

经验之谈：实际项目中我更推荐统一调参考带宽的方式，而不是手工敲cost。手工cost的问题在于后期维护特别累，新增一条链路时你得记得补配置；而参考带宽是全局的，加新链路之后COST自动算好，逻辑一致。只有当个别链路需要特殊照顾（比如卫星链路、专线）时，再单独改接口COST，两者配合使用。

4.4 方案三：用ip ospf cost还是bandwidth？华三和思科的风格差异

如果你手头既有华三设备又有思科设备，要注意配置命令的差异。思科的接口模式里用的是ip ospf cost，华三用的是ospf cost；全局参考带宽配置，思科在路由器模式下用auto-cost reference-bandwidth，华三则在OSPF进程里用bandwidth-reference。虽然写法不同，但底层逻辑完全一样。

跨厂商环境里最怕的就是两台设备配置风格不统一，比如一边靠手工COST，一边靠默认值，选路结果就会各种奇葩。在混合组网里，我一般先把所有设备的参考带宽都调整为统一数值，作为选路基线，再根据需求微调个别接口，这样网络的可预测性会高很多。

5. 让选路符合预期：链路带宽与COST规划的几种实用手法

5.1 从网络拓扑设计角度规划COST：逐层递减原则

多层网络（核心-汇聚-接入）规划OSPF选路时，有个可以参考的原则：越靠近核心，期望承载流量越大的链路，COST值应当越小。

举个例子，接入交换机到汇聚交换机的上联链路，即使物理上也是万兆，如果希望流量优先走汇聚A再到核心，那在接入交换机上就把汇聚A链路的COST设置得比汇聚B低。这样就可以无感地引导跨机房的流量走指定路径，同时不影响路由层面的冗余性。实际项目里，我会给每个层次的链路建立一张COST规划表，比如：

这张表做完，整个网络OSPF的路径走向就完全在掌控中了。后面新增设备、新增链路，跟表对照着设参考带宽或者手工COST就行，不容易拍脑袋。

5.2 链路聚合与COST的耦合关系：不要把聚合后带宽想当然

很多人在核心汇聚之间跑了链路聚合（比如二层链路聚合或者三层Eth-Trunk），然后在OSPF里宣告这个聚合口。普遍认知是“聚合口带宽是成员口之和”，比如4条千兆绑成一个Eth-Trunk，总带宽4G。

但OSPF计算COST时，看的是逻辑口带宽的“名义值”。实际操作中，聚合口默认带宽不一定等于成员口总和，得看设备平台是否自动叠加。我在H3C设备上实测，聚合口的带宽有时候显示出的是成员口带宽之和，有时候则是取成员口最大带宽，跟设备型号、版本都有关系。如果不放心，直接看聚合口的display interface输出，再用公式算一下自动COST是多少，避免“以为聚合了就会自动负载均衡”的错觉。

5.3 环回口和Router-ID：选路之外最容易忽略的“暗桩”

热词里有“ospf 1 router-id 1.1.1.1”这种东西。Router-ID是OSPF进程的路由器标识，很多方案里大家都喜欢把环回口地址配成1.1.1.1或x.x.x.x，用来做Router-ID。但这玩意儿虽然叫Router-ID，它的物理接口网络（LoopBack）也会被宣告进OSPF，而且环回口有一个特殊属性：OSPF宣告环回口时，无论你loopback接口的掩码是多少，LSA里都会把它当作主机路由（/32）通告出去，除非显式改了接口网络类型。

环回口对选路的间接影响在于：它常被用来作为telnet/SNMP网管地址，当OSPF在物理链路之间选路时，网管地址往哪里走，取决于那台路由器去往管理中心网段的最优COST。如果你的环回口是/32主机路由，它不参与物理链路的选路，但在跨区域NSSA或普通区域注入时，一旦ABR对环回口路由做汇总，可能会改变区域内路由器对这台设备的访问路径。规划环回口时，建议单独划一个网段，并为网管流量专门设计OSPF汇总路由，避免这些“额外路由”干扰业务流量的选路大局。

5.4 OSPF与MSTP、VRRP联动的日常：不要让COST成了“背锅侠”

热词里的“ospf mstp vrrp”通常出现在园区网或数据中心接入层。MSTP负责二层防环，VRRP负责网关冗余，OSPF负责三层路由。这几者联动时，最容易出现的诡异现象是：VRRP主备切换后，业务流量跨三层走时，OSPF的COST没有变，但二层拓扑变了，导致实际转发路径跟OSPF最优路径对不上。

遇到这种情况，不要第一时间怀疑OSPF选路出了问题，先看MSTP的根桥位置和VRRP主设备是否在同一台物理交换机上。若根桥和VRRP主不一致，流量进到二层后可能被MSTP阻塞端口挡了一下，或者绕路到另一台设备的三层口出去，表现出来的效果就跟“OSPF选路不准”一样。实际上OSPF的COST计算一点问题都没有，问题出在二三层联动策略上。

6. 排错案例：实测中OSPF选路异常的几个真实场景

6.1 案例一：参考带宽不一致引发的“环回口路由翻车”

有一次在某机房割接，一台新核心上线，另一台老核心还在跑，两台的OSPF进程都是进程1，区域0。老核心的参考带宽一直是默认100M，新核心的配置文件模板里顺手写了一条bandwidth-reference 10000，因为模板是照搬另一个项目的。

结果整个区域里，所有经新核心通告的路由COST计算口径都不一样了。老核心看到新核心通告的某些路由COST大了10倍，老核心就硬生生把去往那些网段的流量导去了远端另一台汇聚设备，整条链路绕了大半个园区。看OSPF邻居，一切正常，LSDB也同步，但路由表的路由就是“歪”的。

排查方法很简单：在所有设备上执行display ospf brief，对照一下每台设备的Reference Bandwidth参数，不一致就先统一。我当时花了半天在查接口COST和链路质量，最后翻到OSPF进程参数才抓到真凶。

6.2 案例二：万兆链路与千兆链路等COST导致的负载不均衡

数据中心场景，服务器接入交换机到核心交换机有两条上联：一条万兆，一条千兆。没有调参考带宽，默认COST都是1，OSPF把两条链路做成了等价负载分担。结果万兆口流量利用率20%，千兆口已经跑到95%，交换机CPU的转发队列开始丢包，业务时延猛增。

这个案例很典型，不是因为OSPF选路“选错了”，而是因为选路“没拉开差距”。等价路由不区分带宽权重，OSPF负载分担默认是等价的，接口速率不同却等COST，就出现了这种物理资源浪费。我的处理方式是全局改参考带宽到10000，让两条链路的COST变成1和10，等价路由自动消失，全部流量切上万兆口。千兆口保留作冗余备份，冗余性没有损失，而主用链路的拥塞问题立刻解决。

6.3 案例三：Type 2外部路由COST的“只看通告者”陷阱

OSPF引入外部路由时，如果用的是Type 2（默认就是Type 2），那么整条外部路由的开销计算有个容易忽略的规则：外部路由的COST值只看ASBR（自治系统边界路由器）通告的那条External LSA里的开销，沿途各路由器累加的链路开销不算在内。

这意味着，如果两台ASBR同时引入同一条外部路由，COST小的那台会吸引全部流量，哪怕到达那台ASBR的链路已经拥塞不堪，OSPF也不会帮流量切换到另一台ASBR。因为Type 2外部路由的选路根本不比较到达ASBR的路径长度。

遇到这类需求，建议把外部路由改成Type 1，让OSPF把链路COST也算进去。在H3C设备上，在ASBR引入外部路由时使用import-route static type 1之类的命令就能实现。这个细节经常被忽略，但它对选路结果的影响非常大。

7. 常见问题速查与我的排错习惯

整理几个项目里反复遇到的OSPF选路相关问题和解决思路，做成速查表方便大家日后排错。

我在实际运维中的几个习惯，分享出来供参考。第一，全局参考带宽一旦定下来，就写进配置基线文档，任何设备上线前必须先核对这一项。第二，想要控制某条具体路径，优先考虑接口COST，但一定在链路两端同时设置，并在变更后查看OSPF路由表确认效果。第三，链路聚合的COST不要凭感觉猜，登录设备看接口带宽的显示值再判断。第四，遇到选路异常时，不要第一时间怀疑COST，先确认LSA是否一致、邻居状态是否稳定、二层拓扑是否有变化，再回到数值层面排查。

8. 我踩过几次坑之后的个人体会

OSPF的选路机制，最反直觉的地方在于它“看不见”带宽。你花大价钱升级了链路，如果不手动调整COST值，OSPF根本不为所动。弄懂了这一层，很多看似“路由选择不合理”的问题就都解释得通了：不是OSPF傻，是它守着协议设计之初的规则在做事。

我在实际项目中有一个屡试不爽的经验：在OSPF域内做任何链路带宽升级时，顺手把带宽参考值也一并调整，并全网统一。千兆和万兆混合的网络尤其如此。好多人只升级物理线路，忘了管路由器“心里”的那杆秤，结果升级完带宽，流量却还是挤在小带宽链路上，业务没有任何体感改善，最后还得回头调OSPF参数。

关于选路测试，建议在割接或调整后，用tracert或display ospf routing验证实际转发路径。OSPF是纯链路状态协议，它的路由计算是全局性的，有时候你以为改的是“一条路”，实际影响的是整个区域里所有设备的路径决策。变更前做好配置备份，变更后多做几组路径验证，比翻来覆去看文档都管用。

搞懂了COST、参考带宽、等价路由这些细节之后，再去看那些网络中“诡异”的绕路现象，很多都能一眼看穿了。OSPF选路这套“算计”并没有多高深，拆开揉碎，无非就是一套数值博弈的规则，而你掌握了这套规则之后，就能真正成为网络路径的“操盘手”。