利用LFS機制排除10GE/100GE以太網鏈路故障

劉亞峰

中國電信股份有限公司江蘇分公司

0 引言

SDH/OTN這樣的光傳輸網絡，由于有著豐富的OAM開銷字節(jié)，網絡監(jiān)測和管理功能強大，一旦出現網絡或設備故障，能夠快速地定位障礙，網絡自愈能力強。而由交換機、路由器組成的數據網絡則不一樣，它更傾向于簡單易用，沒有引入復雜的監(jiān)測和管理機制，尤其是FE、GE這樣的以太網鏈路，在IEEE 802.3ah（EFM）/ITU-T Y.1731（CFM）技術規(guī)范出來之前，是不具備OAM功能的，缺乏鏈路層障礙的定位和分析手段。

近年來高速率大帶寬業(yè)務呈爆發(fā)性增長勢頭，三大運營商從匯聚層往上都已經使用10G乃至100G鏈路，而城域核心以及骨干層鏈路則基本以100G為主了。這就帶來了一個問題，如此大的帶寬，一旦發(fā)生鏈路層故障，勢必造成流量的局部擁塞，導致網絡的不穩(wěn)定。因此如何快速定位10G以上高速鏈路的鏈路層障礙并盡快恢復網絡流量至關重要。

為此，在IEEE 802.3ae（10GE）技術規(guī)范中引入了鏈路故障檢測機制（Link Fault Signaling，LFS），并在100GE（IEEE 802.3ba）中繼續(xù)沿用了該LFS機制來診斷物理層鏈路故障。

1 10GE/100GE以太網鏈路的LFS故障檢測機制

在IEEE 802.3ae（10GE）技術規(guī)范中，10G以太網根據其PHY（物理層）的不同，分為WAN和LAN兩種模式，其中10GE WAN模式是通過WIS子層把以太網幀封裝到SDH幀結構中，并在簡化SDH開銷的基礎上，實現和SDH的兼容，因此，可以使用SDH OAM機制來對10GE WAN鏈路進行端到端的監(jiān)控管理以及故障分析定位。10GE LAN模式由于缺少WIS子層，無法提供額外的開銷字節(jié)來實現OAM功能，如果想要實現和10GE WAN一樣的鏈路故障管理功能，則必須使用上層協議（例如BFD）以及額外的OAM開銷，不過，IEEE 802.3ae還是為10GE LAN提供了功能有限的鏈路故障檢測和誤碼檢測（PCS BER）機制，雖然功能不及SDH OAM強大，但也不失為一種以太網鏈路排障的便捷手段。

根據IEEE 802.3ba（100GE）標準，100GE的PHY（物理層）和10GE LAN基本相同，只是MII接口速率從10Gbps提升為了100Gbps，并增加了一個FEC層，它也使用LFS作為鏈路故障檢測機制。

鏈路故障檢測機制主要用于檢測10G以上速率LAN鏈路的單纖故障。對于10G以上速率的高速以太網鏈路，除非都是局內設備互聯，否則很少使用裸纖直連，大都使用WDM設備或OTN設備承載。因此更確切地來說，LFS是用來檢測LAN鏈路的物理鏈路層故障（包括了承載該鏈路的傳輸系統故障）的。

LFS是10GE/100GE LAN接口功能，因此，數據設備的10GE/100GE接口和承載10GE/100GE LAN鏈路的傳輸設備接口都具備LFS功能，但處理機制略有不同。

對于數據設備而言，一旦設備接口的PHY層檢測到光纖中斷，會上報Local_Fault告警（類似10GE WAN鏈路中的LOS告警），同時RS層禁止發(fā)送以太網幀（接口置Down），并通過MII接口連續(xù)發(fā)送Remote_Fault（類似10GE Down），并通過MII接口連續(xù)發(fā)送Remote_Fault（類似10GE WAN鏈路中的RDI告警）給對端設備接口，對端接口的RS層檢測到Remote_Fault，也會禁止發(fā)送以太網幀（接口置Down），如圖1所示。

