Risoluzione dei problemi relativi ai pacchetti ignorati e all'assenza di perdite di memoria sul Cisco serie 12000 Internet Router

Introduzione

Questo documento spiega come risolvere i problemi relativi al motivo per cui l'output del comando show interfaces su un Cisco serie 12000 Internet Router visualizza un numero crescente di errori ignorati. Fornisce inoltre suggerimenti per la risoluzione dei problemi relativi a un numero crescente di cali di memoria nell'output dello slot di esecuzione<slot#> show controller (frfab) | tofab) comando qm stat. Per risolvere uno di questi errori, verificare che il contatore sia in aumento e che non si tratti semplicemente di un valore cronologico.

Nota: un numero crescente di perdite nella coda di input, come mostrato nell'output show interfaces, viene descritto separatamente in Risoluzione dei problemi di perdita di input sul router Internet Cisco serie 12000.

Prerequisiti

Requisiti

Questo documento richiede la comprensione dell'architettura dei Cisco serie 12000 Internet Router, in particolare delle code ToFab e FrFab. Vedere Come leggere l'output di show controller frfab | tofab queue Comandi per riferimento.

Componenti usati

Le informazioni fornite in questo documento si basano sulle versioni software e hardware riportate di seguito.

• Qualsiasi versione del software Cisco IOS^® che supporti Cisco serie 12000 Internet Router. Di solito queste sono le versioni 12.0S e 12.0ST.

• Tutte le piattaforme Cisco 12000 sono illustrate in questo documento. Questi includono 12008, 12012, 12016, 12404, 12410 e 12416.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Convenzioni

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

Sintomi

Cisco serie 12000 Internet Router utilizza un'architettura distribuita per garantire prestazioni di inoltro ottimali. Per supportare alte velocità di inoltro, mantiene i buffer dei pacchetti sia sulle schede di linea in entrata che in uscita. Questi buffer di pacchetto variano in dimensioni e generalmente sono progettati per supportare frame di dimensioni MTU (Maximum Transmission Unit).

Dopo aver determinato l'interfaccia in uscita per un pacchetto, il processore di inoltro esegue le operazioni seguenti:

1. Il processore di inoltro invia un puntatore con le informazioni sul pacchetto (compresa la sua posizione in memoria) alla coda di output virtuale dell'interfaccia in uscita.

2. Lo scheduler della scheda di linea invia una richiesta allo scheduler. L'utilità di pianificazione concede una licenza e il pacchetto viene inviato dalla memoria buffer attraverso il fabric di switching alla scheda di linea in uscita.

3. La scheda di linea in uscita memorizza i pacchetti nel buffer.

4. Il processore L3 e i circuiti integrati specifici dell'applicazione (ASIC) associati sul LC in uscita trasmettono il pacchetto all'uscita dell'interfaccia.

Se l'interfaccia in uscita ha una sottoscrizione eccessiva, inizia a memorizzare nel buffer i pacchetti in eccesso. Durante i periodi di sovrascrittura prolungata, le code di trasmissione del LC in uscita si riempiono. In questa condizione, a seconda del LC in uscita si verifica quanto segue:

Tipo di motore LC in uscita	Risposta a congestione in uscita	Contatore errori
Motore 0 e 1	Invia un segnale di contropressione. L'interfaccia in entrata inizia a memorizzare nel buffer i pacchetti in eccesso.	Errori ignorati nell'output del comando show interfaces e/o nessuna perdita di memoria nello slot di esecuzione su <slot#> show controllers to fab QM stat output del comando del LC in entrata, a seconda del motore di inoltro L3.¹
Motore 2, 3, 4	Elimina tutti i pacchetti in eccesso in uscita.	Nessun calo di memoria nell'output del comando show controllers frfab QM stat sullo slot di esecuzione in uscita.

¹Verranno ignorati gli errori dei motori L3 0, 1 e 2 LC in entrata. Tuttavia, per quattro, 16 e più porte sui LC del motore 2, il contatore ignorato non aumenterà.

