案例6：华为AG用户呼叫等待业务只有一声提示音故障的处理

华为AG设备割接后，用户2076261申告呼叫等待功能不能使用，联系用户拨打测试确定故障准确现象是：当第三方电话打入时，用户话机能听到一声“迪”的声音，不能确定此声音是否是呼叫等待音。

根据故障现象判断有两个可能原因：1，用户数据不正确。2，AG设备侧问题。因此先检查用户数据是否已设置呼叫等待功能；再确认设置是否已生效，可以跟踪信令确认；若确认设置已生效，则可确定故障在AG设备侧，再检查AG数据配置。

1， 检查HLR上用户数据配置正确。

2， 在SS上跟踪H248信令，当第三方电话呼入时，软交换已将呼叫等待信令送至AG侧，说明在软交换侧此功能是正常的。

3， 检查AG数据配置。

软交换设备是中兴公司的ZXSS10B，华为AG与中兴软交换之间关于呼叫等待功能的对接参数有三个：

查询控制点编号49是缺省设置，值为1，即呼叫等待音播放次数是1，查询结果如下：

BB_ DWT_UA5000>enable

BB_ DWT_UA5000#config

BB_ DWT_UA5000(config)#diagnose

BB_ DWT _UA5000(diagnose)%%displayprofile profile-index 1 item-index49

-----------------------------------------------------------------------------

Profile Index:  1

 ProfileName:ZTE_normal("ZTE_normal/1")

-----------------------------------------------------------------------------

Item          Value

-----------------------------------------------------------------------------

 49            1

 -----------------------------------------------------------------------------

根据用户以前使用习惯修改该参数为10：

BB_DWT_UA5000(diagnose)%%profile modify 1 item-index item-index49 10

配置完成后重启h.248接口使其生效：

BB_DWT_UA5000(config)#interface h2480

BB_DWT_UA5000(config-if-h248-0)#reset coldstart

4， 修改参数后与用户测试正常，故障排除。 

总结：AG、IAD等接入层设备较简单，像新业务方面故障大多是数据配置或参数设置问题，对此类障碍应积极联系厂家支撑处理。

       案例7： IPTV用户无法连接故障分析

用户申告宽带上网正常但是IPTV不能观看，每次输入帐号密码后重启都会提示重新设置.

1、用户机顶盒故障

2、机顶盒设置问题

3、账号密码故障

1、首先处理硬件故障，和线务员沟通现场更换用户机顶盒，发现原故障仍存在，排除硬件设备问题。

2、因为用户家可以上网排除了网络连接问题。

3、在联创中查询用户登录详情显示用户名输入错误，指导用户进行重新设置结果仍不好。

4、登录中兴业务平台查看用户信息，根据联创查询的机顶盒帐号在业务平台中进行查询结果显示该帐号不存在。

5、重新在平台上注册用户信息后再次指导用户进行设置注册后观看正常。

总结：因为接触IPTV方面的故障不是很多因此遇到该故障有盲目不知所措，IPTV故障多数是因为机顶盒故障导致，就怀疑到硬件故障问题，排除硬件因为在联创中查到了用户的操作信息就想当然的认为用户帐号没问题，只是有可能用户操作不慎导致，而最终的处理结果证明了我们的想当然是错误的，处理故障是很需要细心的，不能用自己的主观臆断来处理，这样会影响处理效率，以上这个简单的故障就是一个很好的例子，也是一个很好的教训。

           案例8：电源电压不稳导致用户断话

 MA5620E下挂话务台用户每天上午9点至11点 ，下午1点至2点，出现用户频繁断话现象。用户断话后听电流音，而不是忙音或无音，且端口随机出现。

1、设备版本补丁是否正常

2、用户呼叫信令是否正常

3、下挂用户线路是否正常

4、外部接地和电源是否正常

5、上行光路是否正常

1、在设备上跟踪用户呼叫流程信令，均正常。

2、查看外部电源供电，使用电表测试供电电压为230V，（设备正常工作电压为110V－240V）。当出现用户断话现象时，电压出现10V以上的增压，现场测试电源供电电压高于240V。

3、定位是由于外部供电线路上有使用大功率电器导致电压波动较大，而且语音业务对电流和电压非常敏感，最终引起设备语音业务异常。

4、通过更换另一路电压为220V的电源，故障现象消失。

总结：用户断话时如果不是放忙音或无音时，基本和设备上层信令没有太大关系，建议查看设备现场环境。

       案例9： DSP资源耗尽导致AG语音全阻故障

某AG局华为UA5000设备语音全阻，AG下所有用户摘机忙音，被叫对方提示“您拨打的用户忙”，数据业务正常。

