典型故障处理方法汇总版zhwfangWord格式文档下载.docx
《典型故障处理方法汇总版zhwfangWord格式文档下载.docx》由会员分享，可在线阅读，更多相关《典型故障处理方法汇总版zhwfangWord格式文档下载.docx（11页珍藏版）》请在冰豆网上搜索。
【现象描述】
端点用户名为AG58900,07ONU（R3.07.05.56），需要开通呼叫转接功能，
软交换平台数据已做，用户在进行呼叫转接时，拨完*57*后有拨号音，继续输入转接号码时出现忙音。
【处理过程】
1、通过命令行查看明确匹配及上报功能，确认没有打开；
查看命令：
Config\protocol#shdig
Notifymatcheddigitwithtypeunambiguous:
disable
Notifymatcheddigitdelay:
255
2、通过抓包分析软交换下发数图，发现数图定义不标准，如下图：
在红框表示的数图中规定为[EF][0-9][0-9E].[EF]，表示前三位接受相关拨号后，第四位如果输入“*”（E表示*）或者“#”（F表示#），都表示拨号结束，将立即上报所拨的号码，则IAD收到“*57*”后就把号码上报给软交换平台了，如下图：
这样就造成拨号没有结束就上报了号码，导致转接不成功。
3、和软交换平台协商，把数图改为[EF][0-9][0-9E].F后问题解决。
【故障分析】
数图的定义不符合标准。
由于某些软交换是这样配置的，故我公司后期软件也将更改可以符合这种不标准的数图。
【相关资料】
二、未知包引起语音断断续续故障处理
三、关于07型ONU出现的误摘挂机的情况说明
最近在几个省份陆续出现了07型ONU在下挂智能电话或是较高级的其他类型的电话是出现误摘机的现象。
1.主要现象如下：
主叫正常，被叫时振铃一声就自动断掉了。
换成别的话机就是正常的。
出故障时从抓包来看在振铃0.6s后，出现了al/on的挂机信号如下图
在5.3s时ONU上报摘机，但5.9s却自动上报了挂机。
之间只有0.6s的时间，明显不是人为挂机。
（MGCP协议也有类似的情况）
2.原因分析：
出现故障的话机一般为智能话机或功能较多的高级话机。
此类话机工作时所需要的电流主要来自两个方面，一是本身自带的电池或电源，二会从电话线上取得一部分电流。
这样问题就出现了。
正常情况下，在用户没摘机的情况下，电话线上是没有电流的。
但出故障的高级电话，由于自身工作的需要会从电话线上取得部分电流，而此时在电话没有摘机的情况下，电话线上却有了电流，于是我们的onu根据线路上有了电流这一点判断认为用户已经摘机，故放了al/of摘机信号，但此时电话实际是没有摘机的，属于误判摘机，所以响一声就断了。
3.解决方法：
研发提供了升级包，主要是提高了ONU对摘机的判断门限。
目前主要针对故障07onu进行升级解决，正式软件3月20日之前将释放，等待软件正式释放后再大面积升级。
四、关于北京清河局OLT2_4003外层VLAN用户拨号676错误报告
1、现象描述
1月18日清河局第二框AN5116－02设备出现所有外层vlan为4003的用户，PPPOE拨号均返回676错误的问题。
2、分析过程
Ø
仅外层vlan为4003的用户受到影响；
经过查看主交换盘的mac地址表发现vid为4003的BRASmac地址学习到了槽位端口上，导致所有外层vlan为4003的，目的mac地址为BRAS的单播数据流发送目的地错误；
怀疑是用户家外接网络发生环路或者用户电脑中毒，通过查看onumac地址表的方式找到了发生问题的用户端口，确定用户；
后发现用户家ONU下挂路由器的两个端口用网线连接形成环路导致下行方向BRAS发出的报文又环回到设备，进一步引起系统mac地址学习发生错误。
解决用户外接环路后，业务回复正常。
4、解决办法
最终解决方案：
建议通过配置远端onu过滤规则的方式解决该问题。
操作步骤如下：
用户仅需操作第一步。
第一步：
在网管上配置过滤规则，过滤规则为源mac地址等于BRASmac地址（如果有多个BRAS需要配置多条）；
第二步：
设备收到配置后会自动对当前所有在线onu进行配置，所有从用户侧端口收到的源mac地址为BRASmac地址的数据包均被丢弃；
第三步：
对于以后上电的onu或者以后新增的onu，系统会在该onu上电注册后自动将过滤规则下发。
临时解决方案：
对于FTTHonu可以配置用户端口绑定解决该问题，配置方式为：
源mac地址不等于BRASmac地址的数据包允许通过。
5、时间进度
解决该问题需要升级主控盘软件和EC2pon业务板卡软件（onu软件不需升级），按照目前正规的工程问题解决，发布流程，初步计划在二季度末正式释放解决该问题的版本。
五、同一个PON口下15型ONU上联EUP2盘引起其它15ONU传真的问题
【网络拓扑】
某运营商EPON工程反应有一端OLT的EC2盘同一个PON口下带的四端15ONU，有三端15ONU同时出现传真业务失败，但是语音业务正常，一端15ONU传真业务正常。
现场人员检查15ONU的PON光功率正常。
同时更换了EC2盘，以及1：
8的光分路器，故障仍然无法解决。
现场人员在发送传真失败时，同时在EC2盘抓包，发现RTP流中最大有1.8%的丢包。
如下：
在传真业务正常的15ONU的上联口抓包发现没有丢包，同一个PON口下，一个15ONU传真正常，三个15ONU传真不正常，同时在OLT的上联盘GE3口建一个语音业务VLAN，端口设置为UNTAG，将PC电脑的IP设成与15ONU的AC16IP同一个网段，在上联口用PC去PING15ONU的AC16IP，现场传真正常的15ONU的IP为10.37.111.6，另外三端15ONU的IP分别为10.37.111.2,10.37.111.3,10.37.111.4。
将本机电脑IP设置为10.37.111.253,这时电脑去PING10.37.111.2发现有丢包，如下：
同时PING10.37.111.3,和10.37.111.4都有丢包。
但是PING10.37.111.6的ONU，此时发现没有丢包。
通过以上测试说明传真业务失败与丢包有关系，而且丢包就在PON内，从EC2盘PON口到15ONU的PON口之间有丢包，首先定位到是EC2盘问题，于是更换了EC2盘后再测试传真，仍然是传真业务正常的15ONU仍然正常，传真业务不正常的15ONU仍然不正常。
于是再更换光分路器继续测试，故障现象依旧，于是在1：
8的分路器上将15ONU的光纤分别断开进行测试，当断开传真业务正常的15ONU时（10.37.111.6）,在从PC去PING10.37.111.2,和10.37.111.3,10.37.111.4的15ONU都没有丢包。
在10.37.111.3的15ONU上发传真业务测试发现业务正常,在另外两个15ONU上测试传真业务也是正常的。
于是定位到10.37.111.6的15ONU上联盘EPU2盘问题,将该EPU2盘更换后,再测试四个15ONU的传真业务都是正常。
通过该15ONU传真问题的处理，发现该问题一般与丢包有关系，首先通过抓包分析是否有丢包，可以在上联口抓包，查看是否上联有丢包，如果有丢包需要查看上连通道部分。
包括从上联口经过的交换机，或者是上联光纤收发器的工作模式，排除工作模式不对引起语音上联通道丢包。
另外在EC2盘或15ONU抓包，查看是否PON内有丢包，如果有丢包再分析是光功率不正常引起，还是其它原因引起。
首先排除PON内的丢包才能解决传真问题。
本案例中的传真故障就是由于PON内的丢包造成的，由于同一个PON口下某一个15ONU的上联盘故障引起其他15ONU的丢包，该15ONU的EPU2盘光模块为海信模块，分析可能由于光模块器件原因，光反射太强影响其它ONU的链路正常工作，语音业务由于对丢包不敏感，但是传真业务对与丢包是很敏感。
网管技术问题
一、ANM2000在Win2003SP2上运行间歇服务中断问题说明
问题描述
在测试中发现ANM2000网管装在Windows2003SP2操作系统运行后，偶尔出现操作时间过长或操作返回超时的情况。
问题原因
经分析ANServer的日志D:
\AEMS\md\log\log[date].log文件，可以看到ANServer与Manager间的连接会间歇性被重置。
这是因为Windows2003SP2中新增了一个功能特性：
接收端调节功能（Receive-sideScaling），这一功能在兼容性上还存在问题。
在操作系统为WindowsServer2003SP2的服务器上，可能会出现TCP连接重置的故障。
解决方法
针对这个问题，可以通过禁止接收端调节功能来解决，具体操作过程为：
1）.单击开始，单击运行，键入regedit，然后单击确定。
2）.依次进入并单击以下注册表子项：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
3）.在Parameters项下寻找EnableRSS名称。
如果不存在，在空白处单击右键，指向新建，单击DWORD值，然后键入EnableRSS。
4）.双击EnableRSS，键入0，然后单击确定。
5）.重新启动计算机更改EnableRSS值。
二、网管配置过大导入不成功处理方法
用ostat–l命令查看数据库的逻辑日志数，如果数目小于20，则需要通过onparams-a-drootdbs-s2000命令来添加逻辑日志的条目数（每次执行此命令会添加一条逻辑日志，请多次执行此操作），直到逻辑日志条目数大于20条再导入。
三、网管内存过大导致数据库服务无法启动案例
某EPON工程需替换使用一台超级服务器，16G内存，由于出厂网管版本不符现网要求，本地办事处升级新网管至5.07.04.36SP1，重启后无法informix数据库进程无法启动。
1登录后首先进行常规查询：
检查数据库网卡优先级、IP、环境变量、登录用户管理权限等均符合设置要求；
2在ol_otnm3078命令行环境下中检查数据库服务状况：
D:
\AEMS\md\bin>
onstat提示sharedmemorynotinitializedforINFORMIXSERVER'
ol_otnm3078'
4按照提示报错信息检查C:
\Informix\etc目录下数据库配置文件ONCONFIG.ol_otnm3078中共享内存参数项：
#SharedMemoryParameters
LOCKS2000#Maximumnumberoflocks
BUFFERS1073152#Maximumnumberofsharedbuffers
NUMAIOVPS1#NumberofIOvps
PHYSBUFF32#Physicallogbuffersize（Kbytes）
LOGBUFF32#Logicallogbuffersize（Kbytes）
CLEANERS2#Numberofbuffercleaner
SHMBASE0xC000000L#Sharedmemorybaseaddress
SHMVIRTSIZE65536#initialvirtualsharedmemorysegmentsize
SHMADD16384#Sizeofnewsharedmemorysegments（Kbytes）
SHMTOTAL0#Totalsharedmemory（Kbytes）.0=>
unlimited
CKPTINTVL300#Checkpointinterval（insec）
LRUS8#NumberofLRUqueues
LRU_MAX_DIRTY60#LRUpercentdirtybegincleaninglimit
LRU_MIN_DIRTY50#LRUpercentdirtyendcleaninglimit
TXTIMEOUT300#Transactiontimeout（insec）
STACKSIZE64#Stacksize（Kbytes）
由于默认该最大buffers值按服务器硬件内存大小的25％分配，
1073152×
4096b（需乘以4Kb）＝4395630592b为4G内存
而informxi最大管理内存不能超过1G，故造成数据库服务无法启动。
按照512m计算512x1024x1024/4096=131072
修改BUFFERS131072#Maximumnumberofsharedbuffers
10重新启动数据库服务ol_otnm3078，正常，依次启动网管dbserver、manager、snoope等服务，登录网管ok。
【故障分析】本例中需要注意几点：
1、informxi最大管理内存不能超过1G；
2、此buffers值设置的内存缓存大小对应windows任务管理器中进程“oninit”占用的内存大小；
3、为什么升级网管后不重启时各服务均正常？
因为当时虽然重新创建了数据空间，修改了配置文件，但若不重启数据库服务或重启电脑时是不会生效的。
升级会员 