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