圖1 數據設備接口LFS機制示意圖

對于傳輸設備而言，Local_Fault和Remote_Fault告警如果是傳輸系統外部產生的，傳輸系統將采用只檢測不終結的透傳（pass through）模式。其中，Local_Fault對于傳輸系統而言，屬于客戶信號失效（Client Signal Fail，CSF）一類告警，而Remote_Fault和SDH中的RDI以及OTN中的BDI類似，屬于故障對告信息。傳輸系統對這兩類告警處理也略有不同，在傳輸系統中，承載的所有業(yè)務都是以端到端的鏈呈現的，兩端傳輸設備的客戶側接口負責編碼/解碼以及復用/解復用客戶信號，一旦一端的客戶側接口檢測到Local_Fault告警，則會在該以太網鏈路的另一端傳輸設備客戶側接口上上報一個遠端客戶信號失效告警，用以提示該告警是遠端傳輸設備接入客戶信號問題，而不是在傳輸系統內部產生的，同時往下游方向透傳Local_Fault告警。不同的傳輸設備廠商定義的此項告警略有不同，例如華為設備是REM_SF，中興設備是OPU_CSF。如果傳輸客戶側接口檢測到的是Remote_Fault，則傳輸系統將只是簡單地透傳。具體如圖2所示。

圖2 Local_Fault和Remote_Fault在傳輸系統透傳示意圖

如果傳輸設備客戶側監(jiān)測到的是接入客戶信號丟失R_LOS告警，那么該傳輸鏈路的另一端設備將會往下游方向下插Local_Fault告警，同時上報遠端客戶信號失效告警（REM_SF/OPU_CSF），現象與檢測客戶側有Local_Fault是一樣的。

如果是傳輸系統發(fā)生故障，導致上面承載的以太網鏈路中斷，傳輸設備將會往鏈路下游方向下插Local_Fault告警，下游對接的數據設備或另一個傳輸系統設備接口收到該Local_Fault告警后將會對告一個Remote_Fault告警給本端的傳輸設備。由于是傳輸系統故障，本端傳輸設備上將會有相應的系統側（線路側）服務信號失效（Server Signal Fail，SSF）告警，對于這個告警，不同的廠家也會有所不同，例如，華為通常是ODU的AIS/OCI/LCK告警和OTU的AIS/LOF/LOM告警，中興則是ODU_SSF和OTU_SSF告警。如圖3所示。

圖3 Local_Fault和Remote_Fault在傳輸系統的傳遞機制

2 10GE/100GE以太網鏈路排障原則

2.1 排障原則一：專業(yè)融合排障

如前所述，10GE/100GE鏈路大都用于匯聚層及以上，除非數據設備位于同機房或同局站，否則基本上都是利用光傳輸網絡（WDM/OTN）來承載。LFS用于檢測以太網物理鏈路層故障，這其中也包含了承載該鏈路的傳輸故障，因此利用LFS機制排障10GE/100GE鏈路，同時涉及到了數據和傳輸兩個網絡。

在平時的網絡維護中，傳輸和數據網絡的維護界面通常是彼此獨立的，而網絡維護人員遵循的障礙處理原則是“先局內后局外、先網內后網外”，這意味著傳輸和數據兩個專業(yè)在處理同一條10GE/100GE以太網鏈路故障時，都按照自己專業(yè)的網絡維護界面各自定義了“局內局外”和“網內網外”，而沒有考慮到對接的傳輸設備和數據設備往往處于同一個局站甚至同一個機房，面對的也是同一條以太網鏈路障礙，這樣不僅造成了人員浪費，而且也導致障礙歷時過長。因此，在處理10GE/100GE這種由傳輸承載的物理鏈路障礙時，傳輸和數據兩個專業(yè)融合排障是十分必要的。

在后面的排障處理流程圖中，只區(qū)分設備（遠端或近端、數據或傳輸），而沒有區(qū)分專業(yè)。

2.2 排障原則二：能遠程不現場

