Problemen oplossen Uitgangsdalingen met prioriteit in de wachtrij

Inleiding

Dit document geeft tips over het oplossen van outputdrops die het gevolg zijn van een configuratie van een prioritair wachtrijmechanisme op een routerinterface.

Voorwaarden

Vereisten

Lezers van dit document moeten bekend zijn met deze concepten:

• priority-group of frame-relay priority-group- Maakt het Cisco-mechanisme voor prioriteitswachtrijen mogelijk. Ondersteunt maximaal vier niveaus van prioriteitswachtrijen.

• ip rtp-prioriteit of frame-relay ip rtp-prioriteit - Komt overeen met UDP-poortnummers voor Real-Time Protocol (RTP)-verkeer dat VoIP-pakketten omvat en plaatst deze pakketten in een prioriteitswachtrij.

• prioriteit - Hiermee wordt de LLQ-functie (low latency queueing) van Cisco ingeschakeld en wordt de opdrachtstructuur van de modulaire QoS-opdrachtregelinterface (CLI) voor servicekwaliteit gebruikt.

Een router kan outputdrops rapporteren wanneer een van deze methoden is geconfigureerd, maar er zijn belangrijke functionele verschillen tussen de methoden en de reden voor drops 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 live netwerk werkt, zorg er dan voor dat u de potentiële impact van een opdracht begrijpt voordat u deze 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 live netwerk werkt, zorg er dan voor dat u de potentiële impact van iedere opdracht begrijpt voor u deze gebruikt.

Conventies

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

Drops met ip rtp prioriteit en LLQ

De Cisco IOS Configuration Guide waarschuwt voor uitgangdalingen met deze mechanismen voor prioriteitswachtrijen:

• ip rtp prioriteit: Omdat de ip rtp prioriteit opdracht geeft absolute prioriteit boven ander verkeer, moet het worden gebruikt met zorg. In het geval van congestie, als het verkeer de geconfigureerde bandbreedte overschrijdt, wordt al het overtollige verkeer gedropt.

• prioriteitsopdracht en LLQ: Wanneer u de prioriteitsopdracht voor een klasse opgeeft, wordt een bandbreedteargument gebruikt dat maximale bandbreedte geeft. In het geval van congestie wordt de politie 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 om ervoor te zorgen dat de andere wachtrijen worden onderhouden door de wachtrijplanner. In de Cisco Original Priority Queueing-functie, die de opdrachten voor prioriteitsgroepen en prioriteitenlijsten gebruikt, onderhield de planner altijd eerst de wachtrij met de hoogste prioriteit. Als er altijd verkeer was in de wachtrij met hoge prioriteit, waren de wachtrijen met lagere prioriteit uitgehongerd van bandbreedte en pakjes die naar niet-prioritaire wachtrijen gingen.

Drops met Legacy Priority Queueing

Priority Queueing (PQ) is het oudere voorraadmechanisme van Cisco. Zoals hieronder wordt geïllustreerd, ondersteunt PQ maximaal vier niveaus van wachtrijen: hoog, gemiddeld, normaal en laag.

Als u prioriteitswachtrijen op een interface inschakelt, verandert het display van de uitvoerwachtrij, zoals hieronder wordt geïllustreerd. Voordat prioriteit in de wachtrij wordt geplaatst, gebruikt de Ethernet-interface een enkele uitvoerwachtrij 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 wachtrijlimieten, zoals wordt weergegeven in de uitvoer hieronder:

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 opdracht priority-list {list-number} wordt gebruikt om verkeersstromen toe te wijzen aan een specifieke wachtrij. Als de pakketten op een interface aankomen, worden de prioriteitswachtrijen op die interface gescand op pakketten in een dalende volgorde van prioriteit. De wachtrij met hoge prioriteit wordt eerst gescand, daarna de wachtrij met middelhoge prioriteit, enzovoort. Het pakket aan het hoofd van de wachtrij met de hoogste prioriteit wordt gekozen voor verzending. Deze procedure wordt herhaald elke keer dat een pakket moet worden verzonden.