1、设备供电不正常；

2、网络接口故障
    3、业务单板运行不正常
    4、端口外线短路导致DSP芯片资源耗尽

1、怀疑AG由于掉电原因导致数据丢失。登录设备查看数据配置，确认所有数据配置都正常，因此排除数据丢失可能性。

2、网络接口故障。命令查看H248接口正常，排除AG到软交换网络没有问题，排除网络故障。

UA5000(config)#displayif-h248 all

 ----------------------------------------------------------------------------

接口标识传输方式接口状态 MG端口 MGIP地址  MGC端口 MGCIP地址/用?  

 ----------------------------------------------------------------------------

  0       ALF/UDP  正常     2944  10.28.199.117   2944    10.26.64.13   

 ----------------------------------------------------------------------------

3、业务单板运行不正常。登录设备查看所有单板运行正常，排除单板不正常原因。

UA5000(config-narrow-resource)#displayboard 0

 -------------------------------------------------------------------------

槽号板名称状态扣板0     扣板1     在线/离线

 -------------------------------------------------------------------------

  0    PWX2       正常

  1    PWX2       正常

  2    

  3    

  4    H601PVMD   备用正常  H602ETCM         

  5    H601PVMD   主用正常  H602ETCM         

  6    H601EP1A   正常

  7    

  8    A32        正常

  9    A32        正常

  10   A32        正常

  11    A32        正常

  12   A32        正常

  13   A32        正常

4、端口外线短路导致DSP芯片资源耗尽。查看告警信息，发现短时间内有大量的DSP资源分配不足告警。

UA5000(config)#displayalarm history all list

29865    2010-05-10 19:58:47      DSP资源分配不足告警

机架0; 槽位号:16; 端口号:30

  29864   2010-05-10 19:58:42      DSP资源分配不足告警

机架0; 槽位号:8; 端口号:2

  29863   2010-05-10 19:58:29      DSP资源分配不足告警

机架0; 槽位号:16; 端口号:30

  29862   2010-05-10 19:58:26      DSP资源分配不足告警

机架0; 槽位号:16; 端口号:30

  29861   2010-05-10 19:58:22      DSP资源分配不足告警

机架0; 槽位号:16; 端口号:30

  29859   2010-05-10 19:58:18      DSP资源分配不足告警

机架0; 槽位号:16; 端口号:30

  29858   2010-05-10 19:58:11      DSP资源分配不足告警

机架0; 槽位号:16; 端口号:30

  29857   2010-05-10 19:58:07      DSP资源分配不足告警

机架0; 槽位号:11; 端口号:19

  29856   2010-05-10 19:58:06      DSP资源分配不足告警

机架0; 槽位号:11; 端口号:19

  29855   2010-05-10 19:58:05      DSP资源分配不足告警

机架0; 槽位号:11; 端口号:19

  29854   2010-05-10 19:58:04      DSP资源分配不足告警

机架0; 槽位号:11; 端口号:19

  29853   2010-05-10 19:58:03      DSP资源分配不足告警

机架0; 槽位号:16; 端口号:30

  29852   2010-05-10 19:58:03      DSP资源分配不足告警

机架0; 槽位号:8; 端口号:2

  29851   2010-05-10 19:58:01      DSP资源分配不足告警

机架0; 槽位号:16; 端口号:30

  29850   2010-05-10 19:57:59      DSP资源分配不足告警

机架0; 槽位号:16; 端口号:30

  29849   2010-05-10 19:57:49      DSP资源分配不足告警

机架0; 槽位号:11; 端口号:19

  29848   2010-05-10 19:57:36      DSP资源分配不足告警

机架0; 槽位号:16; 端口号:19

  29847   2010-05-10 19:57:34      DSP资源分配不足告警

机架0; 槽位号:11; 端口号:15

  29845   2010-05-10 19:57:27      DSP资源分配不足告警

机架0; 槽位号:11; 端口号:18

  29844   2010-05-10 19:57:26      DSP资源分配不足告警

机架0; 槽位号:16; 端口号:19

  29843   2010-05-10 19:57:24      DSP资源分配不足告警

机架0; 槽位号:16; 端口号:30

  29842   2010-05-10 19:57:22      DSP资源分配不足告警

机架0; 槽位号:8; 端口号:2

5、查看设备有大量DSP资源分配不足告警，怀疑由此导致。经过咨询厂家，通过如下方法进行查询，确认DSP资源已经耗尽。DSP即语音编码通道资源，一块主控板64个通道，一个通道即是一个语音用户在线占用资源，$表示占用，0表示空闲。