隨著運營商大力推行網絡扁平化和集約化，機房無人值守已經成為一種趨勢，因此，“能遠程不現場”也成了網維人員排障的一條重要準則。對于傳輸網絡來說，通過專業(yè)EMS/NMS網管進行遠程障礙分析定位已經是維護人員必備的手段和技能，現場人員不需太多的專業(yè)技能，要做的只是根據網管人員的指示執(zhí)行更換板卡和測試跳接尾纖工作。而對于數據網絡來說，由于缺乏專業(yè)網管，遠程維護人員一般使用Telnet/SSH遠程登錄設備，而現場維護人員則通常使用串口線直連設備，通過人機交互CLI命令分析排障，遠程和現場的概念沒有傳輸專業(yè)那么明確和清晰，都需要較高的專業(yè)技能。這些年隨著集約化工作的推進，數據網絡的IT支撐手段也越來越完備，通過SSH和第三方支撐系統遠程管理網絡和設備也已經成為了常態(tài)，現場維護量不斷減少，對現場維護人員的技能要求也在不斷降低，“遠程定位分析，現場配合排障”正成為兩個專業(yè)網維人員障礙處理的共識。

綜上所述，10GE/100GE高速以太網鏈路故障在排障時，應遵循“能遠程不現場”的原則。首先使用遠程手段，利用傳輸設備專業(yè)網管和數據設備遠程管理手段來分析定位障礙；接著以局站為單位來區(qū)分“局內局外”，如果是局內障礙，再根據“網內網外”進一步區(qū)分專業(yè)設備。

這對遠程維護人員的技能要求較高，需要同時兼?zhèn)鋫鬏敽蛿祿蓚€專業(yè)的相關知識和維護技能，不僅應熟悉DWDM/OTN設備網管以及相關告警處理流程，還應熟悉交換機/路由器數據鏈路層障礙及處理流程。但對現場維護人員，沒有特別的專業(yè)技能要求，只需能配合遠程維護人員完成光功率測試、尾纖環(huán)回、機盤更換等基本操作即可。這也正是網絡扁平化、集約化維護的要求。

在后面的排障處理流程圖中，清晰地將遠程處理部分和現場處理部分隔開了，大量的障礙分析判斷工作都通過遠程完成，現場只做簡單的配合工作。

3 10GE/100GE以 太 網 鏈 路LFS排 障流程

3.1 10GE/100GE以太網鏈路障礙現象

對于數據設備而言，LFS是其檢測10GE/100GE LAN鏈路單纖障礙的一種接口檢測機制，如果接口沒有啟用LFS檢測功能，那么只要接口收光功率在正常范圍內，接口物理層就處于Up狀態(tài)，一旦接口配置了IP地址，此時如果物理鏈路沒有任何問題，那么線路協議也就隨之Up，如果有鏈路層障礙，線路協議狀態(tài)則為Down。如果接口啟用了LFS功能，那么只有在接口沒有檢測到Local_Fault和Remote_Fault信息時，接口物理層才會Up，也就是說，接口狀態(tài)Up也就意味著接口的物理鏈路層狀態(tài)正常，這時接口只要配上IP地址，線路協議自然就Up了。如果出現接口Up而線路協議Down的情況的話，只有兩種情況，一種是鴛鴦纖，另一種則是數據設備接口對接問題，前者屬于數據和傳輸設備之間跳纖出錯，處理起來比較簡單，而后者則需要設備廠家技術支持介入解決。

數據設備一旦啟用了LFS功能，可以通過CLI命令查看接口告警或者系統Syslog信息來確認是否存在Local_Fault和Remote_Fault信息。

對于傳輸設備而言，其客戶側的10GE/100GE LAN接口默認都啟用了Local_Fault和Remote_Fault告警檢測和上報機制，可以通過EMS/NMS網管查看接口告警或支路盤告警來確認。