Elke wachtrij wordt gedefinieerd door een maximale lengte of door het maximale aantal pakketten dat de wachtrij kan bevatten. Wanneer een aankomend pakket ervoor zorgt dat de huidige wachtrijdiepte de geconfigureerde wachtrijlimiet overschrijdt, wordt het pakket gedropt. Zoals hierboven vermeld, zijn outputdalingen met PQ meestal te wijten aan het overschrijden van de wachtrijlimiet en niet aan een interne politieagent, zoals het typische geval is met LLQ. De opdracht priority-list-number queue-limit wijzigt de grootte van een prioriteitswachtrij.

Verkeersmeting met een Token Bucket

LLQ en IP RTP Priority implementeren de ingebouwde policer door een token bucket te gebruiken als een verkeersmeetsysteem. In dit gedeelte wordt gekeken naar het concept van de token bucket.

Een token bucket zelf heeft geen teruggooi- of prioriteitsbeleid. De token bucket metafoor werkt langs de volgende lijnen:

• Tokens worden in een bepaald tempo in de emmer gestopt.

• Elke token geeft de toestemming aan de bron om een bepaald aantal bits naar het netwerk te sturen.

• Om een pakket te verzenden, moet de verkeersregelaar een aantal tokens uit de emmer kunnen verwijderen die gelijk zijn aan de pakketgrootte.

• Als er niet genoeg tokens in de emmer zitten om een pakket te verzenden, wacht het pakket totdat de emmer voldoende tokens heeft (in het geval van een shaper) of het pakket wordt weggegooid of gemarkeerd (in het geval van een politieagent).

• De emmer zelf heeft een gespecificeerde capaciteit. Als de emmer vol is, worden nieuw aangekomen tokens weggegooid en zijn deze niet beschikbaar voor toekomstige pakketten. Zo is op elk moment de grootste burst die een applicatie in het netwerk kan verzenden ongeveer evenredig met de grootte van de emmer. Een token emmer staat uitbarsting toe, maar beperkt het.

Laten we eens kijken naar een voorbeeld met behulp van pakketten en een gecommitteerde informatiesnelheid (CIR) van 8000 bps.

• In dit voorbeeld beginnen de initiële tokenemmers vol bij 1000 bytes.

• Wanneer een pakket van 450 bytes arriveert, voldoet het pakket omdat er voldoende bytes beschikbaar zijn in de conforme tokenemmer. Het pakket wordt verzonden en 450 bytes worden verwijderd uit de tokenemmer, waardoor 550 bytes overblijven.

• Wanneer het volgende pakket 0,25 seconden later arriveert, worden 250 bytes toegevoegd aan de tokenemmer (0,25 * 8000) / 8), waardoor 700 bytes in de tokenemmer achterblijven. Als het volgende pakket 800 bytes is, overschrijdt het pakket en wordt het gedropt. Er worden geen bytes uit de tokenemmer gehaald.

Stappen voor probleemoplossing om vallen te diagnosticeren

Stap 1 - Verzamel gegevens

De stappen voor het verzamelen van gegevens worden hieronder weergegeven.

