【交換機在江湖-維護無憂系列】網路丟包故障專題
1前言 概述 園區中完成網路部署後,在管理和維護的過程中,我們時常會遇到網路傳輸延遲導致上網連線時斷時續,或者使用者上網速度異常緩慢的現象,這些現象幾乎大多都是由網路資料丟包引起的。 網路中故障發生在所難免,重要的是如何快速隔離及排除故障。如何準確、有效地解決這些故障現象是我們維護人員經常需要思考的問題。 本文件圍繞部署S系列交換機的網路中丟包現象進行分析,描述了定位方法和解決步驟,同時提供了相關的典型案例及參考資訊,希望為維護人員遇到網路丟包時提供參考。 由於硬體形態的差異,不同裝置支援的功能特性及支援的命令列可能不同。本文件中涉及的命令以V200R008C00版本為例,使用時請參考裝置對應版本的產品文件。 修改記錄 釋出日期 修改說明 02 2017-01-31 第二次正式釋出。 01 2016-12-30 第一次正式釋出。 2網路丟包的定位與處理 2.1確認發生網路丟包 網路丟包的故障現象通常表現為: l使用者上網時: −網路速度不穩定,開啟網頁的速度特別的慢,有時候還會出現網頁部分內容或是整個頁面無法顯示的問題; −觀看視訊業務時有馬賽克或花屏等卡頓現象; −QQ等即時通訊工具等頻繁掉線或提示登陸超時; −下載檔案速度慢; l交換機工作時: −在交換機上執行Ping操作,對網路進行連通性測試,提示超時; −埠無法正常轉發資料; −管理使用者登入交換機,提示超時; −業務經常中斷; 這些故障現象幾乎都跟網路丟包有關。如果現網當中出現以上故障現象中的一種或多種,基本可以確認發生了網路丟包。 2.2排查產生丟包現象的PC 排查產生丟包現象的PC本身問題。 如PC的網絡卡是否正常、PC連線裝置的線纜是否正常都有可能造成裝置丟包。解決方法:斷開網路後給PC查殺病毒、檢查網線重灌作業系統、檢查網絡卡等。 確認PC正常後,如果故障仍然存在,繼續執行下一步。 2.3檢查介面物理狀態是否為Down 一般來說,介面的物理狀態Down,或介面雙工模式或速率協商模式與對端不一致,會造成介面的狀態異常。 1.在裝置上執行display interface 這裡以檢查Switch_3的GE1/0/2為例。 <HUAWEI> display interface gigabitethernet 1/0/2 −輸出資訊顯示“current state : UP”,表明介面的執行狀態正常。請跳過本節,參考下一節進行定位與處理。 −輸出資訊顯示“current state : Administratively down”,表示介面被人為Shutdown。 請在系統檢視下執行interfaceinterface-type interface-number進入故障介面檢視,然後執行display this命令檢視介面是否執行了shutdown操作,如果是請在介面下執行undo shutdown命令。 −輸出資訊顯示“current state : DOWN”,則需要檢視介面的協商狀態、速率、雙工模式以及網線適應方式是否鏈路兩端保持一致。 分別在鏈路兩端的裝置執行display interface命令檢視以上資訊,如表2-1所示。 表2-1檢查鏈路兩端的裝置介面雙工、速率、協商模式 顯示資訊解釋說明 後續操作 Negotiation 介面協商狀態 l“ENABLE”:自協商狀態。 l“DISABLE”:非自協商狀態。 保持兩邊的協商狀態一致,要麼都工作在自協商狀態下,要麼都工作在非自協商狀態下。 1.在介面檢視下可以執行命令negotiation auto配置介面工作在自協商狀態。 2.如果自協商狀態下介面仍然頻繁Down,可以嘗試將介面改成非自協商狀態,同時強制兩邊速率、雙工一致。 Speed 介面當前速率。 l自協商狀態下,如果鏈路兩端的裝置介面速率不一致,可以執行命令restart再重啟介面,使之重新協商為一致。 l在非自協商狀態下,如果鏈路兩端的裝置介面速率不一致,在介面檢視下執行speed{10|100|1000}命令配置介面速率為一致。 說明 對於電口,當出現協商成10M/100M工作正常,而協商成1000M工作異常時,請檢測網線是否正常,如果有問題請更換網線。 Duplex 介面工作的雙工模式。 lFULL:全雙工模式。 lHALF:半雙工模式。 l自協商狀態下,如果裝置兩端介面雙工不一致,可以執行命令restart再重啟介面,使之重新協商為一致。或者在介面檢視下執行命令auto duplexfull將介面設定為全雙工模式。 l非自協商狀態下,如果裝置兩端介面雙工不一致,請在介面檢視下執行命令duplex full將介面設定為全雙工模式。 Mdi 介面的網線適應方式。 lacross:交叉網線。 lauto:自動識別網線。即與該介面實際連線的網線型別既可以使用直通網線也可以使用交叉網線。 lnormal:直通網線。 保證兩端裝置介面的網線適應方式和網線型別一致。 預設情況下,網線適應方式為auto模式,如果介面網線適應方式為非auto模式,請在介面檢視下執行mdi auto命令更改為auto模式。 −輸出資訊顯示“current state : ERROR DOWN (down-cause)”,表示介面由亍錯誤事件而被Shutdown,需要根據down-cause具體欄位資訊排查故障。 請參考《S系列交換機乙太網介面物理DOWN故障專題》進行排查。 如果介面的執行狀態仍然Down,請執行下一步。 2.嘗試將線纜連線到其他空閒介面,檢查介面狀態是否正常。 −如果介面的物理狀態仍然Down,請聯絡技術支援工程師。 −如果介面執行狀態為UP、工作在全雙工模式,並且自協商狀態和對端一致,表明介面狀態正常。而丟包現象仍然存在,請參考下一節內容。 2.4檢查介面入方向是否存在CRC校驗錯誤 本節點內容也應該包含在“檢查裝置的介面狀態”章節,但由於擁塞造成丟包的現網問題較多,所以在此單獨介紹。 檢查報文經過的物理埠是否存在CRC校驗錯誤,且錯誤計數是否在不斷增長。 如果輸出資訊顯示欄位“CRC”有計數,且重複執行命令發現計數在不斷增長,說明埠接收到了CRC錯誤報文,即存在CRC校驗錯誤,說明是由於物理鏈路或者裝置問題導致的錯包。 請參考2.10.3檢查裝置之間的物理鏈路排查物理鏈路問題,如果問題仍然存在,請聯絡技術支援工程師處理。 <HUAWEI>display interface gigabitethernet 1/0/2 2.5檢查接口出方向是否存在Discard計數 本節點內容也應該包含在“檢查裝置的介面狀態”章節,但由於擁塞造成丟包的現網問題較多,所以在此單獨介紹。 擁塞是指網路資源不足而造成速率下降,引入額外延時的現象。當網路中存在大量的組播流容易引起流量突發,或者多業務並存的複雜環境下,擁塞現象極為常見。流量突發導致裝置介面傳送頻寬超出限制,裝置出現擁塞丟包。 1.檢查埠是否存在Discard丟包計數。 在任意檢視執行命令display interfaceinterface-typeinterface-number,或在介面檢視執行命令display this interface,檢視裝置連線使用者側端口出方向報文計數,存在Discard丟包計數則說明埠曾經存在擁塞。在業務受到影響時,觀察該Discard是否增加。 −如果不增加,則業務影響與Discard丟包無關。請跳過該節,參考下一節進行問題定位。 −如果增加,則業務影響與Discard丟包相關,請執行下一步; [HUAWEI]display interface GigabitEthernet 1/0/2 2.配置介面快取管理的突發模式為增強模式,檢查埠Discard計數是否增加。 一般來說,交換機介面快取較小,介面上的流量如果突發達到介面頻寬的50%~60%左右就會出現丟包現象。而在介面上配置快取管理的突發模式為增強模式,單個介面可以搶佔到更多的剩餘動態快取,介面應對流量突發的能力更強,擁塞丟包現象就會減少。 <HUAWEI> system-view X1E系列單板不支援此命令。 配置為增強模式時,qos burst-mode(介面檢視)命令與qos burst-mode(系統檢視)命令不能同時配置,且上述兩條命令均不能與qos queue length命令同時配置。 重新執行步驟1,檢查埠Discard計數是否增加。 −如果不增加,則擁塞問題解決。觀察丟包現象是否解決,如果未解決,請跳過該節,參考下一節進行問題定位。 −如果仍然增加或裝置不支援qos burst-mode命令,則需要優化網路,請執行下一步。 3.優化網路。 一般從以下方面考慮,來進行網路優化: −對裝置的上行流量做限速或進行流量整形 突發是造成網路中無規則丟包的主要原因,當突發的尺寸超過埠快取的限制時,就會存在業務丟包,從而可能影響到客戶的業務。從這方面來說,在上游裝置對使用者的資料做限速或進行流量整形,在一定程度上可以減少突發的產生或者減少突發尺寸,在下行裝置上出現突發的擁塞丟包的可能性就會降低。 −對埠業務進行差分服務,關鍵業務入高優先順序佇列,在擁塞時得到優先處理 一般而言,介面上承載的業務比較多,有高優先順序的業務(如語音,視訊業務),也有低優先順序的業務(如上網業務)。對於高優先順序的業務在上行裝置指定不同的優先順序,或者在裝置的入方向進優先順序對映,確保在出方向時,關鍵業務入高優先順序佇列,在出方向配置PQ排程,確保高優先順序的業務能夠得到優先排程。 −如果有多條流量衝突,可以擴大裝置之間的鏈路頻寬,或者用Eth-Trunk增加成員埠負載分擔。 −如果裝置使用了組播業務,通過調整組播源伺服器發包方式,對伺服器發包優化,減小發生流量擁塞的情況。 2.6檢查是否存在環路 這是最容易造成丟包現象的因素,並且具有比較強的隱蔽性,例如在較大型的網路環境中,管理員很容易把交換機之間的埠連線錯誤,從而引起網路環路,導致丟包。 1.觀察是否出現如下環路相關的現象。 網路出現環路後,除了產生丟包現象,一般還有如下現象產生: −執行display interface brief | include up命令,檢視所有Up介面下的流量,存在環路的介面上InUti和OutUti兩個計數會逐步增加,甚至接近100%,遠遠超過業務流量。 第一次查詢: <SwitchA>display interface brief | include up 最後一次查詢: <SwitchA>display interface brief | include up −使用display interface命令檢視該介面統計資訊時,發現介面收到大量廣播報文。 −裝置上發生環路的VLAN的介面指示燈頻繁閃爍。 −裝置CPU佔用率超過80%。 <SwitchB>display cpu-usage 執行命令display cpu-usage檢視CPU的利用率。網路環路會導致CPU利用率一直很高,報文未經處理就被裝置丟棄了。 −裝置出現頻繁的MAC漂移。 n執行命令display trapbuffer,檢視是否存在MAC漂移告警記錄。 MAC漂移時有如下告警記錄。 L2IFPPI/4/MFLPVLANALARM:OID 1.3.6.1.4.1.2011.5.25.160.3.7 MAC move detected, VlanId = 22, MacAddress = 0000-5e00-0116, Original-Port = Eth-Trunk1, Flapping port = Eth-Trunk11. Please check the network accessed to flapping port. 觀察是否存在和Ping丟包相關裝置的MAC地址在漂移。 n執行mac-address flapping detection命令配置MAC地址漂移檢測功能,然後通過display mac-address flapping record命令來判斷是否出現MAC地址漂移。 <HUAWEI>system-view n多次執行display mac-address來觀察,若MAC地址在交換機不同的介面學習到,則存在MAC地址漂移。 <HUAWEI>display mac-address −裝置部署環路檢測功能後,裝置出現環路告警。 環路相關告警如表2-2所示。 表2-2交換機上環路相關告警 告警資訊 告警解釋 1.3.6.1.4.1.2011.5.25.174.3.1 LDT/4/DetectLoop: OID [oid] The port detected loop. (InterfaceIndex: [INTEGER] InterfaceName: [OCTET] VlanListLow: [OCTET] VlanListHigh: [OCTET]) 如果本埠發出去的報文又通過該埠所屬VLAN轉發回到該裝置埠,說明發生報文環回,環路的存在可能導致廣播風暴。 當檢測到這種環回現象後,產生此告警。 1.3.6.1.4.1.2011.5.25.174.3.2 LDT/4/LoopResume: OID [oid] The detected loop is removed. (InterfaceIndex: [INTEGER] InterfaceName: [OCTET] VlanListLow: [OCTET] VlanListHigh: [OCTET]) 本埠發生的報文環回現象消失。 1.3.6.1.4.1.2011.5.25.174.3.3 LBDT/4/PORTTRAP: OID [OID] Loopback exists on interface([INTEGER1]) [OCTET1] ([OCTET2]), loopback detection status: [INTEGER2].(1:normal; 2:block; 3:shutdown; 4:trap; 5:nolearn; 6:quitvlan) 裝置檢測到埠下的二層網路發生環路時上報告警。 1.3.6.1.4.1.2011.5.25.174.3.4 LBDT/4/PORTTRAP: OID [OID] Loopback is removed on interface([INTEGER1]) [OCTET], loopback detection status: [INTEGER2].(1:normal; 2:block; 3:shutdown; 4:trap; 5:nolearn; 6:quitvlan) 環路檢測功能檢測到埠環路消失後上報告警恢復。 根據檢視到的環路相關資訊,結合現網情況,選擇處理方法。 1.通過介面指示燈的閃爍情況和介面流量情況,確認存在廣播風暴的介面。 2.根據鏈路拓撲,逐跳排查產生環路的裝置。 3.判斷產生環路的介面並破環。 根據定位方法,可以發現GE0/0/2可能存在環路,從而導致SwitchB處理Ping報文的時候丟包。為了進一步確認是不是環路問題導致SwitchB上丟包,此時可以關閉SwitchB的GE0/0/2的介面,然後執行Ping操作進行測試。 #關閉SwitchB的GE0/0/2的介面。 <SwitchB>system-view #執行Ping操作。 <SwitchB>ping -c 100 192.168.2.21 確認是SwitchB下掛網路環路引起Ping丟包問題後,關閉埠不能從根本上解決問題,此時需要去解決下掛網路的環路問題。通常我們可以部署RRPP、SEP、Smart Link、STP/RSTP/MSTP等協議,對環路進行處理。 4.如果執行上述措施後仍然無法解決問題,請收集組網資訊(包括埠連線情況)和日誌資訊(可以是log.log日誌檔案,也可以是執行display logbuffer輸出的資訊),聯絡華為交換機經銷商。 這裡僅介紹關於網路環路的簡單定位方法和處理建議,詳細資訊請參考《S交換機環路故障專題》文件。 2.7檢查是否存在攻擊 發生網路攻擊時,交換機忙於處理來自於攻擊源的非正常網路互動請求,無法處理其他業務造成丟包。 常見的網路攻擊包括ARP、ARP-Miss以及DHCP等協議報文攻擊,這些攻擊行為的共同特點是攻擊源產生大量的協議報文對裝置進行衝擊,因此可以在裝置上看到大量上送CPU的報文統計。 lARP協議報文攻擊和ARP-Miss協議報文攻擊 lDHCP協議報文攻擊 l其他攻擊 −ICMP攻擊 −DDoS攻擊 −廣播報文攻擊 −TTL-expired報文攻擊 −目的IP為裝置IP的報文攻擊 −SSH/FTP/Telnet等應用層協議報文攻擊 1.使用display cpu-defend statistics命令檢視上送CPU報文的統計資訊,判斷是否存在過多由於來不及處理而丟棄的協議報文。 a.執行reset cpu-defend statistics命令,清除上送CPU報文的統計資訊。 b.隔幾秒display cpu-defend statistics命令,檢視上送CPU報文的統計資訊。 如果觀察到某種協議報文過多,根據組網判斷是否可能出現這麼多的協議報文。如果不可能出現這麼多協議報文,則可基本判斷為協議報文的攻擊。 <HUAWEI>reset cpu-defend statistics 可以觀察到這臺裝置出現過多被丟棄的ARP-Request報文,如果現網不可能出現這麼多的ARP-Request報文,確定裝置遭受到了ARP攻擊。 2.使用本機防攻擊的攻擊溯源功能找出攻擊源。 裝置提供本機防攻擊功能來保護CPU,解決CPU因處理大量正常上送CPU的報文或者惡意攻擊報文造成的業務中斷問題。本機防攻擊策略主要包括攻擊溯源、埠防攻擊、CPCAR和黑名單這四大功能。 關於本機防攻擊功能的詳細資訊,請參考《S系列交換機CPU佔用率高故障專題》。 a.建立基於攻擊溯源的本機防攻擊策略。 i.建立ACL,用於將閘道器IP加入攻擊溯源的白名單。 <HUAWEI>system-view ii.建立基於攻擊溯源的本機防攻擊策略。 [HUAWEI]cpu-defend policy policy1 b.應用本機防攻擊策略。 框式交換機 對框式交換機來說,主控板和介面板上均有CPU,本機防攻擊策略的配置和應用也需要按主控板和介面板來做區分。 先檢查主控板和介面板的受報文攻擊情況,再建立防攻擊策略並應用。如果主控板和介面板上受報文攻擊的情況相同,可以在主控板和介面板上應用相同的防攻擊策略,否則需要應用不同的防攻擊策略。 i.在主控板上應用防攻擊策略。 <HUAWEI>system-view ii.在介面板上應用防攻擊策略。 如果在所有介面板上應用防攻擊策略,則不能在指定介面板上應用該防攻擊策略。反之亦然。 □如果裝置的介面板承載業務類似,在所有介面板上應用防攻擊策略。 <HUAWEI>system-view □如果裝置的介面板承載業務各有差異,在指定介面板上應用防攻擊策略。 <HUAWEI>system-view 盒式交換機 n非堆疊情況下,在裝置上應用防攻擊策略。 <HUAWEI>system-view n堆疊情況下: -在主裝置上應用防攻擊策略 <HUAWEI>system-view -在所有堆疊裝置上應用防攻擊策略 <HUAWEI>system-view c.檢視攻擊源資訊。 配置基於攻擊溯源的本機防攻擊功能後,可以執行display auto-defend attack-source和display auto-defend attack-source slotslot-id命令,檢視攻擊源資訊。 識別的攻擊源MAC中可能包含閘道器的MAC地址,需要注意剔除。 3.根據檢視到的攻擊源資訊,結合現網情況,選擇處理方法。 −配置ARP安全功能,防範ARP協議攻擊。 針對ARP和ARP-Miss協議報文攻擊,可以部署ARP安全功能,來防止裝置後續遭受這類攻擊。 裝置提供了多種ARP安全的解決方案,請參考產品文件的“配置指南-安全配置-ARP安全配置”的“ARP安全解決方案”進行配置。 −配置攻擊溯源的懲罰功能,在指定週期內丟棄識別為攻擊的報文。 #使能攻擊溯源的懲罰功能,在300秒內,將識別為攻擊的報文全部丟棄。 <HUAWEI>system-view −配置本機防攻擊策略的黑名單,直接丟棄黑名單使用者上送的報文。 如果判斷攻擊源為特定使用者的惡意報文(假設攻擊源為1.1.1.0/24)攻擊,可以通過ACL把符合特定特徵的使用者納入到黑名單中,被納入黑名單的使用者所發的報文到達裝置後均會被丟棄。 #配置ACL 2001匹配源1.1.1.0/24的報文,命中該ACL的特徵報文將被裝置直接丟棄。 [HUAWEI]acl number 2001 −配置攻擊溯源的懲罰功能,將攻擊報文進入的介面shutdown,避免攻擊源繼續攻擊裝置。 如果判斷攻擊報文來自某埠,並且將該埠shutdown,不會對裝置業務造成影響,可以使用該方法。 如果配置攻擊溯源的懲罰措施是將攻擊報文進入的介面shutdown,有可能會造成裝置業務的中斷,介面下合法的使用者會受牽連,請謹慎使用。 #配置攻擊溯源的懲罰措施為將攻擊報文進入的埠shutdown。 <HUAWEI>system-view 找到攻擊源並採取相應措施後,觀察丟包現象是否緩解,如果仍未緩解,請參考下一節。 2.8檢查上送CPU的報文速率是否超出裝置限速 裝置針對每類協議報文都有預設的CPCAR值,一般情況下,裝置上協議報文的CPCAR值採用預設值就可以滿足應用。部分協議報文的CPCAR值需要根據實際業務規模和具體的使用者網路環境進行調整。 1.通過display cpu-defend statistics all命令檢視上送CPU報文的統計資訊,確認對應的業務是否丟包。 2.通過display cpu-defend configuration[packet-typepacket-type] {all|slotslot-id|mcu}命令檢視裝置對上送CPU的報文限速值。 3.通過display cpu-defend rate[packet-typepacket-type] {all|mcu|slotslot-id}命令檢視上送CPU的報文速率。 4.結合現網規模確認當前CPCAR設定值是否匹配。 例如,某網路中有丟包現象,確認當前CPCAR設定值是否與現網規模匹配。 #確認上送CPU的ICMP報文有丟包。 <HUAWEI>display cpu-defend statistics all 表示裝置主控板總共丟棄了44380928個ICMP報文。 #檢視裝置對上送CPU的ICMP報文限速值。 <HUAWEI>display cpu-defend configuration packet-type icmp all 表示裝置主控板每秒允許上送CPU的ICMP報文為256kbit/s=256*1024bit/s=262144bit/s。 #檢視上送CPU的ICMP報文速率。 <HUAWEI>display cpu-defend rate packet-type icmp all 表示裝置主控板每秒通過的上送CPU的ICMP報文為239211bit數,已接近裝置主控板允許的數值262144,同時還有大量丟包。這表明當前CPCAR設定值與現網規模可能不太匹配。 5.如果判斷CPCAR設定值與現網規模可能不匹配,由於調整CPCAR不當將會影響網路業務,請聯絡技術支援工程師調整CPCAR。 2.9檢查相關配置是否合理 1.檢視介面、VLAN、VLANIF以及全域性的配置,檢查是否配置了與丟包相關的配置。 配置檢查項: −是否有相關的流量過濾、抑制或限速,以及是否正確運用了流策略。例如流策略誤配置了對某類報文采取丟棄。 n流策略檢查:主要檢查是否正確應用了流策略,流策略中定義的流行為動作和流分類中匹配的規則是否有導致報文被丟棄的配置。 #執行命令display traffic policy user-defined檢視配置的流策略資訊。 <HUAWEI>display traffic policy user-defined #執行命令display traffic behavior user-defined[behavior-name]檢視配置的流行為資訊,是否有導致報文被丟棄的配置。 <HUAWEI>display traffic behavior user-defined #執行命令display traffic classifier user-defined[classifier-name]檢視配置的流分類資訊。 <HUAWEI>display traffic classifier user-defined #執行命令display acl{acl-number|all}檢視流分類中匹配的ACL是否包含deny內容。 <HUAWEI>display acl all 如果配置不正確,請修改配置。 n流量抑制檢查,請在明確有廣播報文攻擊或有抑制廣播報文需求的時候使用該命令。 broadcast-suppression:配置介面下允許通過的最大廣播報文流量。當廣播流量超過配置閾值時會自動丟棄,並且該丟棄沒有日誌資訊。 2.是否存在安全相關的配置,如埠安全、IPSG、URPF等。 port-security enable:使能埠安全功能後,介面會將學習到的MAC地址轉換為安全動態MAC地址。當介面學習的安全動態MAC數量達到上限後(預設值為1),不再學習新的MAC地址,對超過MAC地址學習數量限制的報文采取直接丟棄的動作。 ip source check user-bind enable:使能IP報文檢查功能,對IP報文中的IP、MAC、VLAN、介面資訊進行繫結表匹配檢查。 urpf strict:使能介面的URPF嚴格檢查功能,從子介面進入的報文無法通過嚴格檢查而被直接丟棄檢查功能。 3.如果交換機做二層轉發,還要同時檢查以下內容。 a.檢查介面的VLAN配置是否正確。 n介面沒有加入相應的VLAN,導致介面不允許報文通過。 執行display vlanvlan-id命令,檢視介面是否以Untagged或Tagged方式加入到指定的VLAN中。如果介面配置了PVID,對於Untagged的報文在入介面會被打上PVID tag,此時需要將介面加入PVID VLAN。 <HUAWEI>display vlan 10 n入埠和出埠是否配置在相同的業務轉發VLAN。 n介面下配置了丟棄入方向帶VLAN Tag的報文。 port discard tagged-packet:配置該命令的介面將丟棄入方向帶VLAN Tag的報文。如果因配置錯誤導致丟包,請通過命令undo port discard tagged-packet修改配置。 n介面下配置了丟棄沒有匹配靈活QinQ和VLAN Mapping的報文。 qinq vlan-translation miss-drop:靈活QinQ和VLAN Mapping介面下配置該命令後,介面會對沒有匹配疊加前或對映前的VLAN的入報文進行丟棄。如果因配置錯誤導致丟包,請通過undo qinq vlan-translation miss-drop命令修改配置。 對於配置靈活QinQ的介面,注意要將介面加入替換後的VLAN。 b.檢查源MAC地址學習是否正常。 執行display mac-addressmac-address命令,檢查源MAC地址和VLAN、介面的繫結關係是否正確。 <HUAWEI>display mac-address 如果源MAC沒有學習到,請重新配置MAC地址、VLAN和裝置埠的繫結關係。 對於配置了靈活QinQ的介面,源MAC是學習在替換後的外層VLAN上的。 c.檢查MAC地址配置中是否有導致丟包的配置項。 n是否關閉了MAC地址學習,並指定了丟棄動作。 在介面檢視或VLAN檢視下檢視配置,顯示資訊有“mac-address learning disable action discard”,裝置將不再從介面進行MAC地址學習,如果MAC地址表中有匹配表項,則按照MAC表進行轉發;如果無匹配表項,則丟棄該報文。 n是否配置了MAC地址學習限制規則。 在介面檢視或VLAN檢視下檢視配置,顯示資訊有“mac-limit maximummax-num”,MAC地址表項數目達到限制後,源MAC為新MAC地址的報文會被丟棄。 n是否配置了靜態MAC。 執行display mac-address static命令檢視靜態MAC地址表項資訊。 如果配置了靜態MAC,只有綁定了靜態MAC的接口才會處理該MAC的報文,其他介面收到該MAC的報文會被丟棄。 n是否配置了黑洞MAC。 執行display mac-address blackhole命令檢視黑洞MAC地址表項資訊。 如果配置了黑洞MAC,當某個報文的源MAC地址或目的MAC地址等於黑洞MAC地址表項的MAC地址,該報文會被丟棄。 4.如果交換機做三層轉發,還要同時檢查以下內容。 a.檢查ARP表項是否存在、是否衝突、是否超規格。 n執行命令display arp all,檢查本端是否學習到對端IP地址的ARP表項。 n執行命令display arp learning strict,檢視全域性和VLANIF介面是否配置了ARP表項嚴格學習。 <HUAWEI>display arp learning strict 配置該功能後,只有本裝置主動傳送的ARP請求報文的應答報文才能觸發本裝置學習ARP,其他裝置主動向本裝置傳送的ARP報文不能觸發本裝置學習ARP。 n執行命令display logbuffer命令,檢視裝置上的日誌資訊。當顯示有如下資訊時,表明裝置從介面接收到IP地址衝突的ARP報文。 ARP/4/ARP_DUPLICATE_IPADDR:Received an ARP packet with a duplicate IP address from the interface. (IpAddress=[IPADDR], InterfaceName=[STRING], MacAddress=[STRING]) 處理方法如下: 系統檢視下執行命令arp anti-attack gateway-duplicate enable,使能ARP防閘道器衝突攻擊功能。裝置在收到地址衝突的報文後,會下發防攻擊表項過濾攻擊源,在後續一段時間內對收到具有相同源MAC地址的報文直接丟棄(該功能會導致攻擊源一段時間不能訪問網路)。 如果使用者允許,也可以直接配置本機防攻擊策略的黑名單來過濾該報文,更嚴厲的懲罰措施可以配置黑洞MAC,徹底不讓該攻擊者上網。 配置請參見2.7檢查是否存在攻擊。 b.檢查是否有到對端的路由 執行命令display ip routing-table和display fib,沿轉發路徑逐跳檢視路由,檢查本端是否有可達對端的路由,對端是否有回程路由,路由協議是否配置正常。 執行命令display ip routing-table statistics,檢視路由總數是否超過裝置規格導致的硬體表項下發失敗。 c.如果是三層子介面,檢查子介面下是否使能了終結子介面的ARP廣播功能arp broadcast enable。終結子介面將不能轉發廣播報文,在收到廣播報文後它們直接把該報文丟棄。 5.檢視介面是否被STP、RRPP、LDT、SmartLink等協議阻塞。 一般在同一介面上不會配置多種環路協議,所以先看介面目前配置了哪種協議型別,再檢視對應的介面狀態。這裡以STP、RRPP為例說明。 −若交換機上配置了STP協議,需檢查介面是否被STP阻塞。 執行命令display stp brief檢視介面狀態,正常情況下介面的“STP State”欄位為“FORWARDING”。 <HUAWEI>display stp brief 若該欄位為DISCARDING,則說明該介面上報文被STP阻塞。需要在系統檢視下執行stp prioritypriority-level命令修改STP的優先順序,將本交換機選舉為根橋,使介面不被阻塞。(priority-level的取值是0~61440,取值越小則優先順序越高,設定較低的優先順序可使本交換機成為環路的根橋。) −若交換機上配置了RRPP協議,需檢查介面是否被RRPP阻塞。 執行命令display rrpp verbose domaindomain-index檢視介面狀態,正常情況下介面的“Port status”欄位都為“Up”。 <HUAWEI>display rrpp verbose domain 1 若介面顯示狀態為為“BLOCK”,則說明該介面上報文被RRPP阻塞。RRPP協議阻塞的是副介面(Secondary port),所以需要重新規劃修改配置,不要將該介面配置成RRPP協議的副介面。 2.10通過流量統計判斷丟包位置 1.沿著發生丟包的鏈路,在裝置的入介面和出介面上部署流策略,分別統計入介面的Inbound方向和出介面的Outbound方向的特定報文,以確認該類報文是否在本裝置被丟棄。 在本例中,如圖2-1所示,在Switch_3、Switch_2和Switch_1上同時配置流策略功能,檢視埠a~埠f在同一走向的流量統計情況。 圖2-1部署流策略示例 配置流量統計 #配置進入Switch_3(埠a入方向)報文的流量統計。 a.配置ACL規則。 <Switch_3>system-view b.配置流分類。 [Switch_3]traffic classifier 3000 c.配置流行為。 [Switch_3]traffic behavior 3000 d.配置流策略。 [Switch_3]traffic policy 3000 e.在介面上應用流策略。 [Switch_3]interface gigabitethernet 1/0/2 #配置離開Switch_3(埠b出方向)報文的流量統計。 a.配置ACL規則。 [Switch_3]acl number 3001 b.配置流分類。 [Switch_3]traffic classifier 3001 c.配置流行為。 [Switch_3]traffic behavior 3001 d.配置流策略。 [Switch_3]traffic policy 3001 e.在介面上應用流策略。 [Switch_3]interface gigabitethernet 1/0/2 在Switch_2和Switch_1上做類似Switch_3的流量統計,配置步驟不再詳述。有關流量統計的概念和配置請參考4.1配置流量統計。 分析統計結果 a.在裝置上執行命令display traffic policy statistics interfaceinterface-type interface-numberinbound/outbound verbose rule-base檢視介面流量統計資訊。 b.分別比較埠a入方向和埠b出方向,埠b出方向和埠c入方向,埠c入方向和埠d出方向,埠d出方向和埠e入方向,埠e入方向和埠f出方向的報文Passed計數,判斷丟包位置。 以埠a入方向和埠b出方向,埠b出方向和埠c入方向的流量統計情況為例。 n如果埠a入方向和埠b出方向Passed計數大致相等,說明此處無丟包。 n如果埠a入方向的報文Passed計數多於埠b出方向的報文Passed計數,說明丟包發生在Switch_3。 請參考2.10.1載入裝置版本對應最新補丁和2.10.2嘗試復位或更換單板進行定位處理。 n如果埠b出方向和埠c入方向Passed計數大致相等,說明此處無丟包。 n如果埠b出方向的報文Passed計數多於埠c入方向的報文Passed計數,說明丟包發生在Switch_3和Switch_2之間的物理鏈路上,請參考2.10.3檢查裝置之間的物理鏈路進行定位處理。 2.10.1載入裝置版本對應最新補丁 請載入並激活版本對應最新的補丁檔案,檢視問題是否有所緩解。 請登入http://support.huawei.com/enterprise/網站獲取補丁的軟體和安裝補丁需要參考的文件(包括補丁說明書和補丁安裝指導書)。 2.10.2嘗試復位或更換單板 確認在對業務沒有影響的狀況下,請嘗試復位或拔插單板恢復業務,觀察丟包現象是否有所緩解。同時聯絡技術工程師更換單板解決。 2.10.3檢查裝置之間的物理鏈路 本文給出的例子中,通過檢視SwitchA和SwitchB上的流量統計資訊,可以發現進入SwitchB的報文數目少於離開SwitchA的報文數目,進入SwitchA的報文數目少於離開SwitchB的報文數目,因此可以判斷是A與B之間物理鏈路上發生丟包。 常見物理鏈路故障有以下幾種: l線纜接頭接觸不良或鬆脫。 l光模組波長引數與實際需求不一致。 l裝置的通訊介面損壞。 l物理連線過長或出現破損。 針對物理鏈路故障,具體排查方法如下: 1.檢視裝置埠指示燈狀態。 如果是常灰,說明無連線。此時需要更換介面或者網線再進行嘗試。 2.檢查裝置連線的線纜以及裝置上的硬體模組等是否插好,不可鬆動。 檢查連線完好之後,如果故障仍然存在,請執行下一步。 3.檢查裝置之間的鏈路、介面模組是否故障。 −如果裝置之間通過雙絞線連線,需要根據表2-3做如下檢查。 表2-3裝置之間通過雙絞線時的檢查項 檢查標準 後續操作 用測試儀測試雙絞線是否故障。 測試儀顯示雙絞線正常。 如果檢查出線纜故障,請更換線纜。 裝置間雙絞線長度是否滿足要求。 裝置間線纜長度<100m。 說明 10/100/1000M電介面採用RJ-45聯結器,介面線纜為5類或5類以上雙絞線,傳輸距離100m。 如果線纜長度大於100m, l縮短裝置之間的距離,以縮短雙絞線長度。 l如果不能改變裝置之間的距離,可以通過中繼或交換機串聯等方式連線裝置。 檢查雙絞線線序型別是否正確。 直通網線用來連線以下裝置之間的乙太網介面: l路由器和集線器 l路由器和交換機 lPC和交換機 lPC和集線器 交叉網線用來連線以下裝置之間的乙太網介面: l路由器和路由器 l路由器和計算機 l集線器和集線器 l集線器和交換機 l交換機和交換機 lPC和PC 如果雙絞線型別選擇錯誤,請選擇正確型別的雙絞線。 檢查兩邊的電口模組是否正常。 1.檢查網口裡面是否有金針凹陷或偏位。 2.看是否存在接觸不好及網線外部損壞的情況。 如果電口模組不正常,請更換兩端電口模組。 l如果裝置之間通過光纖連線,需要根據表2-4做如下檢查。 表2-4裝置之間通過光纖連線時的檢查項 檢查標準 後續操作 檢查光模組和光纖的對應關係。 檢查光纖型別是否正確。 如果對應關係不正確,請選擇更換光模組或光纖。 裝置間光纖的長度和光模組支援的傳輸距離是否匹配。 光纖的長度小於光模組支援的傳輸距離。 根據現網實際情況縮短光纖長度或者更換支援更大傳輸距離的光模組。 用測試儀測試訊號的衰減在允許的範圍內。 光訊號的衰減範圍與光模組型號有關。 1.如果衰減過大請更換光纖。 2.如果更換光纖仍不符合衰減要求,請縮短光纖的長度。 用測試儀或物理環回方法檢查鏈路兩端是否故障。 l使用測試儀測試時,測試儀顯示收發正常。 l使用物理環回時,可以看到介面Up。 1.如果檢查出線纜故障,請嘗試更換線纜。 2.如果更換線纜故障依然存在請嘗試更換兩端介面光模組。 請根據已知型號或光模組的型別,參考產品文件-硬體描述的“介面可插拔模組”章節,來獲取光模組的中心波長、傳輸距離、支援的光纖型別、接收光功率、傳送光功率等資訊。 另外,光功率不正常會觸發裝置告警,也可以通過告警資訊檢視光功率是否正常。 2.11聯絡技術支援工程師 如果執行上述措施後仍然無法解決問題,請收集組網資訊(包括埠連線情況)、故障的源IP,源MAC,目的IP,目的MAC,入埠,出埠和日誌資訊(log.log日誌檔案或者執行命令display logbuffer的輸出資訊),聯絡技術支援工程師。 3後續預防網路丟包措施 根據前面的問題定位章節,我們可以得知引起部署S交換機的網路丟包的原因,建議在網路的部署和維護過程當中,請參考表3-1採取一些預防措施,儘量減少丟包現象發生的可能。 表3-1避免網路丟包措施 後續預防措施 對端裝置或下掛PC引起 定期給裝置下接的PC或伺服器防毒,減少攻擊。 硬體故障(如物理線路故障、單板未插緊或單板故障需要更換以及介面狀態異常等。) l檢查裝置上物理連線、單板等硬體模組是否插緊。 l裝置電口使用的網線必須為標準電纜,非標準的網線可能會引起鏈路問題。 l裝置電口必須為全雙工狀態,半雙工狀態會帶來很多問題。 l使用的光模組必須為華為交換機產品認證的光模組。 很多廠家光模組實現方法不統一,產生的問題也不可控,比如現網出現過很多使用非認證光模組導致出現丟包的問題,因此使用的光模組必須為華為交換機產品認證的光模組。 流量突發超出介面頻寬,導致網路擁塞 l對伺服器進行發包優化,減少流量突發。 l用Eth-Trunk增加成員埠做負載分擔,減小單個埠流量。 配置不當 / 網路環路 合理規劃網路,預先配置破環協議,同時使能環回檢測功能,避免網路成環。 l全域性檢視下配置loopback-detect untagged mac-address ffff-ffff-ffff,保證裝置環路探測報文BPDU報文為廣播報文,不會被其他裝置終結。 l介面檢視下配置loopback-detect enable,使能環回檢測功能。 當裝置所有使能環回檢測功能的介面下的VLAN個數總和超過1024時,建議通過命令loopback-detect action shutdown配置介面檢測到環路時的處理動作為shutdown。(對於每個埠,每加入到一個VLAN,VLAN個數就加1,即使是多個埠同時加入同一個VLAN。) 攻擊 l配置ARP安全功能,防止裝置受到ARP和ARP-Miss協議報文攻擊。 l在經常出現DHCP、ARP協議報文攻擊的網路(如校園網),配置基於DHCP、ARP協議報文的本機防攻擊策略。 上送CPU的報文速率超出CPU限速 裝置針對每類協議報文都有預設的CPCAR值,一般情況下,預設的CPCAR值即可滿足需要。如果存在正常業務的流量過大的問題,請聯絡華為交換機經銷商根據實際業務規模和具體的使用者網路環境進行調整。 產品規格限制或組網規劃不當 在跨板轉發流量較大的場景下,裝置款型建議儘量選擇S9700等款型,主控單元儘量選擇SRUB/SRUD兩種主控板,以確保更大的板間通訊頻寬。 4附錄 4.1配置流量統計 概述 如圖4-1所示,S系列交換機支援介面入方向、出方向的流量統計,基於全域性入方向、出方向的流量統計。流量統計使用流策略功能實現,在介面檢視下應用時,只統計介面的入方向或出方向流量;在全域性應用時,能夠統計所有介面的入方向與出方向的流量。 介面檢視下的流策略優先順序高於全域性檢視下的流策略,當介面下的流量統計優先命中時,全域性檢視則無法命中,即沒有統計值。 圖4-1流量統計介紹示意圖 基於流量統計,可以分析如下問題: 1.流量是否到達裝置入口,進而判斷上游裝置是否丟包; 2.流量是否被轉發到裝置出口,進而判斷裝置是否丟包; 3.流量在裝置入口二三層資訊是否正確,進而判斷上游裝置轉發封裝是否正常; 4.流量在裝置出介面二三層資訊是否正確,進而判斷裝置轉發封裝是否正常; 5.是否存在MAC漂移、路由變化、IP衝突等導致的流量瞬間漂移。 配置步驟 配置ACL規則,匹配需要統計的流量。 配置流分類,根據ACL規則匹配不同的流量,從而區分不同資料流量。 配置流行為,在流行為中配置流量統計。 配置流策略,繫結以上流分類和流行為,並應用在Switch的入方向,實現對不同使用者報文的流量統計。 <HUAWEI> system-view #查詢流量整體的統計值: <Quidway>display traffic policy statistics interface GigabitEthernet 1/0/1 inbound #查詢基於每條rule的統計值: <Quidway>display traffic policy statistics interface GigabitEthernet 1/0/1 inbound verbose rule-base 對流量做完統計,請及時刪除流量統計相關配置,減輕CPU壓力。 S3700不支援出方向流量統計功能,可以使用下面方法快速排除是否存在丟包 l可以考慮在對端入方向做流量統計,將對端裝置入方向的流量統計和S3700裝置入方向的流量統計比較,確認是否丟在S3700上。 l可以在埠入方向配置重定向,將報文直接重定向到出埠,如果丟包的話說明與S3700無關,如果不丟包說明丟在S3700上。 |