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值计算过程10Mbps10100 / 10100Mbps1100 / 1001000Mbps1G1100 / 1000 0.1取整为110000Mbps10G1100 / 10000 0.01取整为1看到问题了吧。千兆和万兆链路计算出来的COST值都是1因为默认参考带宽只有100M合着万兆的口跟百兆的口在OSPF眼里地位一样都是1的花销。这就是很多人说的“OSPF不认万兆”的根源。2.2 为什么参考带宽是100M历史包袱与现实问题这个100Mbps的默认值是上世纪OSPF协议设计时的产物那时候百兆链路已经是顶级配置了以太网、快速以太网横行100M当基准完全够用。到了千兆普及、万兆走进数据中心之后这个默认值明显跟不上时代了所有高速接口算出来的COST都一样OSPF就丧失了在高速链路之间做差异化选路的能力。那怎么办改参考带宽。在接口上设置不同的cost太麻烦更合理的做法是全局调整参考带宽让公式在高速链路下依然能拉开差距。比如把参考带宽调到10Gbps即10000Mbps那一条千兆链路的COST就是10000/100010万兆就是10000/100001两者就分出了明显的高低。注意调整参考带宽时必须保证整个OSPF域内所有路由器保持一致。我在现网见过只改核心设备、没改接入设备的情况结果就是区域内计算出来的路径开销不一致出现环路和次优路由排错排到怀疑人生。2.3 带宽、COST和选路的实际关系一个生活化类比可以这么理解COST和带宽的关系COST不是“速度值”而是“花费值”。同样是去一个地方打车千兆链路花10块钱坐公交百兆链路花1块钱如果不看体验只看价格OSPF毫不犹豫选公交哪怕公交绕路要坐两个小时打车直线只要二十分钟。选路决策只认花费高低不认到达速度。所以在网络设计里想用带宽大的链路承载更多流量不能只把物理带宽提上去还得动手把这条链路的COST值“教”给OSPF——要么改参考带宽要么手动指定接口COST。否则路由器不会理睬你花了多少钱买的那根万兆光纤。3. 选路博弈的关键参与者COST之外还有哪些“裁判”3.1 优先级第一关OSPF外部路由跟内部路由不能只看COSTOSPF协议里路由条目分了三六九等不是所有路由都比COST。一条路由能不能进路由表、用哪条作为最优首先要看它的路由类型优先级然后才轮到COST值比大小。拿华三的设备来说路由表里有一个“Preference路由优先级”的概念这是不同路由协议之间的比拼比如静态路由优先还是OSPF优先取决于厂商默认优先级的大小范围是整个路由协议维度。在OSPF协议内部又分为区域内路由Intra-Area区域间路由Inter-Area第一类外部路由Type 1 External第二类外部路由Type 2 ExternalOSPF对这几类的偏好顺序是区域内 区域间 第一类外部 第二类外部。这意味着哪怕第二类外部路由的COST总值再小它也没资格替换一条区域内的高COST路径协议就是这么规定的先看“身份”再看“开销”。3.2 等价路由ECMP当COST相同时会发生什么如果两条不同链路的COST值计算结果一样比如两条千兆链路在默认参考带宽下都是1OSPF会把它俩作为等价路由同时放进路由表然后基于流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为10GE口被当作次优路径藏在协议路由表里路径生效顺序会优先走10。如果万兆断了COST为100的GE路由立刻顶上来主备切换逻辑就出来了。这里要重点说明接口COST值必须在链路两端同时设置。这是一个新手极易踩的坑——只改了R1没改R2R1发给R2的LSA携带了接口COSTR2收到的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规划表比如链路位置物理带宽预期用途COST设定核心到核心40GE捆绑高可用主链路1核心到汇聚主10GE主用上联10核心到汇聚备10GE备用上联50接入到汇聚1GE常规接入100这张表做完整个网络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都是1OSPF把两条链路做成了等价负载分担。结果万兆口流量利用率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相同走了ECMP查看路由表出现两条等价路由调整bandwidth-reference或手工设置接口cost新核心上线后路由绕路新老核心参考带宽不一致对比display ospf进程参数统一全局参考带宽OSPF路由表正常但业务VRRP网关出方向异常二层MSTP拓扑和三层OSPF最优路径不匹配检查MSTP根桥与VRRP主是否同机调整二层阻塞端口或VRRP主设备位置外部路由总走同一台ASBRType 2外部路由只比通告开销不比内部链路查看引入路由的type类型改为type 1使链路COST参与累计手工改了cost但路由不变改了非所有路径或两端不一致在链路两端分别查看接口cost两端同步配置检查LSA中的cost字段OSPF邻居正常但ping丢包或绕路实际物理断开但聚合接口逻辑未断查看聚合口的成员口状态检查Eth-Trunk链路成员配置我在实际运维中的几个习惯分享出来供参考。第一全局参考带宽一旦定下来就写进配置基线文档任何设备上线前必须先核对这一项。第二想要控制某条具体路径优先考虑接口COST但一定在链路两端同时设置并在变更后查看OSPF路由表确认效果。第三链路聚合的COST不要凭感觉猜登录设备看接口带宽的显示值再判断。第四遇到选路异常时不要第一时间怀疑COST先确认LSA是否一致、邻居状态是否稳定、二层拓扑是否有变化再回到数值层面排查。8. 我踩过几次坑之后的个人体会OSPF的选路机制最反直觉的地方在于它“看不见”带宽。你花大价钱升级了链路如果不手动调整COST值OSPF根本不为所动。弄懂了这一层很多看似“路由选择不合理”的问题就都解释得通了不是OSPF傻是它守着协议设计之初的规则在做事。我在实际项目中有一个屡试不爽的经验在OSPF域内做任何链路带宽升级时顺手把带宽参考值也一并调整并全网统一。千兆和万兆混合的网络尤其如此。好多人只升级物理线路忘了管路由器“心里”的那杆秤结果升级完带宽流量却还是挤在小带宽链路上业务没有任何体感改善最后还得回头调OSPF参数。关于选路测试建议在割接或调整后用tracert或display ospf routing验证实际转发路径。OSPF是纯链路状态协议它的路由计算是全局性的有时候你以为改的是“一条路”实际影响的是整个区域里所有设备的路径决策。变更前做好配置备份变更后多做几组路径验证比翻来覆去看文档都管用。搞懂了COST、参考带宽、等价路由这些细节之后再去看那些网络中“诡异”的绕路现象很多都能一眼看穿了。OSPF选路这套“算计”并没有多高深拆开揉碎无非就是一套数值博弈的规则而你掌握了这套规则之后就能真正成为网络路径的“操盘手”。