案例26： 某小区98幢IPTV卡顿现象的处理
某98幢用户反映IPTV卡顿，98#为电口交换机，通过95#2单元光口交换机接入园区交换机，园区交换机为千兆上行。
LAN交换机接入的IPTV用户反映卡片的现象，可能的障碍原因如下：
1.上联、级联端口匹配模式
2.用户端口双工模式
3.级联端口和级联线问题
4.环路问题
5.园区交换机中继带宽不足或者城域网中继带宽不足
6.交换机硬件问题
1. 首先检查园区中继流量如图
由图可见：该小区峰值流量为91.64M，中继带宽为1G，中继利用率<10%,排除中继拥塞的可能性；
2. 于晚间忙时查看95#2单元交换机到园区交换机之间的中继流量为12M,楼道到园区交换机的中继带宽为100M,中继利用率为12%，处于轻载状态，故排除楼道到园区交换机的中继拥塞的可能性；
3. 查看从园区交换机到98#用户端口之间经过的所有级联口，发现各级联口均工作在百兆全双工，无错误包。但用户上联的98#交换机的11口存在大量aborts错误包，端口速率模式为速率强制10M，双工模式自适应为全双工。怀疑此端口与用户端设备适配有问题，将此端口工作模式改为速率自适应、双工模式自适应后，端口适配成百兆全双工，但回访用户仍有卡顿现象，排除交换机端口适配问题的可能性；
4. 远程登录到园区交换机中，使用1024字节的大包ping95#2单元的光口交换机，发现有明显的丢包现象，因端口工作模式已核实无误，所以怀疑是交换机和光转片老化造成。将园区交换机和95#2单元上联光转片更换后，仍存在丢包现象，故排除交换机硬件故障的可能性；
5. 查看95#2单元光口交换机的log日志（display logbuffer），发现该交换机的24口存在环路告警，怀疑交换机用户端口存在环路（loopback exist in port 24/vlan X），造成广播风暴，导致交换机出现丢包的现象。将24口shutdown后，再用1024字节的大包ping95#2单元的光口交换机，不再出现丢包的现象，回访用户得知IPTV不再出现卡顿的现象，至此该障碍处理完毕。
附：排查环路的方法
1. 是否存在环路的初步判断：
（1）查看交换机log日志，看是否有环路告警；
（2）查看交换机cpu利用率（display cpu），若发现cpu利用率持续维持在80%以上，则因环路造成了广播风暴的可能性很大；
（3）查看交换机用户端口广播包数量是否快速增长，若增长很快则有可能存在广播风暴；
以此障碍为例，查看交换机log日志，发现24口存在环路告警，对于提示某端口下存在环路告警的情况，处理如下：
（1）若此端口为级联口，则将下联交换机所有用户线拔掉，仅留级联线，然后逐个将用户线重新插上，同时实时刷新上联交换机的log，若插上某个端口后环路告警重新出现，则重点检查该端口所联用户端接线是否存在环路或者因网线连接错误导致该端口在交换机上产生自环；
（2）若此端口为用户口，则除了检查用户端接线情况外，还要注意用户端电脑是否中毒，有些病毒会仿冒网关或者DNS（displayarp发现网关对应的端口是某个用户端口或主交换下联口），造成其他用户数据包发向该用户端口而非上联口，从而导致网络瘫痪；
还有一种就是此障碍的现象，此端口并未连接任何线路，则有可能是端口内部硬件故障导致端口自环，此时可以将该端口shutdown，确认障碍解决后将交换机更换，以防止因误操作又将坏端口打开导致障碍重复出现。
案例27： E8-C用户无法正常通话
2011年4月15日有E8-C用户电话申告无法正常做主被叫。现场测试，做主叫,有时无法注册,重启一下E8-C终端后可以重新拨打电话。做被叫有时能振铃；有时主叫听回铃音,被叫不振铃;有时主叫听不到任何声音。
1、查看设备版本已升级至最新
2、确认E8-C终端无硬件故障
3、确认用户线无问题
4、检查是否正常注册到软交换
5、检查注册消息以及呼叫消息是否正常
1、确认设备版本已升级至最新
2、确认设备无硬件故障
3、在软交换上跟踪设备注册消息与呼叫消息发现异常
4、更换物理号码故障消失，同时发现老物理号仍在上报注册消息
5、定位故障在老物理号的使用问题上，分析E8-C终端是经过SBC注册到软交换的，于是在SBC上通过用户物理号码查到终端的MAC地址，再从MAC地址查到是从东苑烽火OLT设备注册上来的，询问维护人员得知是前期安装的秀水山庄的一个FTTH用户，询问用户，用户号码已被停机，但用户终端仍然在线。
6、E8-C终端通过OLT至SBC向软交换注册，因此在OLT上删除此物理号码注册数据，将物理号码换回，故障消失。
总结：E8-C用户目前是新业务，要深入学习E8-C终端与软交换的SIP信令通信原理。E8-C用户拆机后，终端应及时收回，且删除OLT设备上的配置数据。
案例28： FTTH用户经常电话不通
2011年3月30日用户申告FTTH承载的电话时好时坏，并且每次早上必须重启很多次才能恢复正常，但有时候也有重启无效的情况。
1、用户设备吊死
2、用户数据下发不成功
3、PON下用户线路衰耗过大
4、上联设备OLTPON问题
1、确认用户设备无硬件故障
2、确认用户线路光衰耗正常
3、确实不是由于同一PON下各用户之间光衰耗差异过大造成的故障现象
4、在同一PON下继续新装用户发现故障现象转移到新安装的ont id偏后的设备上
5、在OLT上行口镜像抓包。ONT正常上线，ONT的语音Wan口向BRAS发起DHCP请求过程以获取ip信息；BRAS向ONT的语音Wan口发ARP探测报文，ONT立即应答；确认BRAS在持续发送ARP探测报文，但一段时间（3*30s）中未接收到ONT的应答报文；ONT在一段时间后向BRAS的ip地址发起ARP请求报文，BRAS未响应。
6、通过以上分析和抓包数据，确认语音业务不通的原因。ONT正常上线，ONT的语音Wan口向BRAS发起DHCP请求，并正确获取ip地址等信息；由于光路原因导致ONT下线。OLT侧记录了ONT下线原因是Lofi和Loami告警；与此同时，BRAS向ONT的语音Wan口持续发送ARP探测报文，但一段时间（3*30s）中未接收到ONT的应答报文。BRAS将此语音Wan口记录删除；当光路稳定后，ONT再次上线。ONT向BRAS的ip地址发起ARP请求报文，BRAS认为是非法用户未响应。
7、确认导致ONT上线过程由于Lofi告警下线的原因。OLT分析认为，此问题是在大量ONT上线过程中，OLT的DBA分配或者ONT响应OLT带宽分配的问题；在验证环境中，修改带宽为FIX类型（如下）后，问题依旧出现。确认问题不是OLT的DBA带宽计算及分配问题导致；在验证环境中接入光分析仪器，分析确认了问题原因。在OLT的最大带宽利用率模式下，当OLT跨帧下发ONT的带宽配置后，WTD光模块的ONT按配置的Burst时间上线时，会因为OLT检测到Lofi和Loami告警而被OLT踢下线。
8、解决方案：1）OLT带宽下发模式多帧模式改单帧模式，即最小时延模式；2）OLT Gap-time 从目前的32byte改成160byte，不需要OLT重启。但OLT重启后配置丢失
总结：FTTH技术主要是基于光纤，在FTTH工程的施工中更注意光路上的衰耗。当然此类故障也并非都由光纤造成的，要多注意终端设备和OLT等可能引起的故障。
案例29： ADSL用户因MAC地址冲突造成上网掉线及拨号错误“676”
用户上网经常掉线，且再次拨号上网时，出现错误代码676（电话占线）而无法上网。
1、电脑主机是否正常
2、线路是否正常
3、调制解调器是否正常
4、机房设备是否正常
5、数据问题
1、测试线路正常。
2、换猫测试，发现还是正常。
3、 更换设备端口现象还是存在。其他用户没有此现象。
4、 更换电脑测试发现正常，但是此电脑带到电脑公司测试也是正常的。电脑系统应该没有问题。
5、 数据检查正常，不存在接入数不足的问题。
6、 怀疑网卡MAC地址在同一Double VLAN内有冲突，在BRAS内检查后发现的确存在此问题，建议用户更换网卡或更改网卡MAC地址后问题解决。
总结：用户掉线后再次拨号出现代码“676”时，除了接入数过小、线路质量不好引起掉线，然后短时间内多次拨号。出现此现象和电脑系统自身问题外，还有可能是用户电脑MAC地址与同一Double VLAN内其他用户的MAC地址冲突的造成。
案例30： IPTV用户同时上网和看IPTV卡
IPTV用户，是通过DSLAM上联的用户，反映同时上网和看IPTV时，看IPTV很卡。
1、DSLAM设备版本补丁是否正常
2、DSLAM端口网速是否正常
3、下挂用户线路是否正常
4、外部接地和电源是否正常
5、上行光路是否正常
1、DSLAM版本全市统一，均正常。
2、DSLAM用户端口网速是正常，为4M，线路质量可以承载8M。
3、DSLAM设备上联端口正常。上行光路故障没有问题。
4、通过更换另一路电压为220V的电源，故障现象消失。
5、通过用户长时间观察，发现下雨后第二天开始出现问题。此时察看线路质量明显不好，判断为线路故障。对多接头处查找，发现有个接头处不好，处理后线路质量可达8M，业务恢复。
总结：用户断话时如果不是放忙音或无音时，基本和设备上层信令没有太大关系，建议查看设备现场环境。
