OSPF选路不换路？一文讲透带宽与COST值计算原理及排错实战

1. 加宽了链路却没换路OSPF选路最容易被误解的地方先说一个我亲身经历的现场。某次核心网割接同事把两条互联链路从千兆分别升到了万兆链路起来之后业务一切正常但查看路由表却发现OSPF的下一跳一条都没变流量依旧压在原来那条千兆链路上新升级的万兆链路空转。团队里几个人围着设备看了半天第一反应都是“OSPF是不是没感知到带宽变化”还有人怀疑是链路聚合没生效。其实OSPF感知链路带宽的能力远比大家想象得要“间接”。它根本不直接读接口的物理速率也不像EIGRP那样把带宽、延迟、负载、可靠性全部塞进一个复合度量里。OSPF的选路只看一个东西——COST值开销而带宽只是用来计算COST的一个“原材料”。换句话说带宽变了COST不一定变COST变了路由才可能变。搞清楚这条逻辑链很多看似诡异的路由问题就迎刃而解了。这篇文章我打算把OSPF选路里关于带宽与COST这条线彻底讲透包括计算原理、不同厂商的默认差异、排错时怎么定位“为什么改了带宽路由不变”以及除了改带宽之外还有哪些更直接的选路控制手段。适合正在学OSPF的网工、刚接手园区或数据中心网络的运维朋友也适合那些被“升带宽不换路”这类问题困扰过的人。2. COST值的计算逻辑为什么带宽明明是“原材料”却不直接参与比较2.1 OSPF度量值的本质一条路径的累加开销OSPF的COST本质上是一个接口出方向的开销从源到目的经过的所有接口出方向COST相加就是整条路径的开销。路由器比较不同路径的COST总和取最小的那条放进路由表。这个机制和RIP的跳数累加非常像不同的只是RIP把每一跳都当成等值的1而OSPF希望每一跳能反映出链路的“贵贱”程度。问题来了用什么来衡量一条链路“贵”OSPF选择的是带宽。带宽越高理论上转发能力越强这条链路应该越“便宜”。但协议设计者没有直接在报文里携带带宽值而是设计了一个公式COST 参考带宽 ÷ 接口带宽参考带宽是一个固定基准值接口带宽是这条链路对应的带宽值。这样算出来的结果是个无量纲的数字路径上的这些数字累加就是选路依据。参考带宽越大高带宽链路和低带宽链路之间的COST差距越明显参考带宽越小不同速率链路的COST差距就会被压缩甚至完全看不出区别。2.2 参考带宽默认值的“时代烙印”早期OSPF设计时参考带宽默认是100 Mbps。那个年代百兆已经是主流高速接口把百兆作为基准是合理的。在这个基准下接口速率COST值采用默认参考带宽100Mbps10 Mbps10100 Mbps11000 Mbps千兆110000 Mbps万兆1看到问题了吗千兆和万兆算出来都是1。因为100 ÷ 1000 0.1但COST不能是小数协议里只保留整数部分结果就是1万兆更不用说100 ÷ 10000 0.01同样是1。也就是说在默认参考带宽下凡是速率大于等于100Mbps的接口COST值全部相等。千兆链路和万兆链路在OSPF眼里没有任何区别这就是“升带宽不换路”的根本原因——你把物理带宽从千兆升到万兆但OSPF计算出的COST从1变到1路由表当然纹丝不动。2.3 接口带宽从哪里来逻辑值而非物理值这里还要强调一个容易踩坑的点公式里用的“接口带宽”不是接口的物理实际速率而是接口配置的逻辑带宽值。在Cisco设备上这个值来自接口下的bandwidth命令默认情况下千兆口显示为1000000Kbps万兆口显示为10000000Kbps。在华为设备上类似概念是接口的“带宽”属性也可以通过命令调整。物理速率变了逻辑带宽如果不跟着改OSPF的COST计算同样感知不到。反之你甚至可以在一根百兆物理链路上把逻辑带宽改成1000000让OSPF认为它是千兆链路从而影响选路——这在临时调整流量分担时偶尔会被用到但要非常谨慎因为逻辑带宽还影响着QoS、流量整形等其他特性。注意COST公式里的带宽单位需要统一。日常运维中我们习惯说“千兆”、“万兆”但设备配置里带宽单位通常是Kbps计算时换算要仔细别出现数量级错误导致COST值完全不符合预期的情况。3. 修改参考带宽让OSPF真正“看得见”高速链路3.1 参考带宽修改命令与全局生效机制既然默认参考带宽只能区分到百兆那要区分千兆、万兆甚至更高速率最直接的办法就是把参考基准往上抬。以主流厂商的操作为例在OSPF进程下配置router ospf 1 auto-cost reference-bandwidth 10000参考带宽的单位是Mbps10000表示把基准设为10Gbps。修改后各速率接口的COST值会变成下面这样接口速率参考带宽100Mbps时参考带宽1000Mbps时参考带宽10000Mbps时10 Mbps101001000100 Mbps1101001000 Mbps111010000 Mbps111能看到参考带宽提高到1000Mbps后千兆链路COST为1百兆链路为10两者能区分开但千兆和万兆仍然都是1。再提高到10000Mbps万兆成为1千兆变成10。所以参考带宽一定要和网络中最高速率的链路匹配否则高速链路之间依然“平等”。华为设备上类似命令格式稍有不同但思路一样建议组网里统一参考带宽时先确认版本和命令差异不然在割接窗口里手忙脚乱查命令非常被动。3.2 修改参考带宽的连锁反应所有路由重新计算很多人在修改参考带宽后会发现一个问题配置敲下去路由表没有立刻刷新。这不是没生效而是OSPF的SPF计算默认不会因为COST规则变化而自动重算。老练的工程师一般会在修改后执行OSPF进程重启让所有路由器重新计算整网路径。实际操作中常见两条命令clear ip ospf process或者通过shutdown/no shutdown重置OSPF进程。需要注意在核心设备上执行这类操作会造成OSPF邻居震荡瞬间的路由抖动在所难免。如果是在业务高峰期务必评估影响最好维护窗口内操作。这里还隐藏着一个很微妙的点参考带宽必须全网一致。OSPF区域内所有路由器用同一套“货币汇率”计算路径成本如果一台设备参考带宽是1000另一台是10000那么同一段物理链路在两台设备眼里“贵贱”完全不同算出来的路径优劣就会互相矛盾轻则出现次优路径重则产生环路风险。排错时如果发现路由奇奇怪怪先全局检查一下各设备的auto-cost reference-bandwidth是否一致。我在现网见过因为新旧设备配置模板不同参考带宽一边是100、一边是10000导致核心链路长期绕远路的案例改齐之后整个网络的路由都变得清爽了。3.3 参考带宽设置多大的“度”才合适参考带宽并不是越大越好。设得太大会带来一个副作用低速链路比如10Mbps、百兆的COST值变得非常大路径开销的数字一旦上了千、万级别阅读路由表和定位问题就变得费劲。比如参考带宽设为100000100Gbps时10Mbps链路COST是10000日志和路由表里一串大数字直观性大打折扣。建议参考带宽定在全网最高链路速率的一到两个数量级范围内既能区分高速链路又不会让低速链路COST膨胀到难以阅读。我在项目中常用的做法是先梳理全网链路速率清单把最高速率找出来然后参考带宽取最高速率的1到10倍。比如全网最高是万兆就设10000如果考虑未来两三年可能上25G甚至100G可以留余量设成100000。别盲目跟网上的模板走一切以自己网络的现实为准。4. 除了参考带宽哪些因素仍在偷偷影响COST值4.1 手工指定COST选路控制的高权限手段修改参考带宽属于“批量调整汇率”影响全局所有链路。但有些时候我们只想让某一条链路在选路中“变贵”或“变便宜”不想动全局这时候就要用接口级COST覆盖。最直接的手工指定命令interface GigabitEthernet0/1 ip ospf cost 50这条命令的含义是该接口出方向的OSPF开销直接定为50完全忽略带宽和参考带宽的计算结果。手工COST的优先级高于自动计算这一点在处理不对称路由、临时疏导流量时特别好用。举个例子某企业有两条到数据中心的链路一条千兆专线一条万兆专线。正常情况下参考带宽调整后万兆链路COST更小流量集中走万兆。但某段时间万兆链路的对端设备在做版本升级虽然协议还活着但性能明显下降。你不想动物理链路又想让流量暂时回千兆直接在万兆接口上把COST调大比如从1改到20选路立刻切换。等对端升级完成再把COST改回来一条ip ospf cost命令就完成了整个流量的“交通管制”。4.2 环回口与虚链路COST值中的特殊存在OSPF对**环回口Loopback的处理有个特殊规则值得单独说。环回口在OSPF里被通告时默认当成主机路由/32**处理它的COST值固定为1而且不受参考带宽影响。这个设计背后的意图很清晰环回口是设备的逻辑标识代表路由器自身优先级应当最高选路时任何真实物理链路都不应该比“路由器自己”更近。这个特性在实际排错中经常给人惊喜。比如某台设备上有两条路径都能到达对端设备的环回口地址物理路径的COST总和都大于1那么OSPF会认为“到达环回口本身”就是最优的路由会指向设备本地导致某些基于环回口建立的隧道或管理通道出现意料之外的路径选择。虚链路Virtual Link同样有特殊的COST处理。虚链路在两台ABR之间建立时它的COST被设置为经过的骨干区域内部路径的COST总和也就是说虚链路本身的“价格”取决于它穿越的那段区域内部的路径质量。很多人配置虚链路后只关心它Up没Up很少细看COST但实际上虚链路的COST直接决定了跨区域路径选路是否合理。如果发现跨区域流量绕路有必要把虚链路经过区域的COST也纳入排查范围。4.3 参考带宽、接口手工COST与带宽命令的优先级排序常有人把接口下的bandwidth命令、ip ospf cost命令、全局auto-cost reference-bandwidth命令三者混为一谈分不清谁听谁的。这里给出一张优先级表方便记忆配置方式作用对象优先级接口ip ospf cost单个接口的出方向开销最高直接生效全局auto-cost reference-bandwidth所有接口的自动开销计算基准中间影响所有未手工覆盖的接口接口bandwidth仅作为自动计算时的带宽取值最低间接影响COST用一句话概括手工指定永远最大参考带宽定汇率bandwidth只是汇率计算中的输入项。理解了这三者的关系配置和排错时就不会被各种“看起来能改选路”的命令绕晕。5. 排错实录从“带宽没生效”到锁定COST异常的完整链路5.1 问题现象与初步判断回到文章开头的那个割接场景。链路从千兆升万兆后OSPF路由未变当时有位同事坚持认为“OSPF应该能自动识别物理速率肯定是设备有隐藏的开关没打开”。我让他先在设备上验证一下OSPF对这两条链路算出的COST命令如下show ip ospf interface GigabitEthernet0/1 show ip ospf interface GigabitEthernet0/2输出里直接看Cost字段结果两条链路的Cost都是1。这时候问题已经清楚了一半物理带宽确实升了但OSPF看到的COST没有任何区别。接下来需要确认原因究竟是参考带宽过小还是接口逻辑带宽没跟着变。两步走show running-config interface GigabitEthernet0/1 show running-config | include reference-bandwidth结果显示接口逻辑带宽已经正确识别为万兆但OSPF进程下没有配置auto-cost reference-bandwidth用的是默认的100。也就是说问题就出在参考带宽上——千兆和万兆在默认基准下都是1路由当然不会变。5.2 定位COST不一致的“非对称”问题修好参考带宽之后路由确实切换到了万兆链路但不到半小时又接到告警说部分业务访问出现时延抖动。再次查看路由表发现流量被分摊到了两条链路上。这其实就是**等价负载均衡ECMP**在起作用两条路径的COST总和相等OSPF就把流量均分。当时两条路径分别是路径A通过两台千兆设备中转到目的地路径B直连万兆链路到目的地。按直觉判断万兆直连应该比千兆中转更快但路由表里显示两条路径开销相等。逐跳查看COST之后发现问题出在路径B经过的一台老设备上该设备没改参考带宽万兆接口算出的COST仍然是1但路径A上的中转设备改了参考带宽每个千兆接口COST变成了10路径A总COST为20。按道理路径B应该胜出可实际上路径B上的老设备把万兆接口COST也算成1加上其他接口开销也小最后两条路径COST总和恰好相同形成了ECMP。这类问题的隐蔽性在于不是所有设备都采用了相同的参考带宽配置。排查方法很简单全网登陆设备执行同一命令导出所有设备的参考带宽值做核对重点排查新老设备混用的网络。把老设备的参考带宽也改成一致后ECMP消失流量正确压上万兆直连链路。5.3 COST值计算的常见数量级错误再分享一个我自己踩过的坑。有次配置参考带宽时把auto-cost reference-bandwidth 10000理解成了“参考带宽是10000Kbps”也就是10Mbps结果百兆接口COST直接算成10千兆接口COST算成1万兆接口还是1。整张路由表看起来“大体合理”特意对比的几条路径却怎么都对不上。后来才反应过来命令里的单位是Mbps不是Kbps。10000单位是Mbps也就是10Gbps不是10Mbps。这种单位上的数量级差异轻则让选路不符合预期重则整网路由振荡。现在我在配置参考带宽时有个习惯先在白板上算出目标速率对应的COST值再敲命令敲完立刻用show ip ospf interface抽查两三个关键接口的Cost字段确认和预期一致再继续下一步。这个习惯已经帮我避免了好几次潜在事故。6. 选路控制三板斧改带宽之外的实用调整手段6.1 接口COST微调单点控制流量去向前面提过ip ospf cost可以手工指定接口开销这里展开讲讲实战中的用法。假设你有一个双链路上联的场景两条链路一条是100Mbps专线一条是1Gbps宽带业务上希望大部分流量走专线但宽带作为备份。单纯靠OSPF自动计算1Gbps链路的COST一定比100Mbps小流量会优先走宽带这不符合业务诉求。两个办法要么把参考带宽调小让100Mbps的COST和1Gbps的差距不那么悬殊但这是全局动作影响面大要么直接在专线接口上手工指定一个更小的COST比如ip ospf cost 1让它“稳赢”。这种单点精确控制方式比全局调汇率更安全、更直观而且改动影响范围只限于该接口所在的路由非常容易回滚。手工指定COST还有一个隐藏用法模拟链路拥塞。有时候你需要验证网络在“某条路径劣化”时是否具备自动切换能力又不想真把链路拔了。直接把接口COST临时调大比如从1调到1000OSPF会立刻认为这条路径不可用触发切换到备用路径。验证完成后改回原值整条链路的物理状态没有任何变化可以说是一种非常干净的故障演练手法。6.2 通过带宽命令“欺骗”选路双刃剑用法bandwidth命令可以修改接口的逻辑带宽进而影响OSPF自动计算的COST。在参考带宽已设置的前提下把某条接口的逻辑带宽调高COST就会变小流量倾向走这条链路。这种“欺骗”手段在某些场景下比手工COST更优雅因为所有计算仍然是自动的路径开销的数值体系保持一致不会出现手工COST导致的“局部数值断层”。但使用bandwidth命令必须非常小心因为它影响的不仅是OSPF。QoS队列调度、流量整形、部分厂商的链路利用率计算甚至一些基于带宽的监控告警都会跟着变。我曾经在一台设备上为了调OSPF选路把接口带宽调高结果第二天监控平台报出这条链路利用率异常偏高——监控系统拿逻辑带宽当分母计算利用率逻辑带宽翻了十倍利用率数据当然全乱了。所以涉及bandwidth的调整务必先梳理这台设备上哪些特性会读取该参数。6.3 汇总路由与路由策略从源头压缩COST的影响范围还有一种选路控制思路不是去调COST本身而是改变路由的可见性。OSPF的区域设计天然支持路由汇总在ABR上使用area range命令把多个细路由聚合成一条汇总路由通告出去。汇总路由的COST是各明细路由中最小COST的那个这个特性在选路时往往能大幅简化决策。举个例子某区域内部有10条链路各明细路由COST从1到20不等。如果不做汇总区域的出口路由器要为这10条路由分别计算路径做了汇总后外部只需看到一条路由它的COST取最小值1。这不仅减少了路由表规模、降低了SPF计算压力也在一定程度上“隐藏”了区域内部链路的细微差异防止外部流量因为内部某条链路抖动而频繁切换路径起到了天然的稳定性作用。如果汇总还不够还可以上路由策略。比如基于源地址或目的地址段在边界设备上通过策略路由强制部分流量走指定下一跳或者通过修改路由属性如给特定路由加一个管理距离来影响OSPF与其他协议之间的优先级。这些手段已经超出了OSPF本身属于跨协议选路控制但在复杂网络中往往比单纯调COST更灵活有效。我的建议是能通过COST解决的就通过COST解决COST解决不了再考虑策略手段越简单后期维护越省心。7. 关于OSPF选路我的一点运维心得其实OSPF选路的本质并不复杂一句话就是“以COST为标准取最优路径”。但COST这个数值是怎么来的、什么时候不变、什么时候突变里面藏着许多容易被忽略的细节。我对团队新人的要求很简单遇到路由选择不符合预期第一步永远不要急着改配置先查看设备到底是怎么算的把show命令的输出看明白再动手。几个值得反复强调的老经验参考带宽必须全网一致这是最基础也最容易出错的一条接口带宽是逻辑值不是物理值别在割接窗口里想当然手工COST是精细控制的好工具但要有文档记录否则人走茶凉后没人知道当年为什么把这个接口设成了50。如果这篇文章能帮你在下次遇到“升带宽不换路”的诡异现象时少走一点弯路那我觉得这些文字就值了。网络里的每一次路由切换背后都是OSPF在用自己的方式“算计”着走向最优的路径而我们作为运维的人只需要比它更了解它的算法。