Opdrachten Ascertain Bandwith en Priority van een QoS servicebeleid

Inleiding

In dit document wordt beschreven hoe de bandwidth instructies en priority opdrachten worden toegepast in een beleidskaart voor de opdrachtregelinterface voor de modulaire kwaliteit van de service.

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

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

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Achtergrondinformatie

De opdrachten bandbreedte en prioriteit definiëren beide acties die kunnen worden toegepast binnen een MQC-beleidskaart (modular quality of service command-line interface), die u vervolgens via het service-policy commando toepast op een interface, subinterface of virtueel circuit.

Concreet bieden deze opdrachten een bandbreedtegarantie voor de pakketten die voldoen aan de criteria van een verkeersklasse. De twee commando's hebben echter belangrijke functionele verschillen in die garanties.

In deze technische notitie worden deze verschillen uitgelegd en wordt uitgelegd hoe de ongebruikte bandbreedte van een klasse wordt verdeeld over stromen die overeenkomen met andere klassen.

Samenvatting van de verschillen

Deze tabel geeft de functionele verschillen weer tussen de  bandwidth en priority opdrachten:

Bovendien zijn de bandwidth  en prioritaire opdrachten ontworpen om te voldoen aan verschillende beleidsdoelstellingen voor de kwaliteit van de dienstverlening (QoS). Deze tabel geeft een overzicht van de verschillende doelstellingen:

Zelfs met snelle interfaces hebben de meeste netwerken nog steeds een sterk QoS-beheermodel nodig om effectief om te gaan met de congestiepunten en knelpunten die onvermijdelijk optreden als gevolg van snelheidsmismatch of verschillende verkeerspatronen.

Netwerken in de echte wereld hebben beperkte bronnen en knelpunten en hebben een QoS-beleid nodig om de juiste toewijzing van middelen te waarborgen.

De opdracht Bandbreedte configureren

De Cisco IOS ^® Configuration Guides beschrijven de bandwidth  opdracht als de "hoeveelheid bandbreedte, in kbps, die aan de klasse moet worden toegewezen. . . om de bandbreedte op te geven of aan te passen die is toegewezen voor een klasse die behoort tot een beleidskaart."

Kijk naar wat deze definities betekenen.

De bandwidth  opdracht biedt een minimale bandbreedtegarantie tijdens congestie. Er zijn drie vormen van de opdrachtsyntaxis, zoals in deze tabel wordt geïllustreerd:

bandwidth {kbps}

bandwidth percent {value}

bandwidth remaining percent {value}

Opmerking: de opdracht Bandbreedte definieert een gedrag, dat een minimale bandbreedtegarantie is. Niet alle Cisco-routerplatforms gebruiken weighted-fair queueing (WFQ) als het belangrijkste algoritme om dit gedrag te implementeren. Raadpleeg voor meer informatie Waarom CBWFQ gebruiken?

De opdracht Prioriteit configureren

De Cisco IOS Configuration Guides beschrijven het prioriteitscommando als een reserve voor "een prioriteitswachtrij met een bepaalde hoeveelheid beschikbare bandbreedte voor CBWFQ-verkeer ... om prioriteit te geven aan een verkeersklasse op basis van de hoeveelheid beschikbare bandbreedte binnen een verkeersbeleid."

In het volgende voorbeeld wordt uitgelegd wat deze definities betekenen.

U maakt een prioriteitswachtrij met deze sets opdrachten:

Router(config)#policy-map policy-name
Router(config-pmap)#class class-name
Router(config-pmap-c)#priority kpbs [bytes]

Tijdens congestieomstandigheden is de verkeersklasse verzekerd van een bandbreedte die gelijk is aan de opgegeven snelheid. (Denk eraan dat bandbreedtegaranties alleen een probleem zijn wanneer een interface overbelast is.) Met andere woorden, de priority  opdracht biedt een minimale bandbreedtegarantie.

Bovendien implementeert de priority  opdracht een maximale bandbreedtegarantie. Intern gebruikt de prioriteitswachtrij een token-emmer die de aangeboden belasting meet en ervoor zorgt dat de verkeersstroom voldoet aan de geconfigureerde snelheid.

