[计算机]通过交换机showproccpu的命令输出的信息可以看到.docVIP

通过交换机 show proc cpu的命令输出的信息可以看到：在5秒、1分钟、5分钟内 Cat4k Mgmt LoPri进程的CPU占用率分别为 91.69% 92.18% 92.23%显然是这个进程消耗了大量的CPU运行资源，从而导致交换机没有新的资源处理新的请求。处理器运行两个进程，Cat4k Mgmt HiPri和Cat4k Mgmt LoPri，这两个进程同其他进程一样要占用cpu时间。当Cat4k平台上某项进程占用cpu超出了应分配的cpu时间，Cat4k Mgmt LoPri会接管这项进程，使其他进程能够得到cpu时间。同样当某个进程占用cpu时间没有超过规定的cpu利用率，Cat4k Mgmt HiPri会接管这个进程。而Cat4k Mgmt LoPri进程CPU占用率超过90%，我们判断一定是某一个进程大大超过了CPU应分配的时间，而Cat4k Mgmt LoPri进程试图接管这一进程，而导致了Cat4k Mgmt LoPri 进程的CPU占用时间超过了90%。根据这一思路只要我们找出这个进程，将其关闭或找出这个进程的作用，就可以解决这个问题并能够找出CPU占用率过高的原因。show proc cpuCPU utilization for five seconds: 99%/0%; one minute: 99%; five minutes: 99%24 1716 91507 180.00%0.00%0.00% 0 Net Background 25 0 5 00.00%0.00%0.00% 0 Logger 26 716 109117 60.00%0.00%0.00% 0 TTY Background 27 2072 111013 180.00%0.00%0.00% 0 Per-Second Jobs28 38292 1947 196670.00%0.04%0.00% 0 Per-minute Jobs29 2858508 8807360 3244.63%3.81%3.72% 0 Cat4k Mgmt HiPri30 8437156467467994 1250 91.69% 92.18% 92.23% 0 Cat4k Mgmt LoPri31 260 49358 50.00%0.00%0.00% 0 Galios Reschedul32 0 2 00.00%0.00%0.00% 0 IOS ACL Helper通过show platform health 命令进一步更为详细的检查Catalyst 4506交换机的进程我们发现K2CpuMan Review进程有异常， 如下：show pla heaKxAclPathMan reprogr 1.00 0.00 2 1100500 0 0 00:00TagMan-RecreateMtegR 1.00 0.00 10 5100500 0 0 00:00K2CpuMan Review 30.0069.84 30 26100500112 106 781248:14K2AccelPacketMan: Tx10.00 2.74 20 0100500 1212 10254:45K2AccelPacketMan: Au 0.10 0.00 0 0100500 0 0 00:00K2AclMan-taggedFlatA 1.00 0.00 10 5100500 0 0 00:00IOS软件设计的K2CpuMan Review进程CPU占用率最高为30% 而实际却为69.84，大大超过了软件当初设计得阀值，而其他的进程都在软件设计的设定的范围之内，因此我们可以初步判断是K2CpuMan Review 进程出现了意外，致使CPU的管理进程Cat4k Mgmt LoPri试图接管这一进程，而最终导致交换机CPU占用率过高，导致资源的最终耗尽。从而影响了整个网络运行的稳定性。 通过Cisco提供的文档来看，K2CpuMan Review进程主要处理“Hit”CPU的数据包，Catalyist 4506交换方式是CEF,并不是过程交换，在正常的情况下除设备管理、监测、路由计算外，数据包的转发主要由交换引擎来完成，并不需要CPU作过多的处理。K2CpuMan Review占用的CPU资源过多，但各接口的流量并没有明显增大，显然不是正常的负载过重导致，一定是很多异常的数据包Hit了CPU,为了查清楚 CPU受到的异常数据包性质。我们通过命令：Monitor session 1 soure interface cpuMonitor session 1 desinterfacegi 3/8?把CPU收到的数据包镜像到了gi 3/8端口，然后在gi 3/8端口接上装有Sniffer和omnipeek等数据分析软件的计算机。bright.wang2006-10-20, 14:52你可能有默认路由，建设去掉看一下CPU利用率是否正常？还可以用sh int | i protocol | rate | broadcasts看一下哪个端口收发包较多？shoudown后看CPU利用率是否正常？chinese_xieshj2006-10-20, 15:55直接重起xdzdy2006-10-20, 16:15这个问题我前几天看到过，而且让CISCO TAC开了CASE，TAC说这是正常的，是C4K正常的现象，具体信息参考附件，谢谢！如果C4K上的某个interface突然数据传输激增，或者端口在短时间内出现大量的错误激增，就会造成这个现象。marco_myw2006-10-20, 17:26我遇到过的有两种情况，1是交换机接到大量的错误包的时候，show ip traffic 看看，如果有很多bad hop 的话，那就是这个愿意，还有就是病毒，常见的几个sql下的蠕虫病毒都会造成这个现象。刚处理过一次C4506交换机CPU利用率过高（1）通过交换机 show proc cpu的命令输出的信息可以看到：在5秒、1分钟、5分钟内 Cat4k Mgmt LoPri进程的CPU占用率分别为 91.69% 92.18% 92.23%显然是这个进程消耗了大量的CPU运行资源，从而导致交换机没有新的资源处理新的请求。处理器运行两个进程，Cat4k Mgmt HiPri和Cat4k Mgmt LoPri，这两个进程同其他进程一样要占用cpu时间。当Cat4k平台上某项进程占用cpu超出了应分配的cpu时间，Cat4k Mgmt LoPri会接管这项进程，使其他进程能够得到cpu时间。同样当某个进程占用cpu时间没有超过规定的cpu利用率，Cat4k Mgmt HiPri会接管这个进程。而Cat4k Mgmt LoPri进程CPU占用率超过90%，我们判断一定是某一个进程大大超过了CPU应分配的时间，而Cat4k Mgmt LoPri进程试图接管这一进程，而导致了Cat4k Mgmt LoPri 进程的CPU占用时间超过了90%。根据这一思路只要我们找出这个进程，将其关闭或找出这个进程的作用， .Cat4k Mgmt LoPri 进程占用CPU过高,有很多原因.IPX or AppleTalk Routing Host LearningOut of Hardware Resources (TCAM) for Security ACLThe log Keyword in ACL这些都可以显示特征是Cat4k Mgmt LoPri .以host learning为例:Step 1: Check for the Cisco IOS process with the show processes cpu command. Issue the show processes cpu command in order to check which Cisco IOS process consumes the CPU. In this command output, notice that the top process is the Cat4k Mgmt LoPri :Switch# show processes cpu CPU utilization for five seconds: 89%/1%; one minute: 74%; five minutes: 71%PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 4 53 750.00%0.00%0.00% 0 Chunk Manager !- Output suppressed.25 8008 1329154 60.00%0.00%0.00% 0 Per-Second Jobs26 413128 38493 107320.00%0.02%0.00% 0 Per-minute Jobs27 148288424 354390017 41826.47% 10.28% 10.11%0 Cat4k Mgmt HiPri 28 285796820 720618753 396 52.71% 56.79% 55.70% 0 Cat4k Mgmt LoPriStep 2: Check for the Catalyst 4500-specific process with the show platform health command. The output of the show platform health command confirms the use of the CPU in order to process CPU-bound packets. Switch# show platform health %CPU %CPU RunTimeMax PriorityAverage %CPUTotal Target Actual Target Actual Fg Bg 5Sec Min HourCPU!- Output suppressed.TagMan-RecreateMtegR 1.00 0.00 10 4100500 0 0 00:00K2CpuMan Review 30.0046.88 30 47100500 3029 21265:01K2AccelPacketMan: Tx10.00 8.03 20 0100500 2129 26270:4Step 3: Check the CPU queue that receives traffic in order to identify the type of CPU-bound traffic. In order to determine the type of traffic that hits the CPU, issue the show platform cpu packet statistics command.Switch# show platform cpu packet statistics!- Output suppressed.Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg- - - - - -Esmp 48613268 38 39 38 39Control 142166648 74 74 73 73Host Learning 1845568 1328 1808 1393 1309L3 Fwd High 17 0 0 0 0L3 Fwd Medium 2626 0 0 0 0L3 Fwd Low 1582414 1 1 1 1L2 Fwd Medium 1 0 0 0 0L2 Fwd Low 576905398 37 7 8 5L3 Rx High 257147 0 0 0 0L3 Rx Low 5325772 10 19 13 7RPF Failure 155 0 0 0 0ACL fwd(snooping) 65604591 53 54 54 53ACL log, unreach 11013420 9 8 8 8更详细的请参考:/en/US/produ . 86a00804cef15.shtmlshow platform cpu packet statistics显示的是什么信息?在交换机上提示没这命令?C4006#sh verCisco Internetwork Operating System SoftwareIOS (tm) Catalyst 4000 L3 Switch Software (cat4000-IS-M), Version 12.1(8a)EW1, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)TAC Support: /tacCopyright (c) 1986-2002 by cisco Systems, Inc.Compiled Wed 20-Feb-02 18:02 by eaarmasROM: 12.1(12r)EWC4006-5F uptime is 4 days, 8 hours, 7 minutesSystem returned to ROM by reloadSystem image file is bootflash:cat4000-is-mz.121-8a.EW1.bincisco WS-C4006 (MPC8245) processor (revision 7) with 262144K bytes of memory.Last reset from Reload32 FastEthernet/IEEE 802.3 interface(s)10 Gigabit Ethernet/IEEE 802.3 interface(s)467K bytes of non-volatile configuration memory.Configuration register is 0x2102xigang4506# show platform cpu pa stPackets Dropped In Hardware By CPU Subport (txQueueNotAvail)一般4500些列CPU高，在cisco文档中都有典型的描述，排障方法一般现就是三条命令，判断是STP问题，还是ACL问题，还是ACL LOG(keyword),还是广播/ARP问题，基本有个定论；更加可以使用CPU SPAN来分析或在高版本中使用debug platform cpu packet buffer来分析。但是在这次我排障中发现基本不是ARP问题，也不是病毒问题。而是出现了ACL FWD(SNOOPING)数很大，在典型案例中就没有出现这种，很是郁闷。问题：NATIVE VLAN和ACL FWD（snooping）有什么关系呢？你的cpu实在太厉害了。呵呵。给你看一个文档先Catalyst4500交换机CPU利用率高的原因解释环境 Cisco Catalyst4500交换机，使用Supervisor Engines III and IV.问题 Cisco Catalyst4500交换机(Supervisor Engines III and IV)，CPU出现短时90%利用率，其中Cat4k Mgmt LoPr进程占用CPU较高，请解释一下原因？解答 Catalyst4500系列交换机(Supervisor Engines III and IV),运行IOS操作系统，其中命令show process cpu会显示信息如下：W2S-2.8-c4503-A# show processes cpuCPU utilization for five seconds: 97%/2%; one minute: 98%; five minutes: 75%PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process!- Output suppressed.24 360 597068 0 0.00% 0.00% 0.00% 0 Per-Second Jobs25 9029996 47494839 190 2.12% 2.24% 2.48% 0 Cat4k Mgmt HiPri26 5537468 32351753 171 60.09% 63.97% 48.63% 0 Cat4k Mgmt LoPri27 20 32800 0 0.00% 0.00% 0.00% 0 Galios Reschedul!- Output suppressed.38 0 9954 0 0.00% 0.00% 0.00% 0 Port-Security39 133824 66958 1998 32.58% 31.87% 23.30% 0 IP Input40 13292 111414 119 0.00% 0.00% 0.00% 0 CDP Protocol!- Output suppressed.处理器运行两个进程，Cat4k Mgmt HiPri和Cat4k Mgmt LoPri，这两个进程同其他进程一样要占用cpu时间。当Cat4k平台上某项进程占用cpu超出了应分配的cpu时间，Cat4k Mgmt LoPri会接管这项进程，使其他进程能够得到cpu时间。同样当某个进程占用cpu时间没有超过规定的cpu利用率，Cat4k Mgmt HiPri会接管这个进程。 本帖最后由 totle 于 2005-10-8 09:26 PM 编辑ip input 是路由器使用cpu进行process switch的。当cef关闭，或者其他的快速交换的方式关闭了，那么海量的数据包都要通过中央cpu来处理，可能会消耗很多的资源。另外就是病毒或者攻击导致你的缓存中没有match的条目，也会进行process switch。arp input举个例子，就是你的缺省路由指向了一个广播接口，那么大量的数据包会产生很多arp的请求，建议指定下一跳的IP地址。#sh plat cpu pack stat allPackets Dropped In Hardware By CPU Subport (txQueueNotAvail)CPU SubportTxQueue 0 TxQueue 1 TxQueue 2 TxQueue 3- - - - - 0 0 0 0 579682309 1 0 2472798 0 0 2 0 0 0 0 3 0 0 0 0 4 0 0 0 0 5 0 0 0 0 6 0 0 0 54 7 0 0 0 0Packets Enqueued OverallTotal 5 sec avg 1 min avg 5 min avg 1 hour avg- - - - - 0 0 0 0 0Packets Not Enqueued OverallTotal 5 sec avg 1 min avg 5 min avg 1 hour avg- - - - -More- 0 0 0 0 0Packets Dropped In Processing OverallTotal 5 sec avg 1 min avg 5 min avg 1 hour avg- - - - - 57397139 5 5 5 5Packets Not Enqueued by CPU eventEvent Total 5 sec avg 1 min avg 5 min avg 1 hour avg- - - - - -Control Packet 0 0 0 0 0Input Acl 0 0 0 0 0RPF Fail 0 0 0 0 0Adjacency Same If 0 0 0 0 0L3 Forward 0 0 0 0 0NFL Copy To CPU 0 0 0 0 0Output Acl 0 0 0 0 0MTU Check Fail 0 0 0 0 0SA Miss 0 0 0 0 0L2 Forward 0 0 0 0 0SPAN 0 0 0 0 0-More- CPU Generated 0 0 0 0 0Unknown 0 0 0 0 0Packets Dropped In Processing by CPU eventEvent Total 5 sec avg 1 min avg 5 min avg 1 hour avg- - - - - -Control Packet 8506735 0 0 0 0Input Acl 48889041 4 5 4 4RPF Fail 0 0 0 0 0Adjacency Same If 0 0 0 0 0L3 Forward 0 0 0 0 0NFL Copy To CPU 0 0 0 0 0Output Acl 0 0 0 0 0MTU Check Fail 0 0 0 0 0SA Miss 1363 0 0 0 0L2 Forward 0 0 0 0 0SPAN 0 0 0 0 0CPU Generated 0 0 0 0 0Unknown 0 0 0 0 0Packets Not Enqueued by Priority-More- Priority Total 5 sec avg 1 min avg 5 min avg 1 hour avg- - - - - -Unknown 0 0 0 0 0Normal 0 0 0 0 0Medium 0 0 0 0 0High 0 0 0 0 0Crucial 0 0 0 0 0Super Crucial 0 0 0 0 0Packets Dropped In Processing by PriorityPriority Total 5 sec avg 1 min avg 5 min avg 1 hour avg- - - - - -Unknown 0 0 0 0 0Normal 1279945 0 0 0 0Medium 1363 0 0 0 0High 47609096 4 5 4 4Crucial 8506735 0 0 0 0Super Crucial 0 0 0 0 0Packets Not Enqueued by ReasonReason Total 5 sec avg 1 min avg 5 min avg 1 hour avg-More- - - - - - -RxQueueNotAvail 0 0 0 0 0RxNoBuffersAvail 0 0 0 0 0RxBadCpuEvent 0 0 0 0 0Testing 0 0 0 0 0Packets Dropped In Processing by ReasonReason Total 5 sec avg 1 min avg 5 min avg 1 hour avg- - - - - -BadPddType 0 0 0 0 0VlanZeroBadCrc 0 0 0 0 0VlanZeroGoodCrc 0 0 0 0 0NoPimPhyportMap 0 0 0 0 0NoPimPhyport 0 0 0 0 0UnimplementedEvt 0 0 0 0 0SrcAddrTableFilt 1318 0 0 0 0STPDrop 5325812 0 0 0 0UnknownLayer1 0 0 0 0 0UnknownLayer2 0 0 0 0 0DstEn