Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Conventies

Symptomen

Overabonnement met uitgaande interface beheren

Overladen CPU op de inkomende lijnkaart beheren

Samenvatting van de ontwerprichtsnoeren

casestudy

Stap 1 - Controleer de ToFab wachtrijen in sleuf 6.

Stap 2 - Controleer de FrFab-wachtrijen in sleuf 4.

Stap 3 - Vergelijk de uitvoer van de opdracht showinterfaces voor dezelfde overgeplaatste interface.

Stap 4 - Voer een oplossing in.

Cisco IOS-softwarefabels

Gerelateerde informatie

Inleiding

Dit document legt uit hoe u een oplossing kunt vinden waarom de uitvoer van de opdracht Show interfaces op een Cisco 12000 Series Internet Router een steeds groter aantal genegeerde fouten weergeeft. Het geeft ook tips voor het oplossen van problemen voor een toenemend aantal mem-druppels in de uitvoer van de -uitvoeringssleuf< sleuf#> die controllers (frfab) tonen | tofab) qm stat opdracht. Wanneer u een of meer van deze fouten wilt oplossen, controleert u of de teller groter is en niet simpelweg een historische waarde is.

Opmerking: Een steeds groter aantal druppels in de invoerwachtrij, zoals weergegeven in de uitvoer van showinterfaces, wordt afzonderlijk behandeld in druppels voor probleemoplossing op de Cisco 12000 Series internetrouter.

Voorwaarden

Vereisten

Dit document vereist een begrip van de Cisco 12000 Series de architectuur van de Internet Router van Cisco, vooral de wachtrijen van ToFab en FrFab. Zie Hoe de uitvoer van de showcontrollers lezen | Opdrachten voor tofab-wachtrij ter referentie.

Gebruikte componenten

De informatie in dit document is gebaseerd op de onderstaande software- en hardwareversies.

- Elke Cisco IOS® softwarerelease die Cisco 12000 Series Internet Router ondersteunt. Dit zijn meestal de 12.0S- en 12.0ST-releases.

- Alle Cisco 12000-platforms worden door dit document gedekt. Daartoe behoren de jaren 12008, 12012, 12016, 12404, 12410 en 12416.

De informatie in dit document is gebaseerd op apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als u in een levend netwerk werkt, zorg er dan voor dat u de potentiële impact van om het even welke opdracht begrijpt alvorens het te gebruiken.

Conventies

Zie de Cisco Technical Tips Convention voor meer informatie over documentconventies.

Symptomen

Cisco 12000 Series Internet Router gebruikt een gedistribueerde architectuur om optimale verzendprestaties te garanderen. Om hoge die tarieven te steunen, handhaaft het pakketbuffers op zowel de inkomende als uitgaande lijnkaarten. Deze pakketbuffers variëren in grootte en worden over het algemeen ontworpen om maximum Transmission Unit (MTU)-vormige frames te ondersteunen.

Nadat het de uitgaande interface voor een pakje bepaalt, doet de expediteur het volgende:

1. De verzendende processor stuurt een muiswijzer met informatie over het pakket (inclusief de geheugenlocatie) naar de virtuele uitvoerwachtrij van de uitgaande interface.

2. De planner van de lijnkaart geeft een verzoek uit aan de planner. De planner geeft een subsidie uit en het pakje wordt van het buffergeheugen over het overschakelmateriaal naar de uitgaande lijnkaart verzonden.

3. De uitgaande lijnkaart buffert de pakketten.

4. De L3 processor en de bijbehorende Application-Specific Integrated Circuits (ASIC’s) op de uitgaande LC verzenden het pakket naar buiten via de interface.

Als de uitgaande interface wordt oversubscript, begint het de overtollige pakketten te bufferen. Tijdens periodes van aanhoudende overtekening vullen de verzendrijen van de uitgaande LC. In deze conditie gebeurt het volgende afhankelijk van de uitgaande LC:

Motortype uitgaande LC

Reactie op uitgaande congestie

foutenteller

Engine 0 en 1

