Cisco 基于软件的路由器使用软件来处悝和路由数据包当路由器执行更多数据包处理和路由操作时，Cisco 路由器上的 CPU 使用率势必增加因此，show processes cpu 命令可对路由器上的数据流处理负载提供一个相当准确的指示

Catalyst 怎么让交换机产生风暴使用 CPU 的方式不同。这些怎么让交换机产生风暴在硬件而不是软件中做出转发决策因此，当怎么让交换机产生风暴对通过怎么让交换机产生风暴的大多数帧做出转发或交换决策时进程不会占用 Supervisor 引擎

注意： MAC 地址识别也称为路徑设置。

触发数据流进入软件的情况和功能

发往怎么让交换机产生风暴的任何数据包都会进入软件此类数据包包括：

对于 STP、CDP、VTP、热备用蕗由器协议 (HSRP)、PAgP、链路聚合控制协议 (LACP) 和单向链路检测 (UDLD)，将收到控制数据包

这些协议的示例包括路由信息协议(RIP)、增强型内部网关路由协议(EIGRP)、邊界网关协议 (BGP) 和开放最短路径优先（OSPF 协议）。

当CPU上升时请包括这些in命令EEM脚本为了验证SSH会话数量建立：

需要特殊处理的数据包和情况

此列表提供强制数据包在软件中进行处理的特定数据包类型和情况：

·        如果输入信息包返回位错误(例如一位错误(SBE))数据包被发送对处理的软件的CPU囷被更正。系统分配他们的一缓冲区并且使用CPU资源更正它

收集是指需要 ARP 解析的数据包，接收是指归入接收情况的数据包

注意： 这是默認设置。

如果已启用“IP 不可达”功能则 ACL 拒绝的某些数据包将被泄漏给MSFC。需要“ICMP 不可达”的数据包将以用户可配置的速率泄漏默认情况丅，速率为每秒 500 个数据包（500 pps）

在 Supervisor 引擎 720 上可以对受身份验证代理控制的数据流进行速率限制。

·        基于 NetFlow 的功能总是需要在软件中看到数据流嘚第一个数据包数据流的第一个数据包到达软件后，将对同一数据流的后续数据包进行硬件交换

注意： 在 Supervisor 引擎 1 上，自反 ACL 依靠动态 TCAM 条目創建特定数据流的硬件快捷方式原理是相同的：数据流的第一个数据包进入软件。该数据流的后续数据包进行硬件交换

需要 NAT 的数据流茬初始转换后在硬件中进行处理。流的第一个数据包的转换在软件中进行该流的后续数据包进行硬件交换。对于 TCP 数据包将在完成 TCP 三次握手后在 Netflow 表中创建硬件快捷方式。

需要 NAT 的所有数据流都进行软件交换

·        基于上下文的访问控制 (CBAC) 使用 Netflow 快捷方式将需要检查的数据流分类。嘫后CBAC 仅将此数据流发送到软件。CBAC 是一个仅限软件的功能；受检查控制的数据流不进行硬件交换

注意： 在 Supervisor 引擎 720 上可以对受检查控制的数據流进行速率限制。

此数据流实际上被发往路由器

此数据流实际上被发往路由器。

这些多播数据包通过隧道被传输到集合点

软件为所囿数据包执行此 uRPF。

软件处理这些自反 ACL

软件处理此隧道。所有其他进入ISATAP 隧道的数据流进行硬件交换

硬件编程和与中央 Supervisor 模块通信。

当启动 lcp schedular 時它将利用所有进程可用时间。但当新进程需要处理器时间时lcp schedular 会为新进程释放进程时间。此高 CPU 使用率对系统性能没有影响该进程只昰获取所有未使用的 CPU 周期（只要没有更高优先级的进程需要它们）。

高 CPU 使用率问题的常见原因和解决方案

当访问组拒绝数据包时MSFC 会发送 ICMP 鈈可达消息。此操作在默认情况下发生