1. Voer de volgende opdrachten meerdere keren uit en bepaal hoe snel en hoe vaak de toename daalt. Gebruik de uitvoer om een basislijn van uw verkeerspatronen en verkeersniveaus vast te stellen. Zoek uit wat de "normale" drop rate is op de interface.

   • interface voor wachtrijen weergeven

     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 weergeven - Controleer de laadwaarde die in de uitvoer wordt weergegeven. Zorg er bovendien voor dat de som van de droptellingen per wachtrij in de uitvoer van de interface show gelijk is aan het aantal uitvoerdalingen. De teller voor uitvoerdruppels van de showinterface moet het totale aggregaat weergeven van alle druppels op de uitvoer, inclusief WRED-teruggooi, weggooien vanwege buffertekort ("geen bufferfouten") en zelfs teruggooien in het geheugen van de boordpoort-adapter.

     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

     Opmerking: 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 policy-map interface interface-name - Zoek naar een niet-nulwaarde 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: In het volgende voorbeeld worden overeenkomende waarden weergegeven voor de tellers "pakketten" en "overeenkomende punten". Deze voorwaarde geeft aan dat een groot aantal pakketten worden verwerkt of dat de interface extreme congestie ervaart. Beide voorwaarden kunnen leiden tot het overschrijden van de wachtrijlimiet van een klasse 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. Karakteriseren van de verkeersstromen en de pakketten in die stromen.

   • Wat is de gemiddelde pakketgrootte?

   • In welke richting stroomt het MTU-formaat frame? Veel verkeersstromen zijn asynchroon met betrekking tot de belasting. Met een FTP-download stromen de meeste pakketten van MTU-formaat bijvoorbeeld van de FTP-server naar de client. Pakketten van de FTP-client naar de server zijn eenvoudige TCP-ACK's.

   • Gebruiken de pakketten TCP of UDP? TCP staat elke stroom toe om een geautoriseerd aantal pakketten te verzenden voordat de bron de verzending moet opschorten en wacht tot de bestemming de verzonden pakketten erkent.

3. Bepaal met Frame Relay of de druppels zich voordoen in de interface-wachtrij of in een VC-wachtrij. Het volgende diagram illustreert de stroom van pakketten door een Frame Relay virtueel circuit:

   

