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

发布时间: 2013-09-26 点击量:1432 打印 字体:

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

 

00 分享 纠错
相关条目