Zendt een onderdruksignaal. De inkomende interface begint de overtollige pakketten te bufferen.

Genegeerde fouten in de opdrachtoutput van interfaces en/of geen mem daalt in de sleuf <sleuf#> tonen controllers aan om QM stat-opdracht van de inkomende LC uit te voeren, afhankelijk van de L3 Forwarding Engine.¹

Engine 2, 3, 4

druppelt overtollige pakketten op de uitgang.

Geen mem daalt in executie sleuf <sleuf#> tonen controllers van de QM stat opdrachtoutput op de uitgaande LC.

hoger dan de foutmelding voor L3-motoren 0, 1 en 2 op de LC's. Voor vier, 16 en meer poorten op motor 2 LC's zal de genegeerde teller echter niet toenemen.

Op elk intelligent netwerkapparaat, wanneer één of meer hoge snelheids interfaces een relatief snelle interface voeden, treedt een mismatch in interfacetarieven op. Aangezien de langzamere-snelheid uitgaande interface onmogelijk buffers zo snel kan teruggeven als de snellere inkomende interface hen naar de wachtrij van het uitvoerblok stuurt, leidt een vertraging in de bufferterugkeer naar een of ander type druppels. Deze pakketstroom breekt de veronderstelling dat de uitgaande interface de buffer op het tempo van de bufferbeheertijd terugkeert.

Naast een ongelijke verhouding in interfacekaarten, kunnen de genegeerde fouten stijgen wanneer het tempo van aankomende pakketten groter is dan de CPU hen kan verwerken. Deze voorwaarde is zeer zeldzaam op Cisco 12000 en komt meestal voort uit een groot aantal zeer kleine pakketten of wanneer een CPU-intensieve functie, zoals Access Control Lists (ACL’s) of traffic policing, is ingeschakeld op een LC die deze functies in software implementeert. Dit is het geval voor Engine 0 LCs waarbij veel functies in software worden geïmplementeerd. Bij latere motoren worden echter vrijwel alle onderdelen in hardware geïmplementeerd. Bijvoorbeeld, Engine 3 (IP Services Engine - ISE) en Engine 4+ lijnkaarten zijn ontworpen voor Edge-toepassingen en implementeren verbeterde IP-services (zoals Quality of Service - QoS) in hardware zonder effect op de prestaties. Voorbeelden van deze hardware zijn 1-poorts CHOC-48 ISE, 4-poorts CHOC-12 ISE, 16-poorts OC-3 POS ISE, 4-poorts OC-12 POS ISE, 1-poorts OC-48 POS ISE en 1-poorts OC-48 POS ISE.

De genegeerde teller kan ook verhoogd worden wanneer een pakje op een toegangslijnkaart aankomt en een juiste groote pakketbuffer niet beschikbaar is om dit pakket aan te kunnen. Deze voorwaarde is echter zeer zeldzaam en wordt niet in dit document behandeld.

Overabonnement met uitgaande interface beheren

De oplossing om fouten te negeren en geen mem-druppels veroorzaakt door overabonnement van de output interface is hetzelfde voor elk type L3 motor — voorkomt bufferhongersnood. Met andere woorden, we hebben een mechanisme nodig dat verhindert dat de FrFab wachtrijen gevuld worden.

Motoren 0 en 1

Eenvoudig gesteld, wordt de genegeerde teller verhoogd wanneer een pakje op een toegangslijnkaart (LC) aankomt en een juiste groote pakketbuffer niet beschikbaar is om dit pakket aan te pakken. De genegeerde pakketten wijzen dus meestal niet naar een bug in Cisco IOS-software.

Hier is een steekproefuitvoer van het bevel van show interfaces met een niet-nul genegeerde teller op een Cisco 12000 Series router:

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

Wanneer de uitgaande LC een motor 0 of 1 is, stuurt zij een onderdrukbericht naar de andere LC's die hen vragen geen gegevens meer naar die specifieke LC te sturen. De inkomende interface buffert dan de overtollige pakketten in zijn Wachtrijen van ToFab die aan deze bestemmingssleuf beantwoorden.

