Qos funktionsprincip. Hantera QoS på Windows-plattformen. Exempel på trafikklassificering

Lämna en kommentar 6,950

Låt oss börja med definitionerna:

Jämförelse av IPP och DSCP.

Per-Hop Behaviours (PHB)

1.Standard PHB

3. Assured Forwarding PHB (AF)

4.Klassväljare PHB (CS)

Låt oss försöka ta reda på vad QoS (Quality of Service) är, vilka standarder och definitioner som gäller för det. Låt oss prata om Best Effort Service, IntServ, DiffServ, PHB, ToS, CoS, IP Precedence (IPP), DSCP, AF, EF, Default PHB.

Låt oss först definiera vad tjänstekvalitet är. Det finns många definitioner av QoS, men min favorit är den här:

QoS (Quality of Service) ska förstås som förmågan hos ett nätverk (nätverksinfrastruktur) att tillhandahålla den nödvändiga (krävda) servicenivån till en given nätverkstrafik vid användning av olika tekniker.

En tjänst hänvisar till många parametrar vid överföring av data. Låt oss överväga de viktigaste:

1. Bandbredd - bandbredd. 2. End-to-end-fördröjning - fördröjning under paketöverföring. 3. Jitter - förändring av tidsfördröjning vid överföring av paket. 4. Paketförlust – förlust (bortfall) av paket under dataöverföring.

Servicemodeller Servicekvalitet.

Det finns 3 olika QoS-tjänstemodeller.

1. Best Effort Service. Ej garanterad leverans.

I huvudsak saknar denna modell några QoS-mekanismer. Alla tillgängliga nätverksresurser används. Det finns inga trafikkontrollmekanismer. För att förbättra QoS används bandbreddsexpansion i flaskhalsar, men detta ger inte alltid önskad effekt eftersom Det finns typer av trafik som är känsliga för förseningar och jitter (till exempel VoIP).

2. Integrerad tjänst (IntServ). Integrerad tjänst.

Ger end-to-end servicekvalitet, d.v.s. resurser reserveras längs hela trafikleden. För resursreservation används RSVP-protokollet, vilket garanterar den nödvändiga genomströmningen. En betydande nackdel är den ständiga reservationen av en resurs, även om den inte används eller inte används fullt ut.

3. Differentierad tjänst (DiffServ). Differentierad service.

För att säkerställa QoS används ett antal specialkomponenter, såsom klassificerare och trafikformare vid nätverkskanten, och resursallokeringsfunktioner i nätverkskärnan används också.

DiffServ utför två funktioner:

1. Trafikformning vid nätgränserna - funktioner för klassificering, paketmärkning och intensitetskontroll. 2. PHB-policyn (Per-Hop Behavior) inkluderar resursallokering och paketsläppfunktioner.

QoS Klassificering och märkning av paket.

Låt oss börja med definitionerna:

Paketklassificering - tilldela ett paket till en specifik klass.

Paketmärkning - ställ in önskad prioritet.

Det bör noteras att klassificeringen och märkningen av paket skiljer sig beroende på vilket OSI-lager som enheten fungerar på. Som regel fungerar alla switchar på L2-nivå, nämligen med Ethernet-ramar. Routrar fungerar på L3-nivå och inte längre med ramar, utan med paket.

Klassificering och märkning av paket på L2-nivå

Ethernet-protokollet har inte förmågan att klassificera och markera paket. Klassificering är endast möjlig efter nummer inkommande hamn(vilket i de flesta fall inte är av intresse), och märkning är inte alls möjlig.

Men allt är inte dåligt. IEEE 802.1Q-standarden har dykt upp, som beskriver virtuell lokal teknik VLAN, med vilken 802.1P-standarden utvecklades för att tillhandahålla QoS i Ethernet-nätverk (klassificering och märkning av Ethernet-ramar).

802.1P-standarden tillhandahåller ett användarprioritetsfält eller ett andra senare namn CoS (Class of Service), bestående av 3 bitar i 802.1Q-huvudet, dvs. CoS kan ta värden från 0 till 7.

802.1Q Ethernet ramformat.

Trafikklasser enligt standarden IEEE 802.1P.

Klassificering och märkning av paket på L3-nivå

På L3 har vi att göra med IP (Internet Protocol). När IP-protokollet utvecklades tillhandahölls ett enbyte ToS (Type of Service)-fält specifikt för QoS-ändamål.

ToS-fältet kan fyllas i med en IP-precedens eller DSCP-klassificerare beroende på uppgiften.

IP-precedens (IPP) har en dimension på 3 bitar och kan ta värden 0-7, d.v.s. vi kan prata om 8 serviceklasser. Ursprungligen användes IPP-klassificeraren, men med tiden blev det nödvändigt att dela upp trafiken i mer än 8 tjänsteklasser, vilket resulterade i utvecklingen av DSCP-klassificeraren.

DSCP består av 6 bitar (värden 0-63). Användningen av ytterligare 3 bitar gör att du kan ange ett större antal klasser. DSCP är bakåtkompatibel med IPP. Det är viktigt att förstå att utrustningen måste stödja bearbetning av ToS-fältet ifyllt av DSCP-klassificeraren problem med detta kan uppstå på äldre utrustning.

Jämförelse av IPP och DSCP.

Per-Hop Behaviours (PHB)

Låt oss titta på begreppet PHB mer i detalj.

Per-Hop Behaviors (PHB) är en steg-för-steg-tjänstpolicy, med andra ord är det en viss algoritm för paketbearbetningsåtgärder som utförs på varje nod. PHB bestämmer vilken kö ett paket ska tilldelas, och även hur paket i kön släpps i händelse av överbelastning.

Det finns 4 standardiserade PHBs.

1.Standard PHB

Används för att överföra Best-Efforts (icke-garanterad leverans) trafik, dvs. det finns ingen märkning, eller snarare DSCP-bitar 5 till 7 är lika med 000. Används för kompatibilitet med nätverksenheter som inte stöder märkning eller om den inte används.

Distribution av DSCP-bitar i standard-PHB.

2. Snabb vidarebefordran PHB (EF)

Används för att överföra fördröjningskänslig trafik. DSCP-bitarna 5 till 7 är inställda på 101. Paket markerade som EF sänds med minsta fördröjning i kön.

DSCP-bitallokering i EF PHB.

3. Assured Forwarding PHB (AF)

Används för garanterad leverans. Värdet på DSCP-bitar 5 till 7 kan ta 4 värden (001, 010, 011, 100), därför finns det fyra standard AF-klasser (AF1, AF2, AF3, AF4), och inom varje klass kan det finnas tre nivåer av paketdrop (låg, medium, hög).

DSCP-bitallokering i AF PHB.

aaa - serviceklassnummer.
dd är sannolikheten för att paketet tappas.

4.Klassväljare PHB (CS)

Värdet på DSCP-bitarna 2 till 4 är 000, vilket är bakåtkompatibelt med ToS-fältet som fylls i av IPP-klassificeraren.

DSCP-bitallokering i Class Selector PHB.

Nedan finns en jämförelsetabell mellan DSCP och IP Precedence.

Jämförelsetabell mellan DSCP och IPP.

Det är allt. Jag försökte kort prata om QoS och begreppen som ingår i det, som Best Effort Service, IntServ, DiffServ, PHB, ToS, CoS, IPP, DSCP, AF, EF, Default PHB.

För närvarande, tillsammans med den systematiska ökningen av dataöverföringshastigheter inom telekommunikation, ökar andelen interaktiv trafik, som är extremt känslig för parametrarna i transportmiljön. Därför blir uppgiften att säkerställa servicekvalitet (QoS) allt viktigare.

Det är bäst att börja överväga en fråga av sådan komplexitet med enkla och begripliga exempel på utrustningskonfiguration, till exempel från Cisco. Materialet som presenteras här kan absolut inte konkurrera med www.cisco.com. Vår uppgift är den första klassificeringen av en enorm mängd information i en kompakt form för att underlätta förståelse och vidare studier.

1. Definitioner och termer.

Det finns så många definitioner av termen QoS att vi kommer att välja den enda rätta - korrekt, från Cisco: "QoS – QoS refererar till förmågan hos ett nätverk att ge bättre service till utvald nätverkstrafik över olika underliggande teknologier..." . Vilket ordagrant kan översättas som: "QoS är förmågan hos ett nätverk att tillhandahålla den nödvändiga tjänsten till en given trafik inom ett visst tekniskt ramverk."

Den nödvändiga tjänsten beskrivs av många parametrar, vi kommer att notera de viktigaste av dem.

Bandbredd (BW)- bandbredd, beskriver den nominella kapaciteten för informationsöverföringsmediet, bestämmer kanalens bredd. Mätt i bit/s (bps), kbit/s (kbps), mbit/s (mbps).

Dröjsmål- fördröjning under paketöverföring.

Jitter- fluktuation (variation) av fördröjning under paketöverföring.

Paketförlust– paketförlust. Bestämmer antalet paket som tappas av nätverket under överföring.

Oftast för beskrivning bandbredd Kanalen är analogiserad med ett vattenrör. Inom dess ram är bandbredd rörets bredd och fördröjning är längden.

Tid att sända ett paket genom kanalen Sändningstid [s] = paketstorlek / bw .

Låt oss till exempel hitta överföringstiden för ett 64-byte-paket över en 64-kilobit/s bred kanal:

Paketstorlek = 64*8=512 (bitar) Sändningstid = 512/64000 = 0,008 (s)

2. QoS-tjänstemodeller.

2.1. Best Effort Service.

Ej garanterad leverans. Absolut frånvaro av QoS-mekanismer. Alla tillgängliga nätverksresurser används utan tilldelning av separata trafikklasser och reglering. Man tror att den bästa mekanismen för att tillhandahålla QoS är att öka bandbredden. Detta är i princip korrekt, men vissa typer av trafik (till exempel röst) är mycket känsliga för paketförseningar och variationer i deras hastighet. Best Effort Service-modellen, även med stora reserver, tillåter att överbelastningar uppstår vid plötsliga ökningar i trafiken. Därför har andra metoder för att tillhandahålla QoS utvecklats.

2.2. Integrerad tjänst (IntServ).

