Uitvoer van probleemoplossing met prioriteitswachtrij

Inleiding

Dit document geeft tips over hoe u uitvoerdruppels moet oplossen die het gevolg zijn van een prioriteitsconfiguratie van het wachtrij op een routerinterface.

Voorwaarden

Vereisten

Lezers van dit document moeten bekend zijn met deze concepten:

• prioritair-groep of frame-relais prioriteitsgroep-schakelt Cisco erfenis prioriteitswachtrij in. Ondersteunt tot vier niveaus van prioriteitswachtrijen.

• IP RTP-prioriteit of Frame Relay-IP RTP-prioriteit - Overeenkomsten op UDP-poortnummers voor Real-Time Protocol (RTP)-verkeer dat VoIP-pakketten inkapselt en deze pakketten in een prioriteitswachtrij plaatst.

• prioriteit - hiermee wordt de LLQ-functie (Low Latency Queueing) van Cisco ingeschakeld en wordt de opdrachtstructuur van de modulaire kwaliteit van de QoS-interface (CLI) voor serviceproviders gebruikt.

Een router kan uitvoerdruppels melden wanneer een van deze methoden is geconfigureerd, maar er zijn belangrijke functionele verschillen tussen de methoden en de reden voor vallen in elk geval.

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 mogelijke impact van een opdracht begrijpt voordat u het gebruikt.

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

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

Raadpleeg voor meer informatie over documentconventies conventies die in Cisco Technical Tips zijn gebruikt.

Droogt af met IP rtp prioriteit en LLQ

De Cisco IOS Configuration Guide waarschuwt voor uitvoerdruppels met deze prioriteitswachtrij:

• prioriteit ip : Omdat de opdracht om de prioriteit van ip te bepalen absolute prioriteit geeft boven ander verkeer, moet het met zorg worden gebruikt. Als het verkeer de geconfigureerde bandbreedte overschrijdt, wordt het overtollige verkeer in het geval van congestie verlaagd.

• prioriteitsopdracht en LLQ: Wanneer u de prioriteit opdracht voor een klasse specificeert, neemt het een bandbreedte argument dat maximale bandbreedte geeft. In geval van congestie, wordt het toezicht gebruikt om pakketten te laten vallen wanneer de bandbreedte wordt overschreden.

Deze twee mechanismen maken gebruik van een ingebouwde politieagent om de verkeersstromen te meten. Het doel van de politieagent is ervoor te zorgen dat de andere wachtrijen door de planner worden onderhouden. In de oorspronkelijke optie van de prioriteitswachtrij van Cisco, die de opdrachten van de prioriteitsgroep en de prioriteitslijst gebruikt, heeft de planner altijd eerst de wachtrij met de hoogste prioriteit onderhouden. Als er altijd verkeer was in de rij met hoge prioriteit, waren de rijen met lagere prioriteit uitgehongerd van bandbreedte en pakketten gingen naar wachtrijen met geen prioriteit.

Droogt bij Legacy Priority-wachtrij

Prioritaire wachtrij (PQ) is het prioriteitswachtrij voor cisco. Zoals hieronder wordt geïllustreerd, ondersteunt PQ maximaal vier niveaus van wachtrijen: hoog, gemiddeld, normaal en laag.

Het inschakelen van prioriteitswachtrij op een interface verandert de weergave in de uitvoerwachtrij, zoals hieronder wordt weergegeven. Voordat u een prioriteitswachtrij voor de Ethernet-interface maakt, gebruikt u één wachtrij voor uitvoerbestanden met de standaardwachtrijgrootte van 40 pakketten.