Om de meest waarschijnlijke oorzaak te isoleren van waarom de genegeerde teller toeneemt, moet u de ToFab wachtrijen van de ingress LC bekijken. U kunt aan de LC toevoegen via de onderhoudspartitie (MBUS) door de attach-opdracht te gebruiken of door de opdracht voor het uitvoeren van de sleuf <slot#> de wachtrijopdracht van controllers om de ToFab-wachtrijen te controleren gebruiken. Voer deze opdracht een paar keer uit en kijk naar de volgende symptomen:

- Een dalende en lage waarde of waarde van 0 in de #Qelem-kolom van een vrije wachtrij zonder IPC

- Een grote waarde in de #Qelem kolom in een rij van de doelsleuven.

Motoren 2, 3, 4

Lijnkaarten die een meer recente L3-motorarchitectuur gebruiken, gebruiken geen backpressiemechanisme. In plaats daarvan, wanneer de interface wordt oversubscript en een FrFab-wachtrij wordt uitgeput, worden de pakketten eenvoudigweg verzonden als ze op de betreffende lijnkaart aankomen.

Modus 2 LC's vallen niet terug in het volgende grotere bufferbassin wanneer een kleiner bassin wordt uitgeput. Het "fall-back" - mechanisme is alleen geïmplementeerd voor Engine 2 LC's aan de kant ToFab (RX). Als dit gebeurt, zal de "bump count" teller hoger zijn in de uitvoer van de executieve sleuf <slot> die controller toont om QM stat-opdracht te uitvoeren.

Deze vallen worden geteld als geen mem daalt in de uitvoer van de uitzetsleuf <sleuf#> die controllers van de QM stat-opdracht tonen, zoals hieronder wordt geïllustreerd:

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

U moet een manier vinden om te voorkomen dat de FrFab-zijde buffert naar het punt waar de LC ofwel de back-up naar de inkomende interface maakt of gewoon de pakketten laat vallen.

Een simpele oplossing voor alle lijnkaarten, behalve Engine 2 LCs, is het aantal buffers te verminderen beschikbaar voor een bepaalde uitgaande interface op een multi-interface LC. Standaard kan een interface alle opgeslagen FrFab-buffers gebruiken. Gebruik de opdracht limiet-wachtrij om een waarde te configureren die geen standaard is. Dit voorkomt de stress LC van het bufferen van meer dan het gevormde aantal pakketten op de interfacerij voor die specifieke haven. Stel dit nummer laag genoeg in, zodat het niet alle FrFab-wachtrijen voor deze interface bevat. Let op dat deze methode geen onderscheid maakt tussen pakketten met hoge en lage prioriteit en simpelweg een munt implementeert die agressiever daalt voor een bepaalde interface.

Engine 3 lijnkaarten vereisen het gebruik van modulaire QoS CLI (MQC) in plaats van de bestaande Opdracht Line Interface (CLI). Deze opdracht wordt niet ondersteund op de lijnkaarten van Engine 2.

Hier is een configuratievoorbeeld dat de CoS-configuratie (legacy Class of Service) gebruikt:

interface POS 0/0

tx-queue-limit <max Q length in packets>

Hier is een configuratievoorbeeld in MQC:

policy-map TX_QUEUE_LIMIT

class class-default

queue-limit

interface POS 0/0

service-policy out TX_QUEUE_LIMIT

Een andere oplossing is een snellere output interface te implementeren, wat ons een grotere buis geeft. Maar grotere buizen kunnen snel vullen. De aanbevolen oplossing is dus QoS-mechanismen (Quality of Service) op de uitgaande LC te implementeren.

De optie Weighted Random Early Detection (WRED) van Cisco implementeert een gedifferentieerd of intelligent drop-mechanisme. Het is ontworpen om met adaptief verkeer te werken, zoals TCP stromen. Het controleert de rijgrootte en werkt om een consistente gemiddelde rijgrootte te handhaven door pakketten willekeurig uit verschillende stromen te laten vallen terwijl de berekende gemiddelde rij boven een configureerbare minimum drempel stijgt.

