ONU环路故障排除案例.doc

环路故障排错案例刘颐-401l 概述：一、网络拓扑结构二、现场情况三、故障处理流程四、总结l 内容介绍一、网络拓扑结构1） 每个变电站的拓扑结构均相同，业务划分由路由器完成，每个路由器将将此次自能网改造业务流划分到VLAN 499中通过VPN安全隧道汇聚到主站服务中。每个变电站网段均不相同，变电站之间设备均不能互访。2） 主网默认情况下使用老的SDH网，路由器业务传输上联使用STM-12 2M的数据网，现计划改造成路由器业务传输上联使用100M 数据网，改善上联瓶颈问题。3） 默认情况下，如果没有PTN设备，业务走SDH网络，如果有PTN设备，业务走PTN网络。两个网络形成冗余备份，提供保护。4） 我司C8000属于接入层设备，按要求创建VLAN 499 过交换机trunk模式走业务流。另外VLAN 1000走PTN形成局域网走OLT管理流。5）二、现场情况设备联调过程中发现终端设备向上通信质量较差，通过ping发现有比较明显的丢包过程。经过多次验证及长ping发现确实有丢包现象，丢包率在60%以上。三、故障处理流程1） 逐级ping初步定位故障点终端ping - olt ping- 交换机ping - 路由器ping 通过ping发现，从路由器向上ping 丢包率为0 ,从交换机及OLT向上ping均丢包率在 60%以上。初步定为故障点在变电站。2） 远程登录OLT查看ARP表及MAC表nanfang(config)# show arp info LINK LEVEL ARP TABLEDestination LL Address Flags Refcnt Use Interface-20.23.38.254 00:23:89:a4:04:02 0x8405 1 228 sc2192.168.1.1 00:1a:69:01:36:68 0x8405 1 27363 fei1192.168.1.2 00:1a:69:01:36:7e 0x8405 0 58927 fei1192.168.1.3 00:1a:69:01:36:74 0x8405 0 109134 fei1192.168.1.4 00:1a:69:01:36:88 0x8405 0 22536 fei1anfang(config)# show mac-addr vlan 499 Index MacAddr VLAN State Dest-port- 1 00:90:e8:29:05:23 499 dynamic 2/4 2 00:90:e8:29:9f:8d 499 dynamic 2/2 3 00:90:e8:29:a0:d9 499 dynamic 1/4 4 00:90:e8:29:a0:ef 499 dynamic 3/2 5 00:23:89:a4:04:02 499 dynamic 12/1 6 00:90:e8:29:05:77 499 dynamic 2/2 7 00:90:e8:29:9e:e1 499 dynamic 2/1注意：00:23:89:a4:04:02 这个MAC地址，这个地址是路由器的上联接口MAC。20.23.38.254 这个IP地址是路由器接口地址。表中显示均正常。OLT设备二层学习没有问题，ARP解析也正确。继续查看交换机mac表，再次排查故障问题。3） 远程登录H3C的交换机上查看H3C交换机的MAC表：D-SD-LY-NFB.S1display mac-address MAC ADDR VLAN ID STATE PORT INDEX AGING TIME(s)0090-e829-9ee1 499 Learned Ethernet1/0/23 AGING0090-e829-9ec1 499 Learned Ethernet1/0/23 AGING0090-e829-9fa1 499 Learned Ethernet1/0/23 AGING0090-e829-9f8d 499 Learned Ethernet1/0/23 AGING0090-e829-9f89 499 Learned Ethernet1/0/23 AGING0023-89a4-0402 499 Learned GigabitEthernet1/1/1 AGING3456-7987-0098 1 Learned Ethernet1/0/18 AGING0090-e829-0351 499 Learned Ethernet1/0/23 AGING0090-e829-a0d5 499 Learned Ethernet1/0/23 AGING0090-e829-a0d9 499 Learned Ethernet1/0/23 AGING0090-e829-a0ef 499 Learned Ethernet1/0/23 AGING可以看到，物理端口及MAC的学习均没问题。故障还未定位，此时继续登录路由器查看ARP表GigabitEthernet1/1/1 上联路由器接口Ethernet1/0/23 下联OLT接口499 业务VLAN4） 登录路由器查看ARP表:D-SD-LY-NFB.R1display arp vpn-instance VPN-PW Type: S-Static D-Dynamic A-AuthorizedIP Address MAC Address VLAN ID Interface Aging Type20.23.38.250 00aa-bb11-2201 N/A GE0/0.499 18 D20.23.38.249 000c-53a8-b361 N/A GE0/0.499 16 D20.23.38.34 0090-e829-9ee1 N/A GE0/0.499 1 D20.23.38.22 0090-e829-a0d9 N/A GE0/0.499 13 D20.23.38.23 0090-e829-0351 N/A GE0/0.499 7 D20.23.38.56 0090-e829-a129 N/A GE0/0.499 8 D20.23.38.51 0090-e829-9dfb N/A GE0/0.499 10 D注意：20.23.38.250 OLT带内地址00aa-bb11-2201 OLT带内MACARP默认老化时间是20分钟，但是在实际查看情况来看arp中标黄的项目在刷了几次ARP表后自动老化后，重新学习的速度比较慢，可以确定，应该是路由器与交换机连接的端口学习MAC产生了滞后情况。因为时间问题，当时就没有过多的观察其他MAC的学习情况，其他MAC为终端设备MAC。继续返回交换机，再次查看MAC表。(小编补充：以后建议手动修改ARP老化时间表，快速老化，定位速度要快的多)5） 再次查看交换机MAC表：（这次修改了mac的老化时间，将默认的300秒改成10秒）D-SD-LY-NFB.S1display mac-addressMAC ADDR VLAN ID STATE PORT INDEX AGING TIME(s)3456-7987-0098 499 Learned Ethernet1/0/18 AGING0023-89a4-0402 199 Learned GigabitEthernet1/1/1 AGING0090-e829-9ee1 499 Learned Ethernet1/0/23 AGING00aa-bb11-2201 499 Learned Ethernet1/0/23 AGING0090-e829-9dfb 499 Learned Ethernet1/0/23 AGING0023-89a4-0402 499 Learned GigabitEthernet1/1/1 AGING0090-e829-0351 499 Learned Ethernet1/0/23 AGING0023-89a4-0402 299 Learned GigabitEthernet1/1/1 AGING0023-89a4-0402 10 Learned GigabitEthernet1/1/1 AGING - 12 mac address(es) found - D-SD-LY-NFB.S1display mac-addressMAC ADDR VLAN ID STATE PORT INDEX AGING TIME(s)3456-7987-0098 499 Learned Ethernet1/0/18 AGING0023-89a4-0402 199 Learned GigabitEthernet1/1/1 AGING0090-e829-9ee1 499 Learned Ethernet1/0/23 AGING00aa-bb11-2201 499 Learned Ethernet1/0/23 AGING0090-e829-9dfb 499 Learned Ethernet1/0/23 AGING0023-89a4-0402 499 Learned Ethernet1/0/23 AGING0090-e829-0351 499 Learned Ethernet1/0/23 AGING0090-e829-a0d9 499 Learned Ethernet1/0/23 AGING0090-e829-a0ef 499 Learned Ethernet1/0/23 AGING0023-89a4-0402 299 Learned GigabitEthernet1/1/1 AGING0023-89a4-0402 10 Learned GigabitEthernet1/1/1 AGING从mac表中我们发现 0023-89a4-0402 这个MAC地址在端口上发生了抖动。但是刷新了很长时间，只有此mac地址发生了抖动，其他地址均无抖动产生。可以初步定位有环路产生或是ARP攻击。但是此环路产生的mac表抖动情况很奇怪，因为如果是交换机有环路，那么所有的MAC地址都会抖动，而不是一个MAC地址。需要继续排查。6） 单独拿跟网线连交换机上，配置交换接口后直接用PC ping主站服务器。此时也有丢包情况产生，丢包率在60%以上。为了排除OLT原因，将OLT上联交换机网线拔掉后，发现ping正常，未发现丢包。那么此时可以确定，应该是OLT或下联设备有环路或ARP攻击。7） 抓包分析在交换机的下联OLT接口做镜像，对入方向数据包抓包分析。发现有路由器发送的ARP数据包返回。但是无法确认到底是OLT产生环路还是ONU。开启OLT的RSTP功能后ping依然丢包。（当然，其中我也更换过单板、槽位、重启过设备。后来想了一下，这些步骤确实有些多余。建议在软件方面没有查清楚前，建议不要动硬件。）8） 关闭所有PON口激光器。继续ping主站服务器，发现丢包率为0。可以确定应该是OLT以下的故障问题。逐步开启PON口的激光发射器，并持续Ping主机服务器。发现当开启某个pon口后，出现丢包。9） 查看此PON口下注册上来的ONU，并逐步解注册ONU，持续ping。当解注册某台ONU后，发现ping不丢包。10） 远程登录ONU发现ONU其他端口上接收到大量报文需要到现场查看此端口是否有物理环路连接。11） 故障复现情况因解注册ONU后，ONU会重启。重启后ping正常，长时间跟踪后均再未发生丢包。抵达故障点现场，均未发现有物理环路连接。登录设备后查看数据报文接收情况，又表现正常。Switch Port CounterName (1)Value (2)Value (3)Value (4)Value RxGoodBytes 1036484 0 0 0 RxBadBytes 0 0 0 0 TxFCSErr 0 0 0 0 RxUnicasts 14561 0 0 0 TxDeferred 0 0 0 0 RxBroadcasts 0 0 0 0 RxMulticasts 0 0 0 0 64Octets 0 0 0 0 127Octets 0 0 0 0 255Octets 0 0 0 0 511Octets 0 0 0 0 1023Octets 0 0 0 0 maxOctets 0 0 0 0 TxGoodBytes 10797290 0 0 0 TxUnicasts 8854 0 0 0 TxExcessive 0 0 0 0 TxMulticasts 0 0 0 0 TxBroadcasts 157928 0 0 0 TxSingle 0 0 0 0 TxPause 0 0 0 0 RxPause 0 0 0 0 TxMultiple 0 0 0 0 RxUndersize 0 0 0 0 RxFragments 0 0 0 0 RxOversize 0 0 0 0 RxJabber 0 0 0 0 四、总结此故障已经上报jira，有待公司验证复现故障。后期继续跟踪此故障，建议后期将软件版本升级最新版本。总结此次故障，其间走了很多弯路，浪费了很多时间，故障是硬件故障还是软件故障其实比较明显了。不管故障是否彻底解决了，但是这里给大家了一个对于ONU下环路现象的排错思路，其实我司设备是一个典型的二层设备，对于通信的要点无非就是arp表与mac表项。仔细观察，凡是表项有抖动，抓包有重复的帧（如果做了镜像抓包，注意肯定会有一个复制包误导大家，注意排除）的情况。大体上跟环路有关，排错的时候逐级排错便能找到故障位置。工程中，如果设备在线长期运行，那么关闭、重启设备或单板是不能在白天操作的。建议与局方协商时间集中处理比较安妥。