Inhoud

Inleiding

Algemeen

Classificatie en markering

Wachtrijen- en congestiebeheer

Vermijding van congestievermijding door gewogen willekeurige vroege detectie (WRED)

Toezicht en traffic shaping

QoS-Frame Relay (Quality of Service)

Quality-of-Service (QoS) via Asynchronous Transfer Mode (ATM)

Voice en Quality of Service (QoS)

Gerelateerde informatie

Inleiding

Dit document behandelt de meest frequent AskedQ's (Vragen in verband met Quality of Service (QoS).

Algemeen

Vraag: Wat is Quality of Service (QoS)?

A. QoS verwijst naar de mogelijkheid van een netwerk om betere service te bieden aan geselecteerd netwerkverkeer via diverse onderliggende technologieën waaronder Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet en 802.1 netwerken, SONET en IP-routed netwerken.

QoS is een verzameling technologieën waarmee toepassingen voorspelbare serviceniveaus kunnen aanvragen en ontvangen in termen van doorvoercapaciteit (bandbreedte), latentieafwijkingen (jitter) en vertragingen. In het bijzonder bieden QoS-functies betere en voorspelbaardere netwerkservice door de volgende methoden:

- Ondersteuning van toegewijde bandbreedte.

- Verbetering van verlieskenmerken.

- Vermijden en beheren van netwerkcongestie.

- Netwerkverkeer vormen.

- De verkeersprioriteiten op het netwerk instellen.

De Internet Engineering Task Force (IETF) definieert de volgende twee architecturen voor QoS:

- Geïntegreerde services (IntServ)

- Gedifferentieerde services (DiffServ)

IntServ gebruikt het Resource Reservation Protocol (RSVP) om uitdrukkelijk 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 gewenste bandbreedte kan reserveren, kan de oorspronkelijke toepassing beginnen met het verzenden. Verzoek om Comments (RFC) 2205 definieert RSVP en RFC 1633 definieert IntServ.

DiffServ concentreert zich op geaggregeerde en vooraf ingestelde QoS. In plaats van signalering van de QoS-vereisten van een toepassing gebruikt DiffServ een DiffServ-codepoint (DSCP) in de IP-header om de gewenste QoS-niveaus aan te geven. Cisco IOS® softwarerelease 12.1(5)T heeft DiffServ-conformiteit op Cisco-routers geïntroduceerd. Raadpleeg voor meer informatie de volgende documenten:

- Geïntegreerde services in Cisco IOS 12.1

- DiffServ implementeren voor end-to-end Quality-of-Service

- Quality-of-Service beleid met DSCP implementeren

Wat zijn congestie, uitstel en jitter?

A. Een interface ervaart congestie wanneer het wordt voorgesteld met meer verkeer dan het kan verwerken. Netwerkcongestiepunten zijn sterke kandidaten voor QoS-mechanismen (Quality of Service). Het volgende voorbeeld van typische congestiepunten:

Netwerkcongestie leidt tot vertraging. Een netwerk en zijn apparaten introduceren verschillende soorten vertragingen, zoals uitgelegd in de Vertraging van het begrip in de netwerken van de Packet Voice. Variatie in vertraging is bekend als jitter, zoals uitgelegd in Understanding Jitter in Packet Voice Networks (Cisco IOS-platforms). Zowel de vertraging als de scherpstelling moeten worden beheerst en geminimaliseerd ter ondersteuning van realtime en interactief verkeer.

Wat is de MQC?

A. MQC staat voor QoS-opdrachtregel (modulair Quality of Service) (CLI). Het is ontworpen om de configuratie van QoS op Cisco routers en switches te vereenvoudigen door een gemeenschappelijke opdrachtsyntaxis te definiëren en een resulterende reeks QoS-gedragingen langs platforms te definiëren. Dit model vervangt het vorige model van het definiëren van unieke sync's voor elke QoS-functie en voor elk platform.

De MQC bevat de volgende drie stappen:

1. Defineer een verkeersklasse door de class-map opdracht uit te geven.

2. Maak een verkeersbeleid door de verkeersklasse te associëren met een of meer QoS-functies door de opdracht policy-map uit te geven.

3. Bevestig het verkeersbeleid aan de interface, subinterface of Virtual Circuit (VC) door de opdracht Service-beleid uit te geven.

Opmerking: U implementeert de verkeerconditioneringsfuncties van DiffServ, zoals markering en vormgeving, met behulp van de MQC syntax.

Raadpleeg voor meer informatie de modulaire Quality of Service Opdracht-Line interface.

Q. Wat wordt het service-beleid alleen ondersteund op VIP-interfaces met DCEF-enabled-bericht?

A. Op veelzijdige interfaceprocessors (VIP’s) in een Cisco 7500 Series worden alleen gedistribueerde Quality of Service (QoS) ondersteund vanaf Cisco IOS 12.1(5)T, 12.1(5)E en 12.0(14)S. Toewijzing van gedistribueerd Cisco Express Forwarding (dCEF) maakt automatisch gedistribueerde QoS mogelijk.

Non-VIP interfaces, bekend als legacy Interface Processors (IP’s), ondersteunen centrale QoS-functies die mogelijk zijn op de Route Switch Processor (RSP). Raadpleeg voor meer informatie de volgende documenten:

- Gedistribueerde op klasse gebaseerde Weighted Fair Queuing en gedistribueerde gewogen willekeurige detectie

- Gedistribueerde Low Latency Queueing

- Gedistribueerde traffic shaping

