1. 硬件及系统故障处理方法
本章将详细介绍硬件及系统方面的故障处理方法，包括如下：
1.1 电源异常
1.2 风扇异常
1.3 管理板异常
1.4 端口工作异常
1.4.1 电端口工作异常
1.4.2 光端口工作异常
1.5 Console无输出
1.6 软件升级失败
1.1 电源异常
1.1.1 故障处理流程
1.1.2 故障处理步骤
1）步骤1
使用命令show power查看电源状态，确定是否存在FAIL、OFF状态的电源模块。
Ruijie #show power
Chassis-type: RG-RSR77-XA-08
Power-redun: no
Energy-saving: off
power-id power-type supply(W) status vol-in/out(V) cur-out(mA) supply-out(W)
-------- ------------ --------- ---------- ------------- ----------- -------------
0 RG-PA1600I 1600 ok 241 /12.000 20875 250
1 N/A N/A no-present N/A /N/A N/A N/A
2 RG-PA1600I 1600 ok 240 /11.978 28593 342
3 N/A N/A no-present N/A /N/A N/A N/A
slot card_type status require(W) allocate(W)
------- -------------------------------- ---------- ---------- -----------
1 RSR77-XA-SIP3 power-on 180 180
3 RSR77-XA-SIP3 power-on 180 180
4 RSR77-XA-SIP3 power-on 180 180
5 RSR77-XA-SIP3 power-on 180 180
7 RSR77-XA-SIP3 power-on 100 100
8 RSR77-XA-SIP3 power-on 216 216
FE1 RSR77-XA-08-DSF power-on 50 50
FE2 RSR77-XA-08-DSF power-on 50 50
M1 RSR77-XA-08-CM power-on 70 70
M2 RSR77-XA-08-CM power-on 70 70
total-power(W) redundancy(W) available(W) card-used(W) fan-used(W) free-power(W)
-------------- ------------- ------------ ------------ ----------- --------------
3200 0 3200 1376 432 1392
Ruijie#show power
Power-id Power-type Status Hardware-Version Serial Supply(W)
-------- -------------------- ---------- ---------------- ------------------------------- ---------
0 N/A no-present N/A N/A N/A
1 RG-PA150IB-F ok 1.00 R572A2111100323 150
Ruijie #
2）步骤2
如果存在FAIL状态的电源模块，表示该模块异常，无法供电。插拔该电源模块，确定插拔后电源模块是否正常，不正常请转步骤3。
3）步骤3
更换电源插座，确认是否电源插座原因导致。更换后仍然不正常，请转步骤4。
更换同类型的电源模块，确认更换后是否正常。不正常请转步骤4。
4）步骤4
更换电源模块后仍然存在问题，基本可以判断为电源故障，请联系400进一步处理。
注意：电源模块故障可能导致单板供电不足需要根据电源提供的功率计算目前系统中的功率是否够用。详细的设备模块功率（比如RSR30/50/50E/77，请查考硬件安装手册，目前电源的组合模式为“2+1”）
1.2 风扇异常
1.2.1 故障处理流程
1.2.2 故障处理步骤
1）步骤1
使用命令show fan查看风扇状态，确定是否存在FAIL、OFF状态的电源模块。
Ruijie#show fan
Chassis-type: RG-RSR77-XA-08
Fan-id: 1
Fan-type: M10C-FAN
Serial Number: G1QVA7B000016
Fan-id: 2
Fan-type: M10C-FAN
Serial Number: G1QVA7B000020
fan-id status mode speed-level
------ ---------- -------- -----------
1 ok normal N/A
2 ok normal N/A
Ruijie#show fan
Fan id Type Status Hardware Version Serial Number
------ ---------------- ---------- ---------------- ---------------
1 RG_FAN ok N/A N/A
2 RG_FAN ok N/A N/A
3 RG_FAN ok N/A N/A
Ruijie#
2）步骤2
如果存在FAIL状态的风扇模块，表示该模块异常，无法正常运转。插拔该风扇模块，确定插拔后风扇模块模块是否运行正常，不正常请转步骤3。
3）步骤3
更换设备主机框，确认是否由于主机框供电异常导致。更换后如果正常，那么就判断为主机框供电异常，需要更换主机框；如果运行依然异常，那么就转入步骤4
更换同类型的风扇模块，确认更换后是否正常。不正常请转步骤4。
4）步骤4
按照上述3个步骤排查后仍然存在问题，基本可以判断为风扇故障，请联系400进一步处理。
注意：电源模块故障可能导致单板供电不足需要根据电源提供的功率计算目前系统中的功率是否够用。详细的设备模块功率（比如RSR30/50/50E/77，请查考硬件安装手册，目前电源的组合模式为“2+1”）
1.3 管理板异常
1.3.1 故障处理流程
1.3.2 故障处理步骤
1）步骤1
设备使用带屏蔽的串口线接入，确认输出的信息，如果主控板无法正常运行；注意观察主控的指示灯情况，指示灯是否正常，绿色；如果是state灯红色闪烁/绿色闪烁。请转步骤2
2）步骤2
调整相应的波特率（出厂默认为9600，常用的为57600/115200），确认是否能够正常输出；如果无法输出，更换设备串口线（现场实施需要使用屏蔽串口线），如果串口无任何输出/串口有输出，但是数据报文转发异常，请转步骤3
3）步骤3
拔插主控板，同时对主控板的内存条进行检查是否插紧（内存条可能由于运输导致松动），重新拔插后确认串口是否能够正常输出，如果串口仍未有任何输出，请转步骤4
4）步骤4
更换同类型主控板，确认串口是否能够正常输出/数据报文正常转发，如果串口仍未有任何输出/主控板无法正常运行，请转步骤5
5）步骤5
更换主机框，确认该主控板是否能够正常输出/数据报文正常转发，如果主控板无法正常运行，那么判断为主控板硬件问题；如果主控板输出正常，则判断为主机框供电异常。请转步骤6
6）步骤6
如果按照上述步骤更换后，主控板串口有输出但是数据转发异常，请更换同类型的线卡进行组合验证，如果还存在问题，请转步骤7
6）步骤7
按照上述6个步骤排查后仍然存在问题，基本可以判断为硬件单品故障，请联系400进一步处理。
请收集show version slots show redundancy states
1.4 端口工作异常
1.4.1 电端口工作异常
1.4.1.1 故障处理流程
1.4.1.2 故障处理步骤
1）步骤1
查看两端端口是否存在收发错误报文统计。命令为show interfaces 。如果存在错误报文统计，则表明端口配置不正确或者链路质量有问题，需要检查端口配置情况和检查链路质量。如果端口配置和链路质量正常，请转步骤2。
2）步骤2
确认端口配置正常，确保接口双方速率以及双工协商一致后，检查物理链路是否正常。简单方法是使用手轻轻碰网线看是否有UP/DOWN变化。如果没有，则更换连接线观察。如果端口配置/联线正常，请转步骤3。
3）步骤3
如果确认物理链路正常（通过更换网线等措施），而端口又为协商模式，将两端配置为强制模式观察。
更改强制模式后如果端口不正常，请转步骤4。
4） 步骤4
更换一端设备端口（如果条件允许，推荐是同类型的其它槽位单板）。观察是否故障依旧。如果更换端口依旧，则更换另一端设备端口（如果条件允许，推荐是同类型的其它槽位单板）。如果更换端口后不正常，请转步骤5。
5）步骤5
如果故障依旧，请收集相关信息致电400寻求支持。
1 收集show interface后，clear counters隔1分钟后再次收集
2 间隔5秒，收集两次show efd ip fpm statistics/show efd slot x ip fpm statistics
3 间隔5秒，收集两次show efd ip fpm counter/show efd slot x ip fpm counter
1.4.2 光端口工作异常
1.4.2.1 故障处理流程
1.4.2.2 故障处理步骤
1）步骤1
通过命令show interface确认接口的介质类型，确保在光模式下
Ruijie#show interfaces gigabitEthernet 0/0
Index(dec):1 (hex):1
gigabitEthernet 0/0 is DOWN , line protocol is DOWN
Hardware is BCM1250 gigabitEthernet, address is 00d0.f86c.4218 (bia 00d0.f86c.4218)
Interface address is: 192.168.51.161/24
ARP type: ARPA,ARP Timeout: 3600 seconds
MTU 1500 bytes, BW 1000000 Kbit
Encapsulation protocol is Ethernet-II, loopback not set
Keepalive interval is 10 sec , set
Carrier delay is 2 sec
RXload is 1 ,Txload is 1
Queueing strategy: FIFO
Output queue 0/40, 0 drops;
Input queue 0/75, 0 drops
Medium-type is Fiber. //fiber表示光口
Output flowcontrol is off;Input flowcontrol is off.
5 minutes input rate 0 bits/sec, 0 packets/sec
5 minutes output rate 0 bits/sec, 0 packets/sec
860480 packets input, 55025809 bytes, 0 no buffer, 0 dropped
Received 860484 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 abort
49 packets output, 2904 bytes, 0 underruns , 0 dropped
0 output errors, 0 collisions, 2 interface resets
2）步骤2
查看两端端口是否存在收发错误报文统计。命令为show interfaces . 如果存在错误报文统计，则表明端口配置不正确或者链路质量有问题，需要检查端口配置情况和检查链路质量。
Ruijie#show int ten 0/4 transceiver
Transceiver Type : 100BASE-LX-SFP
Connector Type : LC
Wavelength(nm) : 1310
Transfer Distance :
SMF fiber
-- 15km
Digital Diagnostic Monitoring : YES
Vendor Serial Number : PHL4QKL
Current diagnostic parameters[AP:Average Power]:
Temp(Celsius) Voltage(V) Bias(mA) RX power(dBm) TX power(dBm)
36(OK) 3.36(OK) 17.80(OK) -12.39(OK)[AP] -11.76(OK)
Transceiver current alarm information:
None
Ruijie#
3）步骤3
确认双方接口双工模式是否一致。如果一致，请修改成强制模式尝试。在与友商设备光口对接时，由于某些尝试的光口协商报文非标准，照成自动协商失败，正常情况下，强制成1000M全双工能够协商起来。
4） 步骤4
更换光纤测试
更换一端设备端口（如果条件允许，推荐是同类型的其它槽位单板）。观察是否故障依旧。
如果更换端口依旧，则更换另一端设备端口（如果条件允许，推荐是同类型的其它槽位单板）。
如果使用替代法能够排除故障，说明原端口可能存在硬件故障，请致电400进一步确认。
5）步骤5
如果替代测试也无法排除故障，如果有条件，使用光功率计测试传输线路是否正常。如果光衰减严重或无光信号，建议先排查线路问题。
6）步骤6
如果故障依旧，请致电400寻求支持。
1.5 Console无输出
1.5.1 故障处理流程
1.5.2 故障处理步骤
1）步骤1
检查设备面板的SYSTEM、POWER等灯是否亮，如果不亮，请检查电源是否插好。
2）步骤2
a、检查线缆是否正确：
采用设备自带的DB9（母头）---RJ45的线缆，另外准备好DB9（公头）----USB，RJ45连接设
备的Console口，USB连接笔记本电脑。
>>提示：驱动安全正确，然后选择对应的COM口，具体的编号，驱动安装好之后在设备管理
器查看，如下图（就采用COM6进入设备）：
b、相应的的设置是否正确：
主要关注波特率和流控的设置，锐捷设备默认的波特率为9600，但是对于3G路由器上的SIC-3G
卡，如果要单独登录3G卡操作，3G卡启动时它的波特率为115200，当启动完毕之后，它的波
特率为9600，这一点比较特殊。如果还是解决不了问题，请转步骤3处理。
3）步骤3
检查内存是否松动，如果还是不能解决问题，有可能是Console口损坏，请转步骤4处理。
4）步骤4
如果通过以上步骤无法排除故障，请致电400寻求支持。
1.6 软件升级失败
1.6.1 故障处理流程
1.6.2 故障处理步骤
1）步骤1
检查升级的软件版本，确保升级的软件版本和主机匹配，如果不一致，将无法升级。
2）步骤2
检查设备的flash空间，如果flash空间不足，将无法升级
系统内查看flash空间的大小：
Ruijie#dir
Directory of flash:/
Number Properties Size Time Name
------ ---------- ---------- ------------------------ --------------------
1 drwx 4.0k Wed May 11 17:54:39 2022 flash2:\
2 drwx 4.0k Sun Apr 24 17:48:23 2022 addr
3 -rwx 19.6k Sat Jan 2 22:37:28 2038 flash2:syslog.txt
4 drwx 4.0k Sat Jan 9 20:29:10 2038 ruieji
5 drwx 4.0k Tue May 10 09:29:43 2022 factory
6 -rwx 94.8k Sat Jan 9 01:19:52 2038 usb1:sysloggg.txt
7 drwx 4.0k Sat Jan 9 02:18:44 2038 rg_licns
8 drwx 4.0k Tue May 10 10:33:53 2022 syslog
9 drwx 4.0k Thu Feb 11 18:45:23 2038 startup
10 drwx 4.0k Tue May 10 10:03:59 2022 cmpnt
11 drwx 4.0k Sun Apr 24 17:48:23 2022 vsd
12 -rw- 254.4M Wed Jun 22 01:15:11 2022 os.bin
13 drwx 4.0k Sun Apr 24 17:47:34 2022 rep
14 drwx 4.0k Tue May 10 10:03:53 2022 diag_log
15 drwx 4.0k Sun Apr 24 17:47:29 2022 asan
16 drwx 4.0k Tue May 10 10:03:55 2022 tipc
17 drwx 4.0k Thu Feb 11 18:45:39 2038 uft
18 drwx 4.0k Thu Feb 11 18:45:37 2038 pkg_download_tmp
19 -rw- 3.4k Tue Jan 26 20:11:43 2038 config.text
20 -rwx 82B Tue Jan 26 20:11:41 2038 config_vsu.dat
21 drwx 4.0k Sun Apr 24 17:48:22 2022 dev
22 drwx 4.0k Thu Feb 11 18:39:20 2038 upgrade
23 -rwx 512B Sat Jan 2 23:09:34 2038 flash2:sysloggg.txt
24 -rwx 0B Sat Jan 2 23:09:42 2038 flash3:sysloggg.txt
25 -rwx 21B Wed Feb 17 20:58:17 2038 syslog_rfc5424_flag.txt
26 -rwx 1.6k Tue May 10 10:03:55 2022 rsa_private.bin
27 -rwx 1.6k Tue May 10 10:03:53 2022 rsa1_private.bin
28 drwx 4.0k Tue May 10 10:03:44 2022 var
29 drwx 4.0k Tue May 10 10:03:57 2022 security
30 -rwx 0B Wed May 11 18:19:56 2022 syslog.txt
11 files, 19 directories
3,922,853,888 bytes total (3,367,960,576 bytes free)
Ruijie#
如果空闲空间不足，可以删除不需要的bin或者LOG文件，20XA的FLASH是4G，其他的设备FLASH是8G
3）步骤3
确保在软件升级过程中设备不掉电，一旦掉电将导致升级失败，特别是在升级高端路由器产品，
如RSR77，如果在升级BOOT层软件时掉电，将会导致设备直接返厂。
4）步骤4
如果在升级过程中遇到问题，请记录操作日志，同时联系400进一步处理。
2. 软件故障处理方法
本章将详细介绍软件方面的故障处理方法，包括如下：
2.1 系统资源占用率
2.1.1 CPU占用率
2.1.2 内存占用率
2.2 应用协议
2.2.1 NTP
2.2.2 IPFIX
2.3 路由协议
2.3.1 静态路由
2.3.2 策略路由
2.3.3 RIP
2.3.4 OSPFv2
2.3.5 BGP
2.4 安全
2.4.1 IPSec
2.4.2 NAT
2.4.3 SSH
2.5 QoS
2.6 MPLS/MPLS VPN
2.6.1 MPLS VPN路由学习异常
2.6.2 MPLS VPN转发故障
2.7 链路层协议
2.7.1 PPP
2.7.2 MP
2.8 可靠性
2.8.1 VRRP
2.8.2 DLDP
2.8.3 BFD
2.1 系统资源占用率
2.1.1 CPU占用率
2.1.1.1 故障处理流程
2.1.1.2 故障处理步骤
1）步骤1
使用命令show cpu连续查询设备CPU利用率，确定设备CPU利用率是否异常。如果设备CPU利
用率持续在60％以上，说明CPU异常任务处理的可能性比较高（目前RSR系列路由器的功能基本
都下快转），所以需要特别分析设备CPU高的具体原因，以确认设备的CPU是否存在异常，请转
步骤2。
注意：通过TELNET方式登录使用show run/show memory /debug su模式下show task收集诊断
信息时，查询结果会显示CPU利用率较高，此时需要在信息收集完毕后，等待一段时间再次查询
设备的CPU利用率，确定是否是由于收集诊断信息导致的CPU利用率升高还是任务异常导致的CPU
占用率升高。
2）步骤2
使用命令show cpu监控并查询设备CPU各个任务运行情况。下面以RSR20XA为例查询设备各任务运
行情况：
Ruijie#show cpu
===============================================
[Slot 0: RG-RSR20-XA-54]
CPU Using Rate Information
CPU utilization in five seconds: 2.00%
CPU utilization in one minute: 1.60%
CPU utilization in five minutes: 1.40%
NO 5Sec 1Min 5Min Process
1 0.00% 0.00% 0.00% procd
2 0.00% 0.00% 0.00% kthreadd
3 0.00% 0.00% 0.00% rcu_gp
4 0.00% 0.00% 0.00% rcu_par_gp
6 0.00% 0.00% 0.00% kworker/0:0H-kblockd
8 0.00% 0.00% 0.00% mm_percpu_wq
9 0.00% 0.00% 0.00% ksoftirqd/0
10 0.00% 0.00% 0.00% rcu_sched
11 0.00% 0.00% 0.00% rcu_bh
12 0.00% 0.00% 0.00% migration/0
13 0.00% 0.00% 0.00% cpuhp/0
14 0.00% 0.00% 0.00% cpuhp/1
15 0.00% 0.00% 0.00% migration/1
16 0.00% 0.00% 0.00% ksoftirqd/1
18 0.00% 0.00% 0.00% kworker/1:0H-kblockd
29 0.00% 0.00% 0.00% kdevtmpfs
30 0.00% 0.00% 0.00% netns
31 0.00% 0.00% 0.00% kauditd
33 0.00% 0.00% 0.00% kworker/0:1-events
34 0.00% 0.00% 0.00% oom_reaper
35 0.00% 0.00% 0.00% writeback
36 0.00% 0.00% 0.00% kcompactd0
37 0.00% 0.00% 0.00% crypto
38 0.00% 0.00% 0.00% kintegrityd
39 0.00% 0.00% 0.00% kblockd
40 0.00% 0.00% 0.00% ata_sff
41 0.00% 0.00% 0.00% watchdogd
66 0.00% 0.00% 0.00% kswapd0
67 0.00% 0.00% 0.00% kworker/u9:0
96 0.00% 0.00% 0.00% ipv6_addrconf
105 0.00% 0.00% 0.00% kworker/0:2-rcu_gp
184 0.00% 0.00% 0.00% scsi_eh_0
185 0.00% 0.00% 0.00% scsi_tmf_0
186 0.00% 0.00% 0.00% usb-storage
209 0.00% 0.00% 0.00% kworker/1:1H-kblockd
213 0.00% 0.00% 0.00% kworker/0:1H-kblockd
227 0.00% 0.00% 0.00% jbd2/sda10-8
228 0.00% 0.00% 0.00% ext4-rsv-conver
237 0.00% 0.00% 0.00% jbd2/sda12-8
238 0.00% 0.00% 0.00% ext4-rsv-conver
263 0.00% 0.00% 0.00% ubusd
467 0.00% 0.00% 0.00% dump_memoryinfo
512 0.00% 0.00% 0.00% lmk_cap_get_val
513 0.00% 0.00% 0.00% lmk_ham_mon_thr
514 0.00% 0.00% 0.00% lmk_event_task
515 0.00% 0.00% 0.00% lmk_task
565 0.00% 0.00% 0.00% ham
576 0.00% 0.00% 0.00% bspinfo.elf
593 0.00% 0.00% 0.00% ras_logfile_tim
599 0.00% 0.00% 0.00% ham_cnmsg_handl
600 0.00% 0.00% 0.00% ham_process_net
601 0.00% 0.00% 0.00% ham_process_dom
602 0.00% 0.00% 0.00% ham_thread_noti
603 0.00% 0.00% 0.00% ham_availabilit
604 0.00% 0.00% 0.00% ham_inotify_for
3）步骤3
根据步骤2的查询结果，进行故障分析。
在显示的任务信息中，需要关注的是一分钟和5分钟的CPU利用率，5秒钟的CPU利用率可能由于
瞬间CPU处理报文过多导致升高，以此数据判断问题不太准确。
CPU utilization in five seconds: 2.00%
CPU utilization in one minute: 1.60%
CPU utilization in five minutes: 1.40%
Show cpu中第二列到第四列显示该任务占用CPU的比率(重点关注第三和第四列)；第五列显示的是占用CPU的线程，其中有个idle任务比较特殊，是CPU的空闲任务，越高表明CPU越空闲。其他任务如果比率太高，说明该任务运行可能不正常。
下面介绍一些导致设备CPU高的常见任务及处理方法：
判断网络中是否存在过多分片报文，由于分片报文需要消耗CPU对报文进行重组或者丢弃，如果未布置防火墙的网络中经常会遭受分片攻击，攻击者会发送大量未能无法重组成功的分片报文耗尽CPU处理资源。可以通过show efd ip fpm statics中的数字判断（如下红色字体部分）。按照一般网络主机数量判断如果超过800就必须特别注意，需要分析网络架构是否合理，网络中是否存在攻击源。在判断是否攻击的时候可以结合抓包、show efd ip fpm counters辅助判断。如果无法判断故障现象，请按照如下步骤收集（常规的版本信息、内存信息、配置信息、show ip ref adj/show ip ref route不在此处列出）
1、show ip fpm stat 等待5秒再次收集
2、show ip fpm counters
3、clear ip fpm counters，等待5秒收集show ip fpm counters
4、clear ip fpm counter，等待5秒收集clear ip fpm counters
5、重复2-4步骤
6、show ip fpm users
7、show core，等待5秒后，再次收集
8、show ip fpm users
9、show interfaces，等待5秒后，再次收集
10、show cpu，等待5秒后，再次收集
11、debug su模式下show task，等待5秒后，再次收集
12、debug su模式下show skb，等待5秒后，再次收集
show信息举例：
Router#show efd ip fpm counters
The capacity of the flow table:2080000
Number of active flows:517222
Number of the defragment contexts:1705
Number of the buffers hold by FPM:1800
2 Router#show ip fpm counters
Droped packet counters:
Count Reason
0 Non-IPv4 packet
0 Bad IPv4 header length
0 Bad IPv4 total length
169940 IPv4 fragment with DF bit set
320155 Too small IPv4 fragment
3748963 Bad IPv4 fragment offset
412580423 IPv4 fragment timeout
0 Bad IPv4 checksum
17591288 Invalid IPv4 address
10356 Invalid TCP flags
0 Invalid TCP initial flags
0 Invalid TCP initial ACK number
0 Invalid TCP initial window
0 Invalid TCP sequence
21496 Invalid ICMP message type
9192077 Invalid ICMP initial message type
判断网络是否存在过多的协议报文，执行show run确认设备开启的协议报文，同时确认是否存在非法的协议攻击；可以通过在设备前假设hub/交换机进行抓包分析。
判断是否存在过多的到达本机报文，到达本机的报文主要是telnet/icmp/路由不可达报文需送CPU丢弃处理/arp报文。需要分析ICMP回应、不可达是否可以关闭\黑洞路由是否配置\arp表项是否存在过多的incomplete表项，网络中是否存在过多的ARP请求。
printk_task打印日志信息/调试信息。不停地打印日志信息或调试信息（把控debug/show信息/@@@@@信息）使导致该线程占用CPU过过的资源。可通过查看设备产生的日志量/调试信息量来初步定为故障，同时可以尝试把debug信息（undebug all）/show停止后一段时间后观察CPU利用率。如果无法判断故障现象，请按照如下步骤收集（常规的版本信息、内存信息、配置信息、show ip ref adj/show ip ref route不在此处列出）
1、1、show core(间隔5秒，收集多次)
2、debug su模式下show task （两次）
3、执行@@@@@/@@@@t信息，由于@@@@@信息属于高优先级可能会影响网络正常运行，也可采用debug su模式下的show tech_support（两次）
rl_con 控制台线程，用于处理命令，打印或者命令执行的进程，所执行的命令的执行函数长时间占用CPU。比如执行show run、show 命令都会对CPU有所影响，可以在信息收集完一段时间检查cpu利用率是否下降。如果无法判断故障现象，请按照如下步骤收集（常规的版本信息、内存信息、配置信息、show ip ref adj/show ip ref route不在此处列出）
1、show core(间隔5秒，收集多次)
2、debug su模式下的show task （每隔5秒，收集多次）
3、执行@@@@@信息，由于@@@@@信息属于高优先级可能会影响网络正常运行，也可采用debug su模式下的show tech_support（每隔5秒，收集多次）
vty_connect模块初始化线程，用于创建\断开连接；线程出错；可以停止在telnet上执行的操作命令，等待一段时间确认CPU利用率是否下降；如果无法判断故障现象，请按照如下步骤收集（常规的版本信息、内存信息、配置信息、show ip ref adj/show ip ref route不在此处列出）
1、show core(间隔5秒，收集多次)
2、show user
3、debug su模式下的show task （隔5秒，收集多次）
执行上述操作后，现场有条件可以通过控制线登录，执行clear line vty xx的操作，确认此时CPU利用率是否下降，如果无法判断故障现象，请进一步收集
1、show core(间隔5秒，收集多次)
2、show user
3、debug su模式下的show task （隔5秒，收集多次）
4、行@@@@@信息，由于@@@@@信息属于高优先级可能会影响网络正常运行，也可采用debug su模式下的show tech_support（隔5秒，收集多次）
vrrpd，VRRP协议的守护线程。如果该进程占用CPU过多，那么需要判断是收到的VRRP协议报文很多；或者配置的VRRP组很多，导致发送的VRRP协议报文很多；
1、show vrrp brier查看VRRP组发送广播间隔时间是否过短
2、show vrrp brief查看VRRP组，是否存在VRRP组数量众多情况
3、如果1 2无法判断问题，收集show vrrp/Show vrrp brief/Show interface/Debug vrrp，同时在条件情况下在debug support下show task获取线程的堆栈，或输入@@@@t取线程的堆栈。
ospfd/ospf6d ，OSPF协议守护线程/ OSPFv3协议守护进程，判断是否存在OSPF网络邻居较多/OSPF网络路由量较大/OSPF网络振荡较频繁，可通过
1、执行show run收集ospf的配置信息；
2、观察是否有邻居频繁的FULL<--->DOWN来回切换信息。打开log-adj-changes detail。观察是否有邻居状态频繁的变化。
3、执行show log收集一下ospf的Log信息；
4、show core（间隔5秒，收集多次）
5、采集以下show信息
show ip ospf（V4、V6）
show ip/ipv6 ospf neighbor（V4、V6）
show ip/ipv6 ospf route count（V4、V6）
show ip/ipv6 ospf database database-summary（V4、V6）
show ip ospf border-routers（V4）
show ipv6 ospf topology（V6）
6、执行show log收集一下BGP的Log信息；
7、debug su模式show task（收集多次），收集ospf任务的任务运行堆栈信息；
8、请多次(如每5秒执行一次，执行5到10次)执行@@@@@收集系统的运行时信息。
bgpd，BGP协议守护线程，判断BGP邻居是否频繁震荡，是否存在大量BGP路由频繁震荡，可通过：
1、执行show run收集BGP的配置信息；
2、执行show bgp all neighbors收集BGP邻居信息；
3、执行show bgp all summary 收集BGP的路由信息；
4、执行show log收集一下BGP的Log信息；
5、show core（间隔5秒，收集多次）
6、执行debug sup, 多次执行show task,收集BGP任务的任务运行堆栈信息；
7、在无法执行CLI命令的情况下，请多次(如每5秒执行一次，执行3到5次)执行@@@@@收集系统的运行时信息。
4）步骤3
通过show cpu-protect device 1/show cpu-protect slot x查看报文上CPU进程的统计情况
如果Drop统计有持续增加，说明报文上CPU速率比较大，需要判断是否合理是否需要调整报文上CPU的处理门限值。
使用show cpu-protect plane-defend all statistics device 1、show cpu-protect plane-defend all statistics slot x查看三平面的报文速率处理统计。
如果这些Drop的统计有持续整机，表示有攻击或者协议报文过载，需要确认是否合理。
5）步骤5
如果无法确定任务利用率高属于正常现象还是存在异常，收集上述信息后，请联系400进一步处
理。
2.1.2 内存占用率
2.1.2.1 故障处理流程
2.1.2.2 故障处理步骤
1）步骤1
使用命令show memory连续查询设备内存利用率，确定设备内存利用率是否异常。由于RSR路由器为了保证关键业务正常，系统开机会预先保留内存资源（比如RSR50，开机50%；RSR20开机70%），所以正常业务情况下，基本不会耗费过多的内存资源。如果内存利用率偏高，设备内存利用率持续在60％以上（RSR20持续超过80%以上），说明某些线程消耗内存比较大，需要分析设备内存利用率高的具体原因，以确认设备的内存利用率是否存在异常，请转步骤2。
2）步骤2
使用命令show memory监控并查询设备各个任务内存消耗情况，执行多次show memory的操作，确认哪个线程占用的内存不断增大，此时需要对该模块占用内存进行分析，转步骤3。
下面以RSR20为例查询设备各任务内存消耗情况：
Ruijie#show memory
System Memory: 3962676KB total, 1956136KB used, 2006540KB free, 2799074KB available, 41.1% used rate
Swap: 1981336KB total, 1981336KB free
Used detail: 603904KB active, 198944KB inactive, 157800KB mapped, 200088KB slab, 1117756KB others
PID Vsd Text Rss Data Stack Total Process
20024 0 124 5128 45580 132 58048 rl-con/258
20023 0 216 5532 45640 132 58556 telnetd-main
6309 0 124 4500 45580 132 58048 rl-con/1458
6250 0 604 288 200 132 3072 sh
6234 0 520 7544 59064 132 463368 sysha
6222 0 28 6140 8636 132 18512 sntp.elf
6201 0 32 6900 732 132 12268 mtdoops-cli
6169 0 20 120 216 132 1980 run_proxy-io2ne
6164 0 20 116 216 132 1980 demo_proxy-io2n
6162 0 604 292 200 132 3072 sh_app
6140 0 52 5076 8620 132 19516 lsm_rpc_agent.e
6128 0 16 4788 656 132 9892 cpurule
6114 0 780 20416 78504 132 127552 snooping.elf
6102 0 516 19304 78456 132 126552 savi.elf
6090 0 20 2864 108532 132 970684 aof
6078 0 36 6332 45568 132 56644 cmdk.elf
6066 0 16 2516 316 132 7168 zlogd
6042 0 100 8900 17752 132 35576 cli-proxy
6030 0 52 4620 8636 132 18044 ce.cli.pkt.dp
3）步骤3
收集上述信息后，请尽快联系400进一步处理，不要重启设备。
2.2 应用协议
2.2.1 NTP
2.2.1.1 故障处理流程
2.2.1.2 故障处理步骤
1）步骤1
Show run确认设备是否开启NTP的client功能，确保NTP配置正确。
2）步骤2
使用show ntp status确定服务器端配置主时钟或已经同步主时钟，且层数<15。确定服务器配置正确，请转步骤3。
Ruijie#show ntp status
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**0
reference time is 0.0 (00:00:00.000 UTC Thu, Jan 1, 1970)
clock offset is 0.00000 sec, root delay is 0.00000 sec
root dispersion is 0.00000 msec, peer dispersion is 0.00000 msec
Ruijie#sh ntp server
ntp-server source keyid prefer version status
---------------------------------------- -------- ----------- ------ ------- -----------
3.3.3.3 None None FALSE 4 select
Ruijie#3）步骤3
确定服务器地址路由可达，从客户端可以ping通服务器端地址。确定服务器和客户端互通正常，请转步骤4
4）步骤4
使用show run | include ntp确定认证和访问权限配置一致且正确
sh run | in ntp
ntp authentication-key 1 md5 050a1337092610 7
ntp authenticate
ntp server 10.1.1.1
5）步骤5
客户端如果配置source-interface，则要确定该接口地址对于服务器路由可达。
举例：ntp server地址为10.1.1.1；loopback地址为2.2.2.2
Ruijie#sh run | in ntp
ntp authentication-key 1 md5 0132564a3d1103 7
ntp authenticate
ntp server 10.1.1.1 source Loopback 0
!
Ruijie#ping
Protocol [ip]:
Target IP address: 10.1.1.1 --server地址
Repeat count [5]: 5
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address:2.2.2.2 ---loopback地址
Time to Live [1, 64]:
Type of service [0, 31]:
Data Pattern [0xABCD]:
Sending 5, 100-byte ICMP Echoes to 10.1.1.1, timeout is 2 seconds:
< press Ctrl+C to break >
6）步骤6
使用debug ntp 命令收集两端设备的调试信息，以及报文收发状态。
7）步骤7
按照上述6个步骤排查后仍然存在问题，基本可以判断为软件NTP功能故障，请联系400进一步处理
2.2.2 IPFIX (12.6RPJ3 暂时不支持)
2.2.2.1 故障处理流程
2.2.2.2 故障处理步骤
步骤1
采用show ip flow export查看源地址和目的地址，使用ping测试源目地址的可达性：
Ruijie#show ip flow export
cache for main metering process:
flow export is enabled
Exporting flows to 10.0.0.2 (9996) //目的地址10.0.0.2
Exporting using source interface GigabitEthernet 0/1 //源接口
Template export information:
Template timeout = 5 minutes
Template refresh rate = 30 packets
total 2070 packets metering
total 0 packets dropped for no memory
total 1366 flows exported in 180 udp datagrams
0 ipfix message export failed
步骤2
采用show ip flow export查看目标端口号是否正确，同时确保对应的目标UDP端口号的流量没有被过滤：
例如：下面显示的是9996端口，IPFIX采用UDP协议，此UDP 9996端口的流量不能被过滤；
Ruijie#show ip flow export
cache for main metering process:
flow export is enabled
Exporting flows to 10.0.0.2 (9996) //可以修改，但是必须保证和软件设置一致
Exporting using source interface GigabitEthernet 0/1
Template export information:
Template timeout = 5 minutes
Template refresh rate = 30 packets
total 2070 packets metering
total 0 packets dropped for no memory
total 1366 flows exported in 180 udp datagrams
0 ipfix message export failed
步骤3
采用Ruijie#show run | include ip flow-export version
ip flow-export version v9 //版本为v9
默认版本为IPFIX，如果采用上述命令显示不出来，那么表示当前版本为默认的IPFIX；
我司路由器支持ipfix/version9两种报文输出格式；但由于有些分析软件可能不支持version9报文格式，因此一般建议采用ipfix格式。
步骤4
查看接口下是否使能IPFIX和流过滤功能：
ip access-list standard 1
10 permit any
interface gigabitEthernet 0/0
ip flow egress //使能接口的出口流数据统计
ip flow ingress //使能接口的入口流数据统计
flow-sample 255 filter 1 //使能流过滤功能
1：由于RSR系列路由器IPFIX功能为软件实现，因此不支持对采样率进行配置。但可以通过标准或扩展ACL对采样的数据流进行过滤。
2：在接口配置了ip flow egress或ip flow ingress后，必须配置配置流过滤flow-sample功能，否则端口流量将无法转换为ipfix流量输出。
步骤5
如果通过以上步骤无法排除故障，请收集以下信息，同时致电400寻求支持。
Show run
Show ip route
Show ip flow export
Show ip flow export temple
Show ip flow-cache
Show ip flow interface
2.3 路由协议
2.3.1 静态路由
2.3.1.1 故障处理流程
2.3.1.2 故障处理步骤
1）步骤1
不论使用静态路由还是动态路由，必须保证数据来回路径上所有路由器上双向路由都可达。使用tracert命令确认网络中哪台路由出现问题。
如果是如下形式的循环响应，说明网络中存在环路，逐跳排查解除环路即可。
Ruijie#traceroute 2.2.2.2
< press Ctrl+C to break >
Tracing the route to 2.2.2.2
1 1.1.1.2 0 msec 0 msec 0 msec
2 1.1.1.1 0 msec 0 msec 0 msec
3 1.1.1.2 0 msec 10 msec 0 msec
4 1.1.1.1 0 msec 10 msec 0 msec
5 1.1.1.2 0 msec 10 msec 0 msec
6 1.1.1.1 10 msec 0 msec 10 msec
7 1.1.1.2 0 msec 10 msec 0 msec
8 1.1.1.1 10 msec 0 msec 0 msec
9 1.1.1.2 10 msec 0 msec 0 msec
10 1.1.1.1 10 msec 10 msec 0 msec
如果可以tracert到目的地址，但路径不对，那么可能是静态路由配置错误，请逐条排查。需要特别注意，策略路由优于静态路由，需要关注是否配置了策略路由，策略是否正确。
如果是*****，表示路由不可达，说明某一跳路由器的路由出现异常。需要继续排查
2）步骤2
使用命令show ip route确认路由表中是否有去数据包源/目IP的路由。注意，源目IP的路由都需要关注，因为数据是双向的。
3）步骤3
Show ip route如果没有路由，那么需要做如下确认：
Show run确认是否配置静态路由
Show interface确认静态路由下一跳出接口是否up。静态路由装载路由表的前提是静态路由下一跳可达，下一跳可达的条件是路由表中有其他路由条目包含这个下一跳，一般情况下是一个直连路由。如果接口down掉，那么直连路由消失，静态路由也就无法装载路由表。
4）步骤4
Show ip route如果有存在路由，但转发异常，需要做如下确认：
使用ping命令测试静态路由下一跳是否可达
确认邻接表和快转表是否正常
以ip route 0.0.0.0 0.0.0.0 1.1.1.2；ip route 2.2.22 255.255.255.255 1.1.1.3为例，这里的1.1.1.3不可达。
Ruijie#sho ip ref adj
index state type ip interface rfct chg vid tid len l2add
5 unres discard 1.1.1.3 FastEthernet 0/0 1 0 0 0 0 0000.0000.0000
4 resolved forward 1.1.1.2 FastEthernet 0/0 2 0 0 800 14 001a.a941.4043
3 unres glean 0.0.0.0 FastEthernet 0/0 1 0 0 0 0 0000.0000.0000
2 resolved local 0.0.0.0 Local 0 1 0 0 0 0 0000.0000.0000
1 unres local 0.0.0.0 NULL 2 0 0 0 0 0000.0000.0000
//type字段，forward表示邻接可用；discard表示邻接不可用
//l2add 字段，0000.0000.0000表示没解析到该邻居arp信息，邻居不可达；
Show ip ref route 确认快转路由表是否正常
Ruijie#sho ip ref route
Codes: * - default route
# - zero route
ip/mask index next hop interface l2add
#0.0.0.0/0.0.0.0 4 1.1.1.2 FastEthernet 0/0 001a.a941.4043
*0.0.0.0/0.0.0.0 4 1.1.1.2 FastEthernet 0/0 001a.a941.4043
224.0.0.0/224.0.0.0 1 0.0.0.0 NULL 0000.0000.0000
2.2.2.2/255.255.255.255 5 1.1.1.3 FastEthernet 0/0 0000.0000.0000
1.1.1.0/255.255.255.0 3 0.0.0.0 FastEthernet 0/0 0000.0000.0000
1.1.1.255/255.255.255.255 1 0.0.0.0 NULL 0000.0000.0000
1.1.1.2/255.255.255.255 4 1.1.1.2 FastEthernet 0/0 001a.a941.4043
1.1.1.1/255.255.255.255 2 0.0.0.0 Local 0 0000.0000.0000
//如果l2add地址为0000.0000.0000，说明该路由不可用
如果adj表和快转表存在异常，首先确认下一跳是否可达，下一跳arp是否学习正常。如果下一跳可达，但表项却异常，那么请收集信息致电400寻求支持。
5）步骤5
如果通过以上步骤无法排除故障，请收集以下信息，同时致电400寻求支持。
show run
show ver
show cpu
show log
show arp
show interface
show ip route
show ip ref adj
show ip ref route
执行ping目的ip和tracert目的ip的操作，收集日志
2.3.2 策略路由
2.3.2.1 故障处理流程
2.3.2.2 故障处理步骤
1）步骤1
采用traceroute/tracert测试流量的路径走向来判断策略是否生效。
2）步骤2
采用sh ip pbr route查看匹配的流量和设置的策略是否正确：
检查配置的接口，ACL和下一跳IP地址配置是否正常。检查ACL的配置和数据流是否能匹配。查看pbr的route-map信息是否正常
检查PBR的route-map信息是否正常，查看ACL，PBR，下一跳是否UP。
从show route-map显示route-map seq-10中的acl存在，然后采用show access-list查看对应的acl
是否有acl条目即ace，如果不存在ace，那么跳过该route-map，从下一个route-map开始匹配，如
果 下一个route-map不存在，等价于所有的报文走普通路由。
检查下一跳IP地址是否可达等信息。
3）步骤3
如果无法确定问题的原因，请收集以下信息后，请联系400进一步处理：
show version
show run
show cpu
show log
show ip int bri
show ip route
show ip ref route
show ip ref adjacency
ping x.x.x.x
traceroute/tracert x.x.x.x
sh pbr rm
show pbr fw
sh pbr apply-info
sh pbr memory
2.3.3 RIP
2.3.3.1 故障处理流程
2.3.3.2 故障处理步骤
1）步骤1
确认基本配置是否正确，需要注意以下几点：
确认两台邻居路由器开启RIP路由协议，互联接口在RIP 的NETWORK范围内
例如：
接口F0/1 IP地址为131.108.0.1/24
router rip
version 2
network 131.208.0.0
如果RI network 命令将131.108.0.0 ，错误写成131.208.0.0，将导致与网段相关的接口不被纳入到RIP协议中宣告，从而R2学习不到路由。
未正确宣告：
R1#show ip protocols
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 0 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Automatic network summarization is in effect
Maximum path: 4
Routing for Networks:
131.208.0.0
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 120)
正确宣告：
R2#sho ip prot
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 11 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv Triggered RIP Key-chain
FastEthernet0/1 2 2 //正确宣告后，会有接口加入RIP
Automatic network summarization is in effect
Maximum path: 4
Routing for Networks:
131.108.0.0
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 120)
使用show ip rip确认两台邻居路由器之间的发送和接收的RIP版本是否一致。一般，在实施中建议配置成version 2，V2支持无类路由。
R2#sho ip rip
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 11 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv Triggered RIP Key-chain
FastEthernet0/1 2 2
Automatic network summarization is in effect
Maximum path: 4
Routing for Networks:
131.108.0.0
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 120)
确认某些接口是否错误配置了passive-interface,passive-interface只收不发RIP报文，将导致邻居路由无法收到RIP报文。
router rip
version 2
passive-interface FastEthernet0/1
network 131.108.0.0
确认是否关闭了自动汇总 no auto-summary。RIP协议默认开启自动汇总，在网络边界将汇总跨网络路由，使得其他路由器无法学习到明细路由。在实际项目中，如非特殊需求，强烈建议关闭自动汇总。
2）步骤2
确认两台RIP邻居路由之间的连通性：
确认2/3层链路是否连通。如果2/3层不正常，将导致RIP报文无法交互，路由无法学习。可以通过show int查看互联接口是否UP，互联地址是否可以PING通。
R2#show int gi0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is Fast Ethernet, address is cc00.0a18.f001 (bia cc00.0a18.f001)
Internet address is 131.108.1.2/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
……
R2#ping 131.108.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 131.108.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/72/120 ms
确认是否配置安全功能过滤了RIP报文。RIP报文的端口号为UDP 520
3）步骤3
检查RIP协议的认证是否匹配。
例如在设备两端都配置了MD5的认证，而一般情况下由于设备采用了加密显示，无法分清是否匹配，如果不确定，建议重新配置尝试；如果认证字段不匹配，RIP不会正常学习到路由。
interface GigabitEthernet0/1
ip address 131.108.1.1 255.255.255.0
ip rip authentication mode md5
ip rip authentication key-chain 1 th%4s89&49d
4）步骤4
确认metric值是否超过最大跳数限制16跳。一般有以下两种情况可能使得RIP跳数超过16跳，使得路由不可用。
在做RIP路由控制时，会用到offset-list调整RIP路由跳数达到控制路由优选的目的。在使用时需要特写注意跳数的修改，需要全局把握，确认路由在传递过程中跳数不会超出16跳。
以下是一个offset-list调整超出16跳的例子：
在R1上，对131.108.2/24子网进行offset-list调整，将metric增加16并公布给R2
access-list 1 permit 131.108.2.0 0.0.0.255
router rip
version 2
offset-list 1 out 16 GigabitEthernet0/1
network 131.108.0.0
在调整前，R2能学习到该子网路由：
R2#show ip route rip
131.108.0.0/24 is subnetted, 2 subnets
R 131.108.2.0 [120/1] via 131.108.1.1, 00:00:28, FastEthernet0/1
调整之后，在R2的rip数据库中显示该路由不可达：
R2#show ip rip database
131.108.0.0/16 auto-summary
131.108.1.0/24 directly connected, GigabitEthernet0/1
131.108.2.0/24 is possibly down
之后从路由表中消失：
R2#show ip route rip
R2#
RIP协议在进行路由重发布时，缺省是没有定义metric值的，而如果重发布的路由本身metric值超过了16跳的限制，则在RIP中将看不到重发布过来的路由。
例如：
router ospf 1
log-adjacency-changes
network 21.0.31.0 0.0.0.3 area 0
!
router rip
version 2
redistribute ospf 1
network 131.108.0.0
那么对端路由将无法装载从OSPF重发布进来的路由。
在RIP重发布时，要求在重发布协议后增加合适的度量值。
例如：redistribute ospf 1 metric 1
5）步骤5
如果通过以上步骤无法排除故障，请收集以下信息，同时致电400寻求支持。
show run
show ver
show cpu
show log
show interface
show ip route
show ip rip
show ip rip databace
如果是RIP报文交互异常，请打开debug开关。然后shutdown /no shutdown接口，使得RIP重新交互收集信息。Debug信息量较大，会加大CPU的负担，有一定风险，请评估好风险并与客户确认。如果网络规模较大，业务重要，请与400联系后操作。
debug ip rip event
debug ip rip nsm
debug ip rip route
debug ip rip packet
2.3.4 OSPFv2
2.3.4.1 故障处理流程
2.3.4.2 故障处理步骤
1）步骤1
通过show ip ospf neighbor确认邻居状态。OSPF邻居正常建立是OSPF协议交互的基础，首先必须确保邻居状态正常。
Ruijie(config-router)#sho ip ospf neighbor
OSPF process 1, 1 Neighbors, 1 is Full:
Neighbor ID Pri State BFD State Dead Time Address Interface
1.1.1.1 1 Full/BDR - 00:00:38 1.1.1.1 FastEthernet 0/0
故障状态下，show ip ospf neighbor，如果邻居停留在以下几种邻居状态下，请参照相应状态下的排查步骤操作：
Show 邻居为空：邻居根本没有建立，请转步骤2处理
EXSTART：邻居已经过了two-way状态，说明基本的ospf参数已经OK，转步骤3处理
FULL：如果邻居已经正常建立，但OSPF路由学习异常，请转步骤4处理
2）步骤2
检查到邻居的接口是否up，ping对端地址是否能通。如果接口没有UP，ospf自然不会建立邻居。
R1#show int gi 0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is GigabitEthernet, address is cc00.0bd0.f001 (bia cc00.0bd0.f001)
Internet address is 131.108.1.1/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:04, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 220 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 4 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
R1#ping 131.108.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 131.108.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 96/111/144 ms
R1#
检查配置，确认ospf network语句是否将接口宣告。
例如，R1的OSPF配置如下：
router ospf 1
log-adjacency-changes
network 131.108.1.0 0.0.0.255 area 0
network 131.108.2.0 0.0.0.255 area 0
使用show ip ospf interface可以检查接口是否启用OSPF协议
R1#show ip os int
Loopback0 is up, line protocol is up
Internet Address 131.108.2.1/24, Area 0
Process ID 1, Router ID 172.16.1.1, Network Type LOOPBACK, Cost: 1
Loopback interface is treated as a stub Host
GigabitEthernet0/1 is up, line protocol is up
Internet Address 131.108.1.1/24, Area 0
Process ID 1, Router ID 172.16.1.1, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 172.16.1.1, Interface address 131.108.1.1
Backup Designated router (ID) 131.108.1.2, Interface address 131.108.1.2
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:09
Supports Link-local Signaling (LLS)
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 131.108.1.2 (Backup Designated Router)
Suppress hello for 0 neighbor(s)
R1#
检查到达OSPF邻居的接口是否被passive。接口如果被passive，建立和维护OSPF邻居状态的hello报文将不会发送，邻居关系将不能full。
确认OSPF ROUTER-ID是否冲突。必须确保全网OSPF路由器ROUTER-ID都不一样。当ROUTER-ID冲突时，日志有告警
*Dec 30 16:26:59: %OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 2.2.2
.2 from 1.1.1.2 on interface FastEthernet 0/0:1.1.1.1.
检查是否有ACL阻断OSPF的报文。OSPF使用的是IP协议，协议号为89。
检查OSPF接口的hello-interval /dead interval是否一致，如果这两个时间不一致，邻居关系将不能full。
查看接口的hello /dead interval时间：
R1#show ip ospf interface
GigabitEthernet0/1 is up, line protocol is up
Internet Address 131.108.1.1/24, Area 0
Process ID 1, Router ID 172.16.1.1, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State BDR, Priority 1
Designated Router (ID) 131.108.1.2, Interface address 131.108.1.2
Backup Designated router (ID) 172.16.1.1, Interface address 131.108.1.1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:04
Supports Link-local Signaling (LLS)
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 2
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 131.108.1.2 (Designated Router)
Suppress hello for 0 neighbor(s)
// hello-interval和dead-interval邻居双方必须保持一致。
可以在接口下通过以下命令修改：
Ruijie(config-if-FastEthernet 0/0)#ip ospf hello-interval 10
Ruijie(config-if-FastEthernet 0/0)#ip ospf dead-interval 40
检查OSPF接口的子网掩码是否一致。如果掩码不一致，OSPF邻居建立不起来。
由于子网掩码不一致并不影响接口的IP ping通，因此此类故障一般比较隐藏。但现在的软件版本，可以在日志中自动报错。
Ruijie#*Dec 30 17:02:16: %OSPF-4-IF_CONF_ERR: Received Hello packet from 2.2.2.2
via FastEthernet 0/0:1.1.1.1: network mask mismatch.
检查OSPF接口所在区域是否一致。如果区域不一致，OSPF邻居建立不起来。
如果OSPF 有配区域/接口认证，检查OSPF两端的认证类型是否匹配。如果认证不匹配，OSPF邻居建立不起来。
如果OSPF有特殊区域存在，如stub或 NSSA区域，则要检查两端的区域类型配置是否一致。如果区域类型不一致，OSPF邻居建立不起来。
从日志中可以看到有option bit不匹配的告警。
*Dec 30 17:07:27: %OSPF-4-IF_CONF_ERR: Received Hello packet from 2.2.2.2 via FastEthernet 0/0:1.1.1.1: options mismatchLocal(*|-|-|-|-|-|-|-) <-> Nbr(*|-|-|-|-|-|E|-).
3）步骤3
如果OSPF接口两端的MTU不一致，则OSPF邻居可能卡在exchange 或exstart状态，不能full。
例如，R1的F0/1 IP MTU 错误地配置为1000
interface FastEthernet0/1
no switchport
ip address 131.108.1.1 255.255.255.0
ip mtu 1000
则OSPF 邻居状态如下：
R1#show ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
131.108.1.2 1 EXSTART/DR 00:00:39 131.108.1.2 FastEthernet0/1
4）步骤4
如果邻居已经进入FULL状态，那么就需要查看OSPF DATABASE来定位故障。
如果show ip ospf database中的LSA都是正常的，但就是无法装载全局路由表（show ip route）那么最大的可能是邻居接口类型不一致。最常见的是一边配置成BROADCAST 一边配置成POINT_TO_POINT。可以通过show ip ospf interface来确认接口的OSPF类型。
R2#show ip ospf interface
GigabitEthernet0/1 is up, line protocol is up
Internet Address 131.108.1.2/24, Area 0
Process ID 1, Router ID 131.108.3.1, Network Type POINT_TO_POINT, Cost: 1
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:04
Supports Link-local Signaling (LLS)
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 3
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 172.16.1.1
Suppress hello for 0 neighbor(s)
如果DATABASE中某些LSA缺少了，那么需要从产生相应LSA的源头逐跳排查。按照前面的步骤逐步确认。
如果OSPF邻居建立均正常，那么DATABASE的异常一般发生在与其他协议互相重发布的情况下。常见的是其他协议重发布进OSPF时，需要在重发布命令后加上subnet参数。如果没有该参数，将只发布主类路由。
例如：
Ruijie(config-router)#redistribute rip subnets
5）步骤5
如果通过以上步骤无法排除故障，请收集以下信息，同时致电400寻求支持。
show run
show ver
show cpu
show log
show interface
show ip route
show ip route ospf
show ip ospf
show ip ospf neighbor
show ip ospf interface
show ip ospf database
如果是OSPF报文交互异常，请打开debug开关。然后shutdown /no shutdown接口，使得OSPF重新交互收集信息。Debug信息量较大，会加大CPU的负担，有一定风险，请评估好风险并与客户确认。如果网络规模较大，业务重要，请与400联系后操作。
debug ip ospf event
debug ip ospf packet
debug ip ospf route
debug ip ospf lsa
2.3.5 BGP
2.3.5.1 故障处理流程
2.3.5.2 故障处理步骤
1）步骤1
采用show ip bgp neighbor x.x.x.x查看邻居状态：
BGP_HX1#sh ip bg neighbors 172.8.12.2
BGP neighbor is 172.8.12.2, remote AS 100, local AS 100, internal link
BGP version 4, remote router ID 2.2.2.2
BGP state = Established, up for 00:21:42 //该状态表示邻居建议成功
Last read , hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received (old and new)
Address family IPv4 Unicast: advertised and received
Received 27 messages, 0 notifications, 0 in queue
open message:1 update message:0 keepalive message:26
refresh message:0 dynamic cap:0 notifications:0
Sent 26 messages, 0 notifications, 0 in queue
open message:1 update message:0 keepalive message:25
refresh message:0 dynamic cap:0 notifications:0
Route refresh request: received 0, sent 0
Minimum time between advertisement runs is 5 seconds
For address family: IPv4 Unicast
BGP table version 1, neighbor version 1
Index 1, Offset 0, Mask 0x2
0 accepted prefixes
0 announced prefixes
Connections established 1; dropped 0
Local host: 172.8.12.1, Local port: 179
Foreign host: 172.8.12.2, Foreign port: 1071
Nexthop: 172.8.12.1
如果邻居无法建立，请转步骤2处理。
2）步骤2
（a）使用ping命令检测BGP邻居之间是否能ping通：
如果能ping通，说明邻居之间的路由可达并且链路传输没有问题，请转（b）处理；
如果不能ping通，请排查ping不通的原因（比如，BGP邻居所依赖的路由、ARP等）；
（b）检查是否ACL拒绝了TCP 179端口，如果有，那么请修改相关的ACL和运用：
BGP_HX2#sh access-lists
ip access-list extended deny_tcp179
10 deny tcp any any eq bgp
20 deny tcp any eq bgp any
30 permit ip any any
BGP_HX2#
如果没有禁止TCP的179端口的ACL，请转（c）处理。
（c）检查邻居的Router-ID是否冲突：
BGP_HX1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 1
1 BGP AS-PATH entries
0 BGP Community entries
0 BGP Prefix entries (Maximum-prefix:4294967295)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.8.12.2 4 100 63 62 1 0 0 00:52:45 0
Total number of neighbors 1
如果冲突，可以采用进程下手动修改Router-ID：
BGP_HX1(config-router)#bgp router-id ?
A.B.C.D Router-id
如果不冲突，请转（d）处理；
（d）检查两端的AS是否配置正确：
如果配置错误，请修改指定的正确的AS；
如果配置正确，请转（e）处理；
（e）检查其他的配置情况：
如果是iBGP邻居关系，请确保邻居之间指定的AS为同一个AS；
如果是eBGP邻居关系，请确保如果使用loopback接口建立邻居时，配置了ebgp-multihop合适的跳数；
（f）如果按照上述步骤仍然无法排查邻居建立不正常的现象，请转步骤4处理；如果邻居关系建
立正常，请转步骤3处理；
3）步骤3
（a）查看路由是否正确发布：
BGP_HX2#sh run | b r b
router bgp 100
bgp log-neighbor-changes
neighbor 172.8.12.1 remote-as 100
!
address-family ipv4
network 100.1.1.1 mask 255.255.255.255 //后面的掩码必须和show ip route显示的一致
neighbor 172.8.12.1 activate
exit-address-family
（b）查看路由是否学习到：
BGP_HX1#sh ip bg summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 2
1 BGP AS-PATH entries
0 BGP Community entries
1 BGP Prefix entries (Maximum-prefix:4294967295)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.8.12.2 4 100 214 214 2 0 0 03:04:43 1
Total number of neighbors 1
//从邻居那里学习到一条路由；
BGP_HX1#sh ip bgp
BGP table version is 2, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i100.1.1.1/32 172.8.12.2 0 100 0 i
Total number of prefixes 1
//路由学习正常
如果没有学习成功，请转（c）处理；
（c）是否有做路由策略，策略是否配置正确：
如果路由器接的入口\出口有配置路由策略，请确保需要学习的路由没有被过滤；如果被过
滤，请修正路由策略；
如果路由器接的入口\出口没有配置路由策略或者策略配置成功，转（d）处理；
（d）是否有超过设备BGP路由的最大容量：
BGP_HX1#sh ip bg summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 2
1 BGP AS-PATH entries
0 BGP Community entries
1 BGP Prefix entries (Maximum-prefix:4294967295)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.8.12.2 4 100 214 214 2 0 0 03:04:43 1
Total number of neighbors 1
// State/PfxRcd处统计了从邻居学习到的路由前缀数目，然后对照SPEC表；
如果仍难不能学习到路由，请转步骤4处理；如果学习到但是异常，请转（e）处理；
（e）如果路由表显示异常，请检查下一跳是否可达：
BGP_HX1#sh ip bgp
BGP table version is 2, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* i100.1.1.1/32 172.8.12.2 0 100 0 200 100 i
Total number of prefixes 1
此条BGP路由在路由表中未能显示“>”，show ip route查看下一跳路由是否存在，如果不存在请检查BGP对应的IGP路由表；
4）步骤
如果通过以上步骤无法排除故障，请收集以下信息，同时致电400寻求支持。
show run
show ip int bri
show ip route
show ip bgp nei
show ip bgp summary
show ip bg
debug ip bgp events
debug ip bgp updates
2.4 安全
2.4.1 IPSec
2.4.1.1 故障处理流程
2.4.1.2 故障处理步骤
1）步骤1
检查隧道两端的路由是否可达，是否有到对端通讯点的路由在路由器两端去掉接口的cryto map，然后两台路由器之间互ping，看能否ping通？确认加密peer可以互相访问，请转步骤2。
如果能通，证明peer之间的路由没有问题，然后再各自的peer上是否有对端通讯点的路由。
如果不能通，需要检查物理线路，排查物理线路问题
2）步骤2
检查第一阶段的配置，查看双方是否一致？确认第一阶段配置正确，请转步骤3。如果第一阶段配置正确，但是第一阶段仍然无法协商成功，请转步骤5。
查看双方的IKE的策略是否匹配，通过show crypto isakmp policy。
Ruijie#show crypto isakmp policy
Default protection suite
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Rsa-Sig
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds
查看双方的预共享密钥配置是否一致，通过show run查看crypto isakmp key 0 address x.x.x.x
查看双方的peer是否指正确，且建立IPSEC隧道的地址是否正确？
查看双方的peer，使其一致
查看是否配置了Router(config)#cry map crymap local-address，默认情况下，以ipsec数据
包发出接口的ip地址为ipsec的本地地址；
查看双方的ipsec的协商模式是否一致？
3）步骤3
检查第二阶段的配置，查看双方是否一致？确认第二阶段配置正确，请转步骤4。如果第二阶段配置正确，但是第二阶段仍然无法协商成功，请转步骤5。
查看ipsec的转换集是否一致，通过如下命令查看:
Router#show crypto ipsec transform-set
transform set ipsec: { esp-md5-hmac,esp-des,}
will negotiate = {Tunnel,}
查看两端的感兴趣流是否互为对称，通过show access-list来查看；感兴趣流必须严格匹配，
同时我司只支持一个ACL中一条ACE方式，如果需要实现多感兴趣流，可以通过多ACL方式实现。在多分支单服务端的模型下，确保服务端配置的感兴趣数据流不重叠，详见
《[RSR系列路由器]IPSEC感兴趣流重叠故障案例.doc》
如果加密的数据流需要用多条ACE条目定义：如果是老版本（RSR10/10-01G/20：10.3(5b6)之前；RSR20-14E/F：10.3(5b8)之前；RSR30:10.4(3b11)之前；RSR50/50E全系列版本；RSR77:10.4(3b15)之前）那么请参考《RSR系列路由器IPSEC-VPN多感兴趣流配置案例V2.0.doc》配置；如果是新版本（RSR10/10-01G/20：10.3(5b6)及之后；RSR20-14E/F：10.3(5b8)及之后；RSR30:10.4(3b11)及之后；RSR77:10.4(3b15)及之后），那么和思科一致，可以在一个ACL中包含多条ACE
4）步骤4
查看入方向的ACL，是否放行感兴趣流到感兴趣流的流量和peer之间的isakmp, 如果没有放行，需添加允许感兴趣流到感兴趣流的ACL。如果ACL已经放行，但是数据还是无法通信，请转步骤5。
R2#show access-lists
ip access-list extended 100
10 permit udp host 218.1.1.1 eq isakmp host 218.1.1.2 eq isakmp
20 permit 50 host 12.12.12.1 host 12.12.12.2
4 packets filtered
举例：
R2:
ip access-list extended 100
10 permit udp host 218.1.1.1 eq isakmp host 218.1.1.2 eq isakmp
20 permit 50 host 12.12.12.1 host 12.12.12.2
30 permit ip host 1.1.1.1 host 2.2.2.2 //需增加命令
R2(config)#interface fastEthernet 0/0
R2(config-if-FastEthernet 0/0)#ip access-group 100 in
5）步骤5
按照上述4个步骤排查后仍然存在问题，收集如下信息，请联系400进一步处理。
debug crypto isakmp
debug crypto ipsec
show crypto memory[隐藏命令]
show crypto detail[隐藏命令]
show crypto state[隐藏命令]
show crypto data[隐藏命令]
show cpu
show memory
show interface
show cry isa sa
show cry ipsec sa
2.4.2 NAT(12.6RPJ3暂不支持)
2.4.2.1 故障处理流程
2.4.2.2 故障处理步骤
1）步骤1
检查报文经过的入/出接口是否已经配置NAT规则。同时可以通过带源地址的traceroute检验报文的入和出接口是否和预想设计的路径一致。如果确定配置正确并且路由走向正确，请转步骤2。
interface FastEthernet 0/0
ip ref
ip nat inside
ip address 1.1.1.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet 0/1
ip ref
ip nat outside
ip address 2.2.2.2 255.255.255.0
duplex auto
speed auto
2）步骤2
检查配置的NAT规则中的ACL，是否允许相应的报文进行NAT地址转换。如果ACL中的rule规则，并不包括该报文，那么该报文只能被三层转发，无法进行地址转换。
Ruijie#show access-lists
ip access-list extended 100
10 permit ip 20.1.1.0 0.0.0.255 any
Ruijie#show run
interface FastEthernet 0/0
ip nat inside
ip address 1.1.1.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet 0/1
ip nat outside
ip address 2.2.2.2 255.255.255.0
duplex auto
speed auto
!
ip nat pool ruijie 10.1.1.0 10.1.1.200 netmask 255.255.255.0
ip nat inside source list 100 pool ruijie
如果有多个规则并行的时候，请通过隐藏命令明确debug ip nat show rule确认
3）步骤3
NPE50 nat匹配规则的时候使用访问列表作为首要条件，地址池配置中只对一个地址池下面的多条规则逐一查找，不查找多个地址池配置。地址池匹配中可以针对出接口查找，但不支持针对路由下一跳查找。
举例说明
如果配置如下，则对于g0/1口的地址池其实无法匹配。
ip access-list standard 10
10 permit any
ip access-list standard 11
10 permit any
ip nat pool test prefix-length 24
address 100.90.20.100 100.90.20.101 match interface gigabitEthernet 0/2
ip nat pool test1 prefix-length 30
address 200.90.20.100 200.90.20.101 match interface gigabitEthernet 0/1
ip nat inside source list 10 pool test overload
ip nat inside source list 11 pool test1 overload
正确的配置方式如下：
ip access-list standard 10
10 permit any
ip nat pool test prefix-length 24
address 100.90.20.100 100.90.20.101 match interface gigabitEthernet 0/2
address 200.90.20.100 200.90.20.101 match interface gigabitEthernet 0/1
ip nat inside source list 10 pool test overload
4）步骤4
如果上述步骤无法定位问题，请联系400进一步处理。在单个报文调试的情况下收集debug ip nat/debug ip nat event/show ip nat translations
2.4.3 SSH
2.4.3.1 故障处理流程
2.4.3.2 故障处理步骤
1）步骤1
从客户端ping 设备的SSH服务端地址，确认网络连接是否正常。确认网络链路正常，请转步骤2。
2）步骤2
确认使用服务器支持的SSH客户端。现场可尝试使用不同的客户端软件，如putty/crt等软件。确认客户端正确，请转步骤3
3）步骤3
确认设备上的服务器密钥是否已经生成。
Ruijie#show crypto key mypubkey rsa
% Key pair was generated at: 14:39:17 UTC Mon, Dec 27, 2010
Key name: RSA1 private
Usage: SSH Purpose Key
Key is not exportable.
Key Data:
AAAAASMA AABBAJW2 tFp/W+df SPmeeZ6M j4a23AtI NAcAAB2t LB4TGSsL DM5wfQDQ
KJxkJ9KL x+7yRZIW phDLHnDo z2Eu5Z0a S2U=
% Key pair was generated at: 14:39:17 UTC Mon, Dec 27, 2010
Key name: RSA private
Usage: SSH Purpose Key
Key is not exportable.
Key Data:
AAAAASMA AABBAOC9 TeP06O+Y M813ER2h /o5lNAgM PktqB0X3 eQ/PfzPH PYq5IcYA
abZtdg4d yyvAkKYy zXspN/ii cL4We4hA 2L8=
如果没有显示，则说明没有密钥，请使用如下命令生成密钥：
Ruijie(config)#crypto key generate rsa
% You already have RSA keys.
% Do you really want to replace them? [yes/no]:yes
Choose the size of the key modulus in the range of 360 to 2048 for your
Signature Keys. Choosing a key modulus greater than 512 may take
a few minutes.
How many bits in the modulus [512]:
% Generating 512 bit RSA1 keys ...[ok]
% Generating 512 bit RSA keys ...[ok]
默认为1024。
4）步骤4
确认客户端使用的ssh的版本是否是路由器支持的，路由器默认支持ssh2.0，兼容1.x，确认登陆客户端软件所选择的版本。
Ruijie#show service
ssh-server : enabled
telnet-server : enabled
web-server : disabled
snmp-agent : enabled
5）步骤5
确认客户端使用的ssh的版本是否是路由器支持的，路由器默认支持SSH1.99，兼容1.x，确认登陆客户端软件所选择的版本。
Ruijie(config)#ip ssh version ?
<1-2> Protocol version
Ruijie(config)#ip ssh version
6）步骤6
检查line vty下的配置是否正确。
Ruijie(config)#line vty 0 35
Ruijie(config-line)#transport input ?
all All protocols
none No protocols
ssh TCP/IP SSH protocol
telnet TCP/IP Telnet protocol
Ruijie(config-line)#transport input all/ssh
系统默认的是transport input all,可以同时支持ssh和 telnet,但是如果修改成 transport input telnet,那么此vty下的ssh用户不可用，所以还需要察看有没有transport input telnet,如果有，建议删除。
7）步骤7
按照上述6个步骤排查后仍然存在问题，基本可以判断为软件SSH功能故障，请联系400进一步处理
2.5 QoS
2.5.1 故障处理流程
2.5.2 故障处理步骤
2）步骤1
（a）查看流量匹配和分类是否正确：
（b）查看报文是否进入分类的队列：show port-queue statistics int xxx
队列统计，PASS表示通过的报文，Drop表示该队列报文有过载。Que表示有缓存的报文
3）步骤6
如果上述步骤无法定位问题，请联系400进一步处理，并同时收集如下信息：
show run
show ip int bri
show interface xx //隔5s show 一次，联系show 5次
show traffic classifier
show traffic behavior
show traffic policy
show port-queue
show port-queue statistics interface xxx
2.6 MPLS/MPLS VPN(12.6RPJ3暂时不支持)
2.6.1 MPLS VPN路由学习异常
2.6.1.1 故障处理流程
2.6.1.2 故障处理步骤
1）步骤1
检查CE2端是否有对端CE的路由，71.11.1.0为对端CE1的路由：
CE2#show ip ref route
Codes: * - default route
# - zero route
ip mask weight path-id next-hop interface
255.255.255.255 255.255.255.255 1 4 0.0.0.0 Local 0
224.0.0.0 240.0.0.0 1 1 224.0.0.0
224.0.0.0 255.255.255.0 1 4 0.0.0.0 Local 0
73.11.1.0 255.255.255.0 1 165 0.0.0.0 GigabitEthernet 2/0
73.11.1.255 255.255.255.255 1 2 0.0.0.0
73.11.1.2 255.255.255.255 1 4 0.0.0.0 Local 0
73.11.1.1 255.255.255.255 1 169 73.11.1.1 GigabitEthernet 2/0
71.11.1.0 255.255.255.0 1 169 73.11.1.1 GigabitEthernet 2/0
2）步骤2
检查PE与CE之间的路由学习情况，本端和对端CE是否有将自己的路由信息发布给直连的PE
路由器，在PE上查看VRF路由表：
PE1#show ip ref route vrf vpn1
Codes: * - default route
# - zero route
ip mask weight path-id next-hop interface
255.255.255.255 255.255.255.255 1 4 0.0.0.0 Local 0
224.0.0.0 240.0.0.0 1 1 224.0.0.0
224.0.0.0 255.255.255.0 1 4 0.0.0.0 Local 0
73.11.1.0 255.255.255.0 0 1048573 0.0.0.0 ftn nhlfe
71.11.1.0 255.255.255.0 1 51 0.0.0.0 GigabitEthernet 1/1/3
71.11.1.255 255.255.255.255 1 4 0.0.0.0 Local 0
71.11.1.2 255.255.255.255 1 52 71.11.1.2 GigabitEthernet 1/1/3
71.11.1.1 255.255.255.255 1 4 0.0.0.0 Local 0
3）步骤3
采用sh bgp vpnv4 unicast all neighbor.x.x.x查看vpnv4邻居是否建立？
PE1#show bgp vpnv4 unicast all neighbor 3.3.3.3
BGP neighbor is 3.3.3.3, remote AS 100, local AS 100, internal link
BGP version 4, remote router ID 3.3.3.3
BGP state = Established, up for 01:53:18
Last read 00:32:00, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received (old and new)
Address family IPv4 Unicast: advertised and received
Address family VPNv4 Unicast: advertised and received
Received 133 messages, 0 notifications, 0 in queue
open message:1 update message:3 keepalive message:129
refresh message:0 dynamic cap:0 notifications:0
Sent 133 messages, 0 notifications, 0 in queue
open message:1 update message:3 keepalive message:129
refresh message:0 dynamic cap:0 notifications:0
Route refresh request: received 0, sent 0
Minimum time between advertisement runs is 0 seconds
Update source is Loopback 0
For address family: IPv4 Unicast
BGP table version 1, neighbor version 1
Index 1, Offset 0, Mask 0x2
0 accepted prefixes
0 announced prefixes
For address family: VPNv4 Unicast
BGP table version 8, neighbor version 7
Index 1, Offset 0, Mask 0x2
Community attribute sent to this neighbor (extended)
1 accepted prefixes
1 announced prefixes
Connections established 10; dropped 9
Local host: 1.1.1.1, Local port: 1154
Foreign host: 3.3.3.3, Foreign port: 179
Nexthop: 1.1.1.1
Nexthop global: ::
Nexthop local: ::
BGP connection: non shared network
Last Reset: 01:56:56, due to BGP Notification sent
Notification Error Message: (Cease/Unspecified Error Subcode)
如果邻居没有问题，请转步骤4处理。
4）步骤4
检查本端PE是否学习到对端PE发过来的VPNV4私网路由：
PE1#show bgp vpnv4 unicast vrf vpn1
BGP table version is 1, local router ID is 11.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 71:1 (Default for VRF vpn1)
* 71.11.1.0/24 0.0.0.0 1 32768 ?
*> 0.0.0.0 0 32768 ?
*>i73.11.1.0/24 3.3.3.3 0 100 0 ?
Total number of prefixes 2
如果有学习到，但是在CE上没有学习到路由，请检查PE上是否将VPNV4路由从发布到PE与CE
运行的协议相关的vrf路由表里面，如果没有学习到，请检查本端是否有过滤或者RT是否配置正确？
5）步骤5
如果通过上面步骤无法定位问题，在相关设备上请收集如下信息并致电400进一步处理：
show run
show ip route
show ip ref route
sh ip route vrf <vrf名称>
show ip ref route vrf <vrf名称>
show ip vrf detail <vrf名称>
show bgp vpnv4 unicast all neighbor x.x.x.x
show bgp vpnv4 unicast vrf <vrf名称>
2.6.2 MPLS VPN转发故障
2.6.2.1 故障处理流程
2.6.2.2 故障处理步骤
1）步骤1
检查设备和接口上是否启用了MPLS功能：
a、查看全局下是否开启MPLS转发功能：
PE(config)#mpls ip
b、查看接口下是否开启标签交换能力：
PE(config)#int gigabitEthernet 0/0.23
PE(config-GigabitEthernet 0/0.23)#label-switching
c、查看接口下是否开启LDP协议？
PE(config)#int gigabitEthernet 0/0.23
PE(config-GigabitEthernet 0/0.23)#mpls ip
2）步骤2
检查MPLS转发表是否正常：
PE#sho mpls forwarding-table
Label Operation Code:
PH--PUSH label
PP--POP label
SW--SWAP label
SP--SWAP topmost label and push new label
DP--DROP packet
PC--POP label and continue lookup by IP or Label
PI--POP label and do ip lookup forward
PN--POP label and forward to nexthop
PM--POP label and do MAC lookup forward
PV--POP label and output to VC attach interface
IP--IP lookup forward
Local Outgoing OP FEC Outgoing Nexthop
label label interface
-- imp-null PH 2.2.2.2/32 Gi0/0 12.12.12.2
-- 1024 PH 3.3.3.3/32 Gi0/0 12.12.12.2
-- imp-null PH 23.23.23.0/24 Gi0/0 12.12.12.2
-- 1536 PH 20.0.0.0/24(V) Gi0/0 12.12.12.2
1024 imp-null PP 2.2.2.2/32 Gi0/0 12.12.12.2
1025 1024 SW 3.3.3.3/32 Gi0/0 12.12.12.2
1026 imp-null PP 23.23.23.0/24 Gi0/0 12.12.12.2
1536 -- PI VRF(vpn1) -- --
//正常情况下，在P或PE设备上应该至少看到所有BGP VPNv4邻居地址的标签
Label Operation Code:
PH--PUSH label
PP--POP label
SW--SWAP label
SP--SWAP topmost label and push new label
DP--DROP packet
PC--POP label and continue lookup by IP or Label
PI--POP label and do ip lookup forward
PN--POP label and forward to nexthop
PM--POP label and do MAC lookup forward
PV--POP label and output to VC attach interface
IP--IP lookup forward
Local Outgoing OP FEC Outgoing Nexthop
label label interface
-- imp-null PH 2.2.2.2/32 Gi0/0 12.12.12.2
Added by Route(vrf Global), Tag Stack: { 3 }
-- 1024 PH 3.3.3.3/32 Gi0/0 12.12.12.2
Added by Route(vrf Global), Tag Stack: { 1024 }
-- imp-null PH 23.23.23.0/24 Gi0/0 12.12.12.2
Added by Route(vrf Global), Tag Stack: { 3 }
-- 1536 PH 20.0.0.0/24(V) Gi0/0 12.12.12.2
Added by Route(vrf vpn1), Tag Stack: { 1536 1024 }
//正常情况下，在PE设备上，要看到VPN路由的双层标签
1024 imp-null PP 2.2.2.2/32 Gi0/0 12.12.12.2
Added by Route(vrf Global), Tag Stack: { 3 }
1025 1024 SW 3.3.3.3/32 Gi0/0 12.12.12.2
Added by Route(vrf Global), Tag Stack: { 1024 }
1026 imp-null PP 23.23.23.0/24 Gi0/0 12.12.12.2
Added by Route(vrf Global), Tag Stack: { 3 }
1536 -- PI VRF(vpn1) -- --
Added by Route(vrf vpn1), Tag Stack: { }。
如果确认所有P设备及PE设备的标签表均正常，但VPN数据仍无法正常转发，那么可能是bug，
转步骤4收集信息并致电400技术支持。如果标签转发表没有形成或不完整，请转步骤3处理。
3）步骤3
通过show mpls ldp neighbor命令确认LDP邻居是否正常建立
PE1#sho mpls ldp neighbor
Default VRF:
Peer LDP Ident: 2.2.2.2:0; Local LDP Ident: 1.1.1.1:0
TCP connection: 2.2.2.2.1119 - 1.1.1.1.646
State: OPERATIONAL; Msgs sent/recv: 531/532; UNSOLICITED
Up time: 02:11:06
LDP discovery sources:
Link Peer on GigabitEthernet 0/0, Src IP addr: 12.12.12.2
Addresses bound to peer LDP Ident:
12.12.12.2 23.23.23.2 2.2.2.2
//OPERATIONAL表示邻居已正常建立，若邻居无建立，则show mpls ldp neighbor回显中不会有
任何信息。
如果LDP邻居无法建立，请根据以下步骤排查：
a、LDP ROUTER-ID的自动选举原则与OSPF ROUTER-ID的自动选举原则一致。
b、LDP ROUTER-ID的作用不仅仅是标记一个LDP路由器，在没有配置传输地址时（一般不配
置传输地址），ROUTER-ID地址作为建立LDP邻居TCP会话的源地址，有几种情形容易造成
LDP ROUTER-ID不可达：
（Ⅰ）loopback地址没有宣告进IGP;
（Ⅱ）在没有配置loopback的情况下，自动选举的IP没宣告进IGP
具体的确认步骤如下：
通过show mpls ldp parameters确认当前设备的ROUTER-ID
PE1#sho mpls ldp parameters
Default VRF:
Protocol version: 1
Ldp Router ID: 1.1.1.1
Control Mode: INDEPENDENT
Propogate Release: FALSE
Label Merge: TRUE
Label Retention Mode: LIBERAL
Loop Detection Mode: off
Targeted Session Keepalive HoldTime/Interval: 180/60 sec
Targeted Hello HoldTime/Interval: 45/5 sec
LDP initial/maximum backoff: 15/120 sec
//注意，LDP邻居的ROUTER-ID不能冲突，否则TCP连接无法建立，邻居无法形成
则查看TCP连接表项，及LDP邻接表项
PE1#show tcp connect �C-查看TCP连接表项
tcp connect status:
TCB Local Address Foreign Address State
30720000 0.0.0.0.2650 0.0.0.0.0 LISTEN
2daa8800 0.0.0.0.1723 0.0.0.0.0 LISTEN
2da6f800 0.0.0.0.23 0.0.0.0.0 LISTEN
2da36000 0.0.0.0.646 0.0.0.0.0 LISTEN
2d981800 0.0.0.0.179 0.0.0.0.0 LISTEN
2d99c800 1.1.1.1.646 2.2.2.2.1120 ESTABLISHED
2d97f800 0.0.0.0.179 0.0.0.0.0 LISTEN
2d963000 1.1.1.1.179 3.3.3.3.7990 ESTABLISHED
2da1cc00 ::.179 ::.0 LISTEN
2da5c540 ::.23 ::.0 LISTEN
// ESTABLISHED表示一个正常的TCP连接。确认每对MP-BGP邻居是否建立TCP连接。
PE1#show mpls ldp discovery ---查看LDP邻接表项
Default VRF:
Local LDP Identifier:
1.1.1.1:0
Discovery Sources:
Interfaces:
GigabitEthernet 0/0 (ldp): xmit/recv
Total Adjacency count: 1
LDP Ident: 2.2.2.2:0
// GigabitEthernet 0/0 (ldp): xmit/recv 说明在VLAN100这个接口有收到LDP hello报文
LDP邻居无法建立，通常情况有两种：
1）TCP连接建立不起来
没收到对端发送过来的hello 报文
分析：
若TCP连接已建立，则打开debug mpls ldp nsm/binding/connections/session等调试开关，
确认LDP邻居无法建立的原因
若TCP连接无建立，那么确认这队LDP对等体的传输地址是否都可达。通过show ip route
确认是否有到达ROUTER-ID的路由条目，如果路由不可达，请修改IGP路由的配置。如果
路由可达，但还是无法建立TCP连接，那么请确认中间是否某学安全访问控制，如ACL。LDP
的HELLO包的端口号为UDP 646；TCP连接的端口号为 TCP 646
若没收到hello报文，打开debug mpls ldp message hello，查看是否正常收到或发送hello
报文，可在链路上抓包，确认报文是在哪丢了。
当LDP邻居正常建立后，如果分发的标签还是异常，请确认LSP是否连续：
这里有一个概念必须明确：收到LDP邻居发送来的对应FEC的标签映射消息，路由表中必须有
该FEC的路由，且掩码长度必须一致，该标签才能被装载到标签表，否则标签被丢弃。
LSP不连续的可能原因有：
核心网IGP部署的是RIP协议，启用了自动汇总功能
核心网IGP部署的是OSPF协议。如果是新建网络，一般不会在核心网部署STUB区域。但如果是旧网改造，在原有OSPF网络上叠加MPLS-VPN功能时，就需要注意。如果OSPF划分了STUB区域，那么STUB将通过汇总默认路由到达其他区域，照成LSP不连续。
LOOPBACK接口如果配置成24位掩码，在OSPF中，由于LOOPBACK接口默认通告32位掩码，照成邻居路由器收到的路由和标签不一致无法装载转发表。
确认步骤：
从上游往下游每一台路由器上，通过show mpls ldp bingings确认你所关注的FEC标签分发情况。观察是否每一台设备都有对应FEC的“local binding”和“remote binding”。Remote binding=LDP邻居分发的标签；loacl binding=本地分发给LDP邻居的标签
R1#sho mpls ldp bindings
Default VRF:
lib entry: 1.1.1.1/32
local binding: to lsr: 2.2.2.2:0, label: imp-null
remote binding: from lsr: 2.2.2.2:0, label: 1025 (not in FIB)
lib entry: 12.12.12.0/24
local binding: to lsr: 2.2.2.2:0, label: imp-null
remote binding: from lsr: 2.2.2.2:0, label: imp-null (not in FIB)
lib entry: 2.2.2.2/32
local binding: to lsr: 2.2.2.2:0, label: 1024
remote binding: from lsr: 2.2.2.2:0, label: imp-null
lib entry: 3.3.3.3/32
local binding: to lsr: 2.2.2.2:0, label: 1025
remote binding: from lsr: 2.2.2.2:0, label: 1024
lib entry: 23.23.23.0/24
local binding: to lsr: 2.2.2.2:0, label: 1026
remote binding: from lsr: 2.2.2.2:0, label: imp-null
以下是典型的存在路由不对称问题的show mpls ldp bindings：
PE2#sho mpls ldp bindings
Default VRF:
lib entry: 2.2.2.2/32
local binding: to lsr: 3.3.3.3:0, label: imp-null
local binding: to lsr: 1.1.1.1:0, label: imp-null
remote binding: from lsr: 3.3.3.3:0, label: 1024 (not in FIB)
remote binding: from lsr: 1.1.1.1:0, label: 1024 (not in FIB)
lib entry: 23.23.23.0/24
local binding: to lsr: 3.3.3.3:0, label: imp-null
local binding: to lsr: 1.1.1.1:0, label: imp-null
remote binding: from lsr: 3.3.3.3:0, label: imp-null (not in FIB)
remote binding: from lsr: 1.1.1.1:0, label: 1026 (not in FIB)
lib entry: 3.3.3.3/32
local binding: to lsr: 3.3.3.3:0, label: 1024
local binding: to lsr: 1.1.1.1:0, label: 1024
remote binding: from lsr: 1.1.1.1:0, label: 1025 (not in FIB)
lib entry: 3.3.3.0/24
remote binding: from lsr: 3.3.3.3:0, label: imp-null (not in FIB)
//只收到邻居发来的标签映射“remote binding”，本端没有分发标签“local binding”，这是典型的路由不对称问题，本路由器没有3.3.3.0/24的路由。遇到该问题就要确认为什么本地没有3.3.3.0/24的路由。涉及到IGP路由协议的故障排查，可以查阅相应协议的故障排查手册。
lib entry: 12.12.12.0/24
local binding: to lsr: 3.3.3.3:0, label: imp-null
local binding: to lsr: 1.1.1.1:0, label: imp-null
remote binding: from lsr: 3.3.3.3:0, label: 1025 (not in FIB)
remote binding: from lsr: 1.1.1.1:0, label: imp-null (not in FIB)
lib entry: 1.1.1.1/32
local binding: to lsr: 3.3.3.3:0, label: 1025
local binding: to lsr: 1.1.1.1:0, label: 1025
remote binding: from lsr: 3.3.3.3:0, label: 1026 (not in FIB)
remote binding: from lsr: 1.1.1.1:0, label: imp-null
如果经过以上排查任无法排除故障，请转步骤4处理
4）步骤4
如果通过以上步骤无法排除故障，请收集以下信息，同时致电400寻求支持
debug mpls ldp nsm/binding/connections/session //打开debug开关
clear mpls ldp nei * //收集LDP交互完整信息
undebug all //关闭debug开关
在每台设备上收集以下信息：
show run
show ver
show cpu
show ip route vrf vrf_name //确认PE路由器上vpn路由已经学习到
show ip route
show mpls forwarding-table detail
show mpls ldp bindings
show mpls ldp neighbor detail
show mpls ldp parameters
show mpls ldp discovery detail
show mpls ldp bindings
show tcp connect
2.7 链路层协议(12.6RPJ3暂不支持)
2.7.1 PPP
2.7.1.1 故障处理流程
2.7.1.2 故障处理步骤
1）步骤1
采用show interface <接口号>查看接口的状态：
线路可能的状态 |
||
如果出现Serial x is up, line protocol is down状态请转向步骤2；
2）步骤2
采用show run或者show interface serial <接口号>查看两端封装的协议是否都为PPP，如果不一致请修
改，如果一致请转步骤3；
3）步骤3
采用debug ppp packet查看PPP LCP的协商情况：
Ruijie# debug ppp packet
PPP: serial 1/0 [S] LCP CONFREQ id 3 len 10
MAGICNUMBER (6) 0x0 0x2b 0x39 0x1b
%LINK CHANGED: Interface serial 1/0, changed state to up
PPP: serial 1/0 [R] LCP CONFREQ id 6 len 10
MAGICNUMBER (6) 0x29 0xbd 0xea 0xeb
PPP: serial 1/0 [S] LCP CONFACK id 6 len 10
MAGICNUMBER (6) 0x29 0xbd 0xea 0xeb
PPP: serial 1/0 [R] LCP CONFACK id 3 len 10
MAGICNUMBER (6) 0x0 0x2b 0x39 0x1b
PPP: serial 1/0 LCP up
PPP: serial 1/0 PPP up.
双方路由器互相发送 LCP CONFREQ，再互相做LCP CONFACK应答，在LCP阶段，如果没有做认
证需要协商Magic number，如果有做认证请转入步骤4
4）步骤4
如果有做PPP认证，那么在PPP LCP协商过程中将协商下面参数：
｛认证类型、Magic number｝
通过查看配置，确认双方的认证类型和用户名和密码是否正确，如果正确请转入步骤5；
5）步骤5
采用debug ppp packet确认PPP NCP是否协商成功：
Ruijie# debug ppp packet
PPP: serial 1/0 [S] IPCP CONFREQ(2) id 10 len 2
Address (6) 0x64 0x64 0x64 0x1
PPP: serial 1/0 [R] IPCP CONFREQ(3) id 10 len 2
Address (6) 0x64 0x64 0x64 0x2
PPP: serial 1/0 [S] IPCP CONFACK(3) id 10 len 2
Address (6) 0x64 0x64 0x64 0x2
PPP: serial 1/0 [S] LCP PROTREJ id 4 len 10 protocol = 0x82070103
PPP: serial 1/0 [R] IPCP CONFACK(2) id 10 len 2
Address (6) 0x64 0x64 0x64 0x1
%LINE PROTOCOL CHANGE: Interface serial 1/0, changed state to UP
Ruijie#
PPP: serial 1/0 [S] LCP ECHOREQ id 1 len 12 magic 0x2b391b
双方路由器互相发送 IPCP CONFREQ，并且附上本身的 IP 地址，然后在收到 IPCP的 CONFREQ
请求之后，互相发送 IPCP CONFACK 应答附上对方的 IP地址，然后该接口的 PPP 协商就成功了。
6）步骤6
如果通过以上步骤无法排除故障，请收集以下信息，同时致电400寻求支持。
show run
show interface serial <接口号>
debug ppp event
debug ppp error
debug ppp packet
debug ppp negotiation
debug ppp authentication
2.7.2 MP
2.7.2.1 故障处理流程
2.7.2.2 故障处理步骤
1）步骤1
查看物理接口是否绑定到相应的Multilink组，标准配置如下：
interface Serial0/1
no ip address
encapsulation ppp
serial restart-delay 0
ppp multilink
ppp multilink group 2
!
interface Serial0/2
no ip address
encapsulation ppp
serial restart-delay 0
ppp multilink
ppp multilink group 2
!
interface Multilink2
ip address 2.1.1.1 255.255.255.0
ppp multilink
ppp multilink group 2
2）步骤2
采用show interface serial <接口号>查看绑定到Multilink物理接口情况，如果不能up，请转步骤3；
3）步骤3
这部分PPP协商请参照PPP部分，需要增加的是：
由于是Multilink，所以在LCP协商的过程中需要协商以下参数，请检查相关参数：
MRU：最大接收单元
认证协议类型：CHAP或PAP
Magic number：魔术字
Endpoint Discriminator：端点描述符该字段各个厂家实现机制不一样，我司设备在协商过程中不检
查这个选项；思科设备方面，如果一台设备有多个Multilink组，那么不同的组的Endpoint
Discriminator需要设置不一样才能正常绑定；
4）步骤4
如果通过以上步骤无法排除故障，请收集以下信息，同时致电400寻求支持。
show run
show interface serial
show controller e1
debug interface serial
show interfaces multilink
show ip interfaces multilink
debug ppp ne
debug ppp event
debug ppp error
debug ppp multilink event
debug ppp multilink error
2.8 可靠性
2.8.1 VRRP
2.8.1.1 故障处理流程
2.8.1.2 故障处理步骤
1）步骤1
使用show run初步确认VRRP主备设备的VRRP配置是否正确
检查VRRP组内所有成员配置是否对称，即要求VRRP组、虚拟 IP地址、VRRP报文广播间隔时间、认证方式和认证字的配置必须相同，如果存在不一致，请修改。如果VRRP工作仍然不正常，请继续排查。
使用show 命令进一步确认VRRP详细参数是否一致
由于某些参数是默认配置，在配置中不体现，在不同厂商设备对接或同一厂商不同版本之间可能存在默认值不一致的问题，可以通过show vrrp brief/show vrrp等show命令进一步确认VRRP组、虚拟 IP地址、VRRP报文广播间隔时间、认证方式是否配置一致。如果存在不一致，请修改。
RUIJIE(config)#sho vrrp brief
Interface Grp Pri timer Own Pre State Master addr Group addr
FastEthernet 0/0 1 100 3 - P Backup 1.1.1.2 1.1.1.254
RUIJIE2(config)#show vrrp brief
Interface Grp Pri timer Own Pre State Master addr Group addr
FastEthernet 0/0 1 100 3 - P Master 1.1.1.2 1.1.1.254
Grp：所处的VRRP组。同一VRRP组所有设备Grp组必须一致
Pri：优先级
Timer：保持时间。同一VRRP组所有设备timer必须一致
Own：如果该位为O，表示使用实际接口IP作为虚拟IP
Pre：P表示开启抢占功能，—表示未开启
State：当前状态。一个VRRP组内只能有一个Master
Addr：Master的实际IP地址
Group Addr：VRRP组的虚拟IP。同一VRRP组所有设备Group Addr必须一致
RUIJIE2#show vrrp 1
FastEthernet 0/0 - Group 1
State is Master
Virtual IP address is 1.1.1.254 configured
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1 sec
Preemption is enabled
min delay is 0 sec
Priority is 100
Master Router is 1.1.1.2 (local), priority is 100
Master Advertisement interval is 1 sec //通告间隔
Master Down interval is 3 sec //保持时间
以上红色字体部分在所有VRRP组的设备上必须保持一致。
确保参数完全一致后，如果不能排除故障，请进入步骤2.
2）步骤2
可以使用常用的PING测试链路连通性，PING VRRP实际接口IP地址，确认是否能够PING通。如果PING不通，常见以下几点：
检查物理链路是否连接正确，接口是否松动----参见链路层故障排查手册
检查接入层交换机是否配置了该VRRP的VLAN，互联接口类型是否正确access or trunk（在路由器子接口或三层交换机VRRP环境中常见）
检查生成树协议是否配置正确，show spannin-tree确认端口是否被阻塞----参见生成树故障排查手册
检查接口是否配置802.1x等协议
如果能够PING通，说明链路层没有问题，需要继续确认VRRP报文收发是否正常。
打开debug开关确认报文收发是否异常
打开debug vrrp packet开关，确实是否正常收发VRRP 报文，例如
*Nov 20 06:16:04: %7: VRRP: Grp 1 on interface Fa0/0 is sending advertisement checksum a9fd. //发送VRRP 报文的debug信息
正常情况下，Master只发送不会接收到VRRP报文，Backup只接收不发送VRRP报文。
如果debug vrrp确认可以正常收发VRRP报文，但VRRP状态依然不正确，那么请收集信息，致电400寻求支持
如果确认收发报文异常，请继续排查。
确认VRRP报文是否被过滤
这里需要特别注意到，VRRP报文的目的IP为224.0.0.18，是一个组播地址，在接口配置了ACL时，经常忽略了放行该组播地址。
同时需要确认接入交换机是否也做了相应的安全策略过滤了VRRP组播报文，如：交换机过滤了所有组播报文；ACL过滤了224.0.0.18
3）步骤3
如果通过以上步骤确认链路有正常转发VRRP报文的能力，但debug还是没有正常收发报文，那么就要怀疑是否是CPU高无法及时处理VRRP报文。通过show cpu命令查看。对照《CPU异常故障处理手册》处理。
4）步骤4
如果根据以上步骤无法判断故障，请收集信息，联系400进一步处理。
show version
show run
show vrrp
show vrrp brief
show interface
打开debug收集：Debug vrrp
2.8.2 DLDP（12.6RPJ3暂时不支持）
2.8.2.1 故障处理流程
2.8.2.2 故障处理步骤
1）步骤1
检查设备DLDP的配置情况：
DLDP配置只需要单台路由器上配置，如果两端都配置请确保配置的参数一致。
b）如果汇聚路由器和多台分支路由器连接，在分支配置了DLDP之后，在汇聚路由器上只需要
利用分支发过来的ICMP ECHO，然后发送ICMP ECHO REPLAY来检测，避免了汇聚路由器发送
不必要的流量，只需要将DLDP的模式配置为PASSIVE模式即可，命令为：dldp passive
c）如果需要跨路由器检测，在配置DLDP的时候需要配置下一跳，命令为：dldp ip [ next hop ip ]
2）步骤2
采用show dldp interface <接口编号> 可以查看接口运行的DLDP的状态：
Ruijie(config)#show dldp interface fastEthernet 0/0
================= FastEthernet 0/0 ==================
dldp down times up times start time
dldp 8.8.8.1 1 2 1970-0-1 0:0:31
//显示参数的解释：
dldp：表示所配置的dldp的链路；
down times：表示从上一次清零开始到目前为止该 dldp 链路从UP变为DOWN的次数；
up times：表示从上一次清零开始到目前为止该dldp链路从DOWN 变为UP的次数；
start time：表示上一次清零的系统时间；
//如果需要精确查看up\down的次数，可以预先在接口下采用clear-dldp all或者单个ip将这个计数
器清零。
另外，也可以通过show dldp interface查看设备上所有接口的DLDP运行的情况。
如果DLDP状态为down，那么请采用show ip int brief才看链路是否正常，如果不正常请排除链路
问题，如果正常请转步骤3
3）步骤3
检查设备的二层信息：
采用show arp查看IP对应的MAC地址是否正确。
R1#sho arp
Protocol Address Age(min) Hardware Type Interface
Internet 2.2.2.2 13 001a.a940.6d64 arpa FastEthernet 0/0
Internet 2.2.2.1 -- 001a.a941.3f7d arpa FastEthernet 0/0
采用show ip ref adj查看邻接关系表是否正常，主要查看IP对应的l2add选项：
R1#show ip ref adj
index state type ip interface rfct chg vid tid len l2add
6 resolved forward 2.2.2.2 FastEthernet 0/0 2 0 0 800 14 001a.a940.6d64
4）步骤4
路由器上采用Ping命令测试需要检测的DLDP的ip地址，如果路由和二层信息都正常，但是ping
不通，请检查对端设备是否对ICMP流量有做过滤或者限制等。
5）步骤5
如果通过以上步骤无法排除故障，请收集以下信息，同时致电400寻求支持。
show run
show dldp interface //接口下clear-dldp all或者单个ip，然后再show
show ip route
show arp
show ip ref route
show ip ref adj
debug ip icmp //在两个运行DLDP的对等路由器上开启
2.8.3 BFD
2.8.3.1 故障处理流程
2.8.3.2 故障处理步骤
1）步骤1
检查物理链路，协议状态是否正常？
Ruijie# show interfaces gigabitEthernet 0/0
GigabitEthernet 0/0 is UP , line protocol is UP
>如果GigabitEthernet 0/0 is DOWN,说明物理线路不通，需要检测传输线路。
>如果line protocol is DOWN,说明协议未协商成功，需要检测协议状态。
此步骤可以参考PPP故障处理步骤部分的步骤1；
2）步骤2
先了解下BFD的建立过程和检测过程：
BFD的建立过程：
1、上层路由协议发现邻居后并建立连接；
2、上层路由协议在建立了新的邻居关系时，将邻居的参数及检测参数都（包括目的地址和源地址
等）通告给BFD；
3、BFD 根据收到的参数（发送间隔、接收间隔及检测倍数）进行计算并建立邻居。
4、BFD邻居建立以后通知BFD代理模块启用代理。
5、BFD代理模块主要完成心跳报文收发及超时检测工作。
BFD的检测过程：
1、网络出现故障；
2、BFD代理检测到链路/网络故障；
3、BFD代理通知BFD链路/网络出现故障；
4、拆除BFD 邻居会话；
5、BFD 通知本地上层协议进程邻居不可达；
6、本地上层协议中止上层协议邻居关系；
备注：如果网络中存在备用路径，路由器将选择备用路径。
BFD可以和多种协议联动，下面以OSPF为例：
Ruijie#show ip ospf neighbor
OSPF process 1, 1 Neighbors, 1 is Full:
Neighbor ID Pri State Dead Time Address Interface
1.1.1.2 1 Full/DR 00:00:37 1.1.1.2 GigabitEthernet 0/1
相关OSPF邻居异常现象请参考相关资料。
3）步骤3
1、检查接口是否配置BFD基本参数：
Ruijie(config)# interface GigabitEthernet 0/1
Ruijie(config-if)# bfd interval 50 min_rx 50 multiplier 3
2、路由协议是否绑定了BFD功能：
Ruijie(config-router)# router ospf 1
Ruijie(config-router)# bfd all-interfaces
3、查看接口是否禁用了BFD功能，如果禁用，需要no掉：
Ruijie(config)# interface GigabitEthernet 0/1
Ruijie (config-GigabitEthernet 0/0)# ip ospf bfd disable //禁用BFD功能命令；
4、由于我司设备默认开启bfd echo模式，其他厂商有可能不支持bfd echo模式或者关闭，所以需
要在我司设备上关闭bfd echo：
Ruijie(config)# interface GigabitEthernet 0/1
Ruijie (config-GigabitEthernet 0/0)# no bfd echo //关闭bfd echo模式
4）步骤4
特权模式下采用debug bfd packet ipv4 1.1.1.1（指定会话的邻居地址）查看BFD模块是否有报文发
出，如果没有发出有可能是BFD模块出问题了：
Ruijie#debug bfd packet ipv4 1.1.1.1
*Mar 31 11:53:22: %7: BFD-DEBUG Packet: Tx IP:1.1.1.1 ld/rd:1/1 diag:0 Up
*Mar 31 11:53:22: %7:BFD-DEBUG Packet: Rx IP:1.1.1.1 ld/rd:1/1 diag:0 Up ttl:255
>>通过show bfd neighbors details下面命令查看收发包的情况：
Ruijie#sh bfd neighbors details
OurAddr NeighAddr LD/RD RH/RS Holdown(mult) State Int
1.1.1.2 1.1.1.1 1/1 Up 0(3 ) Up
GigabitEthernet 0/0
Session state is Up and using echo function with 50 ms interval.
Local Diag: 0, Demand mode: 0, Poll bit: 0
MinTxInt: 3000000, MinRxInt: 3000000, Multiplier: 3
Received MinRxInt 3000000, Multiplier: 3
Holdown (hits): 9000(0), Hello (hits): 3000(1)
Rx Count: 5612, Rx Interval (ms) min/max/avg: 10/50/50
Tx Count: 5612, Tx Interval (ms) min/max/avg: 40/50/50
Registered protocols: OSPF
Uptime: 0:04:08
Last packet:
Version : 1 - Diagnostic : 0
State bit : Up - Demand bit : 0
Poll bit : 0 - Final bit : 0
Multplier : 3 - Length : 24
My Discr : 1 - Your Discr : 1
Min tx interval : 3000000 - Min rx interval: 3000000
Min Echo interval: 50000
同时，通过show interface <接口号>（多次）查看收发包、已经是否有丢包的情况：
Ruijie#sh interfaces gi 0/0
Index(dec):3 (hex):3
GigabitEthernet 0/0 is UP , line protocol is UP
Hardware is BCM1250 GigabitEthernet, address is 001a.a93a.671e (bia 001a.a93a.671e)
Interface address is: 1.1.1.1/24
ARP type: ARPA, ARP Timeout: 3600 seconds
MTU 1500 bytes, BW 1000000 Kbit
Encapsulation protocol is Ethernet-II, loopback not set
Keepalive interval is 10 sec , set
Carrier delay is 2 sec
Rxload is 1/255, Txload is 1/255
Queueing strategy: FIFO
Output queue 0/40, 0 drops;
Input queue 0/75, 0 drops
Link Mode: 1000M/Full-Duplex, media-type is twisted-pair.
Output flowcontrol is off;Input flowcontrol is off.
5 minutes input rate 35842 bits/sec, 67 packets/sec
5 minutes output rate 23947 bits/sec, 45 packets/sec
532397 packets input, 35153294 bytes, 0 no buffer, 0 dropped
Received 6 broadcasts, 0 runts, 0 giants
1 input errors, 1 CRC, 0 frame, 0 overrun, 0 abort
356175 packets output, 23522568 bytes, 0 underruns , 0 dropped
0 output errors, 0 collisions, 1 interface resets
5）步骤5
如果通过以上步骤无法排除故障，保存上述的操作log，同时收集以下信息，同时致电400寻求支
持。
show run
show int <接口号>
show ip route
show ip ref route
show ip ref adj
show arp
show bfd nei details
deb bfd event interface <接口号>
debug bfd packet ipv4 <邻居地址>
2.9 流平台
配置ACL，PBR，QOS TP流分类，VPN等业务，设备会开启流平台，进行流加速处理。
通过show efd ip fpm statistics/ show efd slot x ip fpm statistics可以查看建立的5元组流数量。
Ruijie#show efd ip fpm statistics
Flow table capacity: 327680
Flow number: 403
Defragment context number: 0
Defragment packet number: 0
Event count: 87
Fpm status: enable
Ruijie#
通过show efd ip fpm flows filter xxx / show efd slot x ip fpm flows filter xxx可以通过5元组过来流详细信息
RSR20-XA-54-1#show efd ip fpm flows filter ?
dst-interface Destination interface information
dst-ip Destination ip address
dst-port Destination port information
protocol-number Protocol number
src-interface Source interface information
src-ip Source ip address
src-port Source port information
vrf VPN Routing/Forwarding instance
RSR20-XA-54-1#show efd ip fpm flows filter
RSR20-XA-54-1#sh efd ip fpm flows filter protocol-number 17 src-ip 161.1.2.59 src-mask 32
Total number of flow entries: 84143
Proto Source Address Destionation Address SrcPort DstPort Vrf State RecvBytes src-ifx dst-ifx
17 161.1.2.59 224.0.0.2 646 646 0 1 955500 1 4095
224.0.0.2 161.1.2.59 646 646 0 1 0 4095 1
RSR20-XA-54-1#
RSR20-XA-54-1# sh efd ip fpm flows filter protocol-number 17 src-ip 161.1.2.59 src-mask 32 detail
Proto Source Address Destionation Address SrcPort DstPort Vrf State RecvBytes src-ifx dst-ifx
17 161.1.2.59 224.0.0.2 646 646 0 1 958090 1 4095
224.0.0.2 161.1.2.59 646 646 0 1 0 4095 1
org flows:
next: 1 tmsp: 6974768 event_sn: 719 status_flag: 64 eaf: 4294967295 gpf: 16
fbf_adj: 0 fbf_intf: 0 fbf_flags: 0 space: 2060493952 cid: 4 org_fid: 32195216
rep_fid: 32195217
rep flows:
next: 1 tmsp: 4294942827 event_sn: 6 status_flag: 64 eaf: 4294967295 gpf: 16
fbf_adj: 0 fbf_intf: 0 fbf_flags: 0 space: 2060493952 cid: 4 org_fid: 0
rep_fid: 0
conntrack:
next: 0 oflow_addr: 2060493824 rflow_addr: 2060493888 create_time: 4294942827 lifetime: 4294967295 app_proto: 0
num_slave: 0 mflow_addr: 0 xmod_reg_sn: 10 create_flag: 0 ori_seq_inc: 0 rep_seq_inc: 0
shid: 65532
RSR20-XA-54-1#