网元GBOVERIP后应急割接不成功的案例分析

1、BSC网元GB OVER IP后应急割接不成功的案例分析一、 背景： GB OVER IP的组网已经开始在全网展开，应急割接演练时发现存在割接不成功的现象，经核查最后确定是BSC上联的Summit 48si交换机配置的去SGSN的业务网段路由数据配置太小，没有涵盖到应急割接的SGSN的业务网段，导致应急割接不成功，通过调整BSC上联Summit 48si交换机的路由配置数据，可有效解决。二、 问题描述 目前江门公司两个新建局JMM10B1和JMM10B7的GB口均为IP承载，因GB OVER IP这种承载方式以后会在现网全面应用，完全取代现网的FR承载模式，因此江门公司组织大家学习了GB OV

2、ER IP的相关原理和应急割接的相关步骤，同时核心室联合数据室在5月27日凌晨业务闲时进行了应急割接的演练，将原归属JMSGSN2的JMM10B7（新入网）网元业务割接至JMSGSN3，原归属JMSGSN3的JMM10B1（2010年1月入网）网元业务割接至JMSGSN2，结果是JMM10B7应急割接演练成功，而JMM10B1应急割接演练失败。三、分析与对策1、网络拓扑结构 目前江门的两个GB OVER IP的网元分别是JMM10B1和JMM10B7,其JMM10B1是下挂在JMSGSN3上，而JMM10B7是下挂在JMSGSN2上，具体的网络拓扑结构如下图所示： 其中JMM10B7和JMM1

3、0B1各自通过一对Summit48si交换机上联到江门综合楼的一对CE(CE3/CE4)，然后均由这对CE上联到江门江海机房的一对CE（CE1/CE2）,最后实现与JMSGSN2和JMSGSN3的互联。2、应急演练的相关过程和结果 本次应急演练的过程是： 1、将JMM10B7的GPRS业务从JMSGSN2应急割接到JMSGSN3 2、将JMM10B1的GPRS业务从JMSGSN3应急割接到JMSGSN2 在进行JMM10B7的演练过程中，整个过程都比较顺利，在进行完下面的数据修改后，GB口状态立刻恢复正常： RRINC:NSEI=6101,NSSTATE=PASSIVE; RRINE:NSEI

4、=6101; RRINI:NSEI=6101,PRIP=10.129.172.65,PPORT=2157,RAT=GERAN; RRINC:NSEI=6101,NSSTATE=ACTIVE; 执行指令后进行JMM10B7的GB口状态打印结果如下： 从上面的打印结果可以看出，GB口状态在执行完激活指令后立刻即变为ACTIVE，且学到了SGSN的业务IP（即RIP项），通过拨测验证业务使用正常，应急割接成功。 紧接着执行JMM10B1的应急割接数据，详细数据如下： RRINC:NSEI=6128,NSSTATE=PASSIVE; RRINE:NSEI=6128; RRINI:NSEI=6128,P

5、RIP=10.129.172.33,PPORT=2157,RAT=GERAN; RRINC:NSEI=6128,NSSTATE=ACTIVE; 执行指令后进行JMM10B1的GB口状态打印结果如下： 由上面的打印结果可以看出GB口处于CONFIG状态，JMM10B1并没有学到对端JMSGSN2的业务IP（即RIP项为NONE），多次检查了应急数据均没有问题，但就是无法学到远端业务IP，其局的应急割接演练失败。但重新定义回原来的数据，即将SGSN的控制IP地址更改回原来的JMSGSN3的控制IP后（10.129.172.65）GB口立刻恢复正常，拨测也没有问题。倒回后的打印结果如下：3、失败原因

6、分析 （1）、BSC分析： 因本次应急演练只是采用在BSC上修改SGSN的控制IP地址的方式，不更改网络的硬件互联结构，即网络拓扑还是和上面的拓扑相同，BSC的应急数据修改相对简单，而且JMM10B7已经应急割接成功，说明BSC的应急割接数据是没有问题的。 （2）、SGSN分析： GB口IP化后应急割接时SGSN不用修改任何数据，其远端地址是自动学习的，因此JMM10B1的割接失败和SGSN无关。 （3）、CE分析： A）、CE到SGSN之间的数据：JMM10B7和JMM10B1是共用CE的，即其CE上联路径是完全一致的，JMM10B7从JMSGSN2割接到JMSGSN3成功，说明CE侧是即可