- Veelzijdige interfaceprocessor-gebaseerde gedistribueerde FRF.11 en FRF.12 voor Cisco IOS release 12.1 T

Q. Hoeveel klassen ondersteunt een QoS-beleid (Quality of Service)?

A. In Cisco IOS versies eerder dan 12.2 kunt u een maximum van slechts 256 klassen definiëren en u kunt tot 256 klassen binnen elk beleid definiëren als de zelfde klassen voor verschillend beleid opnieuw gebruikt worden. Als u twee beleid hebt, zou het totale aantal klassen van beide beleid niet groter moeten zijn dan 256. Als een beleid op klasse gebaseerde Weighted Fair Queueing (CBWFQ) omvat (wat betekent dat het een bandbreedte [of prioriteit] statement binnen een van de klassen bevat), 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 global class-maps gewijzigd. Het is nu mogelijk om tot 1024 global class-maps te configureren en 256 class-maps te gebruiken in dezelfde beleidskaart.

Q. Hoe worden de routing updates en Point-to-Point Protocol (PPP)/High-Level Data Link Control (HDLC) verwerkt wanneer een servicebeleid wordt toegepast?

A. Cisco IOS-routers gebruiken de volgende twee mechanismen om controlepakketten prioriteit te geven:

- IP-voorrang

- paks_prioriteit

Beide mechanismen zijn ontworpen om ervoor te zorgen dat de belangrijkste controlepakketten niet worden ingetrokken of door de router en het systeem van de wachtrijen last worden ingetrokken wanneer een uitgaande interface wordt geblokkeerd. Raadpleeg voor meer informatie het begrip 'Routing updates and Control Packets' op een interface met een QoS-servicebeleid.

Q. wordt Quality of Service (QoS) ondersteund op interfaces ingesteld met Integrated Routing and Bridging (IRB)?

A. Nee. U kunt de QoS-functies niet configureren als de interface is ingesteld voor IRB.

Classificatie en markering

Q. What is Quality of Service (QoS) pre-classificatie?

A. Met de pre-classificatie QoS kunt u de oorspronkelijke inhoud van de IP-header van pakketten die tunnelinsluiting en/of -encryptie ondergaan, vergelijken en classificeren. Deze functie beschrijft niet het proces voor het kopiëren van de oorspronkelijke waarde van het Type of Service (ToS)-byte van de oorspronkelijke pakketheader naar de tunnelkop. Raadpleeg voor meer informatie de volgende documenten:

- QoS configureren voor Virtual Private Networks

- Quality-of-Service voor Virtual Private Networks, 12.2(2)T-functiemodule

Q. Welke pakketheader-velden kunnen worden herkend? Welke waarden zijn er beschikbaar?

A. Met de op klasse gebaseerde markering kunt u de Layer 2, Layer 3 of MPLS (Multiprotocol Label Switching)-header van uw pakketten instellen of markeren. Raadpleeg voor meer informatie de volgende documenten:

- Op klasse gebaseerde pakketmarkering configureren

- Wanneer stelt een router het CLP-bit in een ATM-cel in?

- Packet Marking op Frame Relay PVC’s configureren

Kan ik prioriteit geven aan verkeer op basis van de URL?

A. Ja. Network-Based Application Recognition (NBAR) stelt u in staat pakketten in te delen door ze op velden in de toepassingslaag aan te passen. Vóór de introductie van NBAR was de meest granulaire classificatie Layer 4 Transmission Control Protocol (TCP) en User Datagram Protocol (UDP) poortnummers. Raadpleeg voor meer informatie de volgende documenten:

- Network-Based Application Recognition Q&A

- NBAR-toepassingsnetwerken

- Netwerkgebaseerde Application Recognition- en toegangscontrolelijsten voor het blokkeren van het codegebied

- Uw netwerk beschermen tegen het NIMA-virus

Q. Welke platforms en Cisco IOS-softwareversies 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-softwarerelease

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(2)T

Opmerking: U moet Cisco Express Forwarding (CEF) activeren om NBAR te kunnen gebruiken.

Gedistribueerde NBAR (DNBAR) is beschikbaar op de volgende platforms:

platform

Minimale Cisco IOS-softwarerelease

7500

12.2(4)T, 12.1(6)E

FlexWAN

12.1(6)E

Opmerking: NBAR wordt niet ondersteund op Catalyst 6000 VLAN-interfaces (MSFC) voor meerlaagse Switch, Cisco 12000 Series of RSM-Switch (Routemodule) voor Catalyst 5000 Series. Als u geen specifiek platform ziet dat hierboven is vermeld, kunt u contact opnemen met uw technische vertegenwoordiger van Cisco.

Wachtrijen- en congestiebeheer

V. Wat is het doel van wachtrijen?

A. Queueing is ontworpen om tijdelijke files op de interface van een netwerkapparaat op te slaan door overtollige pakketten in buffers op te slaan tot de bandbreedte beschikbaar wordt. Cisco IOS-routers ondersteunen verschillende wachtrijen-methoden om te voldoen aan de variërende bandbreedte-, startvertraging- en vertragingsvereisten voor verschillende toepassingen.

Het standaardmechanisme op de meeste interfaces is First In First Out (FIFO). Sommige verkeerstypen hebben strengere eisen voor vertraging/jitter. Aldus zou een van de volgende alternatieve wachtrijen mechanismen moeten worden geconfigureerd of door standaard ingeschakeld:

- Weighted Fair Queueing (WFQ)

- Op klasse gebaseerde Weighted Fair Queueing (CBWFQ)