Su qualsiasi dispositivo di rete intelligente, quando una o più interfacce ad alta velocità alimentano un'interfaccia a velocità relativamente bassa, si verifica una mancata corrispondenza nelle velocità di interfaccia. Dal momento che l'interfaccia in uscita a velocità più lenta non può restituire i buffer alla stessa velocità con cui l'interfaccia in entrata più veloce li invia alla coda di attesa dell'output, un ritardo nella restituzione del buffer causa alcuni tipi di perdita. Questo flusso di pacchetto interrompe il presupposto che l'interfaccia in uscita restituisca il buffer alla velocità del tempo di gestione del buffer.

Oltre a una mancata corrispondenza nelle velocità delle interfacce, gli errori ignorati possono aumentare quando la velocità dei pacchetti in arrivo è superiore a quella con cui la CPU è in grado di elaborarli. Questa condizione è molto rara sul Cisco 12000 e in genere è causata da un numero elevato di pacchetti molto piccoli o quando una funzionalità che richiede un uso intensivo della CPU, come gli Access Control Lists (ACL) o il monitoraggio del traffico, è abilitata su un LC che implementa queste funzionalità nel software. Questo è il caso dei LC Engine 0 dove molte funzionalità sono implementate nel software. Nei motori successivi, tuttavia, quasi tutte le funzionalità sono implementate nell'hardware. Ad esempio, le schede di linea Engine 3 (IP Services Engine - ISE) e Engine 4+ sono progettate per applicazioni Edge e implementano servizi IP avanzati (come QoS - Quality of Service) nell'hardware senza alcun impatto sulle prestazioni. Esempi di hardware includono CHOC-48 ISE a 1 porta, CHOC-12 ISE a 4 porte, OC-3 POS ISE a 16 porte, OC-12 POS ISE a 4 porte, OC-48 POS ISE a 1 porta e OC-48 POS ISE a 1 porta.

Il contatore ignorato può anche essere incrementato ogni volta che un pacchetto arriva su una scheda di linea in entrata e non è disponibile un buffer di pacchetto di dimensioni appropriate per gestire questo pacchetto. Tuttavia, questa condizione è molto rara e non viene trattata nel presente documento.

Gestione della sottoscrizione eccessiva dell'interfaccia in uscita

La soluzione per ignorare gli errori e evitare le interruzioni di memoria causate da una sovrascrittura dell'interfaccia di output è la stessa per qualsiasi tipo di motore L3, evitando la scadenza del buffer. In altre parole, abbiamo bisogno di un meccanismo che impedisca alle code di FrFab di riempirsi.

Motori 0 e 1

In parole povere, il contatore ignorato viene incrementato quando un pacchetto arriva su una scheda di linea in entrata (LC) e non è disponibile un buffer di pacchetto di dimensioni appropriate per gestire questo pacchetto. Pertanto, i pacchetti ignorati in genere non puntano a un bug nel software Cisco IOS.

Di seguito viene riportato un output di esempio del comando show interfaces con un contatore non null ignorato su un router Cisco serie 12000:

router#show interfaces G3/0
GigabitEthernet3/0 is up, line protocol is up
  Hardware is GigMac GigabitEthernet, address is 0030.71f5.7980 
     (bia 0030.71f5.7980)
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 1/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
  Full-duplex mode, link type is force-up, media type is SX
  output flow-control is unsupported, input flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:00:07
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 99000 bits/sec, 74 packets/sec
  5 minute output rate 104000 bits/sec, 68 packets/sec
    478 packets input, 71057 bytes, 0 no buffer
    Received 19 broadcasts, 0 runts, 0 giants, 0 throttles
    2 input errors, 2 CRC, 0 frame, 0 overrun, 25 ignored

 !--- Ignored counter is > 0. Ensure it is incrementing.

    
    0 watchdog, 53 multicast, 0 pause input
    541 packets output, 139133 bytes, 0 underruns
    0 output errors, 0 collisions, 0 interface resets
    0 babbles, 0 late collision, 0 deferred
    0 lost carrier, 0 no carrier, 0 pause output
    0 output buffer failures, 0 output buffers swapped out

Quando il LC in uscita è un Engine 0 o 1, invia un messaggio di contropressione agli altri LC dicendo loro di non inviare più i dati a quel particolare LC. L'interfaccia in entrata archivia quindi i pacchetti in eccesso nelle relative code ToFab corrispondenti allo slot di destinazione.