Integrated Service (IntServ, RFC 1633) - integrerad tjänstemodell. Kan tillhandahålla end-to-end servicekvalitet, vilket garanterar den nödvändiga genomströmningen. IntServ använder RSVP-signaleringsprotokollet för sina syften. Tillåter appar att uttrycka resurskrav från slut till ände och innehåller mekanismer för att upprätthålla dessa krav. IntServ kan kort beskrivas som en resursreservation.

2.3. Differentierad tjänst (DiffServ).

Differentierad tjänst (DiffServ, RFC 2474/2475) - Differentierad tjänstemodell. Definierar QoS-försörjning baserat på väldefinierade komponenter som kombineras för att tillhandahålla de tjänster som krävs. DiffServ-arkitekturen förutsätter närvaron av klassificerare och trafikformare vid nätverkskanten, samt stöd för resursallokeringsfunktioner i nätverkskärnan för att tillhandahålla den erforderliga Per-Hop Behavior (PHB) policyn. Delar in trafik i klasser genom att introducera flera QoS-nivåer. DiffServ består av följande funktionsblock: traffic edge shapers (paketklassificering, märkning, intensitetskontroll) och PHB-policyimplementerare (resursallokering, paketsläpppolicy). DiffServ kan kort beskrivas som trafikprioritering (Prioritering).

3. Grundläggande funktioner QoS

De grundläggande funktionerna i QoS är att tillhandahålla nödvändiga parametrar tjänster och definieras i förhållande till trafik som: klassificering, markering, trängselkontroll, trängselförebyggande och strypning. Funktionellt tillhandahålls klassificering och märkning oftast vid ingångsportarna på utrustningen, och kontroll och överbelastningsskydd tillhandahålls vid utgångsportarna.

3.1. Klassificering och märkning.

Paketklassificering är en mekanism för att tilldela ett paket till en specifik trafikklass.

En annan lika viktig uppgift vid bearbetning av paket är Packet Marking - att tilldela en lämplig prioritet (etikett).

Beroende på graden av hänsyn (vilket betyder OSI) löses dessa uppgifter olika.

3.1.1. Lager 2 Klassificering och märkning.

Ethernet-switchar (lager 2) använder datalänkslagerprotokoll. Det rena Ethernet-protokollet stöder inte prioritetsfältet. På Ethernet-portar (Access Port) är därför endast intern (i förhållande till switchen) klassificering möjlig genom numret på den inkommande porten och det finns ingen markering.

En mer flexibel lösning är att använda IEEE 802.1P-standarden, som utvecklades i samband med 802.1Q. Hierarkin av relationer här är som följer: 802.1D beskriver bryggteknik och är grunden för 802.1Q och 802.1P. 802.1Q beskriver virtuell nätverksteknik (VLAN) och 802.1P tillhandahåller servicekvalitet. Generellt sett gör att aktivera 802.1Q-stöd (trunk med vilans) det automatiskt möjligt att använda 802.1P. Enligt standarden används 3 bitar i den andra nivåns header, som kallas Class of Service (CoS). Således kan CoS ta värden från 0 till 7.

3.1.2. Lager 3 Klassificering och märkning.

Routningsutrustning (Layer 3) arbetar med IP-paket, i vilka ett motsvarande fält i rubriken tillhandahålls för markeringsändamål - IP Type of Service (ToS) på en byte i storlek. ToS kan fyllas i med en IP-precedens eller DSCP-klassificerare beroende på uppgiften. IP-prioritet (IPP) har en dimension på 3 bitar (accepterar värden 0-7). DSCP är en DiffServ-modell och består av 6 bitar (värden 0-63).

Förutom digital form kan DSCP-värden uttryckas med hjälp av speciella nyckelord: BE - Best Effort, AF - Assured Forwarding och EF - Expedited Forwarding. Utöver dessa tre klasser finns det klassväljarkoder som läggs till i klassnotationen och är bakåtkompatibla med IPP. Till exempel kan ett DSCP-värde på 26 skrivas som AF31, vilket är helt ekvivalent.

MPLS innehåller en QoS-indikator inuti etiketten i motsvarande MPLS EXP-bitar (3 bitar).

Du kan markera IP-paket med ett QoS-värde på olika sätt: PBR, CAR, BGP.

Exempel 1: PBR-märkning

Policy Based Route (PBR) kan användas för markeringsändamål, göras i lämplig subrutin (Route-map kan innehålla en inställd ip-precedensparameter):

!
gränssnitt FastEthernet0/0
ip policy ruttkarta MARK
hastighet 100
full duplex
ingen cdp-aktivering
!
!
ruttkarta MARK-tillstånd 10
matcha ip-adress 1
ange ip-prioritet
!

Du kan se resultatet vid utgången av gränssnittet (till exempel genom att använda tcpdump-programmet på unix):

# tcpdump -vv -n -i em0
... IP (tos 0x20 ...)

Exempel 2: CAR-märkning.

Mekanismen för Committed Access Rate (CAR) är utformad för att begränsa hastigheten, men den kan dessutom markera paket (set-prec-transmit parameter i rate-limit):

!
gränssnitt FastEthernet0/0
IP-adress 192.168.0.2 255.255.255.252
rate-limit input access-group 1 1000000 10000 10000 conform-action set-prec-transmit 3 överskrida-action set-prec-transmit 3
ingen cdp-aktivering
!
åtkomstlista 1 tillstånd 192.168.0.0 0.0.0.255
!

#sh gränssnitt FastEthernet0/0 hastighetsgräns

3.2. Trängselhantering. Kömekanism.

3.2.1. Trängsel.

Överbelastning uppstår när utgångsbuffertarna för den utrustning som sänder trafik svämmar över. De huvudsakliga mekanismerna för uppkomsten av trängsel (eller, på motsvarande sätt, trängsel) är trafikaggregation (när hastigheten på inkommande trafik överstiger hastigheten för utgående trafik) och inkonsekvens av hastigheter på gränssnitt.

Bandbreddshantering vid överbelastning (flaskhalsar) utförs med hjälp av en kömekanism. Paketen placeras i köer som bearbetas på ett ordnat sätt enligt en specifik algoritm. I själva verket är överbelastningskontroll bestämningen av i vilken ordning paket lämnar gränssnittet (köerna) baserat på prioriteringar. Om det inte finns några överbelastningar fungerar inte köerna (och behövs inte). Låt oss lista metoderna för bearbetning av köer.

3.2.2. Lager 2 i kö.

Den fysiska strukturen för en klassisk switch kan förenklas på följande sätt: ett paket anländer till ingångsporten, bearbetas av omkopplingsmekanismen, som bestämmer vart paketet ska vidarebefordras, och hamnar i utgångsportens hårdvaruköer. Hårdvaruköer är snabbt minne, som lagrar paket innan de kommer direkt till utgångsporten. Därefter, enligt en viss bearbetningsmekanism, tas paket bort från köerna och lämnar switchen. Inledningsvis är köerna lika och det är köbehandlingsmekanismen (Scheduling) som bestämmer prioriteringen. Vanligtvis innehåller varje switchport ett begränsat antal köer: 2, 4, 8 och så vidare.

I översikt Prioritetsinställningen är som följer:

1. Inledningsvis är köerna lika. Därför är det först nödvändigt att konfigurera dem, det vill säga bestämma ordningen (eller proportionaliteten av volymen) för deras bearbetning. Det vanligaste sättet att göra detta är att binda 802.1P-prioriteringar till köer.

2. Det är nödvändigt att konfigurera köhanteraren (Scheduler). De vanligaste är Weighted Round Robin WRR eller Strict Priority Queuing.

3. Tilldela prioritet till inkommande paket: genom ingångsport, av CoS eller, i fallet med ytterligare funktioner (Layer 3 switch), av vissa IP-fält.

Det hela fungerar så här:

1. Paketet träffar switchen. Om detta är ett vanligt Ethernet-paket (klientåtkomstport) så har det inga prioritetsetiketter och dessa kan ställas in av switchen, till exempel av ingångsportnumret, om det behövs. Om ingångsporten är trunk (802.1Q eller ISL), kan paketet ha en prioritetsetikett och switchen kan acceptera den eller ersätta den med den nödvändiga. I vilket fall som helst har paketet i detta skede nått switchen och har den nödvändiga CoS-märkningen.

2. Efter bearbetning av omkopplingsprocessen sänds paketet i enlighet med CoS-prioritetsetiketten av klassificeraren (Klassifiera) till lämplig kö i utgångsporten. Till exempel går kritisk trafik in i en högprioriterad kö och mindre viktig trafik går in i en lågprioriterad kö.

3. Bearbetningsmekanismen (schemaläggning) hämtar paket från köer enligt deras prioriteringar. Fler paket kommer att skickas till utgångsporten från en högprioriterad kö per tidsenhet än från en lågprioriterad kö.

3.2.3. Lager 3 i kö.

Routningsenheter driver paket vid det tredje OSI-lagret (lager 3). Oftast tillhandahålls köstöd i programvara. Detta innebär, i de flesta fall, frånvaron av hårdvarubegränsningar för deras antal och mer flexibel konfiguration av bearbetningsmekanismer. Det allmänna QoS Layer 3-paradigmet inkluderar märkning och klassificering av paket vid ingången (Marking & Classification), distribution i köer och deras bearbetning (Scheduling) enligt vissa algoritmer.

Och låt oss återigen betona att prioritering (köer) huvudsakligen endast krävs på flaskhalsar, överbelastade platser, när kanalkapaciteten inte räcker till för att överföra alla inkommande paket och det är nödvändigt att på något sätt differentiera deras bearbetning. Dessutom är prioritering också nödvändig för att förhindra att skurar av nätverksaktivitet påverkar latenskänslig trafik.

Låt oss klassificera Layer 3 QoS enligt köbehandlingsmetoder.

3.2.3.1. FIFO.

En elementär kö med sekventiell passage av paket, som arbetar enligt First In First Out-principen (FIFO), som har den ryska motsvarigheten till först in först ut och tofflor. I huvudsak finns det ingen prioritering här. Aktiverad som standard på gränssnitt med hastigheter över 2 Mbit/s.

3.2.3.2. P.Q. Prioriterade köer.

