ONU环路故障排除案例.doc

环路故障排错案例
刘颐-401
l 概述：
一、网络拓扑结构
二、现场情况
三、故障处理流程
四、总结

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 TABLE
Destination LL Address Flags Refcnt Use Interface
---------------------------------------------------------------------
20.23.38.254 00:23:89:a4:04:02 0x8405 1 228 sc2
192.168.1.1 00:1a:69:01:36:68 0x8405 1 27363 fei1
192.168.1.2 00:1a:69:01:36:7e 0x8405 0 58927 fei1
192.168.1.3 00:1a:69:01:36:74 0x8405 0 109134 fei1
192.168.1.4 00:1a:69:01:36:88 0x8405 0 22536 fei1

anfang(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.S1]display mac-address
MAC ADDR VLAN ID STATE PORT INDEX AGING TIME(s)
0090-e829-9ee1 499 Learned Ethernet1/0/23 AGING
0090-e829-9ec1 499 Learned Ethernet1/0/23 AGING
0090-e829-9fa1 499 Learned Ethernet1/0/23 AGING
0090-e829-9f8d 499 Learned Ethernet1/0/23 AGING
0090-e829-9f89 499 Learned Ethernet1/0/23 AGING
0023-89a4-0402 499 Learned GigabitEthernet1/1/1 AGING
3456-7987-0098 1 Learned Ethernet1/0/18 AGING
0090-e829-0351 499 Learned Ethernet1/0/23 AGING
0090-e829-a0d5 499 Learned Ethernet1/0/23 AGING
0090-e829-a0d9 499 Learned Ethernet1/0/23 AGING
0090-e829-a0ef 499 Learned Ethernet1/0/23 AGING
可以看到，物理端口及MAC的学习均没问题。故障还未定位，此时继续登录路由器查看ARP表
GigabitEthernet1/1/1 上联路由器接口
Ethernet1/0/23 下联OLT接口
499 业务VLAN
4） 登录路由器查看ARP表:
D-SD-LY-NFB.R1]display arp vpn-instance VPN-PW
Type: S-Static D-Dynamic A-Authorized
IP Address MAC Address VLAN ID Interface Aging Type
20.23.38.250 00aa-bb11-2201 N/A GE0/0.499 18 D
20.23.38.249 000c-53a8-b361 N/A GE0/0.499 16 D
20.23.38.34 0090-e829-9ee1 N/A GE0/0.499 1 D
20.23.38.22 0090-e829-a0d9 N/A GE0/0.499 13 D
20.23.38.23 0090-e829-0351 N/A GE0/0.499 7 D
20.23.38.56 0090-e829-a129 N/A GE0/0.499 8 D
20.23.38.51 0090-e829-9dfb N/A GE0/0.499 10 D
注意：20.23.38.250 OLT带内地址
00aa-bb11-2201 OLT带内MAC
ARP默认老化时间是20分钟，但是在实际查看情况来看arp中标黄的项目在刷了几次ARP表后自动老化后，重新学习的速度比较慢，可以确定，应该是路由器与交换机连接的端口学习MAC产生了滞后情况。因为时间问题，当时就没有过多的观察其他MAC的学习情况，其他MAC为终端设备MAC。继续返回交换机，再次查看MAC表。
(小编补充：以后建议手动修改ARP老化时间表，快速老化，定位速度要快的多)
5） 再次查看交换机MAC表：（这次修改了mac的老化时间，将默认的300秒改成10秒）
D-SD-LY-NFB.S1]display mac-address
MAC ADDR VLAN ID STATE PORT INDEX AGING TIME(s)
3456-7987-0098 499 Learned Ethernet1/0/18 AGING
0023-89a4-0402 199 Learned GigabitEthernet1/1/1 AGING
0090-e829-9ee1 499 Learned Ethernet1/0/23 AGING
00aa-bb11-2201 499 Learned Ethernet1/0/23 AGING
0090-e829-9dfb 499 Learned Ethernet1/0/23 AGING
0023-89a4-0402 499 Learned GigabitEthernet1/1/1 AGING
0090-e829-0351 499 Learned Ethernet1/0/23 AGING
0023-89a4-0402 299 Learned GigabitEthernet1/1/1 AGING
0023-89a4-0402 10 Learned GigabitEthernet1/1/1 AGING

--- 12 mac address(es) found ---
[D-SD-LY-NFB.S1]display mac-address
MAC ADDR VLAN ID STATE PORT INDEX AGING TIME(s)
3456-7987-0098 499 Learned Ethernet1/0/18 AGING
0023-89a4-0402 199 Learned GigabitEthernet1/1/1 AGING
0090-e829-9ee1 499 Learned Ethernet1/0/23 AGING
00aa-bb11-2201 499 Learned Ethernet1/0/23 AGING
0090-e829-9dfb 499 Learned Ethernet1/0/23 AGING
0023-89a4-0402 499 Learned Ethernet1/0/23 AGING
0090-e829-0351 499 Learned Ethernet1/0/23 AGING
0090-e829-a0d9 499 Learned Ethernet1/0/23 AGING
0090-e829-a0ef 499 Learned Ethernet1/0/23 AGING
0023-89a4-0402 299 Learned GigabitEthernet1/1/1 AGING
0023-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 Counter
Name (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表项。仔细观察，凡是表项有抖动，抓包有重复的帧（如果做了镜像抓包，注意肯定会有一个复制包误导大家，注意排除）的情况。大体上跟环路有关，排错的时候逐级排错便能找到故障位置。
工程中，如果设备在线长期运行，那么关闭、重启设备或单板是不能在白天操作的。建议与局方协商时间集中处理比较安妥。