PTN运行维护资料

PTN运行维护篇

目 录

1.1 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.2

网络故障处理基本思路和方法 ......................................................................................3 PTN与MSTP告警对比 ·····························································································3 常见告警故障处理方法 ······························································································5 以太网业务丢包类故障处理方法 ··············································································7 OAM/PING调试法 ······································································································7 环回逐段定位法 ········································································································10 PTN网络例行监控........................................................................................................ 11

1.1 网络故障处理基本思路和方法

PTN的组网、业务配置愈发复杂，需分组厂商网管尽快做好SDH－Like功能。为尽快恢复业务，将检测的故障点最小化，需了解SDH原理、IP网络原理知识、告警信号流及告警产生机理、PTN设备和网管基本操作、常用仪表的基本操作，了解网络拓扑，业务配置，设备运行状态。

? 告警、性能分析法 ? OAM/PING调试法 ? 环回法

PTN对于Tunnel的故障可用MPLS OAM来检测，MPLS OAM包括CV/FFD、Ping和Traceroute。通过CV（Connectivity Verification）/FFD（Fast Failure Detection）检测可以检测LSP的连通性。CV检测和FFD检测的过程基本一致，其不同在于CV检测发送CV报文的频率固定为1帧/s并且不可设置，而FFD检测发送FFD报文的频率是可以自行定义的。MPLS Ping/Traceroute为用户提供了发现LSP错误、并及时定位失效节点的机制。MPLS Ping/Traceroute使用MPLS Echo Request和MPLS Echo Reply检测LSP的可用性。MPLS Echo Request中携带需要检测的FEC（Forwarding Equivalence Class）信息，和其他属于此FEC的报文一样沿LSP发送，从而实现对LSP的检测。

为了更好的理解PTN，我们就把PTN与熟悉的SDH的业务层面告警类比一下，与大家共享。

1.1.1 PTN与MSTP告警对比

对应于业务模型，PTN的告警分为物理层、数据链路层、Tunnel层、PW层、仿真业务层五个层次。对应SDH的物理层、再生段复用段层、服务层、路径层。上层功能的实现依赖于相邻下层提供的服务。低层与高层同时有故障产生时，低层故障的消除是处理高层故障的基础，物理层故障引发的告警屏蔽其它层故障引发的告警。SDH的告警与PTN的最根本的区别在于SDH的告警都是由字节承载上报的，而PTN告警则是由协议控制上报的；但都有其相似之处,如下图：

