Risoluzione dei problemi di elevato utilizzo della CPU causati dal processo di input HyBridge sui router con interfacce ATM

Introduzione

Questo documento spiega come risolvere i problemi relativi all'utilizzo elevato della CPU in un router a causa del processo di input di HyBridge. Le interfacce ATM possono supportare un elevato numero di PVC (Permanent Virtual Circuit) configurati per l'utilizzo della RFC (Request for Comments) 1483 con unità PDU (Protocol Data Unit) con bridging Cisco IOS^® standard e IRB (Integrated Routing and Bridging). Questo approccio si basa principalmente sulle trasmissioni per la connettività agli utenti remoti. Con l'aumento del numero di utenti remoti e di PVC, aumenta anche il numero di trasmissioni tra questi utenti. In alcune circostanze, queste trasmissioni producono un elevato utilizzo della CPU sul router.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Architettura Bridging Standard

Lo standard TRFC 1483 specifica che un bridge trasparente (che include un router Cisco configurato per il bridging) deve essere in grado di inondare, inoltrare e filtrare i frame con bridging. L'inondazione è il processo con cui un frame viene copiato in tutte le possibili destinazioni appropriate. Un bridge ATM invia un frame quando copia esplicitamente il frame in ogni circuito virtuale (VC) o quando utilizza un VC point-to-multipoint.

Con il bridging Cisco IOS standard, i frame come gli Address Resolution Protocol (ARP), le trasmissioni, i multicast e i pacchetti Spanning-Tree devono passare attraverso questo processo. La logica di bridging di Cisco IOS gestisce tutti i pacchetti di questo tipo:

1. Esegue l'analisi dell'elenco di interfacce e sottointerfacce configurate nel gruppo di bridge.

2. Esegue l'elenco dei VC configurati nelle interfacce membro del gruppo bridge.

3. Replica il frame su ciascun sistema VC.

Le routine software Cisco IOS che gestiscono la replica devono essere eseguite in loop per duplicare il pacchetto su ciascun PVC. Se il router supporta un numero elevato di PVC di formato con bridging, le routine di replica vengono eseguite per un periodo di tempo esteso, che aumenta la CPU. L'acquisizione del comando show process cpu determina la visualizzazione di un valore elevato di "5sec" per l'input HyBridge, che è responsabile dell'inoltro dei pacchetti che utilizzano il metodo di commutazione di processo. Cisco IOS deve elaborare-switch (ad esempio pacchetti Spanning Tree Bridge Protocol Data Unit (BPDU), broadcast e multicast che non possono essere multicast a commutazione veloce). La commutazione dei processi può richiedere molto tempo della CPU, in quanto viene elaborato solo un numero limitato di pacchetti per chiamata.

Quando un'unica interfaccia supporta molti VC, l'attraversamento dell'elenco può sovraccaricare la CPU. Per risolvere questo problema, consultare l'ID bug Cisco CSCdr1146. Quando la logica di bridging viene eseguita in loop per replicare i broadcast, cede la CPU in modo intermittente. L'abbandono della CPU viene anche chiamato sospensione della CPU.

Nota: anche la configurazione di molte sottointerfacce nello stesso gruppo di bridge può sovraccaricare la CPU.

Sintomi tipici

Se i PVC con bridging provocano un elevato utilizzo della CPU sul router, la prima cosa da cercare è un numero elevato di trasmissioni sull'interfaccia:

ATM_Router# show interface atm1/0 
   ATM1/0 is up, line protocol is up 
      Hardware is ENHANCED ATM PA 
      MTU 4470 bytes, sub MTU 4470, BW 44209 Kbit,    DLY 190 usec, 
         reliability 0/255, txload    1/255, rxload 1/255 
      Encapsulation ATM, loopback not set    
      Keepalive not supported 
      Encapsulation(s): AAL5 
      4096 maximum active VCs, 0 current VCCs    
      VC idle disconnect time: 300 seconds    
      77103 carrier transitions 
      Last input 01:06:21, output 01:06:21, output    hang never 
      Last clearing of "show interface" counters    never 
      Input queue: 0/75/0/702097 (size/max/drops/flushes);    Total output drops: 12201965 
      Queueing strategy: Per VC Queueing    
      5 minute input rate 0 bits/sec, 0 packets/sec    
      5 minute output rate 0 bits/sec, 0 packets/sec    
         59193134 packets input,    3597838975 bytes, 1427069 no buffer 
         Received 463236 broadcasts,    0 runts, 0 giants, 0 throttles 
         46047 input errors, 46047    CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
         91435145 packets output,    2693542747 bytes, 0 underruns 
         0 output errors, 0 collisions,    4 interface resets 
         0 output buffer failures,    0 output buffers swapped out  

Come effetto collaterale, è possibile vedere un numero elevato di cadute sull'interfaccia. In questa situazione, il problema può verificarsi ovunque, dalla lentezza di risposta sul router alla totale inaccessibilità del router. Se si disinserisce l'interfaccia o si scollega il cavo dall'interfaccia ATM, il router dovrebbe essere riavviato.

Se il traffico di trasmissione è bursty, il che si traduce solo in picchi della CPU per brevi periodi di tempo, il problema può essere risolto modificando la coda di attesa di input sull'interfaccia per adattarla ai picchi. La dimensione predefinita della coda di attesa è 75 pacchetti e può essere modificata con il comando hold-queue <lunghezza coda> in|out. In genere, le dimensioni della coda di attesa non devono essere aumentate oltre 150 perché questo causa un maggiore carico a livello di processo sulla CPU.

Risoluzione dei problemi

Se si verificano problemi di utilizzo elevato della CPU causati dall'input HyBridge, catturare questo output quando si contatta il centro Cisco TAC (Technical Assistance Center). Per acquisire questo output, utilizzare i seguenti comandi:

