产品
产品中心
< 返回主菜单
产品

交换机

交换机所有产品
< 返回产品
交换机
查看交换机首页 >

无线

无线所有产品
< 返回产品
无线
查看无线首页 >

云桌面

云桌面产品方案中心
< 返回产品
云桌面
查看云桌面首页 >

安全

安全所有产品
< 返回产品
安全
查看安全首页 >
产品中心首页 >
行业
行业中心
< 返回主菜单
行业
行业中心首页 >

【路由器】路由器3G类异常,即3G业务不定时中断,造成过一段时间后业务可以自动恢复,或者必须通过重启路由器等操作业务才能够恢复

发布时间:2013-11-23
点击量:4956

1、故障现象

3G路由器下的业务出现不定时中断的现象。过一段时间后业务可以自动恢复,或者必须通过重启路由器等操作业务才能够恢复。

2、故障可能原因

(1)3G客户端或LNS设备运行异常

(2)3G客户端或LNS相关参数配置不合理

(3)3G客户端和LNS软件版本不配套

(4)运营商3G网络调整或3G网络故障

3、故障处理流程

4、故障处理步骤

步骤1:检查设备运的行状态,配置及软件版本

该步骤主要包含以下3个部分,详细排查过程请进入相应部分查看:

(1)检查3G客户端和LNS设备的运行情况

(2)检查3G客户端和LNS相关配置参数

(3)检查3G客户端和LNS软件版本配套情况

步骤1:检查3G客户端和LNS设备的运行情况,是否有异常重启

(1)检查3G客户端路由器和LNS设备的开机时间和运行时间,以判断设备是否有发生过异常重启。通过show version命令可以查看相关信息:

Ruijie#show version

System description      : Ruijie Router (RSR20-04) by Ruijie Networks Co., Ltd.

System start time       : 2012-11-23 1:54:49    //设备开机的时间点为2012年11月23日1点54分49秒

System uptime           : 4:5:21:37                      //设备开机后运行了4天5个小时21分钟37秒

......

如果判断设备末发生过异常重启,则直接跳到“步骤2:检查3G客户端和LNS相关配置参数”步骤排查。

如果判断设备发生过异常重启,请做如下操作:

1)与用户确认是否人为将设备下电,或者设备所在的机房/机柜是否发生过异常断电情况。

2)通过以下操作确认设备是否发生过由于软件异常导致的重启(以下操作不会对在网业务造成影响)

Ruijie#debug support

Ruijie(support)#show exception

Exception address is 0x110000!

No Exception Information!                  //如果设备末因软件异常而重启过,则此处提示“No Exception Information”,反之则会打印出死机的堆栈信息。如果发现死机堆栈信息,请联系4008-111000协助处理。

(2)检查3G客户端路由器和LNS设备的cpu、内存使用情况

如果设备的CPU或内存使用率太高,则很可能某些功能会运行异常,从而导致业务中断。通过show cpu、show memory命令以确认设备的cpu、内存使用情况。

1)通过show cpu命令查看设备的cpu使用率。

Ruijie#show cpu

=======================================

     CPU Using Rate Information

CPU utilization in five seconds: 0%    //最近5秒平均cpu使用率

CPU utilization in one minute  : 0%    //最近1分钟平均cpu使用率

CPU utilization in five minutes: 0%    //最近5分钟平均cpu使用率

  NO   5Sec   1Min   5Min   Process

  0     0%     0%     0%    LISR INT

  1     0%     0%     0%    HISR INT

......

2)通过show memory命令来查看设备的内存使用率。

Ruijie#show memory

System Memory Statistic:

  Free pages: 70818

    watermarks : min 2165, lower 4330, low 6495, high 7895

  System Total Memory : 512MB, Current Free Memory : 286340KB    //总内存大小与空闲内存大小

  Used Rate : 45%            //内存使用率

一般情况下,cpu的使用率都会在10%以内;内存的使用率在80%以内(RSR10由于本身内存较小,因此在加载业务的情况下内存使用率有可能达到80%~90%,但只要内存使用率比较稳定,末再持续增长就是正常的,不影响设备运行)。

 

