【交换机】部署三层组播（PIM）后设备CPU100%的故障排查思路及信息收集

发布时间：2013-09-26

点击量：6748

1）故障现象

S86 CPU利用率100%，查看进程发现nsmd进程CPU利用率非常高，客户全网启用了PIM-DM协议。

如果nsmd线程的cpu过高，可能是这个功能有大量的处理逻辑；可能是大量的末知名组播数据报文送上来需要处理;组播核心需要通告给PIM模块导致的；可能是大量的IGMP协议报文送上来需要处理。

ruijie#show cpu

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

CPU Using Rate Information

CPU utilization in five seconds: 100%

CPU utilization in one minute : 100%

CPU utilization in five minutes: 61%

NO 5Sec 1Min 5Min Process

53 87% 90% 49% nsmd

107 2% 2% 2% ssp_flow_rx_task

131 0% 0% 39% idle

//此处只列出主要线程

查看设备CPU报文接收情况，发现组播相关的报文量都很大

ruijie# show cpu-protect mboard

Type Pps Total Drop

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

tp-guard 0 0 0

arp 31 453692 0

dot1x 0 0 0

rldp 0 0 0

rerp 0 0 0

reup 0 0 0

slow-packet 0 0 0

bpdu 6 60170 0

isis 0 0 0

dhcps 0 0 0

gvrp 0 0 0

ripng 0 0 0

dvmrp 0 0 0

igmp 2 191623 13052 IGMP丢弃，说明曾经IGMP PPS很大

mpls 0 0 0

ospf 0 3410 0

ospf3 0 2537 0

pim 40 276920 12968 PIM协议报文

pimv6 0 0 0

rip 0 0 0

vrrp 0 0 0

mld 0 0 0

unknown-ipmc 7 28159 8 未知组播，表示未建立表项的组播报文

unknown-ipmcv6 0 0 0

stargv-ipmc 0 0 0

bgp_ttl1 0 0 0

ttl1 0 15399 2

hop_limit1 0 219 0

ttl0 0 0 0

dhcp-relay-c 7 76398 0

dhcp-relay-s 0 0 0

option82 0 0 0

udp-helper 0 0 0

tunnel-bpdu 0 0 0

tunnel-gvrp 0 0 0

ip4-packet-local 49 410762 0 目标IP是本地的报文

ip6-packet-local 1 5607 0

ip4-packet-other 200 2064530 722542 目标IP非本地，但需要CPU处理的（非以上详细分类）

ip6-packet-other 0 1462 0

ipv6mc 5 108763 1682

non-ip-packet-other 0 0 0

2）故障处理流程

3）故障处理步骤

a.步骤1

对于CPU利用率高的问题，常规信息收集手段包括：

1）查看CPU进程，查看CPP报文收发情况，show cpu，show cpu-protect mboard；

2）当设备可以管理（包括telnet或Console）的时候，进入debug support模式，执行show task 3-5次，show tech-support 2次；

3）当设备Console口也无法管理的时候，可先获取1次@@@@@，多次执行@@@@T，@@@@M，@@@@S继续执行一次@@@@@

针对组播导致设备CPU利用率高的问题，原因一般在于以下两个方面：

1）众多PIM、IGMP报文、未知组播送交换机都需要CPU进行处理导致的CPU利用率高。

2）锐捷的组播在表项超过硬件容量后，超出的部分能够基于软件转发，超过硬件容量的报文走CPU转发导致CPU利用率高（show msf msc确认）。

本案例中对于IPV4 other的报文可先行减小CPP阈值，查看是否能够缓解一定的CPU利用率

Ruijie#show cpu-protect summary

Type Pps Pri

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

ip4-packet-other 200 0 //默认ip4-packet-other的优先级为0，限速阀值200pps

ip6-packet-other 200 0

Ruijie(config)#cpu-protect type ip4-packet-other pps 50 //调整为50pps

b.步骤2

查看组播路由表项，发现存在大量用户网段为源的组播表项

ruijie#show ip mroute

(172.22.150.134, 224.112.56.29), 00:19:35/00:02:50, PIMDM, Flags: TF

(172.22.150.140, 224.112.56.29), 00:40:20/00:02:50, PIMDM, Flags: TF

(172.22.150.154, 224.112.56.29), 00:39:20/00:02:50, PIMDM, Flags: TF

(172.22.150.177, 224.112.56.29), 00:03:53/00:02:50, PIMDM, Flags: TF

(172.22.150.188, 224.112.56.29), 00:08:39/00:01:10, PIMDM, Flags: TF

(172.22.150.200, 224.112.56.29), 00:03:34/00:01:10, PIMDM, Flags: TF