Priority Queuing (PQ) ger ovillkorlig prioritet för vissa paket framför andra. Det finns totalt 4 köer: hög, medium, normal och låg. Behandlingen utförs sekventiellt (från hög till låg), startar med en högprioriterad kö och går inte vidare till lägre prioriterade köer förrän den är helt rensad. Således är det möjligt för kanalen att monopoliseras av högprioriterade köer. Trafik vars prioritet inte är explicit specificerad hamnar i standardkön.

Kommandoparametrar.
distribution av protokoll efter köer:
prioritetslista LIST_NUMBER protokoll PROTOKOLL(hög|medel|normal|låg) lista ACCESS_LIST_NUMBER
standardködefinition:
prioritetslista LIST_NUMBER standard (hög|medel|normal|låg)
bestämma köstorlekar (i paket):
prioritetslista LIST_NUMBER kögräns HIGH_QUEUE_SIZE MEDIUM_QUEUE_SIZE NORMAL_QUEUE_SIZE LOW_QUEUE_SIZE

beteckningar:
LIST_NUMBER – antal PQ-hanterare (ark)
PROTOKOLL - protokoll
ACCESS_LIST_NUMBER – åtkomstlistans nummer
HIGH_QUEUE_SIZE – köstorlek HIGH
MEDIUM_QUEUE_SIZE - MEDIUM köstorlek
NORMAL_QUEUE_SIZE - NORMAL köstorlek
LOW_QUEUE_SIZE - LÅG köstorlek

Inställningsalgoritm.

1. Definiera 4 köer
åtkomstlistan 110 tillåter ip vilket som helst prioritetsnätverk
åtkomstlistan 120 tillåter ip vilken som helst prioritet som helst
åtkomstlista 130 tillåter ip vilken som helst prioritet på internet
åtkomstlistan 140 tillåter ip vilken som helst prioritetsrutin

prioritetslista 1 protokoll ip hög lista 110
prioritetslista 1 protokoll ip medium lista 120
prioritetslista 1 protokoll ip normal lista 130
prioritetslista 1 protokoll ip låg lista 140
prioritetslista 1 standard låg

prioritetslista 1 kögräns 30 60 90 120

2. Länk till gränssnittet

!
gränssnitt FastEthernet0/0
IP-adress 192.168.0.2 255.255.255.0
hastighet 100
full duplex
prioritetsgrupp 1
ingen cdp-aktivering
!

3. Se resultatet
#sh köprioritet

Aktuell prioritetskökonfiguration:

Lista

Kö Args

låg

standard

hög

protokoll ip

lista 110

medium

protokoll ip

lista 120

vanligt

protokoll ip

lista 130

låg

protokoll ip

lista 140

#sh gränssnitt fastEthernet 0/0
…
Köstrategi: prioritetslista 1
…

Gränssnitt FastEthernet0/0 köstrategi: prioritet

hög/19 medel/0 normal/363 låg/0

3.2.3.3. C.Q. Slumpmässiga köer.

Custom Queuing (CQ) tillhandahåller anpassade köer. Ger kontroll över andelen kanalbandbredd för varje kö. 17 köer stöds. Systemkö 0 är reserverad för högprioriterade kontrollpaket (routing, etc.) och är inte tillgänglig för användaren.

Köerna korsas sekventiellt, med början från den första. Varje kö innehåller en byte-räknare, som i början av genomgången innehåller satt värde och reduceras med storleken på paketet som hoppades över från denna kö. Om räknaren inte är noll, hoppas nästa paket över som en helhet och inte dess fragment lika med resten av räknaren.

Kommandoparametrar.
bestämning av köbandbredd:
kölista LIST-NUMBER kö QUEUE_NUMBER byte-antal
BYTE_COUT

bestämma köstorlekar:
kölista LIST-NUMBER kö QUEUE_NUMBER gräns QUEUE_SIZE

beteckningar:
LIST-NUMMER – hanterarnummer
QUEUE_NUMBER – könummer
BYTE_COUT – köstorlek i paket

Inställningsalgoritm.

1. Definiera köer
åtkomstlista 110 tillåter ip-värd 192.168.0.100 någon
åtkomstlista 120 tillåter ip-värd 192.168.0.200 någon

kölista 1 protokoll ip 1 lista 110
kölista 1 protokoll ip 2 lista 120
kölista 1 standard 3

kölista 1 kö 1 byteantal 3000
kölista 1 kö 2 byte-antal 1500
kölista 1 kö 3 byte-antal 1000

Dessutom kan du ställa in köstorlekar i omgångar
kölista 1 kö 1 gräns 50
kölista 1 kö 2 gräns 50
kölista 1 kö 3 gräns 50

2. Länkar till gränssnittet
!
gränssnitt FastEthernet0/0
IP-adress 192.168.0.2 255.255.255.0
hastighet 100
full duplex
anpassad kölista 1
ingen cdp-aktivering
!

3. Visa resultat
#sh kö anpassad

Aktuell anpassad kökonfiguration:

Lista

Kö

Args

standard

protokoll ip

lista 110

protokoll ip

lista 120

byte-antal 1000

byte-antal 2000

#sh gränssnitt FastEthernet0/0
…
Köstrategi: anpassad lista 1
…

#sh kögränssnitt fastEthernet 0/0
Gränssnitt FastEthernet0/0 köstrategi: anpassad

Utgångsköanvändning (kö/antal)
0/90 1/0 2/364 3/0 4/0 5/0 6/0 7/0 8/0
9/0 10/0 11/0 12/0 13/0 14/0 15/0 16/0

3.2.3.4. WFQ. Viktade rättvisa köer.

Weighted Fair Queuing (WFQ) delar automatiskt upp trafiken i flöden. Som standard är deras antal 256, men kan ändras (dynamic-queues-parametern i fair-queue-kommandot). Om det finns fler trådar än köer, placeras flera trådar i en kö. Ett pakets flödesmedlemskap (klassificering) bestäms baserat på TOS, protokoll, käll-IP-adress, destinations-IP-adress, källport och destinationsport. Varje tråd använder en separat kö.

WFQ-hanteraren (schemaläggaren) ger en rättvis uppdelning av bandbredden mellan befintliga trådar. För att göra detta delas den tillgängliga bandbredden med antalet trådar och var och en får en lika stor del. Dessutom får varje tråd sin egen vikt, med en viss koefficient omvänt proportionell mot IP-prioriteten (TOS). Trådens vikt beaktas också av hanteraren.

Som ett resultat fördelar WFQ automatiskt den tillgängliga bandbredden rättvist, med hänsyn till TOS dessutom. Flöden med samma IP TOS-prioriteringar kommer att få lika andelar av bandbredden; flöden med hög IP-prioritet – en större andel av bandbredden. Vid överbelastning fungerar obelastade högprioriterade trådar utan förändringar, och lågprioriterade högbelastningsgängor är begränsade.

RSVP arbetar tillsammans med WFQ. Som standard är WFQ aktiverat på låghastighetsgränssnitt.

Inställningsalgoritm.
1. Vi markerar trafiken på något sätt (vi ställer in IP-prioritet - TOS) eller tar emot den markerad

2. Aktivera WFQ på gränssnittet
gränssnitt FastEthernet0/0
rättvis-kö

gränssnitt FastEthernet0/0
rättvis kö CONGESTIVE_DISCARD_THRESHOLD DYNAMIC_QUEUES

Alternativ:
CONGESTIVE_DISCARD_THRESHOLD – antalet paket i varje kö, om det överskrids ignoreras paket (standard - 64)
DYNAMIC_QUEUES – antal underköer som trafik klassificeras i (standard - 256)

3. Se resultatet
#sh kömässa
# sh kögränssnitt FastEthernet0/0

3.2.3.5. CBWFQ.

Class Based Weighted Fair Queuing (CBWFQ) motsvarar en klassbaserad kömekanism. All trafik är uppdelad i 64 klasser baserat på följande parametrar: ingångsgränssnitt, åtkomstlista, protokoll, DSCP-värde, MPLS QoS-etikett.

Den totala bandbredden för utgående gränssnitt är fördelad över klasser. Bandbredden som allokeras till varje klass kan bestämmas antingen som ett absolut värde (bandbredd i kbit/s) eller som en procentandel (bandbreddsprocent) i förhållande till det värde som är inställt på gränssnittet.

Paket som inte faller in i de konfigurerade klasserna hamnar i en standardklass, som kan konfigureras ytterligare och som får den återstående lediga kanalbandbredden. Om kön för någon klass är full, ignoreras paket av den klassen. Algoritmen för att avvisa paket inom varje klass kan väljas: normal släppning är aktiverad som standard (tail-drop, queue-limit parameter) eller WRED (random-detect parameter). Endast för standardklassen kan du aktivera enhetlig (rättvis) remsordelning (fair-queue parameter).

CBWFQ stöder interoperabilitet med RSVP.

Kommandoparametrar.

kriterier för att välja paket efter klass:
klass-karta matcha-alla KLASS
matcha åtkomstgrupp
matcha ingångsgränssnitt
matchprotokoll
matcha ip dscp
matcha ip rtp
matcha mpls experimentell

klassdefinition:

klass KLASS
bandbredd BANDBREDD
queue-limit QUEUE-LIMIT
slumpmässigt upptäcka

standardklassdefinition:

klass klass-standard
bandbredd BANDBREDD
bandbreddsprocent BANDWIDTH_PERCENT
queue-limit QUEUE-LIMIT
slumpmässigt upptäcka
rättvis-kö

beteckningar:
KLASS – klassnamn.
BANDBREDD – minsta kbit/s band, värdet är oberoende av bandbredden på gränssnittet.
BANDWIDTH_PERCENT - procent av bandbredden på gränssnittet.
QUEUE-LIMIT – maximalt antal paket i kön.
random-detect - använd WRED.
fair-queue – enhetlig uppdelning av remsan, endast för standardklassen

Som standard kan det absoluta bandbreddsvärdet i klassen CBWFQ inte överstiga 75 % av bandbreddsvärdet på gränssnittet. Detta kan ändras med kommandot max-reserved-bandwidth på gränssnittet.

Inställningsalgoritm.

1. Fördelning av paket efter klass - klasskarta

klass-karta matcha-alla Klass1
match åtkomstgrupp 101

2. Beskrivning av reglerna för varje klass - policy-map
policy-karta Policy1
klass Klass 1
bandbredd 100
kögräns 20
klass klass-standard
bandbredd 50
slumpmässigt upptäcka