E1/E3 净荷 路径层 (LO-VC1服务层 (HO-VC4再生段复用段层物理层 (Fiber) SDH ? TE/PE之间的净荷传送 ?净荷封装到对应的 Line/Tunnel 层 ?通过物理层或数据链路层提供净荷路径的传送 ?多元的LO-VC到HO-VC 或者 PWs到PSN tunnels ?STM-N 帧格式或以太报文通过物理介质传送 ?物理层以光或电脉冲的方式处理传送 CES/ATM/Ethernet

净荷 PW&业务层 Tunnel层 数据链路 (Ethern物理层 (Fiber) PTN

图28 PTN网络与MSTP告警对比图 业务模型中，PW可类比VC12、Tunnel类比VC4管道，CES即电路仿真业务就是传统的E1；告警可划分为业务类告警，系列类通用类告警，下面表格按业务告警，与SDH进行类比，各业务层告警对比： MSTP告警 业务层（VC12）TU_AIS (ETH/CES/IMAT_ALOS /ATM) UP_E1_AIS DOWN_E1_AIS等 SDH、PTN类比结果 继承了SDH E1、ATM、IMA业务告警的特点 PTN告警 PW_DOWN T_A LOS TU_AIS_VC12 UP_E1_AIS DOWN_E1_AIS等 MPLS_TUNNEL_LOCV HP_SLM HP_UNEQ PW&业务层 (ETH/CES/IMA/ATM) 服务层（VC4） HP_SLM 继承了服务HP_UNEQ 层SDH告警，新增加了MPLS Tunnel类告警 再生段复用段B1、B2误码检测 继承了SHD误告警 码类，复用段层 复用段告警 类告警(线(开销) IMA业务告警 性)，增加了多协议标签交换(MPLS)告警，LAG类告警 物理层(单板 R_LOS 物理层告警/ ETH端口/SDHETH_LOS 与SDH相同，端口/ E1口) T_ALOS 完全继承了LASER_MOD_ERR SDH光口、ETHETH_LINK_DOWN 电口、光口的习惯 Tunnel层(Tunnel/ PW / MPLS APS) B1、B2误码检测 线性复用段告警 IMA业务告警 LAG_DOWN MP_DOWN ETH_APS_LOST ETH_APS_PATH_MISMATCH ETH_APS_SWITCH_FAIL ETH_CFM_MISMERGE R_LOS ETH_LOS T_ALOS LASER_MOD_ERR ETH_LINK_DOWN 数据链路层(MLPPP / STM / LAG) 物理层(单板/ ETH端/SDH端口/E1口)

1.1.2 常见告警故障处理方法

? CES业务常见告警故障处理方法： 序号 1 告警名称 T_ALOS UP_E1_AIS DOWN_E1_AIS 产生原因 E1信号丢失，主要上报在支路接口板上； 分别是上行2M信号指示、和下行2M信号指示，产生原因和SDH的相同 处理方法 环回E1 察看对端是否有TU_LOP_VC12、T_ALOS 或2 TU_AIS_VC12 告警。或者E1环回方式 MPLS_TUNNEL_LOCV MPLS_TUNNEL_LOCV 为Tunnel 原因1：物理链路故障。1. 在连通性丢失告警。连续3 个周期网管上检查该链路两端网元内没有收到希望的CV/FFD 报文是否存在单板或光模块相关时出现此告警。产生 g该告警的告警。若存在，消除这些时，该TUNNEL承载的业务已中告警，查看告警是否消除。断， 2. 若告警未消除，查看光纤原因1：往往是下层网络异常引是否故障，更换故障的光纤。起，例如物理链路故障等，光模原因2：网络出现严重拥塞。3 块故障 1. 选择较大的“CC 测试发原因2：网络出现严重的拥塞。 送周期”的参数值，具体操作见本文的创建维护联盟。2. 检查故障Tunnel 的带宽占用情况，如发现已满，请增大Tunnel 带宽配置或消除非法发送大数据量的根源，查看告警是否消除。 TU_AIS_VC12 系统中存在更高阶的告警，如按照产生原因点，逐步排除；R_LOS、R_LOF、HP_SLM、AU_AIS 先看是否有高级别的R_LOS、上游站点存在硬件故障告警 R_LOF、HP_SLM、AU_AIS 告4 交叉板故障 警，然后看是否存在硬件故对端站对应通道失效 障支路板？交叉？最后对端对应通道？需要用到经验法、替换法等。与SDH类似 业务中断类常见告警原因：光纤、电缆故障、环境温度、误操作设置了光路的环回、误操作更改、保护业务配置数据有误。应急处理时优先恢复业务，排除外部设备的问题，将业务倒换到备用通道，复位单板、单站重启、重新下发配置等。

? 以太网业务常见告警故障处理方法： 序号 告警名称 产生原因 以太网端口连接丢失，可能原因：以太网端口的电缆或光纤没有连接好；电缆或光纤故障；本端网元接收光功率过低；单板故障。 MAC_FCS_EXC 为MAC 层检测到误码越限告警。软件定时检测MAC 芯片接收字节数和误处理方法 属于物理层故障类，察看物理连接，端口、单板故障；逐一排除。 1:检测是否链路出现故障，维护光纤或网线，查看告警是否消除。 1 ETH_LOS 2 MAC_FCS_EXC

码字节数，计算误码是否超过门限，超过设置越限门限发出此报警。 3 ETH_LINK_DOWN 以太网连接错误，端口协商失败；可能原因：端口模式不一致；电缆光纤连接故障；单板故障。 端口接收流量超限告警；可能原因为实际接收的端口流量大于设定的端口流量限值。 2:若告警仍未消除，检测是否存在DOS 攻击等，隔离DOS 攻击源，查看告警是否消除。 3.若告警仍未消除，是否出现配置环路或物理等问题，解除环路，查看告警是否消除。 对应需要察看和排除端口协商问题，主要关注端口模式，端口速率级别。最后使用替换法检验是否是硬件故障 4 FLOW_OVER 增加端口带宽。 丢包类故障常见原因：光功率问题、环境温度、数据业务端口协商故障、时钟配置错误、业务流控配置。可通过查看光功率、RMON、丢包率等性能事件解决。

? MPLS保护倒换类告警排除：

倒换告警 ETH_APS_TYPE_MISMATCH 告警信息 故障原因 ETH_APS_PATH_MISMATCH 保护类型信息不1、两端配置的1+1或1:1模式不一致； 一致 2、两端配置的单端或双端倒换的模式不一致； 3、两端配置的恢复式或非恢复式的模式不一致； APS工作、保护路1、保护组两端设备配置的工作路径、保护路径不一致 径不一致； 2、物理链路上存在有错连； 保护倒换失败 APS帧丢失 1、倒换失败； 1、对方没有配置保护； 2、保护通道业务中断； ETH_APS_SWITCH_FAIL ETH_APS_LOST

1.1.3 以太网业务丢包类故障处理方法

业务丢包、错包的可能原因

? 端口光功率异常或光功率不稳定，这是最常见的丢包原因 ? 时钟未跟踪，或跟踪源不稳定，会导致周期性丢包

? Tunnel下一跳端口IP设置错误（如设置为本端端口，扩容或调整业务时）可能

会导致丢包

? 网络侧发生拥塞，由于现网基本是轻载状态，拥塞可能性较小 排查业务丢包、错包的思路：

? 找出与“有问题的业务”走相近链路的业务，看是否有类似问题，以此缩小范围

业务A

网元A 网元C 网元B 网元D 网元E 业务B

如果业务A有丢包，业务B不丢，则问题应该在网元A与网元C之间

1.1.4 OAM/PING调试法

常用场景：数据业务通断判断

维护中，工作难点主要在于如何能够快速有效地排除故障。在众多的故障中，以“业务不通”最为常见。应该如何着手解决呢？首先我们将PTN专线业务做成下图所示的分段。 PTN网络关于OAM的规划主要涉及：MPLS OAM、以太网端口的OAM。适用于故障定位到单站，主要用于检查网络连接是否可达，以及分析网络什么地方发生了故障。

? 常用OAM排障步骤1—Tunnel OAM

PW配置 Tunnel配置 透传设备 (PTN,波分设备等) PW配置

NODEB 接入侧PTN UNI 接入侧PTN NNI 核心侧PTN NNI 核心侧PTN UNI RNC 业务配置 业务配置

红色标识部分是维护关键区域, 因为这一区域的网元多,外部因素多(光缆,光模块,波分设备等) , 需考虑业务扩容，业务归属关系调整 排障的主要工具: Tunnel OAM

使用方法：到两侧(接入侧、核心侧)网元查看Tunnel OAM状态 结果分析：

? 两侧Tunnel OAM状态都是“远、近端可用” ----- 该区域基本没有问题 ? Tunnel OAM检测有任何缺陷上报----- 根据“LSP缺陷位置”可锁定故障位置 ? 查MPLS_TUNNEL_LOCV告警: 含义:Tunnel链路中断 解决措施：需要检查

Tunnel链路的连通性，发起LSP Ping确认故障节点/链路，并观察Tunnel链路中其它节点的相关告警信息，需启动OAM功能。

? 排障步骤2—LSP故障位置分析

红框内的LSP缺陷位置指示了问题网元的LSR ID (GCP NODE ID) 在LSP缺陷位置及相邻网元范围内, 进一步排障步骤: 检查光纤原因 检查业务告警

? ETH_LINK_DOWN, ETH_LOS, R_LOS等链路异常告警 ? IN_PWR_ABN等光功率异常告警

? HARD_BAD、BUS_ERR、BD STATUS等硬件异常告警

检查配置

? 源\\宿节点是否正确

? 相邻网元的出\\入标签是否一致 ? 下一条端口IP是否正确 其它可能原因：

? 源\\宿节点是否正确

? 相邻网元的出\\入标签是否一致 ? 下一条端口IP是否正确

查看各端口收光功率的当前/历史性能是否过低或过高：

? 有可能端口收光功率接近但未超过阈值，导致无告警上报，所以需要查性能 ? 有可能端口收光功率不稳定，导致当前性能值正常，所以需要查历史性能 ? 下一条端口IP是否正确 查看各NNI端口的设置：

ETH OAM的简易操作步骤:

A.两端网元发起LB测试，用于命令触发的连通性检查，对以太网业务执行不中断业务环回检测（LB），可以检验业务的连通性情况，以便定位和修复故障。

注：只须输入对端UNI端口MAC地址就可以启动测试了，其他参数可用默认

OAM功能产生的告警概览： MELS OAM MPLS_TUNNEL_LOCV告警 含义:Tunnel链路中断 解决措施：需要检查Tunnel链路的连通性，发起LSP Ping确认故障节点/链路，并观察Tunnel链路中其它节点的相关告警信息。 MPLS 状态 Init(初始)状态 Ingress端没有使能OAM或者Tunnel链路中断； Available(可用)状态 Tunnel状态正常； Unavailable(不可用)Tunnel状态不可用，需要检查Tunnel链路的连通状态 性，发起LSP Ping确认故障节点/链路，并观察Tunnel链路中其它节点的相关告警信息 ETH OAM ETH_CFM_LOC告警 含义:ETH业务中断 解决措施：需要发起ETH LB进行故障确认，发起LT进行故障定位；对于MPLS承载的ETH业务，需要观察MPLS Tunnel的连通性。 ETH_CFM_RDI告警 含义:对端检测到ETH业务的告警后的回告指示 解决措施：需要在对端进行告警确认和排查操作； ETH_EFM_DF告警 含义：ETH链路发现失败 解决措施：检查两端的ETH Link OAM的配置是否一致，检查ETH链路的连通性； ETH_EFM_EVENT告警 含义: ETH链路存在误码 解决措施:对端网元检测到端口有误码，需要在对端网元确认其接收链路是否正常； 1.1.5 环回逐段定位法

常用场景：CES业务、SDH业务出现故障时，在支路或线路环回，定位故障原因到单站，环回操作会导致业务中断。仅在SDH类业务使用；注意：数据类定位的方法，为避免环回造成的网络风暴，使用ETH OAM功能，维护过程中不使用环回。

SDH 接口在维护中使用内环回和外环回。 PDH 接口使用内环回和外环回两种环回方式。

网管中环回界面与SDH近似。

1.2 PTN网络例行监控

网络维护工程师在维护PTN网络时，比MSTP网络更关注RMON性能等数据 T2000网管上日常维护项目表： 维护责任人 网管操作员 维护地点 网管中心 维护项目 检查网元和单板状态 浏览全网告警 浏览异常事件 浏览当前性能 浏览RMON统计组性能 检查光接口的光功率 浏览历史性能 浏览RMON历史性能 备份T2000的MO数据 备份网元数据库 备份网元数据库：PTN网络在面对灾难性故障时，单主控板失效、数据库损坏等故障时，快速恢复业务方法是数据库下载恢复。网管数据库备份工具中，可设置定期任务，自动定期上载网元数据库到网管电脑中。另外在每次大业务量配置（包括单站配置以及全网配置）修改后，都要进行一次网元数据库的备份操作，保证备份数据库最大限度的与网元一致。

周期 每天 每天 每天 每天 每天 每天 每周 每周（端口流量统计、端口丢包、业务流统计） 每周 每周 备件单板更换：SDH设备的备件单板，需定期拿出来，随现网进行升级更新，而PTN的单板，插入到子架中，能够自动向主控软件包申请，更新自身的单板软件，节省了备件单板维护的工作。

本文来源：https://www.bwwdw.com/article/v0xd.html