lvs-dr部署必须满足同一二层网络、rs抑制arp响应vip、vip绑定lo接口并配置arp_ignore=1和arp_announce=2，keepalived仅管理vip和健康检查，不参与转发；ipvsadm -ln需显示flags: route且activeconn增长，rs上tcpdump -i lo应捕获到流量。
Keepalived + LVS-DR 的核心约束必须提前确认
不能直接套用 NAT 或 TUN 模式配置，LVS-DR 要求所有 Real Server 与 Director 在同一二层网络（同 VLAN / 同物理交换机下），且 Real Server 必须抑制 ARP 响应 VIP，否则会抢答、导致流量错乱。这是部署失败最常见原因，不是 Keepalived 配置问题，而是网络层基础没对齐。
- 检查
ip addr show确认所有节点（Director 和 RS）能 ping 通彼此的物理 IP，但先不要配 VIP - 确认交换机未开启 ARP 代理或端口隔离；虚拟化环境需设为“混杂模式”或关闭安全策略
- Real Server 上必须禁用 VIP 的 ARP 响应：在
/etc/sysctl.conf中设置net.ipv4.conf.all.arp_ignore = 1和net.ipv4.conf.all.arp_announce = 2，并执行sysctl -p
Director 上的 keepalived.conf 关键段必须精简且无冗余
Keepalived 在 DR 模式下只负责 VIP 管理和健康检查，不参与数据转发 —— LVS 转发由内核 ip_vs 模块完成。因此配置里不能出现 virtual_server_group 或 fwmark 等干扰项，且 lvs_sched 必须显式指定（默认是 rr，但别依赖默认）。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
vrrp_instance VI_1中state只能是MASTER或BACKUP，双MASTER会导致脑裂 -
virtual_server的delay_loop建议设为 6～10，太小会加重 RS 健康检查压力；lb_algo推荐rr或wrr，避免lc在短连接场景下倾斜 - 每个
real_server必须配weight（哪怕都是 1），否则 Keepalived 启动时会静默跳过该节点 - 示例片段：
virtual_server 192.168.1.100 80 { delay_loop 6 lb_algo rr lb_kind DR protocol TCP real_server 192.168.1.11 80 { weight 1 TCP_CHECK { connect_timeout 3 } } }
Real Server 必须手动绑定 VIP 并隐藏其 ARP 行为
LVS-DR 要求 RS 本地有 VIP（用于接收 Director 转发来的包），但又不能响应外部对该 VIP 的 ARP 请求 —— 这和普通 VIP 绑定完全不同。不能用 ip addr add 直接加到主网卡，必须加到 lo 并配合内核参数压制 ARP。
- 执行：
ip addr add 192.168.1.100/32 dev lo label lo:0（注意是/32，不是掩码匹配网段） - 验证：
ip route get 192.168.1.100应返回local 192.168.1.100 dev lo table local - 禁止该 VIP 出现在
arping -I eth0 -c 2 192.168.1.100的响应中；若响应了，说明arp_ignore未生效或写错网卡名（要用all，不是具体接口名） - RS 上无需运行 Keepalived，除非你真需要它做本地服务健康检查（如 nginx crash 自动摘除），此时也只需启用
vrrp_script+track_script，不用开vrrp_instance
调试时优先看 ip_vs 连接状态和 ARP 表，而不是日志
Keepalived 日志（/var/log/messages）只能告诉你“VIP 是否起来了”或“某 RS 是否 down”，但无法反映数据是否真正走到 RS。真正卡点永远在内核转发路径上。
- 在 Director 上运行：
ipvsadm -ln—— 必须看到Flags: Route（表示 DR 模式）、State: Active，且ActiveConn/InActConn开始增长 - 在 RS 上运行：
tcpdump -i lo -nn port 80—— 如果收不到包，说明 Director 没转过来，或 RS 的 lo 没绑对 VIP；如果收到包但没响应，检查 RS 的 web 服务是否监听0.0.0.0:80（而非仅127.0.0.1:80） - 在 Director 和 RS 上分别执行：
arp -n | grep 192.168.1.100—— 正常情况只有 Director 有该 VIP 的 MAC 条目，RS 上应该完全没这条记录 - 误配
arp_ignore=0或漏 reloadsysctl是最隐蔽的坑：现象是负载偶尔生效、重启后失效、或者只有一台 RS 工作
sysctl 设置和 ip addr add ... dev lo —— 它们没有错误提示，却直接决定整个集群是否“看似正常实则丢包”。