如果设备的cpu、内存使用率正常,则请直接跳到“步骤2:检查3G客户端和LNS相关配置参数”步骤排查。

如果设备的cpu、内存使用率太高,请直接跳到“步骤9:搜集故障信息,联系4008-111000协助处理。”步骤排查。

步骤2:检查3G客户端和LNS相关参数配置

(1)检查3G客户端async接口下的keepalive配置

async接口下的keepalive功能用于对拨号的3G ppp链路进行保活(一般为3G客户端→LAC),以便3G链路数据通信存在问题时可以及时检测到并拆除3G链路触发重新拨号。但如果3G链路质量不佳,而keepalive间隔又配置的过小,很可能会频繁出现链路检测失败从而重新触发3G拨号,导致业务时断时续。建议:

  • async接口下配置keepalive功能
  • 配置的keepalive时间间隔不小于5秒

Ruijie(config)#interface Async 1

Ruijie(config-if-Async 1)#keepalive 5        //配置keepalive周期为5秒

(2)检查LNS virtual-template接口下的keepalive配置

virtual-template接口下的keepalivea功能用于对l2tp session进行保活(一般为LNS→LAC),以便LNS至LAC间的l2tp session数据通信存在问题时可以及时检测到并拆除相应l2tp session,触发l2tp session重新协商。但如果LNS至LAC间的链路拥塞、或者由于某些原因LAC无法及时响应keepalive报文,而keepalive间隔又配置的过小,很可能出现l2tp session不断重建,导致业务时断时续。建议:

  • virtual-template接口下配置keepalive功能
  • 建议配置的keepalive时间间隔不小于5秒

Ruijie(config)#interface virtual-template 1

Ruijie(config-Virtual-Template 1)#keepalive 5         //配置keepalive周期为5秒

注意:市场上有发现某些LAC功能不完善,对l2tp session keepalive功能的支持存在问题,导致我司LNS virtual-template配置上keepalive后3G客户端async接口有规律频繁up/down,此时就需删除LNS virtual-template上的keepalive配置:

Ruijie(config)#interface virtual-template 1

Ruijie(config-Virtual-Template 1)#no keepalive

(3)检查3G客户端和LNS的DPD参数配置

3G客户端与LNS间的ipsec sa由于某些异常原因可能会出现不同步的现象(一边有相应的ipsec sa,另一边没有),此时就会导致ipsec加密数据通信异常,出现业务无法办理、视频无法调用等故障现象。

为避免此类情况发生,可以通过配置DPD功能(Dead Peer Detection,可以理解为isakmp keepalive功能)来定时检测ipsec peer的可达性,以保持ipsec sa的同步。DPD的配置方法如下:

Ruijie(config)#crypto isakmp keepalive 5    //配置DPD的检测周期为5秒

但并不是3G客户端和LNS都需要配置ipsec DPD功能,原则如下:

  • 如果所有业务都由3G客户端主动发起(如移动银行业务),只需在3G客户端配置DPD功能。
  • 如果LNS端有主动发起业务的需求(如总行需要调用3G路由器下的视频、或者总行网管软件需要定期检测3G路由器是否在线等),则在LNS端也要配置DPD功能。

注意:如果中心点的ipsec加密网关不在LNS上,则需在对应的加密网关设备上配置DPD功能。

步骤3:检查3G客户端和LNS软件版本配套情况

