数据流dhcp是什么

目录简介先决条件要求使用的组件规则CatOS和CiscoIOS系统软件之间的区别了解Catalyst6500/6000交换机上的CPU使用率触发数据流进入软件的情况和功能发往交换机的数据包需要特殊处理的数据包和情况基于ACL的功能基于NetFlow的功能多播流量其它特性IPv6情况LCPSchedular和DFC模块高CPU使用率问题的常见原因和解决方案IP不可达NAT转换流缓存表中CEFFIB表空间的使用优化的ACL日志记录到CPU的数据包的速率限制由于不正确布线导致的VLAN物理合并广播风暴BGP下一跳地址跟踪(BGP扫描程序进程)非RPF多播数据流显示命令Exec进程L3老化进程BPDU风暴SPAN会话%CFIB-SP-STBY-7-CFIB_EXCEPTION:FIBTCAMexception,Someentrieswillbesoftwareswitched运行以高CPU的Catalyst6500/6000有IPv6ACL用L4端口铜缆SPF模块化IOS检查CPU使用率用于确定被传送到CPU的数据流的实用程序和工具CiscoIOS系统软件CatOS系统软件建议相关信息简介本文档介绍CiscoCatalyst6500/6000系列交换机和基于虚拟交换系统(VSS)1440的系统上高CPU使用率的原因.
类似于Cisco路由器,交换机使用showprocessescpu命令显示交换机Supervisor引擎处理器的CPU使用率.
但是,由于Cisco路由器和交换机之间在体系结构和转发机制上存在差异,showprocessescpu命令的标准输出有很大的不同.
输出的含义有所不同.
本文澄清这些差异并且描述在交换机的CPU利用率和如何解释showprocessescpu命令输出.
注意:在本文档中,"交换机"一词是指Catalyst6500/6000交换机.
先决条件要求本文档没有任何特定的要求.
使用的组件本文档中的信息基于Catalyst6500/6000交换机和基于虚拟交换系统(VSS)1440的系统的软件和硬件版本.
本文档中的信息都是基于特定实验室环境中的设备编写的.
本文档中使用的所有设备最初均采用原始(默认)配置.
如果您使用的是真实网络,请确保您已经了解所有命令的潜在影响.
注意:基于虚拟交换系统(VSS)1440的系统的支持的软件是CiscoIOS软件版本12.
2(33)SXH1或以后.
规则有关文档规则的详细信息,请参阅Cisco技术提示规则.
CatOS和CiscoIOS系统软件之间的区别Supervisor引擎上的CatalystOS(CatOS)和MultilayerSwitchFeatureCard(MSFC)上的CiscoIOS软件(混合):可将CatOS映像用作系统软件,以在Catalyst6500/6000交换机上运行Supervisor引擎.
如果安装了可选的MSFC,则将使用单独的CiscoIOS软件映像来运行MSFC.
Supervisor引擎和MSFC上的CiscoIOS软件(本地):可将单个CiscoIOS软件映像用作系统软件,以在Catalyst6500/6000交换机上同时运行Supervisor引擎和MSFC.
注意:有关详细信息,请参阅比较CiscoCatalyst6500系列交换机的CiscoCatalyst和CiscoIOS操作系统.
了解Catalyst6500/6000交换机上的CPU使用率Cisco基于软件的路由器使用软件来处理和路由数据包.
当路由器执行更多数据包处理和路由操作时,Cisco路由器上的CPU使用率势必增加.
因此,showprocessescpu命令可对路由器上的数据流处理负载提供一个相当准确的指示.
Catalyst6500/6000交换机使用CPU的方式不同.
这些交换机在硬件而不是软件中做出转发决策.
因此,当交换机对通过交换机的大多数帧做出转发或交换决策时,进程不会占用Supervisor引擎CPU.
在Catalyst6500/6000交换机上,有两个CPU.
一个CPU是Supervisor引擎CPU,称为网络管理处理器(NMP)或交换机处理器(SP).
另一个CPU是第3层路由引擎CPU,称为MSFC或路由处理器(RP).
SPCPU执行以下功能:帮助执行MAC地址识别和老化操作注意:MAC地址识别也称为路径设置.
q运行提供网络控制的协议和进程示例包括生成树协议(STP)、Cisco发现协议(CDP)、VLAN中继协议(VTP)、动态中继协议(DTP)和端口聚合协议(PAgP).
q处理发往交换机CPU的网络管理数据流示例包括Telnet、HTTP和简单网络管理协议(SNMP)数据流.
qRPCPU执行以下功能:构建和更新第3层路由和地址解析协议(ARP)表q生成Cisco快速转发(CEF)转发信息库(FIB)和邻接表,并将这些表下载到PolicyFeatureCard(PFC)q处理发往RP的网络管理数据流示例包括Telnet、HTTP和SNMP数据流.
q触发数据流进入软件的情况和功能发往交换机的数据包发往交换机的任何数据包都会进入软件.
此类数据包包括:控制数据包对于STP、CDP、VTP、热备用路由器协议(HSRP)、PAgP、链路聚合控制协议(LACP)和单向链路检测(UDLD),将收到控制数据包.
q路由协议更新这些协议的示例包括路由信息协议(RIP)、增强型内部网关路由协议(EIGRP)、边界网关协议(BGP)和开放最短路径优先(OSPF协议).
q发往交换机的SNMP数据流q对交换机的Telnet和安全套接协议(SSH)流量.
高CPUultilization由于SSH被看到如下:当CPU上升时,请包括这些in命令EEM脚本为了验证SSH会话数量建立:showusersshowlineq对ARP请求的ARP响应q需要特殊处理的数据包和情况此列表提供强制数据包在软件中进行处理的特定数据包类型和情况:具有IP选项、过期存活时间(TTL)或非高级研究项目管理局(ARPA)封装的数据包q需要特殊处理(如建立隧道)的数据包qIP分段q需要来自RP或SP的Internet控制消息协议(ICMP)消息的数据包q最大传输单元(MTU)检查失败q具有IP错误(包括IP校验和长度错误)的数据包q如果输入信息包返回有点错误(例如一位错误(SBE))数据包被发送对处理的软件的CPU和被更正.
系统分配他们的一缓冲区并且使用CPU资源更正它.
q当PBR和自反访问列表在通信流的路径时,数据包是交换的软件,要求另外的CPU周期.
q邻接同一接口q失败反向路径转发的数据包(RPF)检查rpf-failureq收集/接收收集是指需要ARP解析的数据包,接收是指归入接收情况的数据包.
qSupervisor引擎720上在CiscoIOS软件和CatOS中都进行软件交换的互联网分组交换(IPX)数据流IPX数据流在Supervisor引擎2/CiscoIOS软件上也进行软件交换,但该数据流在Supervisor引擎2/CatOS上进行硬件交换.
IPX数据流在Supervisor引擎1A上对于两个操作系统都进行硬件交换.
qAppleTalk数据流q硬件资源已满情况这些资源包括FIB、内容可寻址存储器(CAM)和三重CAM(TCAM).
q基于ACL的功能已打开"ICMP不可达"功能的被访问控制列表(ACL)拒绝的数据流注意:这是默认设置.
如果已启用"IP不可达"功能,则ACL拒绝的某些数据包将被泄漏给MSFC.
需要"ICMP不可达"的数据包将以用户可配置的速率泄漏.
默认情况下,速率为每秒500个数据包(500pps).
qIPX根据不支持的参数(如源主机)进行过滤在Supervisor引擎720上,第3层IPX数据流的处理始终在软件中进行.
q具有log关键字的,需要日志记录的访问控制项(ACE)这适用于ACL日志和VLANACL(VACL)日志功能.
同一ACL中不需要日志记录的ACE仍在硬件中进行处理.
具有PFC3的Supervisor引擎720支持对因ACL和VACL日志记录而重定向到MSFC的数据包进行速率限制.
Supervisor引擎2支持对因VACL日志记录而重定向到MSFC的数据包进行速率限制.
Supervisor引擎2上对ACL日志记录的支持计划在CiscoIOS软件版本12.
2S分支中提供.
q策略路由的数据流(使用matchlength、setipprecedence或其他不支持的参数)软件中支持setinterface参数.
但是,setinterfacenull0参数是一个例外.
在具有PFC2的Supervisor引擎2和具有PFC3的Supervisor引擎720上,此数据流在硬件中进行处理.
q非IP和非IPX路由器ACL(RACL)非IPRACL适用于所有Supervisor引擎.
非IPXRACL仅适用于具有PFC的Supervisor引擎1a和具有PFC2的Supervisor引擎2.
q在RACL中被拒绝的广播数据流q在单播RPF(uRPF)检查中被拒绝的数据流,ACLACE此uRPF检查适用于具有PFC2的Supervisor引擎2和具有PFC3的Supervisor引擎720.
q身份验证代理在Supervisor引擎720上可以对受身份验证代理控制的数据流进行速率限制.
qCiscoIOS软件IP安全(IPSec)在Supervisor引擎720上可以对受CiscoIOS加密控制的数据流进行速率限制.
q基于NetFlow的功能本部分介绍的基于NetFlow的功能仅适用于Supervisor引擎2和Supervisor引擎720.
基于NetFlow的功能总是需要在软件中看到数据流的第一个数据包.
数据流的第一个数据包到达软件后,将对同一数据流的后续数据包进行硬件交换.
此数据流安排适用于自反ACL、Web缓存通信协议(WCCP)和CiscoIOS服务器负载均衡(SLB).
注意:在Supervisor引擎1上,自反ACL依靠动态TCAM条目创建特定数据流的硬件快捷方式.
原理是相同的:数据流的第一个数据包进入软件.
该数据流的后续数据包进行硬件交换.
q使用TCP拦截功能,三次握手和会话关闭将在软件中进行处理.
数据流的其余部分在硬件中进行处理.
注意:同步(SYN)、SYN确认(SYNACK)和ACK数据包构成三次握手.
会话关闭发生在完成(FIN)或重置(RST)时.
q使用网络地址转换(NAT),数据流按如下方式进行处理:在Supervisor引擎720上:需要NAT的数据流在初始转换后在硬件中进行处理.
流的第一个数据包的转换在软件中进行,该流的后续数据包进行硬件交换.
对于TCP数据包,将在完成TCP三次握手后在Netflow表中创建硬件快捷方式.
在Supervisor引擎2和Supervisor引擎1上:需要NAT的所有数据流都进行软件交换.
q基于上下文的访问控制(CBAC)使用Netflow快捷方式将需要检查的数据流分类.
然后,CBAC仅将此数据流发送到软件.
CBAC是一个仅限软件的功能;受检查控制的数据流不进行硬件交换.
注意:在Supervisor引擎720上可以对受检查控制的数据流进行速率限制.
q多播流量独立于协议的多播(PIM)监听qInternet组管理协议(IGMP)监听(TTL=1)此数据流实际上被发往路由器.
q多播监听程序发现(MLD)监听(TTL=1)此数据流实际上被发往路由器.
qFIB缺失q与多播源直接连接的用于注册的多播数据包这些多播数据包通过隧道被传输到集合点.
qIP版本6(IPv6)多播q其它特性基于网络的应用程序识别(NBAR)qARP检查,仅适用于CatOSq端口安全,仅适用于CatOSqDHCP监听qIPv6情况具有逐跳选项报头的数据包q与路由器具有相同目标IPv6地址的数据包q未能通过范围实施检查的数据包q超出输出链路的MTU的数据包qTTL小于或等于1的数据包q输入VLAN等于输出VLAN的数据包qIPv6uRPF软件为所有数据包执行此uRPF.
qIPv6自反ACL软件处理这些自反ACL.
qIPv6站内自动隧道编址协议(ISATAP)隧道的6to4前缀软件处理此隧道.
所有其他进入ISATAP隧道的数据流进行硬件交换.
qLCPSchedular和DFC模块在DistributedForwardingCard(DFC)中,在使用率较高的CPU上运行的lcpschedular进程不是问题,不会造成任何运行问题.
LCPSchedular是固件代码的一部分.
在不需要DFC的所有模块上,固件在称为线路卡处理器(LCP)的一个特定处理器上运行.
该处理器用于对ASIC硬件编程和与中央Supervisor模块通信.
当启动lcpschedular时,它将利用所有进程可用时间.
但当新进程需要处理器时间时,lcpschedular会为新进程释放进程时间.
此高CPU使用率对系统性能没有影响.
该进程只是获取所有未使用的CPU周期(只要没有更高优先级的进程需要它们).
DFC#showprocesscpuPIDRuntime(ms)InvokeduSecs5Sec1Min5MinTTYProcess220100.
00%0.
00%0.
00%0SCPChilisLCLis230100.
00%0.
00%0.
00%0IPCRTTYCMessag240900.
00%0.
00%0.
00%0ICCSlaveLCReq250100.
00%0.
00%0.
00%0ICCAsyncmcast260200.
00%0.
00%0.
00%0RPCSync270100.
00%0.
00%0.
00%0RPCrpc-master280100.
00%0.
00%0.
00%0NetInput290200.
00%0.
00%0.
00%0ProtocolFilteri308105760.
00%0.
00%0.
00%0RemoteConsoleP31401530260.
00%0.
00%0.
00%0L2ControlTask3272986730.
00%0.
02%0.
00%0L2AgingTask334211900.
00%0.
00%0.
00%0L3ControlTask3412652180.
00%0.
00%0.
00%0FIBControlTask359148165554421.
22%1.
22%1.
15%0StatisticsTask36441390.
00%0.
00%0.
00%0PFIBTableManag37655016646900361075.
33%77.
87%71.
10%0lcpschedular38076200.
00%0.
00%0.
00%0ConstellationSP高CPU使用率问题的常见原因和解决方案IP不可达当访问组拒绝数据包时,MSFC会发送ICMP不可达消息.
此操作在默认情况下发生.
使用默认启用的ipunreachables命令,Supervisor引擎将在硬件中丢弃大多数被拒绝的数据包.
然后,Supervisor引擎仅将数量很少的数据包(最多10pps)发送到MSFC进行丢弃.
此操作会生成ICMP不可达消息.
丢弃被拒绝的数据包和生成ICMP不可达消息会造成MSFCCPU负载增加.
为了降低负载,可以发出noipunreachables接口配置命令.
此命令将禁用ICMP不可达消息,这允许在硬件中丢弃所有被访问组拒绝的数据包.
如果VACL拒绝数据包,将不发送ICMP不可达消息.
NAT转换NAT同时使用硬件和软件转发.
NAT转换的最初建立必须在软件中完成,进一步的转发在硬件中完成.
NAT还使用Netflow表(最大128KB).
因此,如果Netflow表已满,交换机也将开始通过软件应用NAT转发.
这通常发生在流量突然升高时,并将导致6500CPU使用率的增加.
流缓存表中CEFFIB表空间的使用Supervisor引擎1有一个支持128,000个条目的流缓存表.
但是,根据散列算法的效率,这些条目的数量范围在32,000到120,000个之间.
在Supervisor引擎2上,会生成FIB表并将其编程到PFC中.
该表可容纳多达256,000个条目.
具有PFC3-BXL的Supervisor引擎720支持多达1,000,000个条目.
一旦超出此空间,便变为在软件中交换数据包.
这可能在RP上导致高CPU使用率.
为了检查CEFFIB表中的路由数,请使用以下命令:Router#showprocessescpuCPUutilizationforfiveseconds:99.
26%oneminute:100.
00%fiveminutes:100.
00%PIDRuntime(ms)InvokeduSecs5Sec1Min5MinTTYProcess-10000.
74%0.
00%0.
00%-2KernelandIdle2224510000.
00%0.
00%0.
00%-2FlashMIBUpdat30100.
00%0.
00%0.
00%-2L2L3IntHdlr40100.
00%0.
00%0.
00%-2L2L3PatchRev56531173710000.
00%0.
00%0.
00%-2SynDi!
---Outputissuppressed.
261057661597010000.
00%0.
00%0.
00%0L3Aging27474325169680000.
02%0.
00%0.
00%0NetFlow286758259106083150100096.
62%96.
00%96.
00%0Fib290100.
00%0.
00%0.
00%-2Fib_bg_task!
---Outputissuppressed.
CATOS%showmlscefTotalL3packetsswitched:124893998234TotalL3octetsswitched:53019378962495Totalrouteentries:112579IProuteentries:112578IPXrouteentries:1IPMrouteentries:0IPloadsharingentries:295IPXloadsharingentries:0Forwardingentries:112521Bridgeentries:56Dropentries:2IOS%showipcefsummaryIPDistributedCEFwithswitching(TableVersion86771423),flags=0x0112564routes,1reresolve,0unresolved(0old,0new)112567leaves,6888nodes,21156688bytes,86771426inserts,86658859invalidations295loadsharingelements,96760bytes,112359referencesuniversalper-destinationloadsharingalgorithm,id8ADDA64A2CEFresets,2306608revisionsofexistingleavesrefcounts:1981829leaf,1763584node!
---YouseethesemessagesiftheTCAMspaceisexceeded:%MLSCEF-SP-7-FIB_EXCEPTION:FIBTCAMexception,Someentrieswillbesoftwareswitched%MLSCEF-SP-7-END_FIB_EXCEPTION:FIBTCAMexceptioncleared,allCEFentrieswillbehardwareswitched在Supervisor引擎2上,如果已在接口上配置RPF检查,则FIB条目的数量将减少到一半.
此配置可能导致对更多数据包进行软件交换,并因此导致高CPU使用率.
为了解决高CPU利用率问题,enable(event)路由总结.
路由总结能通过减少处理器工作量、内存要求和带宽需求最小化在复杂网络的延迟.
有关TCAM使用率和优化的详细信息,请参阅了解Catalyst6500系列交换机上的ACL.
优化的ACL日志记录优化的ACL日志记录(OAL)为ACL日志记录提供硬件支持.
除非配置OAL,否则对需要日志记录的数据包的处理将完全在MSFC3上的软件中进行.
OAL在PFC3上的硬件中允许或丢弃数据包.
OAL使用一个优化的例程向MSFC3发送信息以生成日志记录消息.
注意:有关OAL的信息,请参阅了解CiscoIOSACL支持的使用PFC3的优化的ACL日志记录部分.
到CPU的数据包的速率限制在Supervisor引擎720上,速率限制器可以控制数据包进入软件的速率.
此速率控制可帮助防止拒绝服务攻击.
还可以在Supervisor引擎2上使用这些速率限制器中的一部分:Router#showmlsrate-limitRateLimiterTypeStatusPackets/sBurst-MCASTNONRPFOff--MCASTDFLTADJOn100000100MCASTDIRECTCONOff--ACLBRIDGEDINOff--ACLBRIDGEDOUTOff--IPFEATURESOff--ACLVACLLOGOn20001CEFRECEIVEOff--CEFGLEANOff--MCASTPARTIALSCOn100000100IPRPFFAILUREOn50010TTLFAILUREOff--ICMPUNREAC.
NO-ROUTEOn50010ICMPUNREAC.
ACL-DROPOn50010ICMPREDIRECTOff--MTUFAILUREOff--LAYER_2PDUOff--LAYER_2PTOff--IPERRORSOn50010CAPTUREPKTOff--MCASTIGMPOff--Router(config)#mlsrate-limitallRateLimitingforbothUnicastandMulticastpacketslayer2layer2protocolcasesmulticastRatelimitingforMulticastpacketsunicastRatelimitingforUnicastpackets示例如下:Router(config)#mlsrate-limitlayer2l2pt3000为了限制所有CEF转出的数据包发往MSFC的速率,请发出本示例中的命令:Router(config)#mlsipcefrate-limit50000为了减少由于TTL=1而被转出到CPU的数据包数量,请发出以下命令:Router(config)#mlsrate-limitallttl-failure15!
---where15isthenumberofpacketspersecondwithTTL=1.
!
---Thevalidrangeisfrom10to1000000pps.
例如,这是netdr捕获的输出,显示该IPv4TTL是1:Router(config)#mlsrate-limitallttl-failure15!
---where15isthenumberofpacketspersecondwithTTL=1.
!
---Thevalidrangeisfrom10to1000000pps.
高CPU使用率也可能是由于泄漏给CPU的TTL=1的数据包引起的.
为了限制泄漏给CPU的数据包的数量,请配置一个硬件速率限制器.
速率限制器可以限制从硬件数据路径直到软件数据路径泄漏的数据包的速率.
速率限制器可通过丢弃超过配置速率的数据流,来防止软件控制路径发生拥塞.
速率限制是使用mlsrate-limitallttl-failure命令配置的.
由于不正确布线导致的VLAN物理合并高CPU使用率也可能是由于因不正确布线而将两个或更多VLAN合并到一起引起的.
此外,如果在发生VLAN合并的这些端口上已禁用STP,则也可能出现高CPU使用率.
为了解决此问题,请识别布线错误并进行更正.
如果您的要求允许,也可以在这些端口上启用STP.
广播风暴当广播或多播数据包泛洪LAN时,会出现LAN广播风暴,这会创建过多的数据流并且降低网络性能.
协议堆栈实施或网络配置中的错误可能导致广播风暴.
由于Catalyst6500系列平台的体系结构设计,广播数据包始终仅在软件级别被丢弃.
广播抑制可防止广播风暴破坏LAN接口.
广播抑制使用测量1秒时段内LAN上的广播活动并将测量结果与预定义的阈值进行比较的过滤方法.
如果达到阈值,则将在指定时段内抑制进一步的广播活动.
广播抑制在默认情况下处于禁用状态.
注意:从掌握的备份的VRRP飘荡由广播风暴导致也许导致高CPU利用率.
为了了解广播抑制的工作原理以及如何启用该功能,请参阅:配置广播抑制(CiscoIOS系统软件)q配置广播抑制(CatOS系统软件)qBGP下一跳地址跟踪(BGP扫描程序进程)BGP扫描程序进程扫描BGP表并确认下一跳的可达性.
此进程也检查条件通告以确定BGP是否应该通告条件前缀并/或执行路由衰减.
默认情况下,该进程每60秒扫描一次.
在具有大型Internet路由表的路由器上执行BGP扫描程序进程时,您可以预料到会因此出现持续时间较短的高CPU使用率.
每分钟一次,BGP扫描程序扫描BGP路由信息库(RIB)表并执行重要维护任务.
这些任务包括:检查路由器BGP表中引用的下一跳q验证下一跳设备是否可以到达q因此,扫描和验证大型BGP表需要花费相当长的时间.
BGP扫描程序进程扫描BGP表以更新所有数据结构,并扫描路由表以进行路由重分配.
两个表分别存储在路由器内存中.
两个表都可能非常大,并因此可能会耗尽CPU周期.
有关BGP扫描程序进程的CPU使用率的详细信息,请参阅解决由BGP扫描器和BGP路由器进程引起的高CPU使用率问题的由于BGP扫描程序而导致CPU使用率较高部分.
有关BGP下一跳地址跟踪功能和启用/禁用或调整扫描间隔的过程的详细信息,请参阅对下一跳地址跟踪的BGP支持.
非RPF多播数据流多播路由(不同于单播路由)只关心给定多播数据流的源.
即发起多播数据流的设备的IP地址.
基本原理是源设备将数据流"推"出到数量不确定的接收方(在其多播组内).
所有多播路由器都会创建分布树,这些分布树控制多播数据流通过网络将数据流发送到所有接收方所采用的路径.
多播分布树的两种基本类型是源树和共享树.
RPF是多播转发中的一个重要概念.
它使路由器可以沿分布树正确转发多播数据流.
RPF利用现有的单播路由表确定上游与下游邻居.
只有当上游接口收到多播数据包时,路由器才会转发该数据包.
此RPF检查可帮助保证分布树无环路.
根据IEEE802.
3CSMA/CD规范,多播数据流在桥接的(第2层)LAN上对于每个路由器始终可见.
在802.
3标准中,第一个八位组的位0用于指示广播和/或多播帧,具有此地址的所有第2层帧将被泛洪.
即使配置了CGMP或IGMP监听,也是这种情况.
这是因为,如果希望多播路由器做出正确的转发决策,多播路由器必须看到多播数据流.
如果多个多播路由器中的每一个都在公共LAN上有接口,则只有一个路由器转发数据(通过选举过程选择).
由于LAN的泛洪性质,冗余路由器(不转发多播数据流的路由器)在该LAN的出站接口上收到此数据.
冗余路由器通常会丢弃此数据流,因为该数据流已到达错误的接口,因此无法通过RPF检查.
无法通过RPF检查的此数据流称为非RPF数据流或RPF故障数据包,因为它们已按照来自源的流向被反向传输回去.
可以将安装了MSFC的Catalyst6500配置为充当功能完备的多播路由器.
使用多播多层交换(MMLS),RPF数据流通常在交换机内由硬件进行转发.
ASIC被提供了来自多播路由状态的信息(例如,(*,G)和(S,G)),因此可以将硬件快捷方式编程到Netflow和/或FIB表中.
这种非RPF数据流在某些情况下仍然是必需的,MSFCCPU(在进程级别)需要它才能使用PIM主张机制.
否则,它将被软件快速交换路径丢弃(假定未在RPF接口上禁用软件快速交换).
使用冗余的Catalyst6500在某些拓扑中可能无法有效处理非RPF数据流.
对于非RPF数据流,冗余路由器中通常没有(*,G)或(S,G)状态,因此不能创建任何硬件或软件快捷方式来丢弃数据包.
MSFC路由处理器必须分别检查每个多播数据包,这通常被称为CPU中断数据流.
使用第3层硬件交换和连接同一组路由器的多个接口/VLAN,到达冗余MSFC的CPU的非RPF数据流被放大为原始源速率的"N"倍(其中"N"是路由器以冗余方式连接到的LAN的数量).
如果非RPF数据流的速率超过系统的数据包丢弃能力,则可能导致高CPU使用率、缓冲区溢出和整体网络不稳定.
对于Catalyst6500,有一个使过滤能够以线速进行的访问列表引擎.
在某些情况下,此功能可用于有效地处理稀疏模式组的非RPF数据流.
只能在没有下游多播路由器(及对应的接收方)的稀疏模式"残域网络"中,才能使用基于ACL的方法.
此外,由于Catalyst6500的数据包转发设计,内部冗余的MSFC不能使用此实施.
这将在CiscoBugIDCSCdr74908(仅限注册用户)中进行概述.
对于密集模式组,必须在路由器上看到非RPF数据包,PIM主张机制才能正常运行.
不同的解决方案(如CEF或基于Netflow的速率限制和QoS)用于控制密集模式网络和稀疏模式中转网络中的RPF故障.
在Catalyst6500上,有一个使过滤能够以线速进行的访问列表引擎.
此功能可用于有效地处理稀疏模式组的非RPF数据流.
为了实施此解决方案,请在"残域网络"的传入接口上放置一个访问列表,以过滤不是源自"残域网络"的多播数据流.
此访问列表被推入交换机的硬件中.
此访问列表可防止CPU看到数据包,并允许硬件丢弃非RPF数据流.
注意:请勿在中转接口上放置此访问列表.
它只供残域网络(只包含主机的网络)使用.
有关详细信息,请参阅以下文档:残域网络中IP多播的冗余路由器问题q非RPF数据流处理q显示命令发出show命令时,CPU使用率总是几乎100%.
发出show命令时出现高CPU使用率是正常的,高CPU使用率通常仅保持几秒钟.
例如,发出showtech-support命令时,虚拟Exec进程导致CPU使用率升高是正常的,因为此输出是一个中断驱动的输出.
您只需关心执行show命令以外的其他进程时出现的高CPU使用率.
showcefnot-cef-switched命令显示数据包为什么被踢对MSFC(接收、IP选项、没有邻接等等),并且多少.
例如:Switch#showcefnot-cef-switchedCEFPacketspassedontonextswitchinglayerSlotNo_adjNo_encapUnsupp'tedRedirectReceiveOptionsAccessFragRP62220136060122000500000000IPv6CEFPacketspassedontonextswitchinglayerSlotNo_adjNo_encapUnsupp'tedRedirectReceiveOptionsAccessMTURP00000000当您监控CPU状态时,显示ibc和显示ibc简化show命令CPU队列,并且可以使用.
Exec进程CiscoIOS软件中的Exec进程负责路由器TTY线路(控制台、辅助、异步)上的通信.
虚拟Exec进程负责vty线路(Telnet会话).
Exec和虚拟Exec进程是中优先级进程,因此如果有具有更高优先级("高"或"重要")的其他进程,则更高优先级进程将获得CPU资源.
如果通过这些会话传输的数据很多,则Exec进程的CPU使用率将增加.
这是因为当路由器需要通过这些线路发送一个简单字符时,它会使用一些CPU资源:对于控制台(Exec),路由器为每个字符使用一个中断.
q对于VTY线路(虚拟Exec),Telnet会话必须为每个字符建立一个TCP数据包.
q此列表详细说明了执行Exec进程时CPU使用率较高的某些可能原因:通过控制台端口发送的数据过多.
请查看是否已使用showdebugging命令在路由器上启动了任何调试.
使用no形式的loggingconsole命令在路由器上禁用控制台日志记录.
验证是否在控制台上显示了较长的输出.
例如,showtech-support或showmemory命令.
qexec命令是为异步和辅助线路配置的.
如果线路只有传出数据流,则对此线路禁用Exec进程.
这是因为,如果连接到此线路的设备(例如,调制解调器)发送一些主动提供的数据,Exec进程将在此线路上启动.
如果路由器用作终端服务器(以便可以执行到其他设备控制台的反向Telnet),建议在连接到其他设备的控制台的线路上配置noexec命令.
否则,从控制台返回q的数据可能会启动一个Exec进程,该进程将使用CPU资源.
执行虚拟Exec进程时CPU使用率较高的一个可能原因是:通过Telnet会话发送的数据过多.
执行虚拟Exec进程时CPU使用率较高的最常见原因是从路由器传输到Telnet会话的数据过多.
从Telnet会话执行具有较长输出的命令(如showtech-support、showmemory等)时,可能出现这种情况.
可以使用showtcpVTY命令验证通过每个VTY会话传输的数据量.
qL3老化进程当L3老化进程使用NetFlow数据导出(NDE)导出大量IfIndex值时,CPU使用率可能会达到100%.
如果遇到此问题,请检查是否启用了以下两个命令:Switch#showcefnot-cef-switchedCEFPacketspassedontonextswitchinglayerSlotNo_adjNo_encapUnsupp'tedRedirectReceiveOptionsAccessFragRP62220136060122000500000000IPv6CEFPacketspassedontonextswitchinglayerSlotNo_adjNo_encapUnsupp'tedRedirectReceiveOptionsAccessMTURP00000000Switch#showcefnot-cef-switchedCEFPacketspassedontonextswitchinglayerSlotNo_adjNo_encapUnsupp'tedRedirectReceiveOptionsAccessFragRP62220136060122000500000000IPv6CEFPacketspassedontonextswitchinglayerSlotNo_adjNo_encapUnsupp'tedRedirectReceiveOptionsAccessMTURP00000000如果启用这些命令,该进程必须使用NDE导出所有目标和源IfIndex值.
L3老化进程会导致CPU使用率升高,因为它必须对所有目标和源IfIndex值执行FIB查找.
因此,表将变满,L3老化进程导致CPU使用率升高,CPU使用率达到100%.
为了解决此问题,请禁用这些命令:Switch#showcefnot-cef-switchedCEFPacketspassedontonextswitchinglayerSlotNo_adjNo_encapUnsupp'tedRedirectReceiveOptionsAccessFragRP62220136060122000500000000IPv6CEFPacketspassedontonextswitchinglayerSlotNo_adjNo_encapUnsupp'tedRedirectReceiveOptionsAccessMTURP00000000Switch#showcefnot-cef-switchedCEFPacketspassedontonextswitchinglayerSlotNo_adjNo_encapUnsupp'tedRedirectReceiveOptionsAccessFragRP62220136060122000500000000IPv6CEFPacketspassedontonextswitchinglayerSlotNo_adjNo_encapUnsupp'tedRedirectReceiveOptionsAccessMTURP00000000请使用这些命令验证值:showmlscefsummaryqshowmlscefmaximum-routesqBPDU风暴生成树在冗余交换网络和网桥网络中维护一个无环路的第2层环境.
没有STP,帧会无限循环并/或倍增.
这将导致网络崩溃,因为高流量将中断广播域中的所有设备.
在某些方面,STP最初是为基于软件的缓慢网桥规范(IEEE802.
1D)开发的早期协议,但是要在具有以下功能的大型交换网络中成功实施该协议,STP可能非常复杂:多个VLANqSTP域中的许多交换机q多供应商支持q较新的IEEE增强功能q如果网络面临频繁的生成树计算或交换机必须处理更多BPDU,则可能导致CPU使用率较高以及BPDU被丢弃.
为了解决这些问题,请执行下列步骤中的部分或全部:从交换机中删除部分VLAN.
1.
使用STP的增强版,如MST.
2.
升级交换机的硬件.
3.
另请参阅在网络中实施生成树协议(STP)的最佳实践.
运行CatOS配置和管理的Catalyst4500/4000、5500/5000和6500/6000系列交换机的最佳实践q运行CiscoIOS软件的Catalyst6500/6000系列和Catalyst4500/4000系列交换机的最佳实践qSPAN会话基于Catalyst6000/6500系列交换机的体系结构,SPAN会话不会影响交换机的性能,但是,如果SPAN会话中包括高流量/上行链路端口或EtherChannel,则它可能增加处理器上的负载.
如果它随后要选出一个特定VLAN,这还会增加更多工作量.
如果链路上存在不良数据流,这可能进一步增加工作量.
在某些情况下,RSPAN功能可能导致环路,并可能导致处理器上的负载激增.
有关详细信息,请参阅为何SPAN会话会产生桥接环路交换机可以像平常一样传递数据流,因为所有操作都在硬件中进行,但是如果它试图确定要发送哪个数据流,CPU可能难以承受.
建议只在必需时配置SPAN会话.
%CFIB-SP-STBY-7-CFIB_EXCEPTION:FIBTCAMexception,SomeentrieswillbesoftwareswitchedSwitch#showcefnot-cef-switchedCEFPacketspassedontonextswitchinglayerSlotNo_adjNo_encapUnsupp'tedRedirectReceiveOptionsAccessFragRP62220136060122000500000000IPv6CEFPacketspassedontonextswitchinglayerSlotNo_adjNo_encapUnsupp'tedRedirectReceiveOptionsAccessMTURP00000000当TCAM中的可用空间量被超出时,将收到此错误信息.
这将导致CPU使用率较高.
这是一个FIBTCAM限制.
一旦TCAM已满,便将设置一个标志,并将收到FIBTCAM异常错误.
这将停止向TCAM添加新的路由.
因此,所有数据流都将进行软件交换.
删除路由对恢复硬件交换没有帮助.
一旦TCAM进入异常错误状态,必须重新加载系统才能脱离该状态.
通过mlscefmaximum-routes命令可以增加TCAM中可以安装的最大路由数.
运行以高CPU的Catalyst6500/6000有IPv6ACL用L4端口Enable(event)MLSIPv6ACL压缩地址单播.
如果IPv6ACL在L4协议端口端口号,匹配此命令是需要的.
如果此命令没有启用,IPv6流量将被踢对软件处理的CPU.
默认情况下此命令没有配置.
铜缆SPF在CiscoME6500系列以太网交换机中,铜缆SFP比其他类型的SFP需要更多固件交互,这会使CPU使用率升高.
管理铜缆SFP的软件算法已在CiscoIOSSXH版本中改进.
模块化IOS在运行模块化IOS软件的CiscoCatalyst6500系列交换机中,正常CPU使用率稍大于非模块化IOS软件.
模块化IOS软件为每个活动付出的代价多于它为每个数据包付出的代价.
模块化IOS软件通过消耗特定的CPU来维护进程,即使没有多少数据包也是如此,因此CPU消耗并不基于实际数据流.
但是,当处理的数据包比率升高时,在模块化IOS软件中消耗的CPU不应多于在非模块化IOS软件中消耗的CPU.
检查CPU使用率如果CPU使用率较高,请先发出showprocessescpu命令.
输出显示交换机上的CPU使用率以及每个进程的CPU使用率.
Router#showprocessescpuCPUutilizationforfiveseconds:57%/48%;oneminute:56%;fiveminutes:48%PIDRuntime(ms)InvokeduSecs5Sec1Min5MinTTYProcess10500.
00%0.
00%0.
00%0ChunkManager2121806200.
00%0.
00%0.
00%0LoadMeter416453213717119940.
00%0.
21%0.
17%0Checkheaps50100.
00%0.
00%0.
00%0PoolManager!
---Outputissuppressed.
1720900.
00%0.
00%0.
00%0RPCaapi_rp17324391221714551129.
25%8.
11%7.
39%0SNMPENGINE174684631460.
00%0.
00%0.
00%0RPCpm-mp!
---Outputissuppressed.
在此输出中,总CPU使用率是57%,中断CPU使用率是48%.
此处,这些百分比以粗体文本显示.
由CPU进行的数据流中断交换将导致中断CPU使用率.
命令输出列出了导致两种使用率之间的差异的进程.
在本例中,原因是SNMP进程.
在运行CatOS的Supervisor引擎上,输出如下所示:Switch>(enable)showprocessescpuCPUutilizationforfiveseconds:99.
72%oneminute:100.
00%fiveminutes:100.
00%PIDRuntime(ms)InvokeduSecs5Sec1Min5MinTTYProcess-10000.
28%0.
00%0.
00%-2KernelandIdle2226110000.
00%0.
00%0.
00%-2FlashMIBUpdat30100.
00%0.
00%0.
00%-2L2L3IntHdlr40100.
00%0.
00%0.
00%-2L2L3PatchRev!
---Outputissuppressed.
61727295172025180000.
82%0.
00%0.
00%-2SptTimer6218185410371273610600022.
22%21.
84%21.
96%-2SptBpduRx63845683916911050000.
92%0.
00%0.
00%-2SptBpduTx在此输出中,第一个进程是KernelandIdle,它显示空闲CPU使用率.
通常,此进程显示的空闲CPU使用率较高,除非一些其他进程占用CPU周期.
在本示例中,SptBpduRx进程导致高CPU使用率.
如果CPU使用率较高是由于这些进程之一导致的,您可以排除故障并确定此进程导致高CPU使用率的原因.
但是,如果CPU较高是由于被转出到CPU的数据流导致的,则您需要确定数据流被转出的原因.
确定数据流被转出的原因可帮助您识别该数据流是什么.
对于排除故障,当您体验高CPU利用率时,请使用此EEM脚本示例为了从交换机收集输出:Switch>(enable)showprocessescpuCPUutilizationforfiveseconds:99.
72%oneminute:100.
00%fiveminutes:100.
00%PIDRuntime(ms)InvokeduSecs5Sec1Min5MinTTYProcess-10000.
28%0.
00%0.
00%-2KernelandIdle2226110000.
00%0.
00%0.
00%-2FlashMIBUpdat30100.
00%0.
00%0.
00%-2L2L3IntHdlr40100.
00%0.
00%0.
00%-2L2L3PatchRev!
---Outputissuppressed.
61727295172025180000.
82%0.
00%0.
00%-2SptTimer6218185410371273610600022.
22%21.
84%21.
96%-2SptBpduRx63845683916911050000.
92%0.
00%0.
00%-2SptBpduTx注意:当CPU是由于的高处理数据包交换而不是硬件时,调试netdr捕获rx命令是有用.
当命令运行时,它获取4096数据包流入对CPU.
命令是十分安全的并且是高CPU问题的最方便的工具在6500.
它不引起额外的负载CPU.
用于确定被传送到CPU的数据流的实用程序和工具本部分确定了可帮助您查看此数据流的一些实用程序和工具.
CiscoIOS系统软件在CiscoIOS软件中,Supervisor引擎上的交换处理器称为SP,MSFC称为RP.
showinterface命令提供有关接口状态和接口上数据流速率的基本信息.
此命令也提供错误计数器.
Router#showinterfacegigabitethernet4/1GigabitEthernet4/1isup,lineprotocolisup(connected)HardwareisC6k1000Mb802.
3,addressis000a.
42d1.
7580(bia000a.
42d1.
7580)Internetaddressis100.
100.
100.
2/24MTU1500bytes,BW1000000Kbit,DLY10usec,reliability255/255,txload1/255,rxload1/255EncapsulationARPA,loopbacknotsetKeepaliveset(10sec)Half-duplex,100Mb/sinputflow-controlisoff,outputflow-controlisoffClockmodeisautoARPtype:ARPA,ARPTimeout04:00:00Lastinput00:00:00,output00:00:00,outputhangneverLastclearingof"showinterface"countersneverInputqueue:5/75/1/24075(size/max/drops/flushes);Totaloutputdrops:2Queueingstrategy:fifoOutputqueue:0/40(size/max)30secondinputrate7609000bits/sec,14859packets/sec30secondoutputrate0bits/sec,0packets/secL2Switched:ucast:0pkt,184954624bytes-mcast:1pkt,500bytesL3inSwitched:ucast:2889916pkt,0bytes-mcast:0pkt,0bytesmcastL3outSwitched:ucast:0pkt,0bytesmcast:0pkt,0bytes2982871packetsinput,190904816bytes,0nobufferReceived9broadcasts,0runts,0giants,0throttles1inputerrors,1CRC,0frame,28overrun,0ignored0inputpacketswithdribbleconditiondetected1256packetsoutput,124317bytes,0underruns2outputerrors,1collisions,2interfaceresets0babbles,0latecollision,0deferred0lostcarrier,0nocarrier0outputbufferfailures,0outputbuffersswappedout在此输出中,可以看到传入数据流是在第3层交换的(而不是在第2层交换的).
这表明数据流被转出到CPU.
showprocessescpu命令告诉您这些数据包是常规数据流数据包还是控制数据包.
Router#showprocessescpu|exclude0.
00CPUutilizationforfiveseconds:91%/50%;oneminute:89%;fiveminutes:47%PIDRuntime(ms)InvokeduSecs5Sec1Min5MinTTYProcess588116079142111330.
49%0.
19%0.
16%0Checkheaps9812106430207044040.
53%38.
67%20.
59%0IPInput2452093368948282330.
08%0.
05%0.
02%0IFCOMMsgHdlr如果数据包是进程交换的,您会看到IPInputprocess的CPU使用率升高.
发出此命令可以看到以下数据包:showbuffersinput-interfaceRouter#showbuffersinput-interfacegigabitethernet4/1packetBufferinformationforSmallbufferat0x437874D4data_area0x8060F04,refcount1,next0x5006D400,flags0x280linktype7(IP),enctype1(ARPA),encsize14,rxtype1if_input0x505BC20C(GigabitEthernet4/1),if_output0x0(None)inputtime00:00:00.
000(elapsednever)outputtime00:00:00.
000(elapsednever),oqnumber65535datagramstart0x8060F7A,datagramsize60,maximumsize308mac_start0x8060F7A,addr_start0x8060F7A,info_start0x0network_start0x8060F88,transport_start0x8060F9C,caller_pc0x403519B4source:100.
100.
100.
1,destination:100.
100.
100.
2,id:0x0000,ttl:63,TOS:0prot:17,sourceport63,destinationport6308060F70:000A42D17580.
.
BQu.
08060F80:00000000111108004500002E00000000.
.
.
.
.
.
.
.
E.
.
.
.
.
.
.
08060F90:3F11EAF36464640164646402003F003F.
jsddd.
ddd.
.
.
08060FA0:001A261F000102030405060708090A0B08060FB0:0C0D0E0F101164.
.
.
.
.
.
d如果数据流是中断交换的,则使用showbuffersinput-interface命令无法看到这些数据包.
为了看到由于中断交换被转出到RP的数据包,可以执行RP端口的交换端口分析程序(SPAN)捕获.
注意:有关中断交换与进程交换CPU使用率的详细信息,请参阅以下文档:对Cisco路由器上的CPU使用率过高进行故障排除的由于中断而导致CPU使用率较高部分qSPANRP-Inband和SP-InbandCiscoIOS软件中用于RP或SP端口的SPAN在CiscoIOS软件版本12.
1(19)E及更高版本中可用.
以下是命令语法:testmonitorsession1-66add{rp-inband|sp-inband}[rx|tx|both]对于CiscoIOS软件12.
2SX版本,使用以下语法:testmonitoradd{1.
.
66}{rp-inband|sp-inband}{rx|tx|both}注意:对于SXH版本,必须使用monitorsession命令配置本地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]注意:有关这些命令的详细信息,请参阅Catalyst6500版本12.
2SX软件配置指南中的配置本地SPAN(SPAN配置模式).
以下是RP控制台上的一个示例:Router#monitorsession1sourceinterfacefast3/3!
---Useanyinterfacethatisadministrativelyshutdown.
Router#monitorsession1destinationinterface3/2现在,转到SP控制台.
示例如下:Router-sp#testmonitorsession1addrp-inbandrx注意:在CiscoIOS12.
2SX版本中,此命令已更改为testmonitoradd1rp-inbandrx.
Router#showmonitorSession1-Type:LocalSessionSourcePorts:Both:Fa3/3DestinationPorts:Fa3/2SPconsole:Router-sp#testmonitorsession1showIngressSourcePorts:3/315/1EgressSourcePorts:3/3IngressSourceVlans:EgressSourceVlans:FilterVlans:DestinationPorts:3/2注意:在CiscoIOS12.
2SX版本中,此命令已更改为testmonitorshow1.
以下是SP控制台上的一个示例:Router-sp#testmonitorsession1showIngressSourcePorts:3/315/1EgressSourcePorts:3/3IngressSourceVlans:EgressSourceVlans:FilterVlans:DestinationPorts:3/2CatOS系统软件对于运行CatOS系统软件的交换机,Supervisor引擎运行CatOS,MSFC运行CiscoIOS软件.
如果发出showmac命令,可以看到被转出到MSFC的帧的数量.
端口15/1是与MSFC的Supervisor引擎连接.
注意:端口16/1用于插槽2中的Supervisor引擎.
Console>(enable)showmac15/1PortRcv-UnicastRcv-MulticastRcv-Broadcast-15/119357601PortXmit-UnicastXmit-MulticastXmit-Broadcast-15/1300PortRcv-OctetXmit-Octet-15/1185833700MACDely-ExcedMTU-ExcedIn-DiscardOut-Discard--15/10-00此数字快速增加表明数据包被转出到MSFC,导致高CPU使用率.
然后您可以通过以下方式查看数据包:SPANMSFC端口15/1或16/1qSPANsc0qSPANMSFC端口15/1或16/1设置一个SPAN会话,其中源是MSFC端口15/1(或16/1),目标是以太网端口.
示例如下:Console>(enable)setspan15/15/10Console>(enable)showspanDestination:Port5/10AdminSource:Port15/1OperSource:NoneDirection:transmit/receiveIncomingPackets:disabledLearning:enabledMulticast:enabledFilter:-Status:active如果收集端口5/10上的嗅探器踪迹,嗅探器踪迹显示从MSFC传输的数据包和传输到MSFC的数据包.
将SPAN会话配置为tx以只捕获发往MSFC的数据包而不捕获来自MSFC的数据包.
SPANsc0设置一个以sc0接口作为源的SPAN会话,以捕获进入Supervisor引擎CPU的帧.
Console>(enable)setspandisableDisableportmonitoringsc0Setspanoninterfacesc0SourcemoduleandportnumbersSourceVLANnumbers注意:对于光服务模块(OSM),不能执行数据流SPAN捕获.
建议Supervisor引擎CPU使用率不反映交换机的硬件转发性能.
但是,仍必须以Supervisor引擎CPU使用率作为基线并对其进行监控.
以稳定状态网络中具有正常数据流模式和负载的交换机的Supervisor引擎CPU使用率作为基线.
请注意哪些进程导致最高的CPU使用率.
1.
在排除CPU使用率故障时,请考虑以下问题:哪些进程导致最高使用率这些进程是否与您的基线不同CPU使用率是否一直高于基线或者是否存在出现高使用率峰值,然后返回基线水平的情况网络中是否存在拓扑更改通知(TCN)注意:已禁用STPPortfast的抖动端口或主机端口将导致TCN.
管理子网/VLAN中是否存在过多的广播或多播数据流交换机上是否存在过多的管理数据流,如SNMP轮询2.
在高CPU时间期间(当CPU是75%以上)时,从这些命令请收集输出:showclockshowversion排序的showprocessescpushowproccpu历史记录showlog3.
如果可能,请从具有用户数据流(特别是大量广播数据流)的VLAN中分离出管理VLAN.
这种数据流类型的示例包括IPXRIP/服务通告协议(SAP)、AppleTalk和其他广播数据流.
此类数据流可能影响Supervisor引擎CPU使用率,并且在特殊情况下可能干扰交换机的正常运行.
4.
如果由于数据流被转出到RP而导致CPU使用率很高,请确定该数据流是什么以及该数据流为什么被转出.
为了进行此确定,请使用用于确定被传送到CPU的数据流的实用程序和工具部分介绍的实用程序.
5.
相关信息排除故障的高CPU有用的命令在有Sup720的Catalyst6500'sqCatalyst6000/6500系列交换机上常见的CatOS错误消息q运行CiscoIOS软件的Catalyst6500/6000系列交换机上常见的错误消息q排除运行CiscoIOS系统软件的Catalyst6500/6000系列交换机上的硬件和常见问题q交换式园区网络中的单播泛洪qCiscoCatalyst6500系列交换机产品支持q收集的数据EEM脚本在断断续续高CPU问题期间qLAN产品支持qLAN交换技术支持q技术支持和文档-CiscoSystemsq