linux不原生支持ospf，排查分两类：一是仅接收上游ospf路由，需检查路由注入、转发及策略干扰；二是运行frr等套件，需逐层验证服务、邻居状态与路由计算，并注意mtu、router-id等细节。
Linux本身不原生运行OSPF协议栈，标准内核不支持OSPF邻居建立、LSA泛洪或SPF计算。所谓“Linux中排查OSPF路由故障”，实际场景通常有两类：
- Linux作为纯转发节点（如防火墙、网关）：仅参与静态/策略路由，OSPF由上游路由器（如Cisco、华为、VyOS、FRR设备）运行，Linux只接收并使用其下发的路由；
-
Linux运行FRR或Quagga等开源路由套件：此时OSPF由用户态进程（如
frr中的ospfd）实现，具备完整OSPF功能，可真正参与邻居协商与路由计算。
下面按这两种典型情况分别说明排查要点：
Linux只接收OSPF路由（无OSPF进程）
这类环境常见于企业出口防火墙、旁路监控节点或基于Linux的SD-WAN CPE。OSPF本身不在Linux上跑，但路由表里出现OSPF学习到的路由（比如通过ip route show看到proto ospf条目），说明上游设备已将路由通告过来，并经由某种机制（如BFD+静态注入、Netlink同步、或FRR代理）写入内核路由表。
排查重点是验证路由是否到达、是否被内核接受、是否影响转发：
- 查看路由来源和协议类型：
ip route show proto ospf
若无输出，说明OSPF路由根本未进入内核——问题在上游或同步机制。 - 检查上游OSPF设备是否真把路由发出来了：
登录对端路由器，执行show ip route ospf或display ospf routing，确认目标网段存在且状态为Active。 - 验证Linux是否启用了对应接口的转发与ARP：
sysctl net.ipv4.ip_forward应为1；ip neigh show dev eth0确认下一跳MAC已解析（避免“黑洞”转发）。 - 检查是否有策略路由或iptables干扰：
ip rule show和iptables -t mangle -nvL PREROUTING可能篡改路由决策或丢弃报文。
Linux运行FRR（含ospfd进程）
这是真正具备OSPF能力的Linux场景。FRR是当前主流选择（Quagga已停止维护），需确保ospfd服务正常运行。
排查分三层，逐级下沉：
服务层：确认ospfd进程存活且配置加载成功
systemctl status frr→ 看整体状态；vtysh -c "show run" | grep -A 20 ospfd→ 检查OSPF配置块是否存在；ps aux | grep ospfd→ 确保进程在运行。-
邻居层：验证OSPF邻居是否可达、参数是否匹配
vtysh -c "show ip ospf neighbor"→ 正常应显示FULL/BDR/DR；若卡在INIT或2-Way，检查：- 对端IP能否ping通（物理连通性）；
-
vtysh -c "show ip ospf interface"中Hello/Dead时间、Area ID、认证方式、网络类型是否一致； - 接口是否在正确区域宣告：
network 192.168.10.0/24 area 0是否覆盖该接口IP。
路由层：确认LSDB完整、路由计算正确
vtysh -c "show ip ospf database"→ 查看LSA数量与类型（尤其Type 1 Router-LSA、Type 3 Summary-LSA）；vtysh -c "show ip ospf route"→ 显示FRR计算出的OSPF路由（非内核路由表）；ip route show proto 179（FRR默认用协议号179）→ 查看是否已安装进内核；若无，检查ip route replace权限或net.ipv4.conf.all.accept_redirects等内核参数是否阻断。
关键细节提醒：
- FRR默认不自动将OSPF路由安装进内核，需在
ospfd.conf中启用：router ospf→redistribute connected/redistribute static（如需）→ 并确认ip forwarding开启； - MTU不匹配会导致卡在ExStart/Exchange状态：
ip link show eth0 | grep mtu，两端必须一致，或在FRR中加ip ospf mtu-ignore； - Router-ID冲突会引发邻居震荡：
vtysh -c "show ip ospf brief"查ID，手动指定避免自动生成冲突。
不复杂但容易忽略
