FTTH业务情景中数据链路层故障实例分析

王 凯彭 忠

1.内蒙古广播电视网络集团有限公司 内蒙古 呼和浩特市010010

2.内蒙古广播电视网络集团有限公司乌达分公司 内蒙古 乌海市016000

内蒙古广播电视网络集团有限公司（以下简称内蒙古广电网络）从2015年开始实施FTTH（Fiber To The Home光纤到户）试点工程至今，形成了一张覆盖全区盟市、旗县、乡苏木、村嘎查，规模上百万户的数据宽带网络。随着网络建设和用户规模的快速发展，日常故障种类和数量也不断增多，一些类型的故障避免不了处理起来较为棘手。本文着重从比较常见、但处理起来比较困难的数据链路层典型故障案例进行分析，并提出相应的建议。

1 概念介绍：数据链路层

说到数据链路层，首先需要了解OSI（Open System Interconnect开放系统互连参考模型）。OSI是ISO组织在1985年定义的网络互连模型，该标准定义了网络互连需要用到的七层模型框架，即由底层到高层依次分别为：物理层、数据链路层、网络层、传输层、会话层、表示层以及应用层。每一层采用协议描述的形式来实现相应层级的功能，不同层级采用不同的协议实现不同实体相同层级的信息表达，下一层级服务于上一层级。在数据宽带业务中，由于英特网的访问一般需要用到网络层以上的层级，所以数据链路层就成为必不可少的报文流层级。如图1所示。

数据链路层由MAC（介质访问控制子层）和LLC（逻辑链路控制子层）构成，接受物理层的服务并服务于网络层，通过控制MAC地址转发来实现不同实体在数据链路层的信息交互。

2 概念介绍：FTTH技术

图1 OSI七层模型

图2 PON网络结构图

利用光纤信号传递过程中的能量衰耗小、速率高、不易干扰、无源灵活性高等诸多优点，FTTH成为目前最为广泛的有线接入方式，而PON（Passive Optical Network无源光网络）则依靠低成本、高带宽、扩展性强、与现有以太网兼容、方便管理等优点成为FTTH有线宽带数据业务场景中的主流数据通道接入技术。PON按照网络分配层级分为：OLT（Optical Line Terminal光线路终端）、Splitter（分路器）、ONU/ONT（Optical Network Unit光网络单元/Optical Network Terminal光网络终端）三个部分。按照不同标准协议运营商一般采用EPON（Ethernet Passive Optical Network以太网无源光网络）或者GPON（Gigabit-Capable Passive Optical Network千兆无源光网络）的形式来实现FTTH接入。目前内蒙古广电网络主要采用EPON方式来实现从前端到用户家的光配线网接入。如图2所示。

正是因为PON设备以太网兼容这一特性，完成了以太网数据流从运营前端到用户终端的传输：PON系统将从上连设备接收到的下行方向以太网数据，封装为PON协议后，采用广播方式经由局端的OLT设备将IP数据、语音、视频等多种业务通过分配网络中的无源分光器分配到所有ONU终端，在ONU终端完成PON协议解封装后，将以太网数据送给用户；在上行方向，通过分配网中的无源分光器将来自各个ONU反向封装的信息采用TDMA方式耦合到同一根光纤，传送到位于局端OLT接收端口，再由OLT还原为以太网数据。

3 组网情况

上述网络中，网络设计思路是从用户侧发起的以太网数据流通过ONU、OLT、接入交换机、汇聚交换机形成的数据链路层通道将以太网数据流送给BRAS。BRAS将用户拨号请求通过网络层经由骨干路由器转发到鉴权中心通过鉴权认证后，BRAS设备充当网络层业务网关的角色完成DHCP动态地址分发以及向网络层侧路由器进行以太网数据流转发，直到互联网平台。网络结构示意图如图3所示。

4 故障现象

某地市反馈在所属中心机房的若干台FTTH前端设备中的一台设备覆盖用户中出现用户宽带故障，图3中虚线框内的部分是本次故障出现的示意范围，现象如下：

现象1：用户终端采用PPPOE拨号过程用时较长，而且多次拨号后依然无法鉴权通过。

现象2：用户终端采用PPPOE拨号过程用时较长，而且多次拨号后才能完成与后台鉴权系统的关系建立。

图3 网络结构示意图

现象3：显示用户终端拨号成功，在使用互联网过程中存在“掉线”，即上网中断，用户终端重新发起拨号请求，回到现象1或者现象2。

现象4：显示用户拨号成功，但无法使用互联网或者使用互联网过程中存在“卡顿”，上网体验感不好。

5 故障处理思路及步骤

在了解以上现象后，通过对网络结构的梳理，分析问题，下面列出本次故障处理采用的处理步骤：

步骤1：由下到上检查故障用户终端ONU、前端OLT设备以及本台OLT设备上联的接入交换机设备的接口光功率指标、设备运行日志，查看物理层链路的状态是否正常。

理由：故障现象只发生在单台OLT前端设备覆盖范围内，优先考虑物理层链路以及设备状态是否稳定有异常，在日常故障处理中物理层链路占比较大，须优先考虑链路情况。

结果：用户终端ONU、OLT前端设备、接入交换机光功率在正常阈值范围，OLT前端设备、接入交换机无异常行为报错，终端ONU断电重启以及替换测试后均故障复现，初步排除物理层链路异常以及设备运行异常的情况。

步骤2：根据故障用户终端的MAC地址，查看OLT前端设备、接入交换机、汇聚交换机的MAC地址表项中有无异常。

