OSPF路由引入的陷阱：为何Ubuntu上静态路由神秘消失？深挖FRR路由分类机制

在成功使用FRR让Ubuntu变身OSPF路由器后（让Ubuntu服务器变身OSPF路由器！实现服务器与网络设备直接对话），我们实现了与网络设备的基础互通，使得配置OSPF之类的动态路由协议不再是路由器、交换机等网络设备的特权。
对于大规模网络，例如在智算中心的存储集群配置中（2048卡H100算力中心HPE Alletra 4140存储集群部署手册），也是用的FRR来实现存储设备HPE Alletra Storage Server 4140与存储交换机之间的BGP对接，但如果要手工配置成千上万条静态路由，怕是所有工程师的噩梦。
今天，我们就深入研究一下OSPF的核心技能：路由引入。探索如何在H3C VSR路由器和Ubuntu FRR之间，高效、精准地同步各种类型的路由信息，并揭开Ubuntu系统中不同路由配置方式在FRR眼中的身份之谜。
首先，参考路由器的配置案例（OSPF的DR/BDR是怎么选出来的？抓包实战带你看清选举全过程与Router ID的作用），完成VSR一侧的OSPF配置：
#
interface LoopBack0
ip address 10.1.1.239 255.255.255.255
#
interface GigabitEthernet1/0
ip address 192.168.200.239 255.255.255.0
#
ospf 1 router-id 10.1.1.239
area 0.0.0.0
network 192.168.200.0 0.0.0.255

然后，参考Ubuntu中FRR的配置案例（让Ubuntu服务器变身OSPF路由器！实现服务器与网络设备直接对话），完成Ubuntu一侧的OSPF配置：
configure terminal
interface lo
ip address 10.1.1.226/32
router ospf
ospf router-id 10.1.1.226
network 192.168.200.0/24 area 0
network 13.1.1.0/24 area 0
exit
do write memory

现在，两台设备之间的OSPF已经建立起来了，我们检查一下VSR设备的邻居信息和路由条目。

可以看到，两台设备的选举机制是一样的，优先级都是1，但是Ubuntu设备的路由器ID更小，选举成了DR设备。同时，路由通告也没有问题，VSR成功学到了Ubuntu设备宣告的路由13.1.1.0/24。

测试访问也没有问题。接下来，让我们配置一下在OSPF进程中引入自治系统外部路由。
首先，在VSR上新建几个接口地址，这样会生成几条直连路由。

#
interface GigabitEthernet2/0
ip address 10.239.2.1 255.255.255.0
#
interface GigabitEthernet3/0
ip address 10.239.3.1 255.255.255.0
#
interface GigabitEthernet4/0
ip address 10.239.4.1 255.255.255.0

可以看到，通过配置3个接口的IP地址，直接实现了本地新增9条直连路由。接下来，我们在VSR的OSPF进程中配置引入直连路由。
#
ospf 1 router-id 10.1.1.239
import-route direct

可以看到，OSPF进程中，支持引入8种协议的路由条目，我们先配置direct直连路由。配置完成后，到Ubuntu系统中检查一下。

可以看到，Ubuntu的OSPF进程中学习到了3条24位的网段路由，并且同步到了内核的路由表中。简单测试一下连通性。

其实，Ubuntu系统中还有一条静态路由，如何配置引入到OSPF进程呢？

有点意思，34.1.1.0/24这条路由是通过netplan配置文件指定的，竟然显示不属于静态路由，那我们手工再增加一条。
ip route 35.1.1.0/24 13.1.1.3

但我们的探索欲不止于此。Ubuntu系统中本身也有静态路由，能否也引入到OSPF进程，让VSR学习到呢？我们配置一下路由引入，看看会引入几条。
redistribute static

可以看到，FRR竟然支持引入13种类型的路由，涨姿势了！

到VSR一侧检验一下路由学习情况。

果然，只有在FRR中手工配置的静态路由被引入了，那通过netplan配置的路由怎么引入呢？首先得确认它是哪种类型。

可以看到，当前系统中的路由被分成4类：默认路由和netplan配置的路由被归类为Kernel路由，直连路由即connected路由，在FRR中配置的静态路由才是static路由，还有和OSPF相关的ospf路由。
那么，在内核中使用ip route命令配置的路由属于哪一类呢？

可以看到，全都归类为Kernel路由了。原来，FRR通过Zebra组件与内核交互，只要不是由FRR自己生成的路由，无论是netplan配置还是ip route命令添加，在FRR看来统统属于Kernel路由！
病因找到了，药方也就自明了。要引入这些路由，不能再使用redistribute static，而必须改用redistribute kernel。
再到VSR查看路由学习情况。

好了，都学习到了。其中34.1.1.0/24是通过netplan配置的静态路由，35.1.1.0/24是通过FRR配置的静态路由，36.1.1.0/24是通过内核ip route命令配置的静态路由，都被成功引入到了OSPF进程中。同时，我们也注意到，OSPF协议对自治系统内部路由的优先级为10，对引入的自治系统外部路由的优先级为150，这体现了OSPF内部优先的可靠性原则，细节处见真章。
通过这次深入实践，我们不仅掌握了OSPF路由引入的配置方法，更厘清了FRR对Linux系统不同来源路由的分类逻辑。这提醒我们，在复杂网络环境中，不仅要熟悉协议命令，更要理解数据在系统各组件间的流转身份。要知其然，更要知其所以然，方能精准排障，优化设计，让自动化路由分发真正高效可靠，满足大规模路由学习场景下的配置要求。