Risoluzione dei problemi di utilizzo elevato della CPU dello switch Catalyst serie 3850

Introduzione

In questo documento viene descritto come risolvere i problemi relativi all'utilizzo della CPU, principalmente a causa di interrupt, sulla nuova piattaforma Cisco IOS^® XE. 

Premesse

È importante comprendere come è stato costruito Cisco IOS® XE. Con Cisco IOS® XE, Cisco è passato a un kernel Linux e tutti i sottosistemi sono stati suddivisi in processi. Tutti i sottosistemi precedentemente presenti in Cisco IOS, ad esempio i driver dei moduli, l'alta disponibilità (HA, High Availability) e così via, vengono ora eseguiti come processi software nel sistema operativo Linux. Cisco IOS funziona come un daemon all'interno del sistema operativo Linux (IOSd).Cisco IOS® XE conserva non solo lo stesso aspetto del classico sistema Cisco IOS®, ma anche il suo funzionamento, supporto e gestione.

Inoltre, il documento introduce diversi nuovi comandi su questa piattaforma che sono integrali per risolvere i problemi di utilizzo della CPU.

Di seguito sono riportate alcune definizioni utili:

• Driver del motore di inoltro (FED): questo è il cuore dello switch Cisco Catalyst serie 3850 ed è responsabile di tutta la programmazione/inoltro hardware.
  
  
• Cisco IOSd: questo è il daemon Cisco IOS® in esecuzione sul kernel Linux. Viene eseguito come processo software all'interno del kernel.
  
  
• Packet Delivery System (PDS): si tratta dell'architettura e del processo con cui i pacchetti vengono consegnati da e verso vari sottosistemi. Ad esempio, controlla il modo in cui i pacchetti vengono consegnati dalla FED all'IOSd e viceversa.
  
  
• Handle: un handle può essere considerato come un puntatore. È un mezzo per scoprire informazioni più dettagliate sulle variabili specifiche utilizzate negli output prodotti dalla casella. Questa procedura è simile al concetto di indici LTL (Local Target Logic) sugli switch Cisco Catalyst serie 6500.

Caso di studio: Address Resolution Protocol (ARP) Interrupts

Il processo di risoluzione dei problemi e di verifica descritto in questa sezione può essere ampiamente utilizzato per un elevato utilizzo della CPU a causa di interruzioni.

Passaggio 1: Identificare il processo che utilizza i cicli della CPU

Il comando show process cpu visualizza naturalmente l'aspetto corrente della CPU. Notare che gli switch Cisco Catalyst serie 3850 usano quattro core e l'utilizzo della CPU è elencato per tutti e quattro i core:

3850-2#show processes cpu sorted | exclude 0.0
Core 0: CPU utilization for five seconds: 53%; one minute: 39%;  five minutes: 41%
Core 1: CPU utilization for five seconds: 43%; one minute: 57%;  five minutes: 54%
Core 2: CPU utilization for five seconds: 95%; one minute: 60%;  five minutes: 58%
Core 3: CPU utilization for five seconds: 32%; one minute: 31%;  five minutes: 29%
PID    Runtime(ms) Invoked  uSecs  5Sec     1Min     5Min     TTY   Process
8525   472560      2345554  7525   31.37    30.84    30.83    0     iosd
5661   2157452     9234031  698    13.17    12.56    12.54    1088  fed
6206   19630       74895    262    1.83     0.43     0.10     0     eicored
6197   725760      11967089 60     1.41     1.38     1.47     0     pdsd

Dall'output, è chiaro che il daemon di Cisco IOS® consuma una parte importante della CPU insieme al FED, che è il cuore di questo box. Quando l'utilizzo della CPU è elevato a causa di interruzioni, Cisco IOSd e FED utilizzano la maggior parte della CPU e questi sottoprocessi (o un sottoinsieme di essi) utilizzano la CPU:

• FED Punject TX
• FED Punject RX
• Rifornimento perforato FED
• Trasmissione puntiforme FED completata

È possibile eseguire lo zoom avanti su uno qualsiasi di questi processi con il comando show process cpu detailed <process>. Poiché Cisco IOSd è responsabile della maggior parte dell'utilizzo della CPU, di seguito vengono fornite alcune informazioni più dettagliate.