• show process cpu: se si nota un elevato utilizzo della CPU, utilizzare il comando show process CPU per isolare il processo in errore. Vedere Risoluzione dei problemi di utilizzo elevato della CPU sui router Cisco.

• show stacks {process ID} - È possibile utilizzare questo comando anche per verificare quali processi sono operativi e individuare potenziali problemi. Incollare l'output di questo comando nello strumento Output Interpreter (solo utenti registrati). Dopo aver decodificato i processi, è possibile cercare i possibili bug con il Software Bug Toolkit.

  Nota: per utilizzare entrambi questi strumenti è necessario registrarsi per un account CCO ed essere connessi.

• show bridge verbose: utilizzare questo comando show per determinare il numero di sottointerfacce inserite nello stesso gruppo bridge e per verificare se l'interfaccia è sovraccarica.

   router#show process cpu

   CPU utilization for five seconds: 100%/26%; one minute: 94%; five minutes: 56% 
   PID   Runtime(ms)   Invoked   uSecs   5Sec   1Min   5Min   TTY   Process 
    1            44    38169     1       0.00%  0.00%  0.00%    0   Load Meter 
    2           288    733       392     0.00%  0.00%  0.00%    0   PPP auth 
    3         44948    19510     2303    0.00%  0.05%  0.03%    0   Check heaps    
    4             4    1         4000    0.00%  0.00%  0.00%    0   Chunk Manager 
    5          2500    6229      401     0.00%  0.00%  0.00%    0   Pool Manager 
   [output omitted] 
    86            4    1         4000    0.00%  0.00%  0.00%    0   CCSWVOFR    
    87      3390588    1347552   2516    72.72% 69.79% 41.31%   0   HyBridge Input 
    88          172    210559    0       0.00%  0.00%  0.00%    0   Tbridge Monitor    
    89      1139592    189881    6001    0.39%  0.42%  0.43%    0   SpanningTree 

  router#show stacks 87 
   Process 87: HyBridge Input Process 
    Stack segment 0x61D15C5C - 0x61D18B3C 
    FP: 0x61D18A18, RA: 0x60332608 
    FP: 0x61D18A58, RA: 0x608C5400 
    FP: 0x61D18B00, RA: 0x6031A6D4 
    FP: 0x61D18B18, RA: 0x6031A6C0

   router#show bridge verbose
   Total of 300 station blocks, 299 free 
   Codes: P - permanent, S - self

   BG  Hash   Address          Action   Interface       VC Age   RX count   TX count      
     1 8C/0   0000.0cd5.f07c   forward  ATM4/0/0.1      9   0    1857       0
   
Flood ports (BG 1)      RX count TX count 
     ATM4/0/0.1                   0        0

Inoltre, arrestare la BVI (Bridge Group Virtual Interface) e monitorare l'utilizzo della CPU con diverse acquisizioni dell'output del comando show process cpu.

Soluzioni

Cisco consiglia di implementare queste soluzioni come soluzione per un elevato utilizzo della CPU causato dal bridging standard:

• Implementare la funzione di supporto del bridge su linea di abbonati digitale Cisco IOS x, che configura il router per il bridge intelligente flooding tramite le policy degli abbonati. Blocco selettivo di ARP, broadcast, multicast e Spanning-Tree BPDU.

• I sistemi di videoconferenza possono essere suddivisi su poche interfacce multipunto, ciascuna con una rete IP diversa.

• Configurare il timer di aging delle voci ARP IP e della tabella di bridging sullo stesso valore. In caso contrario, è possibile visualizzare inutili sovraccarichi del traffico nei collegamenti. Il timeout ARP predefinito è quattro ore. Il tempo di aging predefinito del bridge è 10 minuti. Per un utente remoto inattivo da 10 minuti, il router elimina solo la voce della tabella bridge dell'utente e mantiene la voce della tabella ARP. Quando il router deve inviare il traffico a valle all'utente remoto, controlla la tabella ARP e trova una voce valida che punti all'indirizzo MAC. Quando il router controlla la tabella bridge per individuare l'indirizzo MAC e non lo trova, inonda il traffico su ogni VC del gruppo bridge. Utilizzare questi comandi per impostare i tempi di aging delle tabelle ARP e bridge.

   router(config)#bridge 1 aging-time ?
   <10-1000000> Seconds
  
   router(config)#interface bvi1    
  
   router(config-if)#arp timeout ? 
        <0-2147483> Seconds 
  

• Sostituire i protocolli standard bridging e IRB con RBE (Routed Bridge Encapsulation) o PVC di tipo bridge sull'interfaccia ATM headend. RBE aumenta le prestazioni di inoltro in quanto supporta Cisco Express Forwarding (CEF) ed esegue pacchetti IP solo tramite una decisione di routing e non tramite una decisione di bridging. Sul treno 12.1(1)T, i pacchetti possono essere commutati via software. In tal caso, viene visualizzato il seguente messaggio di errore:

  %FIB-4-PUNTINTF: CEF punting packets switched to        ATM1/0.100 to next slower path 
  %FIB-4-PUNTINTF: CEF punting packets switched to ATM1/0.101        to next slower path  

  Il problema è documentato in CSCdr37618 e la soluzione è aggiornare alla versione principale 12.2. Per ulteriori informazioni, fare riferimento a Architettura di base Routed Bridged Encapsulation e Configurazione di PVC di tipo Bridged sulle interfacce ATM nelle serie GSR e 7500.

Informazioni correlate

• Risoluzione dei problemi relativi all'utilizzo elevato della CPU nei router Cisco
• Documentazione e supporto tecnico – Cisco Systems
• Strumenti e utilità - Cisco Systems

Cronologia delle revisioni