Wanneer geïmplementeerd op Cisco 12000 Series, kan WRED voorkomen dat de FrFab-wachtrijen worden gevuld en, belangrijker, is selectief over welke pakketten het dropt. Engine 0 LC's ondersteunen WRED in software, terwijl Engine 1 LC's WRED helemaal niet ondersteunen. De andere L3 Engine LC's ondersteunen WRED in hardware.

Raadpleeg voor meer informatie over het configureren van WRED deze documenten:

- Weighted Random vroege Detectie op Cisco 12000 Series router

- MPLS CoS configureren op een Cisco 12000 Series GSR-router

Dit mechanisme voor congestievermijding werkt alleen in een TCP-gebaseerde omgeving. TCP reageert op de juiste manier - en zelfs robuust - op verkeersdruppels door de verkeerstransmissie te vertragen. Zie Hoe TCP verkeersverlies verwerkt en hoe de router met TCP interageert voor details over hoe TCP op pakketverlies reageert.

Een ander ondersteund QoS-mechanisme op Cisco 12000 Series is traffic policing met behulp van Committed Access Rate (CAR) op Engine 0 en Engine 1 LCs, en een aangepaste versie van CAR bekend als Per Interface Rate Control (PIRC) op engine 2 LCs. Configureer traffic policing op de uitgaande interface.

Overladen CPU op de inkomende lijnkaart beheren

Deze situatie is zeer zeldzaam!

U kunt controleren of de CPU op de binnenkomende LC is overbelast met behulp van de opdracht voor het uitvoeren van <sleuf#> tofab wachtrijen voor controllers tonen. Als u een zeer groot aantal in de #Qelem-kolom van de rij "Ruw Wachtrij" ziet, betekent dit dat te veel pakketten bedoeld zijn om door de CPU (die zich op de LC zelf bevindt) te worden verwerkt. U zult genegeerde pakketten beginnen te krijgen omdat de CPU niet met de hoeveelheid pakketten kan doorgaan. Deze pakketten worden gericht op de CPU van de LC, niet op de Gigabit-routeprocessor (GRP)!

Wat u op dit moment moet doen is een deel van het verkeer van deze inkomende LC verschuiven zodat zijn CPU minder wordt beïnvloed.

U dient ook een kijkje te nemen in de LC-configuratie om te controleren of er functies zijn geconfigureerd die een invloed hebben op de CPU. Sommige functies (zoals CAR, ACL en NetFlow) kunnen de prestaties van de LC verslechteren wanneer deze in software wordt geïmplementeerd (alleen op Engine 0 LCs). Als dit probleem zich voordoet, dient u dienovereenkomstig te handelen door de optie te verwijderen of de Cisco IOS-software te verbeteren naar een latere release waar dezelfde functies-implementatie is verbeterd (zoals Turbo ACL). Zie Releaseopmerkingen van Cisco 12000 Series routers om te weten te komen welke functies zijn geïmplementeerd of verbeterd voor verschillende LC’s.

Ten slotte zou de enige oplossing kunnen zijn de LC te ruilen voor een recentere datum wanneer de gevraagde optie in de hardware wordt geïmplementeerd. Dit hangt echt af van het motortype van de LC.

U kunt de volgende snelopdracht gebruiken om het L3-motortype van een LC te bepalen:

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)

...

Opmerking: Engine 3 (IP Services Engine - ISE) en Engine 4+ lijnkaarten zijn ontworpen voor Edge-toepassingen en implementeren verbeterde IP-services (zoals QoS) in hardware zonder effect op de prestaties.

Samenvatting van de ontwerprichtsnoeren

- Gebruik Turbo ACL’s, die de prestaties optimaliseren door de router toe te staan om de ACL’s te compileren voordat u ze aan de LC-processor downloaden.

- Gebruik het "logwoord" niet op ACL’s.