UA5000(config)#narrowresource

UA5000(config-narrow-resource)#displaydsp state 0/4/0

{<cr>|startdspchannel<U><0,767> }: 

命令:

displaydspstate 0/4/0

 ------------------------------------------------------------------------------

  DSP通道号   DSP通道状态 0－空闲 $－占用为G.711通道 A－占用为全速率通道 W－消耗

          X－故障 @－IP 环回 *－PCM 环回  #－禁用

 ------------------------------------------------------------------------------

  0000-0049 $$$$$ $$$$$ $$$$$ $$$$$ $$$$$ $$$$$ $$$$$ $$$$$ $$$$$ $$$$$

  0050-0099 $$$$$ $$$$$ $$$$$

  ------------------------------------------------------------------------------

统计结果: 共查询 64 个DSP通道

其中 64 个空闲通道, 0 个占用为G.711通道, 0个占用为全速率通道, 0 个消耗通道, 0 个故障, 0 个IP环回, 0 个PCM环回, 0 个禁用

 ------------------------------------------------------------------------------

为什么会导致DSP资源耗尽？再次查看告警记录，发现部分端口告警非常多，怀疑是端口外线短路，导致频繁占用资源请求。通过外线测试，确认外线质量存在问题。

UA5000(config)#test

UA5000(config-test)#potsloop-line-test 0/16/19

{<cr>|busy<K> }:

命令:

potsloop-line-test 0/16/19

机?0 槽位 16 端口 19 ( 电话号码 4055275 MG接口号 0 终端标识号 A275 )

正在测试, 请稍?.....

测试端口  : 0/16/19

电话号码  : 4055275

  MG接口号  : 0

终端标识号: A275

 ------------------------------------------------------

测试项目结果

 ------------------------------------------------------

  A->地交流电压(伏特)              0.093          

  B->地交流电压(伏特)              0.094          

  A->B 交流电压(伏特)              0.001          

  A->地直流电压(伏特)             -0.632          

  B->地直流电压(伏特)             -0.210          

  A->B 直流电压(伏特)             -0.422          

  A->地绝缘电阻(欧姆)              8.562K         

  B->地绝缘电阻(欧姆)>10M

  A->B 绝缘电阻(欧姆)              2.316K         

  A->B 环阻    (欧姆)              4.467K         

  A->B反极性电阻(欧姆)              3.611K         

  A->地电容    (微法)              0.260          

  B->地电容    (微法)              0.039          

  A->B 电容    (微法)              0.036          

定性结论                          A线地气

 ------------------------------------------------------

通过测试告警中的端口外线，发现端口存在地气。

为解决问题，复位DSP扣板。方法如下：

UA5000(config)#diagnose

UA5000(diagnose)%%dspreset 0/4/0  //4槽位主控板上编号0的DSP扣板（每块主控板上有2个槽位可以安装DSP扣板，一般一块主控板只配一块DSP扣板）

{force<K>|gracenum<K>|gracetime<K> }:force

命令:

dsp reset0/4/0 force

复位DSP会对业务有影响,确实要复位DSP扣板?  (y/n)[n]: y 

复位后2分钟，查看DSP扣板，时隙都为空闲状态。测试业务正常。

displaydspstate 0/5/0

  ------------------------------------------------------------------------------

  DSP通道号   DSP通道状态 0－空闲 $－占用为G.711通道 A－占用为全速率通道 W－消耗

          X－故障 @－IP 环回 *－PCM 环回  #－禁用

 ------------------------------------------------------------------------------

  0000-0049 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000

  0050-0099 00000 00000 0000

 ------------------------------------------------------------------------------

总结：

以上问题是由于用户外线导致DSP口吊死资源耗尽，最终导致所有业务中断，通过复位DSP扣板恢复业务。经深入分析，复位DSP扣板只能临时恢复业务，最终彻底解决故障还需要将存在“地气”的端口问题解决。

碰到此类故障，有时感觉无从下手，但只要认真分析，逐步排查，仔细查看设备告警运行状态，还是能圆满解决。

       案例10： 华为MA5620E大面积脱网故障处理

某段时间内某本地网每天均有大量华为MA5620E出现2-5分钟短暂脱网。

组网情况：

网管产生告警如下：                                               

1.设备版本是否与网管不匹配

2.设备供电及上行光路是否稳定

3. 网管服务器是否正常

4.是否存在攻击

a)     通过现场检查多台设备，基本排除了版本和供电及上行光路存在问题的可能性。

b)      登陆设备查看运行记录，发现在EPON网管产生脱网告警时，设备并未重启。同时通过登陆OLT设备查看，未发现相关ONT离线告警，由此判断可能为其他原因导致。