理由：故障现象着重发生在拨号过程中，PPPOE拨号报文的成功建立需要进行两次协议握手，协议需要在以太网广播域中进行传播，广播域传播过程需要借助数据链路层来实现，而观测用户拨号终端MAC地址在数据链路层中的有效性就会显得十分必要，有效性可以通过设备MAC地址表项来进行查看，比如观察表项中MAC地址的老化时间可以对数据链路层的稳定性进行初步判断。

结果：通过对比查看用户拨号终端MAC地址在OLT前端设备、接入交换机、汇聚交换机中的MAC地址表项，并没有发现处在这三个节点设备的拨号终端MAC地址有异常，初步判定数据链路层稳定。

步骤3：查看BRAS设备上用户PPPOE拨号状态，判断认证过程中有无异常情况。

理由：用户拨号终端在进行PPPOE拨号过程中，需要与BRAS设备以及后台鉴权中心进行协议报文交互：用户终端发出的PPPOE拨号协议报文（两次握手）通过ONU—OLT—接入交换机—汇聚交换机—BRAS形成的数据链路层通道，将携带封装PPPOE协议的拨号请求送入BRAS设备，并由BRAS交由鉴权中心验证后回复给拨号终端。所以从BRAS设备上可以查看用户拨号请求是否到达，以进一步验证数据链路通道的有效性。

结果：通过BRAS设备采集信息，发现用户报送PPPOE拨号请求可以送达BRAS设备，但会有时延。而且从鉴权中心回复拨号终端的信息经由BRAS下发到拨号终端完成一次握手后，没有收到拨号终端的二次握手信息。在这里会发现一些细节将故障嫌疑指向数据链路层，但是并不确定是鉴权中心回复信息用户终端验证后丢弃还是鉴权中心下发的参数存在异常。在这个阶段终于发现故障的尾巴。

步骤4：查看故障用户账号在鉴权中心的详细信息，判断鉴权系统中留存账号与正常账号有无异常。

理由：根据步骤3得出的初步结论，从难易程度来讲，首先从较为容易的第2条路进行验证，即用户账号信息的有效性。从网络结构上来说，一般情况下，越靠近网络上层，业务流受到的不确定因素越小；反之，越靠近用户侧，网络使用环境越复杂，不确定因素随之就会变多。

结果：通过从鉴权中心后台采集的用户账号信息，发现用户信息并无异常，为了做到更严谨的验证，从鉴权中心重新对用户信息进行登记，并使用“刷新”后的账号信息从用户拨号终端进行测试，故障依旧，至此故障范围重新缩小到汇聚交换机—接入交换机—OLT前端设备的数据链路层。

步骤5：根据步骤4得出的结论，由下至上详细梳理数据链路层业务流，采集分析设备端口VLAN标签。

理由：在数据链路层中，不同的业务流在以太网广播域传播过程中往往是通过VLAN标签来进行划分、相互识别并且相互隔离的，而我们日常查看数据链路层的“指标”往往只需要关注VLAN广播范围和MAC地址表项。在步骤2中我们着重观察故障用户拨号终端的MAC地址在数据链路层中的情况，需要放大到业务VLAN广播域这个节点上进行观察和分析。OLT前端设备中只设置和本设备相关的业务VLAN，所以分析的重点落在接入交换机以及汇聚交换机上面。

结果：通过梳理接入交换机各个端口设置的VLAN信息，发现交换机存在两个端口带有一个共同的VLAN标签，接下来发现这两个端口对接的业务类型均为OLT前端设备。正常情况下为了避免以太网广播域过大而导致数据链路层故障报文相互影响进而不便于确定用户侧故障源，每台OLT前端设备会采用不同的VLAN标签来进行业务在广播域的区分和隔离，在这里出现两个交换机端口使用共同的VLAN标签无疑需要将故障排查范围扩大到两台设备，而通过用户报障信息仅集中在一台设备上，所以计划将两台设备共用广播域的情况进行分离操作，即在不采用更换VLAN标签的情况下采用端口隔离的方式对这两个接入交换机端口进行配置更改，而不中断正在发生的大部分用户上网行为。操作完成后进行测试及报障用户回访，故障现象消失。

结束语

面对这类数据链路层故障该如何避免？如何优化这类故障导致的运维人力成本和时间成本？进而如何能给用户提供更好的宽带使用感受呢？可以从优化网络结构、减少数据链路层规模的方向去尝试。本案例的核心并不是哪个用户终端出现了异常情况进而影响到其他OLT前端设备用户，因为位于用户侧的终端使用环境复杂，无法规范所有用户的使用行为，处于数据链路层的设备层级过多，一旦前端设备接入较多，参数管理起来的难度就会加大，这样故障只是时间问题，不是概率问题。如果采用前端设备（主要工作在数据链路层）直连BRAS（主要工作在网络层），或者减少交换机（主要工作在数据链路层）的级联，这样一来从用户侧发出的数据流能够经历更少的广播域就可以到达网络层网关，这类数据链路层的故障就会比较少。

在日常网络故障分析和处理工作中，由数据链路层引发的故障经常会令人头疼不已，不仅仅是因为想方设法不断重现故障进行观察分析是件不容易的事情，更是因为数据链路层没有网络层路由关系那么相对“直观”，故障线索往往会比较隐蔽。上述案例最终的正确处理方式看起来比较简单，但是面对纷繁复杂的故障现象，需要运维人员熟悉网络的基本原理，更需要耐心。