(172.22.150.206, 224.112.56.29), 00:01:45/00:02:50, PIMDM, Flags: TF

(172.22.150.208, 224.112.56.29), 00:39:12/00:02:50, PIMDM, Flags: TF

(172.22.151.12, 224.112.56.29), 00:35:19/00:02:50, PIMDM, Flags: TF

(172.22.151.23, 224.112.56.29), 00:39:44/00:02:50, PIMDM, Flags: TF

(172.22.151.24, 224.112.56.29), 00:11:54/00:02:50, PIMDM, Flags: TF

(172.22.151.35, 224.112.56.29), 00:11:56/00:02:50, PIMDM, Flags: TF

(172.22.151.36, 224.112.56.29), 00:01:31/00:01:59, PIMDM, Flags: TF

(172.22.151.37, 224.112.56.29), 00:02:52/00:02:50, PIMDM, Flags: TF

(172.22.151.42, 224.112.56.29), 00:15:23/00:02:50, PIMDM, Flags: TF

(172.22.151.45, 224.112.56.29), 00:08:15/00:01:10, PIMDM, Flags: TF

(172.22.151.51, 224.112.56.29), 00:21:48/00:01:10, PIMDM, Flags: TF

(172.22.151.58, 224.112.56.29), 00:39:39/00:02:50, PIMDM, Flags: TF

(172.22.151.67, 224.112.56.29), 00:35:18/00:02:50, PIMDM, Flags: TF

(172.22.151.68, 224.112.56.29), 00:08:41/00:02:50, PIMDM, Flags: TF

(172.22.151.72, 224.112.56.29), 00:05:53/00:02:50, PIMDM, Flags: TF

注：Windows主机默认支持Upnp（即插即用特性），会发出目标为239.255.255.250的组播包，导致设备建立众多组播路由表，可能导致设备组播路由表溢出。

查看IGMP Group发现建立了大量非合法的组播组

ruijie#show ip igmp groups

239.255.255.239 VLAN 127 00:00:02 00:04:17 58.199.24.77

239.255.255.250 VLAN 127 03:49:23 00:04:15 58.199.24.115

224.1.1.1 VLAN 131 00:02:02 00:02:17 58.199.28.85

224.112.56.29 VLAN 131 00:00:03 00:04:16 58.199.28.48

239.255.255.239 VLAN 131 00:02:07 00:04:18 58.199.28.87

239.255.255.250 VLAN 131 00:02:10 00:04:15 58.199.28.32

224.112.56.29 VLAN 121 00:04:14 00:00:05 58.199.18.46

239.255.255.250 VLAN 121 00:08:24 00:04:15 58.199.18.57

224.3.1.3 VLAN 103 00:02:05 00:04:17 58.199.1.64

224.112.56.29 VLAN 103 00:02:09 00:04:14 58.199.1.26

239.255.255.239 VLAN 103 00:00:05 00:04:15 58.199.1.91

239.255.255.250 VLAN 103 00:02:09 00:04:14 58.199.1.20

本案例中需要进行组播网络全网优化：包括但不限于组播源控制（只允许合法的组播源）、IGMP组过滤（只允许提供的合法组播组）、接入组播监听及profile过滤，配置可参考常见咨询中的示例。

c.步骤3

观察设备是否从PIM协议报文触发建立组播表项

在实际部署组播中，对于设备下游所设置的防组播源欺骗，确实可以过滤欺骗从下游产生，但我们通常容易忽略一个问题，就是通过上游接口PIM-DM协议报文导致的设备频繁建立组播表项的问题。PIM-DM的状态刷新泛洪机制，连接组播源的DR设备接收到组播报文，也会创建组播路由，并且封装成pimv2的状态刷新报文分发给下游，会导致下游设备刷新建立表项，下游无用户加入时才会进行剪枝操作，可以避免周期性的流Flood行为，较少网络拥塞的可能性。这种机制设计本身是优化组播频繁周期性的组播流Flood行为的，但如果源DR也遭受了组播源欺骗，那么其PIM State Refresh就会将众多的组播表项信息发送给下游，导致出现问题。所以我们通常要求组播优化需要全网进行，否则仍然有可能遇到由于PIM协议扩散导致的路由表溢出问题。

该步骤可以在组播源所在的那台三层设备做抓包确认，或者是show ip mroute，show ip igmp groups，show msf msc

d.步骤4

在经过以上步骤排查仍然未能解决问题，则可以拨打4008111000获取支持，收集以下信息连同前面的操作信息一同反馈给工程师处理。

客户组播应用模型

设备配置

设备上的组播表项

按照以上1-3步骤排查的相关信息

按照以上1-3步骤排查相关的捉包数据