ONU环路故障排除案例

/环路故障排错案例刘颐—４01概述：一、网络拓扑结构二、现场情况三、故障处理流程四、总结内容介绍一、网络拓扑结构每个变电站的拓扑结构均相同，业务划分由路由器完成，每个路由器将将此次自能网改造业务流划分到VLAN４9９中通过VPN安全隧道汇聚到主站服务中。每个变电站网段均不相同,变电站之间设备均不能互访。主网默认情况下使用老的SDＨ网,路由器业务传输上联使用STM-1２２Ｍ的数据网,现计划改造成路由器业务传输上联使用10０M数据网，改善上联瓶颈问题.默认情况下,如果没有PTN设备,业务走ＳDH网络,如果有PTN设备，业务走PTN网络.两个网络形成冗余备份,提供保护。我司C8000属于接入层设备，按要求创建ＶLAN499过交换机tｒunk模式走业务流。另外ＶＬAＮ１00０走PTＮ形成局域网走ＯＬT管理流。二、现场情况设备联调过程中发现终端设备向上通信质量较差,通过ｐｉng发现有比较明显的丢包过程。经过多次验证及长ｐiｎｇ发现确实有丢包现象,丢包率在60％以上.三、故障处理流程逐级ping初步定位故障点终端ｐinｇ—-——ｏltpｉng—-—－－-交换机pｉng－－路由器ｐing通过ping发现,从路由器向上pｉng丢包率为0，从交换机及OLT向上ping均丢包率在60％以上。初步定为故障点在变电站.远程登录OLT查看ARＰ表及MＡC表nanfaｎg(confiｇ)＃showaｒpiｎfoLIＮKＬＥＶELＡＲPＴABＬEDeｓｔiｎaｔionLLAddressＦｌagsRefcntUseIntｅｒfａce--—－--－-－—-－－－-————-—-——－—－--－－—－-—--—--———－－—-－—-——--———－2０．23.3８.25４０0:2３：８9：a４：0４:02０x84０51228sc21９２.１68．1.１00：1ａ：69：0１:3６:680x8４05127３63fｅi1１９２。168。1．200：１a：６9：０1：3６:7e0x84０505８92７fｅi１１９2.1６8.1。3０0:1a：69：0１：3６：74０ｘ84050１0９１３4feｉ１19２.１68．１.40０:1a:69:0１:36:880x8405022536feｉ1anfaｎｇ（config）＃shoｗｍａc-addｒvlan４99ＩndeｘＭacAddrVLANＳtateDest-poｒt-—－－--—-－—-———-—-————-——--－－—－-—－－———-————————－——-————-——－-——-100:90:ｅ8:2９：05：２3499dynamｉｃ2/4200:９0:e8：２９：9ｆ：8d４99dynａｍic2/2300：90:e8:29：a０：ｄ9４99dynamic1／４40０：90：e8:2９:a0：ｅf4９9ｄynaｍｉc3/2500：23：８9：a4：04：02499dyｎａmic１2/１60０：９0：e8：29：05：7749９ｄynamｉc2／2700：９０：e8:29:9e:e１499dynamiｃ2/1注意：０0：2３:8９:ａ4:０4:02这个MAC地址，这个地址是路由器的上联接口MＡC。20．2３．38。2５4这个ＩP地址是路由器接口地址.表中显示均正常。OＬT设备二层学习没有问题,ARP解析也正确。继续查看交换机mac表,再次排查故障问题。远程登录H3C的交换机上〈建议跟局方提出申请后再登录,建议只查看，不要修改数据配置〉查看H3C交换机的MAC表:[D—ＳD-LY－NFＢ．Ｓ1］displaymａｃ－addreｓｓMACADDRVLANIDSTATEＰORTINDEＸＡGINGＴIＭＥ（s）0090-ｅ82９－9ee1499ＬearnedEthｅrnet1/０/23AＧING00９０—e829—9eｃ１４99LearnedEｔherneｔ1/０/23AGING0０90-e8２9-9fa1499LearnedEthernｅt1/0/23ＡGIＮＧ0０90-e829－9ｆ８d499ＬｅarnｅdEthｅrneｔ1/0/23ＡGING009０—e82９-9f8９499LｅarｎedEｔｈernet1/０/２３ＡGＩＮG00２3—８９ａ4-０4024９9LearｎedGigabiｔＥthｅｒnet1/1/１ＡGING3４56—79８7-009８1ＬeaｒｎedEthernet１/0／18AGING00９0—ｅ829-03５14９9LearｎｅdＥtherneｔ１/0／２3AGIＮG009０－e８29—a0ｄ５49９LｅarnｅdEthernet1/0／2３AGING00９0-ｅ82９—ａ0d9499ＬeａｒneｄEtｈerｎet1/0/23ＡＧING0０90-e829－ａ0eｆ499ＬｅarｎedEtheｒnet1/0／2３AＧＩNG可以看到，物理端口及MAC的学习均没问题.故障还未定位，此时继续登录路由器查看ARP表GｉｇａbitEｔｈernｅｔ1/1/1上联路由器接口Ｅtherｎet１／0/2３下联ＯLT接口４99业务ＶLAＮ登录路由器查看ＡRP表：Ｄ—ＳD-ＬY－ＮFＢ.R1］disｐｌａyarｐvpｎ—iｎsｔanceＶPN—PWType:S－StａｔｉcＤ—DｙnaｍｉcＡ—AuthoriｚedIＰAdｄｒesｓMACＡddrｅssＶLＡＮIＤInterfaceＡginｇTyｐe2０。23。３8．25００0aａ—bb１1—2２01N/ＡＧE0/0.49918Ｄ20．２3.38。249０００ｃ—53a8—ｂ３６１N／ＡGE０/0。49916D2０.2３.38。3400９0-e８29—９ee1N/AGE0/0.４9９１Ｄ２0.23.38。２２００90－ｅ829—a０d9N/AGE0/0。４９91３Ｄ20．２3。38.2３０090-ｅ８29-0351Ｎ/AGE０/０。4997Ｄ20。23.38.560090－ｅ82９－ａ129N/AGE0／０。4998D２0.２3。38.51０0９０－e829—9dfbN/AGE0/０.49９10D注意：20.23．38.２50OLT带内地址０0aａ－bb11－2201OLT带内MAＣARP默认老化时间是20分钟，但是在实际查看情况来看aｒｐ中标黄的项目在刷了几次ＡRＰ表后自动老化后，重新学习的速度比较慢,可以确定，应该是路由器与交换机连接的端口学习ＭAC产生了滞后情况。因为时间问题,当时就没有过多的观察其他MAC的学习情况，其他MAC为终端设备MAＣ。继续返回交换机，再次查看MAＣ表。（小编补充：以后建议手动修改AＲP老化时间表，快速老化,定位速度要快的多)再次查看交换机MAC表:（这次修改了mac的老化时间,将默认的300秒改成1０秒)D—ＳD-ＬY—ＮFB.S1]ｄisplaｙmac－addressMACADDRVLＡNIDＳＴATEPOＲTINDEＸAGIＮGＴIＭE（s）3456—798７-009８499LeaｒnedＥthernｅt1/0／18ＡGINＧ0０2３－89a4-０402１９9LearnedＧigabitEtherneｔ１/1/1AGING0０90—e８２９-9ee1499ＬeaｒｎedEthernet1／０/23AGIＮＧ0０aa—bb11—22０1499ＬeaｒnｅdＥtheｒnet1/0/23ＡGING0090-e８29-9dfb４9９LearnedEthernet1/0/２3AＧINＧ０0２3—8９a４—０4０２４99LeaｒneｄGigabitEｔhernet1／1/1AGIＮG0０90－e８29－035１499LearｎedEｔheｒnｅt1/０/2３ＡGＩNＧ０023-8９a4—0４02299LearneｄGigabｉtＥｔherｎet１/１/1AGING０023—89a4—04０２10ＬeaｒnedGiｇaｂitＥthｅrｎet１/1/1AGING－－-1２ｍacaddress（eｓ）fｏｕｎd--－［D—SD－LY—NＦB。S1］dｉｓplaｙｍａｃ—adｄreｓsMＡCADDＲVＬＡNＩDSＴATEＰＯＲTINDEXＡGINGＴＩＭE（s)３45６—79８７—00９８4９９LearnedEtheｒneｔ1／0／１8AGING002３—8９a4-０4０2１９9LｅarneｄGigabitEthernet1/1/1AＧING０0９0－ｅ８29-9ee14９9LearnedEtheｒnet1/0/2３AGING00aa－bb１1-２201４9９ＬearnｅdEｔhｅrnet１/０／23AGING0090－e82９-９dｆb499LｅaｒneｄＥｔhernet1/0/23ＡＧING０023-89a4-04０2４99LｅarneｄＥthｅrｎｅt1/0/23AGINＧ0090—e829-０３51４9９LｅarnedEthernｅt1/０／23ＡGIＮG００9０－e82９—a0ｄ9499LｅarneｄEtheｒnet1／0/2３AGING0０９０—e８2９-a0ｅｆ４99LeaｒnｅdEtheｒnet1／0／23AＧＩNG０023—8９ａ4－040229９LearneｄＧigabiｔEtｈeｒnet1/１/１AGING00２３－8９a4-０40２10LｅarｎｅdGigabiｔＥthernet1／1/1AGING从mac表中我们发现0023-89a4－0４０２这个MＡＣ地址在端口上发生了抖动。但是刷新了很长时间，只有此mａc地址发生了抖动，其他地址均无抖动产生。可以初步定位有环路产生或是ARP攻击.但是此环路产生的ｍac表抖动情况很奇怪,因为如果是交换机有环路，那么所有的MAC地址都会抖动,而不是一个ＭAＣ地址。需要继续排查。单独拿跟网线连交换机上,配置交换接口后直接用PCpiｎg主站服务器.此时也有丢包情况产生,丢包率在６0%以上。为了排除ＯLＴ原因,将ＯＬT上联交换机网线拔掉后,发现ｐinｇ正常，未发现丢包。那么此时可以确定，应该是ＯLＴ或下联设备有环路或AＲP攻击。抓包分析在交换机的下联OLT接口做镜像，对入方向数据包抓包分析。发现有路由器发送的ARP数据包返回。但是无法确认到底是ＯLＴ产生环路还是ONU。开启OＬT的RSTP功能后ping依然丢包。（当然,其中我也更换过单板、槽位、重启过设备。后来想了一下，这些步骤确实有些多余。建议在软件方面没有查清楚前，建议不要动硬件。)关闭所有PON口激光器.继续pinｇ主站服务器，发现丢包率为0。可以确定应该是OＬT以下的故障问题。逐步开启PON口的激光发射器,并持续Ｐing主机服务器.发现当开启某个pon口后，出现丢包。查看此PON口下注册上来的OＮU，并逐步解注册ＯNU，持续ping.当解注册某台ONU后,发现pinｇ不丢包。远程登录ONU发现ONU其他端口上接收到大量报文需要到现场查看此端口是否有物理环路连接。故障复现情况因解注册ＯNU后,ONU会重启。重启后pｉnｇ正常，长时间跟踪后均再未发生丢包.抵达故障点现场，均未发现有物理环路连接。登录设备后查看数据报文接收情况,又表现正常。SwiｔchＰortCouｎterNａｍe（1）Ｖaluｅ（2）Valuｅ（3)Valｕe(4)ＶalｕeRxGoｏdBytes1０364８4０00RｘＢadＢytｅｓ0000TxＦCSErr0000RｘUｎiｃasts1456１000TｘＤeferred０0００ＲxBroaｄｃasts000０RxＭｕｌtｉcａｓｔｓ０00064Octeｔｓ0００0127Ｏctｅtｓ00002５5Ocｔets０００05１1Ｏctets０0001０23Ｏctets000０maxOcｔｅｔs0000TxGooｄBytｅs10797290000ＴxUnicａｓts88５40００TｘExｃｅｓsｉve０000TxMｕｌticastｓ0０00ＴxBroaｄcasｔs1５7９28００0ＴxSｉngle0000TｘPaｕse0000