华为——PTN常见开局故障处理(2).ppt
2023/2/22,PTN常见开局故障处理,PTN产品组,Page 2,培训目标,学完本课程后，您应该能：了解PTN 产品故障处理基本步骤掌握PTN 产品常见故障处理方法,参考资料OptiX PTN 故障处理手册OptiX PTN 告警和性能手册,目录,PTN 故障定位方法PTN 常见故障处理,Page 4,PTN 故障定位方法,告警法PTN在各种物理端口、逻辑端口、业务、PW等都有相关的告警。当发生故障时，查询当前设备的相关告警。通过分析告警，可以迅速的找到问题发生在什么层面。在定位业务故障的时候，通常建议首先关注传输层和物理层的告警性能法PTN在各种物理端口、逻辑端口（如IMA组、MP组等）、业务、PW都支持性能统计计数。当业务中断后，通过读取业务的相关性能，可以确认数据报文在哪台网元，在什么层面丢了。比如，如果发现端口上有误码计数，就可以直接判定是中间链路问题环回法（CES 业务常见方法）PTN在各种物理端口、逻辑端口（如IMA组）都支持环回功能。在某些物理端口的故障发生后，通过环回的方法，可以确认问题所在的设备（或链路）业务oam法（重点了解和掌握）ATM业务与ETH业务都支持OAM功能，通过OAM可以准确的定位到故障所在的网元和处理板，进而可以快速的对业务进行恢复,Page 5,环回法定位CES 业务故障,现象描述：在下面的组网图中，用误码仪测出BSC 与BTS 之间的CES 业务中存在大量误码,处理步骤步骤1:在网元NE01 上连接仪表做误码测试。将NE04 的L75 单板上的2M 端口设置为“内环回”，仪表显示有大量误码。步骤2:在NE03 配置静态ARP 表项，MAC 地址选择NE03 的出端口，IP 地址选择NE04。在NE03 和NE04 之间创建入标签和出标签相同的Tunnel步骤3:将NE04 的网络侧端口设置为“外环回”，连接NE01 的仪表仍然显示有误码，将NE03 上连接NE04 的网络侧端口设置为“内环回”，仍然有误码。步骤4:将NE03 上连接NE02 的网络侧端口设置为“外环回”，误码消失。据此判定问题出在NE03 网元。步骤5:更换NE03 网元上对NE02 对接的10GE 线路板EX2，误码消失,Page 6,PTN OAM知识-MPLS OAM,MPLS 支持多种三层和二层协议，提供一个完全不依赖于任何上层或下层的OAM 机制MPLS OAM 使用CV/FFD、Ping 等方式检测LSP 的连通性,CV（Connectivity Verification）/FFD（Fast Failure Detection）单向连通检测1.Ingress 节点发送CV/FFD 检测报文，Transit 节点透传报文，报文通过被检测的LSP到达Egress 节点；2.Egress 节点把接收到的报文类型、频率、TTSI 等信息字段与本地记录的应该收到的对应值相比较来判断报文的正误，并统计检测周期内收到的正确报文与错误报文的数量，从而实现对LSP的连通性的实时监3.当Egress 节点检测到LSP 缺陷后，分析出缺陷类型，通过反向通道将携带缺陷信息的BDI报文发送给Ingress 节点，从而使Ingress 节点及时获知缺陷状态,MPLS Ping 单向连通检测1.MPLS Ping使用MPLS Echo Request 和MPLS Echo Reply 检测LSP 的可用性。Echo Request 中携带需要检测的FEC信息，和其他属于此FEC 的报文一样沿LSP 发送，从而实现对LSP 的检测2.Echo Request 消息应该达到Tunnel 的Egress 节点，由Egress 节点的控制平面确认本节点是否是该FEC 的出口。通过MPLS Ping 可以检测LSP 是否建立成功,Page 7,PTN OAM 知识-PW OAM,PTN 设备将业务报文进行PW 封装后送到Tunnel 中进行承载。网络中存在Tunnel 和PW两个层次，MPLS Tunnel 可以通过MPLS OAM 维护和管理，而PW 层则需要通过PWOAM 来进行维护和管理PW OAM 的主要检测方式是PW Ping，Ping 报文在Ingress 节点封装进PW 中，沿虚电路发送，从而实现对PW 的检测,如图 所示，NE1 和NE2 之间存在一条由PW承载的CES 业务，在NE1 发起PW Ping 测试，可以查看Ping 测试的结果，检测PW 的运行状态,Page 8,PTN OAM 知识-以太业务OAM,以太网业务OAM 是一种基于MAC 层的协议，它通过发送OAM 报文来检测以太网链路以太网业务OAM 包括CC、LB 和LT 三种检测手段,1.环回检测（LB），源端MEP 将构造并发送LBM 帧，同时启动定时器开始计时。如果目的MEP 收到该LBM，将构造LBR 帧发送回源端MEP，环回成功。如果源端MEP 定时器超时，环回失败,2.单向连通性检测（CC），源端MEP 将周期性的发送CC 帧，目的MEP 收到源端发送的CC 帧后，启动CC 检测功能。如果目的MEP 在一定时间之内没有收到源端的CC 报文，则自动上报ETH_CFM_LOC 告警。,3.链路追踪检测（LT），源端MEP 发送LTM 帧，同时启动定时器开始计时。链路上所有的MIP 都会转发LTM 帧，所有收到LTM 帧的MEP 和MIP 都会回送LTR 帧响应，根据这些LTR 帧可以判断出源MEP 到目的MEP 所经过的所有MIP。如果源端MEP 定时器超时，LT 失败,Page 9,PTN 故障定位流程,掌握PTN OAM 使用是快速定位链路和业务故障的关键,目录,PTN 故障定位方法PTN 常见故障处理DCN故障处理MPLS Tunnel故障处理PW 故障处理CES 业务故障处理以太网业务故障处理时钟故障处理,Page 11,DCN 故障处理流程,DCN 故障现象网管与网元通信中断，网管上网元图标变灰色，网元脱管；网管操作命令没有响应。若响应中断时间持续超过2 分钟，网管与网元通信中断网管查询信息部分丢失,故障可能原因原因1：全网内的网元ID、网元IP 或者子网掩码存在冲突。原因2：故障网元的带内DCN 端口未使能，或对接端口参数配置不一致。原因3：故障网元与网管之间的物理连接中断。原因4：接收信号丢失或接收光功率过低，无法提取DCN 报文。原因5：单板故障。原因6：DCN 穿越的第三方网络不健康，引入DCN 风暴或DCN 中断。原因7：带内DCN 通道带宽配置过低。原因8：故障网元主控板正在复位或发生了主备倒换，带内DCN 报文得不到响应。,Page 12,DCN 故障处理方法,Page 13,DCN 故障处理案例1/3,故障现象两台非网关网元NE10 和NE30，分别通过ML-PPP 连接第三方SDH 设备，再连接到NE08 与网管保持通讯NE10 和NE08 已配置业务且正常运行，NE30 为新创建的网元，未配置业务NE30 创建后，NE10 和NE30 一直处于间歇性脱管状态，网管上报NE_COMMU_BREAK 和NE_NOT_LOGIN 告警,处理步骤步骤1:检查NE10 的ML-PPP 端口状态，发现链路无问题，业务一直都是正常,排除DCN 通道质量问题步骤2:查看NE30 的网元IP，发现与NE10 某DCN 通道核心路由重复，确认为NE30 网元IP设置错误步骤3:在网管上更改NE30 的网元IP，返回提示成功后，发现该两个网元仍出现间歇脱管步骤4:尝试查询NE30 网元信息，NE30 网元IP 仍为修改前的错误值，网管上修改NE30 网元IP 的操作并未成功步骤5 多次重复修改NE30 网元IP 的操作，直至网元间歇性脱管故障消失,案例类型-IP 地址冲突导致网元间歇性脱管,Page 14,DCN 故障处理案例2/3,故障现象PTN 网络的网关网元穿越一个IP 传送网络后，保持与网管中心之间的通信PTN 网络中的非网关网元全部脱管，系统中出现大量MPLS_TUNNEL_LOCV 告警，业务中断,处理步骤步骤1：检查该网关网元主控板上的ETH 接口，发现该接口通过网线与IP 传送网络中一台路由器的2 号接口直连。该路由器的1 号接口连接网管，但3 号接口与4 号接口被另一条网线直连，产生了环路步骤2:IP 传送网络中的大量DCN 报文及其它报文通过交换机的环路被引入PTN 网络中，造成网关网元的CPU 长期被完全占用，而PTN 网络内非网关网元的DCN 报文及其它协议报文无法得到处理，最终导致网元脱管，业务中断步骤3：拔掉引发交换机环回的网线，PTN 网络恢复正常,案例类型-环回引发DCN 风暴导致网元脱管,Page 15,DCN 故障处理案例3/3,案例类型-子网掩码配置错误导致全网网元脱管故障现象：在由PTN 网元组成的网络中，添加一个新网元后，其它所有网元全部脱管处理步骤步骤1：PTN 网元都属于同一个网段，且“子网掩码”都是16 位，而新添加的这个网元的“子网掩码”是24 位步骤2:“子网掩码”为24 位的网元会生成一个“255.255.255.0”的网段路由，而该路由会通过DCN 通道在网络内扩散。在网管访问网元的过程中，根据最长匹配原则，网管服务器主机原本16 位的网段“255.255.0.0”会被匹配为24 位的“255.255.255.0”，造成其它子网掩码均为16 位的网元无法与网管通信，网元脱管步骤3:断开新添加网元与网管之间的物理连接，并将该网元的子网掩码修改为16 位后，网络正常,案例类型-GE 端口工作模式不一致导致网元间通信中断故障现象：PTN 网元通过GE 链路互联组网，网元属性及DCN 参数已经正确规划与配置，现场安装设备时，发现多处相邻网元之间无法通信，但各网元均无告警上报处理步骤步骤1:选择无法彼此通信的两个相邻网元，现场分别登录，可正常登录，且通信正常。步骤2:查看当前性能事件，链路上无误码，测试光功率也均在正常范围内。步骤3 检查两端网元上直接对接的光口，均为GE 光口，网管上检查两个端口的属性配置，发现“工作模式”不一致（一端为“1000M 全双工”，一端为“自协商”）步骤5:将两端GE 光接口的“工作模式”统一修改为“自协商”模式，通信也正常,目录,PTN 故障定位方法PTN 常见故障处理DCN故障处理MPLS Tunnel故障处理PW 故障处理CES 业务故障处理以太网业务故障处理时钟故障处理,Page 17,MPLS Tunnel 故障处理方法,MPLS Tunnel 故障现象MPLS Tunnel 创建失败，业务不通l MPLS Tunnel 故障，业务中断l 保护倒换失败，业务中断或出现丢包、误码,故障处理方法检查链路两端的IP是否设置正确检查控制链路状态是否OK检查光纤是否连接正确检查NNI端口之间的二层属性设置是否一致(tag/access/hybrid)查询是否有相关链路级告警，如果有需要清除掉检查Tunnel的路由约束是否配置正确检查Tunnel是否使能查询Tunnel所在的物理端口是否存在FLOW_OVER告警，如果存在，说明网络侧出现拥塞，此时部分业务回手到影响,Page 18,BTS 1,CES,CES,BTS 2,PTN,PTN,ETH,BTS 3,PTN,MPLS,PTN,PTN,MPLS,PTN,BSC,CoreNetwrok,PTN,BSC,GE/10GE,GE/FE,STM-1,STM-1,GE/10GE,MPLS_TUNNEL_LOCV,MPLS_TUNNEL_FDI,MPLS_TUNNEL_LOCV：Tunnel连通性丢失告警。物理链路故障。网络出现严重的拥塞。对端设备故障。MPLS_TUNNEL_FDI：Tunnel前向缺陷指示告警。上游设备检测到物理层发生了故障，比如断纤。,MPLS Tunnel 故障典型告警处理,Page 19,MPLS Tunnel 故障处理案例,案例类型-光纤错连导致动态MPLS Tunnel创建失败 故障现象：在现网上集成业务时，发现有这样两个网元，彼此之间的DCN通讯正常，但在二者之间的动态Tunnel却全部创建失败。PING对端端口的IP地址，返回“操作超时”。处理步骤步骤1：查询系统当前告警，未发现ETH_LOS、ETH_LINK_DOWN或HARD_BAD告警，且DCN通讯正常，可以排除链路、端口或单板等硬件出现了故障。步骤2:查询两个网元端口的IP地址，均配置正确，而且在同一个网段内。步骤3:查询ARP表项，发现无法学习到对端端口的“ARP表项”。步骤4:因为两端的DCN通讯是正常的，从DCN的连通性着手分析。只有在学习到对方端口的MAC地址之后，才能开始正常的DCN通讯。查询后发现宿网元的端口的MAC地址与网元规划表不一致。步骤5:现场确认，是设备安装时连错了光纤，导致ARP等协议不能正常工作，动态Tunnel创建失败。步骤6:按照网元规划表重新连接光纤后，问题解决。,目录,PTN 故障定位方法PTN 常见故障处理DCN故障处理MPLS Tunnel故障处理PW 故障处理CES 业务故障处理以太网业务故障处理时钟故障处理,Page 21,PW 故障处理方法,PW 故障现象PW 创建失败，业务不通。PW 故障，业务中断或出现丢包、误码,故障处理方法检查所在的Tunnel是否UP检查两端的PW的ID是否一致检查是否配置了LDP对等体查询PW是否使能检查两端的PW的参数检查Control Word Use Policy”，是否一端配置为“Must Use”，另一端配置为“Nonuse”检查Ethernet 业务，两端的“MTU”是否配置一致 检查CES 业务，两端的“RTP Head”、“Packet Loading Time”等参数是否配置一致,目录,PTN 故障定位方法PTN 常见故障处理DCN故障处理MPLS Tunnel故障处理PW 故障处理CES 业务故障处理以太网业务故障处理时钟故障处理,Page 23,CES 业务故障处理流程,CES业务中断/损伤原因配置错误处理板、接口板的接口接入的信号丢失或恶化Tunnel/PW 故障时钟不同步时延过大,Page 24,CES 业务故障处理方法,Page 25,BTS 1,CES,CES,BTS 2,PTN,PTN,CES 业务故障典型告警处理,ETH,BTS 3,PTN,MPLS,PTN,PTN,MPLS,PTN,BSC,CoreNetwrok,PTN,BSC,GE/10GE,GE/FE,STM-1,STM-1,GE/10GE,T_ALOS信号丢失,故障原因：（1）E1/T1业务未接入；（2）DDF架侧E1/T1接口输出端口脱落或松动；（3）本站E1/T1接口输入端口脱落或松动；（4）单板故障；（5）电缆故障,ALM_E1RAI远端告警指示,故障原因：对端有告警；,Page 26,CES 业务故障处理案例,案例1.Tunnel带宽不够导致CES业务持续误码【问题现象】：一条两站的CES上MLPPP业务，时隙为15个，业务配完后，仪表显示业务通，删掉业 务，重新创建31个时隙的业务，仪表检测到持续误码。【问题原因】：MLPPP组只有一个PPP成员，带宽不足以承载一条CES业务，导致大量PW报文被丢弃。【解决办法】：MLPPP组再添加一个成员后业务通,案例2.多网元的时钟源不同导致长时间测试有少量误码：【问题现象】：某局测试环境，组网如下图所示，约两个多小时后出现1s的LSS告警，查询PW性能 计数，发现有jitter buffer溢出的计数,【问题原因】：1900网元和仪表分别跟踪不同的时钟源，运 行后随着时钟漂移和时延抖动产生滑帧【解决办法】：仪表改为跟踪设备时钟,案例3：E1成帧模式不匹配导致CES业务不通：【问题现象】：一条两站的远程CES业务，一端自环，一端与仪表对接，业务配完后，仪表显示LSS告 警，查询单板告警，发现CES业务使用的E1端口有LMFA告警【问题原因】：E1端口为CRC4-multiframe模式，而仪表设置为Unframe模式，芯片无法正确定帧【解决办法】：将仪表设置为PCM31C模式即可,目录,PTN 故障定位方法PTN 常见故障处理DCN故障处理MPLS Tunnel故障处理PW 故障处理CES 业务故障处理以太网业务故障处理时钟故障处理,Page 28,以太网业务故障处理流程,故障现象以太网业务中断、出现丢包或错包，影响设备接入的其它业务,故障原因原因1：接收信号丢失原因2：以太网网口连接错误，端协商失败原因3：端口配置了环回原因4：接口流量限值配置过低，源宿两端接口配置不一致,Page 29,以太网业务故障处理方法,Page 30,BTS 1,CES,CES,BTS 2,PTN,PTN,以太网业务故障典型告警处理,ETH,BTS 3,PTN,MPLS,PTN,PTN,MPLS,PTN,BSC,CoreNetwrok,PTN,BSC,10G/GE,GE/FE,STM-1,STM-1,10G/GE,ETH_LOS光信号丢失,故障原因：(1)光纤断；(2)光模块坏；(3)光衰减过大；,ETH_LINK_DOWN网口连接故障,故障原因：两端工作模式不一致，造成协商失败；电缆、光纤连接或者对端设备故障。,MAC_FCS_EXC误码越限,故障原因：MAC层检测到误码越限；线路信号劣化；光纤性能劣化；光口不洁净,Page 31,以太网业务故障处理案例1/2,案例类型-以太网接口属性配置错误导致设备与交换机对接失败 故障现象：两台PTN 3900通过由交换机组成的以太网网络，PTN设备通过ETFC单板连接交换机。配置了由IP Tunnel承载的静态以太网专线业务后，业务不通，无法正常工作。处理步骤步骤1:单独测试交换机组成的以太网网络，发现以太网两端可以互通，以太网网络正常。步骤2:查询IP Tunnle配置，本端接口和对端接口IP地址设置均正确，静态路由配置正确。步骤3:查看承载该以太网专线业务的PW的状态为“UP”。步骤4:查询以太网接口的基本属性，其“端口模式”为“二层”，“封装类型”为“802.1Q”。更改“封装类型”为“NULL”，再重新配置E-Line业务，发现业务可以正常工作,Page 32,以太网业务故障处理案例2/2,案例类型-IP Tunnel 承载业务时模式错误导致业务不通故障现象：用GE 端口创建IP Tunnel 承载E-Line 业务时，UNI 侧端口“VLANs”设置为“1-3”，在业务测试的时候，发现业务测试一直不通故障原因PTN 设备只能配置静态IP Tunnel，UNI 端口属性只支持透传模式，PW 报文的封装方式只能支持“以太模式”（即raw 模式），所以配置E-Line 业务时，UNI 侧端口不能配置对应的“VLANs”处理步骤重新配置E-Line 业务，选择透传模式，即不配置“VLANs案例总结“PW 类型”可以为“以太模式”和“以太Tag 模式”。“以太模式”：用户报文中原有的C/SVlan Tag 原封不动地被封装进PW，透传到下游站点。以太Tag 模式”：用户报文中再添加一层Vlan Tag,目录,PTN 故障定位方法PTN 常见故障处理DCN故障处理MPLS Tunnel故障处理PW 故障处理CES 业务故障处理以太网业务故障处理时钟故障处理,Page 34,时钟故障处理,故障现象 时钟问题包括时钟源无法跟踪，时钟源丢失、时钟信号劣化等现象,故障处理方法步骤1：如果当前交叉板没有告警检查这个源是不是当前协议最应该选择的时钟源确认非SSM协议（disables1）时，是不是优先级最高确认标准SSM协议(standards1)时，是不是质量最高的源扩展SSM协议(expands1)时，是不是给它配置了ID是否设置了递减倒换，如果是则无法倒换到高优先级的时钟源。步骤2：是否有SYN_BAD告警源频偏过大，无法跟踪，频偏过大经常是由于时钟自锁引起的，请检查组网情况步骤3：是否有SYNC_LOCKOFF告警说明时钟源被锁定，无法跟踪，请查看该时钟源是否在锁定列表中，如果在，需要将其解除锁定。步骤4：是否有SYNC_F_M_SWITCH告警说明当前使用了外部人工/强制倒换命令，这时需要清除倒换可以触发重新选源。,Page 35,时钟故障处理案例,案例-网元时钟互锁造成所有Node B时钟频偏过大 故障现象：PTN 1900网元NE01上连接的所有Node B都上报告警，指示时钟频偏过大。处理步骤步骤1:因为NE01未上报任何告警，但是与NE01连接的所有Node B都上报时钟频偏过大告警，推测NE01的时钟配置错误。步骤2:查询网元时钟源优先级表”，发现网元NE01跟踪6槽位EFG2单板上光口一的线路时钟，网元NE02跟踪7槽位EFG1上光口一的线路时钟，而这两个光口是直接对接的。结果两个网元时钟跟踪形成互锁，时钟质量劣化，导致Node B上报时钟频偏过大告警。步骤3:按照网元规划表，修改NE01的时钟源配置后，故障解决。,
