华为ETH专线类问题定位指导.ppt

《华为ETH专线类问题定位指导.ppt》由会员分享，可在线阅读，更多相关《华为ETH专线类问题定位指导.ppt（33页珍藏版）》请在三一办公上搜索。

1、2023/9/24,ETH专线类问题定位指导,目录,以太专线配置不通类问题定位指导影响业务的配置参数ETH专线丢包异常类问题定位指导ETH专线业务异常中断类问题定位指导,以太专线配置不通类问题定位指导,基本业务模型影响业务的配置参数配置不通定位手段典型案例,Page 4,基本业务模型,E-Line业务包含业务接入点V-UNI和业务承载点V-NNI业务接入点V-UNI将用户业务接入L2VPN，每个业务可以包含1到2个V-UNI，每个V-UNI可以采用多种接入方式（Phy、P+C、P+S），可以实现接入侧端口带宽共享业务承载点V-NNI通过关联隧道实现用户业务报文的跨运营商网络传输，每个业务可能包

2、含0或1个V-NNI，支持多种传送技术（MPLS、QinQ、Phy），支持网络侧端口带宽共享，通过动态信令或静态配置建立与对端NNI的连接，通过OAM机制维护NNI侧连接。,影响业务的配置参数(一)端口属性,Page 5,影响业务的配置参数(二)业务分界标签与PW属性,Page 6,影响业务的配置参数(三)业务配置限制和注意事项,Page 7,专线业务只有上PW的业务支持Service分界标签，且配置Service分界标签后，Uni端口只支持1个Vlan；Uni-Uni等其他类型业务配置分界标签无意义；业务支持MTU配置，根据报文的最大长度配置合适的MTU;配置本地专线业务的一个uni端口封装

3、类型为null时，必须保证另一个uni也为null，且vlanlist为0(dcn去使能)；配置P+V+Pri专线业务时，只支持上PW的远端专线业务；在Access端口作为专线UNI端口时，该端口的默认vlan与业务vlan必须相同；,Page 8,常见配置错误,(1)两端端口的工作模式配置不一致，例如：一端配置为自协商，另一端配置为全双工；(2)两端端口Tag属性配置不一致，或者端口属性与业务报文特征不一致，例如：用户报文携带VLAN，但端口属性配置为access；(3)网络侧Tunnel/PW参数配置不一致，例如：Tunnel/PW的Label是否一致，两端PW控制字设置是否一致；(4)网

4、络侧两端端口IP不在同一网段；,Page 9,配置不通定位手段,以下故障场景优先排查配置错误：(1)创建后业务不通；(2)修改配置后业务中断；(3)新增业务后其他业务受到影响。,Page 10,典型案例（一）,【问题现象】新创建的ETH专线业务不通。【定位过程】1、使用性能统计，检查网元各个业务端口的收发包统计，发现报文从uni端口进入后，nni侧能够正常发送报文，说明报文在入隧道这边没有问题；2、检查对端nni侧端口的性能统计，发现nni侧没有收到从对端发过来的报文；3、在本端对nni侧报文进行抓包分析，发现nni侧报文带有控制字，检查本端pw控制字设置，发现pw属性设置控制字为：fst-u

5、se;4、检查对端nni对应的pw控制字设置，发现对端nni对应的pw的控制字设置为：not-use，确认为nni对应的pw配置错误；5、将本端nni对应的pw控制字属性设为：not-use，再检查业务，发现专线业务恢复。,典型案例（一）,【问题结论】在专线业务中，要保证两端nni对应的pw控制字属性设置一致，要么都启用控制字，要么都不启用控制字。如果一端不支持控制字，则需要将对端nni对应的pw的控制字属性设置为：not-use。【处理意见】检查两端nni侧对应的pw控制字设置是否一致，如果不一致，将两端端口的控制字设置为一致。,Page 11,Page 12,典型案例（二）,【问题现象】X

6、X移动，PTN3900与PTN950对接，创建静态TUNNEL不通。【定位过程】1、一线确认两个站点之间只有一条链路；2、知会一线分别在两个网元上PING对端端口，发现PING不通，怀疑是光纤连接不正确；3、通过查询核心路由发现，下游PTN950没有直接连接到PTN3900而是连接到其它网元上，从而确认两站之间没有链路。是一线光缆连接不对造成的问题。【问题结论】网管上配置的光缆信息与实际的链路配置不符，导致配置错误导致。【处理意见】检查光缆信息与实际链路配置是否设置正确。,Page 13,典型案例（三）,【问题现象】移动，PTN 950网元的Tunnel大量上报MPLS_TUNNEL_LOCV

