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

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步骤排查相关的捉包数据