使用默认启用的 ip unreachables 命令，Supervisor 引擎将在硬件中丢弃大多数被拒绝的数据包然后，Supervisor 引擎仅将数量很少的數据包（最多 10 pps）发送到 MSFC 进行丢弃此操作会生成 ICMP 不可达消息。

丢弃被拒绝的数据包和生成 ICMP 不可达消息会造成 MSFC CPU 负载增加为了降低负载，可鉯发出 no ip unreachables 接口配置命令此命令将禁用ICMP 不可达消息，这允许在硬件中丢弃所有被访问组拒绝的数据包

如果 VACL 拒绝数据包，将不发送 ICMP

NAT 同时使用硬件和软件转发NAT 转换的最初建立必须在软件中完成，进一步的转发在硬件中完成NAT 还使用 Netflow 表（最大 128 KB）。因此如果 Netflow 表已满，怎么让交换機产生风暴也将开始通过软件应用 NAT 转发这通常发生在流量突然升高时，并将导致 6500 CPU 使用率的增加

流缓存表中 CEF FIB 表空间的使用

128,000 个条目的流缓存表。但是根据散列算法的效率，这些条目的数量范围在 32,000 到 120,000 个之间在 Supervisor 引擎 Supervisor 引擎 720 支持多达 1,000,000 个条目。一旦超出此空间便变为在软件中交換数据包。这可能在 RP 上导致高 CPU 使用率为了检查 CEF FIB 表中的路由数，请使用以下命令：

条目的数量将减少到一半此配置可能导致对更多数据包进行软件交换，并因此导致高 CPU 使用率

为了解决高CPU利用率问题， enable (event)路由总结路由总结能通过减少处理器工作量、内存要求和带宽需求最尛化在复杂网络的延迟。

优化的 ACL 日志记录

优化的 ACL 日志记录 (OAL) 为 ACL 日志记录提供硬件支持除非配置 OAL，否则对需要日志记录的数据包的处理将完铨在 MSFC3 上的软件中进行OAL 在 PFC3 上的硬件中允许或丢弃数据包。OAL 使用一个优化的例程向 MSFC3 发送信息以生成日志记录消息

注意： 有关 OAL 的信息，请参閱了解

到 CPU 的数据包的速率限制

在 Supervisor 引擎 720 上速率限制器可以控制数据包进入软件的速率。此速率控制可帮助防止拒绝服务攻击还可以在 Supervisor 引擎 2 上使用这些速率限制器中的一部分：

为了限制所有 CEF 转出的数据包发往 MSFC 的速率，请发出本示例中的命令：

的数据包数量请发出以下命令：

例如，这是netdr捕获的输出显示该IPv4 TTL是1 ：

高 CPU 使用率也可能是由于泄漏给 CPU 的 TTL=1 的数据包引起的。为了限制泄漏给 CPU 的数据包的数量请配置一个硬件速率限制器。速率限制器可以限制从硬件数据路径直到软件数据路径泄漏的数据包的速率速率限制器可通过丢弃超过配置速率的数据鋶，来防止软件控制路径发生拥塞速率限制是使用 mls rate-limit

由于不正确布线导致的VLAN 物理合并

高 CPU 使用率也可能是由于因不正确布线而将两个或更多 VLAN 匼并到一起引起的。此外如果在发生 VLAN 合并的这些端口上已禁用 STP，则也可能出现高 CPU 使用率

为了解决此问题，请识别布线错误并进行更正如果您的要求允许，也可以在这些端口上启用 STP

当广播或多播数据包泛洪 LAN 时，会出现 LAN 广播风暴这会创建过多的数据流并且降低网络性能。协议堆栈实施或网络配置中的错误可能导致广播风暴

由于 Catalyst 6500 系列平台的体系结构设计，广播数据包始终仅在软件级别被丢弃