7、告警。【定位过程】1、MPLS_TUNNEL_LOCV 为Tunnel 连通性丢失告警。连续3 个周期内没有收到希望的CV/FFD 报文时出现此告警，怀疑Tunnel不连通。2、检查Tunnel设置，发现Tunnel的下一跳ip地址配置错误；3、与一线确认，发现一线更改了端口的IP地址，却没有更新Tunnel的配置，问题原因找到。【问题结论】网元之间的Tunnel的下一条ip地址配置错误。【处理意见】更改端口ip地址的时候注意同步更改Tunnel下一跳ip地址。,ETH专线丢包异常类问题定位指导,原理介绍丢包定位丢包定位示意图典型案例信息采集,Page 15,原理介绍,PTN,城市1,城市2,

8、在之间添加VLAN,添加tunnel的标签和pw的标签,剥标签,剥VLAN，还原用户报文,设备将用户侧特定端口或者特定端口中特定VLAN的报文，送到网络侧的某个端口或者某个PW上，实现用户数据的点到点透传。,PW,Page 16,丢包定位流程,Page 17,丢包定位流程,如果已确定网元NNI侧TUNNEL/PW发生丢包，可继续检查以下内容：1)端口的ARP学习地址是否发生修改；2)端口的工作模式是否匹配？如果模式速率不一致可能会丢包；3)端口的配置是否约束产生丢包；4)单板、光纤、光纤模块是否有问题；5)处理板是否复位过；6)TUNNEL/Pw和端口的MTU是否设置不对；如果已确定网元UNI

9、发生丢包，可继续检查以下内容：1)检查业务、UNI端口MTU是否设置不对；2)利用端口性能统计检查是否有异常帧或出错帧；3)检查UNI端口是否link down过；4)端口的工作模式是否匹配？如果模式速率不一致可能会丢包；,Page 18,丢包定位流程示意图,PTN 1,PTN 2,PTN 3,PTN 4,PTN 5,如图所示，PTN1至PTN5建立远程专线业务，PTN1为ingresss节点，PTN5为egress节点，其他为透传节点，丢包定位流程如下：,查看PTN3收发计数差别特别大，就是在它这里丢包啦,!告警,!告警,步骤1：检查网管告警信息，利用告警信息定位问题故障。比如：1)MPLS

10、_TUNNEL_LOCV告警检查网络是否拥塞；检查节点是否复位；2)MPLS_TUNNEL_SD/MPLS_TUNNEL_SF告警检查端口是否存在误码；tunnel带宽是否占用已满；3)MPLS_TUNNEL_BDI检查本端网元与上游网元之间的物理链路是否存在故障；4)MPLS_TUNNEL_FDI检查本端网元与上游网元之间的物理链路是否存在故障；5)检查是否有MPLS_PWL_LOCV告警检查网络是否拥塞；检查对端PW是否复位；业务接口配置是否对；6)检查是否有MPLS_PW_SD/MPLS_PW_SF告警检查端口是否存在误码；PW对端单板是否复位；7)检查端口是否有FLOW_OVER告警检

11、查流量是否超过端口带宽；8)检查ETH是否有ETH_CFM_CSCL/ETHCRCALI告警检查网络是否拥塞；光模块质量；链路硬件故障；,如果从告警无法定位问题？那么要用性能统计来定位。先确定此处是大量丢包还是少量丢包呢？,查看各节点TNL/PW性能统计！,如果是大量丢包！,ingresss,egress,步骤2：从ingress节点到中间节点最后到egress节点，分别查看它们TNL/PW性能统计，检查收发包是否相差比较大。如果某个NNI收发计数差别大，可认为丢包发生在此网元端口上。,既然已经知道这个网元NNI TNL/PW出现丢包了，继续检查是否因带宽受限而丢包？还是ARP地址被修改?或者

12、MTU不匹配？按这样思路下去找到问题位置啦,如果是少量丢包！,网络存在业务和协议报文，并且业务不可中断，对于少量丢包很难使用性能统计找出丢包位置，单纯从收发数量已不能确定是否丢包。,PTN1有收到PTN2的响应报文并且数量相同，说明PTN1-PTN2之间的TNL/PW路径是正常没有丢包哦!,PTN1发PING报文给PTN3。一段时间后PTN1没有收到PTN3响应报文或者收到报文比发送的报文少，说明PTN2-PTN3之间TNL/PW路径会丢包啦!,既然已知道这个TNL/Pw路径出现问题了，继续检查是否因带宽受限而丢包？还是ARP地址被修改?或者MTU不匹配？按这样思路下去找到问题位置啦,步骤4：

