CloudStack虚拟路由器中DHCP记录未正确释放问题分析

问题背景

在CloudStack 4.19.1.2版本的VPC环境中，当使用冗余虚拟路由器配置时，发现一个关于DHCP服务的重要问题：当虚拟机被彻底删除(expunge)后，虚拟路由器中的DHCP内存记录未能正确释放。这会导致IP地址资源逐渐耗尽，最终新虚拟机无法获取IP地址。

问题现象

在VPC环境中配置了冗余虚拟路由器并创建虚拟机后，如果执行虚拟机彻底删除操作，检查虚拟路由器中的/var/lib/misc/dnsmasq.leases文件会发现，该虚拟机的DHCP记录仍然存在。这些未被释放的记录会持续占用IP地址资源，直到虚拟路由器重启才会被清除。

技术分析

现有机制分析

CloudStack在删除虚拟机时，会通过执行dhcp_release命令尝试释放虚拟路由器中dnsmasq服务维护的内存DHCP记录。命令格式如下：

dhcp_release eth3 172.29.101.250 02:02:00:d4:00:4f

问题根源

深入分析发现，dhcp_release命令实际上并未生效，原因在于dnsmasq服务的安全验证机制。dnsmasq源代码(rfc2131.c)中有如下关键检查逻辑：

if (!(context = narrow_context(context, mess->ciaddr, tagif_netid)) ||
    !(opt = option_find(mess, sz, OPTION_SERVER_IDENTIFIER, INADDRSZ)) ||
    option_addr(opt).s_addr != server_id(context, override, fallback).s_addr)
    return 0;

这段代码要求客户端请求中的服务器ID必须与dnsmasq实际监听的地址匹配。在冗余虚拟路由器配置中：

1. dnsmasq配置(/etc/dnsmasq.d/cloud.conf)中只监听了回环地址(127.0.0.1)和次要IP地址(如172.29.101.1)
2. 但dhcp_release命令发送的请求中，服务器ID使用的是主IP地址(如172.29.101.245)
3. 由于地址不匹配，dnsmasq拒绝了DHCP释放请求

网络配置验证

通过检查虚拟路由器的网络配置可以确认这一点：

5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02:02:00:d4:00:32 brd ff:ff:ff:ff:ff:ff
    inet 172.29.101.245/24 brd 172.29.101.255 scope global eth3
    inet 172.29.101.1/24 brd 172.29.101.255 scope global secondary eth3

解决方案

临时解决方案

有两种临时解决方案：

1. 手动修改dnsmasq配置文件，添加主IP地址到监听列表：

listen-address=127.0.0.1,172.29.101.1,172.29.101.245

2. 修改虚拟路由器中的Python脚本/opt/cloud/bin/cs/CsDhcp.py，在冗余模式下同时添加网关IP和主IP到监听地址列表：

if self.cl.is_redundant():
    listen_address.append(gateway)
    listen_address.append(ip)  # 添加这一行

官方修复

该问题已被CloudStack开发团队确认并修复，修复方案已合并到主分支。修复思路与上述临时解决方案类似，确保在冗余虚拟路由器配置中，dnsmasq同时监听主IP和次IP地址，从而使DHCP释放请求能够被正确处理。

总结

这个问题展示了在冗余网络配置中，IP地址管理需要考虑的额外复杂性。CloudStack的修复确保了在VPC冗余虚拟路由器环境下，DHCP资源能够被正确释放，避免了IP地址泄漏问题。对于生产环境，建议升级到包含此修复的CloudStack版本，以获得更稳定的网络资源管理能力。