Uitgangs-druppels voor probleemoplossing met prioriteitswachtrij

Inleiding

Dit document geeft tips voor het oplossen van uitvoerdalingen die het gevolg zijn van een configuratie van een prioriteitswachtmechanisme op een routerinterface.

Voorwaarden

Vereisten

Lezers van dit document dienen bekend te zijn met deze concepten:

• prioriteitsgroep of frame-relay-prioriteitsgroep - maakt een verouderd Cisco-mechanisme voor prioriteitswachtrijen mogelijk. Ondersteunt tot vier niveaus van prioriteitswachtrijen.

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

• prioriteit - maakt de LLQ-functie (Low Latency Queueing) van Cisco mogelijk en gebruikt de opdrachtstructuur van de modulaire Quality of Service QoS-opdrachtregelinterface (CLI).

Een router kan output laten vallen wanneer een van deze methoden is geconfigureerd, maar er zijn belangrijke functionele verschillen tussen de methoden en de reden voor druppels 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 ervoor dat u de potentiële 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 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 in Cisco Technical Tips worden gebruikt.

Drops met IP RTP-prioriteit en LLQ

De Cisco IOS-configuratiegids waarschuwt voor een daling van de uitvoer met deze mechanismen voor prioriteitswachtrijen:

• IP RTP-prioriteit: Omdat de ip rtp prioriteit opdracht absolute prioriteit geeft over ander verkeer, zou het met zorg moeten worden gebruikt. In het geval van stremming, als het verkeer de geconfigureerde bandbreedte overschrijdt, wordt al het overtollige verkeer gedropt.

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

Deze twee mechanismen maken gebruik van een ingebouwde policer om de verkeersstromen te meten. Het doel van de policer is om ervoor te zorgen dat de andere wachtrijen worden onderhouden door de wachtrijplanner. In de oorspronkelijke optie voor prioriteitswachtrijen van Cisco, die de opdrachten voor prioriteitsgroepen en prioriteitslijsten 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 verstoken van bandbreedte en pakketten die naar wachtrijen zonder prioriteit gingen.

Drops met oudere prioriteitswachtrij

Priority Queueing (PQ) is het mechanisme voor prioriteitswachtrijen van Cisco. Zoals hieronder wordt geïllustreerd, ondersteunt PQ tot vier niveaus van wachtrijen: hoog, gemiddeld, normaal en laag.

Als u prioriteitswachtrijen in een interface inschakelt, verandert de weergave van de uitvoerwachtrij, zoals hieronder wordt weergegeven. Alvorens prioriteit een rij te vormen gebruikt de Ethernet interface één enkele rij van de outputgreep 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 onderstaande uitvoer:

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 prioriteitslijst {lijst-nummer} wordt gebruikt om verkeersstromen aan een specifieke wachtrij toe te wijzen. Aangezien de pakketten bij een interface aankomen, worden de prioriteitswachtrijen op die interface gescand voor pakketten in een aflopende volgorde van prioriteit. De wachtrij met hoge prioriteit wordt eerst gescand, vervolgens de wachtrij met gemiddelde prioriteit, enzovoort. Het pakket aan het hoofd van de hoogste prioriteitswachtrij wordt gekozen voor transmissie. Deze procedure wordt elke keer herhaald dat er een pakketje wordt verzonden.

Elke wachtrij wordt gedefinieerd door een maximumlengte of door het maximale aantal pakketten dat de wachtrij kan bevatten. Wanneer een aankomend pakket zou veroorzaken dat de huidige wachtrijdiepte de geconfigureerde wachtrijlimiet overschrijdt, wordt het pakket gedropt. Zoals hierboven vermeld, zijn de output dalingen met PQ meestal toe te schrijven aan het overschrijden van de wachtrijgrens en niet aan een interne politieagent, zoals het typische geval met LLQ is. Het opdracht wachtrij met prioriteitenlijst-limiet wijzigt de grootte van een prioriteitswachtrij.

Traffic Measurement met een Token Bucket

LLQ en IP RTP Priority implementeren van de ingebouwde policer door een token bucket te gebruiken als een verkeersmetingssysteem. In deze paragraaf wordt gekeken naar het concept van de symboolemmer.