Per isolare la causa più probabile dell'aumento del contatore Ignorato, è necessario esaminare le code ToFab della LC in entrata. È possibile collegarsi al CLI sul bus di manutenzione (MBUS) utilizzando il comando attach oppure utilizzare il comando execute-on slot <slot#> show controllers to fab queue per controllare le code ToFab. Eseguire questo comando alcune volte e cercare i seguenti sintomi:

• Un valore o valore 0 decrescente e basso nella colonna #Qelem di una coda libera non IPC

• Valore elevato nella colonna #Qelem in una coda di slot di destinazione.

Motori 2, 3, 4

Le schede di linea che utilizzano una più recente architettura del motore L3 non utilizzano un meccanismo di contropressione. Al contrario, quando l'interfaccia ha una sottoscrizione eccessiva e una coda FrFab si è esaurita, i pacchetti vengono semplicemente scartati quando arrivano sulla scheda di linea in uscita.

Le LC del motore 2 non eseguono il fallback al successivo pool di buffer di dimensioni maggiori quando un pool di dimensioni inferiori diventa esaurito. Il meccanismo di fallback è stato implementato solo per le LC del motore 2 sul lato ToFab (Rx). In tal caso, il contatore "bump count" aumenta nell'output del comando show controller to fab QM stat dello slot di esecuzione <slot>.

Queste cadute vengono conteggiate come nessuna caduta di mem nell'output del comando execute-on slot <slot#> show controller frfab QM stat, come illustrato di seguito:

Router#execute-on slot 1 show controller
frfab QM stat
========= Line Card (Slot 1) =======

174 no mem drop, 0 soft drop, 0 bump count 

!--- Look for an incrementing value for the "no mem drop" counter

0 rawq drops, 0 global red drops, 0 global force drops
0 no memory (ns), 0 no memory hwm (Ns)
no free queue
0       0       0       0
0       0       0       0
0       0       0       0
0       0       0       0
0 multicast drops
Tx Counts
 Interface 0
8390658710246 TX bytes, 2098330790 TX pkts, 212452 kbps, 6641 pps
 Interface 1
0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 2
0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 3
0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS

È necessario trovare un modo per evitare che il dispositivo FrFab memorizzi nel buffer al punto in cui il dispositivo LC esegue il backup sull'interfaccia in entrata o semplicemente scarta i pacchetti.

Una soluzione semplice per tutte le schede di linea, ad eccezione delle schede LC del motore 2, consiste nel ridurre il numero di buffer disponibili per una particolare interfaccia in uscita su una scheda LC multi-interfaccia. Per impostazione predefinita, un'interfaccia può utilizzare tutti i buffer FrFab scolpiti. Utilizzare il comando tx-queue-limit per configurare un valore non predefinito. In questo modo, si impedisce al controller di dominio in uscita di memorizzare nel buffer un numero di pacchetti superiore al numero configurato nella coda di interfaccia per la porta specifica. Assicurarsi di configurare questo numero in modo che non contenga tutte le code FrFab per questa interfaccia. Notare che questo metodo non distingue tra pacchetti ad alta priorità e pacchetti a bassa priorità e implementa semplicemente tail drop in modo più aggressivo per una particolare interfaccia.

Le schede di linea del motore 3 richiedono l'uso di Modular QoS CLI (MQC) anziché dell'interfaccia CLI (Command Line Interface) legacy. Questo comando non è supportato sulle schede di linea basate sul motore 2.

Di seguito è riportato un esempio di configurazione che utilizza la configurazione CoS (Class of Service) legacy:

interface POS 0/0
    tx-queue-limit <max Q length in packets>

Di seguito è riportato un esempio di configurazione con MQC:

policy-map TX_QUEUE_LIMIT
    class class-default
        queue-limit 

interface POS 0/0
    service-policy out TX_QUEUE_LIMIT

Un'altra soluzione è implementare un'interfaccia di output più veloce, che ci dà un tubo più grande. Ma tubi più grandi possono riempirsi rapidamente. Pertanto, la soluzione consigliata è implementare i meccanismi QoS (Quality of Service) sul LC in uscita.

La funzione WRED (Weighted Random Early Detection) di Cisco implementa un meccanismo di drop differenziato o intelligente. È progettato per l'utilizzo con il traffico adattivo, ad esempio i flussi TCP. Controlla le dimensioni della coda e lavora per mantenere una dimensione media della coda coerente, scartando i pacchetti in modo casuale da vari flussi, quando la coda media calcolata supera una soglia minima configurabile.

