ETH专线丢包异常类问题定位指导上课讲义.ppt

2020 3 7 ETH专线丢包异常类问题定位指导 目录 原理介绍丢包定位丢包定位示意图典型案例信息采集 Page3 原理介绍 PTN 城市1 城市2 在之间添加VLAN 添加tunnel的标签和pw的标签 剥标签 剥VLAN 还原用户报文 设备将用户侧特定端口或者特定端口中特定VLAN的报文 送到网络侧的某个端口或者某个PW上 实现用户数据的点到点透传 PW Page4 丢包定位流程 Page5 丢包定位流程 如果已确定网元NNI侧TUNNEL PW发生丢包 可继续检查以下内容 1 端口的ARP学习地址是否发生修改 2 端口的工作模式是否匹配 如果模式速率不一致可能会丢包 3 端口的配置是否约束产生丢包 4 单板 光纤 光纤模块是否有问题 5 处理板是否复位过 6 TUNNEL Pw和端口的MTU是否设置不对 如果已确定网元UNI发生丢包 可继续检查以下内容 1 检查业务 UNI端口MTU是否设置不对 2 利用端口性能统计检查是否有异常帧或出错帧 3 检查UNI端口是否linkdown过 4 端口的工作模式是否匹配 如果模式速率不一致可能会丢包 Page6 丢包定位流程示意图 PTN1 PTN2 PTN3 PTN4 PTN5 如图所示 PTN1至PTN5建立远程专线业务 PTN1为ingresss节点 PTN5为egress节点 其他为透传节点 丢包定位流程如下 查看PTN3收发计数差别特别大 就是在它这里丢包啦 告警 告警 步骤1 检查网管告警信息 利用告警信息定位问题故障 比如 1 MPLS 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告警 检查流量是否超过端口带宽 8 检查ETH是否有ETH CFM CSCL ETHCRCALI告警 检查网络是否拥塞 光模块质量 链路硬件故障 如果从告警无法定位问题 那么要用性能统计来定位 先确定此处是大量丢包还是少量丢包呢 查看各节点TNL PW性能统计 如果是大量丢包 ingresss egress 步骤2 从ingress节点到中间节点最后到egress节点 分别查看它们TNL PW性能统计 检查收发包是否相差比较大 如果某个NNI收发计数差别大 可认为丢包发生在此网元端口上 既然已经知道这个网元NNITNL PW出现丢包了 继续检查是否因带宽受限而丢包 还是ARP地址被修改 或者MTU不匹配 按这样思路下去找到问题位置啦 如果是少量丢包 网络存在业务和协议报文 并且业务不可中断 对于少量丢包很难使用性能统计找出丢包位置 单纯从收发数量已不能确定是否丢包 PTN1有收到PTN2的响应报文并且数量相同 说明PTN1 PTN2之间的TNL PW路径是正常没有丢包哦 PTN1发PING报文给PTN3 一段时间后PTN1没有收到PTN3响应报文或者收到报文比发送的报文少 说明PTN2 PTN3之间TNL PW路径会丢包啦 既然已知道这个TNL Pw路径出现问题了 继续检查是否因带宽受限而丢包 还是ARP地址被修改 或者MTU不匹配 按这样思路下去找到问题位置啦 步骤4 如果以上步骤还是没有定位到丢包位置 那可以打开UNI性能统计和端口性能统计来查看是否有业务异常 比如UNI性能收发是不是相差特别大 如果是的话那丢包就发送在UNI侧 检查UNI侧端口性能统计 看看有没有校验错误帧或者其他异常帧 如果有的话 可能单板存在异常或者光纤链路出现问题啦 Page7 典型案例 一 问题现象 如下测试方案中 主通路以太专线业务丢包 X 1为主通道 X 2为保护路径 2路径上配置专线PW业务 查看路由器CX1统计 在主通道数据从3900 4到3900 1上测试1 微量丢包 倒换到保护路径不丢包 PTN3900 1129 10 39 1 PTN3900 4129 10 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 现象为少量丢包 从性能统计中无法看出具体在哪里丢包 使用OAMPING自定义包长来检查是否有丢包 步骤3 发现存在丢包现象 检查TNL PW带宽 MTU 检查ARP是否学习到 检查端口工作模式 检查配置等 检查后并没有发现问题 步骤4 打开3900 4NNI侧端口性能统计 检查是否有校验出错帧或异常帧 此时发现性能统计中出现一些校验出错的数据包 根据这个情况很有可能是端口和光纤路径出现问题 需要进一步检查单板 光纤模块及光纤线问题 步骤5 将光纤和光纤模块连接到保护通道测试未发现问题 排除光模块和光纤问题 更换3900 4EX2单板 丢包现象消失 说明丢包来自EX2单板 Page8 典型案例 二 问题现象 某地区现网突发大量丢包 而后恢复正常 PTN10036 PTN10023为工作tunnel 分析丢包原因 PTN10036 PTN10023 10GE 10GE 10GE POS PTN10035 PTN10024 工作TUNNEL 步骤1 查询网管当前告警和历史告警 发现在丢包问题出现之前一小段时间上报MPLS TUNNEL LOCV告警 步骤2 在网管上查询保护信息 发现该丢包的业务所在的TUNNEL配置了APS保护组 该保护组为可恢复式 步骤3 业务恢复后查询APS组状态 为工作在工作TUNNEL 通过告警我们知道MPLS TUNNEL LOCV会触发APS倒换 于是下一步需要确定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链路上 业务出现大量丢包 当MPLS TUNNEL LOCV告警清除后 可恢复式的APS保护组又自动把业务倒换回工作Tunnel 仍然走10GE端口 使得业务恢复正常 问题结论 添加路由约束条件 确保保护Tunnel必须经过10GE端口 保护TUNNEL Page9 典型案例 三 问题现象 XX运营商PTN设备与XX基站对接在近两个月期间70多台基站出现频繁掉话现象 技服称在某时间段内 在基站侧发送报文长度为1000字节 频率为35个 分钟的PING报文 共有3万多个报文 丢失9个报文 据此称是由于中间的PTN设备丢包导致了掉话问题频现 定位过程 1 检查历史告警 发现某期间几乎所有的站点均有发生Eth LOS的告警 比较集中在23 00以后 时间以10秒频率较高 怀疑是链路状态不好 2 对没有出现掉话和出现掉话频率低的站点进行分析 发现这些站点中物理接口也呈现多样性 不仅有ETH百兆电口 还有ETH百兆光口 而且这些站点多为室外站点 没有出现掉话的站点以ETH百兆光口居多 3 考虑到ETH百兆光口的工作模式只能是百兆全双工工作模式 而且在这种类型的端口计数中没有发现CRC校验错误报文 故而怀疑为端口工作模式不一致导致 4 检查基站端口工作模式 确认基站的ETH百兆电口工作模式全部设置为自协商模式 5 根据IEEE802 3的标准 如果端口工作模式为自协商 而对端端口工作模式为百兆全双工 此自协商端口的协商结果为百兆半双工 6 修改两个基站的端口工作模式为百兆全双工 无掉话现象 Page10 典