Keepalived主备服务器不同网段引发的虚拟IP路由问题：用OSPF动态路由协议搞定！

原创

已于 2025-04-16 21:50:21 修改 · 1k 阅读

13 ·

CC 4.0 BY-SA版权

文章标签：

#服务器 #tcp/ip #运维

于 2025-04-16 21:45:55 首次发布

引言

“传统Keepalived双机热备只能在同网段实现虚拟IP漂移，跨网段部署时，虚拟IP的路由成了大难题！静态路由维护复杂、最终我靠OSPF动态路由轻松搞定！”

场景：

服务器A（主）和服务器B（备）位于不同子网）

主服务器 IP：192.168.4.140/24（业务网段 A）

备服务器 IP：10.1.4.250/24（业务网段 B）

虚拟 IP：192.168.200.16/32（对外服务的浮动ip）

虚拟IP（VIP）需在双机间漂移，且跨网段设备能自动感知VIP路由。
核心问题：VIP切换后，其他子网设备无法通过三层交换机访问新位置的VIP！

一、问题背景：为什么跨网段部署Keepalived会失败？

ARP广播的局限性
Keepalived基于VRRP协议承载，依赖ARP协议通告虚拟IP的MAC地址，但ARP广播无法跨越三层网络。当主备服务器位于不同子网时，其他网段的设备无法感知虚拟IP的MAC地址变化，导致流量无法正确路由。

静态路由的弊端

若手动添加静态路由指向虚拟IP所在子网，虽能临时解决问题，但：

无法自动感知主备切换：主节点故障后，静态路由不会自动更新。

维护成本高：大规模网络中需在多台设备上配置，易出错。

二、破局思路：让路由 “活” 起来 —— 动态路由协议的妙用

1.解决方案：在服务器安装路由组件运行OSPF动态路由协议
为什么选择OSPF？
动态路由通告：OSPF能自动学习并广播网络拓扑变化，实时更新路由表。

支持多区域：适用于复杂网络架构，跨网段路由自动收敛。

快速故障切换：通过Hello报文检测邻居状态，收敛时间可优化至秒级

核心思路
将Keepalived虚拟IP所在的子网（如192.168.1.0/24）通过OSPF动态通告到全网。

主备服务器安装支持动态路由协议的组件作为OSPF路由器，参与路由计算，确保虚拟IP所在子网的路由可达性。

2. 核心组件登场：三层交换机 + FRRouting 的黄金组合
在这里插入图片描述
① 三层交换机：网络世界的 “智能导航仪”
作为不同网段的连接枢纽，它不仅具备二层交换能力，更能通过三层路由功能实现跨网段通信。我们需要在交换机上开启动态路由协议功能，让它成为网络拓扑的 “信息集散地”。

② FRRouting：服务器上的 “路由引擎”
这款开源路由软件支持 OSPF、BGP 等多种协议，能让服务器主动参与路由计算。在主备服务器上安装 FRR 后，它们不再是被动的 IP 载体，而是能主动 “告诉” 网络，例如当主服务器掌管虚拟ip的时候会通知网络进行路由更新：“我的虚拟 IP 192.168.200.16 在这里，通过192.168.4.140可以访问到我！”。当主服务器出现故障的时候

三、实战部署：从 0 到 1 的配置全解析（以 OSPF协议为例）

1. 服务器端 FRR 配置（在CentOS 系统部署配置）

#部署FRR（新手推荐容器方式部署）

[root@localhost ~]#docker run  -d --privileged --restart=always --network=host --name frrouting  quay.io/frrouting/frr:10.3.0
#创建并运行容器
[root@localhost ~]# docker exec -it frrouting /bin/bash
#进入运行的容器
localhost:/#vim /etc/frr/daemons
#修改配置文件启用路由协议,将ospf和bfd启用
  bgpd=no
  ospfd=yes
  ospf6d=no
  ripd=no
  ripngd=no
  isisd=no
  bfdd=yes
  …………………………
 保存并退出
localhost:/# /etc/init.d/frr restart   #重启Frr服务或者退出重启容器
Stopping Frr monitor daemon:
[root@localhost ~]#
[root@localhost ~]# ps -ef | grep ospf
root     3092428 3092418