3. Starta den angivna policyn på gränssnittet - service-policy
gränssnitt FastEthernet0/0
bandbredd 256

4. Se resultatet
#sh klass Klass1
#sh policy Policy1
#sh policygränssnitt FastEthernet0/0

Exempel 1.

Dela det totala bandet efter klass i procent (40, 30, 20).
åtkomstlista 101 tillåter ip-värd 192.168.0.10 någon
åtkomstlista 102 tillåter ip-värd 192.168.0.20 någon
åtkomstlista 103 tillåter ip-värd 192.168.0.30 någon

klass-karta matcha-alla Platinum
match åtkomstgrupp 101
klass-karta matcha-allt guld
match åtkomstgrupp 102
klass-karta match-all Silver
match åtkomstgrupp 103

policy-karta Isp
klass platina
bandbreddsprocent 40
klass guld
bandbreddsprocent 30
klass Silver
bandbreddsprocent 20

gränssnitt FastEthernet0/0
bandbredd 256
service-policy output Isp

3.2.3.6. LLQ.

Low Latency Queuing (LLQ) – låg latenskö. LLQ kan ses som en CBWFQ-mekanism med en PQ-prioritetskö (LLQ = PQ + CBWFQ).
PQ i LLQ möjliggör service av latenskänslig trafik. LLQ rekommenderas när det finns rösttrafik (VoIP). Dessutom fungerar det bra med videokonferenser.

Inställningsalgoritm.

1. Fördelning av paket efter klass - Klasskarta
åtkomstlistan 101 tillåter ip vilken som helst kritisk prioritet

klass-karta matcha-all Voice
matcha ip-prioritet 6
klass-karta matcha-alla Klass1
match åtkomstgrupp 101

2. Beskrivning av reglerna för varje klass - Policy-map

I likhet med CBWFQ, endast för prioritetsklassen (det finns bara en) anges prioritetsparametern.
policy-karta Policy1
klass Röst
prioritet 1000
klass Klass 1
bandbredd 100
kögräns 20
klass klass-standard
bandbredd 50
slumpmässigt upptäcka

3. Starta den angivna policyn på gränssnittet - Service-policy
gränssnitt FastEthernet0/0
bandbredd 256
servicepolicy output Policy1

Exempel 1.
Vi tilldelar Voice-klassen till PQ och allt annat till CQWFQ.
!
klass-karta matcha-valfri röst
matcha ip-prioritet 5
!
policy-map Voice
klass Röst
prioritet 1000
klass VPN
bandbreddsprocent 50
klass klass-standard
rättvis kö 16
!
gränssnitt X
Servicepolicyutgång Röst
!

Exempel 2.
Dessutom begränsar vi total hastighet för PQ till LLQ så att den inte monopoliserar hela kanalen vid felaktig drift.
!
klass-karta matcha-valfri röst
matcha ip-prioritet 5
!
policy-map Voice
klass Röst
prioritet 1000
polisen 1024000 32000 32000 överensstämma-åtgärd sända överskrida åtgärd fall
klass VPN
bandbreddsprocent 50
klass klass-standard
rättvis kö 16
!
gränssnitt FastEthernet0/0
servicepolicy output Röst
!

Material från Nationalbiblioteket. N. E. Bauman
Senast ändrad av denna sida: 16:35, 3 juli 2017.

Service kvalitet (QoS- tjänstens kvalitet) är ett kvalitativt mått på prestandan hos ett nätverk (till exempel telefon eller dator) som observeras av dess användare. Oftast kännetecknas mätningar av nätverkets kvalitet på tjänsten av följande parametrar:

frekvens av fel eller misslyckanden
baudhastighet
dataöverföringsfördröjning
kommunikationskanalkapacitet
nätverkstillgänglighet

I området dator nätverk och andra paketnätverk säkerställs tjänstens kvalitet genom att använda trafikprioritering och pakethanteringsalgoritmer. I det här fallet är tjänstekvalitet förmågan att ge olika prioritet åt olika applikationer, användare eller data, och att garantera en viss prestandanivå för en dataström.

Funktionsmekanism

Kretskopplade nätverk tillhandahåller QoS i sitt underliggande protokoll. Sådana nätverk behöver inte ytterligare metoder för att uppnå hög kvalitet.

I fall där QoS är ett kärnverksamhetskrav, nätverksklienter och leverantörer kan ingå ett avtal som kallas ett servicenivåavtal (SLA) som garanterar ett nätverks eller protokolls förmåga att leverera den angivna prestandan och genomströmningen, vanligtvis genom mekanismer för trafikprioritering. Det finns andra tillvägagångssätt för att tillhandahålla QoS, när resurser är reserverade på varje nätverksnod.

Överkapacitet

Ett alternativ till komplexa QoS-kontrollmekanismer är att säkerställa högkvalitativ kommunikation genom att tillhandahålla redundant nätverkskapacitet. Nätverkskapaciteten baseras således på uppskattningar av maximal nätbelastning. Detta tillvägagångssätt är enkelt för nätverk med förutsägbara toppbelastningar.

Nätverksprestanda är en kritisk faktor för många applikationer. Vissa kan kompensera för bandbreddsfluktuationer och latens genom att använda stora mottagningsbuffertar, vilket ofta är möjligt med till exempel videostreaming. Överkapacitet har dock en skalningsgräns under transportprotokoll (som TCP) som exponentiellt ökar mängden data över tiden tills all bandbredd används och paket tappas. Sådana giriga protokoll tenderar att öka nätverkslatensen och kan förlora paket för alla användare.

I praktiken, när ett paket måste vidarebefordras från ett köat gränssnitt, ges paket som kräver lågt jitter (som VoIP) prioritet framför paket i andra köer. Vanligtvis allokeras vissa dataflöden till nätverkskontrollpaket som standard, medan trafik med högsta prioritet helt enkelt kan överföras med vilken bandbredd som helst.

Ett övertygande exempel på behovet av QoS på Internet relaterar till kollisioner. Internet använder protokoll för att undvika överbelastning som är inbyggda i TCP för att minska trafiken. Höga QoS-applikationer som VoIP och IPTV kräver konstanta bithastigheter och låg latens, så de kan inte använda TCP och kan inte strypa trafiken för att förhindra överbelastning. QoS-mekanismer begränsar trafiken som kan nås på Internet och ger därigenom kontroll över trafik som kan orsaka trafikstockningar, och är därför integrerade i Internets förmåga att hantera blandad trafik i realtid utan trängsel.

Protokoll och metoder

Typ av tjänst (ToS)-fältet i IPv4-huvudet (nu ersatt av DiffServ)
Differentierade tjänster (DiffServ)
Integrerade tjänster (IntServ)
Resource Reservation Protocol (RSVP)
Multi-Protocol Label Switching (MPLS) ger 8 QoS-klasser av tjänster
OSA-TE
Ramrelä
Vissa ADSL-modem
Asynkront överföringsläge (ATM)
IEEE 802.1p
IEEE 802.1Q
IEEE 802.11e
Hemnätverk över koaxial- och telefonledningar (HomePNA)
ITU-T G.hn-standarden tillhandahåller QoS genom "constraint-free forwarding capabilities" (CFTXOPs), som allokeras till flöden som kräver QoS och som har förhandlat fram ett "kontrakt" med nätverksstyrenheten. G.hn stöder också QoS-fri drift med hjälp av "konfliktbaserade tidsluckor."
Audio-video kommunikation

Exempel på tekniker som kräver hög QoS

Hög kvalitet på tjänsten är ett nödvändigt krav för vissa typer av nätverkstrafik, till exempel:

Strömmande media
- Audio
Videokonferenser
Applikationer som ger systemstabilitet eller återställning
Dynamiska onlinespel i realtid

För att ovanstående tjänster ska fungera är det nödvändigt att säkerställa en lägsta dataöverföringshastighet och maximal latens.

Öva

All prioritering är meningsfull endast när det är kö till service. Det är där, i kön, som du kan gå först med din högra sida. Kön bildas där den är smal (vanligtvis kallas sådana platser för "flaskhals", flaskhals). En typisk flaskhals är en internetanslutning på kontoret, där datorer som är anslutna till nätverket med en hastighet av minst 100 Mbit/sek alla använder en kanal till leverantören, som sällan överstiger 100 Mbit/sek och ofta uppgår till ynka 1-2 -10 Mbit/sek. För alla.

QoS är inte ett universalmedel: om "halsen" är för smal, svämmar ofta den fysiska bufferten i gränssnittet över, där alla paket som kommer att gå ut genom detta gränssnitt placeras. Och då kommer nyinkomna paket att förstöras, även om de är superbehövliga. Därför, om kön på ett gränssnitt i genomsnitt överstiger 20 % av dess maximala storlek (på Cisco-routrar är den maximala köstorleken vanligtvis 128-256 paket), finns det anledning att tänka ordentligt över utformningen av ditt nätverk, lägga ytterligare rutter eller utöka bandbredden till leverantören.

Låt oss titta på komponenterna i tekniken.

Märkning

I rubrikfälten för olika nätverksprotokoll (Ethernet, IP, ATM, MPLS, etc.) finns speciella fält tilldelade för trafikmarkering. Trafiken behöver markeras för efterföljande enklare hantering i köer.

Ethernet. Class of Service (CoS)-fält - 3 bitar. Låter dig dela upp trafiken i 8 strömmar med olika markeringar

IP. Det finns 2 standarder: gamla och nya. Den gamla hade ett ToS-fält (8 bitar), från vilket 3 bitar som kallas IP Precedence i sin tur tilldelades. Detta fält kopierades till CoS Ethernet-huvudfältet. Senare definierades en ny standard. ToS-fältet har döpts om till DiffServ, och ytterligare 6 bitar har tilldelats för fältet Differential Service Code Point (DSCP), där det krävs av denna typ trafikparametrar.

Det är bäst att märka data nära datakällan. Av denna anledning lägger de flesta IP-telefoner självständigt till fältet DSCP = EF eller CS5 till IP-huvudet för röstpaket. Många applikationer markerar också trafik själva i hopp om att deras paket ska behandlas med prioritet. Till exempel är peer-to-peer-nätverk skyldiga till detta.

Köer

