怎么在Linux利用Arp-Ignore解决在LVS-DR模式下的VIP地址冲突响应-linux运维-PHP中文网

lvs-dr中rs响应vip的arp请求是因为linux默认arp_ignore=0，即只要vip配置在lo上，就响应所有arp请求，导致多rs冲突；必须设arp_ignore=1（配合arp_announce=2）并持久化至sysctl.conf，确保仅接收不响应、且通告时避免暴露vip-mac。

怎么在linux利用arp-ignore解决在lvs-dr模式下的vip地址冲突响应

为什么LVS-DR节点会响应VIP的ARP请求

在LVS-DR模式中，Real Server（RS）必须配置VIP（如 192.168.1.100）到本地回环接口（lo），否则无法接收Director转发来的请求。但Linux默认行为是：只要某IP配置在本机任意接口上，内核就会响应对该IP的ARP请求——哪怕它只绑在lo上。这导致多个RS同时响应VIP的ARP，交换机MAC表震荡，流量错发。

`arp_ignore`设为1或2才能真正抑制VIP的ARP响应

仅靠arp_announce或关闭arp_filter没用。关键在arp_ignore的取值：

arp_ignore = 0（默认）：只要IP在本机存在，就响应所有ARP请求
arp_ignore = 1：只响应目标IP与接收ARP请求的接口IP完全匹配的请求（即：ARP发给eth0的IP，才由eth0响应；发给lo上的VIP，lo不对外响应）
arp_ignore = 2：更严格，只响应目标IP属于接收接口所在子网的请求（对VIP这种非本子网地址也拒绝响应）

生产环境推荐设为1，兼容性更好。执行：

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore

注意：all和lo两个位置都要设，all管全局策略，lo确保回环接口本身不破例。

必须配合`arp_announce=2`防止源IP暴露错误

即使不响应ARP，RS在回复客户端时若从lo发包，源IP是VIP，但出口设备是eth0，此时Linux可能按eth0的IP填ARP请求的源MAC——导致客户端收到“VIP来自eth0 MAC”的错觉，下次直接ARP找它，绕过Director。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

解决方法是强制使用“最匹配接口”的IP来宣告：

arp_announce = 0（默认）：随便选一个本地IP宣告
arp_announce = 2：优先用目标IP所在子网的接口IP宣告（对VIP无效，因它不在任何物理网段）→ 实际效果是：不宣告VIP，只宣告eth0真实IP，客户端不会误学VIP-MAC

执行：

echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce

配置必须持久化且避开NetworkManager干扰

临时写/proc重启即失效。需写入/etc/sysctl.conf：

net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.lo.arp_announce = 2

然后运行sysctl -p生效。但要注意：

某些发行版（如RHEL8+/CentOS8+）默认启用NetworkManager，它会覆盖sysctl设置 → 需禁用NetworkManager或改用nmcli配置内核参数
不要设net.ipv4.conf.eth0.arp_ignore——物理接口不需要抑制ARP，反而会导致Director本身无法被正常访问
验证是否生效：ip neigh flush all && arping -I eth0 -c 2 192.168.1.100，RS上应无响应；Director上应能收到响应

真正的难点不在参数本身，而在于确认ARP请求实际到达哪个接口、内核按哪条路由规则决定响应与否——抓包看tcpdump -i any arp比查文档更快定位问题。