Veelgestelde vragen over QoS
Inhoud
Inleiding
In dit document worden veelgestelde vragen over Quality of Service (QoS) beantwoord.
Algemeen
Q. Wat is Quality of Service (QoS)?
A. QoS verwijst naar de mogelijkheid van een netwerk om betere service te bieden aan geselecteerd netwerkverkeer via verschillende onderliggende technologieën zoals 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), latentievariaties (jitter) en vertragingen. QoS-functies bieden met name een betere en meer voorspelbare netwerkservice via de volgende methoden:
Ondersteuning van toegewezen bandbreedte.
Verbetering van de verlieskenmerken.
Netwerkcongestie voorkomen en beheren.
Vormend netwerkverkeer.
Verkeersprioriteiten instellen op het netwerk.
De Internet Engineering Task Force (IETF) definieert de volgende twee architecturen voor QoS:
Geïntegreerde services (Intelv)
Gedifferentieerde services (DiffServ)
IntServ gebruikt het Resource Reservation Protocol (RSVP) om expliciet aan te geven wat de QoS-behoeften zijn van het verkeer van een toepassing langs de apparaten in het end-to-end pad door het netwerk. Als elk netwerkapparaat langs het pad de benodigde bandbreedte kan reserveren, kan de oorspronkelijke toepassing beginnen met verzenden. RSVP wordt gedefinieerd door de optie Verzoek om opmerkingen (RFC) 2205 en in RFC 1633 wordt IntServ gedefinieerd.
DiffServ richt zich op geaggregeerde en voorziene QoS. In plaats van de QoS-vereisten van een toepassing te signaleren, gebruikt DiffServ een DiffServ-codepunt (DSCP) in de IP-header om de vereiste QoS-niveaus aan te geven. Cisco IOS®-softwarerelease 12.1(5)T introduceerde DiffServ-naleving op Cisco-routers. Raadpleeg de volgende documenten voor meer informatie:
V. Wat zijn congestie, vertraging en jitter?
A. Een interface ervaart congestie wanneer het met meer verkeer wordt voorgesteld dan het kan behandelen. Netwerkcongestiepunten zijn sterke kandidaten voor QoS-mechanismen (Quality of Service). Het volgende is een voorbeeld van typische congestiepunten:
Netwerkcongestie leidt tot vertraging. Een netwerk en zijn apparaten introduceren verscheidene soorten vertragingen, zoals verklaard in het Begrijpen van Vertraging in de Netwerken van de Packet Voice. Variatie in vertraging is bekend als jitter, zoals wordt uitgelegd in Begrip van Jitter in Packet Voice Networks (Cisco IOS-platforms). Zowel vertraging als jitter moeten worden gecontroleerd en geminimaliseerd om real-time en interactief verkeer te ondersteunen.
V. Wat is de MQC?
A. MQC staat voor modulaire 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 een resulterende set QoS-gedrag via platforms 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 bevat de volgende drie stappen:
Definieer een verkeersklasse door de opdracht class-map uit te geven.
Maak een verkeersbeleid door de verkeersklasse te koppelen aan een of meer QoS-functies door de opdracht policy-map uit te geven.
Hang het verkeersbeleid aan de interface, subinterface of Virtual Circuit (VC) door de opdracht Service-Policy uit te geven.
Opmerking: U implementeert de verkeersconditioneringsfuncties van DiffServ, zoals markeren en vormgeven, met behulp van de MQC syntaxis.
Raadpleeg voor meer informatie de modulaire opdrachtregelinterface voor Quality-of-Service.
V. Wat wordt het servicebeleid alleen ondersteund op VIP-interfaces met DCEF-berichten?
A. Op veelzijdige interfaceprocessors (VIP’s) in een Cisco 7500 Series 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. Als u gedistribueerd Cisco Express Forwarding (dCEF) inschakelt, wordt automatisch gedistribueerde QoS ingeschakeld.
Niet-VIP interfaces, bekend als legacy Interface Processors (IPs), ondersteunen centrale QoS-functies zoals ingeschakeld op de Route Switch Processor (RSP). Raadpleeg de volgende documenten voor meer informatie:
V. Hoeveel klassen ondersteunt een QoS-beleid (Quality of Service)?
A. In Cisco IOS-versies eerder dan 12.2 kunt u slechts 256 klassen definiëren en binnen elk beleid maximaal 256 klassen definiëren als dezelfde klassen opnieuw worden gebruikt voor ander beleid. Als je twee polissen hebt, mag het totale aantal klassen van beide polissen niet hoger zijn dan 256. Als een beleid op klasse gebaseerde Weighted Fair Queueing (CBWFQ) bevat (wat betekent dat het een bandbreedte [of prioriteit] statement bevat binnen een van de klassen), is het totale aantal ondersteunde klassen 64.
In Cisco IOS-versies 12.2(12)S, 12.2(12)T en 12.2(12)S is deze beperking van 256 globale class-maps gewijzigd en is het nu mogelijk om tot 1024 globale class-maps te configureren en 256 class-maps te gebruiken binnen dezelfde policy-map.
Q. Hoe worden routingupdates en Point-to-Point Protocol (PPP)/High-Level Data Link Control (HDLC) nog verwerkt wanneer een servicebeleid wordt toegepast?
A. Cisco IOS-routers gebruiken de volgende twee mechanismen om prioriteit toe te kennen aan controlepakketten:
IP-voorrang
pak_prioriteit
Beide mechanismen worden ontworpen om ervoor te zorgen dat de zeer belangrijke controlepakketten niet worden gelaten vallen of laatste door de router en het het een rij vormen systeem worden gelaten vallen wanneer een uitgaande interface verstopt is. Raadpleeg voor meer informatie Begrijpen hoe routing-updates en controlepakketten op een interface met een QoS-servicebeleid worden wachtrijen.
Q. Wordt Quality of Service (QoS) ondersteund op interfaces die met geïntegreerde routing en bridging (IRB) zijn geconfigureerd?
A. Nee. U kunt QoS-functies niet configureren wanneer de interface voor IRB is geconfigureerd.
Classificatie en markering
Q. Wat is de pre-classificatie Kwaliteit van de Dienst (QoS)?
A. Met QoS-voorclassificatie kunt u de oorspronkelijke IP-headerinhoud van pakketten die tunnelinsluiting en/of -codering ondergaan, aanpassen en classificeren. Deze eigenschap beschrijft niet het proces om de originele waarde van de byte van het Type van de Dienst (ToS) van de originele pakketheader aan de tunnelkopbal te kopiëren. Raadpleeg de volgende documenten voor meer informatie:
Q. Welke pakketheader velden kunnen worden opgemerkt? Welke waarden zijn er beschikbaar?
A. Met de op klasse gebaseerde markeringsfunctie kunt u de Layer 2-, Layer 3- of Multiprotocol Label Switching (MPLS)-header van uw pakketten instellen of markeren. Raadpleeg de volgende documenten voor meer informatie:
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 ze aan te passen aan velden op de toepassingslaag. Voorafgaand aan de introductie van NBAR, was de meest korrelige classificatie Layer 4 Transmission Control Protocol (TCP) en User Datagram Protocol (UDP) poortnummers. Raadpleeg de volgende documenten voor meer informatie:
V. 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-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(2)T Opmerking: u moet Cisco Express Forwarding (CEF) inschakelen om NBAR te kunnen gebruiken.
Gedistribueerde NBAR (DNBAR) is beschikbaar voor de volgende platforms:
Platform Minimale Cisco IOS-softwareversie 7500 12.2(4)T, 12.1(6)E FlexWAN 12.1(6)E Opmerking: NBAR wordt niet ondersteund op Catalyst 6000 Multilayer Switch Feature Card (MSFC) VLAN-interfaces, Cisco 12000 Series of de Route Switch Module (RSM) voor Catalyst 5000 Series. Als u geen specifiek platform ziet dat hierboven wordt vermeld, neemt u contact op met uw technische vertegenwoordiger van Cisco.
Wachtrijen en congestiebeheer
V. Wat is het doel van wachtrijen?
A. Queueing is ontworpen om tijdelijke congestie op de interface van een netwerkapparaat aan te passen door overtollige pakketten op te slaan in buffers tot bandbreedte beschikbaar wordt. Cisco IOS-routers ondersteunen verschillende wachtrijmethoden om te voldoen aan de verschillende vereisten voor bandbreedte, jitter en vertraging van verschillende toepassingen.
Het standaardmechanisme op de meeste interfaces is First In First Out (FIFO). Sommige verkeerstypen hebben zwaardere vertragings-/jittervereisten. Aldus, zou één van de volgende alternatieve het een rij vormen mechanismen moeten worden gevormd of door gebrek toegelaten:
Weighted Fair Queueing (WFQ)
Op klasse gebaseerde Weighted Fair Queueing (CBWFQ)
LLQ (Low Latency Queueing), in feite CBWFQ met een Priority Queue (PQ) (bekend als PQCBWFQ)
Prioriteitswachtrij (PQ)
Aangepaste wachtrij (CQ)
Wachtrijen vinden over het algemeen alleen plaats op uitgaande interfaces. Een router vormt een wachtrij voor pakketten die een interface uitgaan. U kunt inkomend verkeer controleren, maar meestal kunt u niet in de wachtrij voor inkomend verkeer staan (een uitzondering is een buffering aan de ontvangstzijde op een Cisco 7500 Series router die gedistribueerd Cisco Express Forwarding (dCEF) gebruikt om pakketten van de ingang naar de uitgang door te sturen; voor meer informatie, raadpleeg Understanding VIP CPU Running at 99% en Rx-Side Buffering. Op gedistribueerde high-end platforms zoals Cisco 7500 en 12000 Series kan de inkomende interface zijn eigen pakketbuffers gebruiken om overtollig verkeer op te slaan dat naar een verstopte uitgaande interface is geschakeld na het switchingbesluit 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 uit pakketgeheugen loopt. Buitensporige congestie kan leiden tot een daling van de uitvoerwachtrij. De de rijdalingen van de input hebben een verschillende worteloorzaak het grootste deel van de tijd. Raadpleeg het volgende document voor meer informatie over druppels voor probleemoplossing:
Raadpleeg de volgende documenten voor meer informatie:
V. Hoe werken Weighted Fair Queueing (WFQ) en Class Based Weighted Fair Queueing (CBWFQ)?
A. Fair Queueing streeft ernaar een redelijk deel van de bandbreedte van een interface toe te wijzen aan actieve gesprekken of IP-stromen. Het classificeert pakketten in subwachtrijen, die door een gespreksidentificatienummer worden geïdentificeerd, die een het hakken algoritme gebruiken dat op verscheidene gebieden van de IP kopbal en de lengte van het pakket wordt gebaseerd. Het gewicht wordt als volgt 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 aandeel 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 bepalen en het een minimumbandbreedtegarantie toe te wijzen. Het algoritme achter dit mechanisme is WFQ, wat de naam verklaart. Om CBWFQ te configureren definieert u specifieke klassen in map-class statements. Vervolgens wijst u een beleid toe aan elke klasse in een policy-map. Deze policy-map wordt vervolgens uitgaand gekoppeld aan een interface. Raadpleeg de volgende documenten voor meer informatie:
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 die worden geboden door het uitgeven van de bandbreedte en de prioritaire bevelen zijn beschreven met woorden zoals "gereserveerd" en "bandbreedte te terzijde te leggen", geen van beide commando implementeert een ware reservering. Het betekent, als een verkeersklasse zijn gevormde bandbreedte niet gebruikt, om het even welke ongebruikte bandbreedte wordt gedeeld onder de andere klassen.
Het systeem van de rij vormde een belangrijke uitzondering op deze regel met een prioritaire klasse. Zoals hierboven vermeld, wordt de aangeboden belasting van een prioriteitsklasse gemeten door een traffic policer. Tijdens stremmingsomstandigheden kan een prioriteitsklasse geen overtollige bandbreedte gebruiken. Raadpleeg voor meer informatie het vergelijken van de bandbreedte en prioriteitsopdrachten van een QoS-servicebeleid.
Q. Wordt op klasse gebaseerde Weighted Fair Queueing (CBWFQ) ondersteund op subinterfaces?
A. Cisco IOS logische interfaces ondersteunen geen toestand van congestie en ondersteunen de rechtstreekse toepassing van een servicebeleid dat een wachtrijmethode toepast, niet. In plaats daarvan moet u eerst de vormgeving toepassen op de subinterface met Generic Traffic Shaping (GTS) of op klasse gebaseerde shaping. Raadpleeg voor meer informatie QoS-functies toepassen op Ethernet-subinterfaces.
Q. Wat is het verschil tussen de prioriteit en bandbreedte verklaringen in een beleid-kaart?
A. De opdrachten voor prioriteit en bandbreedte verschillen zowel in functionaliteit als in de toepassingen die deze doorgaans ondersteunen. De volgende tabel geeft een overzicht van deze verschillen:
Functie bandbreedteopdracht opdracht prioriteit Minimale bandbreedtegarantie Ja Ja Maximale bandbreedtegarantie Nee Ja Ingebouwde politieagent Nee Ja Biedt lage latentie Nee Ja Raadpleeg voor meer informatie Vergelijken van de bandbreedte en prioriteitsopdrachten van een QoS-servicebeleid.
V. Hoe wordt de wachtrijlimiet berekend op de FlexWAN- en veelzijdige interfaceprocessors (VIP)?
A. Aangenomen dat er voldoende SRAM op de VIP of FlexWAN is, 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 bandbreedte:
Wachtrij limiet = 1000000 / (250 x 8 x 2) = 250
Kleinere wachtrijlimieten worden toegewezen naarmate de hoeveelheid beschikbaar pakketgeheugen afneemt en met een groter aantal Virtual Circuits (VCS).
In het volgende voorbeeld wordt een PA-A3 geïnstalleerd op een FlexWAN-kaart voor Cisco 7600 Series en ondersteunt deze meerdere subinterfaces met 2 MB permanente virtuele 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-2048KbpsDe interface van de Asynchronous Transfer Mode (ATM) krijgt een wachtrijlimiet voor de gehele interface. De limiet is een functie van de totale beschikbare buffers, het aantal fysieke interfaces op FlexWAN en de maximale wachtvertraging toegestaan op de interface. Elke PVC krijgt een deel van de interfacelimiet op basis van de PVC’s Sustained Cell Rate (SCR) of Minimale Cell Rate (MCR) en elke klasse krijgt een deel van de PVC-limiet op basis van zijn bandbreedte-toewijzing.
De volgende voorbeeldoutput van de show policy-map interface commando is afgeleid van een FlexWAN met 3687 globale buffers. Geef het bevel van de showbuffer uit om deze waarde te zien. Elke twee Mbps PVC is toegewezen 50 pakketten gebaseerd op de PVC-bandbreedte van twee Mbps (2047/149760 x 3687 = 50). Elke klasse wordt dan toegewezen een gedeelte van 50, zoals getoond in de volgende output:
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 pakketgrootten gebruiken, kan de show policy-map interfaceopdrachtoutput een toenemende waarde voor het veld no buffer drops rapporteren omdat u geen buffers meer kunt gebruiken voordat u de wachtrijlimiet bereikt. In dit geval, probeer handmatig de wachtrijlimiet in niet-prioriteitsklassen af te stemmen. Raadpleeg Begrijpen van de transmissielimiet met IP naar ATM CoS voor meer informatie.
V. Hoe verifieert u de wachtrijgrenswaarde?
A. Op niet-gedistribueerde platforms is de wachtrijlimiet standaard 64 pakketten. De volgende voorbeelduitvoer is 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
V. Kan ik een eerlijke wachtrij in een klas mogelijk maken?
A. Cisco 7500 Series met Distributed Quality of Service (QoS) ondersteunt eerlijke wachtrijen per klasse. Andere platforms, waaronder 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 wachtrijen te bewaken:
wachtrij {interface} {interfacenummer tonen} - Op Cisco IOS-platforms anders dan Cisco 7500 Series, geeft deze opdracht de actieve wachtrijen of gesprekken weer. Als de interface of Virtual Circuit (VC) niet verstopt is, worden geen wachtrijen vermeld. Op Cisco 7500 Series wordt de opdracht in de showwachtrij niet ondersteund.
toon het een rij vormen interface-aantal [vc [[vpi/] vci] - dit toont de het een rij vormen statistieken van een interface of een VC. Zelfs als er geen congestie is, kunt u nog steeds enkele hits hier zien. De reden hiervoor is dat proces switched pakketten altijd worden geteld, ongeacht de congestie die aanwezig is. Cisco Express Forwarding (CEF) en Fast-Switched pakketten worden niet geteld tenzij er congestie is. De legacy Queueing-mechanismen zoals Priority Queueing (PQ), Custom Queueing (CQ) en Weighted Fair Queueing (WFQ) zullen geen classificatiestatistieken opleveren. Alleen op modulaire Quality of Service Command Line Interface (MQC) gebaseerde functies in afbeeldingen later dan 12.0(5)T bieden deze statistieken.
toon beleidsinterface {interface} {interfacenummer} - De pakketteller telt het aantal pakketten die de criteria van de klasse aanpassen. Deze teller verhoogt al dan niet de interface verstopt is. De aangepaste pakketteller geeft het aantal pakketten aan dat overeenkomt met de criteria van de klasse toen de interface verstopt was. Raadpleeg het volgende document voor meer informatie over pakkettellers:
De betekenis van pakkettellers in tonen beleid-kaart interface Output
Cisco op klasse gebaseerde QoS-configuratie en -statistieken MIB - Biedt Simple Network Management Protocol (SNMP)-bewakingsfuncties.
Q. RSVP kan worden gebruikt in combinatie met op klasse gebaseerde Weighted Fair Queueing (CBWFQ). Wanneer zowel Resource Reservation Protocol (RSVP) als CBWFQ zijn geconfigureerd voor een interface, handelen RSVP en CBWFQ onafhankelijk en vertonen zij hetzelfde gedrag als wanneer zij alleen zouden lopen? RSVP lijkt zich te gedragen alsof CBWFQ niet is geconfigureerd voor beschikbaarheid, evaluatie en toewijzing van bandbreedte.
A. Wanneer u RSVP en CB-WFQ in Cisco IOS-softwarerelease 12.1(5)T en hoger gebruikt, kan de router zo werken 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 om toelatingscontrole uit te voeren met behulp van zijn eigen "ip rsvp bandbreedte"-pool, terwijl CBWFQ bezig is met classificatie, toezicht en planning van RSVP-pakketten. Dit veronderstelt vooraf gemarkeerde pakketten door de afzender, en dat niet-RSVP-pakketten verschillend worden gemarkeerd.
Weging van congestievermijding gewogen willekeurige vroege detectie (WRED)
Q. Kan ik Weighted Random Early Detection (WRED) en Low Latency Queueing (LLQ) tegelijkertijd inschakelen of op klasse gebaseerde Weighted Fair Queueing (CBWFQ)?
A. Ja. De wachtrij bepaalt de volgorde van de pakketten die een wachtrij verlaten. Dit betekent dat er een pakketplanningsmechanisme wordt gedefinieerd. Het kan ook worden gebruikt om eerlijke bandbreedtetoewijzing en minimale bandbreedtegaranties te verstrekken. In tegenstelling, definieert de Verzoek om Commentaren (RFC) 2475 het laten vallen als het "proces om pakketten weg te gooien die op gespecificeerde regels worden gebaseerd." Het standaard drop mechanisme is staartdruppel, waarin de interface pakketten laat vallen wanneer de wachtrij vol is. Een alternatief drop-mechanisme is Random Early Detection (RED) en Cisco’s WRED, die beginnen met het willekeurig laten vallen van pakketten voordat de wachtrij vol is en probeert een consistente gemiddelde wachtrijdiepte te behouden. WRED gebruikt de IP-prioriteitswaarde van pakketten om een gedifferentieerd dalingsbesluit te nemen. Raadpleeg Weighted Random Early Detection (WRED) voor meer informatie.
V. Hoe kan ik Weighted Random Early Detection (WRED) bewaken en zien dat het effect heeft?
A. WRED controleert de gemiddelde rijdiepte en begint pakketten te laten vallen wanneer de berekende waarde boven de minimumdrempelwaarde gaat. Geef het show-beleid-kaart interfacebevel uit en controleer de gemiddelde waarde van de rijdiepte, 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 vormgeving
V. Wat is het verschil tussen toezicht en vormgeving?
A. Het volgende diagram illustreert het belangrijkste verschil. Traffic Shaping behoudt overtollige pakketten in een wachtrij en plant vervolgens het overtollige bedrag voor latere transmissie over perioden. Het resultaat van traffic shaping is een vloeiende uitvoersnelheid van het pakket. Traffic policing daarentegen maakt barsten mogelijk. Wanneer het verkeerstarief het ingestelde maximumtarief bereikt, wordt overtollig verkeer verbroken (of gemerkt). Het resultaat is een outputsnelheid die verschijnt als een zaagtand met toppen en troggen.
Raadpleeg voor meer informatie Overzicht van toezicht en vormgeving.
Q. Wat is een symbolische emmer en hoe werkt het algoritme?
A. Een symbolische emmer zelf heeft geen teruggooi of prioritair beleid. Dit is een voorbeeld van hoe de symbolische emmermetafoor werkt:
Tokens worden met een bepaalde snelheid in de emmer gestopt.
Elk token is toestemming voor de bron om een bepaald aantal bits te verzenden.
Om een pakket te verzenden, moet de verkeersregelaar in staat zijn om een aantal tokens te verwijderen dat gelijk is aan de pakketgrootte.
Als er niet genoeg tokens in de emmer zitten om een pakket te versturen, wacht het pakket ofwel tot de emmer genoeg tokens heeft (in het geval van een shaper) of het pakket wordt weggegooid of afgezet (in het geval van een policer).
De emmer zelf heeft een specifieke capaciteit. Als de emmer tot de capaciteit vult, worden nieuw aankomende penningen weggegooid en zijn niet beschikbaar voor toekomstige pakketten. Dus op elk moment is de grootste uitbarsting die een bron naar het netwerk kan sturen ruwweg evenredig met de grootte van de emmer. Een symbolische emmer maakt barstheid mogelijk, maar beperkt het.
V. Met een traffic policer zoals class-based policing, wat betekenen Commited Burst (BC) en Excess Burst (Be) en hoe kan ik deze waarden selecteren?
A. Een traffic policer stoot niet op overtollige pakketten en geeft ze later door, zoals bij een shaper. In plaats daarvan, voert de politieagent eenvoudig uit verzend of verzend geen beleid zonder als buffer op te treden. Tijdens periodes van congestie, omdat u niet kunt bufferen, is het beste dat u kunt doen is minder agressief pakketten te laten vallen door goed te configureren uitgebreide burst. Daarom is het belangrijk om te begrijpen dat de policer de normale burst en uitgebreide burst waarden gebruikt om er zeker van te zijn dat de geconfigureerde Commited Information Rate (CIR) wordt bereikt.
De burst parameters zijn losjes gemodelleerd op de generische buffering regel voor routers. De regel adviseert het configureren van buffering gelijk aan de round-trip time bitrate om de uitstekende TCP-vensters (Transmission Control Protocol) van alle verbindingen in tijden van stremming aan te passen.
In de volgende tabel worden het doel en de aanbevolen formule voor de normale en uitgebreide barstwaarden beschreven:
burst-parameter Doel Aanbevolen formule normale burst
Hiermee wordt een standaard token bucket geïmplementeerd.
Stelt de maximale grootte van de token bucket in (hoewel token kunnen worden geleend als Be groter is dan BC).
Bepaalt hoe groot de symbolische emmer kan zijn aangezien de nieuw aankomende penningen worden verworpen en niet beschikbaar aan toekomstige pakketten zijn als de emmer aan capaciteit vult.
Opmerking: 1,5 seconden is de typische ronde reistijd.
uitgebreide uitbarsting
Hiermee implementeert u een token bucket met uitgebreide burst mogelijkheid.
Uitgeschakeld door BC = Be in te stellen.
Als BC gelijk is aan Be, kan de verkeersregelaar geen tokens lenen en laat het pakket vallen als er onvoldoende tokens beschikbaar zijn.
Niet alle platforms gebruiken of ondersteunen dezelfde reeks waarden voor een policer. Raadpleeg het volgende document voor informatie over de ondersteunde waarden voor uw specifieke platform:
Q. Hoe beslist Committed Access Rate (CAR) of op klasse gebaseerde policing of een pakket voldoet aan of hoger is dan de Commited Information Rate (CIR)? De router laat pakketten vallen en meldt een overschreden tarief alhoewel het conformed tarief minder is dan gevormde CIR.
A. Een traffic policer gebruikt de normale burst- en uitgebreide burstwaarden om er zeker van te zijn dat de geconfigureerde CIR wordt bereikt. Het instellen van voldoende hoge burstwaarden 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 sterk negatief effect hebben op de doorvoersnelheid van TCP-verkeer (Transmission Control Protocol). Met CAR, geef de show interface rate-limit opdracht om de huidige burst te controleren en te bepalen of de weergegeven waarde consistent dicht bij de limiet (BC) en de uitgebreide limiet (Be) waarden is.
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 de volgende documenten voor meer informatie:
V. Zijn de burst- en wachtrijlimiet onafhankelijk van elkaar?
A. Ja, de politieman barst en de wachtrij is 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 met de limiet van de wachtrij die de toegelaten pakketten vóór transmissie op het netwerk houdt. Ideaal gezien, wilt u uw emmer groot genoeg zijn om een uitbarsting van bytes/pakketten te houden die door de poort (politieagent) worden toegelaten.
QoS-Frame Relay (Quality of Service)
Q. Welke waarden zou ik voor Toegewijde Informatiesnelheid (CIR), Toegewijde Uitbarsting (BC), Overtollige Uitbarsting (BE), en Minimale CIR (MinCIR) moeten selecteren?
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 over de interpretatie van deze opdrachten:
V. Werkt prioriteitswachtrij op de Frame Relay-hoofdinterface in Cisco IOS 12.1?
A. Frame Relay-interfaces ondersteunen zowel mechanismen voor interfacewachtrij als mechanismen voor per-Virtual Circuit (VC)-wachtrij. Vanaf Cisco IOS 12.0(4)T ondersteunt de interfacewachtrij First In First Out (FIFO) of Per Interface Priority Queueing (PIPQ) alleen wanneer u Frame Relay Traffic Shaping (FRTS) configureert. Daarom zal de volgende configuratie niet meer werken als u upgrade 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 bandbreedtebuis. Daarnaast kunt u vanaf Cisco IOS 12.1.1(T) Frame Relay Permanent Virtual Circuits (PVC) Priority Interface Queueing (PIPQ) inschakelen op een Frame Relay hoofdinterface. U kunt hoge, middelgrote, normale, of lage prioriteit PVCs bepalen en het frame relay interface-wachtrij prioriteitsbevel uitgeven op de belangrijkste interface, 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 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 Cisco 7500 Series. Om traffic shaping op Frame Relay-interfaces mogelijk te maken, gebruikt u DTS (Distributed Traffic Shaping). Raadpleeg de volgende documenten voor meer informatie:
Quality-of-Service (QoS) over asynchrone overdrachtsmodus (ATM)
Q. Waar pas ik een servicebeleid toe 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 ondersteunt ATM interfaces servicebeleid op drie niveaus voor logische interfaces: hoofdinterface, subinterface en permanent virtueel circuit (PVC). Waar u het beleid toepast, is een functie van de QoS-functie (Quality of Service) die u inschakelt. Wachtbeleid moet worden toegepast per Virtual Circuit (VC) aangezien de ATM-interface het congestieniveau per VC controleert en wachtrijen voor overtollige pakketten per VC handhaaft. Raadpleeg de volgende documenten voor meer informatie:
Q. Welke bytes worden door IP geteld naar de wachtrij voor Asynchronous Transfer Mode (ATM) Class of Service (CO’s)?
A. De bandbreedte en de prioritaire bevelen die in een de dienstbeleid worden gevormd om op klasse gebaseerde gewogen eerlijke het een rij vormen (CBWFQ) en lage latentie het een rij vormen (LLQ) toe te laten, respectievelijk, gebruiken een waarde van Kbps die de zelfde overheadbytes telt zoals door de output van het showinterfacebevel worden geteld. Met name het systeem voor Layer 3-wachtrijen telt Logical Link Control/Subnetwork Access Protocol (LLC/SNAP). Het telt niet het volgende:
ATM-aanpassingslaag 5 (AAL5) aanhangwagen
Opvulling om laatste cel een even veelvoud van 48 bytes te maken
Kop van vijf bytes
V. Hoeveel Virtual Circuits (VCS) kunnen een servicebeleid tegelijkertijd ondersteunen?
A. Het volgende document bevat nuttige richtlijnen over het aantal VCS-systemen (Asynchronous Transfer Mode (ATM) dat kan worden ondersteund. Ongeveer 200 tot 300 VBR-Nrt Permanente Virtuele Circuits (PVC’s) zijn veilig geïmplementeerd:
Houd ook rekening met 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 tot 32 MB (in een systeem met 256 MB) gereserveerd voor pakketbuffer. Voor een NPE-200, wordt tot 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 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 werkt. Als 100 pvc van ATM werden gevormd en als alle VCS gelijktijdig bovenmatige congestie ervoeren (zoals in testmilieu's kon worden gesimuleerd waar de niet-TCP stroom gecontroleerde bron zou worden gebruikt), dan zou gemiddeld elk pvc ongeveer 10 pakketten waard van het als buffer optreden voor hebben, die voor WRED te kort kunnen zijn om met succes te werken. VIP2-50-apparaten met groot SRAM worden dus sterk aanbevolen in ontwerpen met een groot aantal ATM PVC’s die per-VC WRED draaien en die congestie tegelijkertijd kunnen ervaren.
Hoe hoger het aantal gevormde actieve PVC’s, hoe lager het tarief van de Duurzame Cel (SCR) zou moeten zijn, en bijgevolg hoe korter de rij die WRED nodig heeft om op PVC te werken. Dus, zoals het geval is bij het gebruik van de standaard WRED-profielen van fase 1 van de IP-naar-ATM serviceklasse (CO’s), zou het configureren van lagere WRED-drop-drempels wanneer per-VC WRED wordt geactiveerd op een zeer groot aantal lage-snelheid gestremde ATM PVC’s het risico van buffertekort op de VIP minimaliseren. Buffertekort op de VIP resulteert niet in een storing. In het geval van buffertekort op de VIP, degradeert de IP naar ATM COs fase 1 functie simpelweg tot First In First Out (FIFO) staartdaling tijdens de periode van buffertekort (namelijk, hetzelfde drop-beleid dat zou voorkomen als de IP naar ATM COs-functie niet op dit PVC was geactiveerd).
Maximum aantal gelijktijdige VCS dat redelijkerwijs kan worden ondersteund.
V. Welke ATM-hardware (Asynchronous Transfer Mode) ondersteunt functies van IP-naar-ATM serviceklasse (CO’s), waaronder Class Based Weighted Fair Queueing (CBWFQ) en Low Latency Queueing (LLQ)?
A. IP naar ATM CO’s verwijst naar een aantal functies die per Virtual Circuit (VC) zijn ingeschakeld. Gezien deze definitie worden IP naar ATM CoS niet ondersteund op de ATM-interfaceprocessor (AIP), PA-A1 of 4500 ATM-netwerkprocessors. Deze ATM-hardware ondersteunt geen per-VC wachtrijen omdat de PA-A3 en de meeste netwerkmodules (anders dan ATM-25) deze definiëren. Raadpleeg voor meer informatie het volgende document:
Spraak en Quality of Service (QoS)
V. Hoe werkt Link Fragmentation and Interleaving (LFI)?
A. Interactief verkeer zoals Telnet en Voice over IP is vatbaar voor verhoogde latentie wanneer het netwerk grote pakketten zoals de overdrachten van het Protocol van de Overdracht van het Bestand (FTP) over WAN verwerkt. De pakketvertraging voor interactief verkeer is aanzienlijk als de FTP-pakketten op langzamere WAN-koppelingen in de wachtrij worden geplaatst. Er is een methode ontworpen om grotere pakketten te fragmenteren en de kleinere (spraak)pakketten in een wachtrij te plaatsen tussen de fragmenten van de grotere pakketten (FTP). Cisco IOS-routers ondersteunen meerdere Layer 2-fragmentatiemechanismen. Raadpleeg de volgende documenten voor meer informatie:
V. Welke tools kan ik gebruiken om de prestaties van Voice over IP te bewaken?
A. Cisco biedt momenteel verschillende opties voor het bewaken van Quality of Service (QoS) in netwerken met behulp van Cisco Voice over IP-oplossingen. Deze oplossingen meten de spraakkwaliteit niet met Perceptual Speech Quality Measurement (PSQM) of met een aantal van de nieuwe voorgestelde algoritmen voor spraakkwaliteitsmeting. Tools van Agilent (HP) en NetIQ zijn voor dit doel beschikbaar. Cisco biedt echter wel tools die een idee geven van de spraakkwaliteit die u ervaart door vertraging, jitter 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.
Q. %SW_MGR-3-CM_ERROR_TITLE_CLASS: Connection Manager Feature Error: Class SSS: (QoS) - installeer fout, negeer.
A. De waargenomen fout van de eigenschapinstallatie is een verwacht gedrag wanneer een ongeldige configuratie wordt toegepast op een malplaatje. Het geeft aan dat het dienstenbeleid niet werd toegepast vanwege een conflict. In het algemeen, zou u niet het vormen op klasse-gebrek van het kindbeleid in hiërarchische beleidskaarten moeten vormen, in plaats daarvan het op het ouderbeleid van de interface vormen. Dit bericht samen met de traceback wordt als gevolg afgedrukt.
Met op sessies gebaseerd beleid moet vormgeven op klasse-default alleen op subinterface- of PVC-niveau worden gedaan. Het vormen op de fysieke interface wordt niet ondersteund. Als de configuratie op de fysieke interface wordt uitgevoerd, is het voorkomen van deze foutenmelding een verwacht gedrag.
In het geval van LNS, zou een andere reden kunnen zijn dat het de dienstbeleid via de radiusserver zou kunnen zijn provisioned wanneer de zittingen worden opgevoed. Geef de opdracht show tech uit om de radiusserverconfiguratie te bekijken en om elk illegaal servicebeleid te bekijken dat via de radiusserver wordt geïnstalleerd wanneer de sessie verschijnt of flapt.
Feedback