qxy17#2(config)#displayversion

  MA5600V800R305 RELEASE SOFTWARE  PRODUCT MA5620E

  Copyright (c) Huawei Technologies Co., Ltd.1998-2008 All rights reserved

  Uptime is 5 day(s), 9 hour(s), 27 minute(s),54 second(s)

c)      在MA5620E现场通过镜像抓包发现，报文中有大量的snmp报文信息，地址源存在多个IP，报文结果如下，红色圈IP地址是攻击源地址，蓝色标识地址为某EPON网管地址。从报文中可以看出网管中绝大部份都是攻击查询snmp报文。

此时登录到设备查看主控板CPU占用率，发现占用率非常高，超过80%。CPU占用率很高，导致主机无法响应EPON网管发送的正常snmp查询状态消息，连续3次网管未收到MA5620E发送的查询报文，网管则产成脱网告警。

d)判断为报文攻击后，对攻击源IP进行统计，在BRAS上配置禁止攻击源地址所有报文策略，发现MA5620E设备再未收到异常地址的snmp查询报文，主机CPU占用率立即下降至20%左右。

经过观察，在配置策略后一段时间内未出现短暂脱网告警，但在第二天又出现了多台设备脱网，经过再次抓包发现依然有大量未知IP源snmp攻击，所以在BRAS上通过封堵IP方式不能彻底解决问题。

e)尝试在OLT部署ACL方式，具体步骤如下：

MA5680T首先将内层vlan跟MA5620E的管理vlan相同的所有报文全部拒绝

允许源地址为网管IP地址的报文通过（包括OLT下带各厂家DSLAM设备的网管IP地址）。

某EPON网管IP地址218.22.208.228，IP综合网管地址220.180.84.84，MA5680T上启用QinQ-vlan，OLT下挂接MA5620E和DSLAM管理vlan12、13，service-port通过配置QinQ-vlan实现管理业务。

具体配置ACL策略方法如下：

  配置匹配内层VlanId为12(16进制0x0c)，13(16进制0x0d)，三层协议类型为UDP(0x11)，四层UDP目的端口号为161(0xa1)的规则，类型为deny

MA5600T(config)#acl5000

MA5600T(config-acl-user-5000)#rule1 deny 000c 0fff 18 11ff 31 00a1ffff 44 others

MA5600T(config-acl-user-5000)#rule2 deny 000d 0fff 18 11ff 31 00a1 ffff 44 others

配置源IP地址218.22.208.228（16进制DA16D0E4）和220.180.84.84（16进制0xDCB45454），类型为permit

MA5600T(config-acl-user-5000)#rule3 permit 000c 0fff 18 11 ff 31 DA16D0E4ffffffff 34 00a1 ffff 44others

MA5600T(config-acl-user-5000)#rule4 permit 000d 0fff 18 11 ff 31 DCB45454ffffffff 34 00a1 ffff 44others 

将ACL应用到MA5680T的宽带上行端口：

MA5600T(config)#packet-filterinbound user-group 5000 port 0/20/0

查看acl和端口应用数据配置

MA5600T(config)#displayacl 5000

User ACL  5000, 4 rules

Acl's step is 5

rule 1 deny 000c 0fff18 11 ff 31 00a1 ffff 44 others

rule2 deny 000d 0fff 1811 ff 31 00a1 ffff 44 others

rule3 permit 000c 0fff18 11 ff 31 DA16D0E4 ffffffff 34 00a1ffff 44 others

rule4 permit 000d 0fff18 11 ff 31 DCB45454 ffffffff 34 00a1ffff 44 others

MA5600T(config)#displaypacket-filter all

{<cr>|to-cpu<K> }:

  Command:

display packet-filterall

inboundAcl 5000 rule 1port 0/20/0   running

inboundAcl 5000 rule 2port 0/20/0   running

inboundAcl 5000 rule 3port 0/20/0   running

inboundAcl 5000 rule 4port 0/20/0   running

OLT部署ACL后，故障未再发生。

总结

Internet公网中存在着大量的不确认因素，网络随时有遭受攻击的可能，提前预防则是避免问题的有效方式。MA5620E设备如果配置公网IP地址，虽然维护方便，但容易遭受网络攻击。Snmp报文攻击方式比较少见，对后期网络安全维护提出了预警。目前某电信在OLT上部署ACL防snmp攻击策略，经观察能有效解决MA5620E遭受到snmp攻击，同时网管业务不受ACL影响，ACL策略起到应有的效果。针对带有大量公网设备的OLT，应提前部署ACL，防止类似问题再次发生。