广播抑淛可防止广播风暴破坏 LAN 接口。广播抑制使用测量 1 秒时段内 LAN 上的广播活动并将测量结果与预定义的阈值进行比较的过滤方法如果达到阈值，则将在指定时段内抑制进一步的广播活动广播抑制在默认情况下处于禁用状态。

注意： 从掌握的备份的VRRP飘荡由广播风暴导致也许导致高CPU利用率

为了了解广播抑制的工作原理以及如何启用该功能，请参阅：

BGP 下一跳地址跟踪（BGP

BGP 扫描程序进程扫描 BGP 表并确认下一跳的可达性此进程也检查条件通告以确定 BGP 是否应该通告条件前缀并/或执行路由衰减。默认情况下该进程每

在具有大型 Internet 路由表的路由器上执行 BGP 扫描程序进程时，您可以预料到会因此出现持续时间较短的高 CPU 使用率每分钟一次，BGP 扫描程序扫描 BGP 路由信息库 (RIB) 表并执行重要维护任务这些任务包括：

因此，扫描和验证大型 BGP 表需要花费相当长的时间BGP 扫描程序进程扫描 BGP 表以更新所有数据结构，并扫描路由表以进行路由重分配两個表分别存储在路由器内存中。两个表都可能非常大并因此可能会耗尽

有关 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 故障数据包因为它们已按照来自源的流向被反向传输回去。

配置为充当功能完备的多播路由器使用多播多层交换 (MMLS)，RPF 数据流通常在怎么讓交换机产生风暴内由硬件进行转发ASIC 被提供了来自多播路由状态的信息（例如，(*,G) 数据流在某些情况下仍然是必需的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）用于控制密集模式网络和稀疏模式中转网络中的

在 Catalyst 6500 上，有一个使过滤能够以线速进行的访问列表引擎此功能可用于有效地处理稀疏模式组的非 RPF 数据流。为了实施此解决方案请在“残域网络”的传叺接口上放置一个访问列表，以过滤不是源自“残域网络”的多播数据流此访问列表被推入怎么让交换机产生风暴的硬件中。此访问列表可防止 CPU 看到数据包并允许硬件丢弃非

注意： 请勿在中转接口上放置此访问列表。它只供残域网络（只包含主机的网络）使用

有关详細信息，请参阅以下文档：

使用率总是几乎 100%发出 show 命令时出现高 CPU 使用率是正常的，高 CPU 使用率通常仅保持几秒钟

例如，发出 show tech-support 命令时虚拟 Exec 進程导致 CPU 使用率升高是正常的，因为此输出是一个中断驱动的输出您只需关心执行 show 命令以外的其他进程时出现的高 CPU 使用率。

当您监控CPU状態时显示ibc和显示ibc简化show命令CPU队列，并且可以使用

TTY 线路（控制台、辅助、异步）上的通信。虚拟 Exec 进程负责 vty 线路（Telnet 会话）Exec 和虚拟 Exec 进程是中優先级进程，因此如果有具有更高优先级（“高”或“重要”）的其他进程则更高优先级进程将获得

如果通过这些会话传输的数据很多，则 Exec 进程的 CPU 使用率将增加这是因为当路由器需要通过这些线路发送一个简单字符时，它会使用一些 CPU 资源：

此列表详细说明了执行 Exec 进程时 CPU 使用率较高的某些可能原因：

1.    如果线路只有传出数据流则对此线路禁用 Exec 进程。这是因为如果连接到此线路的设备（例如，调制解调器）发送一些主动提供的数据Exec 进程将在此线路上启动。

2.    如果路由器用作终端服务器（以便可以执行到其他设备控制台的反向 Telnet）建议在连接到其他设备的控制台的线路上配置 no exec 命令。否则从控制台返回的数据可能会启动一个 Exec 进程，该进程将使用 CPU 资源

执行虚拟 Exec 进程时 CPU 使用率較高的一个可能原因是：

命令验证通过每个 VTY 会话传输的数据量。

值时CPU 使用率可能会达到 100%。

如果遇到此问题请检查是否启用了以下两个命令：

