Dit document biedt enkele richtlijnen op hoog niveau voor het implementeren van Quality of Service (QoS) in een netwerk dat fungeert als een transport voor meerdere toepassingen, inclusief vertraging-gevoelige en bandbreedte-intensieve toepassingen. Deze toepassingen kunnen bedrijfsprocessen verbeteren, maar strekken netwerkmiddelen uit. QoS kan beveiligde, voorspelbare, meetbare en gegarandeerde services aan deze toepassingen bieden door vertraging, vertragingsvariatie (jitter), bandbreedte en pakketverlies in een netwerk te beheren.
Bepaal eerst welke toepassingen bedrijfskritisch zijn en bescherming vereisen. Het kan zijn dat u alle toepassingen moet bekijken die strijden om netwerkresources. Als dit probleem zich voordoet, gebruikt u NetFlow-accounting, Network-based Application Recognition (NBAR) of QoS Device Manager (QDM) om de verkeerspatronen in het netwerk te analyseren.
NetFlow Accounting biedt gedetailleerde informatie over netwerkverkeer en kan worden gebruikt om de verkeersclassificatie of -voorrang op te nemen die aan elke stroom is gekoppeld.
NBAR is een classificatiehulpmiddel dat verkeer tot de toepassingslaag kan identificeren. Het verstrekt per-interface, per-protocol, en bi-directionele statistieken voor elke verkeersstroom die een interface oversteken. NBAR voert ook subpoortclassificatie uit; verder kijken en identificeren dan toepassingspoorten.
QDM is een webgebaseerde netwerkbeheertoepassing die een gebruiksvriendelijke grafische gebruikersinterface biedt voor het configureren en bewaken van geavanceerde IP-gebaseerde QoS-functionaliteit in routers.
Het is belangrijk de kenmerken te begrijpen van de toepassingen die bescherming nodig hebben. Sommige toepassingen neigen gevoelig te zijn voor latentie of pakketverlies, terwijl anderen als "agressief" worden beschouwd omdat zij bursty zijn of veel bandbreedte verbruiken. Als de toepassing barstte, moet u bepalen of er een constante barst of een kleine barst is. Is de pakketgrootte van de toepassing groot of klein? Is de toepassing TCP of UDP gebaseerd?
kenmerkend | Richtsnoer |
---|---|
Toepassing die vertraging- of verliesgevoelig is. (Spraak en realtime video) | Gebruik geen gewogen random early detectie (WRED), traffic shaping, fragmentatie (FRF-12) of toezicht. Voor dit soort verkeer moet u LLQ (Low Latency Queuing) implementeren en een prioriteitswachtrij gebruiken voor het vertragingsgevoelige verkeer. |
Toepassing die constant bursty of is een bandbreedte hog. (FTP en HTTP) | Gebruik WRED, policing, traffic shaping of op klasse gebaseerde Weighted Fair Queuing (CBWFQ) om bandbreedte te garanderen. |
Toepassing die op TCP is gebaseerd. | Gebruik WRED sinds verloren pakketten veroorzaken TCP om terug te keren en dan opnieuw omhoog te gaan met behulp van het langzaam-start algoritme. Als het verkeer op UDP is gebaseerd en het gedrag niet wijzigt wanneer pakketten worden gedropt, gebruikt u WRED niet. Gebruik Policing als u de toepassing moet beoordelen; anders laat u de pakketten gewoon vallen. |
Sommige apparaten hebben mogelijk een IOS-upgrade nodig om te kunnen profiteren van de QoS-functies die u wilt implementeren. Diagrammen van de netwerktopologie, routerconfiguraties en softwareversie op elk apparaat helpen u het aantal apparaten schatten dat een IOS-upgrade vereist. Raadpleeg de Cisco Icon Library voor pictogrammen die u kunnen helpen netwerkdiagrammen te maken.
Beoordeel het CPU-gebruik op elke router tijdens drukke perioden om te helpen beslissen hoe QoS-functies worden verdeeld over apparaten om de lading te delen.
Classificeren van bedrijfskritieke verkeerstypen en de interfaces die dit verkeer zal verplaatsen. Bepaal welke prioriteitsgroepen of -klassen u wilt maken om de QoS-doelstellingen voor uw netwerk te realiseren.
Bepaal de maximale vertraging die de meest kritieke toepassingen kunnen verwerken en pas de barstparameters aan binnen de verkeersregelaars (traffic shapers of policers) om deze vertraging aan te passen.
Bekijk welke snelheden worden ondersteund op elke interface: PVC’s of subinterfaces en configureer de bandbreedte die moet overeenkomen.
Identificeer trage koppelingen om te helpen bepalen waar de knelpunten in het netwerk zich bevinden en beslis hoe koppelingsefficiëntiemechanismen op de juiste interfaces moeten worden toegepast.
Bereken Layer 2 en Layer 3-overheadkosten voor elk mediatype dat het bedrijfskritieke verkeer zal transporteren. Dit zal helpen de correcte hoeveelheid bandbreedte berekenen die voor elke klasse wordt vereist.
Een andere belangrijke informatie is of u verkeer wilt beschermen op basis van toepassing, IP-bron en bestemming, of beide.
Mediatype | Kop voor linklaag |
---|---|
Ethernet | 14 Bytes |
PPP | 6 Bytes |
Frame Relay | 4 Bytes |
ATM | 5 bytes/cel |
Zodra u bepaalt welke toepassingen QoS en de te gebruiken classificatiecriteria nodig hebben (gebaseerd op de kenmerken van de toepassingen), bent u bereid om klassen te creëren die op deze informatie worden gebaseerd.
Maak een beleid om elke verkeersklasse met de juiste prioriteitswaarden te markeren (gebruik gedifferentieerde services control point (DSCP) of IP Precedence). Het verkeer zal worden gemarkeerd aangezien het in de router op de toegangsinterface komt. De markeringen zullen worden gebruikt om het verkeer te behandelen aangezien het de router op de uitgangsinterface verlaat.
Werk vanuit de router die het dichtst bij het verkeer staat, naar de kern. Pas uw markering toe op de ingangsinterface van de router. In onderstaande topologie is router A de voor de hand liggende plaats om verkeer te markeren en beleid toe te passen voor gegevensbronnen van netwerk A en bestemd voor router B. Het verkeer zal worden gemarkeerd aangezien het in router A's Ethernet0 interface komt, en het QoS beleid zal op router A's Serial0 interface worden toegepast aangezien het de router verlaat. Als hetzelfde beleid in beide richtingen moet worden toegepast (zodat verkeer dat afkomstig is van netwerk B en bestemd is voor netwerk A dezelfde behandeling krijgt), moet het verkeer dat afkomstig is van netwerk B worden gemarkeerd als het in de Ethernet1-interface van router B komt en behandeld wordt als het de router verlaat op de Serial1-interface.
Zodra het verkeer op de toegangsinterface op één router wordt gemarkeerd, handhaaft het de zelfde markeringen aangezien het veelvoudige hop (tenzij het wordt herkend) oversteekt. Normaal gesproken hoeft verkeer slechts eenmaal te worden gemarkeerd. QoS-beleid kan worden toegepast op extra hop op basis van deze markeringen. U hoeft alleen maar opnieuw te markeren in het geval dat er verkeer komt van een onbetrouwbaar domein.
Nu u het verkeer hebt gemarkeerd, kunt u de markeringen gebruiken om een beleid te bouwen en verkeersclassificatie op de rest van de netwerksegmenten te doen. We raden aan om het beleid eenvoudig te houden door niet meer dan vier klassen te gebruiken.
Indien mogelijk, implementeer en test een QoS-implementatie in een laboratoriumomgeving. Implementeer het in het live netwerk nadat u tevreden bent met de resultaten.
Pas het beleid in de juiste richting toe. Beslissen of het beleid in één richting of in beide richtingen moet worden toegepast. Markeer en behandel verkeer altijd zo dicht mogelijk bij de bron, zoals beschreven in het gedeelte Beleid maken om elke klasse van dit document te markeren.
We raden u aan hetzelfde beleid in beide richtingen toe te passen om verkeer te filteren dat van en naar beide kanten van de site komt. Dit betekent dat u hetzelfde beleid moet toepassen op de seriële interface van router A en de seriële interface van router B.
Gebruik QPM als een compleet systeem voor gecentraliseerde beleidscontrole en geautomatiseerde, betrouwbare beleidsontwikkeling.
Hieronder staat een lijst met QOS-categorieën en enkele van de meer algemeen gebruikte QOS-functies die bij elke categorie horen.
Categorie | Bijbehorende QoS-functies |
---|---|
QoS-servicemodel | Provisioned (DiffServ) QoS indien mogelijk of gesignaleerd (RSVP) indien nodig. |
Classificatie/markering | DiffServ-codepunten of qos-groep-id. |
Congestiebeheer | LLQ of CBWFQ. |
Congestievermijding | DiffServ-conforme WRED. |
Koppelingsefficiëntie | MLPPP, LFI, FRF.11, FRF.12, CRTP |
Signalering | RSVP, QPPB |
Traffic conditioners/toezicht | Op klasse gebaseerde policer en Generic Traffic Shaping (GTS) of Frame Relay Traffic Shaping (FRTS). |
Configuratie/bewaking | QPM, modulaire QoS Command Line Interface (CLI), QDM |
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
10-Dec-2001
|
Eerste vrijgave |