MAC地址漂移经典案例分析
网络拓扑如下：
两台运营商接入交换机之间做IRF虚拟化（就是将两台交换机虚拟成一台交换机），两台负载均衡之间做VRRP热备
网络结构为大二层，各链路的网关都在运营商那里
5800-2端口 g2/0/11 是连接笔记本 223.1.5.41
5800-1端口 g1/0/3 是连接到移动ISP（网关）223.1.5.1
问题：
有大量用户反映移动线路的服务器ping移动网关（223.1.5.1）丢包，连接经常掉线，网络非常不稳定。
既然问题出现了，我们就要从最近的网络节点查找故障。首先将一台笔记本配置移动IP（223.1.5.41）接到S5800-1上ping 移动网关正常；说明从移动运营商过来的光纤链路正常；
再将这台笔记本接到S5800-2上，ping 移动网关丢包，ping下面的服务器正常。说明问题出在S5800-2到S5800-1之间数据丢包，而连接两台S5800之间只有一对用于IRF的光纤，可能问题出在这儿，所以我更换了IRF的光纤和光纤模块。不可思议的现象来了，问题依旧。
C:\Users\Administrator>ping 223.1.5.1 -t
正在 Ping 223.1.5.1 具有 32 字节的数据:
来自 223.1.5.1 的回复: 字节=32 时间=1ms TTL=254
Request timed out.
Request timed out.
Request timed out.
来自 223.1.5.1 的回复: 字节=32 时间=1ms TTL=254
Request timed out.
C:\Users\Administrator>arp -a
接口: 223.1.5.2 --- 0xb
Internet 地址 物理地址 类型
223.1.5.1 00-00-5e-00-01-65 动态
223.1.5.41 00-22-15-4c-5d-42 动态
这........不可能啊，按已知条件建立数学模型的结果是唯一的,不会出现这种逻辑错误啊。连接两台S5800之间只有一对用于IRF的光纤，数据传输也只能通过这对IRF光纤。如果光纤和光纤模块都没有问题，那只能说明数据通过IRF光纤传到S5800-1上后，在交换机内部丢失了一部分.........
好！我们做个流量统计来验证这个情况：
telnet 10.10.10.12 \\S5800的IP地址
sys
acl number 3876
rule permit ip source 223.1.5.41 0destination 223.1.5.1 0
rule permit ip source 223.1.5.1 0destination 223.1.5.41 0
quit
traffic classifier aaa
if-match acl 3876
quit
traffic behavior aaa
accounting packet
quit
qos policy aaa
classifier aaa behavior aaa
quit
interface GigabitEthernet 2/0/11
qos apply policy aaa inbound
qos apply policy aaa outbound
quit
interface GigabitEthernet1/0/3
qos apply policy aaa inbound
qos apply policy aaa outbound
quit
测试：用笔记本223.1.5.41 ping223.1.5.1 -n 100 \\ 共ping了100个包只收到64个
[5800]display qos policy interfaceGigabitEthernet 2/0/11
Interface: GigabitEthernet2/0/11
Direction: Inbound
Policy: aaa
Classifier: aaa
Operator: AND
Rule(s) : If-match acl 3876
Behavior: aaa
Accounting Enable:
100 (Packets)
Direction: Outbound
Policy: aaa
Classifier: aaa
Operator: AND
Rule(s) : If-match acl 3876
Behavior: aaa
Accounting Enable:
64 (Packets)
[5800]display qos policy interfaceGigabitEthernet 1/0/3
Interface: GigabitEthernet1/0/3
Direction: Inbound
Policy: aaa
Classifier: aaa
Operator: AND
Rule(s) : If-match acl 3876
Behavior: aaa
Accounting Enable:
64 (Packets)
Direction: Outbound
Policy: aaa
Classifier: aaa
Operator: AND
Rule(s) : If-match acl 3876
Behavior: aaa
Accounting Enable:
64 (Packets)
说明在交换机内部丢包，即从S5800-2的g2/0/11口inbound方向发出100个数据包，到S5800-1的g1/0/3口outbound方向数据包变成了64个。那么剩下的36个数据包哪儿去了呢？真的是在5800-1交换机内部丢失了？好！让我带着大家到交换机内部来看看，那消失的36个数据包到底去了哪里。
[5800-1]en_diag \\进入隐藏模式
[5800-1]debug port mapping 1 \\显示端口对应内部口
[Interface] [Unit] [Port][Name][Combo?][Active?][IfIndex][MID][Link] [Attr]
==============================================================================
GE1/0/1 0 3 ge2 no no 0x900000 4 down Bridge
GE1/0/2 0 2 ge1 no no 0x900001 4 down Bridge
GE1/0/3 0 5 ge4 no no 0x900002 4 up Bridge
..
..
XGE1/0/25 0 26 xe0 no no 0xbc0018 4 up Bridge
XGE1/0/26 0 27 xe1 no no 0xbc0019 4 up Bridge
XGE1/0/27 0 28 xe2 no no 0xbc001a 4 up Bridge
XGE1/0/28 0 29 hg0 no no 0xbc001b 4 up Bridge
在这里看交换机内部口port 5 为g1/0/3端口，交换机内部口port 27 为XGE1/0/26端口
由于二层交换机的数据包转发只跟MAC地址有关，那么我们就来看看移动网关MAC地址0x00005e000165都去了哪里。（大家最好先学习一下二层交换机的数据包转发过程原理）
[5800-diagnose]bcm 1 0l2/conflict/mac=0x00005e000165/vlan=5
（slot1）(2层/冲突/mac/vlan)
conflict: mac=00:00:5e:00:01:65 vlan=5modid=4 port=5/ge4 SDHit Group=Learnt
[5800-diagnose]bcm 1 0l2/conflict/mac=0x00005e000165/vlan=5
conflict: mac=00:00:5e:00:01:65 vlan=5modid=4 port=5/ge4 SDHit Group=Learnt
[5800-diagnose]bcm 2 0l2/conflict/mac=0x00005e000165/vlan=5
（slot2）(2层/冲突/mac/vlan)
conflict: mac=00:00:5e:00:01:65 vlan=5modid=4 port=5 SDHit Group=Learnt
[5800-diagnose]bcm 2 0l2/conflict/mac=0x00005e000165/vlan=5
conflict: mac=00:00:5e:00:01:65 vlan=5modid=4 port=27 SDHit Group=Learnt
注意：共测试了4次，前2次是slot1即s5800-1里，MAC地址无漂移一直在port=5；
后2次是s5800-2里，MAC地址有漂移，一次是port=5，而另一次是port=27
port=5（g1/0/3） port=27(XGE1/0/26) 说明mac=0x00005e000165在S5800-2中分别出现在g1/0/3口（连接到移动网关）和XGE1/0/26口（连接到负载均衡-1设备）。
mac=0x00005e000165怎么会出现在负载均衡-1设备上？难道丢包的36个数据包都跑到负载均衡-1设备上了？
登陆负载均衡-1设备上，发现有一组VRRP（VRID=101）的虚拟MAC地址真的就是mac=0x00005e000165，与移动网关的MAC地址相同，可令人费解的是负载均衡设备已经一年没更改过配置了啊。难到是移动运营商将MAC地址改了？
为了不影响业务，马上绑定移动网关的MAC地址
解决方法：
将移动网关223.1.5.1的MAC绑定到g1/0/3口上
telnet 10.10.10.12 \\登陆S5800
interface GigabitEthernet1/0/3
mac-address static 0000-5e00-0165 vlan 5
给移动运营商打电话得知：原来在前一天晚上，移动运营商在机房又添加了一台bras设备并也做了主备VRRP，VRID恰好也为101，而VRRP建立时MAC地址不是随机的，而是统一从VRID 101 MAC=0000-5e00-0165 ，VRID 102 MAC=0000-5e00-0166……….以此类推。
而BRAS设备和负载均衡设备都没有vrrp method real-mac 即取得真实接口MAC地址的选项，所以导致MAC地址冲突……..
现在很多设备虽然有VRRP热备功能，但都没有配置或不支持实MAC地址功能。
细心的朋友可能已经发现，这是一个由VRRP引起的可以影响大规模网络故障的漏洞啊！
本文章用到了一些交换机调试及配置命令，都是很难在网上找到的，比如流量统计的配置方法、H3C隐藏模式下的调试命令等，大家可以借鉴学习。
我写这篇文章的目的是向朋友们阐述一个网络故障排查的方法，即按已知条件建立数学模型的结果是唯一的，不符合逻辑的问题是因为给出的已知条件存在错误！！！