3850-2#show processes cpu detailed process iosd sorted | ex 0.0
Core 0: CPU utilization for five seconds: 36%; one minute: 39%; five minutes: 40%
Core 1: CPU utilization for five seconds: 73%; one minute: 52%; five minutes: 53%
Core 2: CPU utilization for five seconds: 22%; one minute: 56%; five minutes: 58%
Core 3: CPU utilization for five seconds: 46%; one minute: 40%; five minutes: 31%
PID    T C  TID   Runtime(ms)Invoked uSecs 5Sec   1Min   5Min  TTY  Process
                                            (%)    (%)    (%)
8525   L          556160     2356540 7526  30.42   30.77  30.83  0   iosd
8525   L 1  8525  712558     284117  0     23.14   23.33  23.38  0   iosd
59     I          1115452    4168181 0     42.22   39.55  39.33  0   ARP Snoop
198    I          3442960    4168186 0     25.33   24.22  24.77  0   IP Host Track Proce
30     I          3802130    4168183 0     24.66   27.88  27.66  0   ARP Input
283    I          574800     3225649 0     4.33    4.00   4.11   0   DAI Packet Process

3850-2#show processes cpu detailed process fed sorted | ex 0.0
Core 0: CPU utilization for five seconds: 45%; one minute: 44%; five minutes: 44%
Core 1: CPU utilization for five seconds: 38%; one minute: 44%; five minutes: 45%
Core 2: CPU utilization for five seconds: 42%; one minute: 41%; five minutes: 40%
Core 3: CPU utilization for five seconds: 32%; one minute: 30%; five minutes: 31%
PID    T C  TID   Runtime(ms)Invoked uSecs 5Sec   1Min   5Min   TTY  Process
                                            (%)    (%)    (%)
5638   L          612840     1143306 536   13.22  12.90   12.93  1088  fed
5638   L 3  8998  396500     602433  0     9.87   9.63    9.61   0     PunjectTx
5638   L 3  8997  159890     66051   0     2.70   2.70    2.74   0     PunjectRx

L'output (Cisco IOSd CPU output) mostra che ARP Snoop, IP Host Track Process e ARP Input sono elevati. Questa condizione si verifica in genere quando la CPU viene interrotta a causa di pacchetti ARP.

Passaggio 2: Determinare la coda di CPU che causa la condizione di utilizzo elevato della CPU

Lo switch Cisco Catalyst serie 3850 ha un numero di code che rispondono a diversi tipi di pacchetti (il FED mantiene 32 code di CPU RX, ossia code che vanno direttamente alla CPU). È importante monitorare queste code per individuare i pacchetti puntati alla CPU e quelli elaborati da Cisco IOSd. Queste code sono per ASIC.

Nota: sono disponibili due ASIC: 0 e 1. Le porte da 1 a 24 appartengono all'ASIC 0.

Per esaminare le code, immettere il show platform punt statistics direzione <port-asic>cpuq <queue> asic  

Nel comando show platform punt statistics port-asic 0 cpuq -1 direction rx, l'argomento -1 elenca tutte le code. Pertanto, questo comando elenca tutte le code di ricezione per Port-ASIC 0.

A questo punto, è necessario identificare la coda che invia un numero elevato di pacchetti a una velocità elevata. In questo esempio, un'analisi delle code ha rivelato questo colpevole:

<snip>
RX (ASIC2CPU) Stats (asic 0 qn 16 lqn 16):
RXQ 16: CPU_Q_PROTO_SNOOPING
----------------------------------------
Packets received from ASIC     : 79099152
Send to IOSd total attempts    : 79099152
Send to IOSd failed count      : 1240331
RX suspend count               : 1240331
RX unsuspend count             : 1240330
RX unsuspend send count        : 1240330
RX unsuspend send failed count : 0
RX dropped count               : 0
RX conversion failure dropped  : 0
RX pkt_hdr allocation failure  : 0
RX INTACK count                : 0
RX packets dq'd after intack   : 0
Active RxQ event               : 9906280
RX spurious interrupt          : 0
<snip>

Il numero di coda è 16 e il nome della coda è CPU_Q_PROTO_SNOOPING.

Un altro modo per scoprire la coda colpevole è immettere il comando show platform punt client.