Een symbolische emmer heeft zelf geen teruggooi of prioritair beleid. De metafoor van de symboolemmer werkt als volgt:

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

• Elk token geeft aan dat de bron toestemming heeft 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 in vertegenwoordiging naar de pakketgrootte.

• Als er niet genoeg tokens in de emmer zijn om een pakket te verzenden, wacht het pakket of tot de emmer genoeg tokens heeft (in het geval van een shaper) of het pakket wordt weggegooid of afgetekend (in het geval van een politieman).

• De emmer zelf heeft een specifieke capaciteit. Als de emmer tot de capaciteit vult, worden nieuw aankomende penningen weggegooid en zijn niet beschikbaar voor toekomstige pakketten. Dus op elk moment is de grootste uitbarsting die een applicatie naar het netwerk kan sturen ruwweg proportioneel aan de grootte van de emmer. Een symbolische emmer maakt barstheid mogelijk, maar beperkt het.

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

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

• Wanneer een pakket van 450 bytes wordt ontvangen, is het pakket conform omdat er voldoende bytes beschikbaar zijn in het conforme token-emmer. Het pakket wordt verzonden, en 450 bytes worden verwijderd uit de symbolische emmer, verlatend 550 bytes.

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

Stappen voor probleemoplossing bij het stellen van een diagnose

Stap 1 - Gegevens verzamelen

De stappen voor het verzamelen van gegevens worden hieronder weergegeven.

1. Voer de volgende opdrachten meerdere malen uit en bepaal hoe snel en hoe vaak de druppels worden verhoogd. Gebruik de output om een basislijn van uw verkeerspatronen en verkeersniveaus vast te stellen. Bepaal wat de "normale" valsnelheid is in de interface.

   • Toon wachtrij-interface

     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

   • toon interface - Controleer de ladingswaarde die in de output wordt getoond. Zorg er bovendien voor dat de som van de tellingen van de vervolgkeuzelijsten per rij in de output van de showinterface gelijk is aan de tellingen van de outputdalingen. De teller van de showinterface zou het totale totaal van alle dalingen op output, met inbegrip van WRED moeten tonen verwerping, verwerping wegens buffertekort ("geen buffer"fouten), en zelfs verwerpingen in het geheugen van de havenadapter aan boord.

     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 waarden weer voor "txload" en "rxload".

     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 een niet-nul waarde voor de "pkts verwerpingen" 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 "pakketen gekoppeld". Deze voorwaarde wijst erop dat een groot aantal pakketten proces wordt geschakeld of dat de interface extreme congestie ervaart. Beide omstandigheden kunnen leiden tot overschrijding van de wachtrijlimiet 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. Kenmerk de verkeersstromen en de pakketten in die stromen.

   • Wat is de gemiddelde pakketgrootte?

   • In welke richting stroomt het frame ter grootte van de MTU? Veel verkeersstromen zijn asynchroon ten opzichte van belasting. Bijvoorbeeld, met een FTP-download, stromen de meeste van de MTU-formaat pakketten 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 alvorens de bron transmissie moet opschorten en op de bestemming wachten om de overgebrachte pakketten te erkennen.

3. Met Frame Relay, bepaal of de druppels zich voordoen in de interfacewachtrij of bij een per-VC wachtrij. Het volgende diagram illustreert de stroom van pakketten door een Frame Relay virtuele kring:

   