如果启用这些命令，该进程必须使用 NDE 导出所有目标和源 IfIndex 值L3 老化进程会导致 CPU 使用率升高，因为它必须对所有目标和源 IfIndex 值执行 FIB 查找洇此，表将变满L3 老化进程导致 CPU 使用率升高，CPU 使用率达到

为了解决此问题请禁用这些命令：

请使用这些命令验证值：

生成树在冗余交换網络和网桥网络中维护一个无环路的第2 层环境。没有 STP帧会无限循环并/或倍增。这将导致网络崩溃因为高流量将中断广播域中的所有设備。

在某些方面STP 最初是为基于软件的缓慢网桥规范 (IEEE 802.1D) 开发的早期协议，但是要在具有以下功能的大型交换网络中成功实施该协议STP 可能非瑺复杂：

如果网络面临频繁的生成树计算或怎么让交换机产生风暴必须处理更多 BPDU，则可能导致 CPU 使用率较高以及 BPDU 被丢弃

为了解决这些问题，请执行下列步骤中的部分或全部：

另请参阅在网络中实施生成树协议 (STP) 的最佳实践

基于 Catalyst 系列怎么让交换机产生风暴的体系结构，SPAN 会话不會影响怎么让交换机产生风暴的性能但是，如果 SPAN 会话中包括高流量/上行链路端口或 EtherChannel则它可能增加处理器上的负载。如果它随后要选出┅个特定 VLAN这还会增加更多工作量。如果链路上存在不良数据流这可能进一步增加工作量。

在某些情况下RSPAN 功能可能导致环路，并可能導致处理器上的负载激增有关详细信息，请参阅为何 SPAN 会话会产生桥接环路

怎么让交换机产生风暴可以像平常一样传递数据流，因为所囿操作都在硬件中进行但是如果它试图确定要发送哪个数据流，CPU 可能难以承受建议只在必需时配置

当 TCAM 中的可用空间量被超出时，将收箌此错误信息这将导致 CPU 使用率较高。这是一个 FIB TCAM 限制一旦 TCAM 已满，便将设置一个标志并将收到 FIB TCAM 异常错误。这将停止向 TCAM 添加新的路由因此，所有数据流都将进行软件交换删除路由对恢复硬件交换没有帮助。一旦 TCAM 进入异常错误状态必须重新加载系统才能脱离该状态。通過 mls cef maximum-routes 命令可以增加 TCAM 中可以安装的最大路由数

ACL在L4协议端口端口号，匹配此命令是需要的如果此命令没有启用， IPv6流量将被踢对软件处理的CPU默认情况下此命令没有配置。

比其他类型的 SFP 需要更多固件交互这会使 CPU

6500 系列怎么让交换机产生风暴中，正常 CPU 使用率稍大于非模块化 IOS 软件

模块化 IOS 软件为每个活动付出的代价多于它为每个数据包付出的代价。模块化 IOS 软件通过消耗特定的 CPU 来维护进程即使没有多少数据包也是如此，因此 CPU 消耗并不基于实际数据流但是，当处理的数据包比率升高时在模块化 IOS 软件中消耗的 CPU 不应多于在非模块化 IOS 软件中消耗的 CPU。

cpu 命令输出显示怎么让交换机产生风暴上的 CPU 使用率以及每个进程的 CPU 使用率。

在此输出中总 CPU 使用率是 57%，中断 CPU 使用率是 48%此处，这些百分比以粗體文本显示由 CPU 进行的数据流中断交换将导致中断 CPU 使用率。命令输出列出了导致两种使用率之间的差异的进程在本例中，原因是 SNMP 进程

引擎上，输出如下所示：

在此输出中第一个进程是 Kernel and Idle，它显示空闲 CPU 使用率通常，此进程显示的空闲 CPU 使用率较高除非一些其他进程占用 CPU 周期。在本示例中SptBpduRx 进程导致高 CPU 使用率。

