VOIP IP电话话吧故障处理

具体故障描述
用户反应每天到了高峰时间（18:00-20:30）电话会有几次摘机无声或者摘机盲音，每次持续几分钟到十几分钟不等，一段时间后会自动恢复，
三，故障排除过程
接到用户投诉后为了定位问题，从各个方面去排除一切可能，为了排除中继占用的问题要求网通增加了E1线路，但是E1线路增加了以后的二天的情况还是一样，没有任何改善，为了排除网络的问题在机房的server上装了solarwinds对网通的所有AG以及TG进行全天监控，又在投诉比较集中的几个超市蹲点对故障出现时的网络进行抓包分析，在监控中发现有些IP超市的AG每天会不定时的丢包，而且比较严重，经过检查发现是由于瑞士康达的光纤收发器的以太口跟AG的以太口自适应有问题，将AG的以太口改成强制百兆全双工后丢包现象基本消失，但是每天还是不定时的出现摘机无声以及摘机盲音，在监控中同样发现TCG也会不定时的丢包，由于通过命令行无法看到TCG的网口的状态，只能在半夜没有用户的情况下将TCG的以太口改成强制百兆全双工，但是改完后发现TCG的网口和cisco6506的网口同样处于百兆全双工的状态下无法UP ，只能将端口全部调回auto状态，在超市蹲点观察的过程中发现每次只要一出现摘机无声或者摘机盲音，此时PING 机房对应的TCG一定严重丢包，于是怀疑网络有问题，但是同时PING  TCG的网关以及同在一个网段的OAMserver却不丢包，在用户侧以及TCG侧抓包结果都显示丢包是由于TCG没有回包，由于高峰期丢包现象尤其严重，结合上述一些现象判断是由于TCG的网口丢包引起下端的IP超市摘机无声或者摘机盲音，而丢包时TCG的CPU占用率都在60%以上，故怀疑是由于下联的用户量太多数据量过大导致TCG的CPU处理能力不足导致丢包，于是将这一情况反馈给了研发，研发远程登陆到TCG上观察以后说TCG收到很多的非法的ICMP报文，怀疑有网络攻击，让网通的工程师配合查找，让网通的工程师在CISCO6506上将TCG以及OAM所在的端口全部MIRROR到一个端口抓包，并没有发现任何的来历不明的ICMP报文，过了两天杭州的一个研发到了苏州，我带着研发一起到苏州的一个IP超市看了高峰期丢包的现象，经过观察研发的判断基本相同，CPU处理能力不足引起丢包，到了这一步似乎进入了僵局，因为无法定位故障，如果定位原因是CPU处理能力不足就涉及到硬件的问题，那会是一个漫长的改进过程，对用户来说是不允许的，但是在一次检查的过程中研发发现TCG的CPU跟内部的lanswitch的数据交换有问题，经常出现lanswitch发送给TCG的数据量远远大于TCG发送给lanswitch的数据量，于是重新抓包分析，在分析的过程中发现在丢包的同时CPU收到很多语音包，而本来语音包是不应该由CPU来处理的，经过更进一步的抓包分析终于发现cisco6506在做ARP解析的时候用的MAC地址和转发数据时所填的MAC地址不一样，问题最终定位在cisco6506上，由于cisco6506上有两块主控板，回给TCG的ARP解析包里的MAC地址是xx.xx.xx.xx.xx.fc,而在转发数据的时候改写源MAC地址用的是xx.xx.xx.xx.xx.fd ,所以造成TCG里面的ARP表项老化以后，如果双方都没有发起ARP请求，就会在TCG内部的交换芯片上造成大量的广播，占用大量的CPU资源，最终导致PING TCG 出现丢包，经过网通的工程师在cisco6506上做了配置，定义了从TCG所在的VLAN转发的所有数据的MAC地址都修改成跟ARP请求所获得的一样的MAC地址，修改后故障排除，在机房观察了三天的时间，问题没有重现，相信已经解决，
四，结论，
在解决问题的过程中需要耐心更需要细心的观察分析，不要被表象所迷惑。