利用LFS机制排除10GE/100GE以太网链路故障

刘亚峰

中国电信股份有限公司江苏分公司

0 引言

SDH/OTN这样的光传输网络，由于有着丰富的OAM开销字节，网络监测和管理功能强大，一旦出现网络或设备故障，能够快速地定位障碍，网络自愈能力强。而由交换机、路由器组成的数据网络则不一样，它更倾向于简单易用，没有引入复杂的监测和管理机制，尤其是FE、GE这样的以太网链路，在IEEE 802.3ah（EFM）/ITU-T Y.1731（CFM）技术规范出来之前，是不具备OAM功能的，缺乏链路层障碍的定位和分析手段。

近年来高速率大带宽业务呈爆发性增长势头，三大运营商从汇聚层往上都已经使用10G乃至100G链路，而城域核心以及骨干层链路则基本以100G为主了。这就带来了一个问题，如此大的带宽，一旦发生链路层故障，势必造成流量的局部拥塞，导致网络的不稳定。因此如何快速定位10G以上高速链路的链路层障碍并尽快恢复网络流量至关重要。

为此，在IEEE 802.3ae（10GE）技术规范中引入了链路故障检测机制（Link Fault Signaling，LFS），并在100GE（IEEE 802.3ba）中继续沿用了该LFS机制来诊断物理层链路故障。

1 10GE/100GE以太网链路的LFS故障检测机制

在IEEE 802.3ae（10GE）技术规范中，10G以太网根据其PHY（物理层）的不同，分为WAN和LAN两种模式，其中10GE WAN模式是通过WIS子层把以太网帧封装到SDH帧结构中，并在简化SDH开销的基础上，实现和SDH的兼容，因此，可以使用SDH OAM机制来对10GE WAN链路进行端到端的监控管理以及故障分析定位。10GE LAN模式由于缺少WIS子层，无法提供额外的开销字节来实现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层禁止发送以太网帧（接口置Down），并通过MII接口连续发送Remote_Fault（类似10GE Down），并通过MII接口连续发送Remote_Fault（类似10GE WAN链路中的RDI告警）给对端设备接口，对端接口的RS层检测到Remote_Fault，也会禁止发送以太网帧（接口置Down），如图1所示。

图1 数据设备接口LFS机制示意图

对于传输设备而言，Local_Fault和Remote_Fault告警如果是传输系统外部产生的，传输系统将采用只检测不终结的透传（pass through）模式。其中，Local_Fault对于传输系统而言，属于客户信号失效（Client Signal Fail，CSF）一类告警，而Remote_Fault和SDH中的RDI以及OTN中的BDI类似，属于故障对告信息。传输系统对这两类告警处理也略有不同，在传输系统中，承载的所有业务都是以端到端的链呈现的，两端传输设备的客户侧接口负责编码/解码以及复用/解复用客户信号，一旦一端的客户侧接口检测到Local_Fault告警，则会在该以太网链路的另一端传输设备客户侧接口上上报一个远端客户信号失效告警，用以提示该告警是远端传输设备接入客户信号问题，而不是在传输系统内部产生的，同时往下游方向透传Local_Fault告警。不同的传输设备厂商定义的此项告警略有不同，例如华为设备是REM_SF，中兴设备是OPU_CSF。如果传输客户侧接口检测到的是Remote_Fault，则传输系统将只是简单地透传。具体如图2所示。

图2 Local_Fault和Remote_Fault在传输系统透传示意图

如果传输设备客户侧监测到的是接入客户信号丢失R_LOS告警，那么该传输链路的另一端设备将会往下游方向下插Local_Fault告警，同时上报远端客户信号失效告警（REM_SF/OPU_CSF），现象与检测客户侧有Local_Fault是一样的。

如果是传输系统发生故障，导致上面承载的以太网链路中断，传输设备将会往链路下游方向下插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 排障原则一：专业融合排障

如前所述，10GE/100GE链路大都用于汇聚层及以上，除非数据设备位于同机房或同局站，否则基本上都是利用光传输网络（WDM/OTN）来承载。LFS用于检测以太网物理链路层故障，这其中也包含了承载该链路的传输故障，因此利用LFS机制排障10GE/100GE链路，同时涉及到了数据和传输两个网络。

在平时的网络维护中，传输和数据网络的维护界面通常是彼此独立的，而网络维护人员遵循的障碍处理原则是“先局内后局外、先网内后网外”，这意味着传输和数据两个专业在处理同一条10GE/100GE以太网链路故障时，都按照自己专业的网络维护界面各自定义了“局内局外”和“网内网外”，而没有考虑到对接的传输设备和数据设备往往处于同一个局站甚至同一个机房，面对的也是同一条以太网链路障碍，这样不仅造成了人员浪费，而且也导致障碍历时过长。因此，在处理10GE/100GE这种由传输承载的物理链路障碍时，传输和数据两个专业融合排障是十分必要的。