4. Prioriteitswachtrij 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 ingestelde wachtrijlimiet voordat het pakket in een wachtrij wordt geplaatst. Als de geselecteerde rij volledig is, laat vallen de router het pakket. Probeer de wachtrijgrootte te vergroten met de opdracht wachtrij-limiet {#} voor prioriteitslijst en hervat de bewaking.

Stap 2 - Zorg voor voldoende bandbreedte

Met LLQ maakt toezicht een eerlijke behandeling van andere gegevenspakketten mogelijk in andere op klasse gebaseerde gewogen Fair Queuing (CBWFQ) of WFQ-wachtrijen. Om pakketdalingen te vermijden, ben zeker om een optimale hoeveelheid bandbreedte aan de prioritaire rij toe te wijzen, die met het type van gebruikte codec en interfacekarakteristieken rekening houdt. IP RTP-prioriteit maakt geen verkeer mogelijk dat groter is dan het toegewezen bedrag.

Het is altijd het veiligst om iets meer dan de bekende vereiste hoeveelheid bandbreedte aan de prioriteitswachtrij toe te wijzen. Stel dat u 24 kbps bandbreedte, het standaardbedrag dat vereist is voor spraaktransmissie, aan de prioriteitswachtrij hebt toegewezen. Deze toewijzing lijkt veilig omdat de transmissie van spraakpakketten plaatsvindt tegen 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 de toewijzing van iets meer dan de vereiste hoeveelheid bandbreedte (zoals 25 kbps) voor een constante en beschikbare bandbreedte.

De bandbreedte die voor een prioriteitswachtrij wordt toegewezen omvat altijd Layer 2-inkapselingsheader. De cyclische redundantiecontrole (CRC) is niet inbegrepen. (Raadpleeg welke bytes door IP worden geteld bij ATM CoS-wachtrij? voor meer informatie.) Hoewel het slechts een paar bytes is, legt de CRC een stijgende impact op omdat verkeersstromen een hoger aantal kleine pakketten omvatten.

Bovendien bevat de bandbreedte die voor een prioriteitswachtrij is toegewezen op ATM-interfaces niet de volgende overheadkosten voor ATM-celbelasting:

• Om het even welke het opvullen door de segmentatie en de herassemblage (SAR) om de laatste cel van een pakket tot een even veelvoud van 48 bytes te maken.

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

• 5-byte 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 overheadkosten voor ATM-celbelasting niet zijn inbegrepen. U moet ook bandbreedte voor de mogelijkheid van jitter toestaan die door netwerkapparaten in de spraakweg wordt geïntroduceerd. Raadpleeg het Overzicht van de Low Latency Queueing.

Wanneer u prioriteitswachtrijen gebruikt om VoIP-pakketten te dragen, raadpleegt u Voice over IP - Per Call Bandbreedteconsumptie.

Stap 3 - Zorg voor voldoende barstgrootte

De behandeling van een reeks pakketten die een interface verlaten door een prioriteitswachtrij hangt af van de grootte van het pakket en het aantal bytes dat in de token bucket blijft. Het is belangrijk om rekening te houden met de kenmerken van de verkeersstroom die naar de prioriteitswachtrij wordt geleid omdat LLQ een politieman gebruikt, niet een shaper. Een policer gebruikt als volgt een symbolische emmer:

• De emmer wordt gevuld met tokens op basis van de klassesnelheid tot een maximum van de burst parameter.

• Als het aantal tokens groter is dan of gelijk is aan pakketgrootte, wordt het pakket verzonden en wordt de token emmer verlaagd. Anders wordt het pakket verbroken.

De standaard barstwaarde van LLQ's token bucket traffic meter wordt berekend als 200 milliseconden verkeer bij de ingestelde bandbreedtesnelheid. In sommige gevallen is de standaardwaarde ontoereikend, in het bijzonder wanneer TCP-verkeer in de prioriteitswachtrij terechtkomt. TCP-stromen zijn doorgaans bursty en kunnen een burstgrootte vereisen die groter is dan de standaard die is toegewezen door het systeem van wachtrijen, met name bij langzame koppelingen.

De volgende steekproefoutput werd geproduceerd op een pvc van ATM met een aanhoudende celtarief van 128 kbps. Het wachtrij-systeem past de barstgrootte aan op basis van de waarde die met de prioritaire opdracht is opgegeven.

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 Commited Burst (BC) grootte met de het Vormen Grootte van de Uitbarsting in Lage Latency Queueing eigenschap toe te staan. Met deze nieuwe functionaliteit kan het netwerk nu tijdelijke uitbarstingen van verkeer verwerken en het netwerkverkeer efficiënter verwerken.

Gebruik de burst parameter met de prioriteitsopdracht 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 verschijning geven dat de prioriteitsklassen meer krijgen dan hun eerlijke deel van de bandbreedte.

Bovendien wees het wachtrijsysteem oorspronkelijk een interne wachtrijlimiet van 64 pakketten toe aan de wachtrij met lage latentie. In sommige gevallen, toen een uitbarsting van 64 pakketten bij de prioriteitsrij aankwam, zou de verkeersmeter bepalen dat de uitbarsting aan het gevormde tarief in overeenstemming was, maar het aantal pakketten de wachtrijgrens overschreed. Als gevolg daarvan werden sommige pakketten met staarten gedropt. Cisco bug-id CSC51979 (alleen geregistreerde klanten) lost dit probleem op door de grootte van de prioriteitswachtrij zo diep te laten groeien als door de verkeersmeter is toegestaan.

De volgende uitvoer is opgenomen op een Frame Relay PVC dat met een CIR van 56 kbps is geconfigureerd. In de eerste reeks van steekproefoutput, is het gecombineerde aangeboden tarief van de c1 en c2 klassen 76 kbps. De reden hiervoor is dat de berekende waarden van aangeboden tarieven minus drop rates niet de werkelijke transmissietarieven vertegenwoordigen en geen pakketten omvatten 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 reeks output, zijn de show beleid-kaart interfacetellers genormaliseerd. Op het 56 kbps pvc, de klasse c1 verzenden ongeveer 50 kbps, en de klasse c2 verzenden 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

Het debug-commando geeft output van prioriteitswachtrijen weer als pakketten uit de prioriteitswachtrij worden verwijderd.

Voorzichtig:  Raadpleeg Important Information on Debug Commands (Belangrijke informatie over opdrachten met debug) voordat u debug-opdrachten opgeeft. Het debug-prioriteitsopdracht kan een grote hoeveelheid verstorende debug-uitvoer op een productierouter afdrukken. De hoeveelheid hangt af van het niveau van congestie.

De volgende voorbeelduitvoer is gegenereerd op 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 het volgende debug debug prioriteit output, wijst 64 op de daadwerkelijke prioriteitswachtrijdiepte op het tijdstip dat het pakket werd gelaten vallen.

*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 voor druppels

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

• Het verhogen van de WRED-maximumdrempelwaarden (Weighted random early Detence) op een andere klasse leidde tot een vermindering van de beschikbare buffers en tot een daling in de prioriteitswachtrij. Om de diagnose van dit probleem te vergemakkelijken, is er 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, wordt de verschuiving naar de invoerinterface verlaagd. Deze symptomen zijn gedocumenteerd in Cisco bug-id CSCdu89226 (alleen geregistreerde klanten). Los dit probleem op door de invoerwachtrij en de uitvoerwachtrij correct te rangschikken om invoerdalingen te voorkomen en het mechanisme van de uitgaande prioriteitswachtrij van kracht te laten worden.

• Als u een functie inschakelt die niet wordt ondersteund in het CEF-switched of Fast-switched pad, wordt een groot aantal pakketten procesgeschakeld. Met LLQ, worden de proces-switched pakketten momenteel gecontroleerd al dan niet de interface verstopt is. Met andere woorden, zelfs als de interface niet verstopt is, de wachtrij systeem meters proces-switched pakketten en verzekert de aangeboden lading niet overschrijdt de bandbreedtewaarde die met het prioritaire bevel wordt gevormd. Dit probleem is gedocumenteerd in Cisco bug-id CSCdv86818 (alleen geregistreerde klanten).

Drops van prioriteitswachtrijen en Frame Relay

Frame Relay is een speciaal geval met betrekking tot het toezicht op de prioriteitswachtrij. In het gedeelte Low Latency Queueing voor Frame Relay wordt melding gemaakt van het volgende voorbehoud: "PQ wordt gecontroleerd om ervoor te zorgen dat de eerlijke rijen niet van bandbreedte worden uitgehongerd. Wanneer u de PQ configureert, specificeert u in kbps de maximale bandbreedte die beschikbaar is voor die wachtrij. Pakketten die dat maximum overschrijden worden laten vallen." Met andere woorden, oorspronkelijk, werd de prioriteitsrij van een dienst-beleid dat in een Klasse van de Kaart van Frame Relay wordt gevormd tijdens periodes van congestie en niet-congestie gecontroleerd. IOS 12.2 verwijdert deze uitzondering. PQ wordt nog steeds gecontroleerd met FRF.12, maar andere niet-conforme pakketten worden alleen gelaten vallen als er congestie is.

Gerelateerde informatie

• QoS-ondersteuningspagina
• Cisco IOS-softwarerelease 12.2 Traffic policing-functiemodule
• Technische ondersteuning – Cisco Systems