Opdrachten voor bandbreedte en prioriteit van een QoS-servicebeleid bepalen

Inleiding

Dit document beschrijft hoe de opdrachten bandwidth   en priority de opdrachten worden toegepast in een interfacekaart met modulaire servicekwaliteit en opdrachtregel.

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 bandbreedte en prioriteit opdrachten definiëren beide acties die kunnen worden toegepast binnen een modulaire Quality of Service Command Line Interface (MQC) policy-map, die u vervolgens toepast op een interface, subinterface of virtueel circuit (VC) via het service-policy commando. Met name 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. Deze Tech Note verklaart die verschillen en verklaart hoe de ongebruikte bandbreedte van een klasse wordt verdeeld aan stromen die andere klassen aanpassen.

Samenvatting van verschillen

In deze tabel worden de functionele verschillen tussen de opdrachten bandwidth  en priority weergegeven:

Daarnaast zijn de opdrachten bandwidth  en prioriteitsopdrachten ontworpen om te voldoen aan verschillende QoS-beleidsdoelstellingen (Quality of Service). In deze tabel worden de verschillende doelstellingen opgesomd:

Zelfs met snelle interfaces, hebben de meeste netwerken nog een sterk QoS beheersmodel nodig om effectief de congestiepunten en de knelpunten te behandelen die onvermijdelijk wegens snelheid-wanverhouding of diverse verkeerspatronen voorkomen. Real-world netwerken hebben beperkte bronnen en bronnen knelpunten en hebben QoS-beleid nodig om een juiste toewijzing van middelen te garanderen.

De opdracht Bandbreedte configureren

In de Cisco IOS ® Configuration Guides wordt de bandwidth  opdracht beschreven als de "hoeveelheid bandbreedte, in kbps, die aan de klasse moet worden toegewezen. . . .om de bandbreedte te specificeren of te wijzigen die is toegewezen voor een klasse die tot een beleidskaart behoort."

Kijk naar wat deze definities betekenen.

Deze bandwidth  opdracht biedt een minimale bandbreedtegarantie tijdens stremmingen. 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 bandbreedteopdracht definieert een gedrag, wat een minimale bandbreedtegarantie is. Niet alle Cisco-routerplatforms gebruiken weighted-fair queueing (WFQ) als het belangrijkste algoritme om dit gedrag te implementeren. Zie Waarom CBWFQ gebruiken voor meer informatie.

Configureer de prioriteitsopdracht

De Cisco IOS-configuratiehandleidingen beschrijven de prioriteitsopdracht 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 opdrachten:

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

Tijdens congestievoorwaarden, is de verkeersklasse gegarandeerde bandbreedte gelijk aan het gespecificeerde tarief. (Rappel dat de bandbreedtegaranties slechts een kwestie zijn wanneer een interface verstopt is.) Met andere woorden, het priority  commando biedt een minimale bandbreedte garantie.

Bovendien implementeert het priority  commando een maximale bandbreedte garantie. Intern gebruikt de prioriteitswachtrij een symbolische emmer die de aangeboden belasting meet en ervoor zorgt dat de verkeersstroom voldoet aan de ingestelde snelheid. Alleen verkeer dat voldoet aan de token emmer is gegarandeerd lage latentie. Om het even welk bovenmatig verkeer wordt verzonden als de verbinding niet verstopt is of gelaten vallen als de verbinding verstopt is. Zie Wat is een Token Bucket voor meer informatie?

Het doel van de ingebouwde policer is om ervoor te zorgen dat de andere wachtrijen worden onderhouden door de wachtdienstplanner. In de oorspronkelijke functie voor prioriteitswachtrijen van Cisco, 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 lagere prioriteitswachtrijen zelden onderhouden en effectief uitgehongerd van bandbreedte.

Het echte voordeel van de priority  opdracht en het belangrijkste verschil met de bandwidth  opdracht is hoe de opdracht een strikte prioriteit voor het uit de wachtrij halen van wachtrijen biedt om een gebonden wachttijd te bieden. Hier is hoe de Cisco IOS Configuration Guide dit voordeel beschrijft: "Een strikte prioriteitswachtrij (PQ) maakt het mogelijk dat vertragingsgevoelige gegevens zoals spraak uit de wachtrij worden gehaald en worden verzonden voordat pakketten in andere wachtrijen uit de wachtrij worden gehaald." Kijk wat dit betekent.