13、如果以上步骤还是没有定位到丢包位置，那可以打开UNI性能统计和端口性能统计来查看是否有业务异常。比如UNI性能收发是不是相差特别大？如果是的话那丢包就发送在UNI侧。检查UNI侧端口性能统计，看看有没有校验错误帧或者其他异常帧，如果有的话，可能单板存在异常或者光纤链路出现问题啦,Page 19,典型案例（一）,【问题现象】如下测试方案中，主通路以太专线业务丢包。X=1为主通道，X=2为保护路径，2路径上配置专线PW业务。查看路由器CX1统计，在主通道数据从3900-4到3900-1上测试1%微量丢包，倒换到保护路径不丢包。,PTN3900-1129.10.39.1,PTN3900-4129.1

14、0.39.4,PTN3900-2129.10.39.2,CX2129.10.6.67,CX1129.10.6.66,CX8129.10.6.71,G3/1/10-G3/0/1,G3/1/11-G3/0/4,G2/0/10-G3/0/2,G2/0/11-G3/0/5,G1/0/0,G2/0/0,EX2G11/1,EX2G7/2,EX2G5/2,EX2G11/1,EX2G11/2,EX2G11/2,EG8G3/3,EG8G3/3,X=1,X=2,X=3,步骤1：在主路径3900-4和3900-1上检查是否有相应的告警信息。,在网管中没有发现2台设备的告警信息。,步骤2：现象为少量丢包，从性能统计中

15、无法看出具体在哪里丢包。使用OAM PING自定义包长来检查是否有丢包。,步骤3：发现存在丢包现象。检查TNL/PW带宽/MTU；检查ARP是否学习到；检查端口工作模式；检查配置等，检查后并没有发现问题。,步骤4：打开3900-4 NNI侧端口性能统计，检查是否有校验出错帧或异常帧。此时发现性能统计中出现一些校验出错的数据包。根据这个情况很有可能是端口和光纤路径出现问题。需要进一步检查单板、光纤模块及光纤线问题。,步骤5：将光纤和光纤模块连接到保护通道测试未发现问题，排除光模块和光纤问题。更换3900-4 EX2单板，丢包现象消失，说明丢包来自EX2单板。,Page 20,典型案例（二）,【问

16、题现象】某地区现网突发大量丢包，而后恢复正常，PTN10036PTN10023为工作tunnel，分析丢包原因。,PTN10036,PTN10023,10GE,10GE,10GE,POS,PTN10035,PTN10024,工作TUNNEL,步骤1：查询网管当前告警和历史告警，发现在丢包问题出现之前一小段时间上报MPLS_TUNNEL_LOCV告警。,步骤2：在网管上查询保护信息，发现该丢包的业务所在的TUNNEL配置了APS保护组，该保护组为可恢复式。,步骤3：业务恢复后查询APS组状态，为工作在工作TUNNEL。通过告警我们知道MPLS_TUNNEL_LOCV会触发APS倒换，于是下一步需

17、要确定APS保护组中工作TUNNEL和保护TUNNEL分别的实际路由。,步骤4：通过查询发现APS保护组中的工作tunnel是1跳走10GE端口。而保护tunnel是4跳，其中的一跳走的是POS口。,步骤5：通过使用端口流量统计发现在最后一跳走POS口的时候速率明显下降，认定为最后一跳出现问题。,步骤6：查询APS组中的保护tunnel发现约束配置错误，没有严格约束保护tunnel不经过pos口。10GE端口并未严格约束在“路由约束端口IP”中。当MPLS_TUNNEL_LOCV告警发生时，业务被倒换到经过了POS端口的保护Tunnel，在带宽仅为155M的POS链路上，业务出现大量丢包。当M

