2026-06-02

ARP 重复 IP 地址冲突——免费 ARP、MAC 变化、网关混乱

如何诊断数据包捕获中的重复 IP 地址冲突、ARP 风暴、免费 ARP、错误的 MAC 映射、网关混乱和间歇性 LAN 故障。

重复的 IP 冲突会造成看似随机的间歇性故障。设备可以工作，然后就掉线了。网关MAC发生变化。服务可以从一台主机访问，但不能从另一台主机访问。用户搜索“ARP重复IP pcap”、“无端ARP冲突”、“相同IP两个MAC地址”、“ARP缓存错误MAC”、“间歇性LAN抓包”，因为正常的应用日志很少暴露二层身份问题。

ARP 将 IPv4 地址映射到本地网络上的 MAC 地址。如果两个设备声明相同的 IP，流量可能会在它们之间反弹或流向错误的机器。

PCAP 手术很有用，因为 ARP 证据通常很小，但隐藏在较大的捕获中。您需要 ARP 请求、回复、免费 ARP、MAC 地址、时间戳和周围的故障。

重复的 IP 是什么样子的

一个经典的标志是相同的IP与不同的MAC地址相关联：

10.0.0.25 is-at aa:aa:aa:aa:aa:aa
10.0.0.25 is-at bb:bb:bb:bb:bb:bb

Gratuitous ARP

Look for:

Gateway confusion

Checklist

Use this workflow:

Final diagnosis

用数据包证据回答“ARP 重复 IP 地址冲突——免费 ARP、MAC 变化、网关混乱”

直接答案是：分析器 label 或应用消息不能单独确定原因。应从 capture point 与 flow direction 开始，证明最后成功的 protocol boundary 和首个失败 boundary。另一位 reviewer 必须能找到支撑句子的 packet、gap 或 interval，并知道什么证据可以否定判断。

把抓包放到路径地图上

记录 client、server，以及中间的 proxy、load balancer、NAT 或 firewall。写明 interface、位置、clock、OS 和可见方向。client 附近的 capture 证明什么到达 client，但不能证明 server 没发送；server 附近只证明该位置的出口。对比两个观察点前，修正 clock offset，并按 flow tuple、TCP sequence 或 transaction ID 对齐。

检查 snap length、dropped packets、offload、capture filter、ring buffer 和开始时间。host 上的 bad checksum 可能是 offload artifact。大 segment 可能来自 GRO/TSO，并非 wire 上的一个 packet。有限文件里缺少 packet，不能在证明观察点本应看到它之前写成 network loss。

按顺序读取边界

边界	成功证据	有效失败证据
Link/IP	direction、addresses、route 一致	ARP/NDP 缺失、ICMP、MTU、asymmetry
TCP	SYN、SYN-ACK、ACK、sequence 正确	retransmission、RST、zero window、timeout
TLS	ClientHello、ServerHello、handshake 推进	alert 或 SNI/ALPN/certificate boundary
Application	完整 request 与对应 response	status、gap 或提前 close
User	response time 或 failure window	stall 对应已证实边界

在第一个没有成功证据的边界停止。TCP 未建立时不要先解释 HTTP。request 到达 proxy 却未出现在 upstream，边界位于 proxy 或其路径；upstream 已收到但 timeout 前没有 response，应通过 ACK 与 bytes 推进区分 application delay 与 network loss。

分开 observation 与 hypothesis

observation 可以指到记录：“client 发送到指定 sequence，sender 重复同一 segment 三次，本观察点没有出现推进 ACK。”hypothesis 是“路径丢失 segment”。另一位置的 capture 或 dropped records 可能否定它。为每个假设写一项支持证据与一项反证。

retransmission 或 duplicate ACK 不能自动分配责任。reordering、loss、capture artifact、receiver delay 会产生相似 label。关联 direction、sequence、ACK、SACK、RTT、window 与 application timing。DNS/DHCP 对齐 transaction ID 与 attempts，HTTP 对齐 request/response，TLS 对齐 handshake direction。

编辑前保全原件

计算 original checksum，并保持原件不变。filter、trim、redaction 在 working copy 上完成。记录 input、operation、时间、前后 packet count、output checksum 与理由。timestamp rewrite 或删除 packets 后，该副本不再适合某些 timing 或 sequence 结论。

addresses 与 identifiers 使用一致 aliases，保持 endpoint 可追踪。不能删除判断所需的 port、direction、length。secret mapping 单独保存。通过抓取与导出范围和 PCAP Surgery 概览检查派生文件。

发布前 QA

title 与 answer 是否回答同一 flow？每个 duration 是否写明 clock 与观察点？首个 failure boundary 是否明确？有没有 alternative explanation？复测是否只改一项？original 是否保留？限制结论：“该文件证明指定 interval 的 client 附近行为，不证明 server 内部执行。”

Semrush 验证的一般词 PCAP analyzer 只由产品页负责。技术博客保持自身问题，不编造 volume 或 KD。

flow 台账与排除实验