Quando implementato su Cisco serie 12000, WRED può impedire alle code FrFab di riempirsi e, soprattutto, è selettivo sui pacchetti da scaricare. I LC del motore 0 supportano WRED nel software, mentre i LC del motore 1 non supportano WRED. Gli altri LC L3 Engine supportano WRED nell'hardware.

Per ulteriori informazioni sulla configurazione di WRED, fare riferimento ai seguenti documenti:

• Cisco serie 12000 Random Early Detection

• Configurazione di MPLS CoS su un router Cisco serie 12000 GSR

Questo meccanismo di prevenzione della congestione funziona solo in un ambiente basato su TCP. Il TCP risponde in modo appropriato, anche robusto, alle perdite di traffico rallentando la sua trasmissione. Per ulteriori informazioni sulla reazione del protocollo TCP alla perdita di pacchetti, vedere Come il protocollo TCP gestisce la perdita di traffico e Come il router interagisce con il protocollo TCP.

Un altro meccanismo QoS supportato su Cisco serie 12000 è il monitoraggio del traffico tramite Committed Access Rate (CAR) sui LC del motore 0 e 1 e una versione modificata di CAR nota come Per Interface Rate Control (PIRC) sui LC del motore 2. Configurare il monitoraggio del traffico sull'interfaccia in uscita.

Gestione della CPU sovraccarica sulla scheda di linea in entrata

Questa situazione è molto rara!

È possibile verificare se la CPU è sovraccarica sul LC in arrivo utilizzando il comando execute-on slot <slot#> show controller to fab queue. Se nella colonna #Qelem della riga "Raw Queue" viene visualizzato un numero molto elevato, significa che la CPU (situata sul LC stesso) deve gestire troppi pacchetti. Si inizierà a ricevere pacchetti ignorati perché la CPU non riesce a tenere il passo con la quantità di pacchetti. Questi pacchetti vengono indirizzati alla CPU del CLI, non al Gigabit Route Processor (GRP).

In questo momento, è necessario spostare una parte del traffico da questo LC in entrata in modo da ridurre l'impatto sulla CPU.

È inoltre necessario esaminare la configurazione LC per verificare se vi sono alcune funzionalità configurate che influiscono sulla CPU. Alcune funzioni (come CAR, ACL e NetFlow) possono ridurre le prestazioni del LC quando implementato nel software (solo sui LC Engine 0). In questo caso, occorre procedere di conseguenza rimuovendo la funzione o aggiornando il software Cisco IOS a una versione successiva in cui la stessa implementazione della funzione è migliorata (ad esempio, ACL turbo). Per informazioni sulle funzionalità implementate o migliorate per i diversi LC, vedere le note sulla versione dei router Cisco serie 12000.

Infine, l'unica soluzione potrebbe essere quella di sostituire il cavo LC con uno più recente in cui la funzionalità richiesta sia implementata nell'hardware. Questo dipende dal tipo di motore del LC.

Per determinare il tipo di motore L3 di un LC, è possibile utilizzare il seguente comando di scelta rapida:

Router#show diag | i (SLOT | Engine)
...
SLOT 1  (RP/LC 1 ): 1 port ATM Over SONET OC12c/STM-4c Multi Mode
  L3 Engine: 0 - OC12 (622 Mbps)
SLOT 3  (RP/LC 3 ): 3 Port Gigabit Ethernet
  L3 Engine: 2 - Backbone OC48 (2.5 Gbps)
...

Nota: le schede di linea Engine 3 (IP Services Engine - ISE) e Engine 4+ sono progettate per applicazioni Edge e implementano servizi IP avanzati (ad esempio QoS) nell'hardware senza alcun impatto sulle prestazioni.

Riepilogo delle linee guida di progettazione

• Usare ACL turbo, che ottimizzano le prestazioni permettendo al router di compilare gli ACL prima di scaricarli sul processore LC.

• Evitare di usare la parola chiave "log" sugli ACL.

