登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  linux

Linux ip route 里 metric 相同时怎么判断默认路由

来源:17golang原创

时间:2026-09-08 18:22:13 277浏览 收藏

Linux 里看到两条 default 路由的 metric 相同,不能简单按 ip route 的显示顺序判断“第一条优先”。正确顺序是:先看目标地址命中了哪个最长前缀;如果都属于同一个前缀,再比较 metric;如果仍然相同,就要把它当成等价路径或未明确的并列候选,用具体目标地址查询实际出口。

要点速览
  • 0.0.0.0/0 只是兜底路由,更具体的网段会先胜出。
  • 同一前缀内,metric 数值越小,优先级通常越高;相同 metric 不等于稳定主备。
  • 排查时组合使用 ip route showip rule showip route get

先按最长前缀判断候选范围

假设访问目标是 8.8.8.8。路由表里同时出现 8.8.8.0/248.8.8.8/32 和两条 default,它们并不是四条路线直接比较。前缀越长,匹配越具体;/32 会先于 /24,而 /24 又先于 0.0.0.0/0

所以“metric 相同的默认路由怎么选”这个问题,第一步不是改 metric,而是确认目标真的没有命中更具体路由。IPv6 的对应兜底前缀是 ::/0,不要把 IPv4 和 IPv6 的结果混在一起看。

Linux 路由先按最长前缀筛选,再比较默认路由 metric 的关系图
图1:Linux 先用最长前缀缩小候选,metric 只在同一匹配前缀内比较。

用 ip route show 和 ip route get 还原候选

先看主路由表里的默认路由,但不要把这一步当成最终答案:

# 查看 IPv4 主表中的默认路由和完整字段
ip -4 route show table main

# 查看规则链,确认是否会先跳到其他表
ip rule show

# 对真实目标做一次 FIB 查询
ip -4 route get 8.8.8.8

# 需要展开匹配信息时,要求 iproute2 支持 fibmatch
ip -4 route get 8.8.8.8 fibmatch

ip route show 告诉你配置中有哪些候选;ip route get 才是在给定目标、源地址、标记和入口条件下询问内核“这一个包会怎么走”。输出中的 viadev 和可能出现的 src,比列表排列顺序更适合用来定位问题。

观察项它回答的问题常见误判
前缀目标是否命中更具体的路由只盯着 default
metric同一前缀内哪条偏好更高把相同值当成主备顺序
ip rule / table实际查询使用哪套路由表只看 table main
via / dev / src本次查询最终得到的出口用旧连接或旧缓存推测
ip rule、主路由表、FIB 查询与等价路径之间关系图
图2:先查看路由表与规则,再用具体目标地址做 FIB 查询,才能知道实际 via 和 dev。

metric 相同不是稳定主备

metric 是路由偏好值,较小的值更优。但当两条默认路由的前缀和 metric 都相同,它们已经处在同一优先级层级。此时不要根据“哪条写在前面”设计业务逻辑:Linux 可能把它们作为等价多路径处理,实际选择还会受到内核多路径哈希、地址族和下一跳状态影响。

如果目标是负载分担,应明确写成一条多下一跳路由,让配置意图可读:

# 两条等价出口组成一条 multipath 路由;weight 可表达相对比例
ip route replace default \
  nexthop via 192.0.2.1 dev eth0 weight 1 \
  nexthop via 198.51.100.1 dev eth1 weight 1

如果目标是主备,则给备用出口一个更大的 metric,并在变更后再次查询:

# 主出口 metric 更小,备用出口只在主出口不再可用或策略改变时参与
ip route replace default via 192.0.2.1 dev eth0 metric 100
ip route replace default via 198.51.100.1 dev eth1 metric 200

# 不依赖列表顺序,直接验证目标地址的选择
ip route get 8.8.8.8

这里的“备用”不是健康检查系统的完整故障转移保证;链路状态、邻居解析、路由守护进程和策略规则都可能改变结果。metric 只表达路由偏好,不负责替你判断应用层网关是否健康。

检查规则、路由表和地址族

ip route show table main 与业务实际出口不一致时,优先检查四个边界:

  1. 是否存在更靠前的 ip rule,把特定源地址、fwmark 或接口流量导向了其他表。
  2. 是否查询了 table main,但实际使用的是自定义表、VRF 关联表或 local 表。
  3. 是否漏写 -4-6,把 IPv4 的 default 和 IPv6 的 ::/0 混为一谈。
  4. 是否只看静态列表,遗漏了路由协议、网络管理器或容器网络后来安装的路线。

实战中可以固定一组最小记录:目标地址、源地址、命中的规则、路由表、前缀、metric、via、dev。这样即使下一次网络重连后列表顺序变化,也能复现“为什么走这条路”的判断过程。

常见问题

两条 default 的 metric 都是 100,为什么每次看起来都走同一条?

可能是流哈希保持稳定,也可能其中一条并没有真正进入同一张表或同一个地址族。先用 ip rule showip route get 逐个目标验证,不要用一次 ping 推断全局规则。

把备用路由改成 metric 200 就一定会自动切换吗?

不一定。它只改变候选偏好;能否切换还取决于主路由是否被删除、链路和邻居是否失效,以及管理组件是否重新安装路由。需要可靠切换时,应把链路探测和路由收敛机制一起设计。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>