ipvsadm vip ARP 响应失败的 arp_ignore / arp_announce 配置

VIP的ARP响应失败是因为arp_ignore未正确配置；LVS-DR要求Real Server不响应VIP的ARP，需将all和lo接口的arp_ignore均设为1，否则内核默认值0导致lo接口响应ARP。 为什么 VIP 的 ARP 响应失败，和 arp_ignore 有关 Linux 内核默认会响应所有本地 IP（包括绑定在 lo 上的 VIP）的 ARP 请求，这在 LVS-DR 模式下会导致后端 Real Server 主动应答客户端的 ARP 查询，破坏 Director 的流量调度逻辑。关键在于 控制“谁有资格应答 ARP”。设为 表示：仅当目标 IP 配置在请求到达的接口上时才应答；设为 表示：只要本机任一接口配置了该 IP 就应答（不推荐用于 DR）。LVS-DR 要求 Real Server 完全不响应 VIP 的 ARP，所以必须设为 。 常见错误是只改了 接口的值，却忘了全局默认值仍为 —— 内核优先查接口级配置，查不到就回落到全局，而 默认没定义 ，实际生效的是 。所以必须显式设置： arp_announce 的作用不是“发不发 ARP”，而是“用哪个源地址发” 很多人误以为调高 能阻止 ARP 响应，其实它只影响本机主动发送 ARP 请求（比如地址变更、免费 ARP）时，如何选择源 IP 地址。在 LVS-DR 中，Real Server 需要确保：当它因其他原因（如网关刷新）发出 ARP 请求时，源 IP 不暴露 VIP。因此应设为 ：“总是使用最佳本地地址（即与目标网络匹配的、配置在入接口上的地址）”，避免从 上的 VIP 发出 ARP。 同样需同时设置 all 和 lo： 仅跳过同 子网 内其他接口上的地址，不够严格 不设 级配置时， 仍按默认 行为选源地址，可能泄露 VIP 该参数对被动 ARP 响应无影响，别指望靠它解决“VIP 被抢答”问题 ipvsadm 规则本身不触发 ARP 行为，但依赖正确的内核 ARP 策略 只负责建立连接跟踪和转发规则，它不干预 ARP 协议栈。哪怕 显示服务正常、连接已建立，只要 Real Server 的 没配对，Director 收到客户端 ARP 请求后，仍可能收到 Real Server 的错误应答，导致客户端把 VIP 解析到 Real Server 的 MAC，绕过 Director。 验证是否生效的关键命令： 通义灵码 Linux版 通义灵码 Linux版是阿里云推出的一款AI智能编码助手，专为Linux开发者设计。它支持在Linux操作系统下的JetBrains IDEs、Visual Studio Code等主流集成开发环境中运行。该工具基于通义大模型，提供代码智能生成、实时续写、单元测试生成、代码优化以及研发智能问答等功能，旨在帮助Linux用户在编码过程中提升效率。 下载 最后一条应在 Director 上执行：若能看到 Real Server 回包，说明其仍在响应 ARP —— 配置未生效或未覆盖 lo 接口。 持久化配置容易漏掉 lo 接口，且 systemd-networkd 可能覆盖 sysctl 写进 的 会被加载，但 很多发行版默认不写，重启后丢失。更隐蔽的问题是：某些系统（如使用 或 的新版 Ubuntu/CentOS）会在接口 up 时重置 下的参数，覆盖 sysctl 设置。 稳妥做法： 在 中明确写入 和 添加 systemd service 或 network script，在 up 后再次 echo 这两个值（尤其当使用 cloud-init 或容器环境时） 避免用 临时加载，它不保证接口级配置被应用到 lo lo 接口的 ARP 参数不像物理网卡那样有“启动脚本”概念，它的初始化时机特殊，最容易被忽略。