• Ove possibile, evitare gli ACL in uscita. In un sistema con LC Engine 0, 1 e 2, tutte le elaborazioni degli ACL vengono eseguite sul LC in entrata. Il filtro ACL in uscita viene applicato anche alla scheda in entrata dopo aver stabilito a quale interfaccia in uscita è destinato il pacchetto. Per questo motivo, la configurazione di un ACL in uscita su un'interfaccia influisce su tutti gli ACL del sistema. Inoltre, i controller di dominio del motore 2 possono eseguire ACL in entrata o in uscita, ma non entrambi contemporaneamente nell'ASIC che esegue l'inoltro hardware. Se si configurano gli ACL in entrata e in uscita, il VLC torna all'inoltro basato sulla CPU per gli elenchi degli accessi in uscita, influenzando le prestazioni di switching del VLC. Tuttavia, i nuovi motori, ad esempio il motore 3 e il motore 4+, sono altamente ottimizzati per servizi IP avanzati, quali gli ACL, e per elaborare gli ACL in uscita sul LC in uscita.

• Assegnare il traffico che richiede funzionalità specifiche a un set di LC.

• Assegnare il traffico che non richiede funzionalità a un altro set di LC per mantenere le prestazioni di picco nell'inoltro dei pacchetti.

• Utilizzare LC con tipi di motore superiori quando sono necessarie prestazioni elevate.

• Progettare LC per backbone o core per eseguire funzionalità supportate nell'hardware o nel microcodice.

Case study

In questo caso di studio viene illustrato come risolvere gli errori ignorati incrementali su un'interfaccia di un LC nello slot 6.

Passaggio 1 - Controllare le code ToFab nello slot 6.

Router#exec slot 6 show controllers tofab queue
========= Line Card (Slot 6) =======
Carve information for ToFab buffers
   SDRAM size: 134217728 bytes, address: 30000000, carve base: 30019100
   134115072 bytes carve size,  4 SDRAM bank(s), 8192 bytes SDRAM pagesize,
      2 carve(s)
   max buffer data size 4544 bytes, min buffer data size 80 bytes
   174538/174538 buffers specified/carved
   110797216/110797216 bytes sum buffer sizes specified/carved
        Qnum    Head    Tail            #Qelem  LenThresh
        ----    ----    ----            ------  ---------

   4 non-IPC free queues:
        88964/88964 (buffers specified/carved), 50.97%, 80 byte data size
        1       21120          84604     81074   262143
        54076/54076 (buffers specified/carved), 30.98%, 608 byte data size
        2       122270         116965    49567   262143
        26165/26165 (buffers specified/carved), 14.99%, 1568 byte data size
        3       164160         145355    19518   262143

 !-- Out of the 26165 buffers that are carved, only 19518 are available

        5233/5233 (buffers specified/carved), 2.99%, 4544 byte data size
        4       172325         172088    5233    262143
   IPC Queue:
        100/100 (buffers specified/carved), 0.5%, 4112 byte data size
        30      61             60              100     262143
   Raw Queue:
        31      44229          88895        0       43634

 !-- The Raw Queue has a low or 0 value for the #Qelem column, indicating !-- that the CPU is not overwhelmed with packets destined to it.

   ToFab Queues:
        Dest
        Slot
        0       73769          60489           0       262143
        1       7909           27395           0       262143
        2       61416          71346           0       262143
        3       80352          14567           0       262143
        4       138236         107121        18955     262143     

 !-- 18955 packets are waiting for space in the outbound queues !-- on the LC in slot 4.

        5       4852           48171           0       262143
        6       98318          111757          0       262143
        7       44229          88895           0       262143
        8       0              0               0       262143
        9       0              0               0       262143
        10      0              0               0       262143
        11      0              0               0       262143
        12      0              0               0       262143
        13      0              0               0       262143
        14      0              0               0       262143
        15      0              0               0       262143
 Multicast      0              0               0       262143

Passaggio 2 - Controllare le code FrFab nello slot 4.

Poiché l'output della coda ToFab indica un numero elevato di pacchetti in coda destinati al LC nello slot 4, controllare le code FrFab su questo LC.