围绕“ARP 重复 IP 地址冲突——免费 ARP、MAC 变化、网关混乱”为每个方向建立一行：endpoint aliases、首末 packet、已发送和已确认 bytes、resets、retransmissions、requests、responses。相同 hostname 不等于同一连接，source port、开始时间、TCP initial sequence 用于区分 sessions。经过 NAT 或 proxy 时记录 flows 的对应关系，不期待 sequence 或 ports 相同。

计算 TCP，不数 labels

追踪 receiver 的 next expected sequence。payload 按长度推进 sequence，SYN 与 FIN 也各占一个编号。较高 segment 到达后持续 Duplicate ACK，支持 loss 或 reordering。SACK blocks 说明哪些 ranges 到达，但不能证明丢失位置。sender 侧看到 retransmission 而 receiver 侧没有，应检查中间 path；sender capture 连 original 都没有，应检查 capture loss 或 offload。

区分 duplicate ACK 后的 fast retransmit 与沉默后的 RTO。比较事前 RTT、advertised window、zero-window probes、burst 与 transfer size。overlap、spurious retransmission、从 flow 中段开始抓取都会改变 analyzer label，label 数量不等于 loss 数量。

用边界测量时间

使用 request first byte、request complete、response first byte、response complete。TTFB 不自动等于 server time。response 前 retransmission 可能增加 network delay；request 已完整 ACK 后长时间沉默更支持 application wait。写明数值、unit、clock、point。

两个观察点先在双方向匹配特征 packet，估算 offset，再使用各文件内部 intervals。clock 不确定时给 range。成功与失败 window 应保持相近 duration 与 load。

协议专项问题

DNS 检查 ID、name、type 与 retry resolver；DHCP 检查同一 client identifier 的 Discover/Offer/Request/ACK；TLS 找各方向最后 handshake message 与 alert；HTTP 识别 4xx/5xx 生成者及 upstream flow；TCP close 识别 FIN/RST sender 与未 ACK bytes。

决定性实验与交付

选择两个竞争 hypothesis 和一个区分实验。另一端 capture 区分 network loss 与 measurement loss；test 中关闭 offload 检查 artifact；固定 path 发送相同 request 检查 intermittency；upstream log 对照 packet boundary 检查 application delay。执行前先写预期。

reviewer 能用 metadata 重复计算、找到同一 boundary 并理解限制，才算验收。交付 original/derived checksums、filter、packet ranges、trim/redaction 操作，以 owner、next action 和可测量 close 条件结束。

复现性复核

从新 connection 使用相同 inputs 与 filters 重复三次。ports 与 initial sequence 可以变化，但 boundary、direction、response pattern 应当重复。完整报告成功与失败。修复只改一个变量，并确认预期 packet behavior 发生变化，而不只是应用消息消失。

在另一设备打开 derived copy。reviewer 应找到 flow aliases、clock、capture point、最后成功、首个失败和 alternative。redaction 后重新搜索 hostname、query、header、sensitive payload，同时保留判断所需 length 与 direction。列出未测范围：反方向、IPv6、reconnect 或其他 load。

最终状态只能是范围内已证明、仍可复现、或因指定 capture 缺失而未决。只验证一个 flow 时不能写成“整个网络已修复”。

反向对照与置信度

关闭“{{TITLE}}”前先写反向预测。如果原因是 network path，移动 capture point 后两个位置分别应出现什么 pattern？如果是 server delay，request bytes 是否应全部 ACK 而 response 仍缺失？在结果前写预期，可以防止事后改变解释。

confidence 必须绑定 evidence。high 需要重复结果以及两个观察点或独立证据；medium 表示完整 capture 仍有未测 alternative；low 只有 label 或粗略 timing。confidence 不会把 hypothesis 变成 fact，但能确定 next action。

慢速或 intermittent failure 要测量超过通常 failure interval。比较 rates 而非原始 counts：每 megabyte 的 retransmissions、每 connection 的 failures、相似 load 下的 latency percentiles。记录 idle、reconnect、DNS cache、TLS session reuse，因为它们会改变第二次运行。

交付包包含 flow table、五个 event 的 timeline、first difference、exclusion test、fix result、untested scope。packet numbers 对应 derived copy，并通过 time map 返回 original。接收团队无需 secrets 或作者 session 即可重复 verdict，才算通过。

版本与审核记录

original、working copy、report 使用不同 IDs。manifest 记录 size、packet count、capture start/end、checksum、tool、version。重新 export 时创建新 version，不能覆盖旧文件。保存真实 filter；“只保留 server traffic”不足以复现。

把每项 final claim 关联到 packet 或 interval，并标记 observed、calculated、inferred。observed 是可见 field；calculated 是可重复的 sequence/time 计算；inferred 是仍需实验的解释。压缩报告时不能把 inferred 写成 observed。

reviewer 记录姓名、时间、结果与 open questions。修复后从相同 start state 采集 new run，保留 before/after evidence。pass 只适用于声明的 flow、direction、duration、load，其他范围明确写成未验证。

上线前还要打开 rendered page，确认 table、headings、internal links 可见，locale canonical 指向自身 route。只检查源 Markdown、公开 HTML 却缺少正文，不算完成。还要确认 direct answer 回答 title、表格保留双方向、内链不落回英文 fallback，并记录 rendered check 的日期与 reviewer。