如果 CPU 使用率较高是由于这些进程之一导致的您可以排除故障并确定此进程导致高 CPU 使用率的原因。但是如果 CPU 较高是由于被转出到 CPU 的数据流导致的，则您需要确定数据流被转出的原因确定数据流被转出的原因可帮助您识别该数据流昰什么。

对于排除故障当您体验高CPU利用率时，请使用此EEM脚本示例为了从怎么让交换机产生风暴收集输出：

当CPU是由于的高处理数据包交换洏不是硬件时调试netdr捕获rx命令是有用。当命令运行时它获取4096数据包流入对CPU。命令是十分安全的并且是高CPU问题的最方便的工具在6500它不引起额外的负载CPU。

用于确定被传送到CPU 的数据流的实用程序和工具

本部分确定了可帮助您查看此数据流的一些实用程序和工具

引擎上的交换處理器称为 SP，MSFC 称为 RP

show interface 命令提供有关接口状态和接口上数据流速率的基本信息。此命令也提供错误计数器

在此输出中，可以看到传入数据鋶是在第 3 层交换的（而不是在第 2 层交换的）这表明数据流被转出到 CPU。

show processes cpu 命令告诉您这些数据包是常规数据流数据包还是控制数据包

如果數据包是进程交换的，您会看到 IP Input process 的 CPU 使用率升高发出此命令可以看到以下数据包：

如果数据流是中断交换的，则使用 show buffers input-interface 命令无法看到这些数據包为了看到由于中断交换被转出到 RP 的数据包，可以执行 RP 端口的交换端口分析程序 (SPAN) 捕获

注意： 有关中断交换与进程交换 CPU 使用率的详细信息，请参阅以下文档：

注意： 对于 SXH 版本必须使用

注意： 有关这些命令的详细信息，请参阅 Catalyst 6500 版本 12.2SX 软件配置指南 中的配置本地

以下是 RP 控制囼上的一个示例：

现在转到 SP 控制台。示例如下：

以下是 SP 控制台上的一个示例：

注意： 端口 16/1 用于插槽

此数字快速增加表明数据包被转出到 MSFC导致高 CPU 使用率。然后您可以通过以下方式查看数据包：

端口 15/1（或 16/1）目标是以太网端口。

如果收集端口 5/10 上的嗅探器踪迹嗅探器踪迹显礻从 MSFC 传输的数据包和传输到 MSFC 的数据包。 将 SPAN 会话配置为tx 以只捕获发往 MSFC 的数据包而不捕获来自 MSFC 的数据包

注意： 对于光服务模块 (OSM)，不能执行数據流 SPAN 捕获

Supervisor 引擎 CPU 使用率不反映怎么让交换机产生风暴的硬件转发性能。但是仍必须以 Supervisor 引擎 CPU 使用率作为基线并对其进行监控。

1.    以稳定状态網络中具有正常数据流模式和负载的怎么让交换机产生风暴的 Supervisor 引擎 CPU 使用率作为基线

请注意哪些进程导致最高的 CPU 使用率。

1.    哪些进程导致最高使用率这些进程是否与您的基线不同？

2.    CPU 使用率是否一直高于基线或者是否存在出现高使用率峰值，然后返回基线水平的情况

注意： 已禁用 STP Portfast 的抖动端口或主机端口将导致TCN。

4.    如果可能请从具有用户数据流（特别是大量广播数据流）的 VLAN 中分离出管理 VLAN。

这种数据流类型的礻例包括 IPX RIP/服务通告协议 (SAP)、AppleTalk 和其他广播数据流此类数据流可能影响Supervisor 引擎 CPU 使用率，并且在特殊情况下可能干扰怎么让交换机产生风暴的正常運行

5.    如果由于数据流被转出到 RP 而导致 CPU 使用率很高，请确定该数据流是什么以及该数据流为什么被转出

为了进行此确定，请使用用于确萣被传送到 CPU 的数据流的实用程序和工具部分介绍的实用程序