Alleen verkeer dat voldoet aan de token-emmer is gegarandeerd met lage latentie. Overtollig verkeer wordt verzonden als de link niet is overbelast of wordt weggelaten als de link overbelast is. Raadpleeg voor meer informatie Wat is een token bucket?

Het doel van de ingebouwde policer is om ervoor te zorgen dat de andere wachtrijen worden onderhouden door de wachtrijplanner. In de oorspronkelijke Cisco-prioriteitswachtrij, die de priority-group en priority-list opdrachten gebruikt, onderhield de planner altijd eerst de wachtrij met de hoogste prioriteit.

In extreme gevallen werden de wachtrijen met lagere prioriteit zelden onderhouden en was de bandbreedte effectief afgenomen.

Het echte voordeel van het priority  commando - en het grote verschil met het bandwidth  commando - is hoe het een strikte de-wachtrij prioriteit biedt om een gebonden latentie te bieden.

De Cisco IOS Configuration Guide beschrijft dit voordeel als volgt: "Een strikte prioriteitswachtrij (PQ) maakt het mogelijk om vertragingsgevoelige gegevens zoals spraak uit de wachtrij te halen en te verzenden voordat pakketten in andere wachtrijen uit de wachtrij worden gehaald."

Kijk wat dit betekent.

Elke routerinterface onderhoudt deze twee sets wachtrijen:

In de vorige tabel kunnen we zien dat een servicebeleid alleen van toepassing is op pakketten in de Layer 3-wachtrij.

Strict de-queueing verwijst naar de wachtrijplanner die de prioriteitswachtrij onderhoudt en zijn pakketten eerst doorstuurt naar de zendring. De zendring is de laatste stop voor de fysieke media.

In de volgende afbeelding is de transmissiering geconfigureerd om vier pakketten te bevatten. Als er al drie pakketten op de ring staan, kunnen we in het beste geval in de rij staan naar de vierde positie en dan wachten tot de andere drie leeg zijn.

Het Low Latency Queueing (LLQ)-mechanisme zorgt er dus voor dat de pakketten in de wachtrij worden geplaatst aan het uiteinde van de first-in, first-out (FIFO) wachtrij op het stuurprogrammaniveau op de zendring.

Gebruik de tx-ring-limit opdracht om de grootte van de zendring af te stemmen op een niet-standaardwaarde. Cisco raadt u aan de zenderring af te stemmen wanneer u spraakverkeer verzendt.

Het prioriteren van verkeer is vooral belangrijk voor vertragingsgevoelige, interactieve, op transacties gebaseerde toepassingen. Om vertraging en jitter te minimaliseren, moeten de netwerkapparaten spraakpakketten kunnen onderhouden zodra ze aankomen, of met andere woorden, op een strikte prioriteitsmanier. Alleen een strikte prioriteit werkt goed voor de stem. Tenzij de spraakpakketten onmiddellijk uit de wachtrij worden gehaald, kan elke hop meer vertraging introduceren.

De Internationale Telecommunicatie Unie (ITU) beveelt een maximale 150 milliseconde one-way end-to-end vertraging. Zonder onmiddellijke wachtrijen op de router-interface, kan een enkele router hop goed zijn voor het grootste deel van deze vertraging budget. Raadpleeg voor meer informatie de ondersteuning voor spraakkwaliteit.

Opmerking: bij beide opdrachten moet de kbps-waarde rekening houden met de Layer 2-overhead. Met andere woorden, als een garantie wordt gegeven aan een klasse, is die garantie met betrekking tot Layer 2-doorvoer.

Welke verkeersklassen kunnen overtollige bandbreedte gebruiken?

Hoewel de bandbreedtegaranties die door de bandwidth  en priority  opdrachten worden geboden, zijn beschreven met woorden als "gereserveerd" en "bandbreedte die moet worden gereserveerd", implementeert geen van beide opdrachten een echte reservering. Met andere woorden, als een verkeersklasse de geconfigureerde bandbreedte niet gebruikt, wordt elke ongebruikte bandbreedte gedeeld tussen de andere klassen.