- Low Latency Queueing (LLQ), dat in feite CBWFQ is met een prioriteitenwachtrij (PQ) (bekend als PQCBWFQ)

- Prioritaire wachtrij

- Aangepaste wachtrij (CQ)

Een wachtrij wordt meestal alleen op uitgaande interfaces uitgevoerd. Een router vormt een wachtrij voor pakketten die naar een interface worden verzonden. U kunt inkomend verkeer controleren, maar u kunt gewoonlijk niet in de rij zitten (een uitzondering is aan de ontvangstzijde buffering op een Cisco 7500 Series router die gedistribueerd Cisco Express Forwarding (dCEF) gebruikt om pakketten van de ingang naar de spanning door te sturen; raadpleeg voor meer informatie het begrip van VIP CPU’s die actief zijn op 99% en Rx-Side Buffering. Op hoog-eind gedistribueerde platforms zoals Cisco 7500 en 12000 Series, kan de inkomende interface zijn eigen pakketbuffers gebruiken om overtollig verkeer op te slaan dat naar een verstopt uitgaande interface wordt overgeschakeld na de overstapbeslissing van de inkomende interface. In zeldzame omstandigheden, typisch wanneer de inkomende interface een langzamere uitgaande interface voedt, kan de inkomende interface het verhogen van genegeerde fouten ervaren wanneer het pakketgeheugen op is. Overmatige congestie kan leiden tot een daling van de wachtrij. Invoervoorraaddalingen hebben meestal een andere oorzaak. Raadpleeg voor meer informatie over het opsporen en verhelpen van fouten het volgende document:

- Stapels voor probleemoplossing in invoerwachtrij en uitloop

Raadpleeg voor meer informatie de volgende documenten:

- Problemen oplossen "genegeerd" fouten op een ATM-poortadapter

- Probleemoplossing genegeerd fouten en geen geheugen daalt op Cisco 12000 Series Internet-router

Q. Hoe werken Weighted Fair Queueing (WFQ) en Class Based Weighted Fair Queueing (CBWFQ)?

A. Fair wachtrij probeert een eerlijk deel van de bandbreedte van een interface toe te wijzen aan actieve gesprekken of IP-stromen. Ze classificeert pakketten in subwachtrijen, geïdentificeerd door een conversatie-identificatienummer, met behulp van een hashing-algoritme op basis van meerdere velden van de IP-header en de lengte van het pakket. Zo wordt het gewicht berekend:

- W=K/(voorrang +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 gedeelte van de bandbreedte. Naast het gewicht wordt ook rekening gehouden met de lengte van de verpakking.

CBWFQ staat u toe om een klasse van verkeer te definiëren en het een minimum bandbreedtegarantie toe te wijzen. Het algoritme achter dit mechanisme is WFQ, dat de naam verklaart. Om CBWFQ te configureren definieert u specifieke klassen in map-klasse verklaringen. Dan geef je een beleid aan elke klasse toe in een beleids-kaart. Deze beleidskaart zal dan aan een interface worden gehecht. Raadpleeg voor meer informatie de volgende documenten:

- De betekenis van op klasse gebaseerde Weighted Fair Queuing op ATM

- De betekenis van Weighted Fair Queuing op ATM

Q. Als een klasse in Class Based Weighted Fair Queueing (CBWFQ) zijn bandbreedte niet gebruikt, kunnen andere klassen de bandbreedte gebruiken?

A. Ja. Hoewel de bandbreedtegaranties door het uitgeven van de bandbreedte en prioritaire opdrachten met woorden als "gereserveerd" en "te zetten bandbreedte" zijn beschreven, voert geen van beide opdracht een ware reservering uit. Betekenis, als een verkeersklasse zijn geconfigureerde bandbreedte niet gebruikt, wordt elke ongebruikte bandbreedte onder de andere klassen gedeeld.

Het systeem voor wachtrijen legt een belangrijke uitzondering op deze regel met een prioriteitsklasse. Zoals hierboven vermeld, wordt de aangeboden lading van een prioriteitsklasse gemeten door een verkeersagent. Tijdens congestieomstandigheden kan een prioriteitsklasse geen overtollige bandbreedte gebruiken. Raadpleeg voor meer informatie Vergelijking van de bandbreedte en de prioriteitsopdrachten van een QoS-servicebeleid.

Q. wordt op klasse gebaseerde Weighted Fair Queueing (CBWFQ) ondersteund op subinterfaces?

A. Cisco IOS logische interfaces ondersteunen inherent geen staat van congestie en ondersteunen geen rechtstreekse toepassing van een servicebeleid dat een wachtmethode toepast. In plaats daarvan moet u eerst de vormgeving in de subinterface toepassen met behulp van ofwel de Generic Traffic Shaping (GTS) of de class-Based Shaping. Raadpleeg voor meer informatie de toepassing van QoS-functies op Ethernet-subinterfaces.

Q. Wat is het verschil tussen de prioriteit en bandbreedte in een beleidskaart?

A. De opdrachten prioriteit en bandbreedte verschillen in beide functies en in welke toepassingen ze doorgaans ondersteunen. In de volgende tabel worden deze verschillen samengevat:

Functie

opdracht voor bandbreedte

prioriteitsopdracht

Minimale bandbreedte-garantie

Ja

Ja

Maximale bandbreedte-garantie

Nee

Ja

Ingebouwde politieagent

Nee

Ja

levert lage latentie

Nee

Ja

Raadpleeg voor meer informatie Vergelijking van de bandbreedte en de prioriteitsopdrachten van een QoS-servicebeleid.

Q. Hoe wordt de wachtrijlimiet berekend op de FlexWAN en VIP (VIP) veelzijdige interfaceprocessors?

A. aangenomen dat voldoende RAM op VIP of FlexWAN beschikbaar is, wordt de wachtrijlimiet berekend op basis van een maximale vertraging van 500ms met een gemiddelde pakketgrootte van 250 bytes. Het volgende is een voorbeeld van een klasse met één Mbps van bandbreedte:

Wachtrijlimiet = 1000000 / (250 x 8 x 2) = 250

Kleinere rijbeperkingen worden toegewezen als de hoeveelheid beschikbare pakketgeheugen vermindert en met een groter aantal Virtual Circuits (VCS).

In het volgende voorbeeld, wordt een PA-A3 geïnstalleerd in een FlexWAN-kaart voor Cisco 7600 Series en ondersteunt meerdere subinterfaces met 2 MB Permanent Virtual Circuits (PVC’s). Het servicebeleid wordt op elke VC toegepast.

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-2048Kbps

De Asynchronous Transfer Mode (ATM) interface krijgt een wachtrijlimiet voor de gehele interface. De grenswaarde is een functie van de totale beschikbare buffers, het aantal fysieke interfaces op FlexWAN, en de maximum vertraging van de wachtrij die op de interface is toegestaan. Elk PVC krijgt een deel van de interfacelimiet op basis van de Aanhoudende Cell Rate (solvabiliteitsclassificatie) van het PVC of de Minimale Cell Rate (MCR) en elke klasse krijgt een deel van de PVC-limiet op basis van de bandbreedtetoewijzing.

De volgende voorbeeldoutput van de show policy-map interface opdracht wordt afgeleid van een FlexWAN met 3687 mondiale buffers. Geef de opdracht showbuffer op om deze waarde te zien. Elke twee Mbps PVC wordt toegewezen 50 pakketten gebaseerd op de bandbreedte van PVC van twee Mbps (2047/149760 x 3687 = 50). Aan elke klasse wordt dan een deel van de 50 toegewezen, zoals in de volgende output wordt getoond:

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 0

Als uw verkeersstromen grote pakketformaten gebruiken, kan de show beleid-map interface opdracht uitvoer een stijgende waarde voor de geen buffer veld laten vallen omdat u geen buffers meer kunt hebben voordat u de wachtrijlimiet bereikt. In dit geval, probeer handmatig de wachtrijlimiet in niet-prioriteitsklassen in te stellen. Raadpleeg voor meer informatie het begrip van de limiet van de verzendwachtrij voor IP naar ATM CoS.

Q. Hoe verifieert u de wachtrijgrenswaarde?

A. Op niet-gedistribueerde platforms is de wachtrijlimiet standaard 64 pakketten. De volgende voorbeelduitvoer werd opgenomen 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

Kan ik eerlijke wachtrijen in een klas mogelijk maken?

A. Cisco 7500 Series met Distributed Quality of Service (QoS) ondersteunt eerlijke wachtrij per klasse. Andere platforms, waaronder Cisco 7200 Series en Cisco 2600/3600 Series, ondersteunen Weighted Fair Queueing (WFQ) in de klasse-default klasse; Alle bandbreedteklassen gebruiken First In First Out (FIFO).

Q. Welke opdrachten kan ik gebruiken om wachtrijen te bewaken?

A. Gebruik de volgende opdrachten om de wachtrij te bewaken:

- tonen rij {interface} {interfacenummer} - Op Cisco IOS platforms anders dan de Cisco 7500 Series, toont deze opdracht de actieve rijen of gesprekken. Als de interface of Virtual Circuit (VC) niet is geblokkeerd, worden er geen wachtrijen weergegeven. Op Cisco 7500 Series wordt de opdracht tonen wachtrij niet ondersteund.

- Toon een wachtrij interface-nummer [vc [[vpi/] vci] - Dit geeft de wachtrijen statistieken van een interface of een VC weer. Zelfs als er geen opstoppingen zijn, kan je hier nog wat hits zien. De reden hiervoor is dat procesgeschakelde pakketten altijd worden geteld ongeacht de opstopping aanwezig is. Cisco Express Forwarding (CEF) en Fast-Switched pakketten worden niet geteld tenzij er sprake is van stremmingen. De 'legacy wachtrij'-mechanismen als Priority Queueing (PQ), Custom Queueing (CQ) en Weighted Fair Queueing (WFQ) zullen geen classificatiestatistieken opleveren. Deze statistieken worden alleen verstrekt door middel van modulaire MQC-gebaseerde functies (Quality of Service Interface) in afbeeldingen later dan 12.0(5)T.

- toon beleidsinterface {interface} {interfacenummer} - De pakketten tellen het aantal pakketten die de criteria van de klasse aanpassen. Deze tegenstappen, ongeacht of de interface verstopt is. De overeenkomende teller geeft het aantal pakketten aan dat overeenkomt met de criteria van de klasse toen de interface werd geblokkeerd. Raadpleeg voor meer informatie over pakkettellers het volgende document:

De betekenis van pakkettellers in tonen beleid-kaart interface uitvoer

- Cisco Class-Based QoS Configuration en Statistiek MIB - biedt eenvoudige netwerkbeheerfuncties (SNMP).

Q. RSVP kan worden gebruikt in combinatie met Op klasse gebaseerde Weighted Fair Queueing (CBWFQ). Wanneer zowel Resource Reservation Protocol (RSVP) als CBWFQ voor een interface worden geconfigureerd, werken RSVP en CBWFQ onafhankelijk en tonen ze hetzelfde gedrag dat ze zouden hebben als ze allemaal in hun eentje zouden lopen? RSVP lijkt zich te gedragen alsof CBWFQ niet is geconfigureerd met betrekking tot beschikbaarheid, evaluatie en toewijzing van bandbreedte.

A. Wanneer u RSVP en CB-WFQ in Cisco IOS-softwarerelease 12.1(5)T en later gebruikt, kan de router zo functioneren dat RSVP-stromen en CBWFQ-klassen de beschikbare bandbreedte op een interface of PVC delen, zonder overabonnement.

IOS-softwarerelease 12.2(1)T en hoger stelt RSVP in staat toegangscontrole te verrichten met behulp van zijn eigen "IP RSVP-bandbreedte"-pool, terwijl CBWFQ classificatie, toezicht en planning van RSVP-pakketten uitvoert. Dit veronderstelt vooraf gemarkeerde pakketten door de afzender, en dat de niet-RSVP pakketten verschillend worden gemerkt.

Vermijding van congestievermijding door gewogen willekeurige vroege detectie (WRED)

Q. Kan ik tegelijkertijd Weighted Random Early Detection (WRED) en Low Latency Queueing (LLQ) of op klasse gebaseerde Weighted Fair Queueing (CBWFQ) inschakelen?

A. Ja. Een wachtrij vormt de volgorde van pakketten die een wachtrij verlaten. Dit betekent dat het een pakketplanningsmechanisme definieert. Het kan ook worden gebruikt om eerlijke bandbreedte-toewijzing en minimale bandbreedte-garanties te bieden. In tegenstelling daarmee definieert Aanvraag voor Comments (RFC) 2475 uitdrukking als het "proces van het teruggooien van pakketten op basis van gespecificeerde regels." Het standaard uitrolmechanisme is staartdruppels, waarin de interface pakketten laat vallen wanneer de rij vol is. Een alternatief druppelmechanisme is Random Early Detection (RED) en Cisco WRED, dat pakketten willekeurig begint te vallen voordat de wachtrij vol is en probeert een consistente gemiddelde rijdiepte te behouden. WRED gebruikt de IP-prioriteitswaarde van pakketten om een gedifferentieerd droogebesluit te nemen. Raadpleeg voor meer informatie Weighted Random Early Detection (WRED).

Vraag. Hoe kan ik Weighted Random Early Detection (WRED) controleren en zien hoe deze daadwerkelijk van kracht wordt?

A. WRED controleert de gemiddelde wachtrijdiepte en begint pakketten te drogen wanneer de berekende waarde boven de minimumwaarde gaat. Geef de show policy-map interface opdracht uit en controleer de gemiddelde wachtrijdieptewaarde, zoals in het volgende voorbeeld wordt getoond:

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]

Toezicht en traffic shaping

Wat is het verschil tussen politie en vormgeving?

A. Het volgende schema illustreert het belangrijkste verschil. Traffic Shaping behoudt te veel pakketten in een rij en plant dan de overmaat voor latere transmissie over stappen van tijd. Het resultaat van traffic shaping is een vloeiend pakketuitvoeringspercentage. In contrast hiermee propageert de verkeerspolitie. Wanneer het verkeerstarief de geconfigureerde maximumsnelheid bereikt, wordt het overtollige verkeer verlaagd of aangegeven. Het resultaat is een uitvoersnelheid die als een zaagtand met kreuken en nokken weergegeven wordt.

Zie Toezicht en vormgeving Overzicht voor meer informatie.

Q. Wat is een symbolische emmer en hoe werkt het algoritme?

A. Een emmer zelf heeft geen teruggooi- of prioriteitsbeleid. Hieronder volgt een voorbeeld van hoe de symbolische emmer-metafoor werkt:

- Tokens worden tegen een bepaalde snelheid in de emmer gestopt.

- Elke token is een toestemming voor de bron om een bepaald aantal bits te verzenden.

- Als u een pakket wilt verzenden, moet de verkeersregelaar in staat zijn om een aantal penningen van de emmer te verwijderen, die gelijk zijn aan de grootte van het pakket.

- Als er niet genoeg penningen in de emmer zijn om een pakje te verzenden, wacht de pakje of op totdat de emmer voldoende penningen heeft (in het geval van een vormgever) of wanneer het pakje is weggegooid of af is gemarkeerd (in het geval van een politieagent).

- De emmer heeft zelf een bepaalde capaciteit. Als de emmer gevuld is met capaciteit, worden nieuw aangekomen penningen weggegooid en zijn ze niet beschikbaar voor toekomstige pakketten. Op elk moment is de grootste uitbarsting die een bron in het netwerk kan sturen ruwweg evenredig met de omvang van de emmer. Een symbolische emmer maakt burstentie mogelijk, maar verdeelt het.

Q. Met een verkeersagent zoals klassencontrole, wat betekenen de Committed Burst (BC) en de Excess Burst (BE) en hoe moet ik deze waarden selecteren?

A. Een verkeersagent buffert niet overtollige pakketten en zendt deze later, zoals het geval is voor een vormer. In plaats daarvan zorgt de politie voor een simpel sturen of sturen ze geen beleid zonder te bufferen. Tijdens perioden van stremmingen, omdat u geen buffer kunt vormen, kunt u beter pakketten minder agressief laten vallen door uitgebreide barsten correct te configureren. Daarom is het belangrijk om te begrijpen dat de politieagent de normale uitbarsting en de uitgebreide uitbarstwaarden gebruikt om ervoor te zorgen dat het geconfigureerde Committed Information Rate (CIR) wordt bereikt.

De barstparameters worden losjes gemodelleerd naar de generieke bufferregel voor routers. De regel adviseert het bufferen gelijk aan de ronde-trip tijd bitrate om de openstaande vensters van het Transmission Control Protocol (TCP) van alle verbindingen in tijden van congestie aan te passen.

In de volgende tabel worden het doel en de aanbevolen formule beschreven voor de normale en uitgebreide barstwaarden:

Burst-parameter

doel

Aanbevolen formule

normale breuk

- Voert een standaard emmer uit.

- Hiermee wordt de maximale grootte van de penningmeester ingesteld (hoewel penningen kunnen worden geleend als Be groter is dan BC).

- Bepaalt hoe groot de penningen kunnen zijn omdat nieuwe aankomende penningen worden weggegooid en niet beschikbaar zijn voor toekomstige pakketten als de emmer gevuld is met capaciteit.

CIR [BPS] *

(1 byte)/(8 bits) *

1.5 seconds

Opmerking: 1,5 seconden is de gemiddelde retourtijd.

uitbarsting

- implementeert een emmer met uitgebreide barstcapaciteit.

- Uitgeschakeld door BC = Be.

- Als BC gelijk is aan Be, kan de verkeersregelaar geen penningen lenen en druppelt het pakket eenvoudigweg af als er onvoldoende penningen beschikbaar zijn.

2 * normal burst

Niet alle platforms gebruiken of ondersteunen hetzelfde waardenbereik voor een politieagent. Raadpleeg het volgende document voor informatie over de ondersteunde waarden voor uw specifieke platform:

- Overzicht van toezicht en traffic shaping

Q. Hoe beslist Committed Access Rate (CAR) of op klasse gebaseerde controle of een pakket voldoet of groter is dan het Committed Information Rate (CIR)? De router laat pakketten vallen en rapporteert een overschreden tarief zelfs alhoewel het conformeerde tarief minder dan de gevormd CIR is.

A. Een verkeersagent gebruikt de normale barsten en de uitgebreide barstwaarden om er zeker van te zijn dat de geconfigureerde CIR is bereikt. Het instellen van voldoende hoge barstwaarden is belangrijk om een goede doorvoersnelheid te garanderen. Als de barstwaarden te laag zijn ingesteld, kan de bereikte snelheid veel lager zijn dan de ingestelde snelheid. Het straffen van tijdelijke uitbarstingen kan een sterke nadelige invloed hebben op de doorvoersnelheid van TCP-verkeer (Transmission Control Protocol). Met CAR geeft u de opdracht voor de showinterface rate-limit op om de huidige uitbarsting te bewaken en te bepalen of de weergegeven waarde consistent dicht bij de grenswaarde (BC) en de uitgebreide 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 BPS

Raadpleeg voor meer informatie de volgende documenten:

- Overzicht van toezicht en traffic shaping

- QoS-toezicht op Catalyst 6000

- Quality-of-Service op Catalyst 4000 vaak gestelde vragen

- Catalyst G-L3 Series Switches en WS-X4232-L3 Layer 3 modules voor QoS FAQ

V. Zijn de barsten en de rij onafhankelijk van elkaar?

A. Ja, politieagenten staan in de rij en staan los van elkaar. U kunt de politieagent als een poort zien waar een bepaald aantal pakketten (of bytes) en de rij als een emmer van de rijgrens van de grootte wordt toegestaan die de ingevoerde pakketten vóór overdracht op het netwerk bevat. Idealiter moet uw emmer groot genoeg zijn om een barst van bytes/pakketten vast te houden die door de poort (politieagent) zijn opgenomen.

QoS-Frame Relay (Quality of Service)

Q. Welke waarden moet ik selecteren voor Committed Information Rate (CIR), Committed Burst (BC), Excess Burst (BE) en Minimale CIR (MinCIR)?

A. Frame Relay Traffic Shaping, die u mogelijk maakt door de frame-relais traffic-shaping-opdracht uit te geven, ondersteunt verschillende configureerbare parameters. Deze parameters omvatten frame-relais cir, frame-relais mincir en frame-relais BC. Raadpleeg de volgende documenten voor meer informatie over het selecteren van deze waarden en het begrijpen van verwante tonen opdrachten:

- Frame Relay Traffic Shaping configureren op 7200 routers en lagere platforms

- Opdrachten voor Frame Relay Traffic Shaping tonen

- VoIP via Frame Relay met Quality-of-Service (Fragmentation, Traffic Shaping, IP RTP-prioriteit)

Q. Werkt prioriteitswachtrij voor Frame Relay hoofdinterface in Cisco IOS 12.1?

A. Frame Relay-interfaces ondersteunen zowel interface-wachtmechanismen als per-Virtual Circuit (VC)-wachtmechanismen. Vanaf Cisco IOS 12.0(4)T ondersteunt de interfacestrijd First In First Out (FIFO) of Per Interface Priority Queueing (PIPQ) alleen wanneer u Frame Relay Traffic Shaping (FRTS) vormt. Daarom werkt de volgende configuratie niet langer als u uw upgrade naar Cisco IOS 12.1 uitvoert.

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 IETF

Als FRTS niet is ingeschakeld, kunt u een alternatieve wachtrijmethode, zoals Class Based Weighted Fair Queueing (CBWFQ), op de hoofdinterface toepassen, die op één bandbreedtebuis werkt. Daarnaast kunt u Cisco IOS 12.1.1(T) u Frame Relay Permanent Virtual Circuits (PVC) prioriteitsinterfacewachtrij (PIPQ) op een Frame Relay-hoofdinterface inschakelen. U kunt hoge, gemiddelde, normale, of lage prioriteit PVC's definiëren en het frame-relais prioriteitsopdracht op de hoofdinterface geven, 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

Q. Werkt Frame Relay Traffic Shaping (FRTS) met gedistribueerd Cisco Express Forwarding (dCEF) en Distributed Class Based Weighted Fair Queueing (dCBWFQ)?

A. Vanaf Cisco IOS 12.1(5)T wordt alleen de gedistribueerde versie van QoS-functies ondersteund op VIP’s in Cisco 7500 Series. Gebruik Distributed Traffic Shaping (DTS) om traffic shaping op Frame Relay-interfaces mogelijk te maken. Raadpleeg voor meer informatie de volgende documenten:

- Veelzijdige interfaceprocessor-gebaseerde gedistribueerde FRF.11 en FRF.12 voor Cisco IOS release 12.1 T

- Frame Relay Traffic Shaping met gedistribueerde QoS op Cisco 7500 Series

Quality-of-Service (QoS) via Asynchronous Transfer Mode (ATM)

Q. Waar toepas ik een servicebeleid met Class Based Weighted Fair Queueing (CBWFQ) en Low Latency Queueing (LLQ) op een ATM-interface (Asynchronous Transfer Mode)?

A. Vanaf Cisco IOS 12.2 ondersteunen ATM-interfaces servicebeleid op drie niveaus of logische interfaces: hoofdinterface, subinterface en Permanent Virtual Circuit (PVC). Waar u het beleid toepast is een functie van de QoS-functie (Quality of Service) die u toestaat. Een wachtrij-beleid moet per Virtual Circuit (VC) worden toegepast omdat de ATM-interface het congestieniveau per VC controleert en wachtrijen voor overtollige pakketten per VC onderhoudt. Raadpleeg voor meer informatie de volgende documenten:

- Waar kan ik een QoS-servicebeleid op een ATM-interface toepassen?

- De betekenis van de Per-VC transmissiekaart op de PA-A3 en NM-1A ATM-interfaces

Q. Welke bytes worden door IP naar Asynchronous Transfer Mode (ATM) wachtrij van serviceklasse (CO’s) geteld?

A. De bandbreedte en prioriteitsopdrachten die in een servicebeleid zijn geconfigureerd om op klasse gebaseerde weging in de wachtrij (CBWFQ) en een lage wachtrij voor latentie (LLQ) mogelijk te maken, gebruiken respectievelijk een Kbps-waarde die dezelfde overhead-bytes telt als die worden geteld door de uitvoer van de showinterface-opdracht. Met name telt het Layer 3-systeem voor wachtrij Logical Link Control/Subnetwork Access Protocol (LLC/SNAP). Het telt niet:

- ATM Adapter Layer 5 (AAL5) trailer

- Toevoegen om van de laatste cel een zelfs veelvoud van 48 bytes te maken

- Vijf byte-celheader

- Welke bytes worden door IP naar ATM CO’s-wachtrij geteld?

V. Hoeveel Virtual Circuits (VCS) kunnen een servicebeleid tegelijkertijd ondersteunen?

A. Het volgende document biedt nuttige richtlijnen voor het aantal ATM-VCS (Asynchronous Transfer Mode) dat kan ondersteunen. Er zijn ongeveer 200 tot 300 VBR-NR Permanent Virtual Circuits (PVC’s) op veilige wijze gebruikt:

- Ontwerpgids voor IP-naar-ATM serviceklasse

Overweeg ook het volgende:

- Gebruik een krachtige processor. Een VIP4-80 biedt bijvoorbeeld aanzienlijk hogere prestaties dan een VIP2-50.

- hoeveelheid beschikbaar pakketgeheugen. Op de NPE-400 wordt 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 tegelijkertijd op maximaal 200 ATM PVC’s werken, zijn uitgebreid getest. De hoeveelheid pakketgeheugen op VIP2-50 dat kan worden gebruikt voor de wachtrijen per-VC is eindig. Een VIP2-50 met 8-MB RAM biedt bijvoorbeeld 1085 pakketbuffers beschikbaar voor IP naar ATM CO’s per-VC wachtrij waarop WRED werkt. Als 100 ATM PVC’s waren geconfigureerd en als alle VCS gelijktijdig te kampen hadden met overmatige congestie (wat kon worden gesimuleerd in testomgevingen waar een niet-TCP-flow gecontroleerde bron zou worden gebruikt), dan zou elke PVC gemiddeld ongeveer 10 pakketten met buffering hebben, wat te kort kan zijn om succesvol te kunnen functioneren. VIP2-50-apparaten met groot SRAM worden dus sterk aanbevolen in ontwerpen met een hoog aantal ATM PVC’s per-VC WRED en die gelijktijdig een stremming kunnen ervaren.

- Hoe hoger het aantal geconfigureerde actieve PVC’s, hoe lager hun vaste Cell Rate (solvabiliteitskapitaalvereiste) moet zijn, en hoe korter de wachtrij die WRED nodig heeft om op het PVC te kunnen werken. Zoals het geval is bij gebruik van de standaard-WRED-profielen van de IP-naar-ATM serviceklasse (CO’s), fase 1-functie, zou het configureren van lagere WRED-drempels wanneer per-VC WRED wordt geactiveerd op een zeer groot aantal IP-naar-ATM PVC’s met lage snelheid het risico op een buffertekort op de VIP tot een minimum beperken. Buffertekort op de VIP resulteert niet in een storing. In het geval van een buffertekort op de VIP, wordt de functie IP naar ATM CO’s fase 1 gewoon afgebroken tot First In First Out (FIFO)-staart tijdens de periode van het buffertekort (dat wil zeggen hetzelfde uitvalbeleid dat zou optreden als de functie IP naar ATM CO’s niet op dit PVC werd geactiveerd).

- Maximaal aantal gelijktijdige VCS dat redelijkerwijs kan worden ondersteund.

Q. Welke ATM-hardware (Asynchronous Transfer Mode) ondersteunt IP naar ATM-serviceklasse (CO’s), inclusief op klasse gebaseerde Weighted Fair Queueing (CBWFQ) en Low Latency Queueing (LLQ)?

A. IP naar ATM CO’s verwijst naar een reeks functies die zijn ingeschakeld op een per-Virtual Circuit (VC)-basis. Gezien deze definitie wordt IP naar ATM CO’s niet ondersteund op de ATM-netwerkprocessors (AIP), PA-A1 of 4500 ATM-netwerkprocessors. Deze ATM-hardware biedt geen ondersteuning voor een wachtrij per-VC, aangezien de PA-A3 en de meeste netwerkmodules (anders dan de ATM-25) deze definiëren. Raadpleeg voor meer informatie het volgende document:

- Meer begrip voor ATM-hardwareondersteuning voor IP naar ATM CO’s

- Op klasse 1-VC gebaseerde, gewogen wachtrij op RSP-gebaseerde platforms

- Op klasse gebaseerde, Weighted Fair Queuing (Per-VC CBWFQ) op Cisco 7200, 3600 en 2600 routers

- Per-VC wachtrij voor de PA-A3-8T1/E1 IMA ATM-poortadapter

- ATM per-VC wachtrij configureren op MC3810

Voice en Quality of Service (QoS)

Q. Hoe werkt Link Fragmentation and Interleaving (LFI)?

A. Interactief verkeer zoals Telnet en Voice-over-IP is vatbaar voor verhoogde vertraging wanneer het netwerk grote pakketten verwerkt zoals File Transfer Protocol (FTP) overschrijvingen via een WAN. De vertraging van pakketten voor interactief verkeer is belangrijk wanneer de FTP-pakketten in de wachtrij worden geplaatst voor langzamere WAN-links. Er is een methode ontworpen om grotere pakketten te fragmenteren en de kleinere (spraak) pakketten tussen de fragmenten van de grotere pakketten (FTP) in de wachtrij te plaatsen. Cisco IOS-routers ondersteunen verschillende Layer 2-fragmentatiemechanismen. Raadpleeg voor meer informatie de volgende documenten:

- Overzicht van mechanismen voor koppelingsefficiëntie

- VoIP via Frame Relay met Quality-of-Service (Fragmentation, Traffic Shaping, IP RTP-prioriteit)

- VoIP over PPP Links met Quality of Service (LLQ/IP RTP-prioriteit, LFI, cRTP)

Q. Welke tools kan ik gebruiken om Voice over IP te controleren?

A. Cisco biedt momenteel verschillende opties voor controle Quality of Service (QoS) in netwerken met behulp van Cisco Voice-over-IP oplossingen. Deze oplossingen meten de spraakkwaliteit niet met behulp van een Perceptual Speech Quality Measurement (PSQM) of een aantal van de nieuwe voorgestelde algoritmen voor de meting van de spraakkwaliteit. Gereedschappen van Agent (HP) en NetIQ zijn voor dit doel beschikbaar. Maar Cisco biedt wel gereedschappen die een idee geven van de spraakkwaliteit die u ervaart door vertraging, scherp en pakketverlies te meten. Raadpleeg voor meer informatie Cisco Service Assurance Agent en Internetwork Performance Monitor gebruiken om Quality-of-Service in Voice-over-IP netwerken te beheren.

Vraag %SW_MGR-3-CM_FOUR_FEATURE_CLASS: Functiefout Connection Manager: Klasse SSS: (QoS) - installeer een fout, negeer.

A. De fout die is waargenomen tijdens het installeren van de functie is een verwacht gedrag wanneer een ongeldige configuratie is toegepast op een sjabloon. Het geeft aan dat het dienstenbeleid niet werd toegepast wegens een conflict. In het algemeen, zou u het vormen op klasse-gebrek van het kindbeleid in hiërarchische beleidskaarten niet moeten vormen, in plaats daarvan moet het op het ouderbeleid van de interface vormen. Dit bericht en de traceerbaarheid worden als gevolg daarvan afgedrukt.

Bij sessiegebaseerd beleid moet het vormgeven op class-default alleen op subinterface- of PVC-niveau worden uitgevoerd. Shaping op de fysieke interface wordt niet ondersteund. Als de configuratie uitgevoerd wordt op de fysieke interface, is het optreden van deze foutmelding een verwacht gedrag.

In het geval van LNS zou een andere reden kunnen zijn dat het servicebeleid voorzien zou kunnen worden via de straal server wanneer de sessies omhoog worden gebracht. Geef de show tech opdracht uit om de configuratie van de Straalserver te bekijken en om elk illegaal dienstenbeleid te bekijken dat via de Straalserver geïnstalleerd is wanneer de sessie of de flaps naar voren komt.

Gerelateerde informatie

- Toetsing van prestaties

- QoS-ondersteuning (Quality of Service)

- Technische ondersteuning en documentatie – Cisco Systems