3850-2#show platform punt client
  tag      buffer        jumbo    fallback     packets   received   failures
                                            alloc   free  bytes    conv  buf
 27       0/1024/2048     0/5       0/5        0     0          0     0     0
 65536    0/1024/1600     0/0       0/512      0     0          0     0     0
 65537    0/ 512/1600     0/0       0/512   1530  1530     244061     0     0
 65538    0/   5/5        0/0       0/5        0     0          0     0     0
 65539    0/2048/1600     0/16      0/512      0     0          0     0     0
 65540    0/ 128/1600     0/8       0/0        0     0          0     0     0
 65541    0/ 128/1600     0/16      0/32       0     0          0     0     0
 65542    0/ 768/1600     0/4       0/0        0     0          0     0     0
 65544    0/  96/1600     0/4       0/0        0     0          0     0     0
 65545    0/  96/1600     0/8       0/32       0     0          0     0     0
 65546    0/ 512/1600     0/32      0/512      0     0          0     0     0
 65547    0/  96/1600     0/8       0/32       0     0          0     0     0
 65548    0/ 512/1600     0/32      0/256      0     0          0     0     0
 65551    0/ 512/1600     0/0       0/256      0     0          0     0     0
 65556    0/  16/1600     0/4       0/0        0     0          0     0     0
 65557    0/  16/1600     0/4       0/0        0     0          0     0     0
 65558    0/  16/1600     0/4       0/0        0     0          0     0     0
 65559    0/  16/1600     0/4       0/0        0     0          0     0     0
 65560    0/  16/1600     0/4       0/0        0     0          0     0     0
s65561  421/ 512/1600     0/0       0/128  79565859 131644697  478984244     0 37467
 65563    0/ 512/1600     0/16      0/256      0     0          0     0     0
 65564    0/ 512/1600     0/16      0/256      0     0          0     0     0
 65565    0/ 512/1600     0/16      0/256      0     0          0     0     0
 65566    0/ 512/1600     0/16      0/256      0     0          0     0     0
 65581    0/   1/1        0/0       0/0        0     0          0     0     0
 131071   0/  96/1600     0/4       0/0        0     0          0     0     0
fallback pool: 98/1500/1600
jumbo pool:    0/128/9300

Determinare il tag per il quale sono stati allocati la maggior parte dei pacchetti. In questo esempio, questo valore è 65561.

Immettere quindi questo comando:

3850-2#show pds tag all | in Active|Tags|65561
   Active   Client Client
     Tags   Handle Name                 TDA       SDA         FDA   TBufD       TBytD
    65561  7296672 Punt Rx Proto Snoop  79821397  79821397    0  79821397   494316524

Questo output mostra che la coda è Rx Proto Snoop.

Il valore s prima dello 65561 nell'output del comando show platform punt client indica che l'handle FED viene sospeso e sopraffatto dal numero di pacchetti in arrivo. Se la s non scompare, la coda è bloccata in modo permanente.

Passaggio 3: Scaricare il pacchetto inviato alla CPU

Nei risultati del comando show pds tag all, si noti che accanto allo snoop Punt Rx Proto viene visualizzato un handle, 7296672.

Utilizzare questo handle nel comando show pds client <handle> packet last sink. Si noti che è necessario abilitare debug pds pktbuf-last prima di utilizzare il comando. In caso contrario, viene visualizzato il seguente errore:

3850-2#show pds client 7296672 packet last sink
% switch-2:pdsd:This command works in debug mode only. Enable debug using
"debug pds pktbuf-last" command

Se il debug è abilitato, viene visualizzato questo output:

