Veelgestelde vragen over QoS
Inhoud
Inleiding
In dit document worden veelgestelde vragen over Quality of Service (QoS) beantwoord.
Algemeen
Wat is Quality of Service (QoS)?
A. QoS verwijst naar het vermogen van een netwerk om beter service te bieden aan geselecteerd netwerkverkeer via verschillende onderliggende technologieën, waaronder Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet- en 802.1-netwerken, SONET en IP-gerouteerde netwerken.
QoS is een verzameling technologieën waarmee toepassingen voorspelbare serviceniveaus kunnen aanvragen en ontvangen in termen van gegevensdoorvoercapaciteit (bandbreedte), latentievariaties (jitter) en vertraging. Met name QoS-functies bieden een betere en meer voorspelbare netwerkservice door de volgende methoden:
Ondersteuning voor toegewezen bandbreedte.
Verbetering van de verlieskenmerken.
Het voorkomen en beheren van netwerkcongestie.
Vormgeven van netwerkverkeer.
Stel prioriteiten voor het verkeer in het hele netwerk.
De Internet Engineering Task Force (IETF) definieert de volgende twee architecturen voor QoS:
Geïntegreerde services (IntServ)
Gedifferentieerde services (DiffServer)
IntServ gebruikt het Resource Reservation Protocol (RSVP) om expliciet de QoS-behoeften van het verkeer van een toepassing langs de apparaten in het end-to-end-pad door het netwerk aan te geven. Als elk netwerkapparaat langs het pad de benodigde bandbreedte kan reserveren, kan de oorspronkelijke toepassing beginnen met verzenden. RFC 2205 definieert RSVP en RFC 1633 definieert IntServ.
DiffServer richt zich op geaggregeerde en geleverde QoS. In plaats van de QoS-vereisten van een toepassing te signaleren, gebruikt DiffServer een DiffServer Code Point (DSCP) in de IP-header om de vereiste QoS-niveaus aan te geven. Cisco IOS® Software Release 12.1(5)T introduceerde DiffServer-compliance op Cisco-routers. Raadpleeg voor meer informatie de volgende documenten:
V. Wat zijn congestie, vertraging en jitter?
A. Een interface ondervindt congestie wanneer deze wordt gepresenteerd met meer verkeer dan het aankan. Netwerkcongestiepunten zijn sterke kandidaten voor Quality of Service (QoS)-mechanismen. Dit is een voorbeeld van typische congestiepunten:
Netwerkcongestie leidt tot vertraging. Een netwerk en zijn apparaten introduceren verschillende soorten vertragingen, zoals uitgelegd in Understanding Delay in Packet Voice Networks. Variatie in vertraging staat bekend als jitter, zoals uitgelegd in Understanding Jitter in Packet Voice Networks (Cisco IOS Platforms). Zowel vertraging als jitter moeten worden gecontroleerd en geminimaliseerd om realtime en interactief verkeer te ondersteunen.
V. Wat is de MQC?
MQC staat voor Modular Quality of Service (QoS) Command Line Interface (CLI). Het is ontworpen om de configuratie van QoS op Cisco-routers en -switches te vereenvoudigen door een gemeenschappelijke opdrachtsyntaxis en de resulterende set QoS-gedragingen op verschillende platformen te definiëren. Dit model vervangt het vorige model van het definiëren van unieke syntaxen voor elke QoS-functie en voor elk platform.
De MQC bestaat uit de volgende drie stappen:
Definieer een verkeersklasse door de opdracht class-map uit te geven.
Maak een verkeersbeleid door de klasse traffic te koppelen aan een of meer QoS-functies door de opdracht policy-map uit te geven.
Bevestig het verkeersbeleid aan de interface, subinterface of Virtual Circuit (VC) door de opdracht servicebeleid uit te geven.
Opmerking: U implementeert de verkeersregelingsfuncties van DiffServer, zoals markering en vormgeving, met behulp van de MQC-syntaxis.
Raadpleeg Modulaire opdrachtregelinterface voor meer informatie.
V. Wat betekent het servicebeleid dat alleen wordt ondersteund op VIP-interfaces met een DCEF-bericht?
A. Op veelzijdige interfaceprocessors (VIP's) in een Cisco 7500-reeks worden alleen gedistribueerde Quality of Service (QoS)-functies ondersteund vanaf Cisco IOS 12.1(5)T, 12.1(5)E en 12.0(14)S. Door gedistribueerde Cisco Express Forwarding (dCEF) in te schakelen, worden gedistribueerde QoS automatisch ingeschakeld.
Niet-VIP-interfaces, ook wel legacy Interface Processors (IP's) genoemd, ondersteunen centrale QoS-functies zoals ingeschakeld op de Route Switch Processor (RSP). Raadpleeg voor meer informatie de volgende documenten:
V. Hoeveel lessen ondersteunt een Quality of Service (QoS)-beleid?
A. In Cisco IOS-versies eerder dan 12.2 kunt u maximaal slechts 256 klassen definiëren en kunt u maximaal 256 klassen binnen elk beleid definiëren als dezelfde klassen worden hergebruikt voor verschillende beleidsregels. Als u twee polissen hebt, mag het totale aantal klassen van beide polissen niet hoger zijn dan 256. Als een beleid Class-Based Weighted Fair Queueing (CBWFQ) bevat (wat betekent dat het een instructie bandbreedte [of prioriteit] bevat binnen een van de klassen), is het totale aantal ondersteunde klassen 64.
In Cisco IOS-versies 12.2(12), 12.2(12)T en 12.2(12)S is deze beperking van 256 globale klassenkaarten gewijzigd en is het nu mogelijk om maximaal 1024 globale klassenkaarten te configureren en 256 klassenkaarten binnen dezelfde beleidskaart te gebruiken.
V. Hoe worden routeringsupdates en Point-to-Point Protocol (PPP) / High-Level Data Link Control (HDLC)-bewaarmiddelen verwerkt wanneer een servicebeleid wordt toegepast?
A. Cisco IOS-routers gebruiken de volgende twee mechanismen om prioriteit te geven aan besturingspakketten:
IP-voorrang
pak_priority
Beide mechanismen zijn ontworpen om ervoor te zorgen dat belangrijke besturingspakketten niet worden weggelaten of als laatste worden weggelaten door de router en het wachtrijsysteem wanneer een uitgaande interface overbelast is. Raadpleeg voor meer informatie Begrijpen hoe routeringsupdates en controlepakketten in de wachtrij staan op een interface met een QoS-servicebeleid.
V. Wordt Quality of Service (QoS) ondersteund op interfaces die zijn geconfigureerd met Integrated Routing and Bridging (IRB)?
A. Nee. U kunt QoS-functies niet configureren wanneer de interface is geconfigureerd voor IRB.
Classificatie en markering
Q. Wat is Quality of Service (QoS) pre-classificatie?
A. Met QoS-voorclassificatie kunt u de oorspronkelijke inhoud van de IP-header van pakketten die tunnelinkapseling en/of -codering ondergaan, vergelijken en classificeren. Deze functie beschrijft niet het proces van het kopiëren van de oorspronkelijke waarde van de Type of Service (ToS) byte van de oorspronkelijke pakketheader naar de tunnelheader. Raadpleeg voor meer informatie de volgende documenten:
V. Welke velden voor pakketkoppen kunnen worden gemarkeerd? Welke waarden zijn beschikbaar?
A. Met de op klassen gebaseerde markeringsfunctie kunt u de Layer 2-, Layer 3- of Multiprotocol Label Switching (MPLS)-header van uw pakketten instellen of markeren. Raadpleeg voor meer informatie de volgende documenten:
V. Kan ik prioriteit geven aan verkeer op basis van de URL?
A. Ja. Met Network Based Application Recognition (NBAR) kunt u pakketten classificeren door velden op de toepassingslaag te matchen. Voorafgaand aan de introductie van NBAR was de meest gedetailleerde classificatie laag 4 Transmission Control Protocol (TCP)- en User Datagram Protocol (UDP)-poortnummers. Raadpleeg voor meer informatie de volgende documenten:
V. Welke platforms en versies van Cisco IOS-software ondersteunen Network Based Application Recognition (NBAR)?
A. Ondersteuning voor NBAR wordt geïntroduceerd in de volgende versies van Cisco IOS-software:
Platform Minimale Cisco IOS-softwareversie 7200 12,1(5)T 7100 12,1(5)T 3660 12,1(5)T 3640 12,1(5)T 3620 12,1(5)T 2600 12,1(5)T 1700 12,2, LID 2, ONDER T) Opmerking: U moet Cisco Express Forwarding (CEF) inschakelen om NBAR te kunnen gebruiken.
Distributed NBAR (DNBAR) is beschikbaar op de volgende platforms:
Platform Minimale Cisco IOS-softwareversie 7500 12,2(4)T, 12,1(6)E FlexWAN 12.1, punt 6, onder e) Opmerking: NBAR wordt niet ondersteund op Catalyst 6000 Multilayer Switch Feature Card (MSFC) VLAN-interfaces, de Cisco 12000-reeks of de Route Switch Module (RSM) voor de Catalyst 5000-reeks. Als u een bepaald platform niet ziet dat hierboven wordt vermeld, neemt u contact op met uw technische vertegenwoordiger van Cisco.
Wachtrijen en congestiebeheer
Q. Wat is het doel van de wachtrij?
A. Queueing is ontworpen om tijdelijke congestie op de interface van een netwerkapparaat op te vangen door overtollige pakketten in buffers op te slaan totdat bandbreedte beschikbaar komt. Cisco IOS-routers ondersteunen verschillende wachtrijmethoden om te voldoen aan de verschillende bandbreedte-, jitter- en vertragingsvereisten van verschillende toepassingen.
Het standaardmechanisme op de meeste interfaces is First In First Out (FIFO). Sommige verkeerstypen hebben meer veeleisende vertraging / jitter-vereisten. Daarom moet een van de volgende alternatieve wachtrijmechanismen worden geconfigureerd of is deze standaard ingeschakeld:
Weighted Fair Queueing (WFQ)
Class-Based Weighted Fair Queueing (CBWFQ)
Low Latency Queueing (LLQ), wat in feite CBWFQ is met een Prioriteitswachtrij (PQ) (bekend als PQCBWFQ)
Prioriteitswachtrij (PQ)
Aangepaste wachtrij (CQ)
Wachtrijen gebeurt over het algemeen alleen op uitgaande interfaces. Een router stelt pakketten in de wachtrij die een interface verlaten. U kunt inkomende verkeer controleren, maar meestal kunt u inkomende verkeer niet in de wachtrij plaatsen (een uitzondering is ontvangstbuffering op een Cisco 7500 Series-router met gedistribueerde Cisco Express Forwarding (dCEF) om pakketten van de ingang naar de uitgang-interface door te sturen; voor meer informatie, raadpleegt u Understanding VIP CPU Running at 99% en Rx-Side Buffering. Op geavanceerde gedistribueerde platforms zoals de Cisco 7500- en 12000-reeks kan de inkomende interface zijn eigen pakketbuffers gebruiken om overtollig verkeer op te slaan dat is overgeschakeld naar een overbelaste uitgaande interface na de schakelbeslissing van de inkomende interface. In zeldzame omstandigheden, meestal wanneer de inkomende interface een langzamere uitgaande interface voedt, kan de inkomende interface toenemende genegeerde fouten ervaren wanneer het pakketgeheugen opraakt. Overmatige congestie kan leiden tot dalingen in de uitvoerwachtrij. Invoerwachtrijdruppels hebben meestal een andere hoofdoorzaak. Raadpleeg het volgende document voor meer informatie over het oplossen van problemen:
Raadpleeg voor meer informatie de volgende documenten:
V. Hoe werken Weighted Fair Queueing (WFQ) en Class Based Weighted Fair Queueing (CBWFQ)?
A. Fair queueing is bedoeld om een redelijk deel van de bandbreedte van een interface toe te wijzen aan actieve gesprekken of IP-stromen. Het classificeert pakketten in subqueues, geïdentificeerd door een conversatie-identificatienummer, met behulp van een hashing-algoritme op basis van verschillende velden van de IP-header en de lengte van het pakket. Dit is de manier waarop het gewicht wordt berekend:
W=K/(prioriteit +1)
K= 4096 met Cisco IOS 12.0(4)T en eerdere releases, en 32384 met 12.0(5)T en latere releases.
Hoe lager het gewicht, hoe hoger de prioriteit en het aandeel van de bandbreedte. Naast het gewicht wordt ook rekening gehouden met de lengte van de verpakking.
Met CBWFQ kunt u een verkeersklasse definiëren en deze een minimale bandbreedtegarantie toewijzen. Het algoritme achter dit mechanisme is WFQ, wat de naam verklaart. Als u CBWFQ wilt configureren, definieert u specifieke klassen in instructies voor de mapklasse. Vervolgens wijst u een beleid toe aan elke klasse in een beleidskaart. Deze beleidskaart wordt vervolgens uitgaand aan een interface gekoppeld. Raadpleeg voor meer informatie de volgende documenten:
V. Als een klasse in Class Based Weighted Fair Queueing (CBWFQ) de bandbreedte niet gebruikt, kunnen andere klassen dan de bandbreedte gebruiken?
A. Ja. Hoewel de bandbreedtegaranties die worden geboden door het uitgeven van de bandbreedte en prioriteitsopdrachten zijn beschreven met woorden als 'gereserveerd' en 'bandbreedte die moet worden opzij gezet', implementeert geen van beide opdrachten een echte reservering. Dit betekent dat als een verkeersklasse de geconfigureerde bandbreedte niet gebruikt, alle ongebruikte bandbreedte wordt gedeeld tussen de andere klassen.
Het wachtrijsysteem vormt een belangrijke uitzondering op deze regel met een prioriteitsklasse. Zoals hierboven vermeld, wordt de aangeboden belasting van een prioriteitsklasse gemeten door een verkeerspolitie. Tijdens congestieomstandigheden kan een prioriteitsklasse geen overtollige bandbreedte gebruiken. Zie voor meer informatie De bandbreedte en prioriteitsopdrachten van een QoS-servicebeleid vergelijken.
V. Wordt Class Based Weighted Fair Queueing (CBWFQ) ondersteund op subinterfaces?
A. Logische IOS-interfaces van Cisco ondersteunen niet inherent een staat van congestie en ondersteunen niet de directe toepassing van een servicebeleid dat een wachtrijmethode toepast. In plaats daarvan moet u eerst vormgeving toepassen op de subinterface met behulp van Generic Traffic Shaping (GTS) of op klasse gebaseerde vormgeving. Raadpleeg QoS-functies toepassen op Ethernet-subinterfaces voor meer informatie.
V. Wat is het verschil tussen de prioriteit- en bandbreedteverklaringen in een beleidskaart?
A. De opdrachten voor prioriteit en bandbreedte verschillen zowel in functionaliteit als in de toepassingen die ze doorgaans ondersteunen. De volgende tabel vat deze verschillen samen:
functie bandbreedte, opdracht prioriteitsopdracht Minimale bandbreedtegarantie Ja Ja Maximale bandbreedtegarantie Nee Ja Ingebouwde politieagent Nee Ja Biedt lage latentie Nee Ja Zie voor meer informatie Vergelijking van de bandbreedte en prioriteitsopdrachten van een QoS-servicebeleid.
V. Hoe wordt de wachtrijlimiet berekend op de FlexWAN- en Versatile Interface Processors (VIP)?
A. Ervan uitgaande dat er voldoende SRAM is op de VIP of FlexWAN, wordt de wachtrijlimiet berekend op basis van een maximale vertraging van 500 ms met een gemiddelde pakketgrootte van 250 bytes. Het volgende is een voorbeeld van een klasse met één Mbps aan bandbreedte:
Wachtrijlimiet = 1000000 / (250 x 8 x 2) = 250
Kleinere wachtrijlimieten worden toegewezen naarmate de hoeveelheid beschikbaar pakketgeheugen afneemt en met een groter aantal virtuele circuits (VCS).
In het volgende voorbeeld wordt een PA-A3 geïnstalleerd in een FlexWAN-kaart voor de Cisco 7600-reeks en ondersteunt deze meerdere subinterfaces met 2 MB permanente virtuele circuits (PVC's). Het servicebeleid wordt toegepast op elke VC.
class-map match-any XETRA-CLASS match access-group 104 class-map match-any SNA-CLASS match access-group 101 match access-group 102 match access-group 103 policy-map POLICY-2048Kbps class XETRA-CLASS bandwidth 320 class SNA-CLASS bandwidth 512 interface ATM6/0/0 no ip address no atm sonet ilmi-keepalive no ATM ilmi-keepalive ! interface ATM6/0/0.11 point-to-point mtu 1578 bandwidth 2048 ip address 22.161.104.101 255.255.255.252 pvc ABCD class-vc 2048Kbps-PVC service-policy out POLICY-2048KbpsDe interface Asynchronous Transfer Mode (ATM) krijgt een wachtrijlimiet voor de hele interface. De limiet is een functie van de totale beschikbare buffers, het aantal fysieke interfaces op de FlexWAN en de maximaal toegestane wachtrijvertraging op de interface. Elk PVC krijgt een deel van de interfacelimiet op basis van de Sustained Cell Rate (SCR) of Minimum Cell Rate (MCR) van het PVC, en elke klasse krijgt een deel van de PVC-limiet op basis van de bandbreedtetoewijzing.
De volgende voorbeelduitvoer van de opdracht Beleidskaart weergeven is afgeleid van een FlexWAN met 3687 globale buffers. Geef de opdracht buffer tonen op om deze waarde te zien. Elke twee Mbps PVC krijgt 50 pakketten toegewezen op basis van de PVC-bandbreedte van twee Mbps (2047/149760 x 3687 = 50). Elke klasse krijgt vervolgens een deel van de 50 toegewezen, zoals weergegeven in de volgende uitvoer:
service-policy output: POLICY-2048Kbps class-map: XETRA-CLASS (match-any) 687569 packets, 835743045 bytes 5 minute offered rate 48000 bps, drop rate 6000 BPS match: access-group 104 687569 packets, 835743045 bytes 5 minute rate 48000 BPS queue size 0, queue limit 7 packets output 687668, packet drops 22 tail/random drops 22, no buffer drops 0, other drops 0 bandwidth: kbps 320, weight 15 class-map: SNA-CLASS (match-any) 2719163 packets, 469699994 bytes 5 minute offered rate 14000 BPS, drop rate 0 BPS match: access-group 101 1572388 packets, 229528571 bytes 5 minute rate 14000 BPS match: access-group 102 1146056 packets, 239926212 bytes 5 minute rate 0 BPS match: access-group 103 718 packets, 245211 bytes 5 minute rate 0 BPS queue size 0, queue limit 12 packets output 2719227, packet drops 0 tail/random drops 0, no buffer drops 0, other drops 0 bandwidth: kbps 512, weight 25 queue-limit 100 class-map: class-default (match-any) 6526152 packets, 1302263701 bytes 5 minute offered rate 44000 BPS, drop rate 0 BPS match: any 6526152 packets, 1302263701 bytes 5 minute rate 44000 BPS queue size 0, queue limit 29 packets output 6526840, packet drops 259 tail/random drops 259, no buffer drops 0, other drops 0Als uw verkeersstromen grote pakketgroottes gebruiken, kan de opdrachtuitvoer voor beleidskaart tonen een toenemende waarde voor het veld geen buffer daalt rapporteren omdat u mogelijk geen buffers meer hebt voordat u de wachtrijlimiet bereikt. Probeer in dit geval de wachtrijlimiet in niet-prioriteitsklassen handmatig af te stemmen. Raadpleeg voor meer informatie De wachtrijlimiet voor verzending met IP naar ATM CoS begrijpen.
V. Hoe verifieert u de wachtrijgrenswaarde?
A. Op niet-gedistribueerde platforms is de wachtrijlimiet standaard 64 pakketten. De volgende voorbeelduitvoer is vastgelegd op een Cisco 3600 Series-router:
november# show policy-map interface s0 Serial0 Service-policy output: policy1 Class-map: class1 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: ip precedence 5 Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 30 (kbps) Max Threshold 64 (packets) !--- Max Threshold is the queue-limit. (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: class2 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: ip precedence 2 Match: ip precedence 3 Weighted Fair Queueing Output Queue: Conversation 266 Bandwidth 24 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: any
V. Kan ik een eerlijke wachtrij in een klas inschakelen?
A. De Cisco 7500-reeks met gedistribueerde servicekwaliteit (QoS) ondersteunt eerlijke wachtrijen per klasse. Andere platforms, waaronder de Cisco 7200 Series en Cisco 2600/3600 Series, ondersteunen Weighted Fair Queueing (WFQ) in de klasse-standaard klasse; alle bandbreedteklassen gebruiken First In First Out (FIFO).
V. Welke opdrachten kan ik gebruiken om wachtrijen te bewaken?
A. Gebruik de volgende opdrachten om de wachtrij te bewaken:
show queue {interface}{interfacenummer} - Op andere Cisco IOS-platforms dan de Cisco 7500-reeks worden met deze opdracht de actieve wachtrijen of gesprekken weergegeven. Als de interface of Virtual Circuit (VC) niet overbelast is, worden er geen wachtrijen weergegeven. In de Cisco 7500-reeks wordt de opdracht Wachtrij weergeven niet ondersteund.
interface-nummer wachtrij [vc [vpi/vci] tonen - Hiermee worden de wachtrijstatistieken van een interface of een VC weergegeven. Zelfs als er geen congestie is, kun je hier nog steeds enkele hits zien. De reden hiervoor is dat procesgeschakelde pakketten altijd worden geteld, ongeacht de congestie die aanwezig is. Cisco Express Forwarding (CEF) en snel geschakelde pakketten worden niet meegerekend, tenzij er congestie is. De bestaande wachtrijmechanismen, zoals Priority Queueing (PQ), Custom Queueing (CQ) en Weighted Fair Queueing (WFQ), bieden geen classificatiestatistieken. Deze statistieken worden alleen verstrekt op basis van modulaire Quality of Service Command Line Interface (MQC)-functies in afbeeldingen die later zijn dan 12.0(5)T.
show policy interface {interface}{interface number} - De packets teller telt het aantal pakketten dat overeenkomt met de criteria van de klasse. Deze teller neemt toe, ongeacht of de interface overbelast is. De overeenkomende pakketteller geeft het aantal pakketten aan dat overeenkomt met de criteria van de klasse wanneer de interface overbelast was. Raadpleeg het volgende document voor meer informatie over pakkettellers:
Pakkettellers begrijpen in interface voor beleidskaart weergeven Uitvoer
Cisco Class-Based QoS Configuration and Statistics MIB - Biedt Simple Network Management Protocol (SNMP)-bewakingsmogelijkheden.
V. RSVP kan worden gebruikt in combinatie met Class Based Weighted Fair Queueing (CBWFQ). Wanneer zowel het Resource Reservation Protocol (RSVP) als CBWFQ zijn geconfigureerd voor een interface, handelen RSVP en CBWFQ dan onafhankelijk en vertonen ze hetzelfde gedrag dat ze zouden vertonen als ze alleen zouden werken? RSVP lijkt zich te gedragen alsof CBWFQ niet is geconfigureerd met betrekking tot de beschikbaarheid, beoordeling en toewijzing van bandbreedte.
A. Bij gebruik van RSVP en CB-WFQ in Cisco IOS Software Release 12.1(5)T en hoger kan de router zodanig werken dat RSVP-stromen en CBWFQ-klassen de beschikbare bandbreedte op een interface of PVC delen, zonder overinschrijving.
IOS Software Release 12.2(1)T en hoger, stelt RSVP in staat om toegangscontrole te doen met behulp van zijn eigen "ip rsvp-bandbreedte" -pool, terwijl CBWFQ classificatie, bewaking en planning van RSVP-pakketten doet. Hierbij wordt ervan uitgegaan dat pakketten vooraf zijn gemarkeerd door de afzender en dat niet-RSVP-pakketten anders zijn gemarkeerd.
Congestion Avoidance Weighted Random Early Detection (WRED)
V. Kan ik tegelijkertijd Weighted Random Early Detection (WRED) en Low Latency Queueing (LLQ) of Class Based Weighted Fair Queueing (CBWFQ) inschakelen?
A. Ja. Queueing definieert de volgorde van pakketten die een wachtrij verlaten. Dit betekent dat het een pakketplanningsmechanisme definieert. Het kan ook worden gebruikt om eerlijke bandbreedtetoewijzing en minimale bandbreedtegaranties te bieden. RFC 2475 definieert dropping daarentegen als het "proces van het weggooien van pakketten op basis van gespecificeerde regels." Het standaard dropmechanisme is tail drop, waarbij de interface pakketten laat vallen wanneer de wachtrij vol is. Een alternatief dropmechanisme is Random Early Detection (RED) en Cisco's WRED, dat pakketten willekeurig laat vallen voordat de wachtrij vol is en een consistente gemiddelde wachtrijdiepte probeert te behouden. WRED gebruikt de IP-voorkeurswaarde van pakketten om een gedifferentieerde drop-beslissing te nemen. Voor meer informatie, zie Weighted Random Early Detection (WRED).
V. Hoe kan ik Weighted Random Early Detection (WRED) controleren en zien of het daadwerkelijk effect heeft?
A. WRED bewaakt de gemiddelde wachtrijdiepte en begint pakketten te laten vallen wanneer de berekende waarde de minimumdrempelwaarde overschrijdt. Geef de opdracht interface voor weergave van de beleidskaart op en controleer de gemiddelde waarde voor de wachtrijdiepte, zoals in het volgende voorbeeld wordt weergegeven:
Router# show policy interface s2/1 Serial2/1 output : p1 Class c1 Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 20 (%) (pkts matched/bytes matched) 168174/41370804 (pkts discards/bytes discards/tail drops) 20438/5027748/0 mean queue depth: 39 Dscp Random drop Tail drop Minimum Maximum Mark (Prec) pkts/bytes pkts/bytes threshold threshold probability 0(0) 2362/581052 1996/491016 20 40 1/10 1 0/0 0/0 22 40 1/10 2 0/0 0/0 24 40 1/10 [output omitted]
Politie en vormgeving
V. Wat is het verschil tussen politie en vormgeving?
A. Het volgende diagram illustreert het belangrijkste verschil. Traffic shaping behoudt overtollige pakketten in een wachtrij en plant vervolgens de overtollige voor latere transmissie in stappen van tijd. Het resultaat van verkeersvorming is een afgevlakte pakketuitvoersnelheid. Verkeerspolitie daarentegen verspreidt uitbarstingen. Wanneer de verkeerssnelheid de geconfigureerde maximale snelheid bereikt, wordt overtollig verkeer weggelaten (of gemarkeerd). Het resultaat is een uitvoersnelheid die wordt weergegeven als een zaagtand met toppen en troggen.
Raadpleeg Overzicht van de controle en vormgeving voor meer informatie.
V. Wat is een token bucket en hoe werkt het algoritme?
A. Een token bucket zelf heeft geen teruggooi of prioriteitsbeleid. Het volgende is een voorbeeld van hoe de token bucket metafoor werkt:
Tokens worden in een bepaald tempo in de emmer gestopt.
Elk token is een machtiging voor de bron om een bepaald aantal bits te verzenden.
Om een pakket te verzenden, moet de verkeersregelaar een aantal tokens kunnen verwijderen dat gelijk is aan de representatie van 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 op capaciteit vult, worden nieuw aangekomen tokens weggegooid en zijn ze niet beschikbaar voor toekomstige pakketten. Dus op elk moment is de grootste uitbarsting die een bron in het netwerk kan sturen ongeveer evenredig met de grootte van de emmer. Een token-emmer staat burstiness toe, maar begrenst het.
V. Wat betekenen Committed Burst (BC) en Excess Burst (Be) met een verkeerspolitie zoals op klasse gebaseerde politiebewaking en hoe moet ik deze waarden selecteren?
A. Een verkeerspolitie buffert geen overtollige pakketten en verzendt ze later, zoals het geval is voor een shaper. In plaats daarvan voert de politieagent een eenvoudige verzending uit of verzendt geen beleid zonder buffering. Tijdens periodes van congestie, omdat je niet kunt bufferen, kun je het beste pakketten minder agressief laten vallen door uitgebreide burst goed te configureren. Daarom is het belangrijk om te begrijpen dat de politieagent de normale burst- en extended burst-waarden gebruikt om ervoor te zorgen dat de geconfigureerde committed information rate (CIR) wordt bereikt.
De burst-parameters zijn losjes gemodelleerd naar de generieke bufferregel voor routers. De regel beveelt aan om buffering gelijk aan de round-trip-tijdbitrate te configureren om de openstaande Transmission Control Protocol (TCP)-vensters van alle verbindingen in tijden van congestie te accommoderen.
De volgende tabel beschrijft het doel en de aanbevolen formule voor de normale en uitgebreide burst-waarden:
burst-parameter Doel Aanbevolen formule normale burst
Implementeert een standaard token bucket.
Stelt de maximale grootte van de token-emmer in (hoewel tokens kunnen worden geleend als Be groter is dan BC).
Bepaalt hoe groot de tokenemmer kan zijn omdat nieuw aangekomen tokens worden weggegooid en niet beschikbaar zijn voor toekomstige pakketten als de emmer de capaciteit vult.
Opmerking: 1,5 seconden is de typische rondreistijd.
uitgebreide burst
Implementeert een token bucket met uitgebreide burst mogelijkheid.
Uitgeschakeld door BC = Be.
Wanneer BC gelijk is aan Be, kan de verkeersregelaar geen tokens lenen en laat hij het pakket gewoon vallen wanneer er onvoldoende tokens beschikbaar zijn.
Niet alle platforms gebruiken of ondersteunen dezelfde waarden voor een politieagent. Raadpleeg het volgende document voor meer informatie over de ondersteunde waarden voor uw specifieke platform:
V. Hoe bepaalt het Committed Access Rate (CAR) of op klassen gebaseerde politiewerk of een pakket voldoet aan of hoger is dan het Committed Information Rate (CIR)? De router laat pakketten vallen en rapporteert een overschrijding van de snelheid, ook al is de conforme snelheid minder dan de geconfigureerde CIR.
A. Een verkeersregelaar gebruikt de normale burst- en extended burst-waarden om ervoor te zorgen dat de geconfigureerde CIR wordt bereikt. Het instellen van voldoende hoge burst-waarden is belangrijk om een goede doorvoer te garanderen. Als de burstwaarden te laag zijn geconfigureerd, kan de bereikte snelheid veel lager zijn dan de geconfigureerde snelheid. Het bestraffen van tijdelijke uitbarstingen kan een sterke negatieve invloed hebben op de doorvoer van het Transmission Control Protocol (TCP) -verkeer. Met CAR geeft u de opdracht show interface rate-limit om de huidige burst te bewaken en te bepalen of de weergegeven waarde consistent dicht bij de limiet (BC) en verlengde limiet (Be) waarden ligt.
rate-limit 256000 7500 7500 conform-action continue exceed-action drop rate-limit 512000 7500 7500 conform-action continue exceed-action drop router# show interfaces virtual-access 26 rate-limit Virtual-Access26 Cable Customers Input matches: all traffic params: 256000 BPS, 7500 limit, 7500 extended limit conformed 2248 packets, 257557 bytes; action: continue exceeded 35 packets, 22392 bytes; action: drop last packet: 156ms ago, current burst: 0 bytes last cleared 00:02:49 ago, conformed 12000 BPS, exceeded 1000 BPS Output matches: all traffic params: 512000 BPS, 7500 limit, 7500 extended limit conformed 3338 packets, 4115194 bytes; action: continue exceeded 565 packets, 797648 bytes; action: drop last packet: 188ms ago, current burst: 7392 bytes last cleared 00:02:49 ago, conformed 194000 BPS, exceeded 37000 BPSRaadpleeg voor meer informatie de volgende documenten:
V. Zijn de limiet voor burst en wachtrij onafhankelijk van elkaar?
A. Ja, politieburst en wachtrijlimiet zijn gescheiden en onafhankelijk van elkaar. U kunt de policer bekijken als een poort die een bepaald aantal pakketten (of bytes) toestaat en de wachtrij als een emmer van grootte wachtrijlimiet die de toegelaten pakketten bevat voorafgaand aan verzending op het netwerk. Idealiter wilt u dat uw emmer groot genoeg is om een uitbarsting van bytes / pakketten te bevatten die door de poort (politieagent) worden toegelaten.
Quality of Service (QoS) Frame Relay
V. Welke waarden moet ik selecteren voor CIR (Commitment Information Rate), BC (Commitment Burst), BE (Excess Burst) en MinCIR (Minimum CIR)?
A. Frame Relay Traffic Shaping, die u inschakelt door de opdracht frame-relay traffic-shaping uit te geven, ondersteunt verschillende configureerbare parameters. Deze parameters omvatten frame-relay cir, frame-relay mincir, en frame-relay BC. Raadpleeg de volgende documenten voor meer informatie over het selecteren van deze waarden en het begrijpen van gerelateerde show-opdrachten:
V. Werkt Priority Queueing op de hoofdinterface van Frame Relay in Cisco IOS 12.1?
A. Framerelaisinterfaces ondersteunen zowel interfacewachtrijmechanismen als wachtrijmechanismen per virtueel circuit (VC). Vanaf Cisco IOS 12.0(4)T ondersteunt de interfacewachtrij alleen First In First Out (FIFO) of Per Interface Priority Queueing (PIPQ) wanneer u Frame Relay Traffic Shaping (FRTS) configureert. Daarom werkt de volgende configuratie niet meer als u een upgrade uitvoert naar Cisco IOS 12.1.
interface Serial0/0 frame-relay traffic-shaping bandwidth 256 no ip address encapsulation frame-relay IETF priority-group 1 ! interface Serial0/0.1 point-to-point bandwidth 128 ip address 136.238.91.214 255.255.255.252 no ip mroute-cache traffic-shape rate 128000 7936 7936 1000 traffic-shape adaptive 32000 frame-relay interface-dlci 200 IETFAls FRTS niet is ingeschakeld, kunt u een alternatieve wachtrijmethode, zoals Class Based Weighted Fair Queueing (CBWFQ), toepassen op de hoofdinterface, die werkt als een enkele bandbreedteleiding. Daarnaast kunt u vanaf Cisco IOS 12.1.1(T) Frame Relay Permanent Virtual Circuits (PVC) Priority Interface Queueing (PIPQ) inschakelen op een hoofdinterface van Frame Relay. U kunt PVC's met hoge, gemiddelde, normale of lage prioriteit definiëren en de opdracht frame-relay interface-queue priority op de hoofdinterface uitgeven, zoals in het volgende voorbeeld wordt getoond:
interface Serial3/0 description framerelay main interface no ip address encapsulation frame-relay no ip mroute-cache frame-relay traffic-shaping frame-relay interface-queue priority interface Serial3/0.103 point-to-point description frame-relay subinterface ip address 1.1.1.1 255.255.255.252 frame-relay interface-dlci 103 class frameclass map-class frame-relay frameclass frame-relay adaptive-shaping becn frame-relay cir 60800 frame-relay BC 7600 frame-relay be 22800 frame-relay mincir 8000 service-policy output queueingpolicy frame-relay interface-queue priority low
V. Werkt Frame Relay Traffic Shaping (FRTS) met Distributed Cisco Express Forwarding (dCEF) en Distributed Class Based Weighted Fair Queueing (dCBWFQ)?
A. Vanaf Cisco IOS 12.1(5)T worden alleen de gedistribueerde versie van QoS-functies ondersteund op VIP's in de Cisco 7500-reeks. Als u verkeersvorming wilt inschakelen op Frame Relay-interfaces, gebruikt u DTS (Distributed Traffic Shaping). Raadpleeg voor meer informatie de volgende documenten:
Quality of Service (QoS) via asynchrone overdrachtsmodus (ATM)
V. Waar pas ik een servicebeleid toe met Class Based Weighted Fair Queueing (CBWFQ) en Low Latency Queueing (LLQ) op een Asynchronous Transfer Mode (ATM)-interface?
Vanaf Cisco IOS 12.2 ondersteunen ATM-interfaces het servicebeleid op drie niveaus of logische interfaces: hoofdinterface, subinterface en permanent virtueel circuit (PVC). Waar u het beleid toepast, is een functie van de Quality of Service (QoS) -functie die u inschakelt. Het wachtrijbeleid moet per virtueel circuit (VC) worden toegepast, omdat de ATM-interface het congestieniveau per VC bewaakt en wachtrijen voor overtollige pakketten per VC onderhoudt. Raadpleeg voor meer informatie de volgende documenten:
V. Welke bytes worden door IP geteld in de wachtrij voor de serviceklasse van de asynchrone overdrachtmodus (ATM)?
A. De bandbreedte- en prioriteitsopdrachten die in een servicebeleid zijn geconfigureerd om respectievelijk class-based weighted fair queueing (CBWFQ) en low latency queueing (LLQ) mogelijk te maken, gebruiken een Kbps-waarde die dezelfde overheadbytes telt als die worden geteld door de uitvoer van de opdracht voor de interface tonen. In het bijzonder telt het layer 3-wachtrijsysteem Logical Link Control / Subnetwork Access Protocol (LLC / SNAP). Het telt niet mee:
Aanhangwagen ATM Adaptation Layer 5 (AAL5)
Padding maakt van laatste cel een even veelvoud van 48 bytes
Celkoptekst van vijf bytes
Welke bytes worden geteld door IP naar ATM CO's in de wachtrij?
V. Hoeveel Virtual Circuits (VCS) kunnen tegelijk een servicebeleid ondersteunen?
A. Het volgende document bevat nuttige richtlijnen voor het aantal Asynchronous Transfer Mode (ATM) VCS dat kan worden ondersteund. Ongeveer 200 tot 300 permanente virtuele circuits (PVC's) van VBR-nrt zijn veilig ingezet:
Overweeg ook het volgende:
Gebruik een krachtige processor. Een VIP4-80 levert bijvoorbeeld aanzienlijk hogere prestaties dan een VIP2-50.
Hoeveelheid beschikbaar pakketgeheugen. Op de NPE-400 is maximaal 32 MB (in een systeem met 256 MB) gereserveerd voor pakketbuffer. Voor een NPE-200 is maximaal 16 MB gereserveerd voor pakketbuffers op een systeem met 128 MB.
Configuraties met per-VC Weighted Random Early Detection (WRED) die gelijktijdig op maximaal 200 ATM-PVC's werken, zijn uitgebreid getest. De hoeveelheid pakketgeheugen op de VIP2-50 die kan worden gebruikt voor de per-VC wachtrijen is eindig. Een VIP2-50 met 8-MB SRAM biedt bijvoorbeeld 1085 pakketbuffers die beschikbaar zijn voor IP naar ATM CO's per VC-wachtrij waarop WRED actief is. Als 100 ATM-PVC's werden geconfigureerd en als alle VCS tegelijkertijd overmatige congestie ondervonden (zoals kan worden gesimuleerd in testomgevingen waar niet-TCP-stroomgestuurde bron zou worden gebruikt), dan zou gemiddeld elk PVC ongeveer 10 pakketten buffering hebben, wat te kort kan zijn voor WRED om succesvol te werken. VIP2-50-apparaten met groot SRAM worden daarom sterk aanbevolen in ontwerpen met een hoog aantal ATM-PVC's die per VC-WRED worden uitgevoerd en die tegelijkertijd congestie kunnen ervaren.
Hoe hoger het aantal geconfigureerde actieve PVC's, hoe lager hun Sustained Cell Rate (SCR) zou moeten zijn, en bijgevolg hoe korter de wachtrij die WRED nodig heeft om op het PVC te werken. Zoals het geval is bij het gebruik van de standaard WRED-profielen van de fase 1-functie IP to ATM Class of Service (CO's), zou het configureren van lagere WRED-valdrempels wanneer per-VC WRED wordt geactiveerd op een zeer groot aantal congestieve ATM-pvc's met lage snelheid het risico op buffertekort op de VIP minimaliseren. Buffertekort op de VIP leidt niet tot enige storing. In het geval van buffertekort op de VIP degradeert de IP naar ATM CO's fase 1-functie eenvoudig naar First In First Out (FIFO) -staartval tijdens de periode van buffertekort (dat wil zeggen hetzelfde valbeleid dat zou optreden als de IP naar ATM CO's-functie niet op dit PVC was geactiveerd).
Maximum aantal gelijktijdige VCS dat redelijkerwijs kan worden ondersteund.
V. Welke hardware voor de asynchrone overdrachtmodus (ATM) ondersteunt de functies IP to ATM Class of Service (CO's), waaronder Class Based Weighted Fair Queueing (CBWFQ) en Low Latency Queueing (LLQ)?
A. IP naar ATM CO's verwijst naar een reeks functies die zijn ingeschakeld op basis van een per-virtueel circuit (VC). Gezien deze definitie wordt IP naar ATM CO's niet ondersteund op de ATM Interface Processor (AIP), PA-A1 of 4500 ATM-netwerkprocessors. Deze ATM-hardware ondersteunt geen wachtrijen per VC, omdat de PA-A3 en de meeste netwerkmodules (behalve de ATM-25) dit definiëren. Raadpleeg voor meer informatie het volgende document:
Voice and Quality of Service (QoS)
V. Hoe werkt Link Fragmentation and Interleaving (LFI)?
Interactief verkeer zoals Telnet en Voice over IP is vatbaar voor verhoogde latentie wanneer het netwerk grote pakketten verwerkt, zoals FTP-overdrachten (File Transfer Protocol) via een WAN. Packet delay voor interactief verkeer is significant wanneer de FTP-pakketten in de wachtrij staan op langzamere WAN-links. Er werd een methode bedacht om grotere pakketten te fragmenteren en de kleinere (spraak)pakketten in de wachtrij te plaatsen tussen de fragmenten van de grotere pakketten (FTP). Cisco IOS-routers ondersteunen verschillende fragmentatiemechanismen van laag 2. Raadpleeg voor meer informatie de volgende documenten:
V. Welke tools kan ik gebruiken om de prestaties van Voice over IP te controleren?
A. Cisco biedt momenteel verschillende opties voor het bewaken van Quality of Service (QoS) in netwerken met behulp van Cisco's Voice over IP-oplossingen. Deze oplossingen meten de stemkwaliteit niet met behulp van Perceptual Speech Quality Measurement (PSQM) of enkele van de nieuwe voorgestelde algoritmen voor stemkwaliteitsmeting. Hiervoor zijn tools van Agilent (HP) en NetIQ beschikbaar. Cisco biedt echter wel tools die een idee geven van de spraakkwaliteit die u ervaart door vertraging, jitter en pakketverlies te meten. Raadpleeg Cisco Service Assurance Agent en Internetwork Performance Monitor gebruiken voor meer informatie over het beheer van de servicekwaliteit in Voice over IP-netwerken.
V. %SW_MGR-3-CM_ERROR_FEATURE_CLASS: Connection Manager Fout: Klasse: SSS (QoS) - installatiefout, negeren.
A. De installatiefout van de voorziening is een verwacht gedrag wanneer een ongeldige configuratie wordt toegepast op een sjabloon. Het geeft aan dat het servicebeleid niet is toegepast vanwege een conflict. In het algemeen moet u shaping niet configureren op de standaardklasse van het onderliggende beleid in hiërarchische beleidskaarten, maar in plaats daarvan configureren op het bovenliggende beleid van de interface. Dit bericht wordt samen met de traceback afgedrukt als gevolg.
Bij sessiegebaseerd beleid hoeft het vormgeven van de standaardklasse alleen op subinterface- of PVC-niveau te gebeuren. Vormgeven op de fysieke interface wordt niet ondersteund. Als de configuratie op de fysieke interface wordt uitgevoerd, is het optreden van deze foutmelding een verwacht gedrag.
In het geval van LNS kan een andere reden zijn dat het servicebeleid via de radiusserver kan worden geleverd wanneer de sessies worden geopend. Geef de opdracht show tech uit om de configuratie van de radiusserver te bekijken en om eventuele illegale servicebeleidsregels te bekijken die via de radiusserver zijn geïnstalleerd wanneer de sessie wordt weergegeven of flapt.
Gerelateerde informatie
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
1.0 |
11-Apr-2002
|
Eerste vrijgave |
Feedback