Även om inga prioriteringstekniker används betyder det inte att köer inte uppstår. Vid en flaskhals kommer en kö att uppstå i alla fall och kommer att tillhandahålla en standard FIFO-mekanism (First In First Out). En sådan kö kommer uppenbarligen att göra det möjligt att inte förstöra paket omedelbart, lagra dem i en buffert innan de skickas, men det kommer inte att ge några preferenser, till exempel, för rösttrafik. Om du behöver ge absolut prioritet till någon utvald klass (det vill säga, paket från denna klass kommer alltid att bearbetas först), så kallas denna teknik för Priority queuing. Alla paket i den fysiska utgående bufferten i gränssnittet kommer att delas upp i 2 logiska köer och paket från den privilegierade kön kommer att skickas tills den är tom. Först efter detta kommer paket från den andra kön att börja sändas. Denna teknik är enkel, ganska grov och kan anses föråldrad, eftersom... bearbetning av oprioriterad trafik kommer ständigt att stoppas. På Cisco-routrar kan du skapa 4 köer med olika prioriteringar. De upprätthåller en strikt hierarki: paket från mindre privilegierade köer kommer inte att betjänas förrän alla köer med högre prioritet är tomma. Rättvis köande. En teknik som gör att varje trafikklass kan ges samma rättigheter. Som regel används det inte, eftersom gör lite när det gäller att förbättra kvaliteten på tjänsterna. Weighted Fair Queuing (WFQ). En teknik som ger olika trafikklasser olika rättigheter (vi kan säga att "vikten" på olika köer är olika), men samtidigt servar alla köer. Alla paket är uppdelade i logiska köer med fältet IP Precedence som kriterium. Samma fält anger också prioritet (ju fler, desto bättre). Därefter beräknar routern vilket paket som är "snabbare" att sända från vilken kö och sänder det exakt.

Han beräknar detta med formeln:

D T = (t (i) − t (0)) / (1 + I P P) (\displaystyle dT=(t(i)-t(0))/(1+IPP))

IPP - värdet av IP Precedence-fältet t(i) - Den tid som krävs för den faktiska överföringen av ett paket av gränssnittet. Kan beräknas som L/Speed, där L är paketlängden och Speed är gränssnittets överföringshastighet.

Denna kö är aktiverad som standard på alla Cisco-routrars gränssnitt, förutom punkt-till-punkt-gränssnitt (HDLC- eller PPP-inkapsling). WFQ har ett antal nackdelar: sådan köning använder tidigare markerade paket och tillåter dig inte att självständigt bestämma trafikklasser och allokerad bandbredd. Dessutom är det i regel ingen som markerar med IP Precedence-fältet längre, så paketen blir omarkerade, d.v.s. alla hamnar i samma kö. En utveckling av WFQ var Class-Based Weighted Fair Queuing (CBWFQ). I denna kö definierar administratören själv trafikklasser, efter olika kriterier, till exempel att använda ACL som mall eller analysera protokollhuvuden (NBAR). Därefter bestäms "vikten" för dessa klasser och paketen i deras köer betjänas i proportion till vikten (mer vikt - fler paket från denna kö kommer att gå ut per tidsenhet). Men en sådan kö säkerställer inte strikt passagen av de viktigaste paketen (vanligtvis röst eller paket från andra interaktiva applikationer). Därför dök en hybrid av Priority och Class-Based Weighted Fair Queuing upp - PQ-CBWFQ, även känd som Low Latency Queuing (LLQ). I den här tekniken kan du ställa in upp till 4 prioriterade köer, de återstående klasserna kan betjänas med hjälp av CBWFQ-mekanismen. LLQ är den mest bekväma, flexibla och mest använda mekanismen. Men det kräver att du ställer in klasser, ställer in policyer och tillämpar policyer på gränssnittet. Således kan processen att tillhandahålla kvalitetsservice delas in i två steg:

Märkning. Närmare källorna.
Paketbearbetning. Att sätta dem i en fysisk kö på gränssnittet, dela upp dem i logiska köer och ge de logiska köerna olika resurser.

QoS-tekniken är ganska resurskrävande och belastar processorn ganska rejält. Och ju mer den laddas, desto djupare in i rubrikerna måste du gå för att klassificera paketen. Som jämförelse: det är mycket lättare för en router att titta på IP-pakethuvudet och analysera de 3 IPP-bitarna där, snarare än att snurra upp flödet nästan till applikationsnivån och avgöra vilken typ av protokoll som finns inuti (NBAR-teknik). För att förenkla ytterligare trafikbearbetning, samt skapa en så kallad "trusted boundary", där vi litar på alla QoS-relaterade headers, kan vi göra följande: 1. På accesslagerswitchar och routrar (nära klientdatorer) fångas paket, sortera dem i klasser 2. I policyn, som en åtgärd, färga om rubrikerna på ditt eget sätt eller överför värdena för QoS-rubrikerna mer hög nivå till de lägre.

Till exempel på en router fångar vi alla paket från gäst WiFi domän (vi antar att det kan finnas datorer och mjukvara som vi inte hanterar som kan använda icke-standardiserade QoS-rubriker), vi ändrar eventuella IP-rubriker till initiala, vi matchar länklagerhuvudena (CoS) med 3:e nivåns rubriker ( DSCP), så att ytterligare switchar effektivt kan prioritera trafik med endast länklageretiketten.

Konfigurera LLQ

Att sätta upp köer innebär att sätta upp klasser, sedan för dessa klasser måste du bestämma bandbreddsparametrarna och tillämpa hela den skapade designen på gränssnittet. Skapa klasser:

klass-karta NAMN matchning? åtkomstgrupp Åtkomstgrupp valfri Alla paketklass - map Klasskarta cos IEEE 802.1 Q/ ISL tjänsteklass/ användarprioritetsvärden destination- adress Destinationsadress förkasta- klass Kasta beteendeidentifierare dscp Matcha DSCP i IP(v4) och IPv6-paket flöde Flödesbaserade QoS-parametrar fr- de Matcha på Frame-relä DE bit fr- dlci Matcha på fr-dlci input-interface Välj ett ingångsgränssnitt för att matcha ip IP-specifika värden mpls Multi Protocol Label Switching specific values not Negate this matcha paketresultat Lager 3 Paketlängdsprioritet Matcha prioritet i IP(v4) och IPv6-paketprotokoll Protokoll qos- grupp Qos- gruppkälla - adress Källadress vlan VLAN att matcha

Paket i klasser kan sorteras efter olika attribut, till exempel genom att ange en ACL som en mall, eller genom DSCP-fältet, eller genom att markera ett specifikt protokoll (NBAR-teknik är aktiverad).

Skapa en policy:

policy-karta POLICY klass NAMN1? bandbredd Bandbreddskomprimering Aktivera Kompressionsfall Släpp alla paketlogg Logga IPv4- och ARP-paket netflow- sampler NetFlow-åtgärdspolis Polisprioritet Strikt schemaläggning Prioritet för denna klass kö-gräns Kö Max tröskel för Tail Drop slumpmässigt- detektera Aktivera slumpmässig tidig upptäckt som släpppolicytjänst- policy Konfigurera flöde Nästa set Ange QoS-värden form Traffic Shaping

För varje klass i policyn kan du antingen tilldela en prioriterad del av remsan:

policy-karta POLICY klass NAMN1 prioritet? [ 8-2000000 ] Kilo Bits per sekund procent % av total bandbredd

och då kan paket av denna klass alltid räkna med åtminstone denna bit.

Eller beskriv vilken "vikt" denna klass har inom CBWFQ

policy-karta POLICY klass NAMN1 bandbredd? [ 8-2000000 ] Kilo bitar per sekund procent % av total bandbredd återstående % av återstående bandbredd

I båda fallen kan du ange både ett absolut värde och en procentandel av hela den tillgängliga bandbredden. En rimlig fråga uppstår: hur känner routern till HELA bandet? Svaret är enkelt: från bandbreddsparametern på gränssnittet. Även om det inte är explicit konfigurerat måste det ha någon betydelse. Du kan se den med kommandot sh int. Det är också nödvändigt att komma ihåg att du som standard inte kontrollerar hela randen, utan bara 75%. Paket som inte uttryckligen ingår i andra klasser hamnar i class-default. Den här inställningen för standardklassen kan ställas in explicit

policy-map POLICY-klassklass - standardbandbreddsprocent 10

Du kan ändra den maximala tillgängliga bandbredden från standard 75 % med kommandot i gränssnittet: max-reserved-bandwidth

Routrar ser till att administratören inte av misstag ger ut mer bandbredd än vad det finns och svär över sådana försök. Det verkar som att policyn inte kommer att ge mer till klasser än vad som är skrivet. Denna situation kommer dock bara att inträffa om alla köer är fulla. Om en är tom, kommer körfältet som tilldelats den att delas med de fyllda köerna i proportion till dess "vikt". Hela den här designen kommer att fungera så här: om det finns paket från klassen som anger prioritet, fokuserar routern på att överföra dessa paket. Dessutom eftersom Det kan finnas flera sådana prioritetsköer, sedan delas bandbredden mellan dem i proportion till de angivna procenttalen. När alla prioritetspaket är borta är det CBWFQ:s tur. För varje tidsräkning "scoopes" andelen paket som anges i inställningen för denna klass från varje kö. Om några av köerna är tomma, delas deras bandbredd i proportion till klassens "vikt" mellan de laddade köerna.

Applikation på gränssnittet:

int s0/ 0 servicepolicy [ingång| output]POLICY

Men vad ska du göra om du strikt behöver skära ner paket från en klass som överskrider den tillåtna hastigheten? När allt kommer omkring, ange bandbredd fördelar bara bandbredd mellan klasser när köerna är upptagna. För att lösa detta problem för trafikklassen i politiken finns det en teknik

polis [ hastighet ] [ birst ] överensstämmelse- åtgärd [ åtgärd ] överskridande åtgärd [ åtgärd ]

det låter dig uttryckligen ange önskad medelhastighet (hastighet), den maximala "översvängningen", dvs. mängden data som överförs per tidsenhet. Ju större översvängning, desto mer kan den faktiska överföringshastigheten avvika från det önskade genomsnittet. Indikeras också: en åtgärd för normal trafik som inte överstiger angiven hastighet och en åtgärd för trafik som överstiger medelhastigheten. Åtgärder kan vara så här

