智聖新創｜某高校接入交換機埠環路導致交換機丟包和終端異常

一、組網描述

某高校宿舍有線網採用大二層架構，利用QINQ技術使得接入交換機每個埠一個單獨的VLAN，從而避免ARP、DHCP欺騙，廣播風暴等。核心採用H3C SR8808-X作為BRAS設備，用來進行QINQ終結以及終端用戶的PPPOE Server，實現終端用戶的接入認證。

QINQ外層VLAN標籤在RG S8610下聯宿舍樓匯聚S5560的接口上啟用，內層VLAN標籤在接入交換機E528上。

二、問題描述

某日，從網管軟體上收到217號宿舍樓匯聚和接入交換機丟包率高報警，經檢查，發現網管軟體的217號樓宿舍樓的設備丟包率達70%。

同時終端PC PPPOE撥號錯誤651。

三、處理過程

1.對網管軟體的丟包告警進行驗證；

PING 217號樓設備發現丟包率很高，遠程登錄設備發現操作特別卡頓，說明網管軟體的丟包率告警並非軟體誤報。

2.通過網管軟體發現其它宿舍樓宇的設備並未出現丟包率高報警，因此排除S8610到SR8808-X之間的物理線路和設備問題，同時僅該宿舍樓出現問題，懷疑是S8610的G2/8口有丟包，於是檢查S8610的G2/8接口。發現接口下有錯誤包和丟包，但是數量不是很多，增長速度也不快；

3.嘗試更換G2/8口下的單模光模塊後，觀察一段時間發現G2/8口未在出現錯誤包和丟包，收發光衰都在正在範圍，同時網管軟體上的217號樓丟包率高報警消除，撥號正常；

4.至此，以為出現丟包率高報警的原因是光模塊導致。

5.過了大約一周的時間，網管軟體再次發出217號樓設備丟包率高報警，按照之前同樣的方法進行排查，發現S8610的G2/8接口並沒有出現錯誤包和丟包情況。

6.回歸拓撲圖，考慮到217號樓設備的網關均在SR8808-X上，因此分段進行排查。先排查217號樓匯聚H3C S5560到SR8808-X路徑上的丟包情況，經過測試發現SR8808-X到S8610並沒有丟包，SR8610到S5560丟包嚴重。

7.因此懷疑丟包在S8610-----S5560兩臺設備和中間鏈路存在問題。於是在S8610上開啟ACL計數判斷丟包是否由設備本身造成。

在S8610上配置如下：其中172.16.204.44是217號樓匯聚S5560的管理地址，211.70.160.82是測試PC，可以認為是接在SR8808-X上；

ip access-list extended test

10 permit ip host 172.16.204.44 host211.70.160.82

20 permit ip any any

ip access-list extended test1

10 permit ip host 172.16.204.44 host211.70.160.82

20 permit ip any any

在分別在G2/8的IN方向，和AG6口的出方向丟用ACL，進行計數；

interface GigabitEthernet 2/8

switchport mode dot1q-tunnel

switchport dot1q-tunnel allowed vlan adduntagged 3608

switchport dot1q-tunnel native vlan 3608

medium-type fiber

ip access-group test in

spanning-tree bpdufilter enable

descriptionto_SS217_WiredNet_HuiJu_S5560_G1/0/28

interface AggregatePort 6

switchport mode uplink

switchport trunk allowed vlan remove1-3600,3615-4094

ip access-group test1 out

description to_SR8808-X(wirednet)

8.經過一段時間觀察後，發現從G2/8口收到了1088421個數據包，但是從上聯口僅轉發出去1088362，少了59個包，並且隨著時間的推移這個差值在增加。

9.對 S8610 設備的底層 buffer 計數，發現部分埠有丟包計數，摘取部分 log 如下：

DROP_PKT_CNT(3).cpu0[0xe200043]=0x49fd: <COUNT=0x49fd>

DROP_PKT_CNT(0).ge1[0xe21f040]=0x96: <COUNT=0x96>

DROP_PKT_CNT(0).ge2[0xe220040]=0x2c0: <COUNT=0x2c0>

DROP_PKT_CNT(0).ge3[0xe221040]=0xb21: <COUNT=0xb21>