18、PLS_TUNNEL_LOCV告警清除后，可恢复式的APS保护组又自动把业务倒换回工作Tunnel，仍然走10GE端口，使得业务恢复正常。【问题结论】添加路由约束条件，确保保护Tunnel必须经过10GE端口,保护TUNNEL,Page 21,典型案例（三）,【问题现象】XX运营商PTN设备与XX基站对接在近两个月期间70多台基站出现频繁掉话现象。技服称在某时间段内，在基站侧发送报文长度为1000字节，频率为35个/分钟的PING报文。共有3万多个报文，丢失9个报文。据此称是由于中间的PTN设备丢包导致了掉话问题频现。【定位过程】1、检查历史告警，发现某期间几乎所有的站点均有发生Eth_LOS

19、的告警，比较集中在23：00 以后，时间以10秒频率较高，怀疑是链路状态不好。2、对没有出现掉话和出现掉话频率低的站点进行分析。发现这些站点中物理接口也呈现多样 性。不仅有ETH百兆电口，还有ETH百兆光口，而且这些站点多为室外站点。没有出现掉话 的站点以ETH百兆光口居多。3、考虑到ETH百兆光口的工作模式只能是百兆全双工工作模式，而且在这种类型的端口计数 中没有发现CRC校验错误报文。故而怀疑为端口工作模式不一致导致。4、检查基站端口工作模式。确认基站的ETH百兆电口工作模式全部设置为自协商模式。5、根据IEEE 802.3的标准，如果端口工作模式为自协商，而对端端口工作模式为百兆全双工，

20、此自协商端口的协商结果为百兆半双工。6、修改两个基站的端口工作模式为百兆全双工，无掉话现象。,Page 22,典型案例（三）,【问题结论】XX移动PTN与XX设备掉话的根本原因就是XX基站与PTN设备的端口工作模式设置不一致。【处理意见】尽管从最终的定位结果来看这确实是非常小的配置问题，但是其造成的影响却非常大，而且耗费非常多的时间和人力。端口工作模式的问题比较容易被人忽略，定位起来比较让人摸不着头脑。,Page 23,信息采集,ETH专线业务异常中断类问题定位指导,原理介绍问题定位定位示意图典型案例信息采集,Page 25,原理介绍,PTN,城市1,城市2,在之间添加VLAN,添加tunne

21、l的标签和pw的标签,剥标签,剥VLAN，还原用户报文,设备将用户侧特定端口或者特定端口中特定VLAN的报文，送到网络侧的某个端口或者某个PW上，实现用户数据的点到点透传。,PW,Page 26,问题定位,Page 27,问题定位,确定TNL/PW故障位置:TNL/PW配置不正确:1)检查TNL/PW的标签是否匹配；2)检查PW的tag属性是否两边一致；3)检查Tunnel的出端口和下一跳IP地址是否正确ARP没有学到，可能原因：1)对接的两端口是否存在异常告警，例如ETH_LINK_DOWN/ETH_LOS/；2)对接的两端口工作模式是否一致；3)对接的两端口封装属性和Tag属性是否一致；4

22、)对接的两端口IP是否在同一网段；5)端口所在的单板或者处理板上报了异常告警，例如HARD_BAD、COMMU_FAIL告警确定UNI故障位置:检查UNI配置是否正确:1)检查UNI端口封装属性；2)检查UNI端口工作模式；3)检查UNI端口是否link down;4)检查MTU是否正确；检查UNI端口性能是否正常:1)是否有校验错误帧；2)是否有丢包；3)是否有异常帧；,定位示意图,Page 28,告警弹出！请处理,告警弹出！请处理,1.先检查设备弹出的告警信息，根据告警信息来定位故障点。如果此刻告警信息比较明确，通过告警信息就可以定位出问题在哪。比如单板hard_bad这种告警就指明了那块

23、板出了问题，直接更换单板解决问题！,PTN 1,PTN 2,PTN 3,PTN 4,PTN 5,3.检查业务UNI是否正常？查看当前故障网元UNI性能统计计数，检查收发是否正常,2.通过TUNNEL/PW的OAM功能来检查TUNNEL/PW是否正常连通。使用MPLS Ping/Traceroute方式来确认通路失效点。,Ping/Traceroute,Ping/Traceroute,Ping/Traceroute,故障点,查看UNI性能统计计数，检查收发是否正常,Page 29,典型案例（一）,【问题现象】单板概率性故障导致业务中断。出现两次中断，每次中断时间为20分钟。NNI侧采用GE光接口

