各位读者新年好呀～ 最近比较忙，博客快要长草了。今天我们再来看一个实际的网络问题。
症状如下：
在一次服务扩容的时候，新扩容的虚拟机网络断断续续，它的 TCP 服务时而能连上，时而连不上。新扩容出来的虚拟机的 IP 地址是：10.210.151.90。
|
1 2 3 4 5 6 |
$ nc -vz 10.210.151.90 9999 nc: connect to 10.210.151.90 port 9999 (tcp) failed: Connection refused $ nc -vz 10.210.151.90 9999 nc: connect to 10.210.151.90 port 9999 (tcp) failed: Connection refused $ nc -vz 10.210.151.90 9999 Connection to 10.210.151.90 9999 port [tcp/*] succeeded! |
于是我们联系了虚拟机团队的负责人小马，小马一听说虚拟机的网络有问题，上来就是一顿 ping，结果呢，一个包都没丢。「网络肯定没问题，一定是你们自己服务的问题啦。」小马说。
「可是我们用这台虚拟机部署的服务确实不能用啊！」业务的同事可怜巴巴地说。却也没办法说服小马继续排查网络问题了。小马说：
When a problem is yours, own it. When a problem isn’t yours, prove it.
这时，业务团队里面正好有一个精通网络分析的同事（就是你！），这位网络大神随便找了一台机器，一边去用 ping 和 nc 做 TCP 连接测试，一边 tcpdump，得到下面的抓包文件。
网络大神把这个抓包文件下载到本地，分析起来，不一会儿，就得出了结论……
请分析这个抓包文件，回答：为什么 TCP 连接时而成功时而失败？
==抓包破案录==
这篇文章是抓包破案录系列文章（之前叫做《计算机网络实用技术》，后来改名了）中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网络抓包与分析。
如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！
如果您正在阅读的是题目类的文章，这个目录内容正好用来隔离其他读者的评论。读完题目可以稍作暂停，进行思考，继续向下滑动，可能会被其他的读者剧透答案。
没有链接的目录还没有写完，敬请期待……
- 序章
- 抓包技术以及技巧
- 理解网络的分层模型
- 数据是如何路由的
- 网络问题排查的思路和技巧
- 不可以用路由器？（答案和解析）
- 网工闯了什么祸？（答案和解析，阅读加餐！）
- 网络断断续续…… （答案和解析）
- 延迟增加了多少？（答案和解析）
- 压测的时候 QPS 为什么上不去？（答案和解析）
- 重新认识 TCP 的握手和挥手（答案和解析）
- TCP 下载速度为什么这么慢？（答案和解析）
- 请求为什么超时了？（答案和解析）
- 0.01% 的概率超时问题 （答案和解析）
- 后记：学习网络的一点经验分享
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
丢给gemini, 给了如下结论（在wireshark看了下，确实MAC地址在变）：
“”“
根据这份数据，导致 `10.210.151.90` TCP 连接时断时续的根本原因确实是 **IP 冲突或 MAC 地址漂移**。更具体地说，是一台 **VMware 虚拟机**和一台 **Cisco 网络设备**在“争夺”这同一个 IP 地址。
以下是从抓包文件中提取的“铁证”：
### 1. MAC 地址在两个不同厂商的设备间疯狂横跳
在 ICMP（Ping）测试阶段，您一直在向 `10.210.151.90` 发送 Ping 包，而该 IP 的物理地址（MAC）在不断发生变化：
*
**第 1、9、17 号包**：流量发往了 MAC 地址 `00:0c:29:17:d1:ab`（这属于 **VMware** 虚拟机设备） 。
*
**第 5、13 号包**：流量突然改道，发往了 MAC 地址 `00:03:fd:d1:93:60`（这属于 **Cisco** 网络设备） 。
* 这两台设备竟然都对您的 Ping 请求做出了回应（Reply） 。
### 2. TCP 连接成功的真相（VMware 才是真正的目标服务器）
当 TCP 握手数据包（目的端口 `9999`）恰好被发送到 **VMware** 的 MAC 地址时，连接是成功的：
*
**Frame 21-23**：向 VMware 发送 `SYN`，VMware 正常回复 `SYN, ACK`，您回复 `ACK`，三次握手顺利完成 。
* 这说明真正在运行 `9999` 端口业务的是这台 VMware 虚拟机。
### 3. TCP 连接失败/中断的真相（被 Cisco 设备“误杀”）
当数据包被错误地路由到 **Cisco** 设备的 MAC 地址时，灾难就发生了，表现为两种失败场景：
*
**场景 A（连接半路夭折）**：在 Frame 27-29 中，您的客户端先和 VMware 成功建立了连接 。但在 Frame 30 准备发送 `FIN, ACK` 断开连接时，数据包却发给了 Cisco 设备 。由于 Cisco 设备根本不知道有这个 TCP 连接的存在，它立刻在 Frame 31 回复了一个 `RST`（重置）报文强制掐断了连接 。
*
**场景 B（连接直接被拒）**：在 Frame 32 和 Frame 34 中，您的客户端发起新的 TCP 连接（`SYN`），但数据包直接发给了 Cisco 设备 。因为 Cisco 设备上并没有开放 `9999` 端口，所以它在 Frame 33 和 35 中立刻返回了 `RST, ACK`，导致连接秒拒 。
### 结论与可能的原因
现在情况已经完全明朗了：您的客户端（`10.210.151.187`）的 ARP 表处于一种极其不稳定的震荡状态。
这通常由以下几种情况引起：
1. **静态 IP 配置错误**：有人把 Cisco 路由器的网关 IP 地址错误地配给了这台 VMware 虚拟机，或者反之。
2. **Cisco 代理 ARP（Proxy ARP）开启**：Cisco 路由器可能开启了 Proxy ARP 功能，当它认为自己能够到达目标网络时，它会用自己的 MAC 地址代替虚拟机来响应 ARP 请求。
”“”
怎么一会儿思科一会儿VMware的，IP冲突了吧。
Pingback: ARP 问题诊断 | 卡瓦邦噶！