看下交换机日志情况

结论（快速判断）

当“刷新 ARP 后就恢复”是强线索：问题几乎一定和 ARP 缓存/映射错误或不一致 有关（包括 stale/错误的 ARP 条目、proxy-arp 导致的错误代理、重复 IP/断续的 MAC 学习、或防火墙/交换机上有关 ARP/会话/连接跟踪的异常）。
也有可能是 路径不对称 + conntrack/会话保持 导致某些源地址的会话被防火墙误判，但能被 ARP 刷新临时修复，次要可能性也要检查。

可能的具体根因（按概率）

1. 陈旧或错误的 ARP 条目（最常见）：某些办公终端/核心设备缓存了错误的 IP→MAC 映射，刷新后重新 ARP 成功。

2. proxy-arp 配置问题 / proxy-arp 返回错误 MAC：proxy-arp 在跨 VLAN/子网透传时可能把包代理到错的接口或错误返回 MAC。

3. IP 冲突 / 同一 IP 有多个 MAC（或 MAC 切换）：导致 ARP 表频繁变化，部分主机缓存到错误的 MAC。

4. 交换机 MAC 表 / VLAN 学习不稳定（MAC flapping）：设备在不同端口学到同一 MAC，导致转发异常。

5. 防火墙的 ARP/Conntrack/会话超时或缺陷：某些源 IP 的连接状态被错误保持或与 ARP 表不同步。

6. 服务器端网关/路由配置不一致（非对称路由）：服务器向某些终端回包走了不同路径，导致看似“能发不能收”。

7. ARP 限速 / ARP 安全特性（Dynamic ARP Inspection / ARP protection）误拦：设备误拦特定主机的 ARP。

逐步排查清单（按顺序做；每步都应记录结果）

1. 复现时先检查 ARP/MACTABLE 状态（不要随意清表，先查）

   • 在办公交换机 / 核心交换机上查看对应 IP 的 ARP：

     • H3C：display arp | include <IP>

     • Cisco：show ip arp <IP>

   • 查看交换机上的 MAC 表（看对应 MAC 在哪个端口）：

     • H3C：display mac-address | include <MAC or interface>

     • Cisco：show mac address-table | include <MAC>

   • 在防火墙上查看 ARP 表或 ARP 映射（不同厂商命令不同）以及相关策略命中纪录（看该 IP 的包是否到达防火墙并被允许/拒绝/丢弃）。

   • 在目标服务器 / 访问终端上查看邻居表：Linux ip neigh show | grep <IP>。

2. 确认是否为单一或多个源 IP 出问题

   • 列出所有出现问题的源 IP，检查是否有共性（同一办公交换机端口、同一子网、某型号终端等）。

3. 检查是否存在 IP 冲突或多个 MAC 对应同一 IP

   • 在来问题时用 arping -c 3 <IP>（在同一网段）或者在核心交换机/防火墙上观察是否有多个不同 MAC 与该 IP 关联。

   • 检查 DHCP 服务器是否发了重复租约、或某台设备被静态配置了与 DHCP 范围重叠的地址。

4. 检查 MAC 地址是否在不同端口间抖动（MAC flapping）

   • 交换机日志 / show mac address-table dynamic addr <MAC> 或 H3C 的 display mac-address。

   • 如果发现 flapping，排查链路聚合/环路/端口镜像或错误接线。

5. 检查 proxy-arp 配置与必要性

   • 你提到办公交换机开启 ARP 代理（proxy-arp）。确认是否真的需要 proxy-arp（大部分情况下不推荐在接入交换机上长期开启）。proxy-arp 容易在跨网段/跨设备时返回错误的 MAC（代理别人的 IP）。

   • 临时测试：在可控时间窗口内将 proxy-arp 关闭（或在某台设备上临时禁用）观察是否问题消失。若不方便立即改动，则尽量对单台问题客户端做绕测（移到其它端口或 VLAN）。

6. 查看防火墙会话/连接跟踪

   • 某些防火墙维护的会话表会在源 IP 改变或 ARP 变更时导致流量被丢弃，刷新 ARP 使得新流量重新建立会话从而成功。查看防火墙上是否有老旧的 session/conntrack 条目，对应源 IP 是否被 NAT 或策略影响。必要时清除单个会话测试（不要随意清全表）。

7. 查看服务器网卡/操作系统 ARP 行为

   • 在服务器上看 ip neigh，若服务器上有静态 ARP、或 ARP 缓存老化时间设置异常，可能导致响应不及时。建议服务器在网卡/虚拟化层启用或发送 gratuitous ARP（即网卡重启或手动发送 GARP 可修复）。

8. 抓包确认 ARP 请求/应答过程

   • 在核心交换机、防火墙或服务器上抓 ARP 包（或在问题终端用 tcpdump/wireshark），观察 ARP 请求是否发送、谁回复、回复的 MAC 是否正确。抓包能直接定位是没有答复、答复了但 MAC 错误，还是答复后流量被丢弃。

立即可做的临时缓解（风险低 -> 高）

• 给关键服务器在核心交换机/防火墙上配置静态 ARP（仅作为临时/关键业务缓解）。注意静态 ARP 要同步在所有中间设备上。

• 在服务器 NIC 上启用定期发送 gratuitous ARP（很多 OS / 虚拟化平台或网卡驱动能设置）。

• 若 proxy-arp 没必要，关闭 proxy-arp。这往往能根治由代理错误映射导致的个例问题。

• 若发现是单机 IP 冲突，立即修复冲突（改 IP 或修 DHCP）。

长期根治建议

1. 消除不必要的 proxy-arp：如果网络设计允许，避免在接入/汇聚开启 proxy-arp，改用正确的路由/子网设计。

2. 调整 ARP 老化时间与监控：在核心设备上设置合理的 ARP 老化和告警，定期汇报 mac/arp 异常。

3. 对关键服务器使用静态 ARP / 白名单（受控）。

4. 日志与抓包常态化：把 ARP/MAC flapping/arp error 做为 NOC 警报项。

5. 检查并修复拓扑中的物理/虚拟变动（虚拟机迁移、双网卡 bonding/VRRP 引起的 GARP 行为等）。

6. 如果防火墙是瓶颈，检查并调整 conntrack 超时与 ARP 同步逻辑，或和厂商支持联系确认是否有已知 bug（某些防火墙固件在特定条件下会有 ARP 同步问题）。

常用命令示例（参考）

• H3C：display arp | include <IP>；display mac-address | include <MAC>；display interface brief。

• Cisco：show ip arp <IP>；show mac address-table address <MAC>；clear ip arp（慎用）。

• Linux（服务端/终端）：ip neigh show；ip neigh flush to <IP>；arping -c 3 <IP>；tcpdump -n -i eth0 arp.

• 防火墙（厂商不同，命令差异大）查看 ARP/会话与策略命中日志，或使用厂商 GUI 查看具体 session。