R6-2500# show interface ethernet0 
Ethernet0 is up, line protocol is up 
  Hardware is Lance, address is 0000.0c4e.59b1 (bia 0000.0c4e.59b1) 
  Internet address is 42.42.42.2/24 
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255 
  Encapsulation ARPA, loopback not set, keepalive set (10 sec) 
  ARP type: ARPA, ARP Timeout 04:00:00 
  Last input 00:00:03, output 00:00:02, output hang never 
  Last clearing of "show interface" counters never 
  Queueing strategy: fifo 
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops 
  5 minute input rate 0 bits/sec, 0 packets/sec 
  5 minute output rate 0 bits/sec, 0 packets/sec 
     239407 packets input, 22644297 bytes, 0 no buffer 
     Received 239252 broadcasts, 0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     0 input packets with dribble condition detected 
     374436 packets output, 31095372 bytes, 0 underruns 
     0 output errors, 1 collisions, 13 interface resets 
     0 babbles, 0 late collision, 8 deferred 
     0 lost carrier, 0 no carrier 
     0 output buffer failures, 0 output buffers swapped out

Na het inschakelen van PQ gebruikt de Ethernet-interface nu vier prioriteitswachtrijen met verschillende wachtrijbeperkingen, zoals in de onderstaande uitvoer wordt weergegeven:

R6-2500(config)# interface ethernet0 
R6-2500(config-if)# priority-group 1 
R6-2500(config-if)# end 
R6-2500# show interface ethernet 0 
Ethernet0 is up, line protocol is up 
  Hardware is Lance, address is 0000.0c4e.59b1 (bia 0000.0c4e.59b1)
  Internet address is 42.42.42.2/24 
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255 
  Encapsulation ARPA, loopback not set, keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00 
  Last input 00:00:03, output 00:00:03, output hang never 
  Last clearing of "show interface" counters never 
  Input queue: 0/75/0 (size/max/drops); Total output drops: 0
  Queueing strategy: priority-list 1 
  Output queue (queue priority: size/max/drops): 
     high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/0 
  5 minute input rate 0 bits/sec, 0 packets/sec 
  5 minute output rate 0 bits/sec, 0 packets/sec 
     239411 packets input, 22644817 bytes, 0 no buffer
     Received 239256 broadcasts, 0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     0 input packets with dribble condition detected 
     374440 packets output, 31095658 bytes, 0 underruns
     0 output errors, 1 collisions, 14 interface resets
     0 babbles, 0 late collision, 8 deferred 
     0 lost carrier, 0 no carrier 
     0 output buffer failures, 0 output buffers swapped out

De prioriteit-lijst {lijst-aantal} opdracht wordt gebruikt om verkeersstromen aan een specifieke rij toe te wijzen. Aangezien de pakketten op een interface arriveren, worden de prioriteitsrijen op die interface gescand voor pakketten in een afnemende volgorde van prioriteit. De rij met hoge prioriteit wordt eerst gescand, dan de rij met gemiddelde prioriteit, enzovoort. Het pakje aan het hoofd van de rij met de hoogste prioriteit wordt gekozen voor transmissie. Deze procedure wordt telkens herhaald wanneer een pakje wordt verzonden.

Elke rij wordt gedefinieerd door een maximale lengte of door het maximale aantal pakketten dat de rij kan bevatten. Wanneer een aankomend pakket de huidige wachtrijdiepte om de geconfigureerde rijlimiet te overschrijden, zou veroorzaken, wordt het pakket gedropt. Zoals hierboven vermeld, is een daling van de uitvoer met PQ doorgaans het gevolg van het overschrijden van de wachtrijlimiet en niet van een interne politieagent, zoals het geval is met LLQ. De opdracht prioriteitenlijst lijst-nummer-limiet verandert de grootte van een prioriteitswachtrij.

Verkeersmeting met een Token Bucket

LLQ en IP RTP Prioriteit voert de ingebouwde politieagent uit door een symbolische emmer als systeem voor het meten van verkeer te gebruiken. In dit deel wordt gekeken naar het symbolische emmer-concept.

Een emmer heeft zelf geen teruggooi- of prioriteitsbeleid. De symbolische emmer werkt op de volgende manieren:

• Tokens worden tegen een bepaalde snelheid in de emmer gestopt.

• Elke token geeft toestemming voor de bron om een bepaald aantal bits in het netwerk te versturen.

• Als u een pakket wilt verzenden, moet de verkeersregelaar in staat zijn om een aantal penningen uit de emmer van gelijke weergave naar de pakketgrootte te verwijderen.