(1)如果是新项目实施或测试中遇到的问题,首先请确认是否已经在版本管理系统(http://rtrcn.ruijie.com.cn)上申请了最新的3G解决方案软件版本。

(2)如果是售后维护遇到的故障,请检查3G客户端与LNS的软件版本是否配套。截止2012年12月为止,建议的设备版本配套方式如下:

注意:在极小部分项目中发现LNS使用RSR50、RSR50E等已经停产的设备。这些设备非3G解决方案推荐设备,且由于软件版本不再更新,对于LNS的功能支持比较有限,原则上不推荐作为LNS。

如果对于版本配套方面有什么疑问,可以登陆版本管理系统(http://rtrcn.ruijie.com.cn)查询最新的版本发布情况,或者联系4008-111000寻求支持。

步骤2:检查业务中断时3G网络通信状态

该步骤主要包含以下3个部分,详细排查过程请进入相应部分查看:

(1)检查业务中断时3G拨号是否成功

(2)检查业务中断时3G路由器与LNS是否通信正常

(3)检查业务中断时路由条目是否正确

(1)检查业务中断时3G拨号是否成功

3G业务中断时,很有可能因为当时路由器3G链路断开,且重新拨号失败导致。此时需要排查3G拨号失败的原因。业务中断时在路由器上通过show ip interface brief命令来确认3G拨号情况:

1)拨号失败时,可以看到async拨号接口末能获取到IP地址,如下:

Ruijie#show ip interface brief

Interface                        IP-Address(Pri)      IP-Address(Sec)      Status                 Protocol

Async 1                          no address           no address                 up                      down    

2)拨号成功时,可以看到async接口下能够获取到IP地址,如下:

Ruijie#show ip interface brief

Interface                        IP-Address(Pri)      IP-Address(Sec)      Status                 Protocol

Async 1                          10.10.0.2              no address                 up                         up    

 

  • 如果3G业务中断时,3G接口能够正确获取到IP地址,则说明故障与3G拨号无关。请继续以下“(2)检查业务中断时3G拨号是否成功”步骤排查。
  • 如果3G业务中断时,3G接口末能获取到IP地址,则可以确认故障是由于3G拨号失败导致。请参考“3G场景故障--3G拨号失败”部分章节进行3G拨号失败故障原因排查。
  • (2)检查业务中断时3G路由器与LNS是否通信正常
  • 业务中断时,在3G客户端路由器上ping LNS virtual-template接口IP地址,看能否ping通。
  • (1)如果3G客户端可以ping通LNS的virtual-template接口IP地址,则请直接跳到“(3)检查业务中断时路由条目是否正确”进行排查。
  • (2)如果3G客户端无法ping通LNS virtual-template接口IP地址,则需进行以下步骤排查:
  • 1)检查3G客户端async接口所获取的IP地址是否正确。如获取IP地址错误,则需检查LNS或AAA上的DHCP配置;如DHCP配置不存在问题,则需确认该SIM卡的VPDN业务是否已经正确开通。
  • 2)如果3G客户端已经获取到正确的IP地址,但还是无法ping通LNS virtual-template接口IP地址,则需检查该SIM卡是否已经欠费。在有些省市,SIM欠费后可以拨号成功但数据不通。

(3)检查业务中断时路由条目是否正确

业务中断时,通过在3G客户端路由器和LNS上执行show ip route命令来确认路由条目是否正确。

Ruijie#show ip route

......

Gateway of last resort is no set

S    172.16.0.0 async 1

......

不论3G客户端路由器与LNS上是配置静态路由、或者运行动态路由协议(如RIP、OSPF等),需要确认以下两点:

1)确认3G客户端路由器上已经有了去往目的网段(如对应的业务服务器)的路由,并且路由下一跳为对应的async接口。

2)确认LNS上已经有了去往3G客户端路由器内网网段的路由,并且路由下一跳为对应的Virtual-access接口。

 

  • 如果发现3G客户端路由器与LNS上的路由条目存在问题(如无路由、或者路由下一跳不正确),请修改静态路由的配置或者检查动态路由协议(如RIP、OSPF等)的运行情况。
  • 如果确认3G客户端路由器与LNS上的路由条目已经学习正确,请直接跳到“步骤3:检查业务中断时IPSEC模块运行状态”步骤处理。

步骤3:检查业务中断时IPSEC模块运行状态

  • 该步骤主要包含以下3个部分,详细排查过程请进入相应部分查看:
  • (1)检查业务中断时IPSEC ISAKMP SA是否已经协商成功
  • (2)检查业务中断时IPSEC  SA是否已经协商成功
  • (3)检查业务中断时IPSEC感兴趣流是否重叠

(1)检查业务中断时IPSEC ISAKMP SA是否已经协商成功

业务中断时,通过在3G客户端路由器和LNS上执行show crypto isakmp sa命令来确认ipsec isakmp sa是否已经协商完成:

Ruijie#show crypto isakmp sa

 destination       source                      state                    conn-id           lifetime(second)

 1.1.1.2               1.1.1.1                   QM_IDLE                  33                16 

只有输出了isakmp sa的相关信息,且isakmp sa状态为“QM_IDLE”,才说明ipsec isakmp sa已经协商完成。

 

  • 如果确认3G客户端与LNS上都已经成功协商完成了isakmp sa,则直接跳到“(2)检查业务中断时IPSEC  SA是否已经协商成功”步骤排查。
  • 如果确认3G客户端与LNS上无isakmp sa,或者isakmp sa的状态非“QM_IDLE”,请搜集ipsec两端设备的如下信息联系4008-111000协助处理:

show version

show version slot

show slot

show run

show log

show ip route

show crypto isakmp sa

show crypto ipsec sa

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

*/注意,clear操作或开启debug调试可能影响客户在网业务,请与客户沟通后谨慎使用!!!/*

先clear老sa,打开如下debug信息,触发ipsec感兴趣流,搜集ipsec协商过程中的debug信息

clear crypto isakmp

clear crypto sa

debug crypto isakmp

debug crypto ipsec

*/注意,debug信息搜集完成后,必须通过undebug all命令关闭所有debug调试,否则可能会对客户在网业务造成持续影响/*

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

(2)检查业务中断时IPSEC  SA是否已经协商成功

业务中断时,通过在3G客户端路由器和LNS上执行show crypto ipsec sa命令来确认ipsec  sa是否已经协商完成:

Ruijie#show crypto ipsec sa

Interface: Async 1

         Crypto map tag:3gtest

  local ipv4 addr 135.2.18.23

         media mtu 1500

         ==================================

         sub_map type:static, seqno:1, id=1

         local  ident (addr/mask/prot/port): (10.119.204.64/0.0.0.15/0/0))         //感兴趣流源地址

         remote  ident (addr/mask/prot/port): (0.0.0.0/255.255.255.255/0/0))   //感兴趣流目的地址

         PERMIT

         #pkts encaps: 30951, #pkts encrypt: 30951, #pkts digest 0

         #pkts decaps: 23636, #pkts decrypt: 23636, #pkts verify 0

         #send errors 157, #recv errors 0

         Inbound esp sas:

              spi:0xce00b96 (216009622)

               transform: esp-sm1

               in use settings={Tunnel Encaps,}

               crypto map 3gtest 1

               sa timing: remaining key lifetime (k/sec): (4606670/2933)

               IV size: 16 bytes

               Replay detection support:N

         Outbound esp sas:

              spi:0x3d71525c (1030836828)

               transform: esp-sm1

               in use settings={Tunnel Encaps,}

               crypto map 3gtest 1

               sa timing: remaining key lifetime (k/sec): (4606670/2933)

               IV size: 16 bytes

               Replay detection support:N

只有输出中包含了 Inbound esp sas和 Outbound esp sas,才说明ipsec sa已经协商完成。

 

  • 如果确认3G客户端与LNS上都已经成功协商完成了ipsec sa,则直接跳到“(3)检查业务中断时IPSEC感兴趣流是否重叠”步骤排查。
  • 如果确认3G客户端与LNS上ipsec sa末协商成功,请搜集ipsec两端设备的如下信息联系4008-111000协助处理:

show version

show run

show log

show ip route

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

*/注意,clear操作或开启debug调试可能影响客户在网业务,请与客户沟通后谨慎使用!!!/*

先clear老sa,打开如下debug信息,触发ipsec感兴趣流,搜集ipsec协商过程中的debug信息

clear crypto isakmp

clear crypto sa

debug crypto isakmp

debug crypto ipsec      //打开以上两个debug后重新触发ipsec感兴趣流,搜集ipsec协商过程中的debug信息

*/注意,debug信息搜集完成后,必须通过undebug all命令关闭所有debug调试,否则可能会对客户在网业务造成持续影响/*

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

(3)检查业务中断时IPSEC感兴趣流是否重叠

业务中断时,通过在LNS上执行show crypto ipsec sa命令来查看LNS上所有的ipsec sa信息,确认是否有ipsec感兴趣流重叠的3G客户端拨上来。

Ruijie#show crypto ipsec sa

Interface: va0

         Crypto map tag:3gtest

  local ipv4 addr 135.2.18.23

         media mtu 1500

         ==================================

         sub_map type:static, seqno:1, id=1

         local  ident (addr/mask/prot/port): (10.119.204.64/0.0.0.15/0/0))         //感兴趣流源地址

         remote  ident (addr/mask/prot/port): (0.0.0.0/255.255.255.255/0/0))   //感兴趣流目的地址

         PERMIT

.........

感兴趣流重叠指的是不同客户端的感兴趣流间存在包含关系,如以下:

3G客户端A的感兴趣流为:192.168.0.0/24→172.16.0.0/16

3G客户端B的感兴趣流为:192.168.0.0/16→172.16.0.0/16

由于192.168.0.0/24子网属于192.168.0.0/16子网,因此3G客户端A与3G客户端B的感兴趣流重叠了,如果这两个客户端都与LNS成功协商了ipsec sa,那么其中一个客户端可能无法通信。

 

  • 如果发现部分3G客户端的感兴趣流存在重叠,则该部分的3G客户端可能会出现业务不定时中断的情况,请修改部分3G客户端的感兴趣流配置后,重新触发拨号。
  • 如果确认所有3G客户端都不存在重叠的感兴趣流,则直接跳到“步骤4:确认是否运营商3G网络调整或3G网络故障”步骤。
  • 步骤4:确认是否运营商3G网络调整或3G网络故障
  • 如经过以上9个步骤排查,确认各个节点的检查都末出现异常,但故障还是会不定期地出现,则很有可能是由于运营商的3G网络问题导致:
  • (1)运营商的3G网络调整都会在凌晨0:00~6:00进行操作,因此如果在这段时间内发现部分地区的3G路由器频繁掉线、或业务频繁中断,则很有可能由于运营商的3G网络调整导致,可以联系运营商进行确认。
  • (2)如果仅发现部分地区的3G路由器频繁掉线、或业务中断,而其它地区的3G路由器工作正常,则也很有可能部分地区3G网络调整或3G网络故障,可以联系运营商进行确认。
  • 步骤5:收集信息后,请联系4008111000协助处理
  • 如果经过以上步骤排查故障仍然无法解决,请搜集以下故障信息,联系4008-111000协助处理。
  • (2)搜集3G客户端如下故障信息
  • show version
  • show lc-version(10.4(3B12)之前的版本需将配置线插入SIC-3G卡的console口,在特权模式输入show version,查看SIC-3G卡版本。)
  • show run
  • show log
  • show cellular info  //每隔10秒搜集1次,共搜集3次
  • show slot
  • 业务中断时搜集如下信息:
  • show ip interface brief
  • show ip route
  • show interface     //每隔10秒搜集1次,共搜集3次
  • show cpu            //每隔10秒搜集1次,共搜集3次
  • show memory    //每隔10秒搜集1次,共搜集3次
  • show crypto isakmp sa
  • show crypto ipsec sa     //触发感兴趣流,每隔1分钟搜集1次,共搜集3次
  • (3)搜集LNS如下故障信息
  • show version
  • show slot
  • show version slot
  • show run
  • show log
  • 业务中断时搜集如下信息:
  • show ip interface brief
  • show ip route
  • show crypto iskamp sa
  • show crypto ipsec sa   //触发感兴趣流,每隔1分钟搜集1次,共搜集3次
  • show vpdn tunnel
  • show vpdn session
  • show interface     //每隔10秒搜集1次,共搜集3次
  • show cpu            //每隔10秒搜集1次,共搜集3次
  • show memory    //每隔10秒搜集1次,共搜集3次
  •  

 

 

 

 

 

 

 

 

 

 

 

相关产品

返回顶部

请选择服务项目
关闭咨询页
售前咨询 售前咨询
售前咨询
售后服务 售后服务
售后服务
意见反馈 意见反馈
意见反馈
更多联系方式