7、以路由到JMSGSN2也可路由到JMSGSN3，这部份没有问题； B）、CE到LS之间的数据：CE侧需要定义互联LS的相关路由信息，因为应急过程中JMM10B1上联的LS与CE的地址信息没有发生变化，应急割接前业务是正常的，因此也可以排除此部分的路由数据错误； C）、CE到BSC之间的数据：在CE侧还涉及到BSC的业务地址静态路由，因为在应急的过程中，我们只修改了BSC与其互联的远端SGSN的控制地址，并没有更改BSC本端的业务地址（LIP），应急前业务正常，说明CE上这部分的数据定义也是没有问题的。 （4）、LS交换机部分： A）、LS到BSC之间的数据：JMM10B1在应急割接前后不论是业

8、务IP还是接口IP都没有变化，因此在应急割接前JMM10B1的业务使用正常，说明LS上关于BSC的路由数据是没有问题的，在应急的过程中也不需要修改。B）、LS到CE之间的数据：在应急割接前后CE与LS的物理连接没有发生过改变，即其互联端口地址和相应的路由信息在应急的过程中也是不需要进行修改的，应急演练的失败应该和此部分数据无关。C）、LS到SGSN之间的数据：在JMM10B1应急割接的过程中，BSC侧改变了SGSN的业务网段地址，将其从JMSGSN3割接到JMSGSN2，那么如果LS定义的SGSN的业务网段太小，其路由数据没有涵盖JMSGSN2的业务网段会导致割接后路由失败，因此怀疑是JMM1

9、0B1上联的LS上定义的去SGSN的路由数据有问题，同时因在JMM10B7的应急割接演练时也没有修改LS上相应部分的路由数据，割接可成功，因此我们分别打印了JMM10B7和JMM10B1上联的LS的路由配置数据，进行了对比分析，结果如下图： 上面路由数据为JMM10B7互联的LS上定义的SGSN业务网段的路由数据，其定义的网段是10.129.0.0/16，即其可以路由到此网段内的任何一个SGSN（目前江门10个SGSN的业务网段均是在这个网段内），其JMSGSN2的业务网段是10.129.172.32/27，JMSGSN3的业务网段是10.129.172.64/27，因此JMM10B7做应急割

10、接演练将其业务割接至JMSGSN3时，LS是可以将其业务路由出去的，即演练成功。 上图是在/27的路由信息，即其只能将业务路由到JMSGSN3，当我们在JMM10B1修改SGSN的控制IP地址指向10.129.172.33送到LS后，LS找不到相应的路由出口信息，所以在BSC上打印看到是学习不到对端的RIP地址信息的，导致应急割接演练失败。四、 处理结果 在JMM10B1互联的两台LS交换机上修改相应的路由数据，将其（全部SGSN的业务网段均包含在内），这样以后在某个SGSN出现故障时，我们可以将其下带的GB口以IP承载的BSC灵活割接到任意一个负荷较轻的SGSN上,有效解决应急割接失败的问题。有效性分析 在业务闲时我们安排在JMM10B1上联的两台LS交换机上修改了相关的路由数据，将其去SGSN的路由网段扩大到10.129.0.0/16，同时又组织进行了JMM10B1的应急割接演练，将其业务从原来的JMSGSN3割接至JMSGSN2，整个过程非常顺利，修改完BSC的相关应急数据后，GB口立刻生效，拨测业务正常，应急演练割接成功。五、总结与提炼（讨论与建议） 1、目前GB口的割接操作非常频繁，不仅仅是在SGSN故障时需要割接，当SGSN容量不均衡时也会做其所带BSC业务的调整，因此GB口能否正常顺利割接非常重要。建议组织在全省GB OVER IP 的BSC上联