交换机
园区网交换机
数据中心与云计算交换机
行业精选交换系列
工业交换机
意图网络指挥官
无线
放装型无线接入点
墙面型无线接入点
智分无线接入点
室外无线接入点
场景化无线
无线控制器
行业精选无线系列
物联网
安全
大数据安全平台
下一代防火墙
安全网关
检测管理安全
安全服务
安全云
统一运维
身份管理
服务产品
运营商
政府
金融
互联网
电力能源
制造业
高教/职教
医疗卫生
交通
地产酒店文旅·连锁服务
公共安全
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步骤排查相关的捉包数据