故障-因为MAC地址冲突造成的故障

1、问题分析与解决

1.1 症状与起因

问题症状： 访问卡慢，负载并不高

起因：

笔者有一部分物理机做了虚拟化，由于体量小就直接通过命令行工具创建，在创建时并没有通过kvm的clone命令，而是手工修改一些属性，所以就造成了产生了重复的MAC地址。

虽然问题是一个很low的问题，但是中间还是有许多反思地方，所以在这里记录一下。

2.2 排查与修复

在排查思路前，说一下角色：

目标虚拟机：192.168.100.30
搭载虚拟机的物理机：192.168.101.216
客户机器：192.168.100.21
冲突虚拟机：192.168.100.25

当时发现问题是SSH连接卡顿、慢，直接对SSH进行调优后无果，最终发现如果直接通过VNC连接目标虚拟机则没有影响，通过搭载虚拟机的物理机访问也没有影响，客户机器到搭载虚拟机的物理机访问也正常，这真的是难办了；随后拿出网络神器tcpdump直接进行抓包查看，抓包的思路如下：

客户机器抓包：主要查看数据包发出时间；
搭载虚拟机的物理机抓包：主要查看数据包转发情况；
目标虚拟机抓包：查看包接收情况；

抓包命令如下：

tcpdump ip host 192.168.100.30

最后发现异常，目标虚拟机比其他节点内机器慢2s，最终同步时间发现依然无果。

笔者之前遇到过，因配置同样IP的客户端造成网络抢占也会产生这样的原因，但是经过测试无果；当时顺着上面这个思路往下走IP不重复，那如果是MAC重复呢？

捕捉该网段内所有的存活主机的MAC地址，这里我使用Linux + nmap扫描的方式，nmap扫描如下：

[root@mdw ~]# nmap -sS 192.168.100.0/23

Starting Nmap 6.40 ( http://nmap.org ) at 2018-11-13 17:54 CST

..... 省略

然后通过过滤系统mac地址表，过滤目标问题主机的mac地址：

[root@mdw ~]# egrep "52:54:00:0c:1d:f5" /proc/net/arp

192.168.100.30   0x1         0x2         52:54:00:0c:1d:f5     *        eth0

192.168.100.25   0x1         0x2         52:54:00:0c:1d:f5     *        eth0

果然，是我们的mac地址冲突了。

2、理论分析与改善

2.1 为什么MAC地址冲突会造成这种问题？

摘录百度百科中MAC地址的作用：

谈起MAC地址，不得不说一下IP地址。IP地址工作在OSI参考模型的第三层网络层。两者之间分工明确，默契合作，完成通信过程。IP地址专注于网络层，将数据包从一个网络转发到另外一个网络；而MAC地址专注于数据链路层，将一个数据帧从一个节点传送到相同链路的另一个节点。

在一个稳定的网络中，IP地址和MAC地址是成对出现的。如果一台计算机要和网络中另一外计算机通信，那么要配置这两台计算机的IP地址，MAC地址是网卡出厂时设定的，这样配置的IP地址就和MAC地址形成了一种对应关系。在数据通信时，IP地址负责表示计算机的网络层地址，网络层设备（如路由器）根据IP地址来进行操作；MAC地址负责表示计算机的数据链路层地址，数据链路层设备（如交换机）根据MAC地址来进行操作。IP和MAC地址这种映射关系由ARP（Address Resolution Protocol，地址解析协议）协议完成 .............

每次看到这种专业术语我就头疼，把一个简单的事情用一大堆理论知识描述的晦涩难懂。那么我们可以试着这样理解比如日常生活中我们大家都会使用地图什么的APP，当我们输入到达的目的地之后，地图会给出你的线路，我们可以理解为源IP地址与目标IP地址，这有和MAC地址有啥关系？我们到达目的地是直接飞过去？并不是我们需要一个路线一个路线走，所以MAC地址可以表示下一个站点地址。

网络是一个域与域的组合产生的，而MAC地址通常用在网段内部使用；理论上MAC地址是不会冲突的，但是也存在个例，比如我们上面的情况。

理解了上面之后我们就可以理解为什么我们获取MAC只扫描当前网段了吧。所以当突然有两个MAC地址相同的站点我们的网络包就蒙了，你忽悠谁呢，所以有了后续的一系列问题。

2.2 反思改善

在KVM虚拟创建尽量使用工具来搞，但是非常情况下确实不允许，那么最好用MAC地址生成起来完成。

推荐一款在线的MAC生成器： http://www.ab126.com/web/2907.html