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

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

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

Ruijie(config)#interface virtual-template 1

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

注意：市场上有发现某些LAC功能不完善，对 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次
•