河南移动网络故障类优秀案例汇编
（版本V1.2）
中国移动通信集团河南有限责任公司
网络管理中心
2011年3月
1
河南移动网络故障类优秀案例汇编V1.2
1、 文档说明：
本文档将2010年我省网络故障类案例进行了整理、分析与总结，旨在达到梳理告警处理经验、提炼告警处理指导，并为以后的网络故障处理工作提供经验性指导与参考的目的。
本文档的主要起草人：牛燕萍、杨聪聪、周忠良、庞桂峰、王琰、李锐、师璇。
2、修订历史：
版本 V1.0 更新日期 2011-03-24 作者 杨聪聪 周忠良、庞桂峰、V1.1 2011-04-28 王琰、李锐、师璇 牛燕萍 网管中心监控室 杨聪聪 对各专业案例进行补充与完善 核稿人 牛燕萍 单位 网管中心监控室 更新说明 初稿 1、增加4起集团重大故障张艳琼 V1.2 2011-05-03 杨聪聪 牛燕萍 网管中心监控室 前言部分；3、将话音网改成话音核心网； 案例；2、完善
2
河南移动网络故障类优秀案例汇编V1.2
目录
前言 5
1、集团重大故障案例..................................................................................................................... 6 案例一 平顶山因火灾造成通信设备故障重大故障 ..................................................................... 6 案例二 洛阳地区因暴雨造成大面积基站退服重大故障 ........................................................... 12 案例三 平顶山鲁山地区因暴雨造成大面积基站退服重大故障 ............................................... 15 案例四 南阳地区因暴雨造成大面积基站退服重大故障 ........................................................... 18 案例五 三门峡地区因暴雨造成大面积基站退服重大故障 ....................................................... 21 2、话音核心网优秀故障案例....................................................................................................... 24 案例一ZZGS42 Clear code V60B（负载过高）故障 ................................................................. 24 案例二 ZZGS36/ZHKGM7 3937（H.248连接失败）告警故障 .................................................... 30 案例三 三门峡移动至联通业务全阻故障 ................................................................................... 32 案例四 鹤壁DM1至联通目的信令点不可达故障 ....................................................................... 34 案例五 周口GM6中秋节话务溢出的问题分析 ........................................................................ 36 案例六 多个关口局Server出现M3UA路由不可用、双归属心跳丢失故障 ........................... 37 案例七 智能网SMP服务不可用故障 ........................................................................................... 39 3、无线网优秀故障案例............................................................................................................... 41 案例一 新乡部分用户投诉不能主被叫和使用GPRS业务故障 ............................................... 41 案例二 郑州科技市场附近用户投诉手机无信号故障 ............................................................... 43 案例三 商丘BSC33 Gb link中断故障 ....................................................................................... 45 案例四 新乡BSC软件缺陷导致Gb link中断故障 ................................................................... 50 4、传输网优秀故障案例............................................................................................................... 51 案例一 商丘城域网时钟交叉板吊死引起大面积基站退服故障 ............................................... 51 案例二 一干SDH西部1环3系统故障 ....................................................................................... 54 案例三 省干濮阳至安阳外线OLP故障 ....................................................................................... 56 案例四 省干南阳至方城光缆中断故障 ....................................................................................... 58 6、数据网优秀故障案例............................................................................................................... 59 案例一 CMNET北环两台PA路由器脱网故障 .............................................................................. 59 案例二 全省部分用户发送接收短信成功率下降故障 ............................................................... 61 案例三 焦作、济源、平顶山、许昌、周口部分用户无法正常使用GPRS故障 ................... 62 案例四 MDCN南阳节点故障 .....................................................................................................
3
河南移动网络故障类优秀案例汇编V1.2
案例五 周口BSC27/28 Gb link中断故障 ................................................................................. 66 7、网管网优秀故障案例 .............................................................................................................. 69 案例一 全省MSS、MGW网元以及部分MSC、BSC网元远程登陆不成功故障 ........................... 69 8、网络与信息安全案例 .............................................................................................................. 71 案例一 东区11楼监控大厅网络中断故障 ................................................................................. 71 案例二 东区11楼部分TSM认证失败故障 ................................................................................. 73
4
河南移动网络故障类优秀案例汇编V1.2
前言
随着河南移动通信事业的迅速发展，公司网络规模的扩大，网络结构、网络技术的升级换代，对维护人员的知识技能提出了更高的要求。为了尽快提高我省技术人员的维护水平，为维护人员的网络故障处理工作提供经验性指导与参考，网络管理中心编写完成了《河南移动网络故障类优秀案例汇编》。
本文档将2010年我省网络故障类案例进行了整理、分析与总结。2010年全省共发生网络故障97起，其中达到集团重大故障5起，涵盖话音核心网、无线网、传输网、数据网和网管网。本文档选择了其中具有代表性的28起案例进行了深入分析与经验总结，旨在达到梳理告警处理经验、提炼告警处理指导，并为以后的网络故障处理工作提供经验性指导与参考的目的。河南移动通信有限责任公司网络管理中心保留对此文档的解释权和修改权。
5
河南移动网络故障类优秀案例汇编V1.2
1、集团重大故障案例
案例一 平顶山因火灾造成通信设备故障重大故障 案例名称 设备类型 平顶山因火灾造成通信设备故障重大故障 设备厂家 设备型号 软件版本 M14/U4 故障程度 集团重大故障 故障恢复时间 6月1日21:52 6月6日1:00 99小时50分钟 平顶山市所属的叶县县城周边、宝丰县城局部、鲁山县城周边、舞钢县城、汝阳县城周边和平顶山市区西部 故障或问题现象 2010年 6月1日21时09分开始，话务网管系统陆续出现平顶山交换、无线设备“网关解析失败、目的信令点不可达、路由不可用”等告警，数据网管系统陆续呈现“接口DOWN”等告警，同时动力环境系统呈现“通讯异常”告警。 故障原因分析 6月1日20点54分，平顶山综合生产楼5楼与机房相连的走道里一照明空气开关自燃，火星溅落在机房走道内堆积的可燃物上引发火灾，燃烧产生的浓烟及热气通过门缝进入5楼机房，因烟雾粉尘颗粒沉积导致5楼机房中设备于21点09分开始陆续发生故障。机房内2个MSS、4个MGW 、1个HLR、1对CE，11个BSC部分板件发生故障，受影响基站数量为417个。 处理步骤说明 一、 省公司处理步骤 故障历时 业务影响范围 用户投诉（起） 2900起 火灾 集团重大故障 关键字 故障原因 外部、火灾 HLR、MGW、MSS、诺西、华为 DX200、IPA2800 BSC、CE 故障发生时间 处理步骤1-9条：故障发现及处理过程 1、 6月1日21：09，监控值班长发现平顶山交换、无线设备相继出现目的信令点不可达等重
6
河南移动网络故障类优秀案例汇编V1.2
大告警，立即通知现场交换值班专家和平顶山分公司处理。 2、 6月1日 21:10，省内网管系统自动派发关于平顶山网元目的信令点不可达、路由不可用等故障工单。21:18，监控中心向专业室手动派发一级故障工单“平顶山软交换CE06出现物理实体告警”， 后陆续向专业室、平顶山公司派发多张关于平顶山故障的一级故障工单。 3、 6月1日21:11，集团公司向我省自动派发“平顶山PDSGM106出现目的信令点不可达”故障工单，后陆续派发多张关于平顶山故障工单。 4、 6月1日 21:13，监控中心值班专家对故障影响网元、故障范围进行统计，组织人员检查容灾网元运行情况，组织技术专家赴网管中心现场进行故障处理。 5、 6月1日21：15，监控值班长初步判断故障为重大故障，按照《河南移动重大故障指挥调度流程》，公司迅速建立了省市两级重大故障指挥调度中心，统一指挥业务抢通工作。 6、 6月1日21:15，指挥中心紧急组织交换、数据专家及厂家技术人员开展核心网业务抢修，并组织调度全省20多名交换、数据、无线专家和15名厂家技术工程师携带备件奔赴平顶山开展现场业务抢修工作。 7、 6月1日21:30，集团公司以电话形式向我省监控中心询问平顶山目的信令点不可达故障情况，监控值班长根据掌握信息口头向集团进行了汇报。 8、 6月1日21：32，指挥中心紧急从省内调度8辆应急通信车和2台卫星通信车赶赴平顶山故障现场。同时紧急组织进行省内诺西、华为设备备品备件等资源的调配。分别从郑州、南阳、三门峡等分公司调用7框60个华为单板，从驻马店、新乡、信阳调用3台BSC3i 660诺西设备发往平顶山，为业务快速抢通提供应急资源的支撑与保障。 9、 6月1日21:52，监控中心在集团EMOS上建立重大故障工单“平顶山本地网多个网元出现目的信令点不可达告警”，于22：03正式将平顶山重大故障工单上报集团。 处理步骤10-12条：启动HLR容灾应急预案，恢复HLR业务 10、 6月1日21：32，经分公司拨打测试及现网确认的HLR5设备故障情况，结合平顶山交换网元的告警分析结果，交换专家初步判断了平顶山网元故障情况、原因及影响范围，为尽快抢通业务，立即准备HLR容灾应急。通过检查，确认连接至平顶山HLR5的远程备份服务器上有最新的用户数据备包，立即启动《HLR容灾应急预案》，通过HLR备份服务器，从远程备份服务器向容灾HLR进行数据传送。同时HSTP\\LSTP\\MSC\\MSS修改GT分析数据，将归属PDHLR5的号段指向ZZHLRB，通知BOSS修改IP连接，将原指向PDHLR5的连接改为指向 7
河南移动网络故障类优秀案例汇编V1.2
ZZHLRB。 11、 6月1日22：40，完成数据包传送工作，经手工拷贝部分PDHLR5配置数据、人工创建容灾混合包、校验新生成的混合包等多项工作，系统在23:17进行重启并加载新生成的混合包，23:30分完成系统重启。 12、 6月1日23：32，PDHLR5业务全部恢复。通知分公司按照HLR容灾倒换方案测试表进行拨打测试，确认容灾倒换后用户业务使用正常。 处理步骤13-15条：紧急调整MGW归属关系，恢复软交换业务 13、 6月1日22：00，交换专家在对故障网元机房位置和设备归属关系判断基础上，经过与数通、STP工程师论证，提出了割接PDSGM104（原归属PDSGS101）至ZZGS109来恢复软交换业务的应急抢通方案：采用故障PDSGS101数据包重启ZZGS109，将原先平顶山AR发布的PDSGS101 IP地址段迁移到郑州AR发布，修改IP承载网数据的方式进行割接。 14、 6月2日0：10，向集团提交了IP路由数据割接申请，此次割接得到了集团公司网络部监控处承载传输组的审批和技术支援。在实施割接过程中，交换、CE及承载网三专业联动，成功地将PDSGM104紧急割接至ZZGS109。 15、 6月2日 02：10，PDSGM104业务完全恢复，经拨测验证确认用户业务使用正常。 处理步骤16-1：采用其他交换机恢复部分无线业务 16、 6月1日21:35，根据现场情况，启动无线割接应急预案，利用省内容量富余I系列交换机和其他软交换设备容量承载部分无线业务。 17、 6月1日22:30，交换技术人员开始制作核心网基站数据、号码处理数据。 18、 6月2日00:34，完成了所有核心网配置数据的制作，随着无线网割接，陆续开始承载业务。 二、 平顶山公司处理步骤 1、6月1日21：09，平顶山监控班组接省监控中心通知，同时通过网管系统发现平顶山交换、无线设备相继出现目的信令点不可达等重大告警，从故障网元地理位置归属上分析，初步判断是生产楼五楼机房有故障，随后发现有烟味传来。 2、 6月1日21：13，本地维护人员到达五楼机房进行查看，到达现场时发现机房临近通道冒烟。机房监控系统中断，屋门无法打开。确认火情后迅速拨打“119”。 8
河南移动网络故障类优秀案例汇编V1.2
3、 6月1日21：35，本地维护人员参照《河南移动红橙黄蓝应急预案》立即启动无线网应急预案，根据现场情况，于22:30最终确定了平顶山BSC割接方案：方案1：将采用A口或Abis口割接方案将基站割接至其他交换机，方案2：抓紧故障排查，开通本地BSC。为抢修部分受影响基站，按照优先级别对基站进行了分批次割接。 4、 6月1日21：50，消防支队人员达到后屡次尝试扑火。平顶山分公司网络部经理奋勇当先，先后两次带领消防队员进入火场扑火并打碎玻璃排烟、降温。排烟、降温完毕，维护人员才获准进入。立即组织技术专家进行现场故障处理。 5、 6月1日22：30，现场人员从后门进入机房，由于发现设备指示灯正常，初步认为是CE设备故障，立即组织技术人员对CE设备进行恢复，通过对单板的插拔掉电恢复，设备仍不能正常工作，判断为单板故障引起，组织进行硬件更换工作。 6、 6月1日 23:00，从郑州紧急支援平顶山公司故障处理的网管中心、厂家工程师到达现场后，立即开展业务及设备抢通工作。随后各专业维护人员进入机房对设备进行查看，发现五楼机房内的1台HLR、2台GS、4台MGW、11台BSC因烟雾颗粒沉积到设备上导致设备出现故障。 7、 6月1日23：30，通过A口或Abis口割接，平顶山市区西部及县城以上已基本恢复通信。 8、 6月2日01：01分，维护人员通过更换软交换CE硬件，CE-AR业务恢复。 9、 6月2日11:20，从郑州、南阳、三门峡、周口、驻马店、焦作、商丘等分公司调用的板件陆续到位并投入使用。 10、6月2日12:30，BSC24设备经过清洗，重启后恢复，本地维护人员将BSC24的基站进行了重新倒回。14:40，BSC24基站全部恢复。 11、6月2日14：20，本地维护人员将诺西BSC25、26割接至本地冗余的BSC上。 12、6月3日03:00，BSC26设备恢复，07：00 ，原BSC26下基站全部恢复到BSC26。BSC26业务全部倒回。 13、6月4日06：00，BSC31设备恢复。 14、6月5日06：00，BSC31业务全部倒回。 15、6月6日01：00，BSC27设备恢复，原BSC27下基站全部倒回。 截止6月6日01:00 ，平顶山地区受影响BSC已全部恢复正常并承载现网业务，所有临时割接基站已全部倒回且运行正常，平顶山本地无线网已完全恢复至故障前状态。 应急预案执行情况/解决方案 9
河南移动网络故障类优秀案例汇编V1.2
一、 立即启动全省重大故障指挥调度体系 6月1日21：13，监控值班长初步判断故障涉及MSS、MGW、HLR 、CE、BSC及部分基站，影响范围涉及平顶山市区局部区域及部分县城，为重大故障，按照《河南移动重大故障指挥调度流程》，立即启动一级应急机制。按照《河南移动重大故障指挥调度体系》执行原则，河南公司立即成立了以网络管理中心总经理、网络部总经理、平顶山分公司主管网络副总经理为组长的省市两级指挥调度中心，统一指挥业务抢通工作。故障处理组下设交换、数据、传输、电源、无线、资源五个小组。各小组下按照设备类型建立相应故障处理分队。按照维护职责分工，确定核心网设备抢通工作由省级指挥中心负责，本地网设备抢通工作由平顶山指挥中心负责。 河南移动重大故障指挥调度体系的快速启动与高效运行，确保了本次突发重大故障通信抢修工作的快速反应、有序开展；保障了各专业业务抢通方案的快速确定及实施；为业务短时间快速抢通奠定了基础。 二、 迅速启动各类应急保障方案，快速抢通业务 本次故障涉及专业类型多、抢修难度大，为快速抢通业务，河南移动快速启动了如下应急预案： （一）启动HLR应急倒换方案 6月1日22:00，为尽快抢通业务，故障处理组立即启动了《HLR应急倒换方案》，采用了跳过用户数据抽查步骤、并行进行现网路由数据修改等多种措施，尽量简化流程，压缩时间，于23:32分全部恢复HLR5业务，整个容灾倒回过程比以往应急演练缩短了21分钟。 （二）启动软交换应急方案及三专业联动应急方案 本次故障造成5楼机房2台MSS、4台MGW设备受到影响，21:35开始，故障处理组迅速启动《软交换应急方案》，为尽快抢通软交换业务，在制定方案时充分利用现网核心网资源，最大限度疏通现网业务。技术人员迅速确定利用现网容量富余的I系列核心交换网元，通过 A口或Abis割接方案迅速疏通话务。 同时根据《河南移动软交换三专业联动应急方案》，于22:00制定了将PDGM104（归属5层PDGS101、已故障）割接至ZZGS109的业务疏通方案，通过交换、CE及承载网多专业联合，软交换业务于6月2日 02：10完全恢复。 （三）启动软交换CE应急方案 22：30现场人员进入机房后，确认软交换CE设备出现故障，立即启动《软交换CE应急方案》，组织技术人员对CE设备进行抢修，通过对单板的插拔掉电恢复，设备仍不能正常工作，判断为单板故障引起，组织进行硬件更换工作，与6月2日01:01分恢复CE设备，CE-AR业务 10
河南移动网络故障类优秀案例汇编V1.2
完全恢复。 （四）启动红橙黄蓝应急方案 本次故障造成417个基站中断，为快速恢复基站业务，21：35，指挥中心参考《河南移动红橙黄蓝应急预案》内容，立即启动无线网应急预案，并于22:30最终确定了平顶山BSC割接方案：方案1：将部分基站割接至郑州的BSC，方案2：抓紧故障排查，开通本地BSC。为抢修部分受影响基站，省公司现场专家与分公司本地维护人员按照优先级别对基站进行了分批次割接。6月1日23：30分开始，平顶山市区西部及县城以上基站陆续恢复通信。 经验总结 此次通信抢修工作影响区域广、涉及网元多、涉及专业多、抢修难度大，面对突发事故，各级领导高度重视，各专业快速反应、快速到位、有效联动，快速制定并实施了正确的应急方案、业务疏通方案和故障恢复方案，在较短时间内恢复了平顶山通信业务，将对客户的影响降至了最低，主要得益于以下几方面： 一、集团公司的有力帮助和指导 此次通信抢修工作得到了集团公司的正确领导和大力支持。刘爱力副总裁多次打电话询问火灾及通信抢修进展情况，要求全力以赴尽快恢复通信畅通。集团公司网络部魏丽红总经理携网络部、综合部相关人员迅速到达事故现场，指导通信恢复工作。集团公司网络部监控处孙金霞、谭步律、万奇等经理一直在总部进行远程调度与指挥。集团公司网络部监控处承载传输组为我省开辟了绿色通道，当晚紧急审批了河南公司IP路由数据割接口头申请，并提供了远程技术支援，为软交换设备的顺利割接、业务快速抢通给予了大力支持。 二、公司管理层正确领导与高效的现场指挥 事故发生后，公司总经理原建国第一时间赶到现场，分管网络的武志群副总经理连夜从北京培训地赶到故障现场，全面指挥事故处理和通信抢修工作。省公司网络口各部门各级领导快速到位，现场指挥，以业务快速抢通、降低对客户影响为第一要务，迅速调集全省人力、物力资源全面开展业务及通信抢通工作。 三、重大故障指挥调度体系发挥了积极作用 为增强公司网络重大故障应急处理能力，提高网络通信保障能力，河南公司于09年建立了《河南移动重大故障指挥调度体系》，分别在全省各地市进行了多次有准备、无准备演练，通过演练在加强了上下级之间及各专业之间联动性的同时，进一步提升了维护人员的重大故障应对能力，有效确保了体系建设的有效性、完备性。通过建立了省、市两级重大故障处理指挥 11
河南移动网络故障类优秀案例汇编V1.2
调度体系，有效提升了全省的重大故障防范能力、排查能力和业务快速恢复能力，改善了网络安全运行环境。通过为全省关键岗位人员配备第二通信手段、应急工具并定期开展测试与演练，确保了在突发重大故障中关键岗位人员召之即来，来即能战。体系的确立及演练工作的深入开展有效提升了河南公司网络维护人员对重大事故的业务快速抢通能力，为重大故障的业务快速抢通奠定了基础。 四、人员的快速到位和方案的正确制定 本次突发故障发生后，指挥中心迅速通过第二通信手段与现场取得联系，在第一时间紧急组织交换、数据专家及厂家技术人员开展核心网业务抢修工作，并于21:15开始组织调度全省20多名交换、数据、无线专家和15名厂家技术工程师携带备件奔赴平顶山开展现场业务抢修工作，人员的快速到位为应急抢修奠定了坚实基础。在此次现场抢险中，平顶山分公司网络部经理奋勇当先，先后两次带领消防队员进入现场迅速灭火，控制了灾情的进一步扩大。在业务抢修工作中，各专业技术专家依据现有的应急方案，凭借扎实的技术素养及现场操作能力，处变不惊，沉着应对，在复杂的网络环境下迅速确定了相对完善的抢险方案。同时快速调集了全省可用网络资源，利用容量富余的I系列交换机、BSC快速抢通了无线业务，同时检查容灾HLR系统状态，立即启动了HLR容灾应急预案，使得HLR成为抢修过程中业务恢复最早的网元。河南公司将容灾系统的管理及维护纳入日常维护管理中，确保了故障发生后容灾系统的快速启动，通过人员的快速到位和方案的正确制定与实施，确保了通信的快速恢复。 故障报告（可插入附件） 平顶山因火灾造成通信设备故障重大故障
案例二 洛阳地区因暴雨造成大面积基站退服重大故障 案例名称 设备类型 洛阳地区因暴雨造成大面积基站退服重大故障 设备厂家 设备型号 软件版本 故障程度 BTS 诺西、华为 BSC3i/BSC6000 S12/G3BSC6000 集团重大故障 故障发生时间 故障恢复时故障历时 业务影响范围 用户投自然灾害 暴雨 关键字 故障原因 12
河南移动网络故障类优秀案例汇编V1.2
间 7月24日 11:37 7月29日10：55 119小时18分钟 洛阳栾川、洛宁、新安、嵩县区域 故障或问题现象 诉（起） 200起 基站退服 2010年7月24日11时15分，洛阳BSC15出现7767（基站中断）告警，洛阳HWBSC42出现405（小区退服）告警。 故障原因分析 7月23日20时至24日21时，洛阳市区及南部山区普降暴雨，全市大面积受灾，栾川县、嵩县、洛宁县灾情尤为严重。灾情造成栾川、嵩县、洛宁、偃师、新安、宜阳、涧西、洛龙、吉利等9个县（市）区37个乡镇20余万人受灾，因灾倒塌房屋821间，损坏房屋1038间；毁坏道路86.2公里，冲毁桥梁34座；洛栾快速通道等13条道路中断；全市电力线路有73条10KV以上线路发生跳闸，5个乡镇所有自然村电力中断。受灾害天气的影响，洛阳栾川、嵩县、洛宁、偃师、新安、宜阳、汝阳、市区等地光缆杆路损毁严重，部分管道塌方，导致洛阳大面积光缆中断、大面积基站中断。 7月24日11时15分，洛阳地区陆续出现基站中断告警； 11时37分，洛阳地区基站中断数量达到68个； 13时24分，栾川县通信全阻，洛阳全区断站数达到163个； 15时20分，洛宁县通信全阻，洛阳全区断站数达到213个； 17时20分，栾川县潭头镇汤营伊河大桥因遭受特大洪水发生整体垮塌； 本次汛情造成洛阳地区最高基站中断数达到379个。 处理步骤说明 一、省公司处理步骤 1、7月23日17:00，省监控指挥调度中心根据《河南移动网络预警及重大故障信息沟通发布规范》，提前发布了河南部分地区暴雨蓝色天气预警信息，要求洛阳公司提前建立应急组织机构、检查应急物资情况，并密切关注网络运行情况。 2、7月24日11:15，省监控值班人员发现LYBSC15、LYBSC47、LYHWBSC42出现7767号断站告警和405号小区退服告警，立刻通知洛阳分公司和客服中心，并向相关领导汇报汛情情况，省监控值班人员立即启动全省汛情通信保障信息发布，实时掌控汛情处理进度。 13
河南移动网络故障类优秀案例汇编V1.2
3、灾情发生后，省公司网络部、网络管理中心领导在第一时间赶到省监控指挥调度大厅，全面指挥汛情通信抢修工作。根据汛情及网络影响情况，河南公司按照应急管理办法向省通信管理局进行上报。 4、7月24日11:37，省监控值班人员监控到洛阳地区累计大面积断站超过40个。随后，根据汛情影响情况，河南公司通过集团EOMS上报重大故障管理工单，并上报了阶段重大故障业务核算表。 5、故障期间，根据汛情影响情况，河南公司按照集团公司要求，通过监控大值班、汛情上报工单定期向集团上报洛阳地区汛情及故障信息。 二、洛阳分公司处理步骤 1、7月24日11：15，值班人员从网管监控发现栾川至栾川冷水，洛宁长水至栾川冷水光缆双向中断，栾川冷水部分基站中断。洛阳分公司及时启动应急响应，立即组织抢修队伍和器材物资展开抢修并上报分公司网络部领导、省公司传输主管、省公司保障电话。 2、灾情发生后，洛阳分公司迅速成立救灾抢险临时指挥部，全面启动应急预案，所有网络人员迅速到位。全区出动线路抢修队60组，人员410人，电力抢修人员174人，油机106台，应急发电车11台；总计出动人员584人。已派送277KM光缆、0个接头盒、30根水泥杆、21套仪表、2700根尾纤、11块传输板件至抢修现场。 3、栾川、嵩县分公司现场指挥部迅速组织突击抢修队，集中力量对宜阳-洛宁、洛宁-栾川、长水-冷水、嵩县-栾川、嵩县-栗树街等骨干段落两方向同时进行抢修。克服道路阻断、山体塌方、涉水过河等困难，在发现光缆断点多、抢修难度大的情况下，采取多点共同抢修或重新布放光缆方式，以最快方式进行抢修。 4、7月24日21：25，洛宁125个基站全部恢复。7月25日23：20，栾川至嵩县光缆恢复，栾川约49个基站恢复，栾川县城基站全部恢复。7月26日00点，栾川至嵩县栗树街之间光缆恢复，栗树街下带14个基站恢复。7月26日18：26，洛宁长水至栾川冷水光缆恢复，栾川冷水下带55个基站恢复。 5、随着抢险救灾保通信工作的深入进行，截止7月29日10：55，洛阳地区断站故障基本恢复，重大故障消除。 应急预案执行情况/解决方案 近两年自然灾害频繁，结合集团公司、省公司对2010年防汛应急工作高标准、严要求，洛阳分公司高度重视，在汛期来临之前重点落实好以下四方面工作： 14
河南移动网络故障类优秀案例汇编V1.2
1、 提前做好物资储备、应急通信车检查、卫星电话、对讲机等设施充电，补充食品、药品等。 2、 反应及时，分工明确，人员、油机、燃油调度合理，执行到位，保障效果良好。 3、 及时调用各种应急物资、车辆。 4、 及时启动重大故障指挥调度及信息发布，及时上报故障，及时发布各种信息。 在涉及抢修的各专业中指定信息专管员，专门负责信息搜集和沟通工作，及时向分公司信息沟通组上报灾情及抢修情况，形成了快速有效地内部信息流通渠道。 经验总结 1、 采用橡皮船过河放缆，解决河面无桥、放缆长度太长难题。 2、确定优先级。优先抢通骨干环、优先抢通县城基站、优先在用纤芯接续、优先影响断站光缆、优先抢通传输后恢复业务。 3、一个中继段，投入多组抢修队，查找一个断点后，积极抢修外，断点处向两边测试，判断下一个断点位置，投入另外抢修队前去抢修，以最短时间抢通一个中继段落。 4、 光缆抢通后，投放几千张警示牌，密集悬挂于光缆上，防止二次破环。 5、融合当地线路代维、基站代维与光缆抢修队力量，利用当地线路代维、基站代维熟悉路由、基站站址等优势，协助光缆抢修队上站、运送物资等。每个抢修队配备县分公司网络维护人员1人 、巡线员1人、抢修队6人，其中县分公司维护人员主要负责与相关抢险指挥人员进行联系及时通报进度、巡线员主要负责给抢修队带路、抢修队主要负责查找断点及抢修光缆。 5、 密切关注天气、水库泄洪情况，做好信息发布及应急准备。 7、光缆测试与抢修密切配合，干线中继段两端派人OTDR不间断测试，协助抢修队判断故障点。 8、对应急物资进行日清理，根据情况及时上报物资需求。 9、对当天抢修情况进行日总结，并对第2天抢修工作进行部署。 故障报告（可插入附件）
案例三 平顶山鲁山地区因暴雨造成大面积基站退服重大故障 案例名称 设备类型
平顶山鲁山地区因暴雨造成大面积基站退服重大故障 设备厂家 设备型号 15
软件版本 故障程故障原因 河南移动网络故障类优秀案例汇编V1.2
度 BTS 诺西、华为 BSC3i/BSC6000 S12/G3BSC6000 集团重大故障 故障发生时间 故障恢复时间 7月19日 8:25 7月19日 13:10 4小时45分 平顶山鲁山县区域 故障或问题现象 2010年7月19日8时25分，平顶山BSC26出现7767（基站中断）告警，平顶山HWBSC3出现405（小区退服）告警。 故障原因分析 7月18日夜，平顶山市区、郏县、汝州、鲁山突降大暴雨。 1、大量降雨引发山洪爆发，鲁山县一半以上的基站都位于山上，洪水冲毁了河两岸的光缆线路，致使主备路由均受损，造成基站中断。 2、降雨使得该地区电力设备被损坏，使得基站长时间停电造成断站。 3、雷电击坏部分基站的主设备，致使基站中断。 7月19日0时47分开始，鲁山西山基站开始陆续出现中断； 8时25分，基站中断数量达到40个以上； 9时00分，基站中断数量达到70个； 处理步骤说明 一、省公司处理步骤 1、7月19日0：47 和0：53发现PDHWBSC3、PDBSC26出现7767断站告警和405小区退服告警闪断，立刻通知平顶山分公司密切关注处理，并派发故障工单至平顶山分公司。 2、平顶山回复：当地突降暴雨，并且雨势不断增大。7月19日凌晨0：47鲁山西山基站开始陆续出现中断，立即上报主管及部门领导。 3、要求平顶山分公司积极做好应急通信保障准备工作，积极组织当地人员奔赴现场展开抢修工作，并及时上报处理情况。 4、密切关注平顶山断站情况，7月19日8：25，断站数突增到63个，监控中心值班人员立即电话上报集团公司。
16
自然灾害 暴雨 关键字 故障历时 业务影响范围 用户投诉（起） 3起 基站退服 河南移动网络故障类优秀案例汇编V1.2
5、7月19日11：25，由于达到集团重大故障上报标准，通过集团EOMS上报重大故障管理工单，并填写重大故障业务核算表（工单号JT-53-100719—00003）。 6、7月19日13：10，经过平顶山分公司紧急抢修，断站数减少到14个，电话上报集团申请销障。 二、平顶山分公司处理步骤 1、7月19日凌晨，接到基站断站故障后，鲁山维护人员将当地情况向主管领导汇报，省公司主管网络领导也赶赴受灾现场，全面指挥灾情处理和通信抢修工作。 2、省市县协调，按照重大故障指挥调度体系相关要求，迅速成立了公司主管网络副总为指挥长的应急通信保障组，鲁山当地也组织了移动公司人员、基站代维人员、线路代维人员共63人、17台车就近分布在各节点机房待命。 3、5：20，鲁山抢修人员到达事发现场，发现暴雨引发的泥石流把沙河两岸护堤全部冲毁，河上游的部分村落被冲毁，水面上随处可见家里日常用品漂浮其上。当时天空依然电闪雷鸣、大雨倾盆，抢修工作无法开展。 4、6：00，待其他县形势稳定后，后勤保障组又从市区、叶县、舞钢紧急抽调了线路维护和基站维护人员21人、车辆15台、油机11台赶赴鲁山支援。支援人员于10：00左右陆续到达鲁山，加入到鲁山现场故障处理中。 5、10：00后，雨势渐小，水流也开始有所放缓，线路维护人员分成六组，分段对沙河两岸线路进行巡检排障，12：00后，陆续发现多处光缆中断点，经六组人员全力抢修后，基站从13：00开始陆续恢复，截止13：10断站数量降至14个。 应急预案执行情况/解决方案 按照防汛应急预案的要求，平顶山在汛期到来前已准备了充足的防汛物资，并且按照指挥调度体系的要求，平顶山故障抢修组、信息发布组、后勤保障组及时到位，在重大故障指挥长的统一指挥下，有条不紊的开展应急抢修工作，特别是在其他县区和市区的局面得到控制后，支援的人力和物资也及时到位，为快速抢通业务提供了保障。 经验总结 1、平顶山自主研发的自启动油机在关键时候正常启动，为不能到达区域的通信保障提供了保障； 2、环路所带站点在大环改造的基础上还需要进一步缩小，鲁山因为地理因素原因，环路所带站点都接近15个的大环临界值，如果能够将环路站点都优化在10个左右的话，此次故障带来 17
河南移动网络故障类优秀案例汇编V1.2
的影响面会进一步降低。 3、一个乡镇级汇聚机房不应下挂过多站点，乡镇级汇聚机房不同于城区的核心机房，虽然在油机和双路由保护措施下，安全效果较高，但毕竟地处偏远，安全隐患较大。此次中断基站全是在十亩地洼2.5G机房下挂，下一步我们将在合适位置新建1-2个新汇聚机房，将十亩地洼下挂的88个站点进行负荷分担，以降低单节点失效而带来的隐患。 4、一个环路的两端线路尽量不都在河流上方架空通过，避免区域内河流发生洪灾而导致全环中断。如果确实受地理因素所限，则必须对光缆的过河方式予以特殊重点处理。如至少保证一处光缆过河是利用桥架、塔吊、顶管等方式，避免同时架空带来的安全隐患。 故障报告（可插入附件）
案例四 南阳地区因暴雨造成大面积基站退服重大故障 案例名称 设备类型 南阳地区因暴雨造成大面积基站退服重大故障 设备厂家 设备型号 软件版本 故障程度 BTS 诺西、华为 BSC3i/BSC6000 S12/G3BSC6000 集团重大故障 故障发生时间 故障恢复时间 7月24日1:15 7月29日17:30 136小时15分钟 南阳淅川、西峡、南召部分区域 故障或问题现象 2010年7月24日1时15分，南阳BSC25出现7767（基站中断）告警，南阳HWBSC35出现405（小区退服）告警。 故障原因分析 7月23日晚，南阳地区普降暴雨，受上游洛阳、三门峡的降水影响，南阳市丹江、淇河、灌河、故障历时 业务影响范围 用户投诉（起） 127起 基站退服 自然灾害 暴雨 关键字 故障原因 18
河南移动网络故障类优秀案例汇编V1.2
湍河等主要河流水位上升明显。根据荆紫关水文站数据，本次洪灾为1953年建站以来第一次大洪水，重现期接近100年。受持续强降雨影响，引发多处道路塌方、山体滑坡、泥石流等灾害，经过勘察，初步统计被冲毁光缆里程827.5公里。南阳淅川、西峡、南召等地区由于暴雨引发的山体滑坡、洪水导致多处光缆、电力中断。 7月24日1时15分，南阳基站中断数量达到238个、停电基站数量达到161个。 处理步骤说明 一、省公司处理步骤 1、7月23日17:00，省监控指挥调度中心根据《河南移动网络预警及重大故障信息沟通发布规范》，提前发布河南部分地区暴雨蓝色预警信息，要求南阳公司提前建立应急组织机构、检查应急物资情况，并密切关注网络运行情况。 2、7月24日00:53，省监控值班人员发现NYHWBSC35、NYBSC25 出现405、7767断站告警，立刻通知南阳分公司和客服中心，并向相关领导汇报汛情情况，省监控值班人员立即启动全省汛情通信保障信息发布，实时掌控汛情处理进度。 3、灾情发生后，省公司网络部、网络管理中心领导在第一时间赶到省监控指挥调度大厅，全面指挥汛情通信抢修工作。根据汛情及网络影响情况，河南公司按照应急管理办法向省通信管理局进行上报。 4、7月24日1:15，省监控值班人员监控到南阳地区累计大面积断站超过40个。随后，根据汛情影响情况，河南公司通过集团EOMS上报重大故障管理工单，并上报了阶段重大故障业务核算表。 5、故障期间，根据汛情影响情况，河南公司按照集团公司要求，通过监控大值班、汛情上报工单定期向集团上报南阳地区汛情及故障信息。 二、南阳分公司处理步骤 1、7月23日17：00，南阳分公司收到省网络管理中心监控室、南阳气象局下发的暴雨预警短信，提前启动重大故障应急预案，通知各分公司、各专业（重点传输、基站）、代维公司，确保第二通信方式畅通，准备好各项防汛应急物资；通知工程施工队伍，做好抢修准备；通知本地监控中心及时做好全网监控和信息发布工作；同时加强专业班组人员夜间职守。 2、7月24日00:53开始，监控值班人员发现话务网管系统陆续出现南阳基站中断告警，1:15，南阳地区基站中断数超过40个，灾情发生后，南阳分公司迅速成立救灾抢险临时指挥部，分公司主管副总、各专业主管第一时间到达指挥现场，组织召开紧急会议，成立两级指挥中心，明 19
河南移动网络故障类优秀案例汇编V1.2
确分工后，共组建24支线路抢修队伍，共计416名抢修人员，168台油机、3台发电车，3台应急通信车，18部卫星电话投入抢险工作。 3、南阳分公司现场指挥部迅速组织突击抢修队，指挥长亲自带领抢修人员、物资赶赴灾区，按照“先抢通后抢修、先重点后一般”的抢修原则，对西峡—内乡段骨干光缆、西峡—淅川段骨干光缆、淅川-邓州段光缆同时进行抢修。 4、7月28日淅川、南召基站全部恢复，29日西峡基站陆续恢复；分公司重点加强干线、本地网主干路由、重要管道、VIP基站的巡检工作。 5、随着抢险救灾保通信工作的深入进行，截止7月29日17时30分，南阳地区断站故障基本恢复，重大故障消除。 应急预案执行情况/解决方案 近两年自然灾害频繁，结合集团公司、省公司对2010年防汛应急工作的要求，南阳分公司高度重视，汛期来临之前重点落实好： 1、检查并充实防汛所需各类应急物资，建立应急物资数据库。 2、举行无准备防汛应急演练，完善防汛预案可操作性，检查并实时更新基站、线路应急抢修队伍，明确各类抢修队伍应配备的抢修仪表、物资等；同时结合南阳实际情况，将工程施工队伍纳入应急抢修体系，确保第一时间能够通知到、保障好。 3、在灾害发生后，执行人员根据预案的职责分工分头开始工作：技术保障小组根据停电、中断基站等网络具体情况，按照应急预案“重点基站优先保障原则”，进行基站抢修和恢复； 4、协调调度小组在全区范围内进行油机调配，1个小时内完成向四个受灾县分公司第一批共计87台油机的调配；同时后勤保障小组立刻组织发电电缆、应急油桶、手电筒、雨衣、救生衣等应急物资向灾区送往； 正是由于前期和上述工作落实到位，重大故障面前，在重大故障指挥长的统一指挥下，成立两级指挥调度中心，按照“先抢通后抢修”的原则，为快速抢通业务提供保障；南阳移动比其它运营商抢通早9个小时。 经验总结 1、应急预案中关键的应急物资、应急抢修队伍落实到位，为快速抢通提供保障。 2、加强与沟通协作，关注和话务量密集的重要站点全力保障，采取了多种抢修措施，如临时人工放缆、微波、应急光端机、应急通信车等手段第一时间抢通。 3、海事卫星电话做为受灾区域唯一的通信生命线，在此次抢通过程中，南阳移动同时启用18 20
河南移动网络故障类优秀案例汇编V1.2
部卫星电话，为两级指挥联系提供有力支撑，不管是信息传递还是骨干线路抢通、公司企业形象宣传等方面，卫星电话都起到了不可磨灭的作用。 故障报告（可插入附件）
案例五 三门峡地区因暴雨造成大面积基站退服重大故障 案例名称 设备类型 三门峡地区因暴雨造成大面积基站退服重大故障 设备厂家 设备型号 软件版本 故障程度 BTS 诺西、华为 BSC3i/BSC6000 S12/G3BSC6000 集团重大故障 故障发生时间 故障恢复时间 7月24日11:42 7月28日13:25 97小时43分钟 三门峡卢氏、渑池、义马部分区域 故障或问题现象 2010年7月24日11时42分，三门峡HWBSC1出现1000（基站中断）告警和405（小区退服）告警。 故障原因分析 7月23日至24日，三门峡遭受多年以来罕见暴雨袭击，其中卢氏县降雨量达195.7mm、渑池县降雨量达213.6mm，全区总降雨量为历史之最。因持续强降雨，引发道路塌方、山体滑坡、泥石流等灾害，进而造成全区多处乡镇水、电、道路中断，分公司多处通信光缆受损严重，多处基站停电。 7月24日凌晨2时17分，三门峡陆续出现基站中断告警； 11时42分三门峡基站中断数量达到71个，后由于暴雨引发泥石流及山体滑坡，造成三门峡地区7个乡镇通信中断，分布在卢氏五里川、朱阳关、汤河、瓦窑沟、官坡、狮子坪、双槐树。最多中断基站数达124个。 故障历时 业务影响范围 用户投诉（起） 129起 基站退服 自然灾害 暴雨 关键字 故障原因 21
河南移动网络故障类优秀案例汇编V1.2
处理步骤说明 一、省公司处理步骤 1、7月23日16：30，省监控指挥调度中心根据《河南移动网络预警及重大故障信息沟通发布规范》，提前发布三门峡强降雨天气预警信息，要求三门峡公司提前建立应急组织机构、检查应急物资情况，并密切关注网络运行情况。 2、7月24日02:17省监控值班人员发现SMXBSC1、BSC8、BSC9 出现1000断站告警和405小区退服告警，立刻通知三门峡分公司和客服中心，并向相关领导汇报汛情情况，省监控值班人员立即启动全省汛情通信保障信息发布，实时掌控汛情处理进度。 3、灾情发生后，省公司网络部、网络管理中心领导在第一时间赶到省监控指挥调度大厅，全面指挥汛情通信抢修工作。根据汛情及网络影响情况，河南公司按照应急管理办法向省通信管理局进行上报。 4、7月24日11:42，省监控值班人员监控到三门峡地区累计大面积断站超过40个，达到集团定义的重大故障标准。随后，根据汛情影响情况，河南公司通过集团EOMS上报重大故障管理工单，并上报了阶段重大故障业务核算表。 5、故障期间，根据汛情影响情况，河南公司按照集团公司要求，通过监控大值班、汛情上报工单定期向集团上报三门峡地区汛情及故障信息。 二、三门峡分公司处理步骤 1、 7月23日16：00，三门峡分公司收到省网络管理中心监控室、三门峡气象局下发的暴雨预警短信，提前启动重大故障应急预案，通知各分公司、各专业（重点传输、基站）、代维公司，确保第二通信方式畅通，准备好各项防汛应急物资；通知工程施工队伍，做好抢修准备；通知本地监控中心及时做好全网监控和信息发布工作；同时加强专业班组人员夜间职守。 2、 7月24日02：17，三门峡地区陆续出现基站中断告警，灾情就是命令，分公司主管副总、各专业主管第一时间到达指挥现场，组织召开紧急会议，成立两级指挥中心，明确分工后，调集11支光缆抢修队伍、光缆应急抢修物资、1辆应急通信车、2部海事卫星电话、40余套救生衣第一时间赶赴受灾现场。 3、 市指挥中心将光缆受损情况、光缆下挂基站情况、抢修紧急程度、抢修指导意见第一时间发给卢氏指挥中心。 4、 第一批抢修物资于24日10时达到卢氏抢修一线，分公司主管网络副总任现场指挥长，按照“先抢通后抢修、先重点后一般”的抢修原则，结合抢修中继段优先级组织开展具体的抢修 22
河南移动网络故障类优秀案例汇编V1.2
工作。 5、 为第一时间抢通卢氏至五里川主干光缆，网络维护人员背负海事卫星电话、徒步徒步行走近4个小时，翻山跋水20余公里赶至五里川，安排抢修队伍“里应外合”，从县城和五里川两个方向同时进行人工徒步放缆。 6、 7月25日19点分公司应急抢修人员第一时间恢复了卢氏-五里川主干通信畅通。至26日下午6时，顺利完成卢氏7个受灾乡镇通信畅通，为各电信运营商中的第一家开通。 7、 同期，三门峡渑池、义马分公司积极组织开展抢修工作，其中7月28日15:10义马11个基站全部恢复；其他分公司重点加强干线、本地网主干路由、重要管道、VIP基站的巡检工作。 由于前期各类抢修物资、施工队伍准备充分，本次应急抢修三门峡分公司共组建18支线路抢修队伍，共计246名抢修人员，41台油机、24台自启动油机，1台应急通信车，5部海事卫星电话投入抢险工作。 应急预案执行情况/解决方案 近两年自然灾害频繁，结合集团公司、省公司对2010年防汛应急工作高标准、严要求，三门峡分公司更是高度重视，汛期来临之前重点落实好： 1、检查并充实防汛所需各类应急物资，建立应急物资数据库。 2、检查并实时更新基站、线路应急抢修队伍，明确各类抢修队伍应配备的抢修仪表、物资等；同时结合三门峡实际情况，将工程施工队伍纳入应急抢修体系，确保第一时间能够通知到、保障好。 3、结合网络拓扑情况，将全区所有基站分县整理成图册版的VIP基站&普通基站分布图；依据节点、线路的重要程度，将全区传输网线路划分不同的抢修等级。 正是由于前期上述工作落实到位，重大故障面前，在重大故障指挥长的统一指挥下，成立两级指挥调度中心，按照“先抢通后抢修”的原则，各小组有条不紊的展开应急抢修工作，为快速抢通业务提供保障； 本次三门峡防汛保通信应急抢修现场组织科学、合理，整个抢修过程中，各方资源有效整合，使抢修和效果达到最大化，同时在整个抢修过程中干线运行稳定，在本次应急抢修中，三门峡移动成为了最早抢通的运营商，受到了卢氏县委县的通报表扬。 经验总结 1、应急预案中关键的应急物资、应急抢修队伍落实到位，为快速抢通提供保障。 2、图册版的VIP基站分布图、传输线路优先级为基站发电调度、光缆抢修调度起到关键的指 23
河南移动网络故障类优秀案例汇编V1.2
导作用。 3、加强与沟通协作，关注和话务量密集的重要站点全力保障，采取了多种抢修措施，如临时人工放缆、微波、应急光端机、应急通信车等手段第一时间抢通。 4、海事卫星电话做为受灾区域唯一的通信生命线，必须保证有充足费用，关键时刻不停机。在此次抢通过程中，不管是信息传递还是骨干线路抢通、公司企业形象宣传等方面，海事卫星电话都起到了不可磨灭的作用。 5、前期启用的自启动油机在关键时刻正常启动，为不能到达区域的通信保障提供了保障。 故障报告（可插入附件）
2、 话音核心网优秀故障案例
案例一ZZGS42 Clear code V60B（负载过高）故障 案例名称 设备类型 MSC SERVER 故障发生时间 ZZGS42 Clear code 60B（负载过高）故障 设备厂家 诺西 故障恢复时间 25分钟 设备型号 DX200 故障历时 软件版本 M14 业务影响范围 郑州、省、省军区、经三路周边 故障或问题现象 1、2010年1月11日17时53分，ZZGS42出现Clear code 60B（负载过高）告警，告警信息如下： 故障程度 省内三级 用户投诉（起） 20起 060B 故障原因 软件 关键字 1月11日17:53 1月11日18:18 24
河南移动网络故障类优秀案例汇编V1.2
2、查询ZZGS42的Clear code 60B增长迅速： 3、查询ZZGS42的MSC应答率，已由平时正常应答率45%急速下降，18：00最低接通率为18.28%。 25
河南移动网络故障类优秀案例汇编V1.2
4、查询ZZGS42的系统接通率，已由平时正常接通率97.5%急速下降，18：00最低接通率为60.18%。 故障原因分析 26
河南移动网络故障类优秀案例汇编V1.2
（1）分析历史告警 以VLRU-0单元为例进行告警分析，告警3355，1128，1661和1663伴随出现。60B表示OVERLOAD CONGESTION。 27 河南移动网络故障类优秀案例汇编V1.2 vssqui_p = 0x512 COMMENT '#E: Program Block for VLR Subscriber Data Administration'; 河南移动网络故障类优秀案例汇编V1.2 检查VLRU单元负荷，VLRU-0-0的负荷到达100%，VLRU单元负荷太高。从VLRU容量来看，系统只有3对VLRU，而该MSS实际承载了近100万用户。在忙时处理大批量的用户的话务和位置更新等操作都已经会大幅度提高VLRU单元的负荷，另外由于VSS数据库同步需要增加5－10百分点的CPU负荷，CPU的负荷将被耗尽。 （3）分析ZZGS42的现网负荷： ZZGS42容量为120万，20000Erl。,实际承载用户98万，晚高峰时超过16000千Erl, 各单元CPU负荷比较高。VLRU-0同步造成CPU负荷增加，备用VLRU重启时，它会从主用单元完全复制整个VLR数据库(这个过程叫warming up， 就是我们看的SP-UP状态），因为M14的VLR容量大，复制会造成CPU负荷瞬间提高5～10个百分点。导致VLRU-0主用单元不能完成VLRU备用单元的同步请求，造成同步失败，VLRU备用单元再次重启，如此反复，造成VLRU主用单元CPU负荷持续升高至100%，不能正常处理用户的呼叫，造成大量呼叫失败。 （4）BSC告警 2010年1月11日 17时28分，郑州部分BSC出现2478告警，出现告警的BSC有：ZZBSC114（覆盖市政协）,ZZBSC113（覆盖河南，省，省军区），ZZBSC112(覆盖北环移动办公楼)，ZZBSC41(覆盖科技情报所)，ZZBSC115，ZZBSC30，ZZBSC59，ZZBSC83,ZZBSC52,ZZBSC63。 2478告警详细信息： 告警解释：MSC过载或对BSC进行全局复位，BSC的部分用户被限呼。 1、如果该告警出现，因紧急与核心网工程师联系，查找原因。 2、查看补充信息1为MSC的信令点。 3、查看补充信息2为限呼原因：01为MSC过载，02为MTP过载，03为全局复位。 登陆网元查询告警信息如下： 河南移动网络故障类优秀案例汇编V1.2 00002B00 01 查询以上BSC均下挂在ZZGS42,初步判断为ZZGS42的VLRU单元故障。 处理步骤说明 判断为ZZGS42系统软件原因引起，重启主用VLRU单元后，故障恢复。 应急预案执行情况/解决方案 1、1月11日晚对ZZGS42紧急扩容了两个VLRU。 2、将BSC6从ZZGS42上搬迁到其他MSS，减少ZZGS42用户量，减少系统负荷。 3、通过安装MEN94500补丁解决，MEN94500中ME_4584和ME_5057将对EMB和VSS 两个模块进行改进，减少数据库不一致引起VLRU 备用单元出现重启的可能性。即使出现同步问题备用单元也将自动恢复到正常状态。 经验总结 1、做好网络优化工作，避免某一个网元的用户和负荷过高，避免一个网元覆盖过多热点地区。 2、提高告警级别，将BSC告警2478（现级别为三级）的告警级别进行提高。 3、重点监控3355和0004告警。 4、将Clear code 60B纳入重大告警监控，合理设置告警阈值。 故障报告（可插入附件） ZZGS42 Clear code 60B（负载过高）故障. 案例二 ZZGS36/ZHKGM7 3937（H.248连接失败）告警故障 案例名称 设备类型 MSC SEVER/MGW 故障发生时间 ZZGS36/ZHKGM7 3937（H.248连接失败）告警故障 设备厂家 诺西 故障恢复时间 设备型号 IPA2800 故障历时 软件版本 U4 业务影响范围 故障程度 省内三级 用户投诉（起） 故障原因 内部连线 关键字 30 河南移动网络故障类优秀案例汇编V1.2 3月3日6:24 故障或问题现象 3月3日6:43 19分钟 无 0起 3937 2010年3月3日6时24分， ZZGS36出现3937（H.248连接失败）告警，和20（路由不可用）告警，查询至ZHKGM7。 HST (63653) ZKGM7 1A001-00-11 EQUIPM 2010-03-03 06:24:12.12 NOTICE MXU-1 0691 WORKING STATE CHANGE ACTIVATED BY SYSTEM RXEPRB OMU-1 WO-EX WO-RE 0001 03DA 11 0000FFFF 0000FFFF 00 HST (63661) ZKGM7 1A001-00-11 EQUIPM 2010-03-03 06:24:27.91 NOTICE MXU-1 0691 WORKING STATE CHANGE ACTIVATED BY SYSTEM RXEPRB OMU-1 WO-RE TE-RE 0001 03DA 09 0000FFFF 0000FFFF 00 HST (63662) ZKGM7 1A001-00-9 EQUIPM 2010-03-03 06:24:27.91 NOTICE MXU-0 0691 WORKING STATE CHANGE ACTIVATED BY SYSTEM RXEPRB OMU-1 SP-EX WO-RE 0001 03DA 09 0000FFFF 0000FFFF 00 故障原因分析 通过历史告警分析发现ZKGM7的MXU0、1单元自动重启后SFU、ISU等单元发生了重启。随后在MSS上产生大量的CC843。单元重启结束后CC843停止增长； 处理过程如下： 1、当SFU-0为主用时，一切正常。未出现任何异常。 2、检查SFU-1/MXU-0/MXU-1的前面板及后背板的针，未发现异常。 3、检查SFU-1与MXU-0/MXU-1间的电缆，未发现异常，重新进行拔插。 4、SFU-1主用工作一段时间后，MXU-1自动重启，随后MXU-0、OMU-0、CACU-0、SFU-0、CM-0、VANG-0、ISU-4/3/2/1、 TCU-6//7/14/15/16/17/24/25/27/34/35/3等、IWS1E-37/3634//23/22/21/16/15/14/12/9/4/3等自动重启。 5、切换SFU-0主用，系统逐步稳定。 SFU-1在主用状态，连接的单元都会出现重启，判定故障跟SFU-1有关，重新检查SFU-0的板子、电缆、端口、背板。 31 河南移动网络故障类优秀案例汇编V1.2 检查SFU-1到其它单元的SD LINK，发现SFU-1到NPGEP-2有问题： ZDDS:SFU,1; loadext -n CSXPIR4S pir4st pir4st lstat 显示结果如下： 1C 00:44:43:33 00:03:81:0D 0xFFFF 0xFFFF LINK_GOOD //1C是SFU-1连接NPGEP-2的端口 此表明SFU-1到NPGEP-2累积了大量的错误，引发SFU-1工作异常，导致先后多次出现的MXU等单元异常重启。 插拔SFU-1到NPGEP-2的背板连线，然后检查SFU-1到NPGEP-2的SD LINK，恢复正常。 插拔SFU-1到NPGEP-2的背板连线，将SFU-1状态改成主用，观察系统没有出现其他单元重启的问题。 最终故障定位：SFU-1到NPGEP-2的内部联系问题。SFU-1到NPGEP-2之间的连线有问题导致MXU、SFU、ISU等重要单元重启。 处理步骤说明 插拔SFU-1到NPGEP-2的内部连线，故障解决。 应急预案执行情况/解决方案 插拔SFU-1到NPGEP-2的内部连线，故障解决。 经验总结 1、 做好MGW重点单元状态的监控工作。 2、做好网元硬件安装和入网的硬件核查工作。 故障报告（可插入附件） ZZGS36及ZKGM7出现3937告警故障报告.do 案例三 三门峡移动至联通业务全阻故障 案例名称 设备类型 三门峡移动至联通业务全阻故障 设备厂家 设备型号 32 软件版本 故障程度 故障原因 河南移动网络故障类优秀案例汇编V1.2 GMGW 故障发生时间 华为 故障恢复时间 UMG00 V200R008 业务影响范围 互联互通 省内三级 用户投诉（起） 对端设备 关键字 故障历时 4月6日12:50 故障或问题现象 4月6日14:16 1小时26分 0起 联通G网 2010年4月16日12时50分，SMXDM1出现MTP3链路故障、MTP3信令路由故障、MTP3目的信令点不可达告警，局向信息为SMXLT1（联通G网）。经检查SMXDM1上无EI/TI指示（传输告警），且检查互联互通物理传输无问题。 故障原因分析 经三门峡分公司拨打测试：本地本端正常，而对端联通至电信，固话，移动拨测均不通，且联系当地联通固网、铁通、电信公司得知同样出现到联通G网关口局目的信令点不可达告警。 查询三门峡分公司互联互通网络拓扑结构图如下： 联通固网 电 信 联通G网 移动关口局 铁 通 从网络拓扑图上可以看到联通G网端局兼做关口局，网络组网具有单点隐患。同时，结合故障现象和以上分析推断故障点为联通G网故障引起。 处理步骤说明 三门峡分公司紧急联系联通公司进行故障处理，故障恢复后就故障原因与联通公司多方沟通，联通反馈：故障深层次原因还在进一步分析中。 应急预案执行情况/解决方案 1、省监控指指挥调度中心启动了省市两级主动信息沟通发布，同时启动了重点场景和重点网元的主动监控，加强了重点区域无线网、核心网及用户投诉的实时监测； 33 河南移动网络故障类优秀案例汇编V1.2 2、三门峡分公司网络部按照重大故障处理流程进行信息上报和发布，同时积极联系联通G网跟踪故障处理。 3、由于联通G网为单关口局配置，到各运营商局向均全阻（含联通固网），故无法启动互联互通应急预案。 经验总结 此故障是由对端设备问题引起，且由于联通仅使用G网的一个端局兼做关口局，网络组网具有单点隐患，建议网络部考虑协调其它运营商设置保护路由以避免由于对端网络配置原因影响我方互联互通业务的情况再次发生。 故障报告（可插入附件） 三门峡移动至联通业务全阻重大故障分析 案例四 鹤壁DM1至联通目的信令点不可达故障案例名称 设备类型 GMGW 故障发生时间 鹤壁DM1至联通目的信令点不可达故障设备厂家 华为 故障恢复时间 设备型号 UMG00 故障历时 故障程度 省内三级 用户投诉（起） 故障原因 软件 关键字 软件版本 V200R008 业务影响范围 5月31日2:06 5月31日3:09 1小时3分 无 0起 目的信令点不可达 故障或问题现象 2010年5月31日2时06分，HEBDM1出现单板故障告警，故障定位为：3框2槽，板组号2 前插板SPF，故障原因为“软件异常”，故障时长：1分钟30秒。 同时，HEBDM1至联通出现两条“目的信令点不可达告警”，分别为： （1）目的信令点为FF10FC，目的网元为：HEBLT； （2）目的信令点为“FF38D4”，目的网元为：HEBLT1MGW。 故障原因分析 1、查询单板故障告警，故障定位为3框2槽，板组号2 前插板SPF，故障原因为“软件异常”。 34 河南移动网络故障类优秀案例汇编V1.2 分析SPF单板为信令处理板，完成TDM信令的处理，此告警原因为单板运行过程中，可能软件运行异常，自动复位，或与本框主控板之间通信不畅，规定时间为12S没有发生心跳消息到主控板，被主控板复位。 3、 分析设备告警，发现目的信令点不可达的告警指示为： （1）目的信令点为FF10FC，目的网元为：HEBLT。 原因分析：该目的信令点不是现在鹤壁联通与我公司直连的信令点，此信令点在2009年4月之前由联通公司使用，4月份联通公司新关口局入网后，该信令点已不再使用，该信令点下面的信令链路已全部删除，因此出现目的信令点不可达，但却没有出现信令链路故障告警。 此告警是由于现网垃圾数据没有及时清理所致。 （2）目的信令点为“FF38D4”，目的网元为：HEBLT1MGW。 原因分析：该目的信令点为目前鹤壁移动与鹤壁联通直连的MGW的信令点，鹤壁联通关口局为软交换关口局：MSS和MGW分离。我公司MGW与联通公司MGW之间有物理连接和信令链路直连，但在软交换组网架构中，MGW仅用作MTP信令转接功能，实际的目的信令点应指向MSS。此条告警需手动恢复，无实际意义，不影响业务。 3、经以上分析出来确定具体故障原因为：HEBDM1的3框2槽2组SPF单板运行中检测到软件异常，单板启动自动复位后恢复正常，单板复位后重新刷新告警库导致原来手动恢复的告警重新出现。 处理步骤说明 HEBDM1的3框2槽2组的SPF单板由于检测到软件异常启动自动复位，单板复位后重新刷新告警库导致原来手动恢复的告警重新出现，经重新手动清除告警后，故障恢复。 应急预案执行情况/解决方案 无 经验总结 此告警由于现网垃圾数据没有及时清理导致。因此，鹤壁分公司申请删除目的信令点为FF10FC，目的网元为：HEBLT的相关信令数据，同时要求鹤壁分公司加强网元告警监控，观察该SPF单板运行情况，如再出现异常需及时更换故障单板。 故障报告（可插入附件） 35 河南移动网络故障类优秀案例汇编V1.2 鹤壁DM1至联通目的信令点不可达告警故障 案例五 周口GM6中秋节话务溢出的问题分析 案例名称 设备类型 MSS 故障发生时间 周口GM6中秋节话务溢出的问题分析 设备厂家 诺西 故障恢复时间 9月22日20:22 9月22日21：0 故障或问题现象 2010年9月22日19:00左右，ZKGM6出现告警3294和3311，所在软交换开始出现大量clear code 843，接通率降低。 2010年9月22日20时22分，ZHKGM6所属的MSS，ZZGS21出现2099号告警（LIMIT FOR UNSUCCESFUL CALLS EXCEEDED）告警。经查询，18时58分监控MGW lincence流量时曾发现ZKGM6 lincence占有超过80%，同时ZKGM6上出现3311号告警（SIGNAL PROCESSING RESOURCE SHORTAGE），提示TCU资源不足。联系周口分公司进行拨打测试，在ZHKGM6下，做被叫正常，但做主叫时5个呼叫中只有2个正常接通。 故障原因分析 9月22日为农历中秋节，由于忙时高话务量，ZHKGM6设备处理能力不足，造成ZKGM6所在ZZGS21显示接通率较低。 处理步骤说明 1、 查看MGW上3311告警，提示TCU资源不足，查看MGW上TCU，TCU数量为61个，同时呼叫能力并未超出LICENCE，怀疑资源不足的并不是TCU。 2、 为均衡话务，减弱高话务冲击，在ZZGS21以及ZHKGM6上，新建VMGW，均衡到其他11小时3分 设备型号 IPA2800 故障历时 软件版本 U3 业务影响范围 周口淮阳县部分用户业务 0起 2099 故障程度 省内三级 用户投诉（起） 故障原因 设备容量 关键字 36 河南移动网络故障类优秀案例汇编V1.2 ISU。创建VMGW并均衡到其他ISU后效果并不明显。 3、 因均衡效果不明显及TCU数量较多，判断不是资源不足，而是资源吊死，因此尝试重启ZZGS21上TCU。手工重启一半TCU后，发现效果并不明显。 4、 在TCU重启无效果后，立即通知周口分公司降低功率，减少话务吸收，避免因高话务引发雪崩效应。周口将淮阳的几个BSC功率逐渐下调。 5、 6、 21：00后长途接通率逐步上升，联系分公司拨测，主叫呼叫逐渐恢复正常 21:10分2099告警自动回复。 应急预案执行情况/解决方案 1、 加快新建设备未入网，缓解现网的高话务冲击。 2、 组建周口的MSC POOL。 3、 加快ZKGM6的U4硬件升级工作。 经验总结 根据特殊节假日的忙时话务量提前增加网络资源配置。 故障报告（可插入附件） 关于ZKGM6中秋节话务溢出的问题分析.doc 案例六 多个关口局Server出现M3UA路由不可用、双归属心跳丢失故障 案例名称 设备类型 CE 多个关口局Server出现M3UA路由不可用、双归属心跳丢失故障 设备厂家 华为 设备型号 NE40E 软件版本 V300R003C02B697 故障发生时间 故障恢复时间 9月26日9:59 9月26日10:35 故障或问题现象 2010年9月26号9:59分，长途软交换北环节点网元ZZSSA2、ZZSSA4分别出现至ZZDM1、XCHDM2、 37 故障程度 省内三级 故障原因 硬件 故障历时 业务影响范围 用户投诉（起） 关键字 36分钟 无 0起 M3UA/双归属/CE 河南移动网络故障类优秀案例汇编V1.2 ZZDS101、ZZGS103、PDSDM2等网元SCTP路径故障，M3UA链路故障和M3UA路由不可用告警，此外，ZZDS1/2，ZZDS3/4出现双归属心跳丢失告警，ZZGS10/ZZGS11/ZZGS14/ZZGS15/ZZGS27/ZZGS40/ZZGS41/ZZGS27出现Clear code 885（MGW INTERNAL FAILURE）。 故障原因分析 1、根据大量网元出现M3UA链路失败、SCTP链路失败的告警，初步判断为IP通路有问题； 2、对告警网元进行归类分析，关口局和端局告警网元集中下挂在北环六楼ZZSC1/2，判断是CE与承载网连通性问题。 详见下图： 处理步骤说明 1、对告警网元进行归类分析，关口局和端局告警网元集中下挂在北环六楼ZZSC1/2。立即通知CE和IP承载网协查处理，检查IP网情况。 2、登录北环六楼软交换所属CE(ZZSC1/2)查看，日志及路由表均正常，但从CE2上测试到远端SSA2地址时不通，跟踪ip路径，第一跳（郑州AR2）就不通，测试CE2至郑州AR2直连接口的连通性不通 ，联系AR侧测试结果相同； 3、判断是直连接口转发故障，决定关闭互联接口，让业务从ZZCE1迂回。关闭直连接口后， 38 河南移动网络故障类优秀案例汇编V1.2 软交换SSA/GS/DS所有告警于10:35分全部恢复。 4、9月27日凌晨经过华为厂家进一步定位，确认为接口板卡硬件故障并进行了硬件更换，并督促厂家给出详细故障分析，避免类似故障再次发生。 应急预案执行情况/解决方案 未启动应急预案/更换硬件 经验总结 设备硬件损坏没有告警，督促厂家研发新版本避免此问题再现 故障报告（可插入附件） 河南移动一般通信故障报告模板-201009 案例七 智能网SMP服务不可用故障 案例名称 设备类型 SMP 智能网SMP服务不可用故障 设备厂家 华为 设备型号 HP RP7410 软件版本 IBM IDS Version 9.40.FC7W4 故障发生时间 故障恢复时间 故障历时 业务影响范围 10月30日7:02 10月31日9:50 26小时48分钟 全VPMN销户 故障或问题现象 2010年10月30日7时02分，智能网I2000出现ENIP OAMS958_SMP-100010服务不可用、连接不到服务进程告警。 故障原因分析 10月29日晚华为工程师进行SMP数据库的表格重建，从而达到释放数据库空间、优化表格的目的。10月30日凌晨由于m_phone表格（数据量为1167万）无法创建成功。 10月30日7：00，SMP对V网相关的MML进程进行终止，此时产生“SMP服务不可用”的告警。 39 故障程度 省内三级 故障原因 软件 用户投诉（起） 关键字 省开0起 SMP、m_phone、表格重建 河南移动网络故障类优秀案例汇编V1.2 处理步骤说明 1、10月30日6：30，工程师反映SMP的m_phone表格在导入过程占用extents增长过快，6：50提示无可用空间。 2、10月30日7：00，SMP中止集团V网、家庭V网的MML进程，开机提醒、分时分区、充值等业务进程放开对外提供服务。此时重新删除较大容量表格，采用先建m_phone表格的技术方案，开始进行第二次的表格重建。 3、10月30日10：30，SMP创建m_phone仍提示没有可用空间。此时工程师采用分配大容量extents的进行的技术方案进行第三次m_phone表格重建。 4、10月30日13：30，SMP创建m_phone在尚余100万用户数据的最后阶段，extents占用达到上限，第三次表格重建失败。 5、10月30日13：50，华为工程师经咨询HP工程师后，确定对SMP扩容4g数据库空间，开始进行第四次表格重建，17：10m_phone表格数据导入完成，占用extents为79。最后进行主键生效、索引生效。19：40m_phone索引生效。10月31日1点06分由于网络中断主键生效被中止。1：30分删除主键，然后重新创建主键，9：30主键创建成功，9：50SMP的V网进程对外提供服务，此时SMP正常对外提供全部服务。 应急预案执行情况/解决方案 SMP表格重建的原因为m_phone表格占用的extents已经达到上限，设备无法增加新的用户。由于SMP设备型号较老，数据库存储空间不足，导致释放空间后表格重建和索引重建出现反复。1、10月30日上午执行应急预案，开机提醒、分时分区、充值卡等业务可以正常开销户。 2、10月31日上午SMP设备表格重建成功后，联系业务支援中心执行应急预案，将10月30日至10月31日执行失败的集团V网和家庭V网指令重新执行，保证了用户业务的正常订购，无用户投诉发生。 3、经过紧急协调华为公司进行硬盘借货，11月12日凌晨成功对智能网SMP数据库硬盘进行扩容，扩容前数据库空间为30G，扩容后数据库空间为50G。整体扩容操作正常，扩容后不仅增加了数据库空间，而且提高了SMP数据库的插入、查询等性能。 4、智能网十二期工程中新型SMP的入网将彻底解决SMP设备的性能问题。 经验总结 当设备的性能即将达到上限时，常规的线性预测将变得不可行。以m_phone表格重建为例，3月31日此表格承载的用户为958万，重建耗时5小时，10月30日表格承载的用户为1167 40 河南移动网络故障类优秀案例汇编V1.2 万，重建共耗费14小时50分钟，其中仅索引生效就耗时8小时。经测试在新型SMP设备中2000万的用户数据表格重建仅需要2小时。此类问题最好的解决办法是提前考虑硬件扩容或设备替换。 故障报告（可插入附件） 2010年10月30日智能网SMP服务不可用故障 3、 无线网优秀故障案例 案例一 新乡部分用户投诉不能主被叫和使用GPRS业务故障 案例名称 设备类型 BTS 故障发生时间 新乡部分用户投诉不能主被叫和使用GPRS业务故障 设备厂家 诺西 故障恢复时间 设备型号 BSC 故障历时 软件版本 S14 业务影响范围 1月8日8:14 1月8日9:00 46分钟 辉县、卫辉县部分地区 故障程度 省内三级 用户投诉（起） 183起 SC5、6到AR链路瞬断后导致部分小区假活 故障或问题现象 2010年1月8日8时14分开始，省监控投诉人员陆续接到辉县、卫辉县部分用户投诉：手机无网络信号，无法做主被叫和使用GPRS业务。经查询无设备告警。 故障原因分析 1月8日凌晨华为工程师进行CE-AR链路扩容调测操作（工单编号HA-508-100106-00083）。按照工单要求，华为工程师在0：00-4：00之间依次断开SC5、SC6到AR的两条链路并进行测试。在测试过程中SC5、6到AR出现了链路瞬间闪断现象，链路恢复正常后查看核心网元和相关BSC网元均无任何异常告警，之后测试人员又按照扩容调测要求进行了拨打测试，测试结果均正常。 在8时14分陆续接到用户投诉反映手机无网络信号，无法做主被叫和使用GPRS业务。经过初步分析统计这些用户多位于XXBSC26、30、33下。查询网元告警发现从8：00开始XXBSC26、30、33出现大量7738告警，该告警示意为基站长时间无用户占用触发。这些网元都在SC5、SC6下， 41 故障原因 软件 关键字 河南移动网络故障类优秀案例汇编V1.2 初步判断与凌晨CE-AR链路扩容调测操作有关。进一步详细分析原因，由于扩容调测过程中SC5、6到AR链路瞬断后导致部分小区假活，受限于凌晨话务量较低没有及时反映出来，在忙时话务量逐渐增大，部分基站无法正常通信的故障逐渐反映出来，从而引发大量客户投诉。 处理步骤说明 针对小区假活的情况，维护人员将所有出现7738告警的小区ID从现网提取出来，用ZEFS命令逐一从BCF进行重启，维护人员现场测试正常，回访投诉客户也均可正常使用业务，至1月8日9：00出现7738告警的小区均恢复，至此，新乡部分用户投诉不能主被叫和使用GPRS业务的故障得到彻底解决。 应急预案执行情况/解决方案 解决方案： 1、问题可以定位为SC5、6到AR链路瞬断后导致部分小区假活，受限于凌晨话务量较低没有及时反映出来，在忙时话务量逐渐增大，部分基站无法正常通信的故障逐渐反映出来，从而引发大量客户投诉。 2、BSC维护人员对出现7738告警的小区用ZEFS命令逐一从BCF进行重启后，故障消失，业务测试正常。 执行情况：新乡公司机房值班人员接到用户投诉后初步判断为网络故障，立即启动故障应急处理流程：通知技术人员赶赴现场、上报网络部经理，并迅速报告省网管中心监控室、话务室、数据室。 经验总结 1、严格要求厂家工程师按照规范要求进行工程割接调整，并在工程割接结束后进行详细的拨打测试，并安排专人进行24小时值守； 2、要求维护人员做好日常网络维护，做到防患于未然； 3、已建议华为、诺西厂家对该故障做深层次的分析，杜绝类似故障再次发生。 本故障中工程调整对现网的影响是相当大的，由于故障发生在凌晨话务量较低的时候，给故障处理人员造成一定的错觉。所以在后续的工程调整过程中，需要做好精细化维护，现场测试与告警监控双管齐下，避免类似故障的再次发生。 故障报告（可插入附件） 新乡出现部分用户不能主叫和使用GPRS业 42 河南移动网络故障类优秀案例汇编V1.2 案例二 郑州科技市场附近用户投诉手机无信号故障 43 河南移动网络故障类优秀案例汇编V1.2 案例名称 设备类型 BSC 故障发生时间 郑州科技市场附近用户投诉手机无信号故障 设备厂家 诺西 故障恢复时间 设备型号 BSC2000 故障历时 软件版本 S12CD9.0 业务影响范围 科技市场附近用户 150起 2478 BAR 升级 故障程度 省内三级 用户投诉（起） 故障原因 软件 关键字 2月7日9:20 2月7日11:00 1小时40分钟 故障或问题现象 2010年2月7日9时20分，省监控投诉人员接省客服中心通知郑州科技市场附近用户投诉手机无信号。ZZBSC118上历史告警有2478告警。影响范围：郑州文化路东风路附近，科技市场附近，文化路小铺路附近，信息工程学院，轻工学院，小铺，金水区委附近等区域。经查询无相关设备告警。 故障原因分析 1、 检查BSC历史告警，发现同一MSC下其它BSC有2478告警闪出，联系话务室，发现2月6日晚上话务室进行了CE的调整，怀疑与此有关； 2、 重启基站BCF，基站起来后观察发现没有用户占用。 3、 根据CE中断后，2478告警MSC收不到BSC的global reset 消息，可能BSC小区数据吊死； 4、 诺西公司于2月7日下午正式确认省内BSC版本为CD9 且RC0_BGSX文件版本为17.116的共计18台BSC设备存在软件缺陷。当三种触发条件（MSS重启、BSC重启、IP网络断链）出现时，存在部分基站可能无法起呼的网络隐患。 处理步骤说明 针对此BSC，对所有小区执行ZEQF:SEG=XX:BAR=N； 经过在BSC上观察和现场拨测，用户占用正常，故障得到解决。 1、针对诺西BSC S12 CD9.0软件缺陷问题，厂家提出了版本倒回的方案，郑州地区5台BSC于2月11日进行了升级。 2、由于春节临近，为保证网络安全，我省其他地区版本倒回的方案计划在春节后3月上旬实施。 应急预案执行情况/解决方案 为保障春节期间网络安全，经公司网络部和网管中心共同讨论，制定了临时应急保障预案。 （1）针对新乡BSC32、33、驻马店BSC31、平顶山BSC30、31和洛阳BSC45、46、47、开封BSC12、 44 河南移动网络故障类优秀案例汇编V1.2 24、南阳BSC44、45、46共计13台此版本的BSC设备，新乡、驻马店、平顶山、洛阳、开封、南阳六个分公司密切注意上述BSC网元，并预编写好macro，任何时间出现BSC 2478，20告警（上述两个告警和网元阻断有关），立即执行BSC全部小区debaring指令：ZEQF:SEG=XX:BAR=N； （2）六个分公司在每天凌晨6点左右，使用ZAHP指令查询上述十台BSC历史告警，一旦发现2478或20告警，立即执行BSC全部小区debaring指令：ZEQF:SEG=XX:BAR=N；春节期间将该措施，写入交制度，并按时执行； （3）从2月10日18点起，监控室针对BSC 2478，20告警实行7*24小时无时延监控派单，以便及时发现并解决 。 （4）3月16日-23日完成所有缺陷BSC的版本倒回工作。 经验总结： 1、针对BSC网元要时刻监控重大告警，出现告警后及时分析原因，避免产生更大的故障； 2、针对可能产生的2478等告警，制定应急解决办法，如：ZEQF:SEG=XX:BAR=N；等； 3、认真研究升级文档，发现软件中存在的隐患，避免盲目升级。 4、对BSC的当前告警和历史告警要认真分析，针对潜在的可能影响业务的告警要及时上报，并联系网优进行现场测试； 5、针对软件BUG引起的重大故障，即时进行版本升级或版本倒回，避免产生用户投诉和更为严重的故障。 故障报告（可插入附件） 郑州科技市场附近用户反映手机无信号故 案例三 商丘BSC33 Gb link中断故障 案例名称 商丘BSC33 Gb link中断故障 设备类型 BSC 故障发生时间 9月3日 15:39 设备厂家 诺西 故障恢复时间 9月3日 17:04 2小时25分 设备型号 BSC 2000 故障历时 软件版本 S14 CD5.01 业务影响范围 故障程度 省内三级 用户投诉（起） 民权县部分用0起 户GPRS业务。 环路 SWU 故障原因 人为 关键字 45 河南移动网络故障类优秀案例汇编V1.2 故障或问题现象 2010年9月3日15时39分，商丘BSC33频繁出现3019、3020、3025告警，部分GBlink出现中断。 故障原因分析 SQBSC33 S14软件升级时，工程师将SUW3的数据误配置为SWU9。 处理步骤说明 2010年9月3日接省数据室通知SQBSC33出现双主现象，进入SQBSC33的SWU2查看数据，发现SWU2 至SWU3互联的24口为DOWN状态，检查配置数据及互联线均正常。进入SWU3查看数据，发现进入后为SWU9,当时以为开局时名字配置错误，没有太在意。查询数据后发现24口、25口互联口数据未配置，25口至CE的数据VLAN配置为01。 SQBSC33_SWU9>en SQBSC33_SWU9#sh int ============================================================================== |Port |Name |Type |State |Link|DuplSpeed|Flow |Backpres|Default Vlan +-----+--------+--------+-------+----+---------+-------+--------+------------- 1/1/1 TO-SWU3~ 100TX L3 enable up full-100 disable disable 0001 1/1/2 TO-SWU8~ 100TX L3 enable up full-100 disable disable 0001 1/1/3 100TX L3 disable down unknown disable disable 0001 1/1/4 BCSU10-~ 100TX L3 enable down unknown disable disable 2000 1/1/5 BCSU10-~ 100TX L3 enable up half-100 disable disable 2000 1/1/6 BCSU10-~ 100TX L3 enable up half-100 disable disable 2000 1/1/7 100TX L3 disable down unknown disable disable 0001 1/1/8 100TX L3 disable down unknown disable disable 0001 1/1/9 BCSU9-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/10 BCSU9-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/11 BCSU9-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/12 100TX L3 disable down unknown disable disable 0001 1/1/13 100TX L3 disable down unknown disable disable 0001 1/1/14 BCSU8-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/15 BCSU8-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/16 BCSU8-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/17 100TX L3 disable down unknown disable disable 0001 1/1/18 100TX L3 disable down unknown disable disable 0001 1/1/19 BCSU7-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/20 BCSU7-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/21 BCSU7-P~ 100TX L3 enable down unknown disable disable 2000 1/1/22 100TX L3 disable down unknown disable disable 0001 46 河南移动网络故障类优秀案例汇编V1.2 1/1/23 1000SX disable down unknown disable disable 0001 1/1/24 1000SX disable down unknown disable disable 0001 1/1/25 10-1000T disable down unknown disable disable 0001 1/1/26 10-1000T disable down unknown disable disable 0001 将24口、25口数据重新配置完成后，端口正常为UP状态， SQBSC33_SWU9>en SQBSC33_SWU9#sh int ============================================================================== |Port |Name |Type |State |Link|DuplSpeed|Flow |Backpres|Default Vlan +-----+--------+--------+-------+----+---------+-------+--------+------------- 1/1/1 TO-SWU3~ 100TX L3 enable up full-100 disable disable 0001 1/1/2 TO-SWU8~ 100TX L3 enable up full-100 disable disable 0001 1/1/3 100TX L3 disable down unknown disable disable 0001 1/1/4 BCSU10-~ 100TX L3 enable down unknown disable disable 2000 1/1/5 BCSU10-~ 100TX L3 enable up half-100 disable disable 2000 1/1/6 BCSU10-~ 100TX L3 enable up half-100 disable disable 2000 1/1/7 100TX L3 disable down unknown disable disable 0001 1/1/8 100TX L3 disable down unknown disable disable 0001 1/1/9 BCSU9-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/10 BCSU9-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/11 BCSU9-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/12 100TX L3 disable down unknown disable disable 0001 1/1/13 100TX L3 disable down unknown disable disable 0001 1/1/14 BCSU8-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/15 BCSU8-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/16 BCSU8-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/17 100TX L3 disable down unknown disable disable 0001 1/1/18 100TX L3 disable down unknown disable disable 0001 1/1/19 BCSU7-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/20 BCSU7-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/21 BCSU7-P~ 100TX L3 enable down unknown disable disable 2000 1/1/22 100TX L3 disable down unknown disable disable 0001 1/1/23 1000SX disable down unknown disable disable 0001 1/1/24 to-swu2 1000SX enable up unknown disable disable 0001 1/1/25 to-dc 10-1000T enable up full-100 disable disable 2000 1/1/26 10-1000T disable down unknown disable disable 0001 在配置完成后SQBSC33随即出现大量3019、3020、3025告警，部分GBlink出现中断，马上将SWU3的24口互联线中断，GBlink恢复正常。再次认真检查SWU3数据发现，所有端口数据配置均不对，和之前BSC健康检查的SWU3、9的数据比对，发现此SWU3配置 47 河南移动网络故障类优秀案例汇编V1.2 数据为SWU9的数据。由于SQBSC33在8月26日进行了S14的软件升级，联系升级工程师，经确认为当晚导入数据时将SWU3的数据错为SWU9的数据。按照工程师提供的升级当天提取的SWU3的数据，重新进行配置后，SQBSC33恢复正常，双主现象也消失。 SQBSC33_SWU3# SQBSC33_SWU3#sh int ============================================================================== |Port |Name |Type |State |Link|DuplSpeed|Flow |Backpres|Default Vlan +-----+--------+--------+-------+----+---------+-------+--------+------------- 1/1/1 TO-SWU5~ 100TX L3 enable up full-100 disable disable 0001 1/1/2 TO-SWU9~ 100TX L3 enable up full-100 disable disable 0001 1/1/3 100TX L3 disable down unknown disable disable 0001 1/1/4 BCSU10-~ 100TX L3 disable down unknown disable disable 2000 1/1/5 BCSU3-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/6 BCSU10-~ 100TX L3 disable down unknown disable disable 2000 1/1/7 100TX L3 disable down unknown disable disable 0001 1/1/8 BCSU2-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/9 BCSU2-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/10 BCSU2-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/11 BCSU9-P~ 100TX L3 disable down unknown disable disable 2000 1/1/12 100TX L3 disable down unknown disable disable 0001 1/1/13 BCSU1-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/14 BCSU1-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/15 BCSU1-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/16 BCSU8-P~ 100TX L3 disable down unknown disable disable 2000 1/1/17 100TX L3 disable down unknown disable disable 0001 1/1/18 BCSU0-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/19 BCSU0-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/20 BCSU0-P~ 100TX L3 enable up half-100 disable disable 2000 1/1/21 BCSU7-P~ 100TX L3 disable down unknown disable disable 2000 1/1/22 100TX L3 disable down unknown disable disable 0001 1/1/23 1000SX disable down unknown disable disable 0001 1/1/24 TO-SWU2~ 1000SX enable up full-1000 disable disable 0001 1/1/25 TO_SHQ-~ 10-1000T enable up full-100 disable disable 2000 1/1/26 10-1000T disable down unknown disable disable 0001 应急预案执行情况/解决方案 48 河南移动网络故障类优秀案例汇编V1.2 本故障是由于在升级中将SWU3的数据误配置成SWU9，而在故障处理中，又按照常规将SWU3的24、25口配置成互联及至CE的端口，导致产生网络风暴，不过不及时采取应急措施将会导致全部或大部分BCSU单元出现FLTY信息，BCSU轮流进行切换，根据目前河南移动gb over ip拓扑结构 每个SWU单元与2个或3个SWU单元相连，在极端情况下可能形成3个环路： 这个三个环路的共同点是都包含了SWU2和SWU3,因此当发生广播风暴时最迅速的处理方法是建议直接拔掉SWU2单元的ESB插板，将其环路断开后，广播风暴自然停止。 经验总结 1、 在进行网络升级前，需提前对现网数据进行备份，对升级数据要做到一人制作一人核查，确保无误。 2、 在升级时，要仔细认真，确保修改的网元正确及修改数据的准确，在修改完成后，要对数据重新进行核查。 3、 完成升级后，要将升级后的现网数据和升级前的数据进行核对，确保准确。 4、 在处理故障时，要全面细致分析，避免经验主义，在出现紧急情况时，要严格按照应急预案的要求，做到先抢通业务再恢复故障。 故障报告（可插入附件） 49 河南移动网络故障类优秀案例汇编V1.2 河南移动一般通信故障报告模板.doc 案例四 新乡BSC软件缺陷导致Gb link中断故障 案例名称 设备类型 BSC 故障发生时间 新乡BSC软件缺陷导致Gb link中断故障 设备厂家 诺西 故障恢复时间 12月15日 15:39 12月15日 16:06 27分 设备型号 BSC 故障历时 软件版本 S14 业务影响范围 辉县、卫0起 辉、长垣、封丘等部分地区用户的GPRS业务 PCU软件BUG 网络风暴 故障程度 省内三级 用户投诉（起） 故障原因 软件 关键字 故障或问题现象 2010年12月15日15时39分，新乡BSC25/29/30/31/32/33出现GB link中断告警，告警号：3019、3020、3025、3031。 故障原因分析 新乡BSC27在退网期间进行RG10 MP5.0升级时，工程师未拔掉BSC27连接CE的GB数据网线进行操作（至少断开一个平面的网线可以避免网络风暴发生），引起数据业务网网络风暴，导致XXBSC25、XXBSC29、XXBSC30、XXBSC31、XXBSC32、XXBSC33同CE下共六个BSC上的GBlink出现闪断。诺西RG10 MP5.0在升级过程中PCU存在软件BUG，在升级期间可能会引起网络风暴。 处理步骤说明 初步判断新中大道到GB的IP承载网6506设备下的XXBSC27出现网络风暴，随即通知诺西工程师进行处理。经核实XXBSC27在退网期间诺西工程做RG10的软件版本升级，由于此版本存在缺陷，有可能会导致网络风暴。维护人员将XXBSC27上到CE的的一个平面断开后，故障恢复，业务恢复正常。 应急预案执行情况/解决方案 1、检查告警和系统状态，确认系统运行正常。 50 河南移动网络故障类优秀案例汇编V1.2 2、关注BSC设备硬件连接，将XXBSC27上到CE的的一个平面断开后，故障恢复，业务恢复正常。 经验总结 退网BSC在做RG10 MP5.0升级期间存在影响其他BSC的隐患，在以后升级过程中监督诺西工程师断开一个GB平面，防患于未然。 类似此种网络风暴的产生，应该能够排除软件方面原因，立即检查BSC设备连接CE的GB数据网线情况（至少断开一个平面的网线可以避免网络风暴发生）。 故障报告（可插入附件） L:\\2010故障\\十二月\\12月15日新乡多 4、 传输网优秀故障案例 案例一 商丘城域网时钟交叉板吊死引起大面积基站退服故障 案例名称 设备类型 商丘城域网时钟交叉板吊死引起大面积基站退服故障 设备厂家 设备型号 OSN7500 故障发生时间 华为 故障恢复时间 OSN7500 故障历时 4月1日21：57 4月1日22：45 48分钟 5.21.16.13 业务影响范围 商丘市区中东部、东部、南部及郊区、虞城中西部和宁陵东南部用户业务 故障或问题现象 2010年4月1日21时57分，城域网2平面汇聚层网元2515-睢阳区2（设备型号华为OSN7500）下接入层155/622H网元上所带电路均上报TU—AIS和PS告警；商丘BSC3/11/13/17/18/19/23/29/40/69出现7767（基站中断）告警，统计最高断站数达127个。 故障原因分析 省内三级 用户投诉（起） 0起 TU-AIS、PS 软件 关键字 软件版本 故障程度 故障原因 51 河南移动网络故障类优秀案例汇编V1.2 查询发现所有故障告警TU-AIS、PS均系网元2515-睢阳区2子网下网元上报，查询该网元所在的城域网2平面与其互连的汇聚层网元均无任何告警上报，这类故障一般交叉板故障导致。因为交叉板主要负责它所下挂的所有电路板到光板的业务调度，一旦出现异常即影响相关联的电路板和光板所承载的业务。 交叉板位置见下图： 处理步骤说明 22:00分，网管中心集中监控对商丘分公司派发故障工单。 22：00分，商丘接受工单，同时开始故障处理。值班人员查询该网元当前在用交叉单板为9槽位工作板，立即对之进行硬复位操作，之后查询主用交叉板能够正常倒换到保护板，但操作后观察2分钟发现所有当前告警无恢复。随即又对保护板位进行硬复位操作后，查询正常恢复到工作板，观察2分钟后发现故障依旧，由此怀疑为该设备两块交叉板同时故障或吊死，需赴 52 河南移动网络故障类优秀案例汇编V1.2 现场进行处理。 22：30分，故障处理人员携备件到达故障地点，发现单板告警灯闪烁异常，立即开始更换单板； 22：33分单板更换完毕。 22：39分，接入层网元TU-AIS告警和PS告警开始恢复，同时通知监控班查看发现基站开始逐步恢复。 22:43分，所有告警消失，故障恢复。 22：45分所有网元业务确认恢复。 应急预案执行情况/解决方案 1、网管中心启动故障信息发布流程 2、商丘启动本地传输网重大指挥调度体系。22:00通知市级传输专业重大故障处理组组长，22:01通知市级传输专业重大故障现场抢修组组长，22:03通知商丘分公司网络部经理。 3、商丘启动本地传输网2.5G及以上设备应急预案。 经验总结 该故障为网元2515-睢阳区2的华为OSN7500两块时钟交叉板T1SXCSA同时吊死，导致其下所带基站中断。通过此次故障发现一些我维护人员在故障处理中的不足： （1）在本次故障处理的速度上是有待提升，从发现告警后至赴现场处理的时间可以进行压缩；（2）维护人员对网管告警的监控力度需要更进一步加强，以对故障的发生及发展情况充分了解以便下一步处理； （3）汇聚机房维护人员在日常维护巡检力度方面需进一步加强，以便发生故障后及时响应； （4）现网维护人员的维护技能和故障处理水平需要提升，下一步我专业将进一步加强业务知识培训，加强应急演练，作为10年网络质量提升活动的一部分认真贯彻落实。 按照本地传输网网元维护细则，该设备交叉板测试为季测项目，包机人员已经于本季度1月16日进行了倒换测试，下一季度的测试工作尚未开始，测试结束已经2个月，本次故障为设备两块交叉板同时吊死造成，为避免类似事件的再度发生，下一步分公司将尽快要求维护和包机人员尽快着手第二季度倒换测试和认真按照细则执行汇聚核心层设备巡检。 故障报告（可插入附件） 53 河南移动网络故障类优秀案例汇编V1.2 商丘BSC出现7767断站告警故障报告.doc 案例二 一干SDH西部1环3系统故障 案例名称 设备类型 WDM 故障发生时间 一干SDH西部1环3系统故障 设备厂家 西门子 故障恢复时间 设备型号 无 故障历时 软件版本 无 业务影响范围 6月1日9:02 6月1日9:33 31分钟 故障或问题现象 2010年6月1日9时02分，东部环一期西门子波分河南XIY-ER1-OTM-1 2-009 192.6上报LOS，XIY-ER1-OTU2.5G-8网元脱管；9时10分，一干西部一环3系统SDH郑州-武汉倒换失败。 故障原因分析 根据现网资料，一期西门子波分192.6波所带业务恰好为一干SDH西部I环3系统，正常情况下会正常倒换，但在7时48分由于其他省故障已经导致此系统倒换，我省发生故障后导致系统倒换失败，影响河南H2至南昌、南宁、重庆、石家庄H2各1条信令电路，业务已经其他信令平面转接，不影响业务。经省网管中心维护人员通过网管具体查看后，初步确定故障原因为信阳OTU故障； 一干西部环网络拓扑图如下： 无 故障程度 省内一级 用户投诉（起） 0起 代通 故障原因 硬件 关键字 54 河南移动网络故障类优秀案例汇编V1.2 处理步骤说明 鉴于西门子故障OTU分公司没有相应备件，从郑州送至分公司需要约3小时时间，这样会导致故障时间过长。信阳OTU主要起到中继作用，根据现网性能判断，决定信阳可避开OTU直接从合分波器临时代通。 网管中心通知信阳分公司维护人员执行波道代通操作，信阳维护人员在网管中心传输室指挥下确认故障单板的跳接位置及代通位置，并进行代通操作，将光路打通后，环网恢复倒换。 应急预案执行情况/解决方案 启动《河南移动一干传输网WDM应急方案》，按照“单个光通道”故障采取应急措施，通过协调信阳分公司，采取代通方式进行了光路抢通工作。从9时15分通知分公司至9时33分代通完毕，历时18分钟，完成应急方案的执行。 经验总结 1、针对OTU单波故障，应灵活采取倒波、代通等方式，缩短故障历时； 2、做好网络监控工作，及时发现并处理告警； 3、对于可能影响全网的故障，如环上已有一点断，或已有光板故障，建议由集团或者EM省发布公告，提升该环故障等级，环上其他省公司进入应急准备状态，加快故障响应速度； 4、鉴于一干西门子设备运行时间长，承载业务量少，故障率高，希望尽快推动一干西门子设备 55 河南移动网络故障类优秀案例汇编V1.2 的退网工作。 故障报告（可插入附件） 2010年6月1日一干SDH西部I环3系统重大故 案例三 省干濮阳至安阳外线OLP故障 案例名称 设备类型 省干安阳至濮阳外线OLP故障 设备厂家 设备型号 软件版本 WDM 故障发生时间 北京中昱 故障恢复时间 中昱OLP 故障历时 OASNM6.0 业务影响范围 11月30日17:31 11月30日17:31 6秒 故障或问题现象 2010年11月30日17时31分，省干二、三、四平面DWDM安阳-濮阳监控信道互报LOS，同时产生相关OLP倒换，主光路正常，不影响业务。 故障原因分析 1、 安阳-濮阳段已加载第三方外线OLP以保护省干三个平面以及中石化专线业务，在备用路由上加载了EDFA以提升系统光功率，由于其对1510nm不具备放大功能，因此通过线路两端监控信道的LOS可推测此时外线OLP已切换至备用路由。 无 省内三级 用户投诉（起） 0起 OLP，倒换门限 软件 关键字 故障程度 故障原因 2、 经现场人员查看，省干三个平面的外线主光功率衰耗值均升高了2dB，由于系统对主光路的倒换门限设置过高，与实际收光值仅相差1-2 dB，因此当主光路轻微波动时即触发了OLP倒换。 处理步骤说明 由于OLP设备切换门限参数设置太高，光功率波动时导致主备路由发生倒换。经过查看 56 河南移动网络故障类优秀案例汇编V1.2 OLP设备网管，与实际收光值仅相差1-2 dB，以远离当前值并保证系统光功率、信噪比正常为原则对光功率门限值修改，人工倒回后告警恢复。 应急预案执行情况/解决方案 无 经验总结 1、本故障由第三方外线OLP倒换引发，从干线网管上看主光功率正常，系统瞬时倒换，等待时间过后又会恢复正常，而实际外线已切换至备用路由，因此，维护员应清楚的了解线路上哪些段落加载有外线OLP，对这些段落的倒换告警及事件应特别关注；另外，由于EDFA对1510nm波长不具备光放大功能，对第二路由加载EDFA的段落，可将线路两端监控信道的LOS、IN_POWER_LOW等告警作为主切换至备的预判条件。 2、 华为OLP是根据主备路由光功率的差异判断是否进行倒换，中昱OLP是绝对参照切换门限值判断是否倒换，即网管上人工设定一个切换门限，光功率低于切换门限会触发倒换，因此门限值的设置至关重要，门限值不能设置太高造成系统频繁倒换，同时要保证在门限以上时系统光功率、信噪比均在正常范围内。 3、华为与中昱外线OLP保护机理的对比： 华为OLP采用1+1保护，发端通过OLP分光双发，收端选收，而中昱是采用1：1保护方式，正常情况下, 主用承载通信光, 备用路由承载测试光, 通过2X2光开关互相隔离， 主用干线阻断情况下，2X2光开关交叉切换，备用路由接入通信光，同时主纤接入测试光， 57 河南移动网络故障类优秀案例汇编V1.2 通信光与测试光同样隔离,保证通信正常。 测试光是一路1550nm波长的稳定测试光源，发光功率在-2—-3dBm左右。 故障报告（可插入附件） 11月30日省二干濮阳-安阳传输光缆故障报 案例四 省干南阳至方城光缆中断故障 案例名称 设备类型 WDM 省干南阳至方城光缆中断故障 设备厂家 华为、中兴 设备型号 OPTIX 1600/ZTE M900 故障发生时间 故障恢复时间 故障历时 业务影响范围 12月7日17:43 12月7日18:40 57分钟 故障或问题现象 2010年12月7日17时43分，南阳至方城本地网光缆中断，故障发生时设备倒换成功，不影响业务。 故障原因分析 南阳分公司目前要求代维公司对维护的二干线路进行“天天巡”，我公司包片人员对其进行不定期抽查，但是此次故障为突发事件，冬季河道干枯，加之近6点时天已较黑，当地老百姓利用高速及河道管理人员下班间隙，在高速大桥下偷采沙，挖断光缆。我公司维护人员赶往现场发现偷沙人员已潜逃后，立即封锁现场并报案，同时立即投入抢修工作。 无 用户投诉（起） 0起 外线 关键字 软件版本 V100R003/ V3.09 故障程度 省内三级 故障原因 传输线路 58 河南移动网络故障类优秀案例汇编V1.2 处理步骤说明 维护人员立即通知长通代维公司，并在高新机房测试。测试结果显示该光缆在距高新机房14.71KM处中断，经现场排查，南阳-方城二干直埋光缆在岭南高速白河大桥下（36#37#标石号），被当地老百姓偷沙时挖断。18：05，维护人员开始将业务调整至备用线路，18：40，省干二、三、四平面全面恢复。代维公司对故障光缆经行修复，同时对故障现场进行24小时看护。 应急预案执行情况/解决方案 无 经验总结 2010年我省发生多起由于人为挖断光缆的故障，因此建议要求全省如下: 1、落实各项规章制度，加大对（城乡结合部）易动土地段的检查力度，加强对代维公司人员隐患地段防障思路、方法的教育，提高对不确定地段防障的敏锐性、警觉性，并将护线宣传工作落到实处。 2、及时准确掌握可能发生的外力施工动态，积极联合沿线群众，在重点地段加大发展义务宣传员的力度，提供及时有效的施工信息，将障碍控制在萌芽状态。 3、抓住防障工作的重点，加强与沿线施工单位的施工负责人员及大型机械手的联系，使施工人员了解、掌握线路标识走向等基本情况，引起施工方对线路的重视。 4、按照明显化整治的要求，对重点地段、特殊地段明显化工作进一步加强，确保类似故障不再发生。 故障报告（可插入附件） 12月7日省二干南阳-方城光缆故障报告.do 6、数据网优秀故障案例 案例一 CMNET北环两台PA路由器脱网故障 案例名称 设备类型 CMNET路由器 CMNET北环两台PA路由器脱网故障 设备厂家 华为 设备型号 NE40E 软件版本 NE40E&80E V300R003C02B697 故障程度 省内三级 故障原因 软件 59 河南移动网络故障类优秀案例汇编V1.2 故障发生时间 故障恢复时间 故障历时 业务影响范围 用户投诉（起） 关键字 1月24日21:21 1月24日21:39 18分钟 两台路由器承载的WAP及DNS业务 0起 链路中断 版本BUG 故障或问题现象 2010年1月24日21时21分，郑州北环CMNET承载的WAP及DNS业务中断，两台承载业务的路由器出现PING不通告警。 故障原因分析 两台路由器互为主备接入CMNET两个核心节点并做为业务接入路由器，在发现故障时，接口物理层是UP，链路层为DOWN，造成ISIS协议中断，使得两台路由器PING不通，造成其上承载的业务中断。通过插拔模块或关闭重启端口可使故障恢复但不能彻底解决问题。经华为研发分析，为软件BUG造成，通过给设备装载软件补丁，已彻底解决故障。 处理步骤说明 现场排查故障发现两台路由器上行链路接口掉死（接口状态灯常亮），插拔两台路由器上联接口模块，链路恢复正常，业务恢复。 应急预案执行情况/解决方案 经过华为公司分析定位故障原因为当前使用的V300R003版本和10G POS子卡(对于其他类型子卡不存在此问题)配合问题，当有32字节以下报文和其它报文混合进入子卡，卡对于报文缓存读控制异常，导致无法正常进行后续报文的读控制操作，流量中断，无法转发报文，且无法自动恢复，从而造成了本次链路故障。最终通过安装版本为V300R003C00SPH28的平台补丁进行彻底处理，补丁安装后通过观察未再出现此问题，设备及端口均运行正常。 经验总结 对应新入网的设备、板卡、模块等新类型网元，或者在网络中出现的新部署方式，割接入现网时，可以首先在一个平面进行入网，通过一定时间的观察及相关业务测试以确定其运行正常，随后再对另一平面进行入网，避免出现同时入网，否则可能造成类似的问题出现； 故障报告（可插入附件） CMNET省核心北环两台NE40E脱网故障处理报 60 河南移动网络故障类优秀案例汇编V1.2 案例二 全省部分用户发送接收短信成功率下降故障 案例名称 设备类型 短信中心 故障发生时间 全省部分用户发送接收短信成功率下降故障 设备厂家 诺西 故障恢复时间 2月4日20:10 2月4日21:20 设备型号 HP rp4440 故障历时 软件版本 SC8.1 业务影响范围 1小时10分钟 全省部分用户 280起 FTP、异常、释放、磁盘空间 故障或问题现象 2010年2月4日20时10分，省监控投诉人员接省客服中心通知接客服通知：全省有部分用户投诉不能发送和接收短信。 故障原因分析 初步判断因2月4日凌晨新入网的短信预处理平台运行异常，导致为其提供FTP文件的点对点短信中心FTP文件积压，少部分短信中心系统处理资源耗尽，导致通过该套短信中心提交和下发的短信失败。 短信中心与预处理平台之间采用FTP协议进行通信，其中预处理平台为SERVER端，短信中心为CLIENT端。通过调取短信中心、预处理平台双方日志分析，发现在FTP通信过程中出现了异常： 1. 短信预处理平台报出了磁盘空间满的告警，并采取异常方式对FTP连接进行中断（不返回应答）。 2. 短信中心侧FTP上传文件失败，产生大量的消息积压。同时，由于预处理平台不能正常返回FTP应答，导致短信中心不断尝试建立新的FTP连接，最终耗尽了系统的nfile资源，系统死机。如图： 故障程度 省内二级 用户投诉（起） 故障原因 软件 关键字 处理步骤说明 61 河南移动网络故障类优秀案例汇编V1.2 经数据网维护人员停止短信业务软件，重新启动HP-UX操作系统，并启动短信业务软件后，业务恢复。同时修改短信预处理平台与短信中心组网方案，改由Monitor系统接入 ，并对短信中心进行升级，解决FTP无法容错问题。 应急预案执行情况/解决方案 1、省监控指挥调度中心启动省内二级信息沟通发布； 2、省客服中心启动相关投诉预警。 经验总结 1、操作系统的file-sz不足造成软件无法打开文件进行读写操作，并导致软件运行异常。 2、导致操作系统的file-sz不足的根源是NSN短信中心FTP软件缺乏容错机制，而引发该问题的原因则为预处理系统磁盘空间不足。 3、2月5日 9时15分，省监控投诉人员接到省客服中心通知郑州、商丘、周口、南阳部分用户不能正常发送短信。经查询短信设备运行正常。通过对投诉用户电话采访，部分用户短信失败是因为短信中心号码设置错误导致，由于2月4日短信故障期间部分用户修改了手机中短信中心号码设置引起。投诉量达30起。 故障报告（可插入附件） NSN短信中心与预处理平台ftp通信异常导致 案例三 焦作、济源、平顶山、许昌、周口部分用户无法正常使用GPRS故障 案例名称 焦作、济源、平顶山、许昌、周口部分用户投诉无法正常使用GPRS业务故障 设备类型 IP承载网AR 故障发生时间 设备厂家 华为 故障恢复时间 设备型号 NE80E 故障历时 软件版本 V3R2 业务影响范围 以上区域部分用户600起 LPU ISIS LDP 故障程度 省内二级 用户投诉（起） 故障原因 硬件 关键字 2月11日8:10 2月11日21:20 13小时10分 62 河南移动网络故障类优秀案例汇编V1.2 的GPRS业务 故障或问题现象 2010年2月11日8时10分，省监控投诉人员接省客服中心通知：焦作、济源、平顶山、许昌、周口部分用户投诉不能使用GPRS业务。经检查核心网无异常。 故障原因分析 IP承载网汇聚全省Gb的AR设备单板异常，引起主备切换，期间造成该单板所带的焦作、济源、平顶山、许昌、周口五地市部分BSC上的部分Gb闪断后恢复。因诺西BSC设备的软件缺陷，引发五地市部分小区GPRS功能吊死，从而引起客户投诉。 处理步骤说明 8时20分开始，维护人员启动吊死小区GPRS功能重置操作，业务逐步恢复，大部分业务在10：00恢复。因涉及小区分散，且同样因NSN BSC软件缺陷，部分小区重启PAPU单元、多次重置GPRS功能、切换BCSU单元均无效，需多次尝试操作，因此所有小区经测试确认业务恢复的时间为21时20分。 应急预案执行情况/解决方案 IP承载网侧处理情况：BR设备4端口2.5G POS单板发生部分内存失效故障，导致该单板上的LDP、BFD协议状态down，随后ISIS和接口物理状态也转为down，十几秒后接口状态和协议都恢复正常。路由器自动检测到故障部分，并进行了自动处理，因此业务中断事件很短。但诺西BSC设备有软件缺陷，发生通信短时闪断后会引起部分小区GPRS功能吊死，从而引起客户投诉。 GPRS核心网侧处理情况：通过查看历史告警及地市反馈确定受影响SGSN及BSC，首先通过BSC重启BCSU单元，在无效果的情况下SGSN侧重启PAPU单元强制进行小区重新上报，经过几轮处理后吊死小区陆续恢复；与此同时，在异常小区问题原因定位之前，由网络部统一下发休眠小区管理办法，各分公司每日凌晨通过报表形式采集无流量小区日志进行比对，对流量前后两天有差异的小区进行手工小区GPRS功能重启操作。 经验总结 IP设备电信级程度不高，即使通过多种技术措施优化，仍然存在某些特殊故障会导致出现秒级的网络收敛时长，从而对造成上层业务闪断。需要设备厂家不断改进IP设备的故障检测和切换能力。另由于Gb接口IP化改造后，原由传输电路承载的Gb接口改造为IP承载网 63 河南移动网络故障类优秀案例汇编V1.2 路由，对于IP承载网的异常路由中断均需提高警惕，加大日常告警的监控力度及各类割接业务部门间的协同配合，对于一次性2条及以上Gb链路闪断的告警均要上报GPRS核心网与承载网共同处理。 同时针对诺西BSC存在软件BUG，秒级的网络中断会概率性造成部分小区吊死。需要厂家解决此软件BUG，从根本上杜绝此类问题的再次发生。在BUG未解决前，需要完善应急预案，发现小区吊死情况，迅速进行手段重启操作。 故障报告（可插入附件） 焦作，济源，平顶山，许昌，周口，南阳 案例四 MDCN南阳节点故障 案例名称 设备类型 MDCN 路由器 故障发生时间 MDCN南阳节点故障 设备厂家 CISCO 故障恢复时间 小时 南设备型号 无 故障历时 软件版本 无 业务影响范围 阳150起 MDCN PING不通 路由器 广播风暴 故障程度 省内三级 用户投诉（起） 故障原因 软件 关键字 11月5日8:59 11月5日9:59 1HLR2自动停开机业务 故障或问题现象 2010年11月5日8时59分，数据网管出现MDCN MDCN-NY-DongHuan-2811-01 和 MDCN-NY-DongHuan-2811-02两个节点PING不通告警，2台2811路由器通信中断，影响下面接入的各种业务。 9时17分，南阳HLR2出现9047告警，网元无法正常登陆。 故障原因分析 发生故障的节点设备原为cisco 7609路由器，处理性能较好 。该节点下挂了南阳账务中心 河南移动网络故障类优秀案例汇编V1.2 OA、营业厅和HLR2业务。但根据承载网4期工程计划安排，该设备利旧，做为支撑CE接入IP承载网。工程期间，用2811临时代替，接入了7609路由器下挂的各种业务终端和网元。然后，将7609设备割接进入IP承载网。2811的处理能力较7609下降了很多。 由于对2811路由器进行了冷启动，无法获取设备当时各种信息。经分析，应该是2811路由器IOS软件系统进程吊死，从而造成两台路由器同时断连。 处理步骤说明 1、登陆MDCN网设备，发现这两台设备登陆不上，通过登陆上联设备，发现接入这两台设备端口状态为“UP”，但是却PING不通互联地址。 2、通知南阳数据班维护人员前去处理。南阳维护人员赶到机房现场，对设备进行重启后 ，故障恢复。 应急预案执行情况/解决方案 由于设备IOS进程吊死，无法登录设备。根据《河南移动数据网MDCN应急预案》第6章应急措施第1节总体原则的规定：优先保障、恢复业务。所以不想办法登录设备分析原因，直接重启设备，恢复业务。 经验总结 对于路由器登录不上的原因有两种，一种是本案例的原因，即路由器系统软件IOS的bug造成进程吊死。对于这种原因没有太好的办法，只有实时关注设备厂商官方网站所发布系统软件的信息，及时对系统软件进行升级或打补丁操作。另外一种原因会经常遇到，就是二层环路造成的广播风暴。对于这种情况的避免方式，再接入业务时尽量少使用二层方式。如果发生广播风暴，可以立即关闭一个平面，打破这个环路。然后将这个平面上所有业务全部断开，再打开这个平面，将业务一个一个重新接入到这个平面上，观察网络情况，来定位具体是哪个业务造成的环路。 由于路由器的相关信息是存储在缓存上面，一旦重启，这些缓存就会被清空，这些信息就会提取不到。因此，在处理路由器故障时，尽量避免使用重启路由器这种手段。 故障报告（可插入附件） MDCN南阳节点故障报告--20101105.doc 65 河南移动网络故障类优秀案例汇编V1.2 案例五 周口BSC27/28 Gb link中断故障案例名称 设备类型 SGSN 故障发生时间 故障程度 省内三级 用户投诉（起） 故障原因 硬件 关键字 软件版本 SG6PCD13.0.2 业务影响范围 周口BSC27/28 Gb link中断故障设备厂家 诺西 故障恢复时间 设备型号 DX200 故障历时 8月9日 17:50 8月9日 32分 18:22 故障或问题现象 郸城西南部、沈0起 丘县东南部用户GPRS业务。 Gb link 2010年8月9日17时50分，周口BSC27、28出现大量3019、3020 Gb link中断告警。周口BSC27、28在诺西SGSN5_PAPU2下，经查询，PAPU2单元的工作状态正常。 故障原因分析 经查询，17时49分，PAPU0出现异常，系统自动将PAPU0切换到PAPU2；但是PAPU2未能承载起业务，在单元状态等均正常的情况下Gb全部中断，于18时22分，手动切换PAPU之后业务恢复，但是业务还是切回了PAPU0上。PAPU的状态变化如下： PAPU的状态变化告警如下： 河南移动网络故障类优秀案例汇编V1.2 0691 AUTOMATIC RECOVERY ACTION SE-OU TE-EX C000 0003 6033 00000000 00000000 00000000 0691 AUTOMATIC RECOVERY ACTION TE-EX SP-RE C000 0003 6033 00000000 00000000 00000000 0691 AUTOMATIC RECOVERY ACTION SP-RE SP-EX 0020 00A0 0855 00000000 00000000 00000000 0691 AUTOMATIC RECOVERY ACTION SP-UP SP-EX 4EB5 00A0 0818 00000000 00000000 00000000 0691 AUTOMATIC RECOVERY ACTION SP-RE SP-EX 0022 00A0 0855 00000000 00000000 00000000 PAPU2的Gb恢复告警如下： (9422) 3019 NETWORK SERVICE ENTITY UNAVAILABLE 67 河南移动网络故障类优秀案例汇编V1.2 E86E 1、PAPU0故障的原因。从PAPU0的1078、1024告警上看，PAPU0的进程运行异常，但是从2770告警上看，可能是IOCPE异常导致的软件运行异常。在PAPU0的computer log上可以看到一些关于Piu ind: 3的not ok的日志，而从硬件配置上看，Piu ind: 3是PAPU0的IOCPE板。因此可以推断是PAPU0的IOCPE出现了异常导致的PAPU0切换到PAPU2。需要更换PAPU0的IOCPE单板，但后观察其computer log中是否还会有Piu ind: 3的“JUTMAS: Preprocessor not ok!”异常日志。 1078 PROCESS EXCEPTION 03F2 0001 06 0060 00000BD9 1024 HAND PROCESS ERROR IN PROGRAM BLOCK 07 0d 01 0000 00 0000 0000 0000 00 (9420) 2770 PREPROCESSOR UNIT FAILURE IOCP_E 2d 127d 00A0 CALLER : 03F2 0000 00 RETURN ADDRESS: 0940 (G0296).00000219 WRITE TIME: 2010-08-09 18:18:29.88 PARAMETERS: E-08 0938.00000021 0000003C 0938.00000004 USER TEXT : JUTMAS: Preprocessor not ok! USER DATA : .Piu ind: 3,send comp: 0x20,send fam: 0xbe,msg num: 0x3200 . 需要更换PAPU0的IOCPE板。 2、PAPU2故障原因。PAPU2的computer log中有大量的Piu ind: 3的“JUTMAS: Preprocessor not ok!”异常日志，说明PAPU2的IOCPE异常，需要更换IOCPE或者CPU，在更换之后需要将 68 河南移动网络故障类优秀案例汇编V1.2 业务切换至PAPU2，观察其运行情况以及分析其computer log。 CALLER : 03F2 0000 00 RETURN ADDRESS: 0940 (G0296).00000219 WRITE TIME: 2010-08-09 18:29:18.34 PARAMETERS: E-08 0938.00000021 0000003C 0938.00000004 USER TEXT : JUTMAS: Preprocessor not ok! USER DATA : .Piu ind: 3,send comp: 0x22,send fam: 0xbe,msg num: 0x3200 . 需要更换PAPU2的IOCPE板。 处理步骤说明 18时22分，经切换PAPU2后业务恢复正常。业务正常后对PAPU2进行了硬件诊断，发现PQU异常，由于软件版本升级后PQU已经不再使用，因此删除PQU的硬件数据再次诊断通过；在PAPU2的单元日志上看到IOCPE的异常日志，更换PAPU2的IOCPE后将业务切换至PAPU2，观察PAPU2没有再出现异常日志，业务运行正常。 应急预案执行情况/解决方案 SGSN设备老化，硬件故障率比较高，平时加大设备巡检力度，增加设备健康检查频次，在设备容量允许的条件下，降低老化设备所带业务，逐步由新上设备替换。 经验总结 首先应对spare单元进行硬件诊断后再进行单元切换，以保证备用单元的真实可用性，另一方面SGSN设备老化，硬件故障率比较高，应加强运行状态监控。 故障报告（可插入附件） 周口BSC27 28的Gb中断告警故障报 7、网管网优秀故障案例 案例一 全省MSS、MGW网元以及部分MSC、BSC网元远程登陆不成功故障 案例名称 设备类型 服务器、防火墙 故障发生时间 全省MSS、MGW网元以及部分MSC、BSC网元远程登陆不成功故障 设备厂家 HP Juniper 故障恢复时设备型号 NS500 故障历时 软件版本 5.4.0r7.0 业务影响故障程度 省内三级 用户投诉故障原因 待查 关键字 69 河南移动网络故障类优秀案例汇编V1.2 间 5月19日2：30 故障或问题现象 5月19日 4：55 2小时25分 范围 无 （起） 0起 防火墙 session 2010年5月19日2时30分，省监控室维护人员通过HIT远程TELNET网元提示“端口失败”，同时也接到商丘、开封等分公司反映远程登录不上网元。 同时，安排人员按照最新网元列表逐一进行网元登录验证，发现全省MSS、MGW以及部分MSC、BSC均不能正常登陆。 故障原因分析 省监控值班人员立刻将此情况通知网管室，经检查发现网管网防火墙NS500上连接数达到100%,通过查询防火墙日志发现，南方基地采集机（10.97..129、10.97..130）频繁连接NOKIA网管、话务网管等设备地址，短时间内造成防火墙连接数达到上限（25万多条）。 经过测试，采集机每小时发起的连接达到了4万条以上，防火墙连接数达到上限后不接受新的连接请求，故此出现部分网元登录不成功的故障。 经查看网络拓扑图，标红处为此次故障点： 处理步骤说明 70 河南移动网络故障类优秀案例汇编V1.2 网管室维护人员关闭南方基地采集机（10.97..129、10.97..130）上连端口，并清空防火墙连接后，故障恢复。 应急预案执行情况/解决方案 无 经验总结 南方基地采集机（10.97..129、10.97..130）为何频繁连接NOKIA网管、话务网管等设备地址，从而在短时间内造成防火墙连接数达到上限，此次故障主要原因，主要是由于之前防火墙上Session老化时间配置为24小时，删除配置后该策略没有更新，并且南方基地采集机由于程序错误导致针对不同的目的地址不断的发起大量的UDP Session连接，而Session短时间内不老化，致使防火墙的Session连接数不断增长，最终导致防火墙的资源用尽，不能提供正常的访问需求。 故障报告（可插入附件） 200100519 VPN-NS500 Session故 8、网络与信息安全案例 案例一 东区11楼监控大厅网络中断故障 案例名称 设备类型 三层交换机 故障发生时间 东区11楼监控大厅网络中断故障 设备厂家 华为 故障恢复时间 11月17日12：50 11月17日 13：20 30分钟 设备型号 S8505 故障历时 软件版本 3.10 业务影响范围 监控大厅终端 故障或问题现象 2010年11月17日12时50分，监控大厅所有终端网络中断，终端认证失败，无法正常监控告警。 故障原因分析 S8505交换机是一款分布式转发交换机。本次故障，主要涉及业务单板上的2队列，队列2的任务主要是处理ping报文、ARP请求报文以及广播报文。 71 故障程度 省内三级 用户投诉（起） 故障原因 人为 关键字 0起 ARP攻击 河南移动网络故障类优秀案例汇编V1.2 故障期间，两次对交换机slot2槽位cpu队列的数据包情况进行分析：队列2存在严重的丢包，如下: 故障中采集2槽位队列丢包情况 Rec discard statistics: 0 0 138363 0 0 0 0 0 故障后采集2槽位队列丢包情况 Rec discard statistics: 94084 0 25300150 1120 0 0 0 0 红字标出的数据就是队列2的丢包情况，可以看出，该队列丢包严重，并且也导致了该槽位cpu占有率有所升高。 对slot2槽位cpu的镜像抓包进行分析发现，在短短的100个报文的抓包周期，不到一秒的时间内，IP地址为10.88.129.237对应MAC为000d：605f：7ffd的主机发送了99个广播报文。只有1个报文为正常的业务报文。 分析得出，异常流量主要源于该终端，通知该终端用户关闭对应网络服务后，再次抓包发现异常报文不再产生，此时业务恢复。因此，此次故障主要是由于网络中出现异常流量引发设备CPU广播队列溢出所致。 处理步骤说明 1、12：55分，为了保障监控大厅终端的正常监控，维护人员首先放开5200F终端访问权限，避免TSM故障影响网络。 2、12：55-13：00分，查看网络设备日志信息以及端口状态，没有发现异常，但是从终端Ping网关时会出现丢包情况，于是将异常状况定位在郑东8505和接入层设备之间。 3、13：00-13：15分采用抓包工具对网络数据包进行分析。（1）发现网络中存在异常流量引发郑东8505交换机2槽位CPU利用率异常升高；（2）分析郑东8505异常流量数据，发现异常流量是东区15楼一台终端（数据室厂家工程师裴云平）在短时间内发出大量广播报文所致； 4、13：15-13：20分，确认该用户并通知其关闭产生异常流量的进程后，网络中异常流量消失，交换机CPU利用率恢复正常。此时，监控大厅以及其他故障终端都恢复正常。 应急预案执行情况/解决方案 72 河南移动网络故障类优秀案例汇编V1.2 通知该终端用户关闭对应网络服务后，再次抓包发现异常报文不再产生，此时业务恢复 经验总结 本次故障具体原因是由于数据室厂家接入终端发送大量的广播报文导致网络拥塞、设备引发故障。经现场查看，该终端安装虚拟机并开启Vmwere nat server进程。此进程对网络设备的稳定运行造成非常大的影响。因此与各科室终端管理员协商并制定整改方案：加强对厂家工程师终端的安全审计力度，更新TSM终端安全软件策略，禁止安装虚拟机等高危软件，以避免以后出现类似故障。 故障报告（可插入附件） 网管中心部分设备闪断及监控大厅网络中 案例二 东区11楼部分TSM认证失败故障 案例名称 设备类型 PC终端 故障发生时间 东区11楼部分TSM认证失败故障 设备厂家 凯华 故障恢复时间 11月24日8：02 11月24日 8：25 23分钟 设备型号 无 故障历时 软件版本 无 业务影响范围 监控大厅终端 故障或问题现象 2010年11月24日8时02分，省监控大厅部分维护终端无法正常连接TSM服务器，提示连接服务器中断，无法正常监控告警。 故障原因分析 由于话务室厂家工程师终端IP地址错误的配置成网关地址导致，检查发现没有安装360安全卫士并开启ARP 防火墙 。 经过检查网络断链的监控终端发现，凡是发生网络断链的监控终端，均未按照要求安装360安全卫士或者安装了360安全卫士但未开启ARP防火墙，由于没有安全防护措施，导致这些监控终端错误的认为话务室厂家工程师的终端为网关，将数据流量发至此终端，导致TSM认证无法通过， 73 故障程度 省内三级 用户投诉（起） 故障原因 人为 关键字 0起 配置错误 河南移动网络故障类优秀案例汇编V1.2 无法正常监控告警。 处理步骤说明 1、 8：02分，网管网维护员登陆郑东汇聚交换机8505，查询相关日志发现监控大厅网关MAC地址冲突，网管网终端维护员发现郑东8505上出现网关冲突的异常日志（Delete gateway-duplicate attack from MAC 001e-3788-2784, VLAN: 13, access from this MAC address resumed! ），定位故障原因为人为将终端IP手工配置为网关IP导致。 2、 8：10分，查询网管网维护资料发现MAC地址为001e-3788-2784的终端对应的IP地址为10.88.128.235,终端登记使用人是话务室厂家工程师马明； 4、 8：15分，经询问找到该用户，查询该用户维护终端发现，此用户手动将终端IP地址配置为网关地址，此操作导致没有进行安全防护的监控终端直接将数据流量发送到该终端，因此无法正常通过TSM认证； 5、 8：18分，立即修改其终端IP配置之后，部分受影响终端已开始陆续恢复正常。8：25受影响终端已全部续恢复正常。 应急预案执行情况/解决方案 立即修改其终端IP配置之后，部分受影响终端已开始陆续恢复正常。 经验总结 这次故障的主要原因是由于话务室厂家工程师终端IP地址错误的配置成网关地址导致，检查发现没有安装360安全卫士并开启ARP 防火墙。 经过检查网络断链的监控终端发现，凡是发生网络断链的监控终端，均未按照要求安装360安全卫士或者安装了360安全卫士但未开启ARP防火墙，由于没有安全防护措施，导致这些监控终端错误的认为话务室厂家工程师的终端为网关，将数据流量发至此终端，导致TSM认证无法通过，无法正常监控告警。 首先对厂家人员的管理上存在缺陷，厂家工程师维护终端未进行IP地址与MAC地址绑定是造成本次故障的主要原因。由于话务室厂家人员流动性强，监控大厅IP地址资源紧张，因此根据话务室要求，部分流动性强的厂家人员和临时接入人员的维护终端不进行IP地址与MAC地址绑定。 监控大厅有部分监控终端未按照要求安装360安全卫士并开启ARP防火墙，此问题也是导致本次故障的原因之一。中心安全管理员、终端管理员曾多次强调，中心各专业室的监控、维护终端必须安装360安全卫士并开启ARP防火墙；但此次发生网络断链的监控终端均未安装360 74 河南移动网络故障类优秀案例汇编V1.2 安全卫士或者已经安装了安全卫士但未开启ARP防火墙（此次故障未影响正常安装360安全卫士并成功开启ARP防火墙的监控终端）。 故障报告（可插入附件） 网管中心监控大厅部分终端无法通过认证 75
因篇幅问题不能全部显示，请点此查看更多更全内容
Copyright © 2019- 99spj.com 版权所有 湘ICP备2022005869号-5
违法及侵权请联系：TEL:199 18 7713 E-MAIL:2724546146@qq.com
本站由北京市万商天勤律师事务所王兴未律师提供法律服务