6393
查看次数
50
有帮助
7
评论
本帖最后由 blakegao 于 2015-4-21 21:24 编辑
Source module and port numbers Source VLAN numbers
Cisco 基于软件的路由器使用软件来处理和路由数据包。当路由器执行更多数据包处理和路由操作时，Cisco 路由器上的 CPU 使用率势必增加。因此，show processes cpu 命令可对路由器上的数据流处理负载提供一个相当准确的指示。
Catalyst 6500/6000 交换机使用 CPU 的方式不同。这些交换机在硬件而不是软件中做出转发决策。因此，当交换机对通过交换机的大多数帧做出转发或交换决策时，进程不会占用 Supervisor 引擎 CPU。
在 Catalyst 6500/6000 交换机上，有两个 CPU。一个 CPU 是 Supervisor 引擎 CPU，称为网络管理处理器 (NMP) 或交换机处理器 (SP)。另一个 CPU 是第 3 层路由引擎 CPU，称为 MSFC 或路由处理器 (RP)。
SP CPU 执行以下功能：
· 帮助执行 MAC 地址识别和老化操作
注意： MAC 地址识别也称为路径设置。
· 运行提供网络控制的协议和进程
示例包括生成树协议 (STP)、Cisco 发现协议 (CDP)、VLAN 中继协议 (VTP)、动态中继协议 (DTP) 和端口聚合协议 (PAgP)。
· 处理发往交换机 CPU 的网络管理数据流
示例包括 Telnet、HTTP 和简单网络管理协议 (SNMP) 数据流。
RP CPU 执行以下功能：
· 构建和更新第 3 层路由和地址解析协议 (ARP) 表
· 生成 Cisco 快速转发 (CEF) 转发信息库 (FIB) 和邻接表，并将这些表下载到 Policy Feature Card (PFC)
· 处理发往 RP 的网络管理数据流
示例包括 Telnet、HTTP 和 SNMP 数据流。
触发数据流进入软件的情况和功能
发往交换机的数据包
发往交换机的任何数据包都会进入软件。此类数据包包括：
· 控制数据包
对于 STP、CDP、VTP、热备用路由器协议 (HSRP)、PAgP、链路聚合控制协议 (LACP) 和单向链路检测 (UDLD)，将收到控制数据包。
· 路由协议更新
这些协议的示例包括路由信息协议(RIP)、增强型内部网关路由协议(EIGRP)、边界网关协议 (BGP) 和开放最短路径优先（OSPF 协议）。
· 发往交换机的 SNMP 数据流
· 对交换机的Telnet和安全套接协议(SSH)流量。
高CPU ultilization由于SSH被看到如下：
00:30:50.793 SGT Tue Mar 20 2012
CPU utilization for five seconds: 83%/11%; one minute: 15%; fiveminutes: 8%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
3 6468 8568 754 69.30% 7.90% 1.68% 1 SSH Process
当CPU上升时，请包括这些in命令EEM脚本为了验证SSH会话数量建立：
· show users
· show line
· 对 ARP 请求的 ARP 响应
需要特殊处理的数据包和情况
此列表提供强制数据包在软件中进行处理的特定数据包类型和情况：
· 具有 IP 选项、过期存活时间 (TTL) 或非高级研究项目管理局 (ARPA) 封装的数据包
· 需要特殊处理（如建立隧道）的数据包
· IP 分段
· 需要来自 RP 或 SP 的 Internet 控制消息协议 (ICMP) 消息的数据包
· 最大传输单元 (MTU) 检查失败
· 具有 IP 错误（包括 IP 校验和长度错误）的数据包
· 如果输入信息包返回位错误(例如一位错误(SBE))数据包被发送对处理的软件的CPU和被更正。系统分配他们的一缓冲区并且使用CPU资源更正它。
· 当PBR和自反访问列表在通信流的路径时，数据包是交换的软件，要求另外的CPU周期。
· 邻接同一接口
· 未能通过反向路径转发 (RPF) 检查的数据包 - rpf-failure
· 收集/接收
收集是指需要 ARP 解析的数据包，接收是指归入接收情况的数据包。
· Supervisor 引擎 720 上在 Cisco IOS 软件和 CatOS 中都进行软件交换的互联网分组交换(IPX) 数据流
IPX 数据流在 Supervisor 引擎 2/Cisco IOS 软件上也进行软件交换，但该数据流在 Supervisor 引擎 2/CatOS 上进行硬件交换。IPX 数据流在 Supervisor 引擎 1A 上对于两个操作系统都进行硬件交换。
· AppleTalk 数据流
· 硬件资源已满情况
这些资源包括 FIB、内容可寻址存储器 (CAM) 和三重 CAM (TCAM)。
基于 ACL 的功能
· 已打开“ICMP 不可达”功能的被访问控制列表 (ACL) 拒绝的数据流
注意： 这是默认设置。
如果已启用“IP 不可达”功能，则 ACL 拒绝的某些数据包将被泄漏给MSFC。需要“ICMP 不可达”的数据包将以用户可配置的速率泄漏。默认情况下，速率为每秒 500 个数据包（500 pps）。
· IPX 根据不支持的参数（如源主机）进行过滤
在 Supervisor 引擎 720 上，第 3 层 IPX 数据流的处理始终在软件中进行。
· 具有 log 关键字的，需要日志记录的访问控制项(ACE)
这适用于 ACL 日志和 VLAN ACL (VACL) 日志功能。同一 ACL 中不需要日志记录的 ACE 仍在硬件中进行处理。具有 PFC3 的 Supervisor 引擎 720 支持对因 ACL 和 VACL 日志记录而重定向到 MSFC 的数据包进行速率限制。Supervisor 引擎 2 支持对因 VACL 日志记录而重定向到 MSFC 的数据包进行速率限制。Supervisor 引擎 2 上对 ACL 日志记录的支持计划在 Cisco IOS 软件版本 12.2S 分支中提供。
· 策略路由的数据流（使用 match length、set ip precedence 或其他不支持的参数）
软件中支持 set interface 参数。但是，set interface null 0 参数是一个例外。在具有 PFC2 的 Supervisor 引擎 2 和具有 PFC3 的 Supervisor 引擎 720 上，此数据流在硬件中进行处理。
· 非 IP 和非 IPX 路由器 ACL (RACL)
非 IP RACL 适用于所有 Supervisor 引擎。非 IPX RACL 仅适用于具有 PFC 的 Supervisor 引擎 1a 和具有 PFC2 的 Supervisor 引擎 2。
· 在 RACL 中被拒绝的广播数据流
· 在单播 RPF (uRPF) 检查中被拒绝的数据流，ACL ACE
此 uRPF 检查适用于具有 PFC2 的 Supervisor 引擎 2 和具有 PFC3 的 Supervisor 引擎 720。
· 身份验证代理
在 Supervisor 引擎 720 上可以对受身份验证代理控制的数据流进行速率限制。
· Cisco IOS 软件 IP 安全 (IPSec)
在 Supervisor 引擎 720 上可以对受 Cisco IOS 加密控制的数据流进行速率限制。
基于 NetFlow 的功能
本部分介绍的基于 NetFlow 的功能仅适用于 Supervisor 引擎 2 和 Supervisor 引擎 720。
· 基于 NetFlow 的功能总是需要在软件中看到数据流的第一个数据包。数据流的第一个数据包到达软件后，将对同一数据流的后续数据包进行硬件交换。
此数据流安排适用于自反 ACL、Web 缓存通信协议 (WCCP) 和 Cisco IOS 服务器负载均衡 (SLB)。
注意： 在 Supervisor 引擎 1 上，自反 ACL 依靠动态 TCAM 条目创建特定数据流的硬件快捷方式。原理是相同的：数据流的第一个数据包进入软件。该数据流的后续数据包进行硬件交换。
· 使用 TCP 拦截功能，三次握手和会话关闭将在软件中进行处理。数据流的其余部分在硬件中进行处理。
注意： 同步 (SYN)、SYN 确认 (SYN ACK) 和 ACK 数据包构成三次握手。会话关闭发生在完成 (FIN) 或重置 (RST) 时。
· 使用网络地址转换 (NAT)，数据流按如下方式进行处理：
· 在 Supervisor 引擎 720 上：
需要 NAT 的数据流在初始转换后在硬件中进行处理。流的第一个数据包的转换在软件中进行，该流的后续数据包进行硬件交换。对于 TCP 数据包，将在完成 TCP 三次握手后在 Netflow 表中创建硬件快捷方式。
· 在 Supervisor 引擎 2 和 Supervisor 引擎 1 上：
需要 NAT 的所有数据流都进行软件交换。
· 基于上下文的访问控制 (CBAC) 使用 Netflow 快捷方式将需要检查的数据流分类。然后，CBAC 仅将此数据流发送到软件。CBAC 是一个仅限软件的功能；受检查控制的数据流不进行硬件交换。
注意： 在 Supervisor 引擎 720 上可以对受检查控制的数据流进行速率限制。
多播流量
· 独立于协议的多播 (PIM) 监听
· Internet 组管理协议 (IGMP) 监听 (TTL = 1)
此数据流实际上被发往路由器。
· 多播监听程序发现 (MLD) 监听 (TTL = 1)
此数据流实际上被发往路由器。
· FIB 缺失
· 与多播源直接连接的用于注册的多播数据包
这些多播数据包通过隧道被传输到集合点。
· IP 版本 6 (IPv6) 多播
其它特性
· 基于网络的应用程序识别 (NBAR)
· ARP 检查，仅适用于 CatOS
· 端口安全，仅适用于 CatOS
· DHCP 监听
IPv6 情况
· 具有逐跳选项报头的数据包
· 与路由器具有相同目标 IPv6 地址的数据包
· 未能通过范围实施检查的数据包
· 超出输出链路的 MTU 的数据包
· TTL 小于或等于 1 的数据包
· 输入 VLAN 等于输出 VLAN 的数据包
· IPv6 uRPF
软件为所有数据包执行此 uRPF。
· IPv6 自反 ACL
软件处理这些自反 ACL。
· IPv6 站内自动隧道编址协议 (ISATAP) 隧道的 6to4 前缀
软件处理此隧道。所有其他进入ISATAP 隧道的数据流进行硬件交换。
LCP Schedular 和 DFC 模块
在 Distributed Forwarding Card (DFC) 中，在使用率较高的 CPU 上运行的 lcp schedular 进程不是问题，不会造成任何运行问题。LCPSchedular 是固件代码的一部分。在不需要 DFC 的所有模块上，固件在称为线路卡处理器 (LCP) 的一个特定处理器上运行。该处理器用于对 ASIC 硬件编程和与中央 Supervisor 模块通信。
当启动 lcp schedular 时，它将利用所有进程可用时间。但当新进程需要处理器时间时，lcp schedular 会为新进程释放进程时间。此高 CPU 使用率对系统性能没有影响。该进程只是获取所有未使用的 CPU 周期（只要没有更高优先级的进程需要它们）。
DFC#show process cpu
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
22 0 1 0 0.00% 0.00% 0.00% 0 SCP ChilisLC Lis
23 0 1 0 0.00% 0.00% 0.00% 0 IPC RTTYC Messag
24 0 9 0 0.00% 0.00% 0.00% 0 ICC Slave LC Req
25 0 1 0 0.00% 0.00% 0.00% 0 ICC Async mcast
26 0 2 0 0.00% 0.00% 0.00% 0 RPC Sync
27 0 1 0 0.00% 0.00% 0.00% 0 RPC rpc-master
28 0 1 0 0.00% 0.00% 0.00% 0 Net Input
29 0 2 0 0.00% 0.00% 0.00% 0 Protocol Filteri
30 8 105 76 0.00% 0.00% 0.00% 0 Remote Console P
31 40 1530 26 0.00% 0.00% 0.00% 0 L2 Control Task
32 72 986 73 0.00% 0.02% 0.00% 0 L2 Aging Task
33 4 21 190 0.00% 0.00% 0.00% 0 L3 Control Task
34 12 652 18 0.00% 0.00% 0.00% 0 FIB Control Task
35 9148 165 55442 1.22% 1.22% 1.15% 0 Statistics Task
36 4 413 9 0.00% 0.00% 0.00% 0 PFIB Table Manag
37 655016 64690036 10 75.33% 77.87% 71.10% 0 lcp schedular
38 0 762 0 0.00% 0.00% 0.00% 0 Constellation SP
高 CPU 使用率问题的常见原因和解决方案
IP 不可达
当访问组拒绝数据包时，MSFC 会发送 ICMP 不可达消息。此操作在默认情况下发生。
使用默认启用的 ip unreachables 命令，Supervisor 引擎将在硬件中丢弃大多数被拒绝的数据包。然后，Supervisor 引擎仅将数量很少的数据包（最多 10 pps）发送到 MSFC 进行丢弃。此操作会生成 ICMP 不可达消息。
丢弃被拒绝的数据包和生成 ICMP 不可达消息会造成 MSFC CPU 负载增加。为了降低负载，可以发出 no ip unreachables 接口配置命令。此命令将禁用ICMP 不可达消息，这允许在硬件中丢弃所有被访问组拒绝的数据包。
如果 VACL 拒绝数据包，将不发送 ICMP 不可达消息。
NAT 转换
NAT 同时使用硬件和软件转发。NAT 转换的最初建立必须在软件中完成，进一步的转发在硬件中完成。NAT 还使用 Netflow 表（最大 128 KB）。因此，如果 Netflow 表已满，交换机也将开始通过软件应用 NAT 转发。这通常发生在流量突然升高时，并将导致 6500 CPU 使用率的增加。
流缓存表中 CEF FIB 表空间的使用
Supervisor 引擎 1 有一个支持 128,000 个条目的流缓存表。但是，根据散列算法的效率，这些条目的数量范围在 32,000 到 120,000 个之间。在 Supervisor 引擎 2 上，会生成 FIB 表并将其编程到 PFC 中。该表可容纳多达 256,000 个条目。具有 PFC3-BXL 的 Supervisor 引擎 720 支持多达 1,000,000 个条目。一旦超出此空间，便变为在软件中交换数据包。这可能在 RP 上导致高 CPU 使用率。为了检查 CEF FIB 表中的路由数，请使用以下命令：
Router#show processes cpu
CPU utilization for five seconds: 99.26%
oneminute: 100.00%
fiveminutes: 100.00%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
--- ----------- ---------- -------- ------- ------- ------- ------------------
1 0 0 0 0.74% 0.00% 0.00% -2 Kernel and Idle
2 2 245 1000 0.00% 0.00% 0.00% -2 Flash MIB Updat
3 0 1 0 0.00% 0.00% 0.00% -2 L2L3IntHdlr
4 0 1 0 0.00% 0.00% 0.00% -2 L2L3PatchRev
5 653 11737 1000 0.00% 0.00% 0.00% -2 SynDi
!--- Output is suppressed.
26 10576 615970 1000 0.00% 0.00% 0.00% 0 L3Aging
27 47432 51696 8000 0.02% 0.00% 0.00% 0 NetFlow
28 6758259 1060831 501000 96.62% 96.00% 96.00% 0 Fib
29 0 1 0 0.00% 0.00% 0.00% -2 Fib_bg_task
!--- Output is suppressed.
CATOS% show mls cef
Total L3 packets switched: 124893998234
Total L3 octets switched: 53019378962495
Total route entries: 112579
IP route entries: 112578
IPX route entries: 1
IPM route entries: 0
IP load sharing entries: 295
IPX load sharing entries: 0
Forwarding entries: 112521
Bridge entries: 56
Drop entries: 2
IOS% show ip cef summary
IP Distributed CEF with switching (Table Version 86771423),flags=0x0
112564 routes, 1reresolve, 0 unresolved (0 old, 0 new)
112567 leaves, 6888 nodes, 21156688 bytes,86771426
inserts, 86658859
invalidations
295 load sharing elements,96760 bytes, 112359 references
universal per-destinationload sharing algorithm, id 8ADDA64A
2 CEF resets, 2306608revisions of existing leaves
refcounts: 1981829 leaf, 1763584 node
!--- You see these messages if the TCAM space is exceeded:
%MLSCEF-SP-7-FIB_EXCEPTION: FIB TCAM exception, Some entries willbe software switched
%MLSCEF-SP-7-END_FIB_EXCEPTION: FIB TCAM exception cleared, allCEF entries will be
hardware switched
在 Supervisor 引擎 2 上，如果已在接口上配置 RPF 检查，则 FIB 条目的数量将减少到一半。此配置可能导致对更多数据包进行软件交换，并因此导致高 CPU 使用率。
为了解决高CPU利用率问题， enable (event)路由总结。路由总结能通过减少处理器工作量、内存要求和带宽需求最小化在复杂网络的延迟。
优化的 ACL 日志记录
优化的 ACL 日志记录 (OAL) 为 ACL 日志记录提供硬件支持。除非配置 OAL，否则对需要日志记录的数据包的处理将完全在 MSFC3 上的软件中进行。OAL 在 PFC3 上的硬件中允许或丢弃数据包。OAL 使用一个优化的例程向 MSFC3 发送信息以生成日志记录消息。
注意： 有关 OAL 的信息，请参阅了解 Cisco IOS ACL 支持的使用 PFC3 的优化的 ACL 日志记录 部分。
到 CPU 的数据包的速率限制
在 Supervisor 引擎 720 上，速率限制器可以控制数据包进入软件的速率。此速率控制可帮助防止拒绝服务攻击。还可以在 Supervisor 引擎 2 上使用这些速率限制器中的一部分：
Router#show mls rate-limit
Rate Limiter Type Status Packets/s Burst
--------------------- ---------- --------- -----
MCAST NON RPF Off - -
MCAST DFLT ADJ On 100000 100
MCAST DIRECT CON Off - -
ACL BRIDGED IN Off - -
ACL BRIDGED OUT Off - -
IP FEATURES Off - -
ACL VACL LOG On 2000 1
CEF RECEIVE Off - -
CEF GLEAN Off - -
MCAST PARTIAL SC On 100000 100
IP RPF FAILURE On 500 10
TTL FAILURE Off - -
ICMP UNREAC. NO-ROUTE On 500 10
ICMP UNREAC. ACL-DROP On 500 10
ICMP REDIRECT Off - -
MTU FAILURE Off - -
LAYER_2 PDU Off - -
LAYER_2 PT Off - -
IP ERRORS On 500 10
CAPTURE PKT Off - -
MCAST IGMP Off - -
Router(config)#mls rate-limit ?
all Rate Limiting for both Unicast andMulticast packets
layer2 layer2 protocol cases
multicast Rate limiting for Multicast packets
unicast Rate limiting for Unicast packets
示例如下：
Router(config)#mls rate-limit layer2 l2pt 3000
为了限制所有 CEF 转出的数据包发往 MSFC 的速率，请发出本示例中的命令：
Router(config)#mls ip cef rate-limit 50000
为了减少由于 TTL=1 而被转出到 CPU 的数据包数量，请发出以下命令：
Router(config)#mls rate-limit all ttl-failure 15
!--- where 15 is the number of packets per second with TTL=1.
!--- The valid range is from 10 to 1000000 pps.
例如，这是netdr捕获的输出，显示该IPv4 TTL是1 ：
Source mac 00.00.50.02.10.01 3644
Dest mac AC.A0.16.0A.B0.C0 4092
Protocol 0800 4094
Interface Gi1/8 3644
Source vlan 0x3FD(1021) 3644
Source index 0x7(7) 3644
Dest index 0x380(896) 3654
L3
ipv4 source 211.204.66.117 762
ipv4 dest 223.175.252.49 3815
ipv4 ttl 1 3656
ipv6 source - 0
ipv6 dest - 0
ipv6 hoplt - 0
ipv6 flow - 0
ipv6 nexthdr - 0
高 CPU 使用率也可能是由于泄漏给 CPU 的 TTL=1 的数据包引起的。为了限制泄漏给 CPU 的数据包的数量，请配置一个硬件速率限制器。速率限制器可以限制从硬件数据路径直到软件数据路径泄漏的数据包的速率。速率限制器可通过丢弃超过配置速率的数据流，来防止软件控制路径发生拥塞。速率限制是使用 mls rate-limit all ttl-failure 命令配置的。
由于不正确布线导致的VLAN 物理合并
高 CPU 使用率也可能是由于因不正确布线而将两个或更多 VLAN 合并到一起引起的。此外，如果在发生 VLAN 合并的这些端口上已禁用 STP，则也可能出现高 CPU 使用率。
为了解决此问题，请识别布线错误并进行更正。如果您的要求允许，也可以在这些端口上启用 STP。
广播风暴
当广播或多播数据包泛洪 LAN 时，会出现 LAN 广播风暴，这会创建过多的数据流并且降低网络性能。协议堆栈实施或网络配置中的错误可能导致广播风暴。
由于 Catalyst 6500 系列平台的体系结构设计，广播数据包始终仅在软件级别被丢弃。
广播抑制可防止广播风暴破坏 LAN 接口。广播抑制使用测量 1 秒时段内 LAN 上的广播活动并将测量结果与预定义的阈值进行比较的过滤方法。如果达到阈值，则将在指定时段内抑制进一步的广播活动。广播抑制在默认情况下处于禁用状态。
注意： 从掌握的备份的VRRP飘荡由广播风暴导致也许导致高CPU利用率。
为了了解广播抑制的工作原理以及如何启用该功能，请参阅：
· 配置广播抑制（Cisco IOS 系统软件）
· 配置广播抑制（CatOS 系统软件）
BGP 下一跳地址跟踪（BGP 扫描程序进程）
BGP 扫描程序进程扫描 BGP 表并确认下一跳的可达性。此进程也检查条件通告以确定 BGP 是否应该通告条件前缀并/或执行路由衰减。默认情况下，该进程每 60 秒扫描一次。
在具有大型 Internet 路由表的路由器上执行 BGP 扫描程序进程时，您可以预料到会因此出现持续时间较短的高 CPU 使用率。每分钟一次，BGP 扫描程序扫描 BGP 路由信息库 (RIB) 表并执行重要维护任务。这些任务包括：
· 检查路由器 BGP 表中引用的下一跳
· 验证下一跳设备是否可以到达
因此，扫描和验证大型 BGP 表需要花费相当长的时间。BGP 扫描程序进程扫描 BGP 表以更新所有数据结构，并扫描路由表以进行路由重分配。两个表分别存储在路由器内存中。两个表都可能非常大，并因此可能会耗尽 CPU 周期。
有关 BGP 扫描程序进程的 CPU 使用率的详细信息，请参阅解决由 BGP 扫描器和 BGP 路由器进程引起的高 CPU 使用率问题的由于 BGP 扫描程序而导致 CPU 使用率较高部分。
有关 BGP 下一跳地址跟踪功能和启用/禁用或调整扫描间隔的过程的详细信息，请参阅对下一跳地址跟踪的 BGP 支持。
非 RPF 多播数据流
多播路由（不同于单播路由）只关心给定多播数据流的源。即发起多播数据流的设备的 IP 地址。基本原理是源设备将数据流“推”出到数量不确定的接收方（在其多播组内）。所有多播路由器都会创建分布树，这些分布树控制多播数据流通过网络将数据流发送到所有接收方所采用的路径。多播分布树的两种基本类型是源树和共享树。RPF 是多播转发中的一个重要概念。它使路由器可以沿分布树正确转发多播数据流。RPF 利用现有的单播路由表确定上游与下游邻居。只有当上游接口收到多播数据包时，路由器才会转发该数据包。此 RPF 检查可帮助保证分布树无环路。
根据IEEE 802.3 CSMA/CD 规范，多播数据流在桥接的（第 2 层）LAN上对于每个路由器始终可见。在 802.3 标准中，第一个八位组的位 0 用于指示广播和/或多播帧，具有此地址的所有第 2 层帧将被泛洪。即使配置了 CGMP 或 IGMP 监听，也是这种情况。这是因为，如果希望多播路由器做出正确的转发决策，多播路由器必须看到多播数据流。如果多个多播路由器中的每一个都在公共 LAN 上有接口，则只有一个路由器转发数据（通过选举过程选择）。由于 LAN 的泛洪性质，冗余路由器（不转发多播数据流的路由器）在该 LAN 的出站接口上收到此数据。冗余路由器通常会丢弃此数据流，因为该数据流已到达错误的接口，因此无法通过 RPF 检查。无法通过 RPF 检查的此数据流称为非 RPF 数据流或 RPF 故障数据包，因为它们已按照来自源的流向被反向传输回去。
可以将安装了 MSFC 的 Catalyst 6500 配置为充当功能完备的多播路由器。使用多播多层交换 (MMLS)，RPF 数据流通常在交换机内由硬件进行转发。ASIC 被提供了来自多播路由状态的信息（例如，(*,G) 和 (S,G)），因此可以将硬件快捷方式编程到 Netflow 和/或 FIB 表中。这种非 RPF 数据流在某些情况下仍然是必需的，MSFC CPU（在进程级别）需要它才能使用 PIM 主张机制。否则，它将被软件快速交换路径丢弃（假定未在 RPF 接口上禁用软件快速交换）。
使用冗余的 Catalyst 6500 在某些拓扑中可能无法有效处理非 RPF 数据流。对于非 RPF 数据流，冗余路由器中通常没有 (*,G) 或 (S,G) 状态，因此不能创建任何硬件或软件快捷方式来丢弃数据包。MSFC 路由处理器必须分别检查每个多播数据包，这通常被称为 CPU 中断数据流。使用第 3 层硬件交换和连接同一组路由器的多个接口/VLAN，到达冗余 MSFC 的 CPU 的非 RPF 数据流被放大为原始源速率的“N”倍（其中“N”是路由器以冗余方式连接到的 LAN 的数量）。如果非 RPF 数据流的速率超过系统的数据包丢弃能力，则可能导致高 CPU 使用率、缓冲区溢出和整体网络不稳定。
对于 Catalyst 6500，有一个使过滤能够以线速进行的访问列表引擎。在某些情况下，此功能可用于有效地处理稀疏模式组的非 RPF 数据流。只能在没有下游多播路由器（及对应的接收方）的稀疏模式“残域网络”中，才能使用基于 ACL 的方法。此外，由于 Catalyst 6500 的数据包转发设计，内部冗余的 MSFC 不能使用此实施。这将在 Cisco Bug ID CSCdr74908（仅限注册用户）中进行概述。对于密集模式组，必须在路由器上看到非 RPF 数据包，PIM 主张机制才能正常运行。不同的解决方案（如 CEF 或基于 Netflow 的速率限制和 QoS）用于控制密集模式网络和稀疏模式中转网络中的 RPF 故障。
在 Catalyst 6500 上，有一个使过滤能够以线速进行的访问列表引擎。此功能可用于有效地处理稀疏模式组的非 RPF 数据流。为了实施此解决方案，请在“残域网络”的传入接口上放置一个访问列表，以过滤不是源自“残域网络”的多播数据流。此访问列表被推入交换机的硬件中。此访问列表可防止 CPU 看到数据包，并允许硬件丢弃非 RPF 数据流。
注意： 请勿在中转接口上放置此访问列表。它只供残域网络（只包含主机的网络）使用。
有关详细信息，请参阅以下文档：
· 残域网络中 IP 多播的冗余路由器问题
· 非 RPF 数据流处理
显示命令
发出 show 命令时，CPU 使用率总是几乎 100%。发出 show 命令时出现高 CPU 使用率是正常的，高 CPU 使用率通常仅保持几秒钟。
例如，发出 show tech-support 命令时，虚拟 Exec 进程导致 CPU 使用率升高是正常的，因为此输出是一个中断驱动的输出。您只需关心执行 show 命令以外的其他进程时出现的高 CPU 使用率。
show cef not-cef-switched命令显示数据包为什么被踢对MSFC (接收、IP选项、没有邻接等等)，并且多少。例如：
Switch#show cef not-cef-switched
CEF Packets passed on to next switching layer
Slot No_adj No_encapUnsupp'ted Redirect Receive Options Access Frag
RP 6222 0 136 0 60122 0 0 0
5 0 0 0 0 0 0 0 0
IPv6 CEF Packets passed on to next switching layer
Slot No_adj No_encapUnsupp'ted Redirect Receive Options Access MTU
RP 0 0 0 0 0 0 0 0
当您监控CPU状态时，显示ibc和显示ibc简化show命令CPU队列，并且可以使用。
Exec 进程
Cisco IOS 软件中的 Exec 进程负责路由器 TTY 线路（控制台、辅助、异步）上的通信。虚拟 Exec 进程负责 vty 线路（Telnet 会话）。Exec 和虚拟 Exec 进程是中优先级进程，因此如果有具有更高优先级（“高”或“重要”）的其他进程，则更高优先级进程将获得 CPU 资源。
如果通过这些会话传输的数据很多，则 Exec 进程的 CPU 使用率将增加。这是因为当路由器需要通过这些线路发送一个简单字符时，它会使用一些 CPU 资源：
· 对于控制台 (Exec)，路由器为每个字符使用一个中断。
· 对于 VTY 线路（虚拟 Exec），Telnet 会话必须为每个字符建立一个 TCP 数据包。
此列表详细说明了执行 Exec 进程时 CPU 使用率较高的某些可能原因：
· 通过控制台端口发送的数据过多。
1. 请查看是否已使用 show debugging 命令在路由器上启动了任何调试。
2. 使用 no 形式的 logging console 命令在路由器上禁用控制台日志记录。
3. 验证是否在控制台上显示了较长的输出。例如，show tech-support 或 show memory 命令。
· Exec 命令是为异步和辅助线路配置的。
1. 如果线路只有传出数据流，则对此线路禁用 Exec 进程。这是因为，如果连接到此线路的设备（例如，调制解调器）发送一些主动提供的数据，Exec 进程将在此线路上启动。
2. 如果路由器用作终端服务器（以便可以执行到其他设备控制台的反向 Telnet），建议在连接到其他设备的控制台的线路上配置 no exec 命令。否则，从控制台返回的数据可能会启动一个 Exec 进程，该进程将使用 CPU 资源。
执行虚拟 Exec 进程时 CPU 使用率较高的一个可能原因是：
· 通过 Telnet 会话发送的数据过多。
执行虚拟 Exec 进程时 CPU 使用率较高的最常见原因是从路由器传输到 Telnet 会话的数据过多。从 Telnet 会话执行具有较长输出的命令（如 show tech-support、show memory 等）时，可能出现这种情况。可以使用 showtcp VTY
L3 老化进程
当 L3 老化进程使用 NetFlow 数据导出 (NDE) 导出大量 IfIndex 值时，CPU 使用率可能会达到 100%。
如果遇到此问题，请检查是否启用了以下两个命令：
set mls nde destination-ifindex enable
set mls nde source-ifindex enable
如果启用这些命令，该进程必须使用 NDE 导出所有目标和源 IfIndex 值。L3 老化进程会导致 CPU 使用率升高，因为它必须对所有目标和源 IfIndex 值执行 FIB 查找。因此，表将变满，L3 老化进程导致 CPU 使用率升高，CPU 使用率达到 100%。
为了解决此问题，请禁用这些命令：
set mls nde destination-ifindex disable
set mls nde source-ifindex disable
请使用这些命令验证值：
· showmls cef summary
· showmls cef maximum-routes
BPDU 风暴
生成树在冗余交换网络和网桥网络中维护一个无环路的第2 层环境。没有 STP，帧会无限循环并/或倍增。这将导致网络崩溃，因为高流量将中断广播域中的所有设备。
在某些方面，STP 最初是为基于软件的缓慢网桥规范 (IEEE 802.1D) 开发的早期协议，但是要在具有以下功能的大型交换网络中成功实施该协议，STP 可能非常复杂：
· 多个 VLAN
· STP 域中的许多交换机
· 多供应商支持
· 较新的 IEEE 增强功能
如果网络面临频繁的生成树计算或交换机必须处理更多 BPDU，则可能导致 CPU 使用率较高以及 BPDU 被丢弃。
为了解决这些问题，请执行下列步骤中的部分或全部：
1. 从交换机中删除部分 VLAN。
2. 使用 STP 的增强版，如 MST。
3. 升级交换机的硬件。
另请参阅在网络中实施生成树协议 (STP) 的最佳实践。
· 运行CatOS 配置和管理的 Catalyst 4500/4000、5500/5000和 6500/6000 系列交换机的最佳实践
· 运行 Cisco IOS 软件的 Catalyst 6500/6000 系列和 Catalyst 4500/4000 系列交换机的最佳实践
SPAN 会话
基于 Catalyst 6000/6500 系列交换机的体系结构，SPAN 会话不会影响交换机的性能，但是，如果 SPAN 会话中包括高流量/上行链路端口或 EtherChannel，则它可能增加处理器上的负载。如果它随后要选出一个特定 VLAN，这还会增加更多工作量。如果链路上存在不良数据流，这可能进一步增加工作量。
在某些情况下，RSPAN 功能可能导致环路，并可能导致处理器上的负载激增。有关详细信息，请参阅为何 SPAN 会话会产生桥接环路？
交换机可以像平常一样传递数据流，因为所有操作都在硬件中进行，但是如果它试图确定要发送哪个数据流，CPU 可能难以承受。建议只在必需时配置 SPAN 会话。
%CFIB-SP-STBY-7-CFIB_EXCEPTION ：FIB TCAM exception, Someentries will be software switched
%CFIB-SP-7-CFIB_EXCEPTION : FIB TCAM exception, Some entries willbe software switched
%CFIB-SP-STBY-7-CFIB_EXCEPTION : FIB TCAM exception, Some entrieswill be software
switched
当 TCAM 中的可用空间量被超出时，将收到此错误信息。这将导致 CPU 使用率较高。这是一个 FIB TCAM 限制。一旦 TCAM 已满，便将设置一个标志，并将收到 FIB TCAM 异常错误。这将停止向 TCAM 添加新的路由。因此，所有数据流都将进行软件交换。删除路由对恢复硬件交换没有帮助。一旦 TCAM 进入异常错误状态，必须重新加载系统才能脱离该状态。通过 mls cef maximum-routes 命令可以增加 TCAM 中可以安装的最大路由数。
运行以高CPU的Catalyst 6500/6000有IPv6 ACL用L4端口
Enable (event) MLS IPv6 ACL压缩地址单播。如果IPv6 ACL在L4协议端口端口号，匹配此命令是需要的。如果此命令没有启用， IPv6流量将被踢对软件处理的CPU。默认情况下此命令没有配置。
铜缆 SPF
在 Cisco ME 6500 系列以太网交换机中，铜缆 SFP 比其他类型的 SFP 需要更多固件交互，这会使 CPU 使用率升高。
管理铜缆 SFP 的软件算法已在 Cisco IOS SXH 版本中改进。
模块化 IOS
在运行模块化 IOS 软件的 Cisco Catalyst 6500 系列交换机中，正常 CPU 使用率稍大于非模块化 IOS 软件。
模块化 IOS 软件为每个活动付出的代价多于它为每个数据包付出的代价。模块化 IOS 软件通过消耗特定的 CPU 来维护进程，即使没有多少数据包也是如此，因此 CPU 消耗并不基于实际数据流。但是，当处理的数据包比率升高时，在模块化 IOS 软件中消耗的 CPU 不应多于在非模块化 IOS 软件中消耗的 CPU。
检查 CPU 使用率
如果 CPU 使用率较高，请先发出 show processes cpu 命令。输出显示交换机上的 CPU 使用率以及每个进程的 CPU 使用率。
Router#show processes cpu
CPU utilization for five seconds: 57%/48%; one minute: 56%;five minutes: 48%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
1 0 5 0 0.00% 0.00% 0.00% 0 Chunk Manager
2 12 18062 0 0.00% 0.00% 0.00% 0 Load Meter
4 164532 13717 11994 0.00% 0.21% 0.17% 0 Check heaps
5 0 1 0 0.00% 0.00% 0.00% 0 Pool Manager
!--- Output is suppressed.
172 0 9 0 0.00% 0.00% 0.00% 0 RPC aapi_rp
173 243912 2171455 112 9.25% 8.11% 7.39% 0 SNMP ENGINE
174 68 463 146 0.00% 0.00% 0.00% 0 RPC pm-mp
!--- Output is suppressed.
在此输出中，总 CPU 使用率是 57%，中断 CPU 使用率是 48%。此处，这些百分比以粗体文本显示。由 CPU 进行的数据流中断交换将导致中断 CPU 使用率。命令输出列出了导致两种使用率之间的差异的进程。在本例中，原因是 SNMP 进程。
在运行 CatOS 的 Supervisor 引擎上，输出如下所示：
Switch> (enable) show processes cpu
CPU utilization for five seconds: 99.72%
one minute: 100.00%
fiveminutes: 100.00%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
--- ----------- ---------- -------- ------- ------- ------- ------------------
1 0 0 0 0.28% 0.00% 0.00% -2 Kernel and Idle
2 2 261 1000 0.00% 0.00% 0.00% -2 Flash MIB Updat
3 0 1 0 0.00% 0.00% 0.00% -2 L2L3IntHdlr
4 0 1 0 0.00% 0.00% 0.00% -2 L2L3PatchRev
!--- Output is suppressed.
61 727295 172025 18000 0.82% 0.00% 0.00% -2 SptTimer
62 18185410 3712736 106000 22.22% 21.84% 21.96% -2 SptBpduRx
63 845683 91691 105000 0.92% 0.00% 0.00% -2 SptBpduTx
在此输出中，第一个进程是 Kernel and Idle，它显示空闲 CPU 使用率。通常，此进程显示的空闲 CPU 使用率较高，除非一些其他进程占用 CPU 周期。在本示例中，SptBpduRx 进程导致高 CPU 使用率。
如果 CPU 使用率较高是由于这些进程之一导致的，您可以排除故障并确定此进程导致高 CPU 使用率的原因。但是，如果 CPU 较高是由于被转出到 CPU 的数据流导致的，则您需要确定数据流被转出的原因。确定数据流被转出的原因可帮助您识别该数据流是什么。
对于排除故障，当您体验高CPU利用率时，请使用此EEM脚本示例为了从交换机收集输出：
event manager applet cpu_stats
event snmp oid "1.3.6.1.4.1.9.9.109.1.1.1.1.3.1"get-type exact entry-op gt entry-val "70"
exit-op lt exit-val "50" poll-interval 5
action 1.01 syslog msg "------HIGH CPU DETECTED----,CPU:$_snmp_oid_val%"
action 1.02 cli command "enable"
action 1.03 cli command "show clock | appenddisk0:cpu_stats"
action 1.04 cli command "show proc cpu sort | appenddisk0:cpu_stats"
action 1.05 cli command "Show proc cpu | exc 0.00% | appenddisk0:cpu_stats"
action 1.06 cli command "Show proc cpu history | appenddisk0:cpu_stats"
action 1.07 cli command "show logging | appenddisk0:cpu_stats "
action 1.08 cli command "show spanning-tree detail | inieee|occurr|from|is exec | append
disk0:cpu_stats"
action 1.09 cli command "debug netdr cap rx | appenddisk0:cpu_stats"
action 1.10 cli command "show netdr cap | appenddisk0:cpu_stats"
action 1.11 cli command "undebug all"
!
注意： 当CPU是由于的高处理数据包交换而不是硬件时，调试netdr捕获rx命令是有用。当命令运行时，它获取4096数据包流入对CPU。命令是十分安全的并且是高CPU问题的最方便的工具在6500。它不引起额外的负载CPU。
用于确定被传送到CPU 的数据流的实用程序和工具
本部分确定了可帮助您查看此数据流的一些实用程序和工具。
Cisco IOS 系统软件
在 Cisco IOS 软件中，Supervisor 引擎上的交换处理器称为 SP，MSFC 称为 RP。
show interface 命令提供有关接口状态和接口上数据流速率的基本信息。此命令也提供错误计数器。
Router#show interface gigabitethernet 4/1
GigabitEthernet4/1 is up, line protocol is up (connected)
Hardware is C6k 1000Mb802.3, address is 000a.42d1.7580 (bia 000a.42d1.7580)
Internet address is100.100.100.2/24
MTU 1500 bytes, BW 1000000Kbit, DLY 10 usec,
reliability 255/255,txload 1/255, rxload 1/255
Encapsulation ARPA,loopback not set
Keepalive set (10 sec)
Half-duplex, 100Mb/s
input flow-control is off,output flow-control is off
Clock mode is auto
ARP type: ARPA, ARPTimeout 04:00:00
Last input 00:00:00,output 00:00:00, output hang never
Last clearing of"show interface" counters never
Input queue: 5/75/1/24075(size/max/drops/flushes); Total output drops: 2
Queueing strategy: fifo
Output queue: 0/40(size/max)
30 second input rate7609000 bits/sec, 14859 packets/sec
30 second output rate 0bits/sec, 0 packets/sec
L2 Switched: ucast: 0pkt, 184954624 bytes - mcast: 1 pkt, 500 bytes
L3 in Switched: ucast:2889916 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
L3 out Switched: ucast: 0pkt, 0 bytes mcast: 0 pkt, 0 bytes
2982871 packets input,190904816 bytes, 0 no buffer
Received 9 broadcasts,0 runts, 0 giants, 0 throttles
1 input errors, 1 CRC,0 frame, 28 overrun, 0 ignored
0 input packets withdribble condition detected
1256 packets output,124317 bytes, 0 underruns
2 output errors, 1collisions, 2 interface resets
0 babbles, 0 latecollision, 0 deferred
0 lost carrier, 0 nocarrier
0 output bufferfailures, 0 output buffers swapped out
在此输出中，可以看到传入数据流是在第 3 层交换的（而不是在第 2 层交换的）。这表明数据流被转出到 CPU。
show processes cpu 命令告诉您这些数据包是常规数据流数据包还是控制数据包。
Router#show processes cpu | exclude 0.00
CPU utilization for five seconds: 91%/50%; one minute: 89%; fiveminutes: 47%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
5 881160 79142 11133 0.49% 0.19% 0.16% 0 Check heaps
98 121064 3020704 40 40.53%38.67% 20.59% 0 IP Input
245 209336 894828 233 0.08% 0.05% 0.02% 0 IFCOM Msg Hdlr
如果数据包是进程交换的，您会看到 IP Input process 的 CPU 使用率升高。发出此命令可以看到以下数据包：
show buffers input-interface
Router#show buffers input-interface gigabitethernet 4/1 packet
Buffer information for Small buffer at 0x437874D4
data_area 0x8060F04,refcount 1, next 0x5006D400, flags 0x280
linktype 7 (IP), enctype 1(ARPA), encsize 14, rxtype 1
if_input 0x505BC20C(GigabitEthernet4/1), if_output 0x0 (None)
inputtime 00:00:00.000 (elapsednever)
outputtime 00:00:00.000(elapsed never), oqnumber 65535
datagramstart 0x8060F7A,datagramsize 60, maximum size 308
mac_start 0x8060F7A,addr_start 0x8060F7A, info_start 0x0
network_start 0x8060F88,transport_start 0x8060F9C, caller_pc 0x403519B4
source: 100.100.100.1,destination: 100.100.100.2, id: 0x0000, ttl: 63,
TOS: 0 prot: 17, sourceport 63, destination port 63
08060F70: 000A 42D17580 ..BQu.
08060F80: 00000000 11110800 4500002E 00000000 ........E.......
08060F90: 3F11EAF3 64646401 64646402 003F003F ?.jsddd.ddd..?.?
08060FA0: 001A261F 00010203 04050607 08090A0B ..&.............
08060FB0: 0C0D0E0F 101164 ......d
如果数据流是中断交换的，则使用 show buffers input-interface 命令无法看到这些数据包。为了看到由于中断交换被转出到 RP 的数据包，可以执行 RP 端口的交换端口分析程序 (SPAN) 捕获。
注意： 有关中断交换与进程交换 CPU 使用率的详细信息，请参阅以下文档：
· 对 Cisco 路由器上的 CPU 使用率过高进行故障排除的由于中断而导致 CPU 使用率较高 部分
SPAN RP-Inband 和 SP-Inband
Cisco IOS 软件中用于 RP 或 SP 端口的 SPAN 在 Cisco IOS 软件版本 12.1(19)E 及更高版本中可用。
以下是命令语法：
test monitor session 1-66 add {rp-inband | sp-inband} [rx | tx | both]
对于 Cisco IOS 软件 12.2 SX 版本，使用以下语法：
test monitor add {1..66} {rp-inband | sp-inband} {rx | tx | both}
注意： 对于 SXH 版本，必须使用 monitor session 命令配置本地 SPAN 会话，然后使用此命令将 SPAN 会话与 CPU 关联：
source {cpu {rp | sp}} | single_interface | interface_list |
interface_range | mixed_interface_list | single_vlan |
vlan_list | vlan_range | mixed_vlan_list} [rx | tx | both]
注意： 有关这些命令的详细信息，请参阅 Catalyst 6500 版本 12.2SX 软件配置指南 中的配置本地 SPAN（SPAN 配置模式）。
以下是 RP 控制台上的一个示例：
Router#monitor session 1 source interface fast 3/3
!--- Use any interface that is administratively shut down.
Router#monitor session 1 destination interface 3/2
现在，转到 SP 控制台。示例如下：
Router-sp#test monitor session 1 add rp-inband rx
注意： 在 Cisco IOS 12.2 SX 版本中，此命令已更改为 test monitor add 1 rp-inband rx。
Router#show monitor
Session 1
---------
Type : Local Session
Source Ports :
Both : Fa3/3
Destination Ports : Fa3/2
SP console:
Router-sp#test monitor session 1 show
Ingress Source Ports: 3/3 15/1
Egress Source Ports: 3/3
Ingress Source Vlans:
Egress Source Vlans:
Filter Vlans:
Destination Ports: 3/2
注意： 在 Cisco IOS 12.2 SX 版本中，此命令已更改为 test monitor show 1。
以下是 SP 控制台上的一个示例：
Router-sp#test monitor session 1 show
Ingress Source Ports: 3/3 15/1
Egress Source Ports: 3/3
Ingress Source Vlans:
Egress Source Vlans:
Filter Vlans:
Destination Ports: 3/2
CatOS 系统软件
对于运行 CatOS 系统软件的交换机，Supervisor 引擎运行 CatOS，MSFC 运行 Cisco IOS 软件。
如果发出 show mac 命令，可以看到被转出到 MSFC 的帧的数量。端口 15/1 是与 MSFC 的 Supervisor 引擎连接。
注意： 端口 16/1 用于插槽 2 中的 Supervisor 引擎。
Console> (enable) show mac 15/1
Port Rcv-Unicast Rcv-Multicast Rcv-Broadcast
-------- -------------------- ----------------------------------------
15/1 193576 0 1
Port Xmit-Unicast Xmit-Multicast Xmit-Broadcast
-------- -------------------- ----------------------------------------
15/1 3 0 0
Port Rcv-Octet Xmit-Octet
-------- -------------------- --------------------
15/1 18583370 0
MAC Dely-ExcedMTU-Exced In-Discard Out-Discard
-------- ---------- ---------- ---------- -----------
15/1 0 - 0 0
此数字快速增加表明数据包被转出到 MSFC，导致高 CPU 使用率。然后您可以通过以下方式查看数据包：
· SPAN MSFC 端口 15/1 或 16/1
· SPAN sc0
SPAN MSFC 端口 15/1 或 16/1
设置一个 SPAN 会话，其中源是 MSFC 端口 15/1（或 16/1），目标是以太网端口。
示例如下：
Console> (enable) set span 15/1 5/10
Console> (enable) show span
Destination : Port 5/10
Admin Source : Port 15/1
Oper Source : None
Direction :transmit/receive
Incoming Packets: disabled
Learning : enabled
Multicast : enabled
Filter : -
Status : active
如果收集端口 5/10 上的嗅探器踪迹，嗅探器踪迹显示从 MSFC 传输的数据包和传输到 MSFC 的数据包。 将 SPAN 会话配置为tx 以只捕获发往 MSFC 的数据包而不捕获来自 MSFC 的数据包。
SPAN sc0
设置一个以 sc0 接口作为源的 SPAN 会话，以捕获进入 Supervisor 引擎 CPU 的帧。
Console> (enable) set span ?
disable Disable port monitoring
sc0 Set span on interfacesc0
注意： 对于光服务模块 (OSM)，不能执行数据流 SPAN 捕获。
建议
Supervisor 引擎 CPU 使用率不反映交换机的硬件转发性能。但是，仍必须以 Supervisor 引擎 CPU 使用率作为基线并对其进行监控。
1. 以稳定状态网络中具有正常数据流模式和负载的交换机的 Supervisor 引擎 CPU 使用率作为基线。
请注意哪些进程导致最高的 CPU 使用率。
2. 在排除 CPU 使用率故障时，请考虑以下问题：
1. 哪些进程导致最高使用率？这些进程是否与您的基线不同？
2. CPU 使用率是否一直高于基线？或者是否存在出现高使用率峰值，然后返回基线水平的情况？
3. 网络中是否存在拓扑更改通知 (TCN)？
注意： 已禁用 STP Portfast 的抖动端口或主机端口将导致TCN。
4. 管理子网/VLAN 中是否存在过多的广播或多播数据流？
5. 交换机上是否存在过多的管理数据流，如 SNMP 轮询？
3. 在高CPU时间期间(当CPU是75%以上)时，从这些命令请收集输出：
0. showclock
1. showversion
2. 排序的show processes cpu
3. showproc cpu历史记录
4. showlog
4. 如果可能，请从具有用户数据流（特别是大量广播数据流）的 VLAN 中分离出管理 VLAN。
这种数据流类型的示例包括 IPX RIP/服务通告协议 (SAP)、AppleTalk 和其他广播数据流。此类数据流可能影响Supervisor 引擎 CPU 使用率，并且在特殊情况下可能干扰交换机的正常运行。
5. 如果由于数据流被转出到 RP 而导致 CPU 使用率很高，请确定该数据流是什么以及该数据流为什么被转出。
为了进行此确定，请使用用于确定被传送到 CPU 的数据流的实用程序和工具部分介绍的实用程序。
标签：
评论