3850-2#show pds client 7296672 packet last sink
Dumping Packet(54528) # 0 of Length 60
-----------------------------------------
Meta-data
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0010 00 00 16 1d 00 00 00 00 00 00 00 00 55 5a 57 f0  ............UZW.
0020 00 00 00 00 fd 01 10 df 00 5b 70 00 00 10 43 00  .........[p...C.
0030 00 10 43 00 00 41 fd 00 00 41 fd 00 00 00 00 00  ..C..A...A......
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0050 00 00 00 3c 00 00 00 00 00 01 00 19 00 00 00 00  ...<............
0060 01 01 b6 80 00 00 00 4f 00 00 00 00 00 00 00 00  .......O........
0070 01 04 d8 80 00 00 00 33 00 00 00 00 00 00 00 00  .......3........
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0090 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00a0 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00  ................
Data
0000 ff ff ff ff ff ff aa bb cc dd 00 00 08 06 00 01  ................
0010 08 00 06 04 00 01 aa bb cc dd 00 00 c0 a8 01 0a  ................
0020 ff ff ff ff ff ff c0 a8 01 14 00 01 02 03 04 05  ................
0030 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11              ............

Con questo comando viene eseguito il dump dell'ultimo pacchetto ricevuto dal sink, che in questo esempio è Cisco IOSd. Ciò mostra che scarica l'intestazione e può essere decodificata con Wireshark (TShark) basato su terminale. I metadati sono destinati all'uso interno da parte del sistema, ma l'output dei dati fornisce informazioni effettive sul pacchetto. I metadata, tuttavia, rimangono estremamente utili.

La linea che inizia con 0070. Usare i primi 16 bit successivi, come mostrato di seguito:

3850-2#show platform port-asic ifm iif-id 0x0104d88000000033
Interface Table
Interface IIF-ID        : 0x0104d88000000033
Interface Name          : Gi2/0/20
Interface Block Pointer : 0x514d2f70
Interface State         : READY
Interface Stauts        : IFM-ADD-RCVD, FFM-ADD-RCVD
Interface Ref-Cnt       : 6
Interface Epoch         : 0
Interface Type          : ETHER
        Port Type         : SWITCH PORT
        Port Location     : LOCAL
Slot              : 2
        Unit              : 20
        Slot Unit         : 20
        Acitve            : Y
        SNMP IF Index     : 22
        GPN               : 84
        EC Channel        : 0
        EC Index          : 0
        ASIC              : 0
        ASIC Port         : 14
        Port LE Handle    : 0x514cd990
Non Zero Feature Ref Counts
        FID : 48(AL_FID_L2_PM), Ref Count : 1
        FID : 77(AL_FID_STATS), Ref Count : 1
        FID : 51(AL_FID_L2_MATM), Ref Count : 1
        FID : 13(AL_FID_SC), Ref Count : 1
        FID : 26(AL_FID_QOS), Ref Count : 1
Sub block information
        FID : 48(AL_FID_L2_PM), Private Data : 0x54072618
        FID : 26(AL_FID_QOS), Private Data : 0x514d31b8

L'interfaccia colpevole è identificata qui. Gig2/0/20 è dove c'è un generatore di traffico che pompa il traffico ARP. Se si arresta il sistema, il problema verrà risolto e l'utilizzo della CPU verrà ridotto al minimo.

Passaggio 4: Utilizzare la traccia FED

L'unico inconveniente del metodo illustrato nell'ultima sezione è che viene scaricato solo l'ultimo pacchetto che viene inserito nel sink, e non può esserne il responsabile.

Un modo migliore per risolvere il problema consiste nell'utilizzare una funzione denominata tracciamento FED. Il trace è un metodo di acquisizione dei pacchetti (utilizzando vari filtri) che viene eseguito dal FED sulla CPU. Tuttavia, il trace FED non è semplice come la funzione Netdr sugli switch Cisco Catalyst serie 6500.

Il processo è suddiviso in passaggi:

1. Abilitare il rilevamento dei dettagli. Per impostazione predefinita, la traccia degli eventi è attivata. Per acquisire i pacchetti effettivi, è necessario abilitare la traccia dei dettagli:
   
   

   3850-2#set trace control fed-punject-detail enable

   
   
   
2. Ottimizzare il buffer di acquisizione. Determinare la profondità dei buffer per la traccia dei dettagli e aumentare se necessario.
   
   

   3850-2#show mgmt-infra trace settings fed-punject-detail
   One shot Trace Settings:
   
   Buffer Name: fed-punject-detail
   Default Size: 32768
   Current Size: 32768
   Traces Dropped due to internal error: No
   Total Entries Written: 0
   One shot mode: No
   One shot and full: No
   Disabled: False

   
   È possibile modificare le dimensioni del buffer con questo comando:
   
   

   3850-2#set trace control fed-punject-detail buffer-size  
          

   
   I valori disponibili sono:
   
   

   3850-2#set trace control fed-punject-detail buffer-size ?
     <8192-67108864>  The new desired buffer size, in bytes
     default          Reset trace buffer size to default

   
   
   
3. Aggiungere i filtri di acquisizione. A questo punto è necessario aggiungere diversi filtri per l'acquisizione. È possibile aggiungere filtri diversi e scegliere se far corrispondere tutti i filtri o solo quelli per la cattura.
   
   I filtri vengono aggiunti con questo comando:
   
   

   3850-2#set trace fed-punject-detail direction rx filter_add  
          

   
   Queste opzioni sono attualmente disponibili:
   
   

   3850-2#set trace fed-punject-detail direction rx filter_add ?
     cpu-queue  rxq 0..31
     field      field
     offset     offset

   
   Ora bisogna collegare le cose. Ricordare la coda colpevole identificata nel passaggio 2 di questo processo di risoluzione dei problemi? Poiché la coda 16 è la coda che invia un numero elevato di pacchetti alla CPU, ha senso tracciare questa coda e vedere quali pacchetti vengono puntati alla CPU da essa.
   
   È possibile scegliere di tracciare qualsiasi coda con questo comando:
   
   

    3850-2#set trace fed-punject-detail direction rx filter_add cpu-queue  
          
    
         
         

   
   Di seguito è riportato il comando per questo esempio:
   
   

   3850-2#set trace fed-punject-detail direction rx filter_add cpu-queue 16 16

   
   È necessario scegliere una corrispondenza per tutti i filtri o una corrispondenza per tutti i filtri, quindi abilitare la traccia:
   
   

   3850-2#set trace fed-punject-detail direction rx match_all
   3850-2#set trace fed-punject-detail direction rx filter_enable

   
   
   
4. Visualizza pacchetti filtrati. È possibile visualizzare i pacchetti acquisiti con il comando show mgmt-infra trace messages fed-punject-detail.
   
   

   3850-2#show mgmt-infra trace messages fed-punject-detail
   [11/25/13 07:05:53.814 UTC 2eb0c9 5661]
   00 00 00 00 00 4e 00 40 07 00 02 08 00 00 51 3b
   00 00 00 00 00 01 00 00 03 00 00 00 00 00 00 01
   00 00 00 00 20 00 00 0e 00 00 00 00 00 01 00 74
   00 00 00 04 00 54 41 02 00 00 00 00 00 00 00 00
   
   [11/25/13 07:05:53.814 UTC 2eb0ca 5661]
   ff ff ff ff ff ff aa bb cc dd 00 00 08 06 00 01
   08 00 06 04 00 01 aa bb cc dd 00 00 c0 a8 01 0a
   ff ff ff ff ff ff c0 a8 01 14 00 01 02 03 04 05
   06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 f6 b9 10 32
   [11/25/13 07:05:53.814 UTC 2eb0cb 5661] Frame descriptors:
   [11/25/13 07:05:53.814 UTC 2eb0cc 5661]
   =========
   fdFormat=0x4    systemTtl=0xe
   loadBalHash1=0x8        loadBalHash2=0x8
   spanSessionMap=0x0      forwardingMode=0x0
   destModIndex=0x0        skipIdIndex=0x4
   srcGpn=0x54     qosLabel=0x41
   srcCos=0x0      ingressTranslatedVlan=0x3
   bpdu=0x0        spanHistory=0x0
   sgt=0x0 fpeFirstHeaderType=0x0
   srcVlan=0x1     rcpServiceId=0x2
   wccpSkip=0x0    srcPortLeIndex=0xe
   cryptoProtocol=0x0      debugTagId=0x0
   vrfId=0x0       saIndex=0x0
   pendingAfdLabel=0x0     destClient=0x1
   appId=0x0       finalStationIndex=0x74
   decryptSuccess=0x0      encryptSuccess=0x0
   rcpMiscResults=0x0      stackedFdPresent=0x0
   spanDirection=0x0       egressRedirect=0x0
   redirectIndex=0x0       exceptionLabel=0x0
   destGpn=0x0     inlineFd=0x0
   suppressRefPtrUpdate=0x0        suppressRewriteSideEfects=0x0
   cmi2=0x0        currentRi=0x1
   currentDi=0x513b        dropIpUnreachable=0x0
   srcZoneId=0x0   srcAsicId=0x0
   originalDi=0x0  originalRi=0x0
   srcL3IfIndex=0x2        dstL3IfIndex=0x0
   dstVlan=0x0     frameLength=0x40
   fdCrc=0x7       tunnelSpokeId=0x0
   
   =========
   [11/25/13 07:05:53.814 UTC 2eb0cd 5661]
   [11/25/13 07:05:53.814 UTC 2eb0ce 5661] PUNT PATH (fed_punject_rx_process_packet:
   830):RX: Q: 16, Tag: 65561
   [11/25/13 07:05:53.814 UTC 2eb0cf 5661] PUNT PATH (fed_punject_get_physical_iif:
   579):RX: Physical IIF-id 0x104d88000000033
   [11/25/13 07:05:53.814 UTC 2eb0d0 5661] PUNT PATH (fed_punject_get_src_l3if_index:
   434):RX: L3 IIF-id 0x101b6800000004f
   [11/25/13 07:05:53.814 UTC 2eb0d1 5661] PUNT PATH (fed_punject_fd_2_pds_md:478):
   RX: l2_logical_if = 0x0
   [11/25/13 07:05:53.814 UTC 2eb0d2 5661] PUNT PATH (fed_punject_get_source_cos:638):
   RX: Source Cos 0
   [11/25/13 07:05:53.814 UTC 2eb0d3 5661] PUNT PATH (fed_punject_get_vrf_id:653):
   RX: VRF-id 0
   [11/25/13 07:05:53.814 UTC 2eb0d4 5661] PUNT PATH (fed_punject_get_src_zoneid:667):
   RX: Zone-id 0
   [11/25/13 07:05:53.814 UTC 2eb0d5 5661] PUNT PATH (fed_punject_fd_2_pds_md:518):
   RX: get_src_zoneid failed
   [11/25/13 07:05:53.814 UTC 2eb0d6 5661] PUNT PATH (fed_punject_get_acl_log_direction:
   695): RX: : Invalid CMI2
   [11/25/13 07:05:53.814 UTC 2eb0d7 5661] PUNT PATH (fed_punject_fd_2_pds_md:541):RX:
    get_acl_log_direction failed
   [11/25/13 07:05:53.814 UTC 2eb0d8 5661] PUNT PATH (fed_punject_get_acl_full_direction:
   724):RX: DI 0x513b ACL Full Direction 1
   [11/25/13 07:05:53.814 UTC 2eb0d9 5661] PUNT PATH (fed_punject_get_source_sgt:446):
   RX: Source SGT 0
   [11/25/13 07:05:53.814 UTC 2eb0da 5661] PUNT PATH (fed_punject_get_first_header_type:680):
   RX: FirstHeaderType 0
   [11/25/13 07:05:53.814 UTC 2eb0db 5661] PUNT PATH (fed_punject_rx_process_packet:916):
   RX: fed_punject_pds_send packet 0x1f00 to IOSd with tag 65561
   [11/25/13 07:05:53.814 UTC 2eb0dc 5661] PUNT PATH (fed_punject_rx_process_packet:744):
   RX: **** RX packet 0x2360 on qn 16, len 128 ****
   [11/25/13 07:05:53.814 UTC 2eb0dd 5661]
   buf_no 0 buf_len 128
   
   <snip>

   
   
   Questo output fornisce un'ampia quantità di informazioni e può in genere essere sufficiente per individuare l'origine e il contenuto dei pacchetti.
   
   La prima parte del dump dell'intestazione è ancora una volta costituita dai metadati utilizzati dal sistema. La seconda parte è il pacchetto effettivo.
   
   

   ff ff ff ff ff ff - destination MAC address
   aa bb cc dd 00 00 - source MAC address

   
   
   È possibile scegliere di tracciare questo indirizzo MAC di origine per trovare la porta colpevole (una volta identificato che questa è la maggior parte dei pacchetti che vengono puntualizzati dalla coda 16; questo output mostra solo un'istanza del pacchetto e gli altri output/pacchetti vengono ritagliati).
   
   Tuttavia, c'è un modo migliore. Si noti che i log presenti dopo le informazioni dell'intestazione:
   
   

   [11/25/13 07:05:53.814 UTC 2eb0ce 5661] PUNT PATH (fed_punject_rx_process_packet:
   830):RX: Q: 16, Tag: 65561
   [11/25/13 07:05:53.814 UTC 2eb0cf 5661] PUNT PATH (fed_punject_get_physical_iif:
   579):RX: Physical IIF-id 0x104d88000000033

   
   Il primo log indica chiaramente da quale coda e tag proviene il pacchetto. Se non si era a conoscenza della coda in precedenza, questo è un modo semplice per identificare la coda che era.
   
   Il secondo log è ancora più utile in quanto fornisce l'ID IIF (Interface ID Factory)-ID fisico per l'interfaccia di origine. Il valore esadecimale è un handle che può essere utilizzato per eseguire il dump delle informazioni relative alla porta:
   
   

   3850-2#show platform port-asic ifm iif-id 0x0104d88000000033
   Interface Table
   Interface IIF-ID        : 0x0104d88000000033
   Interface Name          : Gi2/0/20
   Interface Block Pointer : 0x514d2f70
   Interface State         : READY
   Interface Stauts        : IFM-ADD-RCVD, FFM-ADD-RCVD
   Interface Ref-Cnt       : 6
   Interface Epoch         : 0
   Interface Type          : ETHER
           Port Type         : SWITCH PORT
           Port Location     : LOCAL
           Slot              : 2
           Unit              : 20
           Slot Unit         : 20
           Active            : Y
           SNMP IF Index     : 22
           GPN               : 84
           EC Channel        : 0
           EC Index          : 0
           ASIC              : 0
           ASIC Port         : 14
           Port LE Handle    : 0x514cd990
   Non Zero Feature Ref Counts
           FID : 48(AL_FID_L2_PM), Ref Count : 1
           FID : 77(AL_FID_STATS), Ref Count : 1
           FID : 51(AL_FID_L2_MATM), Ref Count : 1
           FID : 13(AL_FID_SC), Ref Count : 1
           FID : 26(AL_FID_QOS), Ref Count : 1
   Sub block information
           FID : 48(AL_FID_L2_PM), Private Data : 0x54072618
           FID : 26(AL_FID_QOS), Private Data : 0x514d31b8

Ancora una volta avete identificato l'interfaccia di origine e la causa del guasto.

La funzione di trace è un potente strumento fondamentale per la risoluzione dei problemi relativi all'utilizzo elevato della CPU e in grado di fornire numerose informazioni per risolvere correttamente questa situazione.

Esempio di script EEM (Embedded Event Manager) per gli switch Cisco Catalyst serie 3850

Utilizzare questo comando per attivare la generazione di un registro a una determinata soglia:

process cpu threshold type total rising 
    
     interval 
    
    
switch 
    
    

Il log generato con il comando ha il seguente aspetto:

*Jan 13 00:03:00.271: %CPUMEM-5-RISING_THRESHOLD: 1 CPUMEMd[6300]:  Threshold: : 50, Total CPU Utilzation(total/Intr) :50/0, Top 3 processes(Pid/Util) : 8622/25, 5753/12, 9663/0

Il log generato fornisce le seguenti informazioni:

• Utilizzo totale della CPU al momento del trigger. Questo valore è identificato dall'utilizzo totale della CPU (total/Intr) :50/0 in questo esempio.
• Primi processi: elencati nel formato PID/CPU%. In questo esempio sono:
  

      8622/25 - 8622 is PID for IOSd and 25 implies that this process is using 25% CPU.
      5753/12 - 5733 is PID for FED and 12 implies that this process is using 12% CPU.

Di seguito è riportato lo script EEM:

event manager applet highcpu
event syslog pattern "%CPUMEM-5-RISING_THRESHOLD"
 action 0.1 syslog msg "high CPU detected"
 action 0.2 cli command "enable"
 action 0.3 cli command "show process cpu sorted | append nvram:<filename>.txt"
 action 0.4 cli command "show process cpu detailed process <process name|process ID>
 sorted | nvram:<filename>.txt"
 action 0.5 cli command "show platform punt statistics port-asic 0 cpuq -1
 direction rx | append nvram:<filename>.txt"
 action 0.6 cli command "show platform punt statistics port-asic 1 cpuq -1
 direction rx | append nvram:<filename>.txt"
 action 0.7 cli command "conf t"
 action 0.8 cli command "no event manager applet highcpu"

Nota: il comando process cpu threshold non funziona attualmente nel treno 3.2.X. Un altro aspetto da tenere presente è che questo comando analizza l'utilizzo medio della CPU tra i quattro core e genera un registro quando questa media raggiunge la percentuale definita nel comando.

Cisco IOS XE 16.x o versioni successive

Se sugli switch Catalyst 3850 è in esecuzione il software Cisco IOS® XE versione 16.x o successive, vedere Risoluzione dei problemi di utilizzo elevato della CPU sulle piattaforme degli switch Catalyst con IOS-XE 16.x.

Informazioni correlate

• Cos'è Cisco IOS XE?
• Switch Cisco Catalyst 3850 - Data sheet e documentazione
• Supporto tecnico Cisco e download