在后面的排障处理流程图中，只区分设备（远端或近端、数据或传输），而没有区分专业。

2.2 排障原则二：能远程不现场

随着运营商大力推行网络扁平化和集约化，机房无人值守已经成为一种趋势，因此，“能远程不现场”也成了网维人员排障的一条重要准则。对于传输网络来说，通过专业EMS/NMS网管进行远程障碍分析定位已经是维护人员必备的手段和技能，现场人员不需太多的专业技能，要做的只是根据网管人员的指示执行更换板卡和测试跳接尾纤工作。而对于数据网络来说，由于缺乏专业网管，远程维护人员一般使用Telnet/SSH远程登录设备，而现场维护人员则通常使用串口线直连设备，通过人机交互CLI命令分析排障，远程和现场的概念没有传输专业那么明确和清晰，都需要较高的专业技能。这些年随着集约化工作的推进，数据网络的IT支撑手段也越来越完备，通过SSH和第三方支撑系统远程管理网络和设备也已经成为了常态，现场维护量不断减少，对现场维护人员的技能要求也在不断降低，“远程定位分析，现场配合排障”正成为两个专业网维人员障碍处理的共识。

综上所述，10GE/100GE高速以太网链路故障在排障时，应遵循“能远程不现场”的原则。首先使用远程手段，利用传输设备专业网管和数据设备远程管理手段来分析定位障碍；接着以局站为单位来区分“局内局外”，如果是局内障碍，再根据“网内网外”进一步区分专业设备。

这对远程维护人员的技能要求较高，需要同时兼备传输和数据两个专业的相关知识和维护技能，不仅应熟悉DWDM/OTN设备网管以及相关告警处理流程，还应熟悉交换机/路由器数据链路层障碍及处理流程。但对现场维护人员，没有特别的专业技能要求，只需能配合远程维护人员完成光功率测试、尾纤环回、机盘更换等基本操作即可。这也正是网络扁平化、集约化维护的要求。

在后面的排障处理流程图中，清晰地将远程处理部分和现场处理部分隔开了，大量的障碍分析判断工作都通过远程完成，现场只做简单的配合工作。

3 10GE/100GE以 太 网 链 路LFS排 障流程

3.1 10GE/100GE以太网链路障碍现象

对于数据设备而言，LFS是其检测10GE/100GE LAN链路单纤障碍的一种接口检测机制，如果接口没有启用LFS检测功能，那么只要接口收光功率在正常范围内，接口物理层就处于Up状态，一旦接口配置了IP地址，此时如果物理链路没有任何问题，那么线路协议也就随之Up，如果有链路层障碍，线路协议状态则为Down。如果接口启用了LFS功能，那么只有在接口没有检测到Local_Fault和Remote_Fault信息时，接口物理层才会Up，也就是说，接口状态Up也就意味着接口的物理链路层状态正常，这时接口只要配上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信息）。硬件原因比较简单，通过查询接口收发光功率就能判断（数据设备使用CLI接口命令，传输设备则通过专业网管）。如果是软件原因，还需要进一步区分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开销字节，对于其上承载的业务链路都可以按需实施端到端的监测和管理，因此在障碍处理时，可以很容易地定位该障碍是局内（本端）还是局外（对端），是网内（传输）还是网外（数据），并根据障碍定位来分析具体的故障原因。传输设备10GE/100GE接口故障处理流程如图7和图8所示。

图7 传输设备接口有Local_Fault告警处理流程

图8 传输设备接口有Remote_Fault告警处理流程

由于本文关注的是LFS机制下的以太网链路故障处理流程，而传输网络排障与传输设备收LOS告警处理和LFS机制无关，就是通常意义上的传输专业排障，可以参考传输设备厂家的排障手册，这里不作赘述。

4 结束语

在10GE/100GE以上高速以太网链路中启用LFS检测机制，可以帮助维护人员快速判断定位链路层障碍，文中也提供了具体的障碍处理流程图，这也是作者在日常的网络维护中经过反复实践，确认行之有效的数据链路层排障方法，希望能够对网维人员在处理10GE/100GE以太网链路故障时有所帮助。

此外，上述告警处理流程中的远程处理部分，基本都是信息检索和判断，这部分工作可以考虑通过IT手段完成，将其编码为程序模块，实现自动化处理。而现场处理部分，除了疑难障碍需要设备厂家介入外，其余的都是更换机盘和尾纤这类的简单操作，可以嵌入到运营商电子运维系统的派单流程中，由现场的综合维护人员进行处理。这样整个链路层障碍处理流程几乎无需技术人员干预，不仅极大地提升了障碍处理效率，而且也降低了对网络维护人员的技能要求。