DROP_PKT_CNT(0).ge7[0xe225040]=0x19b1:<COUNT=0x19b1>

10.經過與銳捷廠家確認後，目前S8610的兩塊千兆線卡的MAC晶片的buffer大小是3MB，當發送到某一個埠的瞬時流量超過千兆時，其埠就會丟包。當流量高峰期時，出現burst（突發）流量，是有可能因為buffer不足導致丟包的；

11.根據廠家的答覆可能是設備硬體規格不夠導致丟包，對此我是持懷疑態度的，主要有兩方面原因：

1)客戶現場有2塊這種規格的千兆業務板卡，目前出現問題的只有其中一塊，並且通過網管軟體的監控，未出現問題的板卡流量一直要比出現問題的板卡流量大；

2)通過網管軟體的監控，出現丟包的板卡單個千兆口最大高峰期流量200Mbps，並沒有達到「瞬時流量超過千兆」

經過廠家的確定後，如果是硬體問題，只能新增業務板卡進行分流，沒有其它好的解決方案。

12.過了大約2周後，丟包現象再次出現，利用ACL計數同樣發現包丟在S8610上，但是經過檢查，S8610底層上並沒有丟包記錄，也就是說這次丟包不是硬體buffer不足導致。

13.考慮到S8610僅根據MAC地址做二層轉發，懷疑是不是有什麼造成S8610上的MAC地址表學習錯誤導致轉發失敗。

14.因為終端和設備的網關均在SR8808-X上，而S8610作為二層設備，只是根據數據幀中的目的MAC地址（網關的MAC地址）轉發，丟包有可能是數據幀中的目的MAC地址在S8610的MAC地址表中不存在表項或者對應的出接口不正確。基於此，想到通過二層ACL計數確定網關的MAC地址在S8610是通過正確上聯口AG6口學習到。做了如下配置：

1)創建二層ACL，其中741f.4ac5.f802為網關的MAC地址

mac access-listextended 700

10 permit host 741f.4ac5.f802 any etype-any

20 permit any any etype-any

2)在所有接口下應用該ACL，上聯口除外

mac access-group 700 in

3)開啟對該ACL計數功能

mac access-list counter 700

15.果不其然，一段時間後發現ACL有計數，並且數量很多。正常情況下，網關的MAC地址不可能從下聯口學習到，出現這種情況一般有兩個原因：

1）有設備一直在模擬網關的MAC作為數據幀的源MAC在發送數據，導致S8610上MAC地址學習錯誤；

2）接口下聯設備有環路；

16.為了定位在S8610的哪個接口學習到MAC地址，通過不停的在S8610上執行命令：

xq_stud_huiju_S8610rldp enable

xq_stud_huiju_S8610(config-if-GigabitEthernet 1/1)#rldpport loop-detect block

五、總結

1.對於該種組網方式，利用QINQ已經實現每埠每VLAN，避免了設備之間的環路，廣播風暴，ARP、DHCP等欺騙，但是無法避免接入交換機某個埠的環路；

2.利用單埠環路檢測可以解決該問題，原理是：設備啟用了單埠環路檢測後，會從接口向外發送檢測包，如果從該接口又收到了檢測包，說明該接口下有環路。

H3C設備會根據配置對埠進行相應的處理：

1）block：將該埠阻塞，不進行數據轉發，埠物理狀態UP，同時設備日誌中會有告警；

2）shutdown：將該埠關閉，不進行數據轉發，埠物理狀態down，同時設備日誌中會有告警；

銳捷的設備會根據配置對埠進行如下處理：

1）block：將該埠阻塞，不進行數據轉發，埠物理狀態UP，同時設備日誌中會有告警；

2）shutdown-port：將該埠關閉，不進行數據轉發，埠物理狀態down，同時設備日誌中會有告警；

3）shutdown-svi：將該埠對應svi置於shutdown狀態，同時設備日誌中會有告警；

4）warning：設日誌中僅發出告警，不做其它操作；

一般建議使用shutdown方式，這樣排錯時也比較容易，同時設備又不損耗資源。

3.強烈建議此種組網方式，必須要在接入設備上開啟單埠環路檢測功能；