Router#exec slot 4 show controllers frfab queue
========= Line Card (Slot 4) =======
Carve information for FrFab buffers
   SDRAM size: 67108864 bytes, address: 20000000, carve base: 2002D100
   66924288 bytes carve size,  0 SDRAM bank(s), 0 bytes SDRAM pagesize, 
      2 carve(s)
   max buffer data size 4544 bytes, min buffer data size 80 bytes
   65534/65534 buffers specified/carved
   66789056/66789056 bytes sum buffer sizes specified/carved
        Qnum    Head    Tail            #Qelem  LenThresh
        ----    ----    ----            ------  ---------
   4 non-IPC free queues:
        
        26174/26174 (buffers specified/carved), 39.93%, 80 byte data size
        1       10123   4332            14515   65535
        
        19630/19630 (buffers specified/carved), 29.95%, 608 byte data size
        2       27898   37167           12279   65535
        
        13087/13087 (buffers specified/carved), 19.96%, 1568 byte data size
        3   0       52275          0       65535        

 !-- Zero buffers available for this pool

        
        6543/6543 (buffers specified/carved), 9.98%, 4544 byte data size
        4       60805   60804           6543    65535
   
   IPC Queue:
        
        100/100 (buffers specified/carved), 0.15%, 4112 byte data size
        30      75      74              100     65535
   
   Raw Queue:
        
        31      0       80              0       65535
   
   Interface Queues:
        
        0       0       39413           0       65535
        1       0       44192           0       65535
        2       48426   58230           32111   65535     

 !-- Interface 2 is using half or 32111 of the carved packet buffers

        3       0       41219           0       65535

Passaggio 3 - Confrontare l'output del comando show interfaces per la stessa interfaccia con sottoscrizione in eccesso.

Associare l'interfaccia sovrascritta indicata nell'output della coda frfab show controllers all'output del comando show interfaces per la stessa interfaccia. L'output seguente conferma che la velocità dell'interfaccia di output è uguale alla velocità della linea ed è sovrassegnata:

Router#show interfaces POS 4/2
POS4/2 is up, line protocol is up
  Hardware is Packet over SONET
  Description: Pacbell OC3 to other ISP...
  Internet address is 10.10.10.10/30
  MTU 4470 bytes, BW 155000 Kbit, DLY 100 usec, rely 255/255, load 156/255
  Encapsulation HDLC, crc 32, loopback not set
  Keepalive set (10 sec)
  Scramble enabled
  Last input 00:00:01, output 00:00:03, output hang never
  Last clearing of "show interface" counters never
  Queueing strategy: FIFO  Output queue 0/300, 0 drops; input queue 0/300, 
     0 drops
  5 minute input rate 20274000 bits/sec, 6263 packets/sec
  5 minute output rate 148605000 bits/sec, 28776 packets/sec
  
!-- The output interface rate is at line rate which means that the interface !-- is oversubscribed.


     1018621328 packets input, 2339977099 bytes, 0 no buffer
     Received 0 broadcasts, 1 runts, 0 giants, 0 throttles
              0 parity
     1 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     378645 packets output, 156727974 bytes, 0 underruns
     0 output errors, 0 applique, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     1 carrier transitions

Fase 4 - Implementazione di una soluzione.

Per i passaggi successivi da eseguire per risolvere gli errori ignorati incrementali in base all'architettura di una particolare interfaccia in uscita, vedere le sezioni soluzioni di questo documento. Ad esempio, su una scheda LC Engine 0, provare a deviare parte del traffico verso un'altra interfaccia o, come misura temporanea, ridurre il numero di buffer di pacchetto che questa particolare interfaccia può utilizzare dalle code libere della scheda di linea. Utilizzare il comando seguente:

Router(config)#int POS 4/2
Router(config-if)#tx-queue-limit 5000

Bug software Cisco IOS

A volte i contatori aumentano a causa di un difetto del software Cisco IOS. Accertarsi di usare l'ultima versione del software Cisco IOS disponibile sul treno per eliminare tutti i bug che sono già stati risolti. Se i pacchetti ignorati vengono ancora visualizzati e le informazioni di questo documento non risolvono il problema, contattare il Technical Assistance Center (TAC) di Cisco per assistenza.

Informazioni correlate

• Risoluzione dei problemi di input sul Cisco serie 12000 Internet Router
• Come leggere l'output di show controller frfab Comandi | tofab queue
• Cisco serie 12000 Random Early Detection
• Configurazione di MPLS CoS su un router Cisco serie 12000 GSR
• Come TCP gestisce la perdita di traffico
• Modalità di interazione del router con TCP
• Configurazione della velocità di accesso impegnata
• Note sulla release dei Cisco serie 12000 Router
• Documentazione e supporto tecnico – Cisco Systems