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隱藏模式下的調試命令等，大家可以借鑒學習。

我寫這篇文章的目的是向朋友們闡述一個網絡故障排查的方法，即按已知條件建立數學模型的結果是唯一的，不符合邏輯的問題是因為給出的已知條件存在錯誤！！！