Het wachtrijsysteem vormt een belangrijke uitzondering op deze regel met een prioriteitsklasse. Zoals eerder opgemerkt, wordt de aangeboden belasting van een prioriteitsklasse gemeten door een verkeerspolitie. Tijdens congestieomstandigheden kan een prioriteitsklasse geen overtollige bandbreedte gebruiken.

In deze tabel wordt beschreven wanneer een klasse bandbreedte en een prioriteitsklasse overtollige bandbreedte kunnen gebruiken:

Opmerking: Een uitzondering op deze richtlijnen voor LLQ is Frame Relay op de Cisco 7200-router en andere niet-Route/Switch Processor (RSP)-platformen. De oorspronkelijke implementatie van LLQ over Frame Relay op deze platforms stond niet toe dat de prioriteitsklassen de geconfigureerde snelheid overschreden tijdens perioden van niet-congestie. Cisco IOS Software Release 12.2 verwijdert deze uitzondering en zorgt ervoor dat niet-conforme pakketten alleen worden verwijderd als er congestie is. Bovendien worden pakketten die kleiner zijn dan een FRF.12-fragmentatiegrootte niet langer door het fragmentatieproces verzonden, waardoor het CPU-gebruik wordt verminderd.

Uit de vorige discussie is het belangrijk om te begrijpen dat, aangezien de prioriteitsklassen worden bewaakt tijdens congestieomstandigheden, ze geen resterende bandbreedte van de bandbreedteklassen krijgen toegewezen. De resterende bandbreedte wordt dus gedeeld door alle bandbreedteklassen en standaardklassen.

Niet-gebruikte bandbreedtetoewijzing

In dit gedeelte wordt uitgelegd hoe het wachtrijsysteem de resterende bandbreedte verdeelt. Hier is hoe het Class-Based Weighted Fair Queueing Feature Overview het toewijzingsmechanisme beschrijft:

"Als overtollige bandbreedte beschikbaar is, wordt de overtollige bandbreedte verdeeld over de verkeersklassen in verhouding tot hun geconfigureerde bandbreedten. Als niet alle bandbreedte is toegewezen, wordt de resterende bandbreedte proportioneel verdeeld over de klassen, op basis van hun geconfigureerde bandbreedte."

Kijk naar twee voorbeelden.

In het eerste voorbeeld garandeert policy-map foo 30 procent van de bandbreedte naar class bar en 60 procent van de bandbreedte naar class baz.

policy-map foo 
  class bar 
    bandwidth percent 30 
 class baz 
  bandwidth percent 60

Als u dit beleid toepast op een koppeling van 1 Mbps, betekent dit dat 300 kbps gegarandeerd wordt aan de klassebalk en 600 kbps gegarandeerd aan de klassebaz. Belangrijk is dat 100 kbps overblijft voor class-default.

Als class-default dit niet nodig heeft, is de ongebruikte 100 kbps beschikbaar voor gebruik door class bar en class baz.

Als beide klassen de bandbreedte nodig hebben, delen ze deze in verhouding tot de geconfigureerde snelheden. In deze configuratie wordt de verhouding gedeeld 30:60 of 1:2.

De volgende voorbeeldconfiguratie bevat drie beleidskaarten: bar, baz en poli. In de beleidskaart met de naam bar en de beleidskaart met de naam baz wordt de bandbreedte opgegeven per percentage.

In de beleidskaart met de naam poli wordt de bandbreedte echter opgegeven in kbps.

Vergeet niet dat de klassenkaarten al moeten worden gemaakt voordat u de beleidskaarten maakt.

 policy-map bar
  class voice
   priority percent 10
  class data
   bandwidth percent 30
  class video
   bandwidth percent 20
 policy-map baz
  class voice
   priority percent 10
  class data
   bandwidth remaining percent 30
  class video
   bandwidth remaining percent 20
 policy-map poli
  class voice
  class data
   bandwidth 30
  class video
   bandwidth 20

Opmerking: De bandbreedte resterende procent opdracht werd geïntroduceerd in Cisco IOS versie 12.2 (T).

Gebruik het politiecommando om een maximum in te stellen