Elke routerinterface handhaaft deze twee reeksen rijen:

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

Strikte de-wachtrij verwijst naar de wachtrij die de prioriteitswachtrij bedient en zijn pakketten eerst doorstuurt naar de verzendring. De zend ring is de laatste stop voor de fysieke media.

In de volgende illustratie, is de zend ring gevormd om vier pakketten te houden. Als er al drie pakketten op de ring staan, dan kunnen we in het beste geval in de wachtrij staan voor de vierde positie en dan wachten tot de andere drie leeg zijn. Zo zorgt het LLQ-mechanisme (Low Latency Queueing) ervoor dat de pakketten gewoon uit de wachtrij worden gehaald naar het eindpunt van de FIFO-wachtrij (First In, First Out) op bestuurdersniveau in de verzendring.

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

Verkeersprioritisering is vooral belangrijk voor vertragingsgevoelige, interactieve op transacties gebaseerde toepassingen. Om vertraging en jitter te minimaliseren, moeten de netwerkapparaten in staat zijn om spraakpakketten te onderhouden zodra ze aankomen, of met andere woorden, op strikte prioritaire wijze. Slechts een strikte prioriteit werkt goed voor spraak. Tenzij de spraakpakketten direct uit de wachtrij worden gehaald, kan elke hop meer vertraging introduceren.

De Internationale Telecommunicatie-Unie (ITU) beveelt een maximale end-to-end vertraging van 150 milliseconden aan. Zonder onmiddellijke de-wachtrij bij de routerinterface, kan één enkele routerhop het grootste deel van deze vertragingsbegroting rekenschap geven. Raadpleeg voor meer informatie de ondersteuning voor spraakkwaliteit.

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

Welke verkeersklassen kunnen overtollige bandbreedte gebruiken?

Hoewel de bandbreedte garanties die door de bandwidth  en priority  commando's worden geboden zijn beschreven met woorden als "gereserveerd" en "bandbreedte terzijde te leggen", implementeert geen van beide commando's een ware reservering. Met andere woorden, als een verkeersklasse zijn geconfigureerde bandbreedte niet gebruikt, wordt elke ongebruikte bandbreedte gedeeld tussen de andere klassen.

Het systeem van de rij vormde een belangrijke uitzondering op deze regel met een prioritaire klasse. Zoals eerder opgemerkt, wordt de aangeboden belasting van een prioriteitsklasse gemeten door een traffic policer. Tijdens stremmingsomstandigheden kan een prioriteitsklasse geen overtollige bandbreedte gebruiken.

Deze tabel beschrijft wanneer een bandbreedteklasse en een prioriteitsklasse de overtollige bandbreedte kunnen gebruiken:

Opmerking: een uitzondering op deze richtlijnen voor LLQ is Frame Relay op Cisco 7200 routerplatforms en andere niet-Route/Switch Processor (RSP)-platforms. De oorspronkelijke implementatie van LLQ via Frame Relay op deze platforms stond niet toe dat de prioriteitsklassen de ingestelde snelheid overtroffen tijdens perioden van niet-congestie. Cisco IOS-softwarerelease 12.2 verwijdert deze uitzondering en zorgt ervoor dat niet-conforme pakketten alleen worden gedropt als er congestie is. Bovendien worden pakketten kleiner dan een FRF.12 fragmentatiegrootte niet meer verzonden door het fragmentatieproces, en dit vermindert het gebruik van CPU.

Van de vorige discussie is het belangrijk om te begrijpen dat, aangezien de prioriteitsklassen worden bewaakt tijdens congestieomstandigheden, ze geen resterende bandbreedte van de bandbreedteklassen toegewezen krijgen. Aldus, wordt de resterende bandbreedte gedeeld door alle bandbreedteklassen en klasse-gebrek.

Ongebruikte bandbreedte-toewijzing