24、对接。业务中断时，网管上报MPLS_TUNNEL_LOCV和ETH_APS_LOST告警。处理步骤见图,NB 1,NB 1,RNC,RNC,ETH,PTN 1,PTN,PTN 3,PTN,RNC,RNC,Tunnel路径,ingress,egress,1.在网管中检查告警信息，发现一段时间内网元有MPLS_TUNNEL_LOCV和ETH_APS_LOST告警。说明TUNNEL在一段时间内连通性失效。,2.检查业务TUNNEL是否正常。使用MPLS TRACEROUTE报文在ingress节点发送来检查TUNNEL路径，发现不正常，说明tunnel是连通失效，导致业务中断。,ETH,PTN 2,

25、PTN,上报网管收到traceroute报文,没发出tracerout报文,从ingress发送traceroute报文后，PTN2可以收到，PTN3收不到traceroute 报文，证明失效路径发生在PTN2PTN3之间。,告警,是否ARP没学到？,是否TNL/PW配置不正常？,是否性能统计不正常？,3.检查PT2 NNI侧端口是否正确学习到对方MAC，检查NNI侧ARP表，发现正确的MAC地址被概率性修改了，导致ARP协议报文中的“目的MAC地址”被设置为错误的信息（被修改）。而业务正常时，源网元NNI侧出端口学习到的对端端口的MAC地址应是正确的。从中可以判断TUNNEL中断是因为对端A

26、RP地址被修改，导致业务不通。,对端网元收到携带错误信息的ARP报文后，因校验不通过就全部丢弃，ARP协议协商失败，Tunnel中断，业务也随之中断。,经过ARP老化时间后，源网元NNI侧出端口重新学习到对端端口正确的MAC地址，ARP协议协商成功，业务恢复正常。这是业务恢复正常的原因。,4.继续查询APS保护组，发现保护Tunnel也经过了同一物理链路，故障发生时，工作Tunnel和保护Tunnel同时中断，APS保护组失效。5.更换故障单板，避免再次出现小概率性的错误。故障未再发生，问题解决。因为网管未上报ETH_LOS告警，可以判断出物理链路连接良好。业务中断时间又与ARP老化时间吻合，

27、可以推断故障原因是MAC地址学习失败。,Page 30,典型案例（二）,【问题现象】某运营商网络通过在PTN设备上配置专线业务，专线业务穿越波分设备网，一段时间后发现业务中断，PTN2、PTN3上报MPLS_TUNNEL_LOCV告警。,NB 1,PTN 1,Tunnel路径,ingress,PTN 3,RNC,波分设备网,egress,PTN3设备上报MPLS_TUNNEL_LOCV告警,1.通过TUNNEL OAM告警得知TUNNEL连通不正常,PTN 2,2.从ingress发送traceroute报文，确定故障点,上报tracerout响应报文,无tracerout响应报文,3.失效路

28、径发生在PTN2PTN3之间,4.检查端口发现ARP已学到；TNL/PW配置正常，没有发现问题。从PTN2设备向PTN3设备发送包长1000字节PING报文，查看报文响应时间，发现响应超时。,Ping无响应,5.为确定路径时延，在PTN2和PTN3设备上分别打开性能统计，统计发送PING包和收到PING包的时间,打开性能统计计数，查看PING报文发包时间,打开性能统计计数，查看PING报文收包时间,检查性能统计计数，查看PING报文发收包时间，相差10s，可以说明穿越的波分设备网中存在较大延时，导致TUNNEL OAM产生MPLS_TUNNEL_LOCV告警。请波分相关技术人员过来定位，确实是

29、波分设备中存在延时。,Page 31,典型案例（三）,【问题现象】激光器状态异常导致LAG组业务中断。某日，客户反馈一条LAG（链路聚合组）上的以太网业务突然中断。该LAG组包括一个主端口，三个从端口。从网管上看，四个端口同时上报LASER_SHUT告警并且激光器确实无光输出，但该四个端口均已使能。,主端口,从端口,LAG组,LASER_SHUT告警,LASER_SHUT告警,1.检查当前告警，发现有LASER_SHUT告警,2.检查上报告警的端口的状态为“使能”,3.查询历史告警，发现单板曾经上报HARD_BAD告警，说明该单板出现过故障，LAG组自动关闭了所有端口的激光器,4.但是当HARD_BAD告警消失时，单板的状态并未随之恢复为正常，导致LASER_SHUT告警一直存在,5.硬复位该单板，单板状态恢复正常，LASER_SHUT告警消失，业务恢复正常,LAG组检测到单板状态为异常，自动关闭了所有端口的激光器，但无法改变端口的“使能”状态.,Page 32,信息采集,