4. Priority Queueing ondersteunt maximaal vier uitvoerwachtrijen, één per prioriteitswachtrijniveau en elke wachtrij wordt gedefinieerd door een wachtrijlimiet. Het wachtrijsysteem controleert de grootte van de wachtrij aan de hand van de geconfigureerde wachtrijlimiet voordat het pakket in een wachtrij wordt geplaatst. Als de geselecteerde wachtrij vol is, laat de router het pakket vallen. Probeer de wachtrijgrootte te vergroten met de opdracht Priority-list {#} queue-limit en hervat de bewaking.

Stap 2 - Zorg voor voldoende bandbreedte

Met LLQ zorgt de politie voor een eerlijke behandeling van andere gegevenspakketten in andere klasse-gebaseerde gewogen eerlijke wachtrij (CBWFQ) of WFQ-wachtrijen. Om pakketdruppels te voorkomen, moet u ervoor zorgen dat u een optimale hoeveelheid bandbreedte toewijst aan de prioriteitswachtrij, rekening houdend met het type gebruikte codec en de interfacekarakteristieken. IP RTP Priority staat geen verkeer toe boven het toegewezen bedrag.

Het is altijd het veiligst om iets meer dan de bekende vereiste hoeveelheid bandbreedte toe te wijzen aan de prioriteitswachtrij. Stel dat u bijvoorbeeld een bandbreedte van 24 kbps, het standaardbedrag dat vereist is voor spraakoverdracht, hebt toegewezen aan de prioriteitswachtrij. Deze toewijzing lijkt veilig omdat de overdracht van spraakpakketten plaatsvindt met een constante bitsnelheid. Omdat het netwerk en de router of switch echter een deel van de bandbreedte kunnen gebruiken om jitter en delay te produceren, zorgt het toewijzen van iets meer dan de vereiste hoeveelheid bandbreedte (zoals 25 kbps) voor constantheid en beschikbaarheid.

De bandbreedte die is toegewezen voor een prioriteitswachtrij bevat altijd de Layer 2-inkapselingshoofdkop. De cyclische redundantiecontrole (CRC) is niet inbegrepen. (Raadpleeg Welke bytes worden geteld door IP naar ATM CoS Queueing? voor meer informatie.) Hoewel het slechts een paar bytes is, legt de CRC een toenemende impact op, omdat verkeersstromen een groter aantal kleine pakketten omvatten.

Bovendien omvat de bandbreedte die is toegewezen voor een prioriteitswachtrij op ATM-interfaces niet de volgende overhead voor de belasting van ATM-cellen:

• Elke opvulling door de segmentatie en reassembly (SAR) om de laatste cel van een pakket een even veelvoud van 48 bytes te maken.

• 4-byte CRC van de ATM Adaptation Layer 5 (AAL5) trailer.

• ATM-celheader van 5 bytes.

Wanneer u de hoeveelheid bandbreedte berekent die moet worden toegewezen voor een bepaalde prioriteitsklasse, moet u rekening houden met het feit dat Layer 2-headers zijn opgenomen. Bij het gebruik van geldautomaten moet u rekening houden met het feit dat de overhead van de belasting op geldautomaten niet is inbegrepen. U moet ook bandbreedte toestaan voor de mogelijkheid van jitter geïntroduceerd door netwerkapparaten in het spraakpad. Raadpleeg het overzicht van de wachtrijen met lage latentie.

Raadpleeg Voice over IP - Per Call Bandwidth Consumption (Bandbreedteverbruik per oproep) bij het gebruik van prioriteitswachtrijen om VoIP-pakketten te vervoeren.

Stap 3 - Zorg voor voldoende burst grootte

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

• De emmer is gevuld met tokens op basis van de klasse tarief tot een maximum van de burst parameter.

• Als het aantal tokens groter is dan of gelijk is aan de pakketgrootte, wordt het pakket verzonden en wordt de tokenemmer verlaagd. Anders wordt het pakje weggelaten.

De standaard burst-waarde van de token bucket traffic meter van LLQ wordt berekend als 200 milliseconden verkeer met de geconfigureerde bandbreedtesnelheid. In sommige gevallen is de standaardwaarde ontoereikend, vooral wanneer TCP-verkeer naar de prioriteitswachtrij gaat. TCP-stromen zijn doorgaans bursty en vereisen mogelijk een burstgrootte die groter is dan de standaard die door het wachtrijsysteem is toegewezen, met name bij trage koppelingen.

De volgende monsteroutput werd gegenereerd op een ATM PVC met een aanhoudende celsnelheid van 128 kbps. Het wachtrijsysteem past de burstgrootte aan naarmate de waarde die is opgegeven met de opdracht Priority 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 Committed Burst (Bc)-grootte mogelijk te maken met de functie Burst Size in Low Latency Queueing configureren. Met deze nieuwe functionaliteit kan het netwerk nu tijdelijke uitbarstingen van verkeer opvangen en efficiënter omgaan met netwerkverkeer.

Gebruik de burst parameter met de prioriteit opdracht om de burst waarde te verhogen van 1600 bytes 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 indruk geven dat de prioriteitsklassen meer krijgen dan hun billijke aandeel van de bandbreedte.

Bovendien heeft het wachtrijsysteem oorspronkelijk een interne wachtrijlimiet van 64 pakketten toegewezen aan de wachtrij met lage latentie. In sommige gevallen, wanneer een uitbarsting van 64 pakketten op de prioriteitswachtrij arriveerde, zou de verkeersmeter bepalen dat de uitbarsting in overeenstemming was met de geconfigureerde snelheid, maar het aantal pakketten overschreed de wachtrijlimiet. Als gevolg hiervan werden sommige pakketten met de staart gedropt. Cisco bug ID CSCdr51979 (alleen geregistreerde klanten) lost dit probleem op door de prioriteitswachtrijgrootte zo diep te laten groeien als de verkeersmeter toestaat.

De volgende output werd vastgelegd op een frame relais PVC geconfigureerd met een CIR van 56 kbps. In de eerste set van sample output, de gecombineerde aangeboden tarief van de c1 en c2 klassen is 76 kbps. De reden is dat de berekende waarden van aangeboden tarieven minus dalingspercentages niet de werkelijke transmissiesnelheden vertegenwoordigen en geen pakketten bevatten die in de shaper 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 uitvoer zijn de toon-policy-map interface tellers genormaliseerd. Op de 56 kbps PVC stuurt de klasse c1 ongeveer 50 kbps en de klasse c2 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 - debug prioriteit

De prioriteit foutopsporing geeft de uitvoer van de prioriteitswachtrij weer als er pakketten uit de prioriteitswachtrij worden verwijderd.

Waarschuwing: Voordat u debug opdrachten gebruikt, raadpleegt u Belangrijke informatie over debug opdrachten. De opdracht Prioriteit debuggen kan een grote hoeveelheid verstorende debug-uitvoer op een productierouter afdrukken. De hoeveelheid is afhankelijk van de mate van congestie.

De volgende sample output werd gegenereerd op een Cisco 3640.

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 de volgende debug prioriteit output geeft 64 de werkelijke prioriteit wachtrij diepte op het moment dat het pakket werd gedropt.

*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

Andere oorzaken van druppels

De volgende redenen voor outputdalingen met LLQ werden ontdekt door het Cisco Technical Assistance Center (TAC) tijdens het oplossen van problemen en gedocumenteerd in een Cisco-bugrapport:

• Het verhogen van de gewogen maximale drempelwaarden voor willekeurige vroege detectie (WRED) op een andere klasse heeft de beschikbare buffers uitgeput en geleid tot dalingen in de prioriteitswachtrij. Om dit probleem te helpen diagnosticeren, is een "no-buffer drops" teller voor de prioriteitsklasse gepland voor een toekomstige release van IOS.

• Als de wachtrijlimiet van de invoerinterface kleiner is dan de wachtrijlimiet van de uitvoerinterface, verschuift het pakket naar de invoerinterface. Deze symptomen zijn gedocumenteerd in Cisco bug ID CSCdu89226 (geregistreerde klanten alleen). Los dit probleem op door de grootte van de invoerwachtrij en de uitvoerwachtrij op de juiste manier te wijzigen om te voorkomen dat de invoer daalt en het mechanisme voor de uitgaande prioriteitswachtrij in werking te laten treden.

• Als u een functie inschakelt die niet wordt ondersteund in het CEF-geschakelde of snelgeschakelde pad, wordt een groot aantal pakketten procesgeschakeld. Met LLQ worden procesgeschakelde pakketten momenteel gecontroleerd of de interface al dan niet overbelast is. Met andere woorden, zelfs als de interface niet overbelast is, metert het wachtrijsysteem procesgeschakelde pakketten en zorgt het ervoor dat de aangeboden belasting de bandbreedtewaarde niet overschrijdt die is geconfigureerd met de opdracht prioriteit. Dit probleem is gedocumenteerd in Cisco bug ID CSCdv86818 (geregistreerde klanten alleen).

Priority Queues Drops en Frame Relay

Frame Relay is een speciaal geval met betrekking tot het bewaken van de prioriteitswachtrij. In het overzicht van de Low Latency Queueing for Frame Relay-functie wordt het volgende voorbehoud gemaakt: "De PQ wordt gecontroleerd om ervoor te zorgen dat de eerlijke wachtrijen niet worden uitgehongerd van bandbreedte. Wanneer u de PQ configureert, specificeert u in kbps de maximale hoeveelheid bandbreedte die beschikbaar is voor die wachtrij. Pakketten die dat maximum overschrijden, worden gedropt." Met andere woorden, oorspronkelijk werd de prioriteitswachtrij van een servicebeleid dat was geconfigureerd in een Frame Relay-kaartklasse gecontroleerd tijdens perioden van congestie en niet-congestie. In iOS 12.2 is deze uitzondering verwijderd. PQ wordt nog steeds gecontroleerd met FRF.12, maar andere niet-conforme pakketten worden alleen gedropt als er congestie is.

Gerelateerde informatie

• QoS-ondersteuningspagina
• Cisco IOS Software Release 12.2 Traffic Policing-module
• Technische ondersteuning – Cisco Systems