polis 100000 8000 överensstämmelse- åtgärd? släpp släpp paketöverskridande åtgärd när hastigheten är inom överensstämmelse och överensstämmer + överskrid burst set- clp- sänd set atm clp och skicka det set- discard- class - transmit set discard- klass och skicka det set- dscp- överför set dscp och skicka det set- frde- sänd set FR DE och skicka det set- mpls- exp - imposition- överför set exp vid taggpåläggning och skicka det set- mpls- exp - överst- överför set exp på översta etiketten och skicka det set- prec - sänd omskrivning av paketföreträde och skicka det set- qos- sänd set qos- grupp och skicka det sända sändningspaket

Ofta dyker också en annan utmaning upp. Låt oss anta att vi behöver begränsa flödet som går mot en granne med en långsam kanal.

För att exakt förutsäga vilka paket som kommer att nå grannen och vilka som kommer att förstöras på grund av kanalöverbelastning på den "långsamma" sidan, är det nödvändigt att skapa en policy på den "snabba" sidan som skulle behandla köer i förväg och förstöra redundanta paket . Och här står vi inför en mycket viktig sak: för att lösa detta problem måste vi efterlikna en "långsam" kanal. För denna emulering är det inte tillräckligt att bara distribuera paket i köer, du behöver också emulera den fysiska bufferten för det "långsamma" gränssnittet. Varje gränssnitt har en paketöverföringshastighet. De där. Varje gränssnitt kan inte överföra mer än N paket per tidsenhet. Vanligtvis är den fysiska gränssnittsbufferten utformad för att säkerställa "autonom" drift av gränssnittet under flera tidsenheter. Därför kommer den fysiska bufferten att vara tiotals gånger större än något seriellt gränssnitt.

Vad är det för fel med att komma ihåg mycket? Låt oss titta närmare på vad som kommer att hända om bufferten på den snabba sändande sidan är betydligt större än den mottagande bufferten. För enkelhetens skull, låt det vara 1 kö. På den "snabba" sidan simulerar vi en låg överföringshastighet. Detta innebär att paket som faller under vår policy kommer att börja samlas i kön. Därför att Eftersom den fysiska bufferten är stor blir den logiska kön imponerande. Vissa applikationer (fungerar via TCP) kommer att få ett sent meddelande om att vissa paket inte har tagits emot och kommer att hålla fönsterstorleken stor under lång tid, vilket laddar mottagningssidan. Detta kommer att hända i det ideala fallet när överföringshastigheten är lika med eller lägre än mottagningshastigheten. Men gränssnittet för den mottagande sidan kan i sig laddas med andra paket, och då kommer den lilla kön på den mottagande sidan inte att kunna ta emot alla paket som sänds till den från centrum. Förluster kommer att börja, vilket kommer att medföra ytterligare överföringar, men i sändningsbufferten kommer det fortfarande att finnas en solid "svans" av tidigare ackumulerade paket som kommer att överföras "tomgång", eftersom den mottagande sidan väntade inte på det tidigare paketet, vilket betyder att senare helt enkelt kommer att ignoreras.

Därför, för att korrekt lösa problemet med att minska överföringshastigheten till en långsam granne, måste den fysiska bufferten också begränsas. Detta görs av ett team

formmedelvärde [hastighet]

Tja, nu är det mest intressanta: tänk om jag, förutom att emulera en fysisk buffert, behöver skapa logiska köer inuti den? Till exempel prioritera röst? För detta skapas en så kallad kapslad policy, som appliceras inuti den huvudsakliga och delar upp i logiska köer vad som kommer in i den från den överordnade. Det är dags att titta på något coolt exempel baserat på bilden ovan. Låt oss säga att vi kommer att skapa stabila röstkanaler över Internet mellan CO och Remote. För enkelhets skull, låt fjärrnätverket (172.16.1.0/24) endast ha kommunikation med CO (10.0.0.0/8). Gränssnittshastigheten på Remote är 1 Mbit/s och 25 % av denna hastighet är allokerad för rösttrafik. Sedan måste vi först välja en prioriterad trafikklass på båda sidor och skapa en policy för denna klass. På CO kommer vi dessutom att skapa en klass som beskriver trafik mellan kontor på CO:

klass - map RTP match protocol rtp policy- map RTP klass RTP prioritetsprocent 25 ip access- lista utökad CO_REMOTE tillstånd ip 10.0.0.0 0.255.255.255 172.16.1.0 0.0.0.255 klass - map CO_REMOTE match access-lista

På Remote kommer vi att göra saker annorlunda: även om vi inte kan använda NBAR på grund av svag hårdvara, kan vi bara explicit beskriva portarna för RTP

ip-åtkomstlista utökad RTP-tillåtelse udp 172.16.1.0 0.0.0.255 intervall 16384 32768 10.0.0.0 0.255.255.255 intervall 16384 32768 klass - karta RTP matcha åtkomst- lista RTP klass policy- karta 5 karta Qo procent

policy-karta QoS-klass CO_REMOTE form genomsnitt 1000000 service-policy RTP

och tillämpa policyn på gränssnittet

int g0/ 0 servicepolicy output QoS

På Remote, ställ in bandbreddsparametern (i kbit/sek) för att matcha gränssnittshastigheten. Låt mig påminna dig om att det är från denna parameter som 25 % kommer att beaktas. Och tillämpa policyn.

int s0/ 0 bandbredd 1000 servicepolicy output QoS

1. Samla statistik om nätverkstrafik. Antingen via NetFlow, eller NBAR eller SNMP. 2. Vi identifierar profilen för normal trafik, d.v.s. Enligt statistik tar HTTP-protokollet (Hypertext Transfer Protocol) i genomsnitt inte upp mer än 70%, ICMP - inte mer än 5%, etc. En sådan profil kan antingen skapas manuellt eller genom att använda statistiken som samlas in av NBAR. Dessutom kan du till och med automatiskt skapa klasser, policyer och tillämpa dem på gränssnittet med autoqos-kommandot. 3. Därefter kan du begränsa bandbredden för atypisk nätverkstrafik. Om vi plötsligt drabbas av en infektion icke-standardport, kommer det inte att vara några större problem för gatewayen: på ett upptaget gränssnitt kommer infektionen inte att uppta mer än den tilldelade delen. 4. Genom att skapa en design (class-map - policy-map - service-policy) kan du snabbt svara på uppkomsten av en atypisk ökning av trafiken genom att manuellt skapa en klass för den och kraftigt begränsa bandbredden för denna klass.

Det finns inte en enda person som inte minst en gång har läst några vanliga frågor om Windows XP. Och om så är fallet, då vet alla att det finns en sådan skadlig Quality of Service-tjänst - QoS för kort. Det rekommenderas starkt att inaktivera det när du konfigurerar ditt system eftersom det begränsar nätverkets bandbredd med 20 % som standard, och det här problemet verkar finnas i Windows 2000 också.

Dessa är raderna:

"F: Hur inaktiverar man tjänsten QoS (Quality of Service) helt? Hur konfigurerar man den? Är det sant att det begränsar nätverkshastigheten?
S: Som standard reserverar Quality of Service faktiskt 20 % av kanalkapaciteten för sina behov (vilken som helst kanal - även ett 14400-modem, till och med ett gigabit Ethernet). Dessutom, även om du tar bort QoS Packet Scheduler-tjänsten från Properties-anslutningen, släpps inte denna kanal. Du kan frigöra en kanal eller helt enkelt konfigurera QoS här. Starta grupprincipappleten (gpedit.msc). I Grupprincip, hitta Lokal datorpolicy och klicka på Administrativa mallar. Välj Nätverk - QoS Packet Sheduler. Aktivera Begränsa reserverbar bandbredd. Nu sänker vi bandbreddsgränsen 20 % till 0 % eller stänger helt enkelt av den. Om så önskas kan du även konfigurera andra QoS-parametrar här. För att aktivera de ändringar som gjorts behöver du bara starta om."
20% är förstås mycket. Microsoft är verkligen Mazda. Påståenden av det här slaget vandrar från FAQ till FAQ, från forum till forum, från media till media och används i alla typer av "tweaks" - program för att "tuna" Windows XP (öppna förresten "Group Policies" och " Lokal policy säkerhet", och inte en enda "tweak" kan jämföras med dem när det gäller rikedomen av konfigurationsalternativ). Ounderbyggda uttalanden av detta slag måste exponeras noggrant, vilket vi nu kommer att göra genom att tillämpa ett systematiskt tillvägagångssätt. Det vill säga, vi kommer att studera den problematiska frågan grundligt, med hjälp av officiella primära källor.

Vad är ett nätverk med kvalitetsservice?

Låt oss acceptera följande förenklade definition nätverkssystem. Applikationer körs och körs på värdar och kommunicerar med varandra. Applikationer skickar data till operativsystemet för överföring över nätverket. När data väl har överförts till operativsystemet blir det nätverkstrafik.
Nätverkstjänst QoS förlitar sig på nätverkets förmåga att bearbeta denna trafik på ett sätt som säkerställer att vissa applikationsförfrågningar uppfylls. Detta kräver en grundläggande mekanism för att behandla nätverkstrafik som kan identifiera trafik som är berättigad till särskild behandling och rätten att kontrollera dessa mekanismer.

QoS-funktionalitet är utformad för att tillfredsställa två nätverksenheter: nätverksapplikationer och nätverksadministratörer. De är ofta oense. Nätverksadministratören begränsar resurserna som används av en specifik applikation, samtidigt som applikationen försöker ta så många nätverksresurser som möjligt. Deras intressen kan samordnas, med hänsyn till att nätverksadministratören spelar en dominerande roll i förhållande till alla applikationer och användare.

Grundläggande QoS-parametrar

Olika applikationer har olika krav för att bearbeta deras nätverkstrafik. Applikationer är mer eller mindre toleranta mot förseningar och trafikbortfall. Dessa krav har funnits i följande QoS-relaterade parametrar:

Bandbredd - hastigheten med vilken trafik som genereras av en applikation måste överföras över nätverket;
Latency - Fördröjningen som ett program kan tolerera vid leverans av ett datapaket.
Jitter - ändrar fördröjningstiden.
Förlust – procentandel av förlorad data.