• Als er niet genoeg penningen in de emmer zijn om een pakje te verzenden, wacht het pakket totdat de emmer genoeg penningen heeft (in het geval van een vormgever) of het pakket is weggegooid of afgedrukt (in het geval van een politieagent).

• De emmer heeft zelf een bepaalde capaciteit. Als de emmer gevuld is met capaciteit, worden nieuw aangekomen penningen weggegooid en zijn ze niet beschikbaar voor toekomstige pakketten. Op elk moment is de grootste uitbarsting die een toepassing naar het netwerk kan sturen ruwweg evenredig met de omvang van de emmer. Een symbolische emmer maakt burstentie mogelijk, maar verdeelt het.

Laten we een voorbeeld bekijken met pakketten en een geëngageerd informatiesnelheid (CIR) van 8000 bps.

• In dit voorbeeld, beginnen de aanvankelijke symbolische emmers vol bij 1000 bytes.

• Wanneer een pakket van 450 bytes arriveert, voldoet het pakket aan de woorden omdat er genoeg bytes in het conform geheugen beschikbaar zijn. Het pakket wordt verzonden, en 450 bytes worden verwijderd van de token emmer, waardoor 550 bytes achterblijven.

• Wanneer het volgende pakket 0,25 seconden later arriveert, worden 250 bytes toegevoegd aan het token emmer (0,25 * 8000)/8), waardoor 700 bytes in het token emmer achterblijven. Als het volgende pakje 800 bytes is, overschrijdt het pakje en wordt het ingetrokken. Geen bytes worden uit de penning gehaald.

Stappen voor probleemoplossing bij het afdrogen van diagnoses

Stap 1 - Verzamel gegevens

De stappen om gegevens te verzamelen worden hieronder weergegeven.