- Vermijd het verlaten van ACL's wanneer mogelijk. In een systeem met motor 0, 1 en 2 LC's wordt alle verwerking van ACL's uitgevoerd op de inkomende LC. Zelfs uitgaande ACL-filtering wordt op de inkomende kaart uitgevoerd als het weet naar welke uitgaande interface het pakket is bestemd. Om deze reden, het configureren van een uitgaande ACL op een interface beïnvloedt alle LCs in het systeem. Daarnaast kunnen Engine 2 LC's binnenkomende of uitgaande ACL's uitvoeren, maar niet beide tegelijkertijd in de ASIC die hardware-expediteur uitvoert. Als u zowel inkomende als uitgaande ACL’s vormt, valt de LC terug naar CPU-gebaseerd verzenden voor uitgaande toegangslijsten, wat de switchprestaties van de LC beïnvloedt. nieuwere motoren zoals Engine 3 en Engine 4+ zijn echter zeer geoptimaliseerd voor verbeterde IP-services zoals ACL’s en verwerken uitgaande ACL’s op de uitgaande LC.

- Pas verkeer aan dat specifieke eigenschappen vereist aan één reeks LCs.

- Wijs verkeer toe dat geen eigenschappen aan een andere reeks LCs vereist om de piekprestaties van het pakkettransport te handhaven.

- Gebruik LC's met hogere motortypen wanneer hoge prestaties nodig zijn.

- Design backbone- of core-face LC's om functies uit te voeren die ondersteund worden door hardware of microcode.

casestudy

Deze casestudy toont hoe u problemen kunt oplossen met het vergroten van genegeerde fouten op een interface van een LC in sleuf 6.

Stap 1 - Controleer de ToFab wachtrijen in sleuf 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

Stap 2 - Controleer de FrFab-wachtrijen in sleuf 4.

Aangezien de uitvoer van de Voorkant van ToFab op een groot aantal in de wachtrij staande pakketten voor de LC in sleuf 4 wees, controleert u de wachtrijen van de FrFab op deze 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

Stap 3 - Vergelijk de uitvoer van de opdracht showinterfaces voor dezelfde overgeplaatste interface.

Stem de oversubscribed interface aan die in de show controllers van de wachtrij wordt aangegeven met de show interfaces uitvoer voor dezelfde interface. De volgende output bevestigt dat de output interface rate op de lijnsnelheid is en oversubscript is:

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

Stap 4 - Voer een oplossing in.

Zie de delen van dit document met oplossingen voor de volgende stappen om groeiende genegeerde fouten op te lossen die zijn gebaseerd op de architectuur van de betreffende uitgaande interface. Bijvoorbeeld, op Engine 0 LC, probeer wat verkeer naar een andere interface om te leiden of, als tijdelijke maatregel, het aantal pakketbuffers te verminderen die deze specifieke interface kan gebruiken van de vrije rijen van de lijnkaart. Gebruik de volgende opdracht:

Router(config)#int POS 4/2

Router(config-if)#tx-queue-limit 5000

Cisco IOS-softwarefabels

Soms telt increment toe vanwege een Cisco IOS softwaredefect. Zorg ervoor dat u de nieuwste beschikbare Cisco IOS-softwarerelease in uw trein draait om alle insecten weg te halen die al zijn gerepareerd. Als u nog steeds genegeerde pakketten ziet, en de informatie in dit document uw probleem niet oplost, neem contact op met het Cisco Technical Assistance Center (TAC) voor assistentie.

Gerelateerde informatie

- Stapels voor probleemoplossing in de Cisco 12000 Series Internet-router

- Hoe de Uitvoer van de showcontrollers lezen | Opdrachten voor tofab-wachtrij

- Weighted Random Early Detection op Cisco 12000 Series Internet-router

- MPLS CoS configureren op een Cisco 12000 Series GSR-router

- Hoe TCP verkeersverlies verwerkt

- Hoe de router met TCP reageert

- Committed Access Rate instellen

- Releaseopmerkingen van Cisco 12000 Series routers

- Technische ondersteuning en documentatie – Cisco Systems