Om oändliga nätverksresurser fanns tillgängliga, skulle all programtrafik kunna överföras med den hastighet som krävs, med noll latens, noll latensvariation och noll förlust. Nätverksresurserna är dock inte obegränsade.

QoS-mekanismen styr allokeringen av nätverksresurser till applikationstrafik för att möta överföringskrav.

Grundläggande QoS-resurser och trafikbearbetningsmekanismer

Nätverken som ansluter värdar använder en mängd olika nätverksenheter Inklusive nätverkskort värdar, routrar, switchar och hubbar. Var och en av dem har nätverksgränssnitt. Varje nätverksgränssnitt kan ta emot och överföra trafik med en begränsad hastighet. Om hastigheten med vilken trafik skickas till ett gränssnitt är snabbare än hastigheten med vilken gränssnittet vidarebefordrar trafik, uppstår överbelastning.

Nätverksenheter kan hantera trafikstockningar genom att köa trafik i enhetens minne (buffert) tills trängseln passerar. I andra fall nätverkshårdvara kan vägra trafik för att lindra trängseln. Som ett resultat upplever applikationer latensförändringar (eftersom trafik lagras i köer på gränssnitt) eller trafikförlust.

Förmåga nätverksgränssnitt trafikvidarebefordran och tillgången på minne för att lagra trafik i nätverksenheter (tills trafiken inte kan skickas längre) utgör de grundläggande resurserna som krävs för att tillhandahålla QoS för programtrafikflöden.

Fördelning av QoS-resurser över nätverksenheter

Enheter som stöder QoS använder nätverksresurser intelligent för att överföra trafik. Det vill säga att trafik från mer latens-toleranta applikationer köas (lagras i en buffert i minnet), medan trafik från latenskritiska applikationer skickas vidare.

För att utföra denna uppgift måste nätverksenheten identifiera trafik genom att klassificera paket, och även ha köer och mekanismer för att betjäna dem.

Trafikbearbetningsmekanism

Trafikbehandlingsmekanismen inkluderar:

802.1p
Differentierade tjänster per-hop-beteenden (diffserv PHB).
Integrerade tjänster (intserv).
bankomat osv.

De flesta lokala nätverk är baserade på IEEE 802-teknik inklusive Ethernet, token-ring, etc. 802.1p är en trafikbehandlingsmekanism för att stödja QoS i sådana nätverk.

802.1p definierar ett fält (lager 2 i OSI-nätverksmodellen) i 802-pakethuvudet som kan bära ett av åtta prioritetsvärden. Som regel markerar värdar eller routrar, när de skickar trafik till ett lokalt nätverk, varje skickat paket och tilldelar det ett visst prioritetsvärde. Nätverksenheter som switchar, bryggor och hubbar förväntas bearbeta paket på lämpligt sätt med hjälp av kömekanismer. Omfattningen av 802.1p är begränsad till det lokala nätverket (LAN). När paketet korsar det lokala nätverket (via OSI Layer 3), tas 802.1p-prioriteten bort.

Diffserv är en lager 3-mekanism Den definierar ett fält i lager 3-huvudet för IP-paket som kallas diffserv codepoint (DSCP).

Intserv är en hel rad tjänster som definierar en garanterad tjänst och en tjänst som hanterar nedladdningar. En garanterad tjänst lovar att bära en viss mängd trafik med mätbar och begränsad latens. Tjänsten som hanterar nedladdningen går med på att bära en del trafik med "lätt överbelastning på nätet". Dessa är kvantifierbara tjänster i den meningen att de är definierade för att tillhandahålla mätbar QoS till en viss mängd trafik.

Eftersom ATM-teknik fragmenterar paket till relativt små celler, kan den erbjuda mycket låg latens. Om ett paket behöver skickas akut kan ATM-gränssnittet alltid frigöras för överföring så länge det tar att skicka en cell.

QoS har många fler olika komplexa mekanismer, vilket säkerställer driften av denna teknik. Låt oss bara notera en viktig punkt: för att QoS ska fungera krävs stöd för denna teknik och lämplig konfiguration under hela överföringen från startpunkten till slutpunkten.

För tydlighetens skull, överväg Fig. 1.

Vi accepterar följande:

Alla routrar är involverade i att överföra de nödvändiga protokollen.
En QoS-session som kräver 64 Kbps initieras mellan värd A och värd B.
En annan session som kräver 64 Kbps initieras mellan värd A och värd D.
För att förenkla diagrammet antar vi att routrarna är konfigurerade så att de kan reservera alla nätverksresurser.

I vårt fall skulle en begäran om en reservation på 64 Kbps nå tre routrar på datavägen mellan värd A och värd B. En annan begäran om 64 Kbps skulle nå tre routrar mellan värd A och värd D. Routrarna skulle uppfylla dessa resursreservationsförfrågningar eftersom de inte överstiger max. Om istället var och en av värdarna B och C samtidigt initierade en 64 Kbps QoS-session med värd A, skulle routern som betjänar dessa värdar (B och C) neka en av anslutningarna.

Anta nu att nätverksadministratören inaktiverar QoS-bearbetning i de tre nedströmsroutrarna som betjänar värdarna B, C, D, E. I det här fallet skulle förfrågningar om resurser upp till 128 Kbps tillfredsställas oavsett platsen för den värd som är involverad i anslutningen. Kvalitetssäkringen skulle dock vara låg eftersom trafik till en värd skulle sätta trafik till en annan i fara. Servicekvaliteten skulle kunna bibehållas om den övre routern begränsade alla förfrågningar till 64 Kbps, men detta skulle resultera i ineffektiv användning av nätverksresurser.

Å andra sidan kunde genomströmningen av alla nätverksanslutningar ökas till 128 Kbps. Men den ökade bandbredden kommer bara att användas när värdarna B och C (eller D och E) samtidigt begär resurser. Om så inte är fallet kommer nätverksresurserna återigen att användas ineffektivt.

Microsoft QoS-komponenter

Windows 98 innehåller endast QoS-komponenter på användarnivå, inklusive:

Applikationskomponenter.
GQoS API (del av Winsock 2).
QoS-tjänsteleverantör.

Operativsystemet Windows 2000/XP/2003 innehåller allt som beskrivs ovan och följande komponenter:

Resource Reservation Protocol Service Provider (Rsvpsp.dll) och RSVP-tjänster (Rsvp.exe) och QoS ACS. Används inte i Windows XP, 2003.
Trafikhantering (Traffic.dll).
Generisk paketklassificerare (Msgpc.sys). Paketklassificeraren bestämmer den tjänsteklass som paketet tillhör. I detta fall kommer paketet att placeras i lämplig kö. Köer hanteras av schemaläggaren QoS-paket.
QoS Packet Scheduler (Psched.sys). Definierar QoS-parametrar för en specifik dataström. Trafiken är markerad med ett specifikt prioritetsvärde. QoS-paketschemaläggaren bestämmer köschemat för varje paket och hanterar konkurrerande förfrågningar mellan köade paket som behöver åtkomst till nätverket samtidigt.

Diagrammet i figur 2 illustrerar protokollstacken, Windows-komponenter och deras interaktion på värden. Objekt som användes i Windows 2000 men som inte användes i Windows XP/2003 visas inte i diagrammet.

Applikationer är överst i stacken. De kanske känner till QoS eller inte. För att utnyttja den fulla kraften i QoS rekommenderar Microsoft att du använder Generic QoS API-anrop i dina applikationer. Detta är särskilt viktigt för applikationer som kräver högkvalitativa servicegarantier. Vissa verktyg kan användas för att anropa QoS på uppdrag av applikationer som inte känner till QoS. De fungerar via Traffic Management API. Till exempel använder NetMeeting GQoS API. Men för sådana applikationer är kvaliteten inte garanterad.

Den sista spiken

Ovanstående teoretiska punkter ger inget tydligt svar på frågan om vart de ökända 20% tar vägen (som, jag noterar, ingen har ännu exakt mätt). Baserat på ovanstående bör detta inte ske. Men motståndarna lägger fram ett nytt argument: QoS-systemet är bra, men implementeringen är sned. Därför är 20 % fortfarande "feta". Uppenbarligen har problemet plågat mjukvarujätten också, eftersom den separat har motbevisat sådana påhitt för ganska länge sedan.

Men låt oss ge ordet till utvecklarna och presentera utvalda punkter från artikeln "316666 - Windows XP Quality of Service (QoS) Enhancements and Behavior" på litterär ryska:

"Hundra procent av nätverkets bandbredd är tillgänglig för distribution bland alla program om inte ett program uttryckligen begär prioriterad bandbredd. Denna "reserverade" bandbredd är tillgänglig för andra program om inte programmet som begärde det inte skickar data.

Som standard kan program reservera upp till 20 % av huvudanslutningshastigheten på varje datorgränssnitt. Om programmet som reserverade bandbredden inte skickar tillräckligt med data för att använda allt, är den oanvända delen av den reserverade bandbredden tillgänglig för andra dataströmmar.

Det har förekommit påståenden i olika tekniska artiklar och nyhetsgrupper att Windows XP alltid reserverar 20 % av den tillgängliga bandbredden för QoS. Dessa påståenden är felaktiga."

Om nu någon fortfarande äter upp 20% av sin bandbredd, ja, jag kan råda dig att fortsätta använda fler av alla typer av tweaks och sneda nätverksdrivrutiner. Det blir inte lika mycket att "bli uppfettad" heller.

Det är det, QoS-myten, dö!

12/01/2016 | Vladimir Khazov

All Internettrafik skapas inte lika. En onlinevideo utan en stammande bild eller ett Skype-samtal utan en stammande röst är viktigare än att ladda ner en stor fil med en torrentklient. Kvaliteten på tjänsten (QoS)-funktionen i en router, shaper eller djuptrafikanalys (DPI)-system gör att du kan prioritera vilken trafik som är viktigast och ge den mest bandbredd.

Och om hemma varje användare kan konfigurera QoS på sin router, hanterar teleoperatören, med hjälp av modern nätverksutrustning, bandbredden för alla sina abonnenter och säkerställer konsekvent hög kvalitet för var och en av dem.

Vad är kvaliteten på tjänsten (QoS)