1. Voer de volgende opdrachten verschillende malen uit en controleer hoe snel en hoe vaak de toename van de druppels is. Gebruik de uitvoer om een basislijn van uw verkeerspatronen en verkeersniveaus vast te stellen. Stel in wat de "normale" druppelsnelheid op de interface is.

   • interface voor wachtrij tonen

     router# show queueing interface hssi 0/0/0
               Interface Hssi0/0/0 queueing strategy: priority
     
               Output queue utilization (queue/count)
     
                high/12301 medium/4 normal/98 low/27415

   • interface tonen - Controleer de laadwaarde die in de uitvoer wordt weergegeven. Zorg er bovendien voor dat de som van de tellingen per wachtrij in de uitvoer van de showinterface gelijkwaardig is aan de tellen van de uitvoerdruppels. De teller van de uitvoer van de show interface moet het totale totaal van alle druppels op uitvoer weergeven, inclusief WRED teruggooi, teruggooi vanwege buffertekorten ("geen buffer"-fouten) en zelfs weggegooid geheugen van de poortadapter.

     router# show interface serial 4/1/2
     
     Serial4/1/2 is up, line protocol is up 
     Hardware is cyBus Serial 
     Description: E1 Link to 60W S9/1/2 Backup 
     Internet address is 169.127.18.228/27 
     MTU 1500 bytes, BW 128 Kbit, DLY 21250 usec, rely 255/255, load 183/255 
     Encapsulation HDLC, loopback not set, keepalive set (10 sec) 
     Last input 00:00:00, output 00:00:00, output hang never 
     Last clearing of "show interface" counters 5d10h 
     Input queue: 0/75/0 (size/max/drops); Total output drops: 68277 
     Queueing strategy: priority-list 7 
     Output queue: high 0/450/0, medium 0/350/143, normal 0/110/27266, low 0/100/40868 
     5 minute input rate 959000 bits/sec, 419 packets/sec 
     5 minute output rate 411000 bits/sec, 150 packets/sec 
     144067307 packets input, 4261520425 bytes, 0 no buffer 
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
     42 input errors, 34 CRC, 0 frame, 0 overrun, 1 ignored, 8 abort 
     69726448 packets output, 2042537282 bytes, 0 underruns 
     0 output errors, 0 collisions, 0 interface resets 
     0 output buffer failures, 46686454 output buffers swapped out 
     0 carrier transitions

     N.B.: Sommige interfaces geven afzonderlijke "txload"- en "rxload"-waarden weer.

     Hssi0/0/0 is up, line protocol is up 
      Hardware is cyBus HSSI 
      MTU 1500 bytes, BW 7500 Kbit, DLY 200 usec, 
      reliability 255/255, txload 138/255, rxload 17/255 
      Encapsulation FRAME-RELAY IETF, crc 16, loopback not set 
      Keepalive set (5 sec) 
      LMI enq sent 4704, LMI stat recvd 4704, LMI upd recvd 0, DTE LMI up 
      LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 
      LMI DLCI 1023 LMI type is CISCO frame relay DTE 
      Broadcast queue 0/256, broadcasts sent/dropped 8827/0, interface 
      broadcasts 7651 
      Last input 00:00:00, output 00:00:00, output hang never 
      Last clearing of "show interface" counters 06:31:58 
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 84 
      Queueing strategy: priority-list 1 
      Output queue (queue priority: size/max/drops): 
      high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/84 
      5 minute input rate 524000 bits/sec, 589 packets/sec 
      5 minute output rate 4080000 bits/sec, 778 packets/sec 
      11108487 packets input, 1216363830 bytes, 0 no buffer 
      Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
      0 parity 
      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
      15862186 packets output, 3233772283 bytes, 0 underruns 
      0 output errors, 0 applique, 1 interface resets 
      0 output buffer failures, 2590 output buffers swapped out 
      0 carrier transitions 
      LC=down CA=up TM=down LB=down TA=up LA=down

   • toon beleid-kaart interface interface-naam - zoek naar een niet-nul waarde voor de "pkts discards" teller.

     Router# show policy-map interface s1/0
      Serial1/0.1: DLCI 100 -
      output : mypolicy
       Class voice
        Weighted Fair Queueing
            Strict Priority
            Output Queue: Conversation 72 
              Bandwidth 16 (kbps) Packets Matched 0
             (pkts discards/bytes discards) 0/0
       Class immediate-data
        Weighted Fair Queueing
            Output Queue: Conversation 73 
              Bandwidth 60 (%) Packets Matched 0
              (pkts discards/bytes discards/tail drops) 0/0/0
              mean queue depth: 0
              drops: class  random   tail     min-th   max-th   mark-prob 
                     0      0        0        64       128      1/10
                     1      0        0        71       128      1/10
                     2      0        0        78       128      1/10
                     3      0        0        85       128      1/10
                     4      0        0        92       128      1/10
                     5      0        0        99       128      1/10
                     6      0        0        106      128      1/10
                     7      0        0        113      128      1/10
                     rsvp   0        0        120      128      1/10

     Opmerking: de volgende voorbeelduitvoer geeft overeenkomende waarden weer voor de "pakketten" en "pkts mating"-tellers. Deze voorwaarde geeft aan dat een groot aantal pakketten wordt verwerkt of dat de interface extreme files ervaart. Beide voorwaarden kunnen ertoe leiden dat de wachtrijlimiet van een klasse wordt overschreden en moeten worden onderzocht.

     router# show policy-map interface
     
     Serial4/0 
     
     Service-policy output: policy1 
     
     Class-map: class1 (match-all) 
     189439 packets, 67719268 bytes 
     5 minute offered rate 141000 bps, drop rate 0 bps 
     Match: access-group name ds-class-af3 
     Weighted Fair Queueing 
     Output Queue: Conversation 265 
     Bandwidth 50 (%) Max Threshold 64 (packets) 
     (pkts matched/bytes matched) 189439/67719268 
     (depth/total drops/no-buffer drops) 0/0/0