Als een bandbreedte of prioriteitsklasse de toegewezen bandbreedte niet mag overschrijden tijdens perioden zonder congestie, kunt u de priority opdracht combineren met de police  opdracht.

Deze configuratie legt een maximale snelheid op die altijd actief is in de klasse. De keuze voor het configureren van een police  instructie in deze configuratie is afhankelijk van de beleidsdoelstelling.

De waarde van de beschikbare bandbreedte begrijpen

In dit gedeelte wordt uitgelegd hoe het wachtrijsysteem de waarde Beschikbare bandbreedte afleidt, zoals wordt weergegeven in de uitvoer van de show interface- ofshow queueing opdrachten.

We maakten deze beleidskaart genaamd Leslie:

7200-16#show policy-map leslie 
  Policy Map leslie 
    Class voice 
      Weighted Fair Queueing 
            Strict Priority 
            Bandwidth 1000 (kbps) Burst 25000 (Bytes) 
    Class data 
      Weighted Fair Queueing 
            Bandwidth 2000 (kbps) Max Threshold 64 (packets)

Vervolgens hebben we een permanent virtueel ATM-circuit (PVC) gemaakt, dit toegewezen aan de variabele bitrate non-real-time ATM-servicecategorie en een aanhoudende celsnelheid van 6 Mbps geconfigureerd. Vervolgens pasten we de beleidskaart toe op de PVC met het service-policy output leslie commando.

7200-16(config)#interface atm 4/0.10 point 
7200-16(config-subif)#pvc 0/101 
7200-16(config-if-atm-vc)#vbr-nrt 6000 6000 
7200-16(config-if-atm-vc)#service-policy output leslie

show queueing interface atm De opdracht geeft Beschikbare bandbreedte van 1500 kilobits/sec. weer.

7200-16#show queue interface atm 4/0.10 
  Interface ATM4/0.10 VC 0/101 
  queue strategy: weighted fair 
  Output queue: 0/512/64/0 (size/max total/threshold/drops) 
     Conversations  0/0/128 (active/max active/max total) 
     Reserved Conversations 1/1 (allocated/max allocated) 
     Available Bandwidth 1500 kilobits/sec

Laten we eens kijken hoe deze waarde wordt afgeleid:

1. 6 Mbps staat voor sustained cell rate (SCR). Standaard is 75 procent hiervan reserveerbaar:

   0.75 * 6000000 = 4500000
   

2. 3000 Kbps wordt al gebruikt door de spraak- en gegevensklassen:

   4500000 - 3000000 = 1500000 bps
   

3. Beschikbare bandbreedte is 1500000 bps.

De standaard maximale reserveerbare bandbreedtewaarde van 75 procent is ontworpen om voldoende bandbreedte over te houden voor overheadverkeer, zoals routeringsprotocolupdates en Layer 2-keepalives.

Het dekt ook Layer 2-overhead voor pakketten die overeenkomen en zijn gedefinieerd verkeersklassen of de klasse-standaard klasse. U kunt nu de maximale reserveerbare bandbreedtewaarde op ATM-pvc's verhogen met de max-reserved-bandwidth opdracht.

Voor ondersteunde Cisco IOS-releases en verdere achtergrondinformatie raadpleegt u De opdracht max-gereserveerde bandbreedte op ATM-PVC begrijpen.

Op Frame Relay PVC's berekenen de bandwidth en priority opdrachten de totale hoeveelheid beschikbare bandbreedte op een van deze manieren:

• Als er geen Minimum Acceptable Commitment Information Rate (minCIR) is geconfigureerd, wordt de CIR door twee gedeeld.

• Als een minCIR is geconfigureerd, wordt de minCIR-instelling gebruikt in de berekening. De volledige bandbreedte van de vorige snelheid kan worden toegewezen aan bandbreedte- en prioriteitsklassen.

De max-reserved-bandwidth opdracht wordt dus niet ondersteund op Frame Relay PVC's, hoewel u ervoor moet zorgen dat de hoeveelheid geconfigureerde bandbreedte groot genoeg is om Layer 2-overhead te kunnen verwerken. Raadpleeg voor meer informatie CBWFQ configureren op framerelais-PVC's.

Gerelateerde informatie

• Cisco Technical Support en downloads