關於High CPU及基本排查
阿新 • • 發佈：2018-11-29
隊列最大值 master auto oba 多次 配置 三層 show ast
One of the reasons that different ranges and models within those ranges will differ in the baseline utilization is differences in design. Where the earlier models of the switches with little usage of microcontrollers, the later ones do utilize these more. As more tasks are being offloaded to those microcontrollers there is an increase in communication between the CPU and the microcontrollers.
通過show processes cpu sorted命令，可以看到CPU在過去5秒，1分鐘，5分鐘的繁忙情況，也可以看到每個系統進程對CPU占用的百分比。
5%——告知CPU在最近5秒的繁忙情況，這個是活躍的系統進程CPU利用率的總量，包括了interrupt level的百分比。
0%——體現的是在最近5秒interrupt level的百分比占用情況。interrupt百分比是CPU花在從交換機硬件接收的數據包上的，該百分比總是小於等於總的CPU利用率。 2、識別並判斷high CPU 2.1 正常的high CPU
在一些情況下，正常的high CPU不會對網絡正常影響，我們可以通過show processes cpu history去查看過去60秒，60分鐘，以及72小時的CPU利用情況，你可以看到CPU的利用情況，以及是否存在突發情況。
在一些例子中，CPU飆升可能是一些已知的網絡事件，例如執行“write memory”、“A Large L2 Network”拓撲發生改變”、“IP路由表的更新”、“其他IOS命令”等。
大量的IP SLA監控會話，CPU會生成ICMP或者traceroute數據包；
SNMP輪詢活動，特別是MIB walk，Cisco IOS SNMP engine執行SNMP請求；
大量同時發出的DHCP請求；
ARP廣播風暴；
Ethernet廣播風暴。
2.2 通過high CPU正常的癥狀
high CPU會影響系統進程正常運行，當系統進程不執行時，交換機或直接連接的網絡設備會反映對網絡問題，對於L2網絡，可能會發生STP從新收斂，對於L3網絡，路由拓撲可能發生變化。
當交換機CPU high時可能出現的已知癥狀：
2.2.1、STP topo change：當二層網絡設備未在RP上及時收到STP BPDU時，它會將Root Switch的二層路徑視為down，並且交換機會嘗試查找新路徑，那麽STP將會重新收斂。
2.2.2、routing topo change：例如BGP路由震蕩或OSPF路由震蕩。
2.2.3、EtherChannel鏈路反彈：當EtherChannel另一端的網絡設備沒有收到維護EtherChannel鏈路所需的協議數據包時，這可能導致鏈路斷開。 2.2.4、交換機無法響應正常的管理請求：
輸入show platform port-asic stats drop 命令以查看CPU接收隊列丟棄計數並識別丟棄數據包的隊列。 此命令沒有show controllers cpu-interface命令那麽有用，因為輸出顯示接收隊列的數字而不是名稱，並且它僅顯示丟棄。 由於交換機硬件將CPU接收隊列丟棄的數據包視為發送給管理程序，因此丟棄的數據包在命令輸出中稱為Supervisor TxQueue Drop Statistics。 Switch #show platform port-asic stats drop Port-asic Port Drop Statistics - Summary ======================================== RxQueue Drop Statistics Slice0 RxQueue 0 Drop Stats Slice0: 0 RxQueue 1 Drop Stats Slice0: 0 RxQueue 2 Drop Stats Slice0: 0 RxQueue 3 Drop Stats Slice0: 0 RxQueue Drop Statistics Slice1 RxQueue 0 Drop Stats Slice1: 0 RxQueue 1 Drop Stats Slice1: 0 RxQueue 2 Drop Stats Slice1: 0 RxQueue 3 Drop Stats Slice1: 0 !<Output truncated> Port 27 TxQueue Drop Stats: 0 Supervisor TxQueue Drop Statistics Queue 0: 0 Queue 1: 0 Queue 2: 0 Queue 3: 0 Queue 4: 0 Queue 5: 0 Queue 6: 0 Queue 7: 0 Queue 8: 0 Queue 9: 0 Queue 10: 0 Queue 11: 0 Queue 12: 0 Queue 13: 0 Queue 14: 0 Queue 15: 0 ! <Output truncated> Supervisor TxQueue Drop Statistics的此輸出中的隊列號與show controllers cpu-interface命令輸出中的隊列名稱的順序相同。 例如，此輸出中的隊列0對應於前一輸出中的rpc;。 隊列15對應於cpu heartbeat，依此類推。
統計信息不會重置。 多次輸入命令以查看活動隊列丟棄。 命令輸出還顯示其他丟棄統計信息，其中一些在示例中被截斷。 其他輔助命令： A、您還可以使用show platform ip unicast statistics 來顯示有關已發送數據包的相同信息。 發送的IP數據包計為CPUAdj，在此示例中以粗體顯示。 Switch# show platform ip unicast statistics Global Stats: HWFwdLoc:0 HWFwdSec:0 UnRes:0 UnSup:0 NoAdj:0 EncapFail:0 CPUAdj:1344291253 Null:0 Drop:0 Prev Global Stats: HWFwdLoc:0 HWFwdSec:0 UnRes:0 UnSup:0 NoAdj:0 EncapFail:0 CPUAdj:1344291253 Null:0 Drop:0 這些統計信息每2到3秒更新一次。 多次輸入命令以查看CPUAdj計數的變化。 當CPUAdj計數快速遞增時，許多IP數據包將被轉發到CPU進行IP路由。 B、在第3層交換機上，硬件使用TCAM來容納IP路由數據庫。 用於第3層路由信息的TCAM空間是有限的。 當此空間已滿時，Cisco IOS學習的新路由無法編程到TCAM中。 如果交換機硬件接收的IP數據包具有不在TCAM中的目標IP地址，則硬件將IP數據包發送到CPU。 Switch# show platform tcam utilization CAM Utilization for ASIC# 0 Max Used Masks/Values Masks/values Unicast mac addresses: 6364/6364 31/31 IPv4 IGMP groups + multicast routes: 1120/1120 1/1 IPv4 unicast directly-connected routes: 6144/6144 4/4 IPv4 unicast indirectly-connected routes: 2048/2048 2047/2047 IPv4 policy based routing aces: 452/452 12/12 IPv4 qos aces: 512/512 21/21 IPv4 security aces: 964/964 30/30 Note: Allocation of TCAM entries per feature uses a complex algorithm. The above information is meant to provide an abstract view of the current TCAM utilization Cisco IOS從路由協議（例如BGP，RIP，OSPF，EIGRP和IS-IS）以及靜態配置的路由中學習路由。 您可以輸入show platform ip unicast counts 命令，以查看有多少這些路由未正確編程到TCAM中。 Switch# show platform ip unicast counts # of HL3U fibs 2426 # of HL3U adjs 4 # of HL3U mpaths 0 # of HL3U covering-fibs 0 # of HL3U fibs with adj failures 0 Fibs of Prefix length 0, with TCAM fails: 0 Fibs of Prefix length 1, with TCAM fails: 0 Fibs of Prefix length 2, with TCAM fails: 0 Fibs of Prefix length 3, with TCAM fails: 0 Fibs of Prefix length 4, with TCAM fails: 0 Fibs of Prefix length 5, with TCAM fails: 0 Fibs of Prefix length 6, with TCAM fails: 0 Fibs of Prefix length 7, with TCAM fails: 0 Fibs of Prefix length 8, with TCAM fails: 0 Fibs of Prefix length 9, with TCAM fails: 0 Fibs of Prefix length 10, with TCAM fails: 0 Fibs of Prefix length 11, with TCAM fails: 0 Fibs of Prefix length 12, with TCAM fails: 0 Fibs of Prefix length 13, with TCAM fails: 0 Fibs of Prefix length 14, with TCAM fails: 0 Fibs of Prefix length 15, with TCAM fails: 0 Fibs of Prefix length 16, with TCAM fails: 0 Fibs of Prefix length 17, with TCAM fails: 0 Fibs of Prefix length 18, with TCAM fails: 0 Fibs of Prefix length 19, with TCAM fails: 0 Fibs of Prefix length 20, with TCAM fails: 0 Fibs of Prefix length 21, with TCAM fails: 0 Fibs of Prefix length 22, with TCAM fails: 0 Fibs of Prefix length 23, with TCAM fails: 0 Fibs of Prefix length 24, with TCAM fails: 0 Fibs of Prefix length 25, with TCAM fails: 0 Fibs of Prefix length 26, with TCAM fails: 0 Fibs of Prefix length 27, with TCAM fails: 0 Fibs of Prefix length 28, with TCAM fails: 0 Fibs of Prefix length 29, with TCAM fails: 0 Fibs of Prefix length 30, with TCAM fails: 0 Fibs of Prefix length 31, with TCAM fails: 0 Fibs of Prefix length 32, with TCAM fails: 693 Fibs of Prefix length 33, with TCAM fails: 0 要查看每個路由協議使用的路由條目數，請輸入show ip route summary 命令。 Switch# show ip route summary IP routing table name is Default-IP-Routing-Table(0) IP routing table maximum-paths is 32 Route Source Networks Subnets Overhead Memory (bytes) connected 5 0 320 760 static 0 0 0 0 rip 0 2390 152960 363280 internal 1 1172 Total 6 2390 153280 365212 Switch# 參考：https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/troubleshooting/cpu_util.html#pgfId-999591
在實際的網絡中，總會存在設備出現high CPU的情況，這種情況下，往往會讓網絡管理員比較著急，因為如果CPU持續high，可能導致設備的性能降低，嚴重還可能導致設備down掉。
本篇記錄，主要記錄一下關於high CPU的一些基本知識以及排查的方法。
1、關於high CPU
當設備啟動完成後，CPU具有兩個不同的功能，其一，是在IOS下運行不同的進程（Process）；其二，是CPU從交換硬件中發送/接收報文進行處理。CPU同時執行這兩個功能。
不管是IOS Process占用了太多的CPU還是CPU從硬件收到太多的報文，都會導致CPU high，這兩者都會相互影響，例如，當CPU忙於處理收到的大量的報文，那麽可能導致IOS Process無法訪問CPU資源。
在正常情況下，在一些非堆疊的交換機上，CPU有一定的基線利用率，根據設備型號和類型，這個範圍可以從5%到40%（設備設計上的差異），如果交換機是堆疊的，那麽CPU的至少可以正常運行幾個百分點利用率，堆疊中的成員數量會對整體的CPU利用率產生影響
One of the reasons that different ranges and models within those ranges will differ in the baseline utilization is differences in design. Where the earlier models of the switches with little usage of microcontrollers, the later ones do utilize these more. As more tasks are being offloaded to those microcontrollers there is an increase in communication between the CPU and the microcontrollers.
通過show processes cpu sorted命令，可以看到CPU在過去5秒，1分鐘，5分鐘的繁忙情況，也可以看到每個系統進程對CPU占用的百分比。
Switch# show processes cpu sorted
CPU utilization for five seconds: 5%/0%; one minute: 6%; five minutes: 5% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 4539 89782 50 0.00% 0.00% 0.00% 0 Chunk Manager 2 1042 1533829 0 0.00% 0.00% 0.00% 0 Load Meter 3 0 1 0 0.00% 0.00% 0.00% 0 DiagCard3/-1 4 14470573 1165502 12415 0.00% 0.13% 0.16% 0 Check heaps 5 7596 212393 35 0.00% 0.00% 0.00% 0 Pool Manager 6 0 2 0 0.00% 0.00% 0.00% 0 Timers 7 0 1 0 0.00% 0.00% 0.00% 0 Image Licensing 8 0 2 0 0.00% 0.00% 0.00% 0 License Client N 9 1442263 25601 56336 0.00% 0.08% 0.02% 0 Licensing Auto U 10 0 1 0 0.00% 0.00% 0.00% 0 Crash writer 11 979720 2315501 423 0.00% 0.00% 0.00% 0 ARP Input 12 0 1 0 0.00% 0.00% 0.00% 0 CEF MIB API <output truncated> 如上輸出示例，在最近5秒的CPU利用率有兩個百分比（5%/0%）。5%——告知CPU在最近5秒的繁忙情況，這個是活躍的系統進程CPU利用率的總量，包括了interrupt level的百分比。
0%——體現的是在最近5秒interrupt level的百分比占用情況。interrupt百分比是CPU花在從交換機硬件接收的數據包上的，該百分比總是小於等於總的CPU利用率。 2、識別並判斷high CPU 2.1 正常的high CPU
在一些情況下，正常的high CPU不會對網絡正常影響，我們可以通過show processes cpu history去查看過去60秒，60分鐘，以及72小時的CPU利用情況，你可以看到CPU的利用情況，以及是否存在突發情況。
在一些例子中，CPU飆升可能是一些已知的網絡事件，例如執行“write memory”、“A Large L2 Network”拓撲發生改變”、“IP路由表的更新”、“其他IOS命令”等。
- A Large L2 Network”拓撲發生改變：STP的計算，實例越多，活躍的接口越多，越可能出現。
- IP路由表更新：更新的路由表越大，周期越頻繁，接收更新的路由協議進程數量，存在任何route map或者filters等情況都可能導致。
- IOS命令：show tech、write memory、show-running configuration、debug等命令
- 其他事件：
大量的IP SLA監控會話，CPU會生成ICMP或者traceroute數據包；
SNMP輪詢活動，特別是MIB walk，Cisco IOS SNMP engine執行SNMP請求；
大量同時發出的DHCP請求；
ARP廣播風暴；
Ethernet廣播風暴。
2.2 通過high CPU正常的癥狀
high CPU會影響系統進程正常運行，當系統進程不執行時，交換機或直接連接的網絡設備會反映對網絡問題，對於L2網絡，可能會發生STP從新收斂，對於L3網絡，路由拓撲可能發生變化。
當交換機CPU high時可能出現的已知癥狀：
2.2.1、STP topo change：當二層網絡設備未在RP上及時收到STP BPDU時，它會將Root Switch的二層路徑視為down，並且交換機會嘗試查找新路徑，那麽STP將會重新收斂。
2.2.2、routing topo change：例如BGP路由震蕩或OSPF路由震蕩。
2.2.3、EtherChannel鏈路反彈：當EtherChannel另一端的網絡設備沒有收到維護EtherChannel鏈路所需的協議數據包時，這可能導致鏈路斷開。 2.2.4、交換機無法響應正常的管理請求：
- ICMP ping 請求
- SNMP timeout
- Telnet或SSH會話很慢或不能建立
- UDLD flapping
- IP SLAs failures
- DHCP或802.1x failures
- 丟包或者延遲增加
- HSRP flapping
2.3 確定中斷百分比
CPU利用率歷史記錄僅顯示隨時間變化的總CPU利用率。它不顯示中斷所花費的CPU時間。了解中斷所花費的時間對於確定CPU利用率的原因至關重要。 CPU利用率歷史記錄顯示CPU何時持續接收網絡數據包，但未顯示原因。
輸入Cisco IOS設備輸入show processes cpu sorted 5sec 命令以顯示當前CPU利用率以及哪些IOS進程占用的CPU時間最多。正常情況下，中斷百分比大於0％且小於5％。中斷百分比可以在5％到10％之間。應調查超過10％的中斷百分比。
在三層交換機上，當IP route未知時，交換機硬件將會把IP數據包發送到CPU進行IP routing，發送的數據包會在interrupt level處理，並且會導致CPU繁忙。 如果命令輸出中顯示的中斷百分比很高，但是最活躍的進程不是上表中所示的那些，或者沒有任何進程看起來足夠有效證明CPU利用率，那麽高CPU利用率很可能是由於被發送到CPU的數據包引起的，示例輸出中顯示。
Switch# show processes cpu sorted 5sec
CPU utilization for five seconds: 53%/28%; one minute: 48%; five minutes: 45% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 78 461805 220334990 2 11.82% 11.53% 10.37% 0 HLFM address lea 309 99769798 1821129 54784 5.27% 1.53% 1.39% 0 RIP Timers 192 19448090 72206697 269 1.11% 0.87% 0.81% 0 Spanning Tree 250 25992246 58973371 440 0.63% 0.27% 0.29% 0 RIP Router 99 6853074 11856895 577 0.31% 0.46% 0.44% 0 hpm counter proc 131 3184794 210112491 15 0.31% 0.13% 0.12% 0 Hulc LED Process 140 20821662 11950171 1742 0.31% 0.28% 0.26% 0 HRPC qos request 139 3166446 1498429 2113 0.15% 0.11% 0.11% 0 HQM Stack Proces 67 2809714 11642483 241 0.15% 0.03% 0.00% 0 hrpc <- response 223 449344 16515401 27 0.15% 0.03% 0.00% 0 Marvell wk-a Pow 10 0 1 0 0.00% 0.00% 0.00% 0 Crash writer 11 227226 666257 341 0.00% 0.00% 0.00% 0 ARP Input !<Output truncated> 表2列出了CPU忙於處理被發送到CPU的數據包時最活躍的系統進程，punted packets的CPU進程和列出的進程無關。
監視CPU接收隊列的數據包計數
如果交換機被特定數據包類型泛洪，則硬件會將該數據包類型放入適當的CPU隊列並對其進行計數。 輸入show controllers cpu-interface 命令以查看每個隊列的數據包計數。
Switch # show controllers cpu-interface
ASIC Rxbiterr Rxunder Fwdctfix Txbuflos Rxbufloc Rxbufdrain ------------------------------------------------------------------------- ASIC0 0 0 0 0 0 0 ASIC1 0 0 0 0 0 0 cpu-queue-frames retrieved dropped invalid hol-block stray ----------------- ---------- ---------- ---------- ---------- ---------- rpc 726325 0 0 0 0 stp 16108 0 0 0 0 ipc 56771 0 0 0 0 routing protocol 3949 0 0 0 0 L2 protocol 827 0 0 0 0 remote console 58 0 0 0 0 sw forwarding 0 0 0 0 0 host 0 0 0 0 0 broadcast 382 0 0 0 0 cbt-to-spt 0 0 0 0 0 igmp snooping 3567 0 0 0 0 icmp 11256 0 0 0 0 logging 0 0 0 0 0 rpf-fail 0 0 0 0 0 dstats 0 0 0 0 0 cpu heartbeat 322409 0 0 0 0 <output truncated> 交換機還會計算由於擁塞而丟棄的CPU-bound數據包。 每個CPU接收隊列都具有最大數據包計數。 當達到接收隊列最大值時，交換機硬件會丟棄發往擁塞隊列的數據包。 交換機為每個隊列計算丟棄的數據包。 特定CPU隊列的丟棄計數增加意味著該隊列的使用率很高。輸入show platform port-asic stats drop 命令以查看CPU接收隊列丟棄計數並識別丟棄數據包的隊列。 此命令沒有show controllers cpu-interface命令那麽有用，因為輸出顯示接收隊列的數字而不是名稱，並且它僅顯示丟棄。 由於交換機硬件將CPU接收隊列丟棄的數據包視為發送給管理程序，因此丟棄的數據包在命令輸出中稱為Supervisor TxQueue Drop Statistics。 Switch #show platform port-asic stats drop Port-asic Port Drop Statistics - Summary ======================================== RxQueue Drop Statistics Slice0 RxQueue 0 Drop Stats Slice0: 0 RxQueue 1 Drop Stats Slice0: 0 RxQueue 2 Drop Stats Slice0: 0 RxQueue 3 Drop Stats Slice0: 0 RxQueue Drop Statistics Slice1 RxQueue 0 Drop Stats Slice1: 0 RxQueue 1 Drop Stats Slice1: 0 RxQueue 2 Drop Stats Slice1: 0 RxQueue 3 Drop Stats Slice1: 0 !<Output truncated> Port 27 TxQueue Drop Stats: 0 Supervisor TxQueue Drop Statistics Queue 0: 0 Queue 1: 0 Queue 2: 0 Queue 3: 0 Queue 4: 0 Queue 5: 0 Queue 6: 0 Queue 7: 0 Queue 8: 0 Queue 9: 0 Queue 10: 0 Queue 11: 0 Queue 12: 0 Queue 13: 0 Queue 14: 0 Queue 15: 0 ! <Output truncated> Supervisor TxQueue Drop Statistics的此輸出中的隊列號與show controllers cpu-interface命令輸出中的隊列名稱的順序相同。 例如，此輸出中的隊列0對應於前一輸出中的rpc;。 隊列15對應於cpu heartbeat，依此類推。
統計信息不會重置。 多次輸入命令以查看活動隊列丟棄。 命令輸出還顯示其他丟棄統計信息，其中一些在示例中被截斷。 其他輔助命令： A、您還可以使用show platform ip unicast statistics 來顯示有關已發送數據包的相同信息。 發送的IP數據包計為CPUAdj，在此示例中以粗體顯示。 Switch# show platform ip unicast statistics Global Stats: HWFwdLoc:0 HWFwdSec:0 UnRes:0 UnSup:0 NoAdj:0 EncapFail:0 CPUAdj:1344291253 Null:0 Drop:0 Prev Global Stats: HWFwdLoc:0 HWFwdSec:0 UnRes:0 UnSup:0 NoAdj:0 EncapFail:0 CPUAdj:1344291253 Null:0 Drop:0 這些統計信息每2到3秒更新一次。 多次輸入命令以查看CPUAdj計數的變化。 當CPUAdj計數快速遞增時，許多IP數據包將被轉發到CPU進行IP路由。 B、在第3層交換機上，硬件使用TCAM來容納IP路由數據庫。 用於第3層路由信息的TCAM空間是有限的。 當此空間已滿時，Cisco IOS學習的新路由無法編程到TCAM中。 如果交換機硬件接收的IP數據包具有不在TCAM中的目標IP地址，則硬件將IP數據包發送到CPU。 Switch# show platform tcam utilization CAM Utilization for ASIC# 0 Max Used Masks/Values Masks/values Unicast mac addresses: 6364/6364 31/31 IPv4 IGMP groups + multicast routes: 1120/1120 1/1 IPv4 unicast directly-connected routes: 6144/6144 4/4 IPv4 unicast indirectly-connected routes: 2048/2048 2047/2047 IPv4 policy based routing aces: 452/452 12/12 IPv4 qos aces: 512/512 21/21 IPv4 security aces: 964/964 30/30 Note: Allocation of TCAM entries per feature uses a complex algorithm. The above information is meant to provide an abstract view of the current TCAM utilization Cisco IOS從路由協議（例如BGP，RIP，OSPF，EIGRP和IS-IS）以及靜態配置的路由中學習路由。 您可以輸入show platform ip unicast counts 命令，以查看有多少這些路由未正確編程到TCAM中。 Switch# show platform ip unicast counts # of HL3U fibs 2426 # of HL3U adjs 4 # of HL3U mpaths 0 # of HL3U covering-fibs 0 # of HL3U fibs with adj failures 0 Fibs of Prefix length 0, with TCAM fails: 0 Fibs of Prefix length 1, with TCAM fails: 0 Fibs of Prefix length 2, with TCAM fails: 0 Fibs of Prefix length 3, with TCAM fails: 0 Fibs of Prefix length 4, with TCAM fails: 0 Fibs of Prefix length 5, with TCAM fails: 0 Fibs of Prefix length 6, with TCAM fails: 0 Fibs of Prefix length 7, with TCAM fails: 0 Fibs of Prefix length 8, with TCAM fails: 0 Fibs of Prefix length 9, with TCAM fails: 0 Fibs of Prefix length 10, with TCAM fails: 0 Fibs of Prefix length 11, with TCAM fails: 0 Fibs of Prefix length 12, with TCAM fails: 0 Fibs of Prefix length 13, with TCAM fails: 0 Fibs of Prefix length 14, with TCAM fails: 0 Fibs of Prefix length 15, with TCAM fails: 0 Fibs of Prefix length 16, with TCAM fails: 0 Fibs of Prefix length 17, with TCAM fails: 0 Fibs of Prefix length 18, with TCAM fails: 0 Fibs of Prefix length 19, with TCAM fails: 0 Fibs of Prefix length 20, with TCAM fails: 0 Fibs of Prefix length 21, with TCAM fails: 0 Fibs of Prefix length 22, with TCAM fails: 0 Fibs of Prefix length 23, with TCAM fails: 0 Fibs of Prefix length 24, with TCAM fails: 0 Fibs of Prefix length 25, with TCAM fails: 0 Fibs of Prefix length 26, with TCAM fails: 0 Fibs of Prefix length 27, with TCAM fails: 0 Fibs of Prefix length 28, with TCAM fails: 0 Fibs of Prefix length 29, with TCAM fails: 0 Fibs of Prefix length 30, with TCAM fails: 0 Fibs of Prefix length 31, with TCAM fails: 0 Fibs of Prefix length 32, with TCAM fails: 693 Fibs of Prefix length 33, with TCAM fails: 0 要查看每個路由協議使用的路由條目數，請輸入show ip route summary 命令。 Switch# show ip route summary IP routing table name is Default-IP-Routing-Table(0) IP routing table maximum-paths is 32 Route Source Networks Subnets Overhead Memory (bytes) connected 5 0 320 760 static 0 0 0 0 rip 0 2390 152960 363280 internal 1 1172 Total 6 2390 153280 365212 Switch# 參考：https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/troubleshooting/cpu_util.html#pgfId-999591
關於High CPU及基本排查