2. Tekenen de verkeersstromen en de pakketten in die stromen.

   • Wat is de gemiddelde pakketgrootte?

   • In welke richting stroomt het met een MTU grote frame? Veel verkeersstromen zijn asynchroon qua lading. Bijvoorbeeld, met een download van FTP, stromen de meeste van de pakketten van de grootte van MTU van de server van FTP naar client. Packets van de FTP-client naar de server zijn eenvoudige TCP-ACK’s.

   • Gebruikt de pakketten TCP of UDP? TCP staat elke stroom toe om een geautoriseerd aantal pakketten te verzenden voordat de bron transmissie moet opschorten en tot de bestemming moet wachten om de verzonden pakketten te erkennen.

3. Bepaal met Frame Relay of de druppels in de interfacestrijd of in een per-VC wachtrij voorkomen. In het volgende schema wordt de stroom van pakketten door een virtueel circuit van Frame Relay geïllustreerd:

   

4. Prioritaire wachtrij ondersteunt maximaal vier uitvoerwachtrijen, één per prioriteitsniveau in de wachtrij en elke wachtrij wordt gedefinieerd door een wachtrijlimiet. Het wachtrijen-systeem controleert de grootte van de wachtrij aan de hand van de geconfigureerde rijlimiet voordat u het pakket in een wachtrij plaatst. Als de geselecteerde rij vol is, daalt de router het pakje. Probeer de wachtrijgrootte te vergroten met de prioriteit-lijst {#} de bevelhebber-limiet en hervat controle.

Stap 2 - Zorg voor voldoende bandbreedte

Met LLQ maakt het toezicht een eerlijke behandeling mogelijk van andere gegevenspakketten in andere op klasse gebaseerde gewogen fair lange wachtrijen (CBWFQ) of WFQ wachtrijen. Om pakketdalingen te vermijden, moet u zeker een optimale hoeveelheid bandbreedte aan de prioritaire rij toewijzen, met inachtneming van het type van gebruikte codec en interfacekaarten. IP RTP-prioriteit zal geen verkeer boven het toegewezen bedrag toestaan.

Het is altijd het veiligst om iets meer dan de bekende vereiste hoeveelheid bandbreedte aan de prioriteitswachtrij toe te wijzen. Bijvoorbeeld, veronderstel u toegewezen 24 kbps bandbreedte, het standaardbedrag vereist voor spraaktransmissie, aan de prioriteitenrij. Deze toewijzing lijkt veilig omdat de overdracht van spraakpakketten bij een constante bitsnelheid plaatsvindt. Maar omdat het netwerk en de router of switch een deel van de bandbreedte kunnen gebruiken om bitter en vertraging te produceren, garandeert de toewijzing iets meer dan de vereiste hoeveelheid bandbreedte (zoals 25 kbps) constant en beschikbaar.

De bandbreedte die voor een prioriteitswachtrij wordt toegewezen, bevat altijd de Layer 2-insluitingsheader. Het omvat niet de cyclische overtollige controle (CRC). (Raadpleeg Welke bytes worden door IP geteld naar ATM CoS Queueing? voor meer informatie . ) Hoewel het slechts een paar bytes zijn, legt CRC een stijgende impact op omdat de verkeersstromen een hoger aantal kleine pakketten omvatten.

Bovendien omvat de bandbreedte die op ATM-interfaces wordt toegewezen voor een prioriteitswachtrij niet de volgende ATM-celbelasting:

• AnyPadding door de segmentatie en herassemblage (SAR) om de laatste cel van een pakket met een nog veelvoud van 48 bytes te maken.

• 4-poorts CRC van ATM Adapter Layer 5 (AAL5) trailer.

• 5-bits ATM-celkop.

Wanneer u de hoeveelheid bandbreedte berekent die voor een bepaalde prioriteitsklasse moet worden toegewezen, moet u rekening houden met het feit dat Layer 2 headers zijn opgenomen. Wanneer ATM wordt gebruikt, moet u rekening houden met het feit dat de overhead van de ATM-celbelasting niet wordt inbegrepen. U moet ook bandbreedte voor de mogelijkheid van jitter die door netwerkapparaten in het stempad wordt geïntroduceerd toestaan. Raadpleeg het Overzicht van de Low Latency Queueing.

Wanneer u prioriteitswachtrij gebruikt voor het vervoer van VoIP-pakketten, raadpleegt u Voice-over-IP - Per Call Bandbreedteswitch-verbruik.

Stap 3 - Zorg voor voldoende barstgrootte

De behandeling van een reeks pakketten die een interface door een prioriteitswachtrij verlaten, is afhankelijk van de grootte van het pakket en het aantal bytes dat in de token resteert. Het is belangrijk om rekening te houden met de kenmerken van de verkeersstroom die naar de prioriteitswachtrij wordt gericht, omdat LLQ een politieagent gebruikt en geen vormer. Een politieagent gebruikt een emmer met penning als volgt:

• De emmer is gevuld met penningen op basis van het aantal klassen tot een maximum van de barstparameter.

• Als het aantal penningen groter is dan of gelijk is aan de pakketgrootte, wordt het pakket verzonden, en wordt de symbolische emmer verminderd. Anders wordt het pakje ingetrokken.

De standaard burst waarde van LLQ's token bucket-verkeersmeter wordt berekend als 200 milliseconden van verkeer met de ingestelde bandbreedte-snelheid. In sommige gevallen is de standaardwaarde ontoereikend, vooral wanneer TCP-verkeer naar de prioriteitswachtrij gaat. TCP-stromen zijn doorgaans barstend en kunnen een barstgrootte vereisen die groter is dan de default die wordt toegewezen door het wachtrijen-systeem, met name bij langzame koppelingen.

De volgende steekproefuitvoer werd gegenereerd op een ATM PVC met een aanhoudende celsnelheid van 128 kbps. Het systeem voor wachtrijen past de barstgrootte aan aangezien de waarde die met de prioriteitsopdracht is opgegeven, verandert.

7200-17# show policy-map int atm 4/0.500
 ATM4/0.500: VC 1/500 - 
  
Service-policy output: drops 

    Class-map: police (match-all)
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any 
      Weighted Fair Queueing 
        Strict Priority 
        Output Queue: Conversation 24 
        Bandwidth 90 (%) 
        Bandwidth 115 (kbps) Burst 2875 (Bytes) 
        
!--- Burst value of 2875 bytes is assigned when !--- the reserved bandwidth value is 115 kbps. 

        (pkts matched/bytes matched) 0/0 
        (total drops/bytes drops) 0/0 

    Class-map: class-default (match-any) 
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any 

7200-17# show policy-map int atm 4/0.500 
 ATM4/0.500: VC 1/500 - 

  Service-policy output: drops 

    Class-map: police (match-all) 
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any 
      Weighted Fair Queueing 
        Strict Priority 
        Output Queue: Conversation 24 
        Bandwidth 50 (%) 
        Bandwidth 64 (kbps) Burst 1600 (Bytes) 
        
!--- Burst value changes to 1600 bytes when the !--- reserved bandwidth value is changed to 64 kbps. 

        (pkts matched/bytes matched) 0/0 
        (total drops/bytes drops) 0/0 

    Class-map: class-default (match-any) 
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any

De functionaliteit van LLQ werd uitgebreid om een configureerbare burst (BC) grootte met de configuratie Burst Size in Low Latency Queueing mogelijk te maken. Met deze nieuwe functionaliteit kan het netwerk nu tijdelijke bursten van verkeer verwerken en netwerkverkeer efficiënter verwerken.

Gebruik de burst parameter met de prioriteit opdracht om de burst waarde van 1600 bytes te verhogen naar 3200 bytes.

policy-map AV 
  class AV 
  priority percent 50 3200

Opmerking: Een hoge waarde verhoogt de effectieve bandbreedte die de prioriteitsklasse kan gebruiken en kan de verschijning geven dat de prioriteitsklassen meer dan hun eerlijk aandeel in de bandbreedte krijgen.

Daarnaast heeft het wachtrijen-systeem oorspronkelijk een interne rijlimiet van 64 pakketten toegewezen aan de wachtrij. In sommige gevallen, wanneer een barst van 64 pakketten bij de prioritaire rij aankwam, zou de verkeersmeter bepalen dat de barst aan de geconfigureerde snelheid overeenkwam, maar het aantal pakketten overtrof de rijlimiet. Hierdoor werden sommige pakketten achtergelaten. Cisco bug-ID CSCdr51979 (alleen geregistreerde klanten) lost dit probleem op door de prioriteit in de wachtrij de grootte zo diep mogelijk door de verkeersmeter te laten groeien.

De volgende uitvoer werd opgenomen op een Frame Relay PVC dat is geconfigureerd met een CIR van 56 kbps. In de eerste set steekproefuitvoer is het gecombineerde aangeboden tarief van de c1- en c2-klassen 76 kbps. De reden hiervoor is dat de berekende waarden van de aangeboden tarieven minus de verlaagde tarieven niet de werkelijke transmissietarieven weergeven en geen pakketten bevatten die in de vormer zitten voordat ze worden verzonden.

router# show policy-map int s2/0.1
  Serial2/0.1: DLCI 1000 - 

   Service-policy output: p 

     Class-map: c1 (match-all) 
       7311 packets, 657990 bytes 
       30 second offered rate 68000 bps, drop rate 16000 bps 
       Match: ip precedence 1 
       Weighted Fair Queueing 
         Strict Priority 
         Output Queue: Conversation 24 
         Bandwidth 90 (%) 
         Bandwidth 50 (kbps) Burst 1250 (Bytes) 
         (pkts matched/bytes matched) 7311/657990 
         (total drops/bytes drops) 2221/199890 

     Class-map: c2 (match-all) 
       7311 packets, 657990 bytes 
       30 second offered rate 68000 bps, drop rate 44000 bps 
       Match: ip precedence 2 
       Weighted Fair Queueing 
         Output Queue: Conversation 25 
         Bandwidth 10 (%) 
         Bandwidth 5 (kbps) Max Threshold 64 (packets) 
         (pkts matched/bytes matched) 7310/657900 
         (depth/total drops/no-buffer drops) 64/6650/0 

     Class-map: class-default (match-any) 
       2 packets, 382 bytes 
       30 second offered rate 0 bps, drop rate 0 bps 
       Match: any

In deze tweede set van output zijn de tellers van de showbeleid-plattegrond genormaliseerd. Op het 56 kbps PVC verzonden de klasse c1 ongeveer 50 kbps en de klasse c2 zendt ongeveer 6 kbps.

router# show policy-map int s2/0.1 
  Serial2/0.1: DLCI 1000 - 

   Service-policy output: p 

     Class-map: c1 (match-all) 
       15961 packets, 1436490 bytes 
       30 second offered rate 72000 bps, drop rate 21000 bps 
       Match: ip precedence 1 
       Weighted Fair Queueing 
         Strict Priority 
         Output Queue: Conversation 24 
         Bandwidth 90 (%) 
         Bandwidth 50 (kbps) Burst 1250 (Bytes) 
         (pkts matched/bytes matched) 15961/1436490 
         (total drops/bytes drops) 4864/437760 

     Class-map: c2 (match-all) 
       15961 packets, 1436490 bytes 
       30 second offered rate 72000 bps, drop rate 66000 bps 
       Match: ip precedence 2 
       Weighted Fair Queueing 
         Output Queue: Conversation 25 
         Bandwidth 10 (%) 
         Bandwidth 5 (kbps) Max Threshold 64 (packets) 
         (pkts matched/bytes matched) 15960/1436400 
         (depth/total drops/no-buffer drops) 64/14591/0 

     Class-map: class-default (match-any) 
       5 packets, 1096 bytes 
       30 second offered rate 0 bps, drop rate 0 bps 
       Match: any

Stap 4 - Ontvang prioriteit

De opdracht debugprioriteit geeft prioriteitswachtrij voor uitvoer weer indien pakketten uit de prioriteitswachtrij worden gedropt.

Voorzichtig:  Voordat u debug-opdrachten gebruikt, raadpleegt u Belangrijke informatie over debug-opdrachten. Het bevel om prioriteit te zuiveren kan een grote hoeveelheid ontwrichtend debug uitvoer op een productirouter afdrukken. De hoeveelheid is afhankelijk van het congestieniveau.

De volgende voorbeelduitvoer is gegenereerd op een Cisco 3640-platform.

r3-3640-5# debug priority 
Priority output queueing debugging is on 

r3-3640-5# ping 10.10.10.2 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms 
r3-3640-5# 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:41: PQ: Serial0/1 output (Pk size/Q 13/0) 
r3-3640-5#no debug priority 
00:42:51: PQ: Serial0/1 output (Pk size/Q 13/0) 
Priority output queueing debugging is off

In het volgende debug-prioriteitsuitvoer geeft 64 de eigenlijke prioriteitswachtrijdiepte aan op het moment dat het pakket viel.

*Feb 28 16:46:05.659:WFQ:dropping a packet from the priority queue 64
*Feb 28 16:46:05.671:WFQ:dropping a packet from the priority queue 64
*Feb 28 16:46:05.679:WFQ:dropping a packet from the priority queue 64
*Feb 28 16:46:05.691:WFQ:dropping a packet from the priority queue 64

Overige oorzaken voor vallen

De volgende redenen voor uitvoerdruppels met LLQ zijn ontdekt door het Cisco Technical Assistance Center (TAC) tijdens probleemoplossing en gedocumenteerd in een Cisco-bug-rapport:

• Het verhogen van de gewogen willekeurige vroegtijdige detectie (WRED)-maximumwaarden op een andere klasse trok de beschikbare buffers uit en leidde tot dalingen in de prioriteitswachtrij. Om dit probleem te diagnosticeren is een "no-buffer drops"-teller voor de prioriteitsklasse gepland voor een toekomstige release van IOS.

• Als de limiet van de wachtrij van de invoerinterface kleiner is dan de limiet van de wachtrij van de uitvoerinterface, daalt het pakket naar de invoerinterface. Deze symptomen zijn gedocumenteerd in Cisco bug-ID CSCdu89226 (alleen geregistreerde klanten). Los dit probleem op door de ingangsrij en de uitvoerrij juist in te stellen om ingangsdruppels te voorkomen en het uitgaande prioriteitswachtrij mechanisme van kracht te laten worden.

• Als u een functie uitschakelt die niet in het CEF-switched of snelgeschakelde pad wordt ondersteund, wordt een groot aantal pakketten verwerkt. Met LLQ worden de proces-switched pakketten op dit moment gecontroleerd of de interface al dan niet wordt geblokkeerd. Met andere woorden, zelfs als de interface niet verstopt is, zullen de procesgeschakelde pakketten van het systeem van de wachtrijen meters worden gebruikt en waarborgt dat de aangeboden lading niet de bandbreedte waarde overschrijdt die met de prioritaire opdracht wordt gevormd. Dit probleem is gedocumenteerd in Cisco bug-ID CSCdv86818 (alleen geregistreerde klanten).

Prioriteitswachtrijen voor Frame Relay

Frame Relay is een speciaal geval met betrekking tot het toezicht op de prioriteitswachtrij. Het Low Latency Queueing voor Frame Relay maakt melding van het volgende voorbehoud: "Het hoofdkwartier wordt gecontroleerd om ervoor te zorgen dat de eerlijke rijen niet van bandbreedte worden uitgehongerd. Wanneer u de PQ vormt, specificeert u in kbps de maximale hoeveelheid bandbreedte beschikbaar aan die rij. Pakketten die dat maximum overschrijden worden ingetrokken." Met andere woorden, aanvankelijk werd de prioriteitswachtrij van een service-beleid dat is geconfigureerd in een Frame Relay-kaartklasse ingeschakeld tijdens perioden van congestie en niet-congestie. IOS 12.2 verwijdert deze uitzondering. PQ wordt nog steeds gecontroleerd met FRF.12, maar andere niet-conforme pakketten worden alleen ingetrokken wanneer er sprake is van stremmingen.

Gerelateerde informatie

• QoS-ondersteuningspagina
• Cisco IOS-softwarerelease 12.2 traffic policing
• Technische ondersteuning - Cisco-systemen