Deze sectie verklaart hoe het systeem van de rij om het even welke resterende bandbreedte verdeelt. Hier is hoe het Class-Based Weighted Fair Queueing Feature Overview het toewijzingsmechanisme beschrijft: "Als er overtollige bandbreedte beschikbaar is, wordt de overtollige bandbreedte verdeeld onder de verkeersklassen in verhouding tot hun ingestelde bandbreedte. Als niet alle bandbreedte wordt toegewezen, wordt de resterende bandbreedte evenredig verdeeld over de klassen, gebaseerd op 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 1 Mbps link, betekent dit dat 300 kbps is gegarandeerd aan de klassenbalk en 600 kbps is gegarandeerd aan de klassenbalk. Belangrijk is dat 100 kbps resterend is voor het standaard klassestandaardinkomen. Als class-default het niet nodig heeft, is de ongebruikte 100 kbps beschikbaar voor gebruik door klassenbalk en klassenbank. Als beide klassen de bandbreedte nodig hebben, delen zij het in verhouding tot de gevormde tarieven. In deze configuratie wordt de verhouding gedeeld 30:60 of 1:2.

De volgende voorbeeldconfiguratie bevat drie beleidskaarten: balk, baz en poli. In de beleidskaart met de naam bar en de beleidskaart met de naam baz wordt de bandbreedte gespecificeerd per percentage. In de beleidskaart met de naam poli wordt de bandbreedte echter gespecificeerd 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 opdracht voor de resterende percentages voor bandbreedte is geïntroduceerd in Cisco IOS versie 12.2(T).

Gebruik politieopdracht om een maximum in te stellen

Als een bandbreedte of prioritaire klasse niet de toegewezen bandbreedte mag overschrijden tijdens perioden zonder stremming, kunt u de priority opdracht combineren met de police  opdracht. Deze configuratie legt een maximumtarief op dat altijd actief op de klasse is. De keuze om een police  statement in deze configuratie te configureren hangt af van de beleidsdoelstelling.

De beschikbare bandbreedtewaarde begrijpen

Deze sectie legt uit hoe het systeem met wachtrijen de waarde voor beschikbare bandbreedte afleidt, zoals weergegeven in de uitvoer van de show interface of show queueing   opdrachten.

We creëerden een beleidsplan met de naam 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 circuit van ATM (PVC) gecreëerd, dat is toegewezen aan de servicecategorie met variabele bitsnelheid en niet-realtime ATM, en hebben we een duurzaam celtarief van 6 Mbps ingesteld. Vervolgens hebben we met de service-policy output leslie opdracht de beleidskaart op PVC toegepast.

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 1500 kilobits/sec. beschikbare bandbreedte 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 kijken hoe deze waarde wordt afgeleid:

1. 6 Mbps is de vaste celsnelheid (SCR). Standaard kan 75 procent hiervan worden gereserveerd:

   0.75 * 6000000 = 4500000
   

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

   4500000 - 3000000 = 1500000 bps
   

3. De beschikbare bandbreedte is 1500000 Gbps.

De standaard maximaal reserveerbare bandbreedtewaarde van 75 procent is ontworpen om voldoende bandbreedte voor overhead verkeer te laten, zoals het routeren van protocolupdates en Layer 2 keepalives. Het behandelt ook Layer 2-overhead voor pakketten die overeenkomen met en gedefinieerd zijn als verkeersklassen of de klasse-standaardklasse. U kunt nu de maximale reserveerbare bandbreedtewaarde op ATM PVC’s verhogen met de opdracht max-reserved-bandwidth . Raadpleeg voor ondersteunde Cisco IOS-releases en verdere achtergrondinformatie 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 de volgende manieren:

• Als een Minimum Acceptable Commited Information Rate (minCIR) niet is geconfigureerd, wordt de CIR door twee gedeeld.

• Als een minCIR is geconfigureerd, wordt de minCIR-instelling gebruikt bij de berekening. De volledige bandbreedte van het vorige tarief kan aan bandbreedte en prioritaire klassen worden toegewezen.

Aldus, wordt het max-reserved-bandwidth bevel niet ondersteund op Frame Relay PVCs, hoewel u moet ervoor zorgen dat de gevormde hoeveelheid bandbreedte groot genoeg is om Layer 2 overhead aan te passen. Raadpleeg CBWFQ op Frame Relay PVC’s configureren voor meer informatie.

Gerelateerde informatie

• Cisco Technical Support en downloads