局域网IP冲突排查实录：一次模拟生产环境的抓包与定位全过程
做网络运维和系统部署的人，十有八九都撞上过IP冲突的鬼打墙。现象千奇百怪：时通时断、能ping通网关却上不了外网、某台设备频繁掉线、隔一阵子就断一次然后又自己恢复。以前在学校实验室里遇到这种问题还能糊弄过去，但真到了企业内网、车间工控网或者数据中心机房，IP冲突就是一根能掀翻整个业务稳定性的隐形引线。我最近在模拟生产环境里完整复现并排查了一次局域网IP冲突，从现象出现到最终定位根源，整个过程踩了不少坑，也积累了一些很值得记录的经验。这篇文章把那次测试的完整链路写出来，包括触发条件、排查思路、抓包手法、定位技巧，以及几个被很多人忽略的隐蔽成因。
1. 这次测试的背景与整体设计思路
1.1 为什么专门做一次IP冲突复现测试
先说触发我这轮测试的动机。之前在一个项目现场，某间办公室的工位网络出现间歇性中断，维护的人换了交换机端口、重装了系统、甚至把网线都换成了六类屏蔽线，问题依旧。后来蹲了一整天，才发现是另外一栋楼里某台临时接入的设备占用了同网段IP，导致核心交换机上的ARP表项在两个MAC地址之间反复横跳，整个广播域都被搅浑了。
这种经历让我意识到，IP冲突不是一个简单的“改个IP就行”的琐事，它涉及TCP/IP协议栈的地址探测机制、ARP协议的缓存更新策略、交换机的MAC表学习机制等多个层面。如果不在受控环境里把整个冲突过程完整复现一遍，很多细节根本看不出来。
所以这次测试的目的很明确：在一套独立搭建的模拟生产环境里，人为制造IP冲突，观察网络设备、终端主机和交换机在冲突发生前后的行为差异，掌握一套可以迁移到真实排障现场的思路方法。
1.2 测试环境的选型与网络拓扑设计
模拟环境搭建遵循一个原则：足够简单，方便观察；同时足够接近现实，结论才有参考价值。我选了最经典的小型局域网拓扑，核心组件如下：
- 一台普通千兆交换机（没有配置DHCP Snooping，模拟的是一大批默认配置的傻瓜交换机或低端网管交换机）
- 一台软路由/网关设备，承担DHCP服务、NAT和三层转发功能，内网网段设为192.168.50.0/24
- 两台PC终端：终端A作为“受害者”，终端B作为“闯入者”
- 一台用于抓包的笔记本，接在交换机的镜像端口上，或者直接通过集线器方式接入（我这里用的是交换机端口镜像，效果更干净）
整个测试分三个阶段：先建立正常通信基线，再触发IP冲突，最后模拟真实业务场景观察冲突影响。后面还会在同一个环境里复现几种常见的变体情况，比如“静态IP对静态IP”、“DHCP分配IP对静态IP”、“设备关机后再开机导致的冲突”。
1.3 为什么选择ARP抓包作为核心诊断手段
排查IP冲突，最直接、最有效的技术手段就是ARP抓包。因为IP冲突的本质就是同网段内两个节点对同一IP地址的声明权产生了竞争，而这种竞争最终都会反映在ARP请求和ARP应答报文上。
打个比方，ARP协议就像是局域网里的“户籍登记处”，每个IP地址要能正常通信，必须先在交换机广播域内登记对应的MAC地址。正常情况下一个IP只有一个MAC对应关系。但如果同一个IP突然出现了两个MAC，广播域内所有设备就开始收到矛盾的信息——今天记的是甲的地址，明天又记成乙的地址。终端一旦缓存了错误的ARP条目，数据帧就会送到错误的目的地，通信自然中断。
在冲突过程中，受影响的不只是冲突双方，还包括整个广播域里的所有主机。因为ARP请求是广播的，任何收到ARP应答的设备都会无条件更新自己的ARP缓存。这也是为什么IP冲突影响面往往比想象中大：明明只是两台设备IP重了，整个办公室或车间的网络都跟着颤抖。
2. 冲突触发前的预检与关键参数准备
2.1 网络基线数据的采集方法
在真正触发冲突之前，必须先采集一套完好的基线数据，否则冲突发生后根本没对照参考。这一步很多人会犯懒，觉得“又不是生产环境，随便跑一下就行”，但恰恰是这个偷懒，导致后面排查时无法判断某些报文的性质。
我做的基线采集包括四部分：
第一是端口与VLAN信息确认。登录交换机，确认所有接入端口都在同一个VLAN，没有端口隔离或私设VLAN的情况。这一步排查的是交换层面的干扰因素。
第二是ARP缓存快照。在正常状态下，分别在网关、终端A、终端B上执行arp -a命令，记录192.168.50.10这个关键IP对应的MAC地址。注意Windows系统用arp -a，Linux系统用ip neigh show或者arp -n，macOS用arp -a也能出结果。
第三是DHCP租约记录。如果环境里有DHCP服务器，登录Web管理界面或者查日志，记录IP 192.168.50.10被分配给了哪台终端，租约起始时间和过期时间各是多少。
第四是流量基线。用Wireshark连续抓3到5分钟正常通信报文，记录正常情况下ARP报文出现的频率（通常很低，只有在设备刚启动、IP地址刚设定或通信目标不在ARP缓存里时才会出现ARP请求）。
2.2 IP地址资源分配与冲突触发点选择
这次测试选了一个非常典型的冲突触发点：终端A已在运行中，IP地址为192.168.50.10/24，MAC地址为AA:BB:CC:00:00:01。终端B原本是另一网段的静态IP，现在手动改成192.168.50.10/24，MAC地址为AA:BB:CC:00:00:02。
这个设计的巧妙之处在于，终端B改IP的时候，终端A的业务流量是持续存在的。终端B接入网络的一瞬间，就相当于强行往局域网里插入了一个二手房的“一房两卖”声明——交换机学了一次终端B的MAC到端口映射，网关也开始收到终端B的ARP报文，整个广播域瞬间被搅混。
需要注意的一个细节是，终端B改IP后，最好先不要立即物理接入网络，而是预先设置好IP，再插入网线。这样做的目的是模拟现实中“一台闲置电脑被搬到新位置，插上网线就上不了网”的场景，避免人为的顺序干扰。
2.3 抓包工具的部署与配置要点
抓包这块直接决定整个排查过程的质量，一定要提前配好。我用的方案是交换机端口镜像，把连接终端A的端口流量镜像到抓包机所在端口。如果你手头只有普通的傻瓜交换机，没有镜像功能，也可以把终端A和抓包机同时接入到一个只有两个端口的集线器（Hub）上。集线器是物理层设备，所有报文都会广播到所有端口，天然具备“全端口镜像”的能力。
Wireshark的过滤规则需要提前准备。在碰到IP冲突时，重点关注的过滤器有这几个：
- arp：显示所有ARP报文，这是最核心的过滤条件
- arp.duplicate-address-frame：筛选Wireshark自动标记的IP冲突告警报文（前提是Wireshark的启用了重复地址检测）
- ip.addr == 192.168.50.10：筛选与该IP相关的所有报文，包括ARP和ICMP以及实际业务数据
另外，抓包时同步开启命令行抓包工具tcpdump作为备份。考虑到Wireshark在图形界面下处理大量报文时占用资源较高，长时间抓包容易丢包，我用的是tcpdump写pcap文件的组合方案。抓完后用Wireshark离线分析，既保证了抓包完整性，又方便灵活过滤。
3. 冲突触发后的现象观察与报文分析
3.1 冲突发生瞬间的ARP报文突变特征
终端B接入网络后，最典型的ARP异常出现了。我抓到的第一个异常报文是终端B主动发出的ARP请求，目标IP是自己的IP 192.168.50.10。这个动作在协议栈里叫作无偿ARP或免费ARP（Gratuitous ARP）。
正常情况下，一台主机在完成IP地址配置后，会发送一次免费ARP，用来宣告自己的IP-MAC映射关系，同时检测网络上是否已经存在相同IP地址的主机。如果网络上已经有主机占用了这个IP，那么该主机会收到一个ARP应答，由原主机发出，声称这个IP是它的，这时新接入的主机就会在屏幕上提示“IP地址冲突”。
但这里就有一个容易被忽视的坑：很多操作系统在检测到冲突后，并不会立刻禁用网卡，而是进入一种“受限使用”状态。Windows系统的表现是弹出网络错误提示、网卡显示“未识别的网络”，但实际上仍然会继续发送少量报文；Linux系统则会把冲突接口标记为DECAYING或FAILED状态，停止接收单播流量，但广播流量还能收到。
再看终端A这边的反应。终端A在持续发送业务流量的过程中，如果它的ARP缓存里已经有网关和终端的映射关系，正常情况下它不会频繁发送ARP请求。但当终端B的免费ARP广播被终端A收到后，终端A会发送一个ARP探测报文，确认网络上是否真的存在另一个192.168.50.10。紧接着，终端B会回应这个探测。双方的这种“你来我往”的ARP请求和应答报文，在抓包里就形成了一连串密集的ARP流量，频率远高于正常基线。
3.2 ARP缓存表项反复横跳的深层机制
这个阶段是整个测试的高潮。我在终端A上用arp -a连续观察192.168.50.10对应的MAC地址，结果发现它就像打乒乓球一样，一瞬间记录的是AA:BB:CC:00:00:01（终端A自己），下一瞬间又变成了AA:BB:CC:00:00:02（终端B）。
为什么会出现这种横跳？因为ARP协议的设计本身没有“身份认证”机制——谁先应答，谁是最后的赢家。终端A发出的ARP请求是广播报文，终端B只要在同一广播域内就能收到，然后它就会以单播的形式应答“192.168.50.10在AA:BB:CC:00:00:02这个位置”。
交换机在这里扮演了一个微妙的角色。正常场景下，交换机通过MAC地址表建立了端口与MAC的对应关系。终端B的MAC地址是第一次出现，所以交换机会在学习后把它记录到对应的端口上。终端A的MAC地址是旧条目，正常情况下不会被清除。当终端A向网关发送数据时，交换机会查表，发现目标MAC对应的端口是网关所在端口，直接把帧转发过去。但是当终端B发出免费ARP后，交换机记录的192.168.50.10对应的MAC变成了AA:BB:CC:00:00:02，如果后续有单播数据要交给这个IP，交换机就根据MAC表把帧送到终端B所在的端口——哪怕这个数据本来是要发往终端A的。
用生活化的例子理解就是：某个小区里“2栋301”这个门牌号，本来住的是张三。突然有一天李四也把自己的门牌改成了“2栋301”。快递员看门牌号派件，结果今天敲张三的门、明天敲李四的门，两个人的快递就全乱了。ARP缓存表就是那本派件地址册，谁后登记谁就覆盖掉之前的记录。
3.3 业务层面的冲突影响实测
光看ARP报文还不够，必须验证业务层面的实际影响。我在终端A上开了三条虚拟通道：一条持续ping网关192.168.50.1，一条持续ping外部模拟服务器192.168.50.200，还有一条是TCP长连接模拟业务（用Python脚本每隔一秒钟向服务器发送心跳数据）。
冲突触发后的第一个现象是ping网关出现间歇性超时。最开始还能通，大概过了几秒钟后开始出现连续的请求超时，之后又恢复，然后又超时，形成了一种没有规律的抖动模式。原因就是终端A发出的ICMP请求到达网关后，网关的回包是发给192.168.50.10的。但网关的ARP缓存此时指向的是终端B的MAC，于是回包被送去了终端B那里。终端B收到一个自己没发起过的回包，自然是直接丢弃，所以终端A就表现为丢包。
TCP长连接的测试更直观。心跳包发送后，服务器端如果收到了请求，会返回响应。但因为ARP混乱，服务器的响应可能会被错误地转发到终端B，导致终端A一直收不到响应，最终TCP连接因为超时被断开。这时候如果应用没有重连机制，业务就彻底中断了。
3.4 网关视角的ARP状态变化
网关是另一个容易忽略的观察点。在排查真实网络故障时，很多人只盯着出问题的终端，忘了看网关的ARP表。但网关才是整个内网流量的集散中心，它的ARP缓存一旦出错，影响的是内网所有设备的外联通信。
我登录网关设备，执行arp -n查看192.168.50.10的状态。正常情况下它显示的是AA:BB:CC:00:00:01。冲突触发后，刚开始网关还保留着旧MAC，过了几十秒后变成了AA:BB:CC:00:00:02。再过一会儿又变回AA:BB:CC:00:00:01。
网关的ARP走向也呈横跳状态，而且横跳的节奏和终端A上的观察并不完全同步。原因是网关的ARP缓存刷新机制、终端操作系统的刷新机制以及交换机的MAC表老化时间各自独立，三者叠加在一起，最终呈现给用户的就是网络时好时坏、毫无规律。这个“无规律”本身就是IP冲突的一个显著特征。如果你在处理网络故障时发现丢包现象毫无规律、时区时不区，排除天线或无线干扰后，第一个要怀疑的就是IP冲突。
4. 常见问题与排查技巧实录
4.1 为什么有些IP冲突测不出来
很多人在模拟测试时都会遇到一个尴尬情况：明明把IP设成了一样，却等了半天也没出现明显断网。这种现象不代表冲突不存在，只说明冲突的影响被某种机制暂时掩盖了。
最常见的掩盖机制是ARP缓存还保留着旧映射。终端A在缓存过期之前，始终认为192.168.50.10就是本机，通信照常进行。终端B虽然发了免费ARP，但终端A在自己的缓存过期之前不会主动刷新对“自己IP”的ARP记录，因为自身IP的ARP记录在协议栈里通常是被特殊处理的。要加速暴露冲突，可以在终端A上执行arp -d清空缓存，或者禁用再重新启用网卡，强制重新进行地址探测。
第二种掩盖机制是交换机端口安全。有些网管型交换机会在端口上配置动态MAC地址学习或端口安全性策略，当新MAC出现在错误端口时，直接把端口关闭或丢弃该MAC的流量。这种机制反而成了冲突的“挡箭牌”——冲突报文根本传不出去，表面上网络一直很正常，但新接入的设备完全无法通信。
第三种掩盖机制是代理ARP。某些网关设备在配置了代理ARP之后，会直接代替局域网内的目标主机回答ARP请求，导致真正的设备识别被绕过去。这种情况下抓包看到的所有ARP应答都来自网关的MAC，问题表象完全不同于典型的IP冲突。
4.2 排查时最容易踩的四个坑
第一个坑是只看终端不查网关。很多刚入门的朋友排障时喜欢在出问题的主机上反复ping、重启网卡，但网关的ARP表才是关键。直接在网关上执行arp -n，连续观察冲突IP对应的MAC变化，比在终端上瞎猜高效得多。
第二个坑是忽略交换机的MAC地址表。交换机的MAC表在IP冲突时会频繁更新，记录到异常端口。登录交换机查看mac address-table动态表项，如果发现同一个IP对应的MAC在多个端口之间跳变，IP冲突基本实锤。但很多小企业的交换机是没有管理界面的，这时只能通过抓包来推断。
第三个坑是抓包时间太短。有的同事习惯抓个十几秒就分析，但IP冲突的ARP报文并不总是高频出现。如果两台终端都处于相对静默状态（各自没有持续的业务流量），ARP报文可能每隔几十秒才出现一次，甚至几分钟都不冒一个。抓包至少要持续3分钟以上，并且最好在抓包期间主动制造一些流量（比如持续ping网关）。
第四个坑是没有记录冲突前状态。再次强调基线数据的重要性——如果没有提前记录正常状态下ARP报文的频率、MAC对应关系和交换机端口的MAC表，等冲突发生后拿到一堆报文，很难分辨哪些是正常流量、哪些是冲突特征。这也是为什么我这次测试坚持分阶段进行，每个阶段都留存独立的抓包文件和命令输出。
4.3 大内网中的IP冲突特征与快速定位方法
把小规模测试的结论放到真实的大内网里，定位难度会成倍放大。因为大内网可能跨越多个交换机、多个VLAN，同一个IP冲突的双方可能并不在同一个交换机下，而是在不同的接入交换机上。这种情况下，ARP报文只会在同一个广播域内传播，所以冲突双方必须属于同一个VLAN或同一个广播域。
快速定位的思路可以遵循三步：第一步，在核心交换机上下发一个ACL或者用抓包工具镜像整个VLAN的上行口，捕获包含冲突IP ARP报文的源MAC；第二步，根据源MAC查询全网交换机的MAC地址表，找到这个MAC最后一次活跃的物理端口；第三步，顺着物理端口找到接入设备，直接改IP或拔线确认。
如果网络规模实在太大，也可以临时断开部分交换机或物理链路，缩小广播域范围。这个方法虽然粗暴，但在生产环境紧急情况下非常管用。需要注意的是，断开链路前必须先和业务方沟通，预防业务中断引发更大的事故。
因为IP冲突的根源往往不是单一设备的问题，而是一个管理规范的问题。头痛医头式的临时改IP，只能让冲突暂时缓解，过不了多久另一个IP又会被占用。
4.4 防止冲突再次发生的长效手段
这次测试做完后，我顺手总结了几条真正管用的预防措施，不是纸上谈兵的那种，是实际部署过、验证过有效的手段。
最核心的一条是开启DHCP Snooping。只要网络里的交换机支持这个功能，就一定要开启。DHCP Snooping会建立一张信任端口和非信任端口的表：连接DHCP服务器的端口设为信任端口，其他所有接入端口都设为非信任端口。非信任端口只允许接收来自服务器确认分配的DHCP报文，其他伪造的DHCP应答会被直接丢弃。这个功能同时还能在DHCP租约里记录IP和MAC的绑定关系，后续可以根据绑定表做IP防冲突。
第二条是整个内网推行DHCP静态绑定或DHCP保留。把所有服务器、打印机、网络摄像头等需要固定IP的设备，统一在DHCP服务器上做MAC绑定分配保留地址。这样做既能让设备每次拿到同一个IP，又能避免有人手滑设置了冲突地址。
第三条是对接入层交换机启用端口安全。配置每个接入端口允许学习的MAC地址数量上限为1，超过则触发保护动作。这样即便有人恶意更改IP或接入陌生设备，交换机也会在端口层面挡住，不会让它干扰整个广播域。
第四条是定期做IP地址扫描和ARP审计。用脚本批量扫描网段内所有活动IP，记录每个IP对应的MAC地址，再和DHCP服务器的绑定表交叉比对。一旦发现同一IP对应多个MAC，立刻告警。这个工作在真实生产环境里建议每半小时跑一次，防患于未然。
5. 复盘总结与一点实际操作体会
这张模拟测试的完整过程走下来，最深的感受是：IP冲突看起来是网络协议层的一个小问题，实际牵扯出来的是一整套地址管理、设备准入和监控审计机制。技术上抓包定位并不难，难的是在故障发生时迅速判断出这是IP冲突，并且不被“时通时断”的表象迷惑。
我个人在实际操作中有两个小技巧值得分享。第一个，排障的时候先别急着登录交换机，先在出问题的主机上连续执行几十次ping，观察丢包率和延迟抖动情况。如果丢包呈“有规律的无规律”，大概率是ARP层面的问题，这时候再上抓包就有明确方向。第二个，抓包文件不要一次性抓完所有报文再分析，而是在抓包的同时实时盯着ARP过滤视图，眼见冲突双方的MAC在短短几秒内交替出现，基本上不用再等完整分析就能下结论。
还有一个细节是在脚本化处理DHCP日志时，顺手加一个简单的比对规则：同日同时段内，同一个IP如果被分配给了超过一个不同的MAC，就自动标记为可疑事件。这种经验只会在多次踩坑后才能总结出来——它不解决冲突本身，却能让你在下一次冲突发生的第一时间就收到告警，而不是等用户把报修电话打进机房。
