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.
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.
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.
Zie de Cisco Technical Tips Convention voor meer informatie over documentconventies.
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:
De verzendende processor stuurt een muiswijzer met informatie over het pakket (inclusief de geheugenlocatie) naar de virtuele uitvoerwachtrij van de uitgaande interface.
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.
De uitgaande lijnkaart buffert de pakketten.
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.
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.
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.
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:
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.
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.
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.
Deze casestudy toont hoe u problemen kunt oplossen met het vergroten van genegeerde fouten op een interface van een LC 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
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
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
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
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.