Service Quality Assurance är ett utmärkt men sällan använt verktyg för att hjälpa till att prioritera olika typer trafik, och med hjälp DPI-systemäven för vissa tillämpningar, dela bandbredden mellan dem i olika proportioner. Korrekt inställning av QoS-regler kommer att säkerställa smidig uppspelning av onlinevideor medan du laddar ner en stor fil, eller snabb webbsurfning medan barn spelar onlinespel.

En internetuppkoppling kan jämföras med ett sjukhus, där bandbredden är antalet läkare som ska behandla patienter, patienterna är applikationerna och sjuksköterskan är routern som distribuerar dem.

I ett typiskt nätverk fördelar en likgiltig sjuksköterska patienterna jämnt mellan tillgängliga läkare, oavsett sjukdomens komplexitet, vare sig det är en person med en blåslagen arm eller ett bilolycksoffer med hjärnskakning och brutna ben. Var och en av dem kommer att få hjälp, men de får vänta lika länge tills en läkare blir tillgänglig. Om alla patienter behandlas med samma prioritet kommer det förr eller senare att leda till katastrofala konsekvenser för sjukhuset och skadade.

Samma sak händer i ett hemnätverk eller leverantörsnätverk. Kommunikationsbandbredden fördelas jämnt inom tariffplanen, utan hänsyn till vikten av varje applikation. Till exempel, om du är på ett Skype-samtal och dina barn tittar på en Netflix-film, kommer kvaliteten på samtalet att försämras dramatiskt. Internetleverantören är i sin tur begränsad av kanalens hastighet till uppströms teleoperatören, och dess bandbredd kanske inte räcker till för att säkerställa kvaliteten på anslutningen om alla användare samtidigt börjar ladda ner filer via en torrentklient med maximal hastighet.

Routern delar bandbredden lika mellan alla, utan att prioritera någon typ av trafik.

För att återgå till vår jämförelse med ett sjukhus är vårdens kvalitet en kompetent sjuksköterska som fördelar patienterna bland läkarna i de flesta effektivt sätt: flera specialister kommer att ta hand om de skadade i en olycka, och en person med ett blåmärke kommer att vänta på en läkare när han är ledig.

I ett nätverk med en tjänstekvalitetsfunktion kommer applikationen eller tjänsten att prioriteras som du själv bestämmer (onlinevideo, IPTV, onlinespel, etc.), den kommer att få högre hastighet och minimala förseningar.

Hur man slår på denQoS

Det finns hundratals olika routrar - hem och kontor, såväl som komplexa enheter av operatörsklass. Inte alla av dem har en QoS-funktion, och om den gör det kan dess implementering skilja sig åt i mängden av möjliga inställningar. Vissa kan bara bestämma prioritet mellan enheter, vissa kan markera vissa typer av trafik (till exempel video eller röstkommunikation), DPI-system kan känna igen applikationer som inte använder tidigare kända rubriker och datastrukturer för datautbyte, och göra ändringar i prioritetsfältet för paket som passerar genom det för vidare tillämpning av QoS-regler.

Det är omöjligt att gå in på detaljerna för att ställa in varje enhet, men vi kan beskriva de grundläggande stegen för att börja använda QoS för en bättre internetupplevelse.

Första steget: Definiera ditt mål

Innan du börjar konfigurera någon enhet måste du tydligt definiera dina QoS-konfigurationsmål. Om du bestämmer dig för att ställa in hem router, då kan detta vara prioriteringen av arbetsdatorn framför andra enheter med internetåtkomst för att säkerställa bekvämt arbete, eller prioriteringen av onlinespel framför strömmande video för att säkerställa minimala förseningar och fördröjningar under spelet.

I ett hemnätverk bör reglerna vara selektiva och extremt enkla. Om du tillämpar dussintals olika prioriteringar kan du få ett negativt resultat när ingen av applikationerna kommer att fungera korrekt.

Telekomoperatören använder QoS för att uppnå fler globala mål:

trafikdifferentiering;
säkerställa ett enhetligt trafikflöde;
garanti för kvalitet och hastighet för internetåtkomst för varje abonnent;
förhindra nätstockning;
minskning av Uplink-kostnader.

Men principerna för att uppnå dem liknar hemnätverk: bestämma prioriterade typer av trafik och applikationer, fastställa regler beroende på prioritet och varaktighet.

Andra steget: bestäm internethastigheten

För en telekomoperatör är internethastigheten hastigheten för åtkomst till en leverantör på högre nivå (Uplink) eller till flera leverantörer. Detta värde är fast och fördelas mellan alla abonnenter enligt deras taxeplaner. Problemet med dess optimering och kompetent distribution måste lösas av QoS-regler för att säkerställa kundnöjdhet från den mottagna tjänsten.

Fart hem internetöverensstämmer ofta inte med det som anges av leverantören av någon anledning, så att bestämma dess reella nummer är en viktig uppgift innan du ställer in QoS. Det finns begrepp om utgående och inkommande hastighet som du måste bestämma själv.

För att få den verkliga bilden måste du stänga alla applikationer på din dator som skapar en belastning på nätverket och ansluta den till routern med en kopparkabel. Wi-Fi trådlös nätverksteknik, särskilt om den inte fungerar över moderna protokoll Wireless N eller Wireless AC kan vara en flaskhals för bandbredd. Mätningar kan visa hastigheter på 40 Mbps istället för tillgängliga 75 Mbps just på grund av hastighetsbegränsningar för trådlös dataöverföring.

Gå till webbplatsen www.speedtest.net och klicka på knappen "Starta test". Det erhållna resultatet måste konverteras från "Mbit/s" till "Kbit/s", eftersom QoS-inställningar oftast anges i dessa enheter. Detta kan göras genom att multiplicera de resulterande värdena med 1000.

I det här exemplet fick vi en inkommande hastighet på 42 900 Kbps och en utgående hastighet på 3 980 Kbps. Det är dessa värden som kan distribueras mellan användare och applikationer på nätverket.

Tredje steget: aktiveraQoSpå routern

Det är omöjligt att beskriva proceduren för att aktivera QoS på alla routrar, eftersom varje tillverkare förser användaren med sitt eget hanteringsgränssnitt och nätverksenheter i bärarklass, som Cisco, Juniper, Huawei, konfigureras från kommandoraden.

I de flesta fall måste du gå till sidan för enhetshantering (skriv dess adress i webbläsaren, oftast är det 192.168.1.1), ange administratörsinloggningen och lösenordet, som anges i användarmanualen, och gå till NAT-delen av nätverksinställningar, QoS-fliken. Välj Aktivera motsatt Starta funktioner QoS, port för tillämpning av regler - WAN (anslutningsport med leverantören), inkommande och utgående hastighetsinställningar (nedlänk och upplänk) bör specificeras i mängden 85–90 % av det som uppmätts i det andra steget.

Reducerade hastigheter är specificerade för att ge QoS-hanteraren lite utrymme att manövrera så att den kan fungera effektivt. QoS-funktionen är nu aktiverad och du måste konfigurera prioriteringsreglerna.

Hur man prioriterar trafik

Efter att QoS-funktionen har aktiverats är det nödvändigt att definiera reglerna för vilka den ska fungera med trafik.

Transportörer konfigurerar regler baserat på data från DPI-systemanalysverktyg som visar bandbreddsflaskhalsar och trender under dagen. Vissa hemenheter har färdiga förinställningar som användaren måste använda för prioritering.

Om routern tillåter manuella prioritetsinställningar måste du ställa in deras "gafflar" som en procentandel av den totala bandbredden:

Max: 60–100 %
Premium: 25–100 %
Express: 10–100 %
Standard: 5–100 %
Bulk: 1–100 %

Dessa inställningar bestämmer bandbreddsvärdet för en specifik enhet eller applikation. Genom att till exempel ställa in en applikation på Maximum tilldelar du den att använda 60 % av bandbredden när nätverket är upptaget och 100 % när nätverket är fullt tillgängligt. Om du ställer in den på "Trunk", då när nätverket är inaktivt, kan applikationen använda vilken bandbreddshastighet som helst, men om det finns en belastning kommer den bara att ta emot 1%.

Vi vill påminna dig om att prioritering måste göras med en tydlig förståelse för vad du vill begränsa.

Alternativ för prioritering

1. Tjänste- eller tillämpningsprioritet

Tillåter alla enheter i nätverket att prioritera bandbredden för en specifik applikation eller tjänst framför andra. Till exempel, om det är nödvändigt att Skype-applikationen alltid har dedikerad bandbredd och att video- och ljudkommunikation inte har förseningar, förvrängningar eller artefakter.

2. Gränssnittsprioritet

Gränssnittet i det här fallet är metoden med vilken dina enheter ansluter till nätverket. Du kan konfigurera högre prioritet för enheter som ansluter via tråd eller trådlöst nätverk, eller omvänt minska prioriteten för gästenheter.

3. Prioritering av enheter efter IP-adress

Du kan tilldela en högre prioritet specifik enhet ditt nätverk genom sin IP-adress (statisk eller reserverad dynamisk), vilket ger det högre åtkomsthastigheter jämfört med andra.

4. Prioritera enheter efter MAC-adress

Om du använder dynamisk adressering kan du fortfarande ge hög prioritet till en av nätverksenheterna baserat på dess MAC-adress, som är unik och information om vilken kan erhållas antingen från programvara, eller från etiketten på fodralet.

Test och utvärdering

De viktigaste reglerna för att ställa in QoS är att lägga till regler sekventiellt och inte förhasta. Du måste börja med de mest globala och sedan konfigurera individuella applikationer och tjänster. Om du har uppnått önskat resultat och QoS uppfyller alla dina krav måste du spara konfigurationen som skärmdumpar eller en fil säkerhetskopia om du behöver återställa routern och återställa inställningarna.

Du kan verifiera att reglerna fungerar korrekt genom att lansera tjänster med hög och låg prioritet och jämföra deras hastigheter, eller köra ett hastighetstest på nätverksenheter med olika prioriteringar och se vilken som visar bäst resultat.

Att sätta upp QoS är en mer komplex process än grundläggande routerinstallation, och för teleoperatören tillkommer även ytterligare kapitalkostnader för att köpa en DPI-plattform, men resultatet kommer att göra att du kan uppnå bättre tillgång till Internet, samt spara pengar på köp av en höghastighetskommunikationskanal.