MAC地址漂移經(jīng)典案例分析

網(wǎng)絡(luò)拓撲如下：

兩臺運營商接入交換機之間做IRF虛擬化（就是將兩臺交換機虛擬成一臺交換機），兩臺負載均衡之間做VRRP熱備

網(wǎng)絡(luò)結(jié)構(gòu)為大二層，各鏈路的網(wǎng)關(guān)都在運營商那里

5800-2端口 g2/0/11 是連接筆記本  223.1.5.41

5800-1端口 g1/0/3  是連接到移動ISP（網(wǎng)關(guān)）223.1.5.1

問題：

有大量用戶反映移動線路的服務(wù)器ping移動網(wǎng)關(guān)（223.1.5.1）丟包，連接經(jīng)常掉線，網(wǎng)絡(luò)非常不穩(wěn)定。

既然問題出現(xiàn)了，我們就要從最近的網(wǎng)絡(luò)節(jié)點查找故障。首先將一臺筆記本配置移動IP（223.1.5.41）接到S5800-1上ping 移動網(wǎng)關(guān)正常；說明從移動運營商過來的光纖鏈路正常；

再將這臺筆記本接到S5800-2上，ping 移動網(wǎng)關(guān)丟包，ping下面的服務(wù)器正常。說明問題出在S5800-2到S5800-1之間數(shù)據(jù)丟包，而連接兩臺S5800之間只有一對用于IRF的光纖，可能問題出在這兒，所以我更換了IRF的光纖和光纖模塊。不可思議的現(xiàn)象來了，問題依舊。

C:\Users\Administrator>ping 223.1.5.1 -t

正在 Ping 223.1.5.1 具有 32 字節(jié)的數(shù)據(jù):

來自 223.1.5.1 的回復(fù): 字節(jié)=32 時間=1ms TTL=254

Request timed out.

Request timed out.

Request timed out.

來自 223.1.5.1 的回復(fù): 字節(jié)=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     動態(tài)

 223.1.5.41          00-22-15-4c-5d-42     動態(tài)

這........不可能啊，按已知條件建立數(shù)學(xué)模型的結(jié)果是唯一的,不會出現(xiàn)這種邏輯錯誤啊。連接兩臺S5800之間只有一對用于IRF的光纖，數(shù)據(jù)傳輸也只能通過這對IRF光纖。如果光纖和光纖模塊都沒有問題，那只能說明數(shù)據(jù)通過IRF光纖傳到S5800-1上后，在交換機內(nèi)部丟失了一部分.........

好！我們做個流量統(tǒng)計來驗證這個情況：

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)

說明在交換機內(nèi)部丟包，即從S5800-2的g2/0/11口inbound方向發(fā)出100個數(shù)據(jù)包，到S5800-1的g1/0/3口outbound方向數(shù)據(jù)包變成了64個。那么剩下的36個數(shù)據(jù)包哪兒去了呢？真的是在5800-1交換機內(nèi)部丟失了？好！讓我?guī)е蠹业浇粨Q機內(nèi)部來看看，那消失的36個數(shù)據(jù)包到底去了哪里。

[5800-1]en_diag                   \\進入隱藏模式

[5800-1]debug port mapping 1       \\顯示端口對應(yīng)內(nèi)部口

[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

在這里看交換機內(nèi)部口port 5 為g1/0/3端口，交換機內(nèi)部口port 27 為XGE1/0/26端口

由于二層交換機的數(shù)據(jù)包轉(zhuǎn)發(fā)只跟MAC地址有關(guān)，那么我們就來看看移動網(wǎng)關(guān)MAC地址0x00005e000165都去了哪里。（大家最好先學(xué)習(xí)一下二層交換機的數(shù)據(jù)包轉(zhuǎn)發(fā)過程原理）

[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中分別出現(xiàn)在g1/0/3口（連接到移動網(wǎng)關(guān)）和XGE1/0/26口（連接到負載均衡-1設(shè)備）。

mac=0x00005e000165怎么會出現(xiàn)在負載均衡-1設(shè)備上？難道丟包的36個數(shù)據(jù)包都跑到負載均衡-1設(shè)備上了？

登陸負載均衡-1設(shè)備上，發(fā)現(xiàn)有一組VRRP（VRID=101）的虛擬MAC地址真的就是mac=0x00005e000165，與移動網(wǎng)關(guān)的MAC地址相同，可令人費解的是負載均衡設(shè)備已經(jīng)一年沒更改過配置了啊。難到是移動運營商將MAC地址改了？

為了不影響業(yè)務(wù)，馬上綁定移動網(wǎng)關(guān)的MAC地址

解決方法：

將移動網(wǎng)關(guān)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設(shè)備并也做了主備VRRP，VRID恰好也為101，而VRRP建立時MAC地址不是隨機的，而是統(tǒng)一從VRID 101  MAC=0000-5e00-0165 ，VRID 102  MAC=0000-5e00-0166……….以此類推。

而BRAS設(shè)備和負載均衡設(shè)備都沒有vrrp method real-mac 即取得真實接口MAC地址的選項，所以導(dǎo)致MAC地址沖突……..

現(xiàn)在很多設(shè)備雖然有VRRP熱備功能，但都沒有配置或不支持實MAC地址功能。

細心的朋友可能已經(jīng)發(fā)現(xiàn)，這是一個由VRRP引起的可以影響大規(guī)模網(wǎng)絡(luò)故障的漏洞啊！

本文章用到了一些交換機調(diào)試及配置命令，都是很難在網(wǎng)上找到的，比如流量統(tǒng)計的配置方法、H3C隱藏模式下的調(diào)試命令等，大家可以借鑒學(xué)習(xí)。

我寫這篇文章的目的是向朋友們闡述一個網(wǎng)絡(luò)故障排查的方法，即按已知條件建立數(shù)學(xué)模型的結(jié)果是唯一的，不符合邏輯的問題是因為給出的已知條件存在錯誤?。。?/span>