由此可見，在啟用了LFS功能后，數據設備和傳輸設備上10GE/100GE高速以太網鏈路障礙現象有所不同，數據設備障礙現象主要為10GE/100GE接口Down，此時需要進一步查看接口上是否存在Local_Fault或Remote_Fault信息，并根據不同的告警信息來分析排障。傳輸設備障礙則為10GE/100GE接口上報Local_Fault和Remote_Fault告警，同時還伴隨有客戶信號失效（CSF）或服務信號失效（SSF）告警，用以最終分析定位障礙。

3.2 數據設備10GE/100GE接口故障處理流程

對于啟用了LFS接口檢測機制的數據設備而言，接口只要檢測到Local_Fault和Remote_Fault信息，接口的RS層都會將接口置Down。因此，在處理數據設備接口Down障礙時，除了檢測接口收光是否正常之外，最關鍵的是需要確認接口

上是否檢測到了Local_Fault和Remote_Fault信息，并根據檢測到的是Local_Fault信息還是Remote_Fault信息來分別分析定位障礙原因。數據設備10GE/100GE接口故障處理流程如圖4所示。

圖4 數據設備接口Down處理流程

這里主要依靠遠程排障，數據設備物理接口Down原因無外乎兩種：硬件原因（光模塊故障和尾纖故障）和軟件原因（接口檢測到Local_Fault和Remote_Fault信息）。硬件原因比較簡單，通過查詢接口收發(fā)光功率就能判斷（數據設備使用CLI接口命令，傳輸設備則通過專業(yè)網管）。如果是軟件原因，還需要進一步區(qū)分Local_Fault和Remote_Fault信息，采用不同的故障處理流程，具體如圖5和圖6所示。

圖5 數據設備接口有Local_Fault告警處理流程

圖6 數據設備接口有Remote_Fault告警處理流程

從兩個故障處理流程圖中可以看到，由于10GE/100GE以太網數據鏈路是承載在傳輸DWDM/OTN網絡之上的，所以傳輸設備故障和傳輸網絡故障都有可能導致數據設備接口檢測到Local_Fault和Remote_Fault信息，因此需要進一步結合傳輸網管來同步分析判斷。

3.3 傳輸設備10GE/100GE接口故障處理流程

由于傳輸DWDM/OTN網絡有著豐富的OAM開銷字節(jié)，對于其上承載的業(yè)務鏈路都可以按需實施端到端的監(jiān)測和管理，因此在障礙處理時，可以很容易地定位該障礙是局內（本端）還是局外（對端），是網內（傳輸）還是網外（數據），并根據障礙定位來分析具體的故障原因。傳輸設備10GE/100GE接口故障處理流程如圖7和圖8所示。

圖7 傳輸設備接口有Local_Fault告警處理流程

圖8 傳輸設備接口有Remote_Fault告警處理流程

由于本文關注的是LFS機制下的以太網鏈路故障處理流程，而傳輸網絡排障與傳輸設備收LOS告警處理和LFS機制無關，就是通常意義上的傳輸專業(yè)排障，可以參考傳輸設備廠家的排障手冊，這里不作贅述。

4 結束語

在10GE/100GE以上高速以太網鏈路中啟用LFS檢測機制，可以幫助維護人員快速判斷定位鏈路層障礙，文中也提供了具體的障礙處理流程圖，這也是作者在日常的網絡維護中經過反復實踐，確認行之有效的數據鏈路層排障方法，希望能夠對網維人員在處理10GE/100GE以太網鏈路故障時有所幫助。

此外，上述告警處理流程中的遠程處理部分，基本都是信息檢索和判斷，這部分工作可以考慮通過IT手段完成，將其編碼為程序模塊，實現自動化處理。而現場處理部分，除了疑難障礙需要設備廠家介入外，其余的都是更換機盤和尾纖這類的簡單操作，可以嵌入到運營商電子運維系統的派單流程中，由現場的綜合維護人員進行處理。這樣整個鏈路層障礙處理流程幾乎無需技術人員干預，不僅極大地提升了障礙處理效率，而且也降低了對網絡維護人員的技能要求。