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隐藏模式下的调试命令等，大家可以借鉴学习。

我写这篇文章的目的是向朋友们阐述一个网络故障排查的方法，即按已知条件建立数学模型的结果是唯一的，不符合逻辑的问题是因为给出的已知条件存在错误！！！