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拨号，导致业务时断时续。建议：
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不断重建，导致业务时断时续。建议：
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功能，原则如下：
注意：如果中心点的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
（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接口。
步骤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已经协商完成。
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已经协商完成。
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，那么其中一个客户端可能无法通信。
