Caracteristici Qos Intr O Retea Tcpip
Introducere
Capitolul 1: Introducere în QoS
1.1. Evoluția QoS
1.2. Aplicarea QoS de la un capăt la altul
1.3. Pachetele cu trafic diferit
1.4. Nivelele QoS
1.5. Modelele QoS
1.6. Tehnici și mecanisme QoS: Prezentare generală
1.7. Simplificarea QoS
1.7.1. Modulul QoS în linie de comandă
1.7.2. Standardul QoS
1.7.3. Comportarea Implicită
1.8. Beneficiile QoS
Capitolul 2: Caracteristicile traficului și QoS
2.1. Introducere
2.2. Caracteristicile de performanță ale rețelei
2.2.1. Lățimea de bandă
2.2.2. Întârzierea
2.2.3. Jitter-ul
2.2.4. Aruncarea pachetelor
2.3. Caracteristicile traficului de voce și date
2.3.1. Caracteristicile traficului de voce și QoS
2.3.2. Caracteristicile traficului de date și QoS
Capitolul 3: Mecanismele QoS
3.1. Clasificarea
3.2. Marcarea
3.2.1. Marcarea bazată pe clase
3.2.2. Marcarea bazată pe politicile de clasă
3.2.3. Marcarea de Nivel 3
3.3. Aplicarea de politici și ajustarea
3.4. Mecanismele de Management al congestiei
3.5. Mecanismele de Evitare a congestiei
Capitolul 4: QoS în rețeaua locală (LAN)
4.1. Mecanisme QoS în LAN
4.1.1. Necesitatea aplicării QoS în LAN
4.1.2. Clasificarea și marcarea pachetelor
4.1.3. Cozile de așteptare de Nivel 2
4.1.4. Limitele de aruncare
4.1.5. Limitele de încredere
5. QoS în monitorizarea traficului in rețea
5.1. IMQ-devices pt ce?
5.2 Queuing Disciplines – HTB, HFSC or CBQ
5.2 .Definiții si termeni
5.2.1 Lățimea de banda
5.2.2 Protocoale
5.2.3 Porturi
5.2.4 Obiectivele-ținta
5.2.5 Nivelele de serviciu
5.2.6 Filtre
5.2.7 Canale
5.2.8 Pipes
5.2.9 Bridge sau Router
5.2.4 Configurația
5.2.4.1 Setarile
5.2.4.1.1 Opțiunile
5.2.4.1.2 Obiectivul
5.2.4.2 Folosirea
5.2.4.2.1 Nivelele de serviciu
5.2.4.2.2 Filtre
5.2.4.2.3 Canalele
5.2.4.2.4 Pipes
5.2.4.3 Monitorizarea
5.2.4.3.1 Canale,Pipe ,Latime de banda
5.2.4.4 Overview
5.2.4.5 Reguli
5.2.4.5.1 Incarcarea (Load)
5.2.4.5.2 Load(debug)
5.2.4.5.3 Show
5.2.4.5.4 Unload
5.2.6 Exemple de forme
5.2.6.1 Forme pe un server Web
5.2.6.2 Implementarea
Acronime
Index
Bibliografie
Pagini 80
Prezentare power point
=== Capitol1 ===
Introducere
Tehnica de calcul în general și rețelele în particular trebuie să facă față problemelor legate de resursele limitate. Pentru calculatoare, sistemele de operare trebuie să distribuie eficient timpul procesorului și memoria programelor care sunt active pe el. Când limita memoriei interne este atinsă procesorul pierde timpi suplimentari pentru a muta datele din memoria internă pe suport fizic, de obicei HD (Hard Disk). Dacă procesorul nu reușește să asigure un management eficient al resurselor, utilizatorii devin frustrați pentru că nu pot să-și continuie munca.
Pentru a face față cerințelor tot mai mari pentru rețelele moderne Cisco și specialiștii în rețelistică au grupat toate mecanismele și tehnicile de asigurare a calității pentru rețele sub numele de QoS (Quality of Service). De asemenea, au îmbunătățit și au dus la dezvoltarea QoS pentru rețelele convergente de voce, video și date.
Prezenta lucrare este un studiu asupra mecanismelor și tehnicilor QoS pentru aplicarea practică a QoS într-o rețea locală (LAN) care trebuie să suporte date, voce și video. Prezint detaliat mecanismele QoS care țin de rețeaua LAN și mai general mecanismele QoS folosite în WAN. Pentru aplicația practică am avut nevoie de acest studiu care se bazează pe documentația oficială oferită de Cisco.
În capitolul 1 prezint modul în care a apărut și a evoluat QoS. De asemenea, am abordat în general mecanismele și tehnicile folosite de QoS.
Capitolul 2 prezintă caracteristicile traficului într-o rețea modernă. Sunt prezentate problemele care apar și tehnicile QoS care au fost create pentru a le soluționa. În detaliu sunt prezentate cerințele de trafic pentru voce și date.
Capitolul 3 descrie în detalii mecanismele QoS folosite în LAN. Sunt prezentate și exemple din CLI (Command Line Interface) pentru configurarea lor pe echipamentele de rețea Cisco.
Capitolul 4 descrie cu lux de amănunte QoS pentru rețeaua LAN.
Capitolul 5 reprezintă partea practică a lucrării care descrie implementarea QoS într-o rețea LAN. Exemplele sunt reale și asigură și astăzi servicii de calitate Cisco QoS într-o rețea convergentă de voce și date.
Capitolul 1: Introducere în QoS
1.1. Evoluția QoS
Acum un secol rețeaua publică de telefonie cu comutare de circuite (PSTN) a început să se dezvolte la nivel mondial. Această rețea se compunea din lățime de bandă fixă, circuite dedicate și era concepută pentru traficul în timp real, cum ar fi vocea. Cinci decenii mai târziu, experții în rețelistică din mediul educațional și militar au introdus rețelele cu comutare de pachete pentru a evita orice punct de cădere. Rețelele cu comutarea pachetelor împart fluxul de informație în părți mai mici care pot fi transmise pe căi independente spre aceeași destinație, analog sistemului poștal.
Teoretic comunicațiile în timp real, cum ar fi vocea, pot folosi circuite virtuale indiferent de tehnologia de rețea pe care se bazează. Totuși, vocea bazată pe circuite virtuale nu a devenit o realitate comercială sau practică până când router-ele și switch-urile folosite în rețelele cu comutare de pachete nu au devenit îndeajuns de puternice pentru a conduce fluxul de pachete în timp real la costuri rezonabile.
Când puterea de procesare a ajuns la limitele care permit crearea circuitelor virtuale, au apărut alte probleme legate de caracteristicile unui trafic în timp real. De exemplu, pachetele sunt aruncate sau întârzie foarte mult din cauza umplerii tampoanelor de memorie. Soluția retransmiterii pachetelor care funcționa foarte bine pentru traficul de date nu mai asigură cerințele traficului în timp real.
Prima tehnologie pentru transferul pachetelor care a introdus conceptul de “categorie de serviciu” la Nivel 2 a fost ATM. Această tehnologie oferă tratament diferit pentru diferite tipuri de trafic. ATM minimizează întârzierile prin definirea unor celule – pachete cu lungime fixă care pot fi rutate în hardware. ATM utilizează, de asemenea, conceptul de PVC și SVC pentru a elimina întârzierile care apar pentru a stabili ruta pachetelor.
În efortul de a integra traficul de date și voce a fost inventat ISDN (Integrated Services Digital Network). Termenul de servicii integrate se referă la convergența între tipurile diferite de trafic: voce, video și date pe o singură rețea cu comutare de pachete. ISDN, care a fost prima tehnologie prin care s-a încercat aplicarea arhitecturii de rețea convergentă, definește modul de transport al traficului de date peste o rețea care suportă nativ voce.
La sfârșitul anilor 90, tehnologia bazată pe IP a câștigat lupta pentru transportul traficului convergent din cauza ușurinței cu care poate fi folosită și a avantajelor pe care le oferă pentru traficul în timp real. Factorii care au asigurat acest succes tehnologiei IP în convergența diferitelor tipuri de trafic sunt mecanismele QoS. QoS permite tratament diferențiat pentru voce față de date și pentru video față de voce. Odată cu evoluția QoS un număr mare de întreprinderi au văzut un avantaj în a avea o singură rețea convergentă pentru date, voce și video și au început să participe activ la dezvoltarea rețelelor convergente.
Rețelele IP din anii 1990 au fost rețele de tip „Best-Effort” și Internetul, ca și întreg a rămas așa până în prezent. Rețelele private ale marilor companii și furnizori de servicii Internet au evoluat de la modelul „Best-Effort” la un model mult mai complex bazat pe servicii diferențiate, care asigură pentru un anumit tip de aplicație un anumit tip de serviciu. Figura 1.1-1 prezintă evoluția QoS începând cu mijlocul anilor 1990:
Figura 1.1-1 Evoluția QoS
Prima încercare de a standardiza QoS a fost la mijlocul anilor 90, când IETF a publicat documentul oficial RFC 1633 în iunie 1994 și altele. Aceste documente tratau un singur protocol de rezervare a resurselor (RSVP). RSVP semnalizează lățimea de bandă și întârzierea necesară pentru orice sesiune discretă la fiecare nod în parte (circuit logic) pe care pachetul va trebui să-l parcurgă din momentul trimiterii până când ajunge la destinație. Inițial RSVP avea nevoie de rezervarea resurselor pe fiecare nod ceea ce era destul de greu de realizat pe fiecare switch, server, router care există pe internet și care sunt produse de diferite companii. Pentru a rezolva această problemă, au fost create alte modele de tip DiffServ în încercarea de a standardiza QoS. Modelul DiffServ descrie modul în care trebuie să se comporte fiecare nod. Nodurile pot folosi orice metodă (proprietară sau standard) pentru a se conforma. Marcarea pachetelor, de tip IP Precedence (IPP) și succesorul ei DSCP (Differentiated Services Code Points) au fost definite cu comportări specifice per hop pentru majoritatea tipurilor de trafic.
Evoluția ambelor modele nu a clarificat care dintre ele este cel care trebuie standardizat, ci doar prin împletirea și aplicarea armonioasă a mecanismelor ambelor modele se poate obține o calitate bună a serviciului de rețea. În figura de mai jos este reprezentată poziția ambelor modele pentru asigurarea eficienței unei rețele:
Figura 1.1-2 Poziția IntServ și DiffServ pentru asigurarea eficienței QoS
Scurte definiții pentru IntServ și DiffServ:
IntServ folosește conceptul de flux împreună cu un protocol de semnalizare de-a lungul căii pachetului. Protocolul de semnalizare garantează ca resursele necesare să fie disponibile la fiecare hop pentru flux înainte ca să înceapă transmiterea pachetelor.
DiffServ folosește marcarea pachetelor pentru clasificare și tratează fiecare pachet în parte. Chiar dacă acest model este scalabil (este implementat de majoritatea întreprinderilor și furnizorilor de servicii internet), el asigură o lățime de bandă stabilă pentru pachetele care aparțin unui flux și acceptă mai greu un alt flux pentru procesare.
Cu avantaje și dezavantaje de ambele părți, mecanismele QoS continuă să utilizeze o mixtură între ambele tehnologii pentru a asigura servicii de calitate rețelelor moderne.
La sfîrșitul anilor 90, tehnicile QoS au devenit mult mai sofisticate și au fost adaptate noilor tehnologii avansate cum ar fi MPLS (Multiprotocol Label Switching) și VPN (Virtual Private Networks). Ultimile tendințe în evoluția QoS sunt simplificarea și automatizarea cu scopul de a simplifica și a asigura rețele IP „inteligente” prin QoS.
1.2. Aplicarea QoS de la un capăt la altul
Indiferent de modul în care este măsurat QoS, el este un element vital pentru orice rețea convergentă. Pentru a asigura un nivel ridicat al calității traficului în rețea, QoS trebuie implementat de la un capăt la celălalt. Fiecare echipament care se ocupă de plasarea pachetelor mai departe în rețea (calculator, server, switch sau router) trebuie să implementeze QoS pentru a asigura funcționarea corectă a rețelei în toate nodurile ei.
Este un mit afirmația conform căreia QoS este aplicabil doar în rețelele lente de tip WAN sau pe Internet. Practica a demonstrat că traficul sensibil la întârzieri cum este vocea se degradează din cauza întârzierilor și a aruncării pachetelor dacă QoS nu este implementat pe echipamentele din LAN, ca de exemplu, telefoanele IP CISCO sau switch-urile CISCO Catalyst.
Figura 1.2-1 arată segmentele unei rețele industriale cu telefonie IP unde QoS trebuie aplicat pe fiecare segment:
Figura 1.2-1 QoS în rețelele industriale
1.3. Pachetele cu trafic diferit
Rețelele care nu folosesc QoS sunt descrise ca și rețele de tip Best-Effort. Acest tip de rețele tratează toate pachetele cu același tip de prioritate. Acest tip de rețea funcționează bine dacă există timpi de procesare, memorie, și lățime de bandă pentru procesarea imediată a tuturor pachetelor care traversează rețeaua imediat ce acestea sosesc pe interfață. De obicei acest lucru nu este posibil și apar următoarele probleme:
Disfuncționalități în rețea pe partea de utilizator, când mai mulți utilizatori, mai multe grupuri, încercă să acceseze aceeași resursă.
Disfuncționalități în rețea pe partea de aplicații, când mai multe aplicații de la un utilizator sau mai mulți încearcă să acceseze aceeași resursă.
Traficul are cerințe diferite de la rețea și aceasta trebuie să i le asigure diferențiat.
Figura 1.3-1 Cererile traficului de date, voce și video
Pentru soluționarea problemelor congestiei traficul trebuie tratat diferențiat. Trebuie aplicate politici și tehnici prin care să se asigure funcționarea corectă a fiecărui echipament (nod de rețea).
Conceptele QoS trebuie aplicate atât pentru traficul de încredere de voce sau video cât și pentru traficul generat de virușii de tip SPAM și trafic care poate duce la DoS. Aici intervine componenta de securitate QoS care ne permite să aplicăm diferite politici pentru tipuri de trafic diferit.
1.4. Nivelele QoS
Traficul în rețele este debitat de o varietete însemnată de aplicații de pe stațiile de capăt. Aceste aplicații diferă la cerințele de funcționare și performanțe. Cerințele fiecărui trafic depind de aplicația de care aparține traficul respectiv. Deci, înțelegerea tipului aplicației, este un lucru absolut necesar pentru a cunoaște nevoile de trafic pentru diferite servicii.
Capabilitatea rețelei de a livra servicii pentru anumite aplicații de rețea, cu control asupra indicatorilor de performanță – întârziere/jitter, lățime de bandă, pierderi – este categorizată pe 3 nivele :
1. Serviciul Best-Effort – Conectivitate de bază fără garanția livrării pachetului la destinație, sau a timpului în care acesta ar putea ajunge, deși pachetul este aruncat numai când cozile buffer-elor de intrare sau ieșire sunt pline.
Serviciul Best-Effort nu este realmente o componentă a QoS, deoarece acesta nu asigură servicii sau garanții în înaintarea traficului best-effort. Acest serviciu este însă singurul serviciu pe care îl asigură Internetul astăzi.
Majoritatea aplicațiilor de rețea, ca File Transfer Protocol (FTP), funcționează corect cu serviciul Best-Effort, cu toate că are performanțe mai reduse. Pentru funcționare bună, toate aplicațiile necesită alocare de resurse din partea rețelei, adică, bandwith, întârzieri minime și număr cât mai mic de pachete pierdute.
2. Serviciul Diferențiat – În cadrul serviciului diferențiat, traficul este grupat în clase, în funcție de cerințe. Fiecare clasă de trafic este diferențiată de rețea și servită conform mecanismului QoS configurat pentru clasa respectivă. Aceast tip de QoS este adesea întâlnit sub numele de CoS.
A se sublinia că serviciile diferențiate nu dau garanții la livrare. Aceste servicii, doar diferențiază traficul și permit tratamente preferențiale ale anumitor tipuri de clase. Din acest motiv acestui serviciu i se mai spune și Soft QoS.
Această schemă de QoS dă un randament bun atunci când avem aplicații ce folosesc intensiv banda. Este foarte important ca traficul de control al rețelei să fie diferențiat de restul traficului de date din rețea, și prioritizat astfel încât să existe conectivitate la orice moment.
3. Serviciul Garantat – Un serviciu care necesită rezervarea resurselor rețelei pentru a se asigura că rețeaua întâlnește cerințele de comunicare specifice tipului de trafic respectiv. Datorită faptului că necesită garanții rigide din partea rețelei, serviciul garantat este numit și Hard QoS.
Rezervarea căii nu se integrează bine în structura Internet-ului, care deservește mii de fluxuri de trafic simultan. Aplicațiile ce necesită astfel de servicii includ aplicații multimedia ca audio și video. Aplicațiile interactive de voce peste Internet necesită o întârziere limită de 100 ms pentru a nu afecta conversația. Această întârziere este de asemenea acceptabilă pentru un spectru larg de aplicații multimedia. Telefonia peste Internet necesită minim o bandă de 8 Kbps și maxim 100 ms întârziere „round-trip”. Rețeaua necesită alocarea de resurse pentru a putea satisface asemenea cerințe.
QoS la Nivelul 2 (Nivel din stivă OSI) se referă la toate mecanismele care țintesc sau există în tehnologiile de la nivel de link. QoS la Nivelul 3 se referă la funcțiile QoS de la nivelul rețea.
În Tabelul 1.4-1 sunt afișate cele trei nivele de servicii și funcțiile QoS corespunzătoare, la Nivelul 2 (Data Link) și la Nivelul 3 (Network).
Tabelul 1.4-1 Nivelele QoS
1.5. Modelele QoS
După cum am relatat anterior există două modele pentru asigurarea nivelelor diferite de servicii într-o rețea: IntServ și DiffServ.
IntServ caracteristici generale
Un serviciu IP de tip “Best-Effort” este asemănător cu cel de poștă tradițională. O scrisoare poate ajunge la destinație, și ajunge de obicei, dar se poate și pierde pe parcurs. Modelul IntServ este asemănător cu serviciile de curierat rapid sau poștă diplomatică unde este garantat faptul că scrisoarea ajunge în timp util la destinația stabilită. Specific, IntServ are următoarele caracteristici:
Ce trimite echipamentul transmițător (rată, MTU, etc.), descrise de niște specificații Tspec (specificațiile transmițător)
De ce are nevoie echipamentul receptor (lățime de bandă, MTU, etc.), descrise de specificațiile receptor Rspec.
Cum are loc semnalizarea pe rețeaua dintre transmițător și receptor RSVP.
Platforma pe care se bazează IntServ ia în cosiderare aplicarea tehnicilor QoS pentru IP de la capăt la capăt. Factorii cheie sunt transmițătorul și receptorul care cer un anumit serviciu din partea rețelei pentru anumite fluxuri, definite de adresa sursă, adresa destinație, protocolul de transport, portul sursă și portul destinație.
IntServ descrie trei clase de servicii de bază pe care aplicațiile le pot cere:
Servicii Garantate (RFC 2212) – asigurarea fermă că pachetul va ajunge de la un capăt la celălalt fără întârzieri și face acest lucru garantând lățimea de bandă și minimizând întârzierile.
Trafic Controlat (RFC 2211) – asigură fluxul aplicației cu o calitate a serviciului de rețea apropiată cu cea în care fluxul ar fi într-o rețea liberă sau fără mult trafic; folosește mecanismul de control al capacității pentru a se asigura că serviciul este primit chiar atunci când rețeaua e supraâncărcată.
Serviciul BestEffort – nu garantează nici un serviciu.
Avantajele modelului IntServ sunt următoarele:
Simplitatea în concept, care-i permite să se integreze în politicile de rețea.
QoS-ul discret per flux, îl face din punct de vedere al arhitecturii aplicabil pentru telefonia IP.
Capabilitățile CAC (Call Admisin Control), care indică punctelor terminale unde există lățime de bandă necesară pe flux.
Dezavantajele modelului IntServ sunt următoarele:
Toate elementele din rețea trebuie să-și mențină și să-i propage starea per flux, care poate cere o lățime de bandă considerabilă în rețelele mari.
Sunt folosite mesaje, periodic, care au nevoie de protecție împotriva pierderilor de pachete pentru a asigura sesiunea intactă.
Toate nodurile intermediare trebuie să implementeze RSVP.
DiffServ caracteristici generale
Dacă continuăm cu analogia poștei tradiționale modelul DiffServ este asemănător cu serviciile diferențiate din cadrul aceluiași serviciu poștal. Adică poșta diplomatică poate asigura servicii rapide, ultra rapide și normale pentru trimiterea unei scrisori. Acest model însă nu asigură fluxul de la un capăt la celălalt cu o calitate a serviciului, el se concentrează asupra fiecărui pachet pe nodurile pe care este implementat.
Strategia DiffServ este foarte simplă: el asigură servicii diferențiate per pachet, asigurând prioritatea unora față de celelalte fără a ține cont de flux. Pachetele dintr-un anumit serviciu aparțin de o „clasă” și tratamentul fiecărei clase de pachete este descrisă de componentele DiffServ și rețeaua trebuie să se conformeze lor. Acest lucru este posibil datorită următoarelor caracteristici:
Marcarea câmpului de IP la intrarea în rețea după o anumită limită.
Folosind această marcare determină nodurile care trebuie să trimită pachetul.
Condiționează tratamentul fiecărui pachet specific „clasei” de care aparține.
Specificațiile DiffServ:
Serviciul expediat rapid (RFC 3246) – asigură o coadă de strictă prioritate.
Serviciul expediere asigurată (RFC 2597) – asigură un serviciu de calitate ridicată aplicând tehnici precum aruncarea pachetelor și planificarea pentru traficul în exces.
Serviciul de selecție a claselor (RFC 2474) – asigură o tehnică care este folosită pentru compatibilitate cu IP Precedence.
Serviciul Best-Effort – nu asigură nimic.
Modelul DiffServ are următoarele avantaje:
Scalabilitate – nu este nevoie de informații despre stare sau flux ca să fie menținut.
Performanță – pachetul trebuie să fie cercetat doar o dată pentru procesul de clasificare. Toate deciziile următoare se fac pe baza unei singure citiri din pachet.
Interoperabilitate – este bazat pe IP.
Flexibilitate – nodul nu trebuie să aplice o tehnică anume, el poate să folosească ce tehnică dorește pentru a se conforma cerințelor descrise de DiffServ.
Dezavantajele modelului DiffServ sunt:
Nu există un control de la cap la coadă a tuturor nodurilor rețelei și pot apărea noduri unde rețeaua să nu asigure servicile dorite.
Lipsa controlului per flux poate duce la congestii. Spre exemplu, dacă există bandă doar pentru 10 telefoane IP un al 11-lea telefon poate duce la congestionarea rețelei.
1.6. Tehnici și mecanisme QoS: Prezentare generală
Există multe tehnici și mecanisme utilizate pentru a oferi o calitate mai bună a rețelelor moderne. Mai jos voi prezenta câteva dintre ele și în capitolul 3 voi prezenta detaliat funcția și rolul pe care le pot juca în anumite circumstanțe care apar într-o rețea.
În general, mecanismele și tehnicile QoS se împart în următoarele categorii:
Clasificare și marcare
Aplicare de politici și ajustare
Evitarea congestiei
Managementul congestiei
Unelte specifice legăturii
Pachetele sau frame-urile care intră într-un echipament de rețea trebuie să fie analizate pentru a determina tratamentul pe care trebuie să-l primească din partea rețelei. Această analiză este numită clasificare. Clasificarea este prima funcție QoS fără de care nu ar fi posibilă aplicarea serviciilor diferențiate. Se recomandă să se facă clasificarea traficului cât mai aproape de sursă.
Marcarea stabilește limite distincte de încredere care demarcheză punctele în rețea unde pachetele sunt admise ca atare fără a mai fi nevoie de o clasificare detaliată de nivel 3 sau 4.
Traficul de tip VoIP, HTTP sau FTP care intră în echipamentul de rețea este marcat și clasificat în diferite clase. Înainte de plasare în cozi se aplică mecanismul de evitare a congestiei WRED. Traficul este apoi plasat în cozi sau aruncat. Apoi funcție de prioritate este planificat pentru ieșirea din echipament.
În figura de mai jos voi prezenta mecanismele și tehnicile QoS:
Figura 1.6-1 Mecanismele QoS
1.7. Simplificarea QoS
La sfârșitul anilor 90, Cisco a depus un efort considerabil pentru a dezvolta și implementa un mecanism eficient QoS cu o serie de îmbunătățiri. Mecanismele QoS au devenit foarte multe și foarte complicate la nivelul implementării. Pe parcursul anului 2000, cererea clienților Cisco a fost să fie simplificate tehnicile de aplicare a QoS. Ca și răspuns la această cerere au fost dezvoltate o serie de proiecte pentru simplificarea și automatizarea QoS. Rezultatele au dus la:
Crearea modulului de QoS în linie de comandă (CLI)
Stabilirea standardului QoS
Comportarea implicită (conform standardului)
Portabilitatea pe diferite platforme
QoS automatizat (AutoQoS)
1.7.1. Modulul QoS în linie de comandă
Primul pas pentru a simplifica lucrurile a fost modularizarea configurării QoS și stabilirea aceluiași set de comenzi pentru toate platformele. La sfîrșitul acestui pas a fost introdus MQC (Modular QoS Comand-Line Interface) în versiunea 12.0(5)T a sistemului de operare Cisco IOS.
În MQC există trei componente de bază:
class-map – Un filtru de clasificare definit în cadru schemei de politici pentru a identifica traficul pentru un tratament preferențial sau diferențial. Traficul poate fi identificat după IPP sau DSCP, de asemenea, după listele de acces ACL, după parametri de nivel 2 CoS, DE, ATM CLP, MPLS.
policy-map – O comandă care definește cum trebuie să fie deservit fiecare tip de trafic clasificat de class-map. Opțiunile sunt marcarea, aplicarea de politici, ajustarea, aruncarea selectivă, comprimarea.
service-policy – O comandă care asignează politicile pe interfață și le specifică direcția.
1.7.2. Standardul QoS
Chiar dacă a fost dezvoltat MQC un pas important în simplificarea QoS, el a rezolvat doar problemele de implementare a QoS. Un alt factor în complexitatea QoS este inconsistența capabilităților QoS de-a lungul diferitelor platforme hardware și software.
În 2002, o serie de activități în cadrul Cisco au dus la crearea Standardelor Tehnologiei pentru a clarifica ce capabilități QoS sunt prezente și pe ce platforme. Specific pentru QoS, Standardul QoS este un document strategic intern scris de experți Cisco care a avut la bază unul din aceste două scopuri:
Pentru a documenta ce capabilități QoS sunt necesare pe echipamentele considerate produse cu QoS înglobat.
Pentru a asigura o analiză a capabilităților, considerate importante din punct de vedere a platformei pe care există.
Pentru produsele noi acest standard a impus inginerilor proiectanți anumite reguli și produsele deja proiectate trebuiau ajustate la noile reguli QoS.
Standardul QoS definește 11 clase de trafic care sunt folosite în toate exemplele de configurare și testare Cisco. Standardul nu cere ca firmele care folosesc QoS să folosească toate clasele imediat. Aceste clase sunt menite să asigure cerințele traficului de astăzi și cel pentru viitorul apropiat. Tabelul de mai jos oferă un rezumat al recomandărilor din standardul Cisco cu privire la QoS:
Tabelul 1.7.2-1 Clasele standardului QoS
Tabelul 1.7.2-1 Clasele standardului QoS
1.7.3. Comportarea Implicită
Următorul pas spre simplificare a fost implementarea unei comportări implicite pentru fiecare nod de rețea, adică fiecare nod trebuie să facă ce are de făcut fără nici o configurare. După o serie de modificări în sistemul de operare Cisco IOS și în echipamentele care nu sunt Cisco (telefoane IP), tot traficul de voce este marcat cu DSCP EF. Prin acest lucru se elimină necesitatea de a configura ceva în plus. Aceste schimbări sunt discutate în detaliu în capitolul următor la clasificare și marcare.
Automatizarea QoS
Automatizarea QoS (AutoQoS) este în esență macro care permite administratorului de rețea să folosească două sau trei comenzi QoS pentru a activa toate capabilitățile QoS pe un anumit echipament.
De exemplu, în prima sa versiune AutoQoS pentru VoIP a asigurat cea mai bună practică pentru configurarea VoIP pe router-ele Cisco și Switch-urile Catalyst. Printr-o singură comandă pe interfață sau global (depinde de platformă) era configurat QoS pentru acel echipament.
AutoQoS există pentru LAN și WAN pe switch-urile Catalyst și pe router-ele Cisco IOS. În versiunea sa inițială QoS se putea aplica doar pentru mediile VoIP.
Pentru switch-urile din LAN, AutoQoS efectuează următoarele automatizări:
Stabilesc limitele de încredere (trust) pînă la telefoanele Cisco IP.
Stabilesc limitele de încredere (trust) cu celelalte switch-uri Cisco.
Activează o coadă strict prioritară pentru voce și coadă round-robin și de greutate pentru date.
Modifică criteriile de admitere în echipament.
Modifică dimensiunea și greutatea cozilor unde este necesar.
Modifică mapările de la Nivel 2 la Nivel 3.
Pentru router-ele Cisco IOS, AutoQoS este suportat pe Frame Relay, ATM, HDLC, PPP și legăturile între Frame Relay și ATM și execută următoarele funcții:
Aplică planificarea:
LLQ (Low-Latency Queuing) pentru voce
CBWFQ (Class-Based Weighted Fair Queuing) pentru semnalizare voce
FQ (Fair Queuing) pentru traficul normal
Activează ajustarea traficului pentru Frame Relay dacă este nevoie.
Activează fragmentarea și intercalarea pentru legăturile lente (< 768kbss).
Activează comprimarea pentru IP RTP.
Asigură alerte de tip RMON dacă pachetele IP sunt aruncate.
În cea de a doua versiune AutoQoS au fost implementate 10 clase conform standardului QoS. AutoQoS simplifică implementarea QoS pentru voce, video și date. Un alt avantaj este că această tehnologie reduce posibilitatea erorilor umane în implementarea QoS. Fiecare client Cisco poate să-și adapteze cu ajutorul MQC cerințele specifice pentru QoS.
1.8. Beneficiile QoS
Principalele beneficii al IP QoS sunt următoarele :
1. Permite ca rețeaua să suporte serviciile multimedia, împreună cu cerințele lor. Noile aplicații, ca Voice over IP (Voce peste IP) și video au cerințe specifice de la rețea.
2. Acordă operatorului de rețea controlul și utilizarea resurselor rețelei.
3. Oferă garanție serviciilor și diferențierea traficului în rețea. Este necesar să avem convergența diferitelor tipuri de trafic voce, video și date într-o singură rețea IP.
4. Permite furnizorilor de servicii de internet să ofere servicii bonus împreună cu serviciul existent „Best-Effort” – Class of Service (CoS). Un furnizor de servicii de internet poate să-și evalueze serviciul bonus ca fiind Platină, Aur sau Argint, spre exemplu, și să configureze rețeaua pentru a diferenția traficul.
5. Joacă un rol important în noile servicii de rețea oferite ca Virtual Private Network (VPN).
=== Capitolul 2 ===
Capitolul 2: Caracteristicile traficului și QoS
2.1. Introducere
În rețelistică, QoS (calitatea serviciului) descrie o serie de concepte și instrumente care pot fi folosite pentru a afecta accesul pachetelor la un anumit serviciu. Mulți cred că QoS se rezumă la posibilitatea plasării pachetelor în diferite cozi de așteptare în funcție de prioritatea lor. Dar există multe alte concepte și instrumente care afectează calitatea serviciilor într-o rețea: comprimarea, politica de aruncare a pachetelor, ajustarea, politica de semnalizare, etc. În cele din urmă, utilizarea oricărui din aceste mecanisme nu face altceva decât să acorde prioritate unui pachet față de altul. Ca și în cazul unor bănci la ghișeul cărora scrie: „Persoanele juridice au prioritate.” Fiecare dintre noi, devine frustrat când trebuie să stea la coadă după diferite lucruri ce țin de satisfacerea anumitor nevoi. Ar fi minunat dacă nu am avea pe nimeni așteptând în fața noastră la bancă sau la supermarket. O soluție ar fi dublarea sau triplarea numărului de ghișee la bănci și mărirea ariei de efectuare a plăților la supermarket. O soluție costisitoare de altfel… care nu va soluționa definitiv problema. Vor exista zile, în week-end, spre exemplu, când se vor forma cozi.
Tabelul 2.1-1. Comportarea unei rețele fără QoS
2.2. Caracteristicile de performanță ale rețelei
În acest capitol voi prezenta patru caracteristici pe care QoS le poate afecta și de care depinde performanța unei rețele:
Lățimea de bandă (Bandwidth)
Întârzierea (Delay)
Jitter-ul (Jitter)
Pierderea pachetelor (Packet loss)
Lățimea de bandă definește capacitatea de transmisie a mediului. Comprimarea reduce lățimea de bandă necesară pentru a trimite toate pachetele, însă procesul de comprimare adaugă întârzieri per pachet și consumă din timpii de procesare ai CPU.
Jitter-ul este variația întârzierilor între pachetele consecutive, de aceea este numit uneori și „variația întârzierii.” Router-ul poate reduce jitter-ul pentru un anumit trafic însă acest lucru duce de obicei la creșterea întârzierilor și jitter-ului pentru alt trafic. Caracteristicile QoS pot rezolva problemele jitter-ului prin capacitățile plasării pachetelor în diferite cozi de așteptare în funcție de prioritatea lor.
Pierderea pachetelor poate apărea din cauza erorilor de transmisie. Totuși, multe pachete se pot pierde mai degrabă din cauza umplerii cozilor decât a erorilor de transmisie și QoS poate decide care dintre pachete să fie aruncate.
Cheia către un succes real în implementarea QoS este îmbunătățirea acelor caracteristici QoS pentru traficul care are nevoie de ele, degradând în același timp caracteristicile QoS de care acel trafic nu are nevoie. De exemplu, QoS trebuie să scadă întârzierile pentru traficul sensibil la întârzieri (voce, video), în timp ce va crește întârzierile traficului insensibil la întârzieri.
Următoarele patru secțiuni voi prezenta mai detaliat aceste caracteristici.
2.2.1. Lățimea de bandă
Termenul de lățime de bandă sau „bandwith” se referă la numărul de biți pe secundă care se așteaptă să fie transmiși cu succes într-o rețea. Termenul este mai larg dar strâns legat de un alt termen „throughput” adică lățimea reală de bandă care se referă la capacitatea reală de transmisie a mediului, adică câți biți se transferă în mod curent pe acest link. Ca formule de calcul avem:
; ;
BW – lățimea de bandă ideală;
P – lățimea de bandă reală;
S – mărimea fișierului în biți;
T – timpul de transfer al unui fișier;
Acest lucru este valabil pentru rețele punct la punct (Point-to-Point). În cazul tehnologiei Frame Relay furnizorii de servicii internet au contractată o anumită lățime de bandă chiar dacă capacitatea fizică de transmisie a rețelei este mai mare. CIR (Committed Information Rate) definește câtă lățime de bandă garantează furnizorul de servicii să asigure clientului sau de la DTE (Data Terminal Equipment) până la capătul fiecărui circuit virtual (VC).
Mecanisme QoS care afectează lățimea de bandă
Cea mai bună soluție QoS pentru soluționarea problemelor legate de lățimea de bandă este mărirea lățimii de bandă! Dar după cum am menționat anterior aceast lucru nu va rezolva toate problemele. De fapt, în rețelele convergente (date, voce, video) creșterea lățimii de bandă duce la scăderea întârzierilor care pot fi soluționate și prin alte metode QoS sau prin implementarea unui bun design QoS. Unul din aceste instrumente este comprimarea pachetelor:
Figura 2.2.1-1. Transmiterea pachetelor cu și fără comprimare
Figura 2.2.1-2. Transmiterea pachetelor cu și fără comprimare (continuare)
Lucrul care se poate întâmpla în cazul neutilizării comprimării este umplerea cozii de așteptare și aruncarea pachetelor.
Un alt instrument este CAC (Call Admision Control). Acesta poate decide dacă rețeaua mai poate accepta noi convorbiri telefonice sau transmisii video. De exemplu, rețeaua poate accepta doar trei apeluri de VOIP (voice over IP) de tip G.729A pe o anumită cale; CAC va fi folosit pentru fiecare apel și atunci cînd acestea vor depăși numărul maxim apelurile noi nu vor fi acceptate.
Tehnicile de formare a cozilor de prioritate alocă o anumită lățime de bandă pentru fiecare coadă în parte. De exemplu, alocarea 75% din trafic unei cozi și a 25% altei cozi.
Figura 2.2.1-3. Rezervarea lățimii de bandă folosind cozi de așteptare
2.2.2. Întârzierea
Într-o rețea orice pachet experimentează anumite întârzieri din momentul în care este trimis de la sursă pînă ajunge la destinație. Majoritatea conceptelor QoS sunt legate mai mult sau mai puțin de întârzierile care apar într-o rețea. Întîrzierile pot apărea în mai multe locuri într-o rețea; în anumite locuri nu se simt dar în altele au un impact negativ asupra performanțelor rețelei. Există următoarele tipuri de întârzieri:
1. De serializare (fixă)
2. De propagare (fixă)
3. De folosire a cozilor (variabilă)
4. De procesare (variabilă)
5. De ajustare (variabilă)
6. De rețea (variabilă)
7. De codec (fixă)
8. De compresie (variabilă)
Voi încerca să explic detaliat tipurile de întârzieri de mai sus pe următoarea topologie de rețea. Să presupunem că avem o rețea locală LAN în Oradea, România, care este legată prin linii închiriate de alte LAN-uri din Europa, cel mai aproape ca distanță fiind în Italia:
Figura 2.2.2-1 Topologia de rețea WAN pe care se vor calcula timpii de întârziere
1. Întârzierea de serializare – este legată de timpii de întârziere care apar la plasarea (codificarea) biților în mediu prin care se propagă. Dacă interfața e rapidă timpul de întârziere este mai mic. Folosim următoarea formulă pentru calculul acestor timpi:
#biții trimiși/ Viteza link
Să presupunem că vom trimite un pachet de 125-octeți de la Oradea spre server-ul care se află în Milano. Oradea trimite pachetul de 125-octeți echivalentul a 1000 biți, la viteza link-ului de Ethernet timpul va fi 1000 biți/100000000 bps, sau .01 ms pentru serializarea pachetului. De asemenea, se va întârzia cu .01 ms când switch-ul trimite pachetul la R1. Când pachetul părăsește R1 (Oradea) pentru R2 (București) pe un link serial de 56 kbps, întârzierea de serializare devine 1000 biți/56000 bps sau 17.85 ms. Legătura între București și Milano este o linie serială de 2 Mbps, deci vom avea o întârziere 1000 biți/2000000 bps sau 0.5 ms. La un pachet de 1500-octeți vom avea: 0.12 ms pe FastEthernet, 267 ms între Oradea și București, 0.75 ms pe seriala între București și Milano.
2. Întârzierea de propagare – ține de întârzierea care apare din momentul în care un bit părăsește sursa și momentul în care acest bit ajunge la destinație. Pentru distanțe mici aceste valori sunt neglijabile, la nivelul miilor de metri valorile cresc. Cea mai importantă variabilă care afectează întârzierea de propagare este lungimea link-ului. Astfel avem următoarele formule de calcul:
;
;
Unde este viteza luminii în vid; mulți folosesc a doua formulă atunci când este nevoie de mai multă exactitate; fiind viteza de propagare a luminii în mediul de cupru și mediu optic.
Pentru distanțele din figura de mai sus vom avea următoarele întârzieri:
Oradea – București = 3.1 ms
București – Milano = 8.75 ms
Total = 11.85 ms
3. Întârzierea de folosire a cozilor (Queuing Delay) – constă în timpul de întârziere care apare la așteptarea pachetelor în cozi, în special la ieșirea din router, așteptarea la intrare fiind minimă. Totuși, acest tip de întârziere poate fi destul de mare de ordinul sutelor de milisecunde sau chiar mai mult. Pachete fară prioritate vor aștepta mai mult facilitând astfel calitatea serviciilor de voce și video.
Să presupunem că trimitem patru pachete de 1500 octeți de la R1 (Oradea) la R2 (București). Deoarece întârzierea de serializare este de 1500*8/56,000 sau 214 ms pentru serializarea fiecărui pachet de 1500 octeți, următorul pachet fie va fi stocat în memorie fie va fi aruncat. Router-ele folosesc memoria RAM pentru păstrarea pachetelor. Cea mai simplă formă de păstrare este sub forma unei cozi FIFO (First-In, First-Out). După 856 ms, toate cele patru pachete vor fi trimise pe legătura serială. Presupunând că rețeaua nu a fost ocupată când am trimis cele patru pachete nu vom avea întârziere pentru primul pachet, cel de al doilea pachet va aștepta timpul de serializare al primului, adică 214 ms, al treilea 428 ms și al patrulea 642 ms. Fără a funcția de plasare a pachetelor în coadă ele trebuia să fie aruncate și probabil retransmise de mai multe ori.
4. Întârzierea de procesare (Forwarding delay) – se referă la întârzierea care apare la plasarea sau procesarea pachetului de la o interfață la alta și exclude întârzierea de folosire a cozilor. Aceasta se datorează timpilor de scoatere a pachetelui de nivel 3 OSI (IP) din pachetul specific interfeței de nivel 2, de exemplu, extragerea pachetului IP din frame-ul Ethernet și plasarea acestuia pe o altă interfață, spre exemplu, serială după identificarea destinației și asigurarea că acest pachet IP poate trece de listele de acces.
5. Întârzierea de ajustare (shaping delay) – se datorează tehnicilor QoS de ajustare a traficului. Ajustarea se produce atunci când traficul este mare și umple cozile de așteptare a router-ului destinație, router-ul sursă va fi astfel anunțat să încetinească trimiterea pachetelor. În cazul în care viteza de transmisie nu scade pachetele sunt aruncate și va fi nevoie de retransmiterea lor, valabil doar în cazul unui transfer cu capacități de recunoaștere a pierderilor și de retrimitere de pachete cum este TCP la Nivelul 4 OSI. Dacă această capabilitate ar lipsi, în multe cazuri în care s-ar depăși rata de transfer contractată de la furnizorul de servicii internet acesta din urmă ar arunca pachetele.
6-8. Întârzierea de codec și cea de compresie se întâlnesc mai des în rețelele de video și voce.
Tabelul de mai jos sumarizează tipurile de întârzieri.
Tabelul 2.2.2-1 Tipuri de întârzieri
Mecanisme QoS care afectează întârzierea
Soluția ideală pentru acest tip de întârziere ar fi din nou lățimea de bandă. Lățimea de bandă mai mare va diminiua întârzierea de serializare de care depinde întârzierea de așteptare în cozi. În rețelele Frame Relay o lățime de bandă contractată mai mare înseamnă diminuarea întârzierilor de ajustare.
Tabelul 2.2.2-2 Instrumente QoS ce afectează întârzierea
2.2.3. Jitter-ul
Pachetele consecutive care experimentează timpi diferiți de întârziere sunt cele care generează jitter-ul. Într-o rețea de date unde există timpi diferiți de întârziere jitter-ul există; întrebarea este unde ar fi limita la care jitter-ul existent nu ar afecta serviciile din rețea. Rețelele de voce peste date necesită o transmisie uniformă a pachetelor (de exemplu la fiecare 20ms), în caz contrar apare degradarea serviciului de telefonie IP. Aceleași instrumente care afectează întârzierea pot fi utilizate cu succes și în cazul jitter-ului.
2.2.4. Aruncarea pachetelor
O ultimă caracteristică care afectează performanțele unei rețele este aruncarea pachetelor. Router-ele aruncă pachete în multe cazuri, spre exemplu, atunci când FCS (Frame Check Sequence) nu este cel așteptat, sau pachetul respectiv nu trebuie să ajungă la destinație respectivă datorită politicilor de securitate…și cu aceste pierderi de pachete QoS nu poate face nimic. Dar exista și situații când pachetele pot fi salvate de la aruncare prin QoS și unul din aceste cazuri este atunci când aruncarea pachetelor are loc datorită umplerii cozilor sau memoriei router-elor.
Mecanisme QoS care afectează aruncarea pachetelor
Ca și în cazul celorlalte caracteristici de performanță, aruncarea pachetelor poate fi evitată prin lățimea de bandă…o mai mare lățime de bandă va duce la scăderea dimensiunii cozilor și la diminuarea riscului umplerii lor. Totuși, într-o rețea convergentă (voce, date, video) vor apărea probleme și după dublarea sau triplarea lățimii de bandă. O soluție fiabilă pusă la dispoziție de QoS este RED (Random Early Detection).
2.3. Caracteristicile traficului de voce și date
De ce am avea nevoie de QoS? QoS poate afecta lățimea de bandă, întârzierile, jitter-ul și aruncarea pachetelor. Aplicațiile au nevoie de cerințe diferite pentru parametrii enumerați anterior. Cu ajutorul QoS o rețea poate asigura mai bine fiecare aplicație cu necesarul ei de resurse.
2.3.1. Caracteristicile traficului de voce și QoS
Traficul de voce poate fi alterat repede în rețelele unde lipsește QoS. În această secțiune voi încerca să explic modul în care mecanismele QoS afectează traficul de voce. Fără QoS, cel care este sunat experimentează un apel slab. Vocea devine sacadată și de neînțeles. Întârzierile provoacă interactivitate scăzută, din cauza faptului că aceia care discută nu-și dau seama dacă interlocutorul lor a terminat sau nu fraza. Se pierde vocea, fiind auzite pauze în loc de voce. Apelul poate fi chiar intrerupt.
Bazele traficului de voce
Vocea peste date include Vocea peste IP (VoIP), Vocea peste Frame Relay (VoFr) și Vocea peste ATM (VoATM). Toate aceste trei tehnologii transportă voce dar fiecare diferit. Cea pe care vom pune accent este VoIP din cauza faptului că ea este folosită la transportul pachetelor între telefoanele IP.
În imaginea de mai jos voi prezenta un apel telefonic folosind VoIP de la Oradea în Milano.
Figura 2.3.1-1 Topologia de rețea WAN pe care se va prezenta VoIP
Înainte de a fi auzită vocea în celălalt capăt trebuie să se întâmple mai multe lucruri. Utilizatorul trebuie să formeze numărul. Router-ul conectat la telefon interpretează digiții și folosește semnalizarea pentru a crea un apel VoIP. Deoarece ambele telefoane sunt conectate prin porturi analogice la R1 și R3, router-ele vor folosi semnalizarea H.323. La o anumită etapă a procesului de semnalizare apelatul aude sunetul telefonului și după ce ridică receptorul procesul de creare a apelului se încheie. Vocea care se aude acum la telefon folosește protocolul RTP (Real-time Transport Protocol).
În figura de mai jos voi prezenta structura pachetului IP folosind RTP:
Figura 2.3.1-2 Structura pachetului IP folosind RTP
Atunci când se folosesc telefoanele analogice, router-ul va colecta semnalul analogic, va digitaliza vocea, o va codifica folosind un codec de voce și va plasa vocea codificată în câmpul de voce din figura de mai sus. Adresa sursa IP va fi cea a router-ului R1 și adresa destinație va fi adresa R3. R3 va executa procesul invers față de R1 și va plasa semnalul sonor pe interfața spre telefon.
Telefoanele pe IP vor experimenta un proces similar chiar dacă detaliile diferă puțin. Procesul de semnalizare include folosirea protocolului SSCP (Skinny Station Control Protocol) care asigură fluxul de voce între telefoane și server-ul Cisco Call Manager (CCM). După ce semnalizarea a luat sfârșit, un flux RTP a fost creat între telefoane și nu mai este nevoie de CCM el fiind necesar la stabilirea conexiunii. R1 și R3 nu au un rol în stabilirea fluxului RTP și în crearea acestor pachete, deoarece telefoanele IP sunt capabile să creeze singure aceste pachete. În final administratorul de rețea poate alege diferite metode de codificare și decodificare a vocii pentru apelurile de VoIP. Codec-urile procesează semnalul analogic și îl convertesc într-unul digital (binar). Valoarea binară a reprezentării vocii depinde de codec-ul utilizat. Fiecare codec are mai multe proprietăți, una din cele mai importante este lățimea de bandă utilizată pentru transmiterea vocii codificate.
Tabelul de mai jos listează cele mai populare codec-uri și lățimea de bandă necesară pentru fiecare.
Tabelul 2.3.1-1 Codecuri și lățimea de bandă pentru transportul de voce
De remarcat este faptul că rata utilizării de bandă conține doar partea pachetului IP ce conține voce digitalizată.
În esență traficul de voce are următoarele elemente esențiale:
mai multe tipuri de protocoale de semnalizare stabilesc o conexiune RTP între două telefoane, ca și consecință a formării numărului de telefon conexiunea RTP transmite vocea între două telefoane (sau între două echipamente VoIP). Aceste două elemente au nevoie de diferite mecanisme QoS pentru a funcționa corect. În continuare când mă voi referi la voce voi folosi termenul de trafic de voce pentru conexiunea RTP. Semnalizarea de voce este traficul pentru crearea acestei conexiuni.
Mecanismele QoS pot trata vocea în mod diferit de traficul de semnalizare voce. Pentru a face acest lucru fiecare din uneltele QoS va clasifica traficul în una din aceste două categorii. Pentru această clasificare QoS folosește informațiile din tabelul de mai jos care reprezintă protocoalele și porturile care sunt utilizate de VoIP.
Tabelul 2.3.1-2 Protocoalele utilizate de VoIP
2.3.2. Caracteristicile traficului de date și QoS
Sute de mii de aplicații există la oră actuală și fiecare dintre ele sunt diferite. Unele sunt bazate pe TCP altele pe UDP, unele sunt tolerante la întârzieri altele nu, unele trimit datele în rafale altele au nevoie de un trafic constant, etc.
Caracteristicile traficului de date variază de la o aplicație la alta. Mai mult ele variază și în cadrul mai multor versiuni ale aceleiași aplicații. Ca de exemplu o companie producătoare de componente electronice care folosit QoS pentru voce și date critice (SAP/V3) a constat că totul a merge bine aproximativ șase luni. După această perioadă au apărut plângeri ale utilizatorilor că nu puteau efectua sarcini uzuale în timp util și trebuia să aștepte enorm pentru o simplă interogare. Echipele de suport de aplicații au intervenit și au exercitat presiuni asupra echipelor de administrare a rețelei. După o investigație s-a descoperit o schimpare dramatică a caracteristicilor de trafic înversiunea nouă, proaspăt instalată de SAP.
Figura de mai jos arată aceste diferențe:
Figura 2.3.2-1 Diferențele caracteristicilor de trafic între versiunile aceleiași aplicații
În acest exemplu după ce s-a trecut de la versiunea 4.6C fără folosirea memoriei tampon la versiune 4.6C HTML a fost nevoie de 35 de ori mai mult trafic decît la versiunea anterioră. În consecință QoS a trebuit să fie adaptat noilor cerințe ale aplicației.
Din exemplul de mai sus ne putem da seama că pentru clasificarea traficului de date este nevoie de mare atenție. Din cauza acestei realități cercetătorii QoS au definit patru clase de trafic de date. Aceste clase sunt: Date tip Best-Effort, Date Mari, Date tip tranzacție sau interactive și Date definite local Critice. Fiecare din aceste clase sunt examinate mai jos:
Date Best-Effort
Atunci când aplicăm QoS pentru traficul de tip Best-Effort sunt recomandate următoarele sfaturi:
Acest trafic este marcat cu DSCP 0.
Acestui trafic trebuie acordată o lățime de bandă de aproximativ 25% din cauza
faptului că o mare parte din aplicații aparțin acestei categorii de trafic.
Traficul de date aparține implicit acestei clase doar aplicațiile care sunt selectate pentru un trafic preferențial aparțin de alte clase.
Date Mari
Implementarea QoS pentru acest tip de trafic trebuie să țină cont de următoarele reguli:
trebuie să fie marcate cu DSCP AF11; în cazul exesului de trafic se remarchează
cu AF12 sau AF13.
trebuie să-i fie garantată o lățime de bandă moderată și trebuie să fie constrâns să nu ocupe toată lățimea de bandă disponibilă.
În această clasă intră aplicații care nu sunt interactive și nu sunt tolerante la aruncarea de pachete, de obicei au o durată de transfer mai lungă a datelor prin rețea. Ca de exemplu FTP, email, aplicațiile de backup, sincronizarea bazelor de date.
Avantajul asigurării unei lățimi de bandă moderate este că în orele cînd banda este liberă acest trafic poate folosi întreaga bandă și când banda este ocupată folosesc doar limita disponibilă.
Date tip tranzacție sau interactive
Implementarea QoS pentru acest tip de trafic trebuie să țină cont de următoarele reguli:
Datele tip tranzacție/interactive trebuie să fie marcate cu DSCP AF21;traficul în exces trebuie marcat din nou cu DSCP AF22 sau AF23
Datele de acest tip trebuie să posede o lățime de bandă garantată.
Acest tip de trafic este compus din datele tranzacționale și datele interactive ale aplicațiilor client/server sau de mesagerie interactivă.
Timpii de răspuns separă alicațiile cu date tranzacționale client/server de aplicațiile generice client/server. De exemplu în aplicații precum SAP, PeopleSoft, Oracle utilizatorii așteaptă terminarea unei operații înainte de a o putea începe pe următoarea (cu alte cuvinte tranzacția e o operație care nu este ascunsă).
Date definite local Critice
Implementarea QoS pentru acest tip de trafic trebuie să țină cont de următoarele reguli:
Acest tip de date trebuie marcat cu DSCP AF31; traficul în exces trebuie marcat cu DSCP AF32 sau AF33. Traficul de semnalizare pentru VoIP folosește DSCP 31; până se va rezolva această coincidență traficul definit local critic va putea fi marcat cu DSCP 25.
Acest tip de trafic are nevoie de o garantare a lățimii de bandă pentru traficul interactiv pe care-l suportă.
Această clasă de trafic este probabil cea mai confuză în sensul determinării carui tip de trafic îi aparține. Astfel, ea se definiște ca fiind traficul critic pentru organizația respectivă care îi asigură cerințele de trafic pentru afacere și fără prioritizarea acestui trafic afacerea ar avea de suferit. Este recomandată plasarea unui număr cât mai mic de aplicații în această clasă de trafic.
Tabelul de mai jos reprezintă rezumatul caracteristicilor de trafic pentru anumite aplicații și clasa în care s-ar potrivi cel mai bine:
Tabelul 2.3.2-1 Clasa și caracteristicile de trafic pentru anumite aplicații
=== Capitolul 3 ===
Capitolul 3: Mecanismele QoS
Primul pas în definirea politicilor QoS este de a identifica traficul care trebuie să fie tratat diferit (preferențial sau diferențial). Acest lucru se realizează prin clasificare și marcare.
Termenii clasificare și marcare sunt deseori interpretați ca fiind identici. Ei se disting chiar dacă sunt folosiți împreună.
Clasificarea – sortează pachetele în tipuri de trafic diferit, pe care se pot aplica diferite politici. Clasificare are loc de obicei în toate nodurile rețelei dar nu este obligatorie peste tot. Clasificarea pachetelor poate avea loc și fără marcare.
Marcarea – tipic este folosită pentru delimitarea limitelor de încredere (trust). Poate fi folosită și în alte locuri în rețea. Nu este întotdeauna legată doar de clasificare.
Aceste două mecanisme sunt puse în practică prin clasificatori și marcatori care execută efectiv operațiile de marcare și clasificare și care au corespondenți în comenșile CLI de pe Cisco IOS.
3.1. Clasificarea
Mecanismele de clasificare examinează oricare din criteriile de mai jos pentru a identifica un flux și ai asigna un tratament diferențial sau preferențial.
Parametri de Nivel 1 – interfața fizică, subinterfață, PVC, sau port.
Parametri de Nivel 2 – adresa MAC, biții CoS, identificarea VLAN, biții MPLS experimentali, CLP din ATM, Frame Relay biții DE.
Parametri de Nivel 3 – IP Precedence, codul DiffServ DSCP, adresa IP sursă/destinație.
Parametri de Nivel 4 – porturile TCP sau UDP
Parametri de Nivel 7 – semnăturile aplicațiilor sau URL-urile în pachete
După ce traficul a fost corect identificat poate fi tratat prin anumite politici. Cele mai bune practici recomandă să identificăm și să marcăm traficul cu valori DSCP cît mai aproape de sursă. Dacă clasificare are loc corect nodurile care urmeză nu vor mai trebui să examineze în detaliu fiecare pachet sau frame. În schimb ele pot aplica deja politici pentru traficul clasificat.
CLI pentru clasificare
Ca și parte integrantă a sistemului de operare Cisco IOS, modulul MQC vine cu comenzile de tip class map pentru a efectua clasificarea traficului. Comanda permite identificarea fluxului prin mai multe criterii, aceste criterii pot fi selectate toate sau separat prin cuvântul cheie match.
match-all – operația logică ȘI, care înseamnă că toate condițiile trebuie să fie adevărate în același timp pentru ca maparea să aibă loc.
mach-any – operația logică SAU, oricare din condițiile clasei care este adevărată va face ca maparea să fie validă.
Exemplul de mai jos permite înțelegerea mai ușoară a conceptului de clasificare:
Exemplul 3.1-1 Aplicarea CLI pentru clasificare pe un router Cisco
Mai sus se definesc trei mapări de clase diferite. Prima clasă, este clasa ERP, care va mapa traficul ce corespunde cu protocoalele (sqlnet, ftp, telnet). În clasa AUDIO-VIDEO, clasificarea se va efectua după traficul MIME video sau audio. Ultima clasă de trafic va filtra paginile web care au poze de tip GIF sau JPG.
AutoQoS introduce o tehnică care se numește NBAR și care este capabilă să efectueze clasificarea automată a traficului prin mecanisme de „mirosire” a rețelei.
3.2. Marcarea
Principalele tipuri de marcare folosite astăzi sunt marcarea bazată pe clase și marcarea folosind politicile de clasă. Alte tipuri de marcare mai vechi sunt CAR (Committed Access Rate) și PBR (Policy-Based Routing).
3.2.1. Marcarea bazată pe clase
Marcarea bazată pe clase a fost introdusă în versiunea 12.1(2)T și este reprezentată de comanda din MQC set în cadrul comenzii policy map pentru a marca pachete, frame-uri, celule sau ethichete. Următorul exemplu exemplifică opțiunile pe care le avem în cadrul comenzii set:
Exemplul 3.2.1-1 Utilizarea comenzii set
Este de remarcat faptul că marcarea bazată pe clase are loc după clasificarea pachetelor, adică, set are loc după ce s-a găsit o clasă (match) pentru pachet. Cu alte cuvinte dacă clasificarea are loc pe o interfață de intrare a unui echipament, marcarea va fi implementată pe interfața de ieșire din acel echipament.
3.2.2. Marcarea bazată pe politicile de clasă
Aplicarea de politici și alte mecanisme de ajustare sunt o altă cale de marcare a pachetelor. În loc de a marca fiecare pachet cu o anumită valoare, un marcator de politici va marca sau chiar va arunca orice pachet care nu este în concordanță cu politica pe care o promovează. Următorul exemplu arată sintaxa necesară pentru un limitator de rată care va transmite pachetele doar dacă ele se conformeză politicii sale:
Exemplul 3.2.2-1 Politică de limitare a traficului
Din exemplul de mai sus putem observa că în cazul în care se va viola limita de transmitere pachetele vor fi aruncate. Acest exemplu este tipic pentru configurarea conexiunilor tip Frame Realay. Acest tip de marcare poate seta IP Precedence, DSCP, MPLS EXP, Frame Relay DE, ATM CLP.
Exemplul de mai jos prezintă opțiunile pentru marcarea bazată pe politicile de clasă:
Exemplul 3.2.2-2 Opțiunile pentru marcarea bazată pe politicile de clasă
3.2.3. Marcarea de Nivel 3
Marcarea de Nivel 3 prin DSCP și IP Precedence este cea mai larg răspândită metodă de marcare implementată din cauza faptului că marcarea de Nivel 3 are o semnificație de la capăt la capăt și poate fi translată ușor în marcare de Nivel 2.
IP Precedence
Al patrulea octet din pachetul IP este octetul ToS (Type of Service). Primii trei biți sunt numiți biții IP Precedence. Biții IP Precedence, similar cu cei din standardul 802.1Q/p CoS permit opt valori diferite pentru marcare (0 la 7). Din cauza faptului că valorile 6 și 7 sunt rezervate pentru protocoalele de rutare și valoarea 0 este implicită în realitate se folosesc pentru marcare 5 valori:
IP Precedence cu valoarea 5 este recomandat pentru voce.
IP Precedence cu valoarea 4 este împărțit de video-conferință și fluxul video.
IP Precedence cu valoarea 3 este recomandat pentru semnalizare voce.
Rămân doar două valori pentru traficul de date (1 și 2). Acest lucru pare destul de restrictiv și din această cauză multe firme preferă implementarea DSCP cu 64 de valori posibile.
DSCP (Differentiated Services Code Points)
DSCP folosește aceeași trei biți ca și IP Precedence dar prin combinarea lor cu următorii trei biți din octetul ToS asigură șase biți pentru marcare. De aici valorile DSCP pot fi de la 0 (000000) la 63 (111111). Aceste valori asigură o marcare granulară a traficului.
Valorile DSCP pot fi exprimate numeric sau prin cuvinte cheie, numite PHB (Per-Hop Behaviors). Există trei clase de PHB: Best-Effort (BE sau DSCP 0), Afxy (Assured Forwarding) și EF (Expedited forwarding).
În documentul RFC 2597 este definit termenul de clasă AF, o clasă AF este reprezentă de literele AF și două cifre xy. Prima valoare x poate varia de la 1 la 4 ea formând clase compatibile cu cele IP Precedence. Al doilea digit reprezintă probabilitatea de aruncare a pachetului, spre exemplu AF33 va fi aruncat mai repede decât AF32 care va fi aruncat mai repede decât AF31.
În figura de mai jos este reprezentată maparea de la Codurile PHB la valorile binare DSCP:
Figura 3.2.3-1 Maparea de la Codurile PHB la valorile binare DSCP
3.3. Aplicarea de politici și ajustarea
Tehnicile de aplicare a politicilor și de ajustare sunt formele cele mai vechi ale QoS. Aceste unelte au același obiectiv, și anume, de a identifica și a răspunde la violarea traficului. Ceea ce au diferit este modul cum reacționează la aceste nereguli.
Tehnicile de aplicare a politicilor – sunt cele care realizează o verificare în timp real a traficului și în cazul în care detectează nereguli aplică acțiunile prescrise. De exemplu, se poate detecta excesul unei rate de trafic definit și în acest caz se vor remarca pachetele și se vor arunca. Figura de mai jos reprezintă comparația între aceste două tehnici:
Figura 3.3-1 Comparație între aplicarea de politici și ajustare
Ajustarea – este un mecanism de rearanjare și rafinare a traficului care lucrează împreună cu mecanismale de plasare în coadă. Obiectivul este ca tot traficul să fie trimis mai departe sub o anumită rată pentru a nu fi aruncat. Acest mecanism se folosește pe router-ele de la ieșirea din rețeaua privată în cea a furnizorului de servicii internet. Contractul este făcut pentru o anumită rată la tehnologia Frame Relay este numită CIR, dacă această rată ese depășită atunci pachetele care vin în exces sunt aruncate. Pentru a nu se pierde aceste pachete se folosește tehnica de ajustare.
Mai jos voi prezenta o comparație între aplicarea de politici și ajustare.
Tabelul 3.3-1 Caracteristici Aplicarea de Politici și Ajustare
3.4. Mecanismele de Management al congestiei
Dintre toate mecanismele QoS tehnicile de management a congestiei asigură cel mai mare impact asupra funcționării aplicațiilor de rețea. Aceste tehnici se numesc și tehnici de plasare în coadă și se aplică pe interfețele unde este experimentată o congestie de trafic. Întotdeauna pachetele intră pe interfață mai repede decât ies și deci riscul ca să se creeze o congestie există.
Este important de remarcat că aceste tehnici se activează atunci cînd apare congestionarea rețelei pe o interfață. Dacă nu există congestie pachetele sunt trimise mai departe imediat ce sosesc pe interfața de intrare. Atunci când are loc congestia, pachetele trebuie plasate în memorii tampon sau în cozi pentru a evita aruncarea.
Planificarea și Plasarea în Cozi
Planificarea se referă la modul în care un pachet sau un frame părăsește echipamentul de rețea. Acest termen se referă la rearanjarea pachetelor funcție de priorități la ieșire. De exemplu, intrarea pachetelor pe o interfață a unui router care separă un LAN de un WAN are loc mult mai rapid decât ieșirea. Pentru ca traficul critic să poată ajunge în timp until la destinație este nevoie de plasarea traficului fără prioritate în memorii tampon și plasarea pe interfața de ieșire a traficului prioritar.
Figura de mai jos arată acest proces:
Figura 3.4-1 Plasarea în Cozi și Planificarea
Prin definiție plasarea în cozi și planificarea sunt complementare, însă acțiunile lor se împletesc pentru a da rezultatele calității rețelelor moderne:
Plasarea în cozi – se ocupă de plasărea pachetelor în diferite cozi legate de tampoanele de memorie. Este important de remarcat că plasarea în cozi este activată doar cînd există congestie și este dezactivată în scurt timp după ce congestia dispare.
Planificarea – este mecanismul care implică decizia cu privire la ce pachet să fie trimis următorul. Planificarea are loc cînd este congestie și atunci cînd nu este congestie. Atunci cînd există congestie planificarea trebuie să decidă care din cozile deservite va furniza următorul pachet pentru trimitere. Aceste decizii se iau pe baza următorilor algoritmi:
De strictă prioritate – cozile fără prioritate sunt servite doar dacă cozile de strictă prioritate sunt goale. Acest tip de planificare crește riscul congestiei în cozile neprioritare,
Round-Robin – cozile sunt servite la rînd pentru anumite intervale de zimp. Acest tip de planificare poate duce la umplerea cozilor cu trafic strict prioritar.
Prin cântărire – pachetele sunt „cântărite” după IP Precedence și astfel anumite cozi sunt servite mai des decât altele. Acest tip de planificare rezolvă problemele celorlalte două tehnici. El însă nu rezolvă garantarea lățimii de bandă de care are nevoie traficul prioritar.
3.5. Mecanismele de Evitare a congestiei
Mecanismele de evitare a congestiei, ca de exemplu WRED, sunt complementare și dependente de tehnicile de plasare a pachetelor în cozi. Plasarea în coadă sau planificarea se ocupă de capetele cozii pe când evitarea congestiei se ocupă de mijlocul sau „corpul” cozii.
Evitarea congestiei este destinată să gestioneze traficul TCP. TCP are un mecanism de retransmisie care crește rata de transmisie a traficului până cînd are loc aruncarea de pachete. Acest lucru se întâmplă de obicei cu traficul care are date mari (fișiere mari). Dacă se încearcă retransmiterea lor se ajunge la cosumarea întregii lățimi de bandă pentru trafic neprioritar care duce la congestionarea generală a rețelei.
Mecanismul RED (Random Early Detection)
Mecanismul RED calculează efectul sincronizarii globale TCP aruncând pachete alese aleator pentru a preântâmpina umplerea cozilor. Aruncarea aleatoare de pachete este mult mai bună decât aruncarea tuturor pachetelor și retransmiterea lor din nou prin TCP.
În loc de a aștepta umplerea tampoanelor de memorie ale cozilor pentru a arunca pachete, routerul folosește RED pentru a detecta traficul care poate duce la umplere și a arunca pachete din el. La tehnologia Frame Relay se aruncă pachetele marcate cu DE (Discard Eligible) și care de obicei nu sunt prioritare și nu au impact asupra traficului critic.
Sistemul de operare Cisco IOS implementează o tehnologie evoluată din RED care se numește WRED (Weighted RED) și care face același lucru prin algoritmi mai complecși de detectare și aruncare a pachetelor ce pot duce la umplera cozilor.
Mecanismul WRED (Weighted Random Early Detection)
WRED este o tehnică îmbunătățită față de RED care are o mai mare influență asupra alegerii aleatoare a pachetelor care trebuie aruncate. WRED ia în cosiderație valorile IP Precedence pentru a selecta pachetele pentru aruncare.
Implicit, WRED aruncă pachetele cu o valoare mai mică IPP mai des decît pachetele cu o valoare mai mare.
WRED poate fi configurată pe interfață dar este recomandată utilizarea ei împreună cu setul MQC pentru că acest lucru duce la creșterea granularității și posibilității de control a algoritmului.
Mecanismul ECN (Explicit Congestion Notification)
În mod tradițional, singura cale de a informa stația care transmite că a avut loc o congestie în rețea era să arunci pachetele TCP.
RFC 3168 definește o nouă metodă mult mai eficientă pentru rețea dea a comunica congestia stației care transmite. Această metodă constă în adăugarea biților ECN la pachetul IP. Prin marcarea ultimilor doi biți ai octetului ToS din IP, echipamentele de rețea pot comunica între ele și la stațiile care transmit că ele experimentează o congestie. Acești doi biți se definesc:
bitul ECN – Capable Transport (ECT) – indică dacă acest echipament suportă ECN.
bitul CE (Congestion Experienced) – indică dacă congestia a avut log pe ruta pachetului.
În perioada congestiei, WRED și WRED bazat pe DSCP aruncă pachetele care depășesc o anumită limită de aruncare. ECN ca și extinsie a WRED marcheză pachetele, îl loc de a le arunca pentru a semnala congestia atunci cînd se depășește limita de aruncare. Routerele care sunt capabile să suporte combinația WRED și ECN au instalat sistemul de operare Cisco IOS 12.2(8)T sau mai mare. În acest fel ratele de transmisie TCP pot fi controlate fără aruncarea pachetelor sau aruncarea parțială.
Combinația WRED ECN ia următoarele acțiuni atunci când este activată:
Dacă numărul pachetelor în coadă este mai mic decît limita minimă de aruncare, pachetele sunt transmise. Acest lucru are loc dacă ECN este sau nu activat. Acest tratament este identic cu situația în care ar fi activat doar WRED.
Dacă numărul pachetelor în coadă este între limita minimă și cea maximă se pot întâmpla următoarele lucruri:
Dacă ECT arată că ambele capete ale fluxului de rețea sunt capabile ECN (ECT=1) și WRED a determinat faptul că pachetul trebuie să fie aruncat, biții ECT și CE sunt setați pe 1 și transmiși. Pachetele sunt marcate în loc de a fi aruncate.
Dacă bitul ECT este 0 adică nu este suportat ECN pe ambele capete, pachetele încep să fie aruncate conform WRED.
Dacă ambii biți sunt setați pe 1 ECT și CE atunci pachetul este transmis fără nici o setare.
Dacă limita de aruncare maximă este atinsă toate pachetele vor fi aruncate indiferent de ENC sau CE până la stabilirea traficului mai jos de limita maximă.
Pentru activarea combinației WRED și ECN vom folosi sintaxa random-detect ecn ca în exemplul de mai jos:
Exemplul 3.5-1 Folosirea WRED și ECN
=== Capitolul 4 ===
Capitolul 4: QoS în rețeaua locală (LAN)
4.1. Mecanisme QoS în LAN
4.1.1. Necesitatea aplicării QoS în LAN
Aplicarea QoS în LAN este deseori înțeleasă greșit și pare lipsită de sens pentru o bună parte din administratorii de rețea. Dacă avem în plan extinderea rețelei de voce și de video-conferințe peste cea de date, ar trebui să acordăm prioritate strategiilor de QoS aplicate în rețeaua locală. Această planificare va duce la un succes sau la o nereușită a proiectului în fața utilizatorului final.
În acest capitol voi aborda nevoia pentru QoS în rețeaua locală și voi discuta următoarele noțiuni existente:
Prioritizare de nivel 2 (CoS)
Mapare între nivelul 2 și nivelul 3 (DSCP-to-CoS)
Cozi de nivelul 2
Nivele de aruncare
Limite de încredere
Umplerea memoriilor tampon
Presupunem că este luni dimineața, ora 8:30. Majoritatea colegilor de muncă, care sunt mai mulți de o sută, pornesc calculatoarele simultan și își încep ziua de muncă. Traficul generat trece printr-un switch de nivel de acces (modelul Cisco) și converge într-un switch de nivel de distribuție. Pentru un anumit interval de timp, ceea ce se întâmplă este aruncarea pachetelor la ieșirea din switch-ul de nivel de acces spre switch-ul de nivel de distribuție. Într-o rețea tipică TCP/IP acest lucru nu este o problemă deoarece pachetele sunt retransmise. Într-o rețea compusă din aplicații în timp real, așa cum este telefonia IP și conferințele video, umplerea tampoanelor de memorie poate afecta calitatea serviciilor de sunet și video.
Într-un mediu de telefonie IP Cisco, procesorul de semnal G.729 (DSP) poate reconstrui până la 30 ms din pierderea de voce. Dacă a fost adoptat standardul Cisco de 20 ms pe pachet atunci un singur pachet se poate pierde fără a afecta calitatea vocii, dacă se pierd două pachete consecutive, rezultă o pierdere de 40 ms care nu poate fi compensată de algoritmul G.729 și o degradare a vocii în conversație. În cazul în care protocolul de timp real RTP va transporta informații de la un fax sau un modem, o pierdere de pachet va însemna o resincronizare a modemului, iar două vor duce la pierderea conexiunii.
Clasificând aplicațiile de timp real în rețeaua locală și asigurându-le un nivel corespunzător de prioritate, putem evita aceste probleme. Instrumentele QoS sunt necesare pentru manipularea acestor tampoane de memorie, pentru minimizarea aruncării de pachete, întîrzierii și jiter-ului. Lățimea de bandă nu este un înlocuitor pentru QoS în LAN!
4.1.2. Clasificarea și marcarea pachetelor
Clasificarea și marcarea de nivel 2 are loc în al 3-lea bit din câmpul numit Clasa Serviciului (CoS), care este în interiorul frame-ului Ethernet. CoS există în interiorul pachetelor atunci când este utilizat mecanismul de trunking folosit pentru comunicarea între mai multe LAN-uri virtuale figura 4.1.2-1. Există două tipuri de mecanisme de marcare a pachetelor pe o legătură trunk unul este ISL (Inter Switch Link) sau 802.1q. Câmpul CoS poate fi folosit pentru setarea a opt valori binare diferite care pot fi utilizate de celelalte instrumente QoS.
Figura 4.1.2-1 Prezentarea unei legături de trunk
Traficul reprezentat în figură poate fi de la un VLAN de voce și alte două de date, sau un VLAN de voce, altul video, și un al treilea de date. Pe legătura de trunk vom avea identificatori pentru pachetele care provin din vlan-uri diferite. Astfel, după cum am menționat mai sus vom avea fie încapsularea ISL, fie 802.1q a căror format este prezentat în figura de mai jos:
Figura 4.1.2-2 Formatul pachetelor folosite pe legătura de trunk
În figură se observă ca formatul ISL nu modifică frame-ul ethernet original ci doar îi atașează informații adiționale, acest mecanism este utilizat pe echipamentele Cisco. 802.1q este un standart ANSI și este folosit pe echipamentele Cisco și alte tipuri de echipamente făcându-le compatibile. Marcarea pachetelor de Nivel 3 are loc în interiorul câmpului Tipul Serviciului (ToS) sau Serviciu Diferențiat (DS) în pachetul IP.
Mapare între nivelul 2 și nivelul 3 (DSCP-to-CoS)
Swith-urile de Nivel 2 vor aplica QoS pe baza câmpului CoS în frame-ul Ethernet fără a lua în considerare marcarea pachetelor IP. După cum am discutat anterior, când un pachet iese pe interfața unui router care nu este configurată ca și 802.1q trunk, valoarea CoS nu există. Switch-ul care va primi acest pachet va marca valoarea CoS ca și 0, de asemenea, DSCP va fi la valoarea EF. Dacă switch-ul nu va reuși să clasifice pachetele la Nivel 3 aceste pachete vor trece drept trafic normal chiar dacă fac parte dintr-un trafic prioritar.
Pentru soluționarea acestei probleme trebuie mapată marcarea pachetelor de Nivel 3 la cea de Nivel 2 pe router și plasată o legătură trunk între switch și router în așa fel încât switch-ul de Nivel 2 să fie capabil să distingă traficul prioritar de cel fără prioritate. În figura de mai jos este prezentată o configurație de pe un router care este conectat cu un switch de Nivel 2.
class-map cos3
match cos 3
!
class-map cos5
match cos 5
!
class-map EF
match ip dscp EF
!
class-map AF31
match ip dscp AF31
policy-map map-cos-to-dscp
class cos5
set ip DSCP EF
class cos3
set ip dscp af31
class class-default
set ip dscp default
!
policy-map map-dscp-to-cos
class EF
set cos 5
class AF31
set cos 3
class class-default
set cos 0
!
interface FastEthernet0/0
!
interface FastEthernet0/0.1
encapsulation dot1Q 2
service-policy input map-cos-to-dscp
service-policy output map-dscp-to-cos
!
interface FastEthernet0/0.2
encapsulation dot1Q 2 native
Figura 4.1.2-3 Configurația unui router necesară pentru maparea între Nivelul 3 și 2 OSI
În figura de mai sus definirea politicii de mapare (policy-map map-dscp-to-cos) va lua în cosiderare trei valori pentru DSCP care trebuie mapate în CoS: pentru valoarea EF se va marca CoS 5, pentru AF31 se va marca CoS 3 și respectiv pentru valoarea implicită CoS va fi 0. De asemenea, această politică se aplică pe interfața router-ului care face legătura cu switch-ul de nivel 2. Nu am folosit această mapare în cazul rețelei pe care o administrez din cauza folosirii switch-urilor de Nivel 3 care fac automat această mapare. După ce s-a stabilit din ce clasă face parte pachetul urmează ca acesta să fie direcționat spre coada corespunzătoare de celelalte mecanisme QoS.
4.1.3. Cozile de așteptare de Nivel 2
Chiar dacă există similarități între router-e și switch-uri, o perspectivă diferită ne va ajuta să înțelegem mai bine problemele care apar la cozile de așteptare în LAN. Cozile de nivel 2 sunt ca niște containere care colectează pachete înainte ca acestea să fie transportate. Cu cât e mai mare containerul cu atât încap mai multe pachete în el. Într-un switch care are o coadă, la care ne vom referi cu 1q, de exemplu, tot traficul va fi plasat într-o singură coadă fără a se ține cont de clasificare și va fi deservit după principiul FIFO (First-In, First-Out). Dacă pachetul ajunge în coadă când aceasta este supraîncărcată, el poate fi aruncat dacă coada numai poate păstra pachete.
Dacă se utilizează cozi multiple pe o interfață a unui switch acestea vor folosi aceeași memorie tampon limitată pentru a aloca spațiu de memorie pentru fiecare coadă. Putem însă proteja traficul de voce plasând pachetele sensibile la întârzieri într-o coadă și restul traficului în altă coadă. De exemplu, switch-ul care folosește două cozi la care ne vom referi ca și 2 q, este capabil să direcționeze tot traficul care îndeplinește un anumit criteriu, presupunem vocea cu valoarea CoS 5 într-o coadă și în același timp tot celălalt trafic în altă coadă. Deoarece pachetele de voce sunt mai mici este puțin probabil să se umple coada în care sunt păstrate și astfel dispare posibilitatea degradării traficului de voce.
Fiecare port are o memorie limitată, dacă vom folosi o coadă de așteptare ea va ocupa întreaga memorie, dacă vom folosi două cozi, spațiul de memorie va fi divizat în două, trei cozi vor duce la crearea a trei spații de memorie diferite din acel spațiu inițial finit…Dacă spațiul de memorie alocat unei cozi este foarte mic ea nu va face față creșterii traficului. Deoarece cozile fără prioritate sunt deservite după algoritmul Round-Robin sau Weighted Round-Robin, nu există nici o certitudine că pachetul aflat în coadă va fi transportat imediat. Astfel, poate apărea umplerea tampoanelor de memorie înainte ca pachetele să poată fi transportate din cauza spațiului mic de memorie pe care îl are o coadă.
Remediul pentru această problemă este folosirea unei cozi prioritare care va transporta pachetele imediat ce acestea sosesc în coadă. Ne vom referi la această coadă ca și la 1p – o coadă prioritară. Astfel vom avea 1p1q, adică o coadă prioritară și una standard. Tot traficul prioritar va merge direct la destinație trecând prin coada de prioritate 1 și celălalt trafic va aștepta trecerea traficului prioritar. Chiar dacă se vor pierde pachete din coada standard acest lucru nu va afecta traficul sensibil la întârzieri și acest lucru este de dorit. În tabelul de mai jos voi prezenta tipurile de cozi existente pe un switch:
Tabelul 4.1.3-1 Tipuri de cozi existente în LAN
4.1.4. Limitele de aruncare
Limitele de aruncare definesc cantitatea de memorie tampon de nivel 2 care trebuie să fie folosită înainte de a începe aruncarea unui anumit tip pachete. Cu alte cuvinte, cât de mult se pot umple memoriile tampon fără a se lua o decizie cu privire la aruncarea pachetelor. Unele switch-uri au o coadă prioritară și una standard cu patru limite de aruncare pe coada standard. Cu aceste limite de aruncare se va stabili care pachete pot fi aruncate mai agresiv funcție de valoarea CoS pe care o au.
În tabelul următor avem stabilite anumite limite pentru aruncarea pachetelor în coada standard.
Tabelul 4.1.4-1 Limitele de aruncare pentru o coadă standard
Dacă coada a ajuns la 50% din capacitate, traficul cu CoS egal cu 0 sau 1 devine eligibil pentru aruncare pentru a preântâmpina congestionarea. Dacă coada continuă să se umple în ciuda faptului că se aruncă pachete, atunci cînd ajunge la 60% din capacitate traficul care are CoS 0,1,2, sau 3 devine eligibil pentru aruncare. Dacă procesul de umplere continuă până la 80%, traficul clasificat cu CoS 0,1,2,3,4, sau 5 devine eligibil pentru aruncare pentru a se preântâmpina congestionarea rețelei.
La 100% tot traficul indiferent de clasificare este eligibil pentru aruncare. În figura de mai jos este reprezentată diagrama limitelor de aruncare într-o coadă de Nivel 2.
Figura 4.1.4-1 Limitele de aruncare a pachetelor într-o coadă de Nivel 2
Utilizarea limitelor de aruncare permite folosirea eficientă a tampoanelor de memorie disponibile pe switch. Astfel, spațiul de memorie nu va fi doar împărțit între cozi cu diferite nivele de prioritate ci și utilizat corect de traficul care are nevoie de el pentru a nu fi aruncat.
4.1.5. Limitele de încredere
Limitele de încredere sunt locurile rețelei de unde putem avea încredere în marcarea pachetelor. Acest lucru devine mai important în momentul în care unele sisteme de operare permit calculatoarelor un anumit control asupra marcării pachetelor. Multe sisteme Unix și Linux mai nou și platforme de Windows permit marcarea pachetelor pentru QoS. Din acest motiv este importantă delimitarea spațiilor de unde echipamentele de rețea pot avea încredere în marcarea traficului. Mai jos este prezentată o rețea unde limitele de încredere sunt plasate înainte de telefoanele IP care sunt capabile să ajusteze marcarea pachetelor pe care o primesc de la calculator. Astfel traficul marcat de calculator ca și prioritar va fi marcat de telefonul IP ca și trafic normal urmând ca traficul de voce să fie clasificat drept prioritar Figura 4.1.5-1:
Figura 4.1.5-1 Limitele de încredere și marcarea pachetelor
Limitele de încredere sunt utile pentru marcarea corectă a traficului. Cu ajutorul lor un administrator de rețea poate controla mai bine echipamentele care au dreptul să marcheze pachetele cu prioritate.
=== Capitolul 5 ===
5. QoS în monitorizarea traficului in rețea
„QoS” este o interfață Web pentru utilitațile unei rețele Linux.Acest site furnizează o interfața web „easy2use” despre funcțiile QoS disponibile in Linux.Utilizatorii iși pot defini propriile setări pentru tratarea traficului rețelei și de asemenea primind suport prin statisticile grafice despre folosirea benzii curente .
Obiectivul programului QoS este de a face posibil monitorizarea traficului pentru utilizatorii care au cunoștiințe despre capabilitațile rețelei și ale monitorizării traficului ,dar nu au multă experiența cu Linux-ul, scriptarea și alte instrumente necesare pt acest job.
Acest program nu va expune ce se întamplă practic in rețeaua ta,ci va arata doar ce se întâmplă cand tu limitezi anumite parți din rețea .
5.2 .Definiții si termeni
Aplicația „QoS” folosește cațiva termeni pentru a defini !!!!!!!!!!!1
5.2.1 Latimea de banda
Latimea de banda sau banda este viteza retelei a linkului tau.Aplicatia „QoS” foloseste definițiile vitezei in kbit pe secunda (kbit/s).
5.2.2 Protocoale
Deseori intalnești protocoale in mediile de rețea.In zilele noastre întâlnești Trafic – IP (TCP/UDP) sau Trafic –ICMP (ping) – dar sunt și alte protocoale.
5.2.3 Porturi
Porturile reflectă numerele comune de porturi pentru traficul TCP si UDP.
5.2.4 Obiectivele-ținta
Acestea sunt adresele IP sau adresele MAC.
Adresa IP poate fi specificata ca un localhost (1.1.1.1), adresa de rețea (10.0.0.0./8) sau distanța –IP(1.1.1.1 – 1.1.1.9 ).
Adresa MAC poate fi folosita doar in modul iptables.Mai multe obiective –ținte pot fi grupate împreună ca un grup –ținta.
5.2.5 Nivelele de serviciu
Predefinesc limitele lațimii de banda.
Aici poți defini parametrii detaliați pentru HTB,HFSC sau CBQ .Pentru CBQ poți specifica rata și prioritatea.Poți defini traficul de intrare și ieșire pt HTB.Pentru HFSC este posibil sa specifici intaryierea maxima a pachetelor de rețea.
5.2.6 Filtre
Filtrele sunt metode care potrivesc traficul dupa reguli stabilite.De exemplu poți defini ca un filtru „Web-Traffic” sa ii corespunda HTTP si HTTPS.
Discponibilitatea funcțiilor filtrelor depinde de ce sistem de „potrivire” folosești.Aplicația QoS suporta tc-filter si iptables.In timp ce tc+filter este rapid si deja integrat in pachetul iproute2,iptables este un subistem adițional care suporta multe metode luxusoase,complicate.
5.2.7 Canale
Canalele sunt canalele de trafic.Fiecare canal are asignat un anumit nivel de serviciu – latimea de banda maxima disponibila in interiorul canalului.Dacă ai un singur canal ,aceste nivel de serviciu este normal egal cu viteza liniei (de ex 2048/1024kbit/s).
Pe langa acestea,fiecare canal are un nivel de serviciu fall-back -orice trafic care nu e compatibil unei definiții pipe poate folosi banda nivelului de serviciu fall-back.Deci aplicația QoS se asigura ca orice trafic necunoscut sa nu poata folosi intreaga banda.
Ordinea regulilor canalului este importanta – primul compatibil câștigă ,nu cel mai exact.
Deci daca ai 2 canale cu cu urmatoarele obiective-țintă:
192.168.1.0/24
192.168.1.1
traficul to-from 192.168.1.1 va fi compatibil cu ținta 192.168.1.0/24 si nu de canalul cu 192.168.1.1
Daca nu specifici adrese IP pt Ținte ,poți folosi orice intrare in setarea canalului.
Este de asemenea posibil de a defini un canal care ignora setările QoS.Acest lucru câteodată e folositor deoarece dacă ai trafic care nu ar trebui atins de nice o setare de forma.Canalele care ignora setările QoS nu sunt inregistrate prin tc-colector.pl si nu sunt vizualizate in graficele de monitorizare.
5.2.8 Pipes
Pipe-urile reunesc canalele,filtrele și nivelele de serviciu impreună.Mai poțispecifica direcția lor(intrare ,ieșire) sau asignarea unui nivel de serviciu,care controleza folosirea benzii apartinand acestei pipe.
Banda de distribuție intre pipe-uri poate fi vizualizata in Monitoring -> Pipes.
5.2.9 Bridge sau Router
Bridge- dispozitiv de rețea transparent.De exemplu normal conectezi roter-ul tau principal direct la switch-ul propriu de rețea.Dupa care conectezi router-ul de prima interfața a bridge-ului.A doua interfața a pdului este conectata la switch-ul rețelei.Podul se poarta total inviyibil pentru orice conectare intre router si rețeaua ta.Dar ești capabil sa afectezi randamentul rețelei pentru amândouă interfețele podului.( http://bridge.sourceforge.net/)
Router-ul conecteaza 2 rețele diferite (de exemplu 192.168.191.0-24 si 172.16.2.0/24).Nici un client din subrețelele diferite nu știu despre alți clienți din cealalta rețea.Ei ltiu doar cum sa trimită pachetele catre celelalte rețele .Router-ul știe unde să trimită pachetele.
Manevrarea pachetelor este un pic diferita intre router si bridge deci trebuie sa ii spui aplicației in care mod sa acționeze.
5.2.4 Configuratia
5.2.4.1 Setarile
5.2.4.1.1 Optiunile
Banda
Aceasta banda este esentiala pentru clasa de initializare si ar trebui sa fie cats e poate de apropiata de viteza maxima a interfetei specificate (Ethernet,DSL)
Interfetele
De asemenea se pot specifica interfetele de intrare si iesire pe care vor functiona formele.Chiar daca avem de-a face cu poduri sau routeri,se introduce interfata fizica a dispozitivului de forma.
Optiunile MS
In continuare se poate defini o folosire preferantiala a pachetelor ACK si a pachetelor mici.Intai trebuie sa creezi un nivel de serviciu pt a manevra aceste pachete.
Se configureaza o queueing discipline care se potriveste cerintelor.
Se allege intre filtru-tc si iptables-matching.Filtru-tc este in inclus in pachetul iproute2 si este foarte rapid.Iptables pe de alta parte este raspandit mai mult,multe module aditionale fiind disponibile si foarte stabile.Iptables consuma un mic mai mult cpu si memorie pentru aranjarea pachetelor.
Trebuie sa informezi QoS-ul daca ruleaza pe un pod sau pe un router.
5.2.4.1.2 Obiectivul
Daca vrei formele de traffic pt o adresa IP sau MAC specificata,le poti defini in aceasta sectiune.Aceste definitii vor fi folosite in setarea canalelor.
5.2.4.2 Folosirea
5.2.4.2.1 Nivelele de serviciu
Aici se specifica nivelele de serviciu care sunt folosite in Canale, Conducte si Optiuni.Fiecare nivel de serviciu are o definitie separata ptparametrii HTB ,HFSC si CBQ.
5.2.4.2.2 Filtre
In aceasta vedere poti manipula definitile filtrului.Filtrele sunt mecanisme QoS care clasifica traficul ca sa fie destinat in conductele corespunzatoare.
5.2.4.2.3 Canalele
Canalele sunt necesare pentru trafic si obiectivul tinta.Daca obiectul tinta se potriveste traficului de retea, traficul de retea va fi redirectionat intr-un canal specificat.
Un canal trebuie sa defineasca latimea de banda si un nivel de serviciu fall-back.Orice trafic care vine in acest canal si care nu se potriveste definitiilor de conducte va cadea in acel nivel de serviciu fall-back.
5.2.4.2.4 Pipes
Pipe-urile sunt asignate canalelor si conform definitiilor de filtru impotriva traficului retelei care virtual curge prin aceste canale.De asemnea ele specifica cata latime de banda un servicu poate consuma.
5.2.4.3 Monitorizarea
5.2.4.3.1 Canale,Pipe ,Latime de banda
Daca regulile QoS-ului sunt incarcate corect si colectorul-tc este activ ,QoS ca desena grafice :
Canale
Aceasta va arata latimea de banda curenta distribuita intre canale.
Pipe-urile
Aceasta forma ca preyenta latimea de banda totala de intrare si de ieșire.
5.2.4.4 Overview
5.2.4.5 Reguli
5.2.4.5.1 Incarcarea (Load)
Acesta va face o incarcare ,,goala,, a tuturor regulilor QoS.Dupa fiecare schimbare de configuratie regulile trebuiesc reincarcate.Din punct de vedere tehnic QoS in primul rand va descarca toate regulile si apoi va incarca noua configurație.
Daca apare o bulina verde – totul este ok si regulile vor fi activate.Daca apare un X roșu si niște mesaje de eroare incearca sa incarci regulile incepand de la Rules – Load(debug) .
5.2.4.5.2 Load(debug)
Aceasta va incarca setul de reguli ,regula cu regula apoi intorcand fiecare eroare pe care o regula o face.
5.2.4.5.3 Show
„Show” va arata fiecare comanda care va fi incarcata cand activeyi QoS-ul.Include comenyile tc cat si comenyile iptables.
5.2.4.5.4 Unload
Dezactiveaza functionalitatea formelor QoS.
5.2.6 Exemple de forme
5.2.6.1 Forme pe un server Web
Un server web (linux,apache,MySQL,PHP) cu un server FTP
Conexiune prin DSL in ethernet cu 2Mbit/s link. IP 1.1.1.1.
64kbit/s ar trebui intotdeuna garantat pe un SSH dar poate folosi intreaga banda daca este disponibila.Va trebui sa aiba o prioritate ridicata.
HTTP trebuie sa aiba o rata fixa de 1024kbit/s dar poate folosi de asemnea intreaga banda daca e disponibila
FTP trebuie sa aibe 512kbit/s disponibili dar poate folosi de asemnea intreaga banda daca e disponibila
Tot celalalt trafic devine 256kbit/s si nu poate folosi mai mult de 768kbit/s.
5.2.6.2 Implementarea
Settings -> Options – definirea benzii de intrare si iesire. Specificarea HTB.Selectarea iptable ca filtru de trafic.
Crearea unui nivel de serviciu cu o definitie a ratei de intrare si ieșire care este egala cu banda maxima (20048 kbit/s)
Crearea unui nivel de serviciu care are o rata de 64kbit/s si introducem 2048kbit/s ca parametru .Setarea prioritatii ridicata.
Crearea unui nivel de serviciu care are o rata de 1024kbit/s si introducem 2048kbit/s ca parametru .Setarea prioritatii normala.
Crearea unui nivel de serviciu care are o rata de 512kbit/s si introducem 2048kbit/s ca parametru .Setarea prioritatii normala.
Crearea unui nivel de serviciu care are o rata de 256kbit/s si introducem 768kbit/s ca parametru .Setarea prioritatii scazuta.
Verificam listele cu porturi daca avem http,https,ftp,ftp+data si ssh.Daca nu e disponibil ,creaza o definire noua a portului pt aceste filtre.
Creaza un obiectiv-ținta pt adresa 1.1.1.1.
Creaza un filtru „Web-Traffic”.Selecteaza TCP ca protocol,asigneaza porturile http si https.
Creaza un filtru „FTP-Traffic” .Selectează protocolul TCP,asigneaza porturile ftp si ftp-data.Selectează Match FTP data channel”.
Creaza un filtru „SSH-Traffic”.Selecteaza protocolul TCP,asigneaza portul ssh.
Crearea unui canal nou.Nivelul de trafic pentru acest canal este 2046kbit/s.Pentru fall-back foloseste nivelul de serviciu cu rata de 256kbit/s.De la „Affecting” alege any ,iar ca obiectiv-ținta 1.1.1.1 si selectam amandoua directiile.
Crearea unei Pipe.Alege canalaul creat ,selectea filtru „Web-Traffic” ,nivelul de serviciu cu rata de 1024kbit/s si alege ambele direcții.
Crearea unei Pipe.Alege canalaul creat ,selectea filtru „FTP-Traffic” ,nivelul de serviciu cu rata de 512kbit/s si alege ambele direcții.
Crearea unei Pipe.Alege canalaul creat ,selectea filtru „SSH-Traffic” ,nivelul de serviciu cu rata de 64kbit/s si alege ambele direcții.
Apasa „Overview” și observa configuratia QoS-ului.
Selecteaza Rules -> Load și activeaza noul set de reguli.
=== Capitolul 5-anexa ===
Acronime
Bibliografie
Flannagan Michael and Kevin Turek, “Cisco Catalyst QoS: Quality of Service in Campus Networks”, Indianapolis, Cisco Press, 2003.
Szgeti Tim, Christina Hattingh, “End-to-End QoS Network Design”, Cisco Press, 2004.
Vegesna Srinivas, “IP Quality of Service”, Indianapolis, Cisco Press, 2001.
Cisco.com QoS page: http://www.cisco.com/go/qos.
Cisco IOS QoS Configuration Guide, Cisco IOS version 12.3: http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/qos_vcg.htm.
Documentatie HTML : http://www.porjes.com/idocs/
Index
Lista exemplelor
Exemplul 3.1-1. Aplicarea CLI pentru clasificare pe un router Cisco…………………33
Exemplul 3.2.1-1. Utilizarea comenzii set……………………………………………………………..34
Exemplul 3.2.2-1. Politică de limitare a traficului………………………………………34
Exemplul 3.2.2-2. Opțiunile pentru marcarea bazată pe politicile de clasă……………..35
Exemplul 3.5-1. Folosirea WRED și ECN……………………………………………..41
Lista figurilor
Fig. 1.1-1. Evoluția QoS………………………………………………………………………………………..3
Fig. 1.1-2. Poziția IntServ și DiffServ pentru asigurarea eficienței QoS………………………4
Fig. 1.2-1. QoS în rețelele industriale……………………………………………………………………..5
Fig. 1.3-1. Cererile traficului de date, voce și video………………………………………………….6
Fig. 1.6-1. Mecanismele QoS……………………………………………………………………………….12
Fig. 2.2.1-1. Transmiterea pachetelor cu și fără comprimare……………………………19
Fig. 2.2.1-2. Transmiterea pachetelor cu și fără comprimare (continuare)…………….19
Fig. 2.2.1-3. Rezervarea lățimii de bandă folosind cozi de așteptare…………………..20
Fig. 2.2.2-1. Topologia de rețea WAN pe care se vor calcula timpii de întârziere…………………………………………………………………………………21
Fig. 2.3.1-1. Topologia de rețea WAN pe care se va prezenta VoIP…………………..25
Fig. 2.3.1-2. Structura pachetului IP folosind RTP……………………………………..26
Fig. 2.3.2-1. Diferențele caracteristicilor de trafic între versiunile aceleiași aplicații….28
Fig. 3.2.3-1. Maparea de la Codurile PHB la valorile binare DSCP…………………….36
Fig. 3.3-1. Comparație între Aplicarea de Politici și Ajustare…………………………..37
Fig. 3.4-1. Plasarea în cozi și planificarea………………………………………..…….38
Fig. 4.1.2-1. Prezentarea unei legături de trunk………………………………………………………43
Fig. 4.1.2-2. Formatul pachetelor folosite pe legătura de trunk…………………………44
Fig. 4.1.2-3. Configurația unui router necesară pentru maparea între Nivelul 3 și 2 OSI………………………………………………………………………………………45
Fig. 4.1.4-1. Limitele de aruncare a pachetelor într-o coadă de Nivel 2……………..….48
Fig. 4.1.5-1. Limitele de încredere și marcarea pachetelor………….………………….49
Fig. 4.2.1-1. Rezultatul comenzii show module………………………………………………………51
Lista tabelelor
Tabelul 1.4-1. Nivelele QoS………………………………………………………………8
Tabelul 1.7.2-1. Clasele standardului QoS……………………………………………………………..14
Tabelul 2.1-1. Comportarea unei rețele fără QoS………………………………………17
Tabelul 2.2.2-1. Tipuri de întârzieri…………………………………………………….23
Tabelul 2.2.2-2. Instrumente QoS ce afectează întârzierea……………………………..24
Tabelul 2.3.1-1. Codec-uri și lățimea de bandă pentru transportul de voce……………27
Tabelul 2.3.1-2. Protocoalele utilizate de VoIP…………………………….………….27
Tabelul 2.3.2-1. Clasa și caracteristicile de trafic pentru anumite aplicații…………….31
Tabelul 3.3-1. Caracteristici Aplicarea de Politici și Ajustare…………………………..38
Tabelul 4.1.3-1. Tipuri de cozi existente în LAN……………………………………….47
Tabelul 4.1.4-1. Limitele de aruncare pentru o coadă standard……………….………..47
Tabelul 4.2.1-1. Combinații între supervisor și motorul de forwardare………………………50
Tabelul 4.2.1-2. Mărimea memoriilor tampon și a cozilor…….………………………..52
=== Caracteristcile QoS pt o retea TCPIP ===
Introducere
Tehnica de calcul în general și rețelele în particular trebuie să facă față problemelor legate de resursele limitate. Pentru calculatoare, sistemele de operare trebuie să distribuie eficient timpul procesorului și memoria programelor care sunt active pe el. Când limita memoriei interne este atinsă procesorul pierde timpi suplimentari pentru a muta datele din memoria internă pe suport fizic, de obicei HD (Hard Disk). Dacă procesorul nu reușește să asigure un management eficient al resurselor, utilizatorii devin frustrați pentru că nu pot să-și continuie munca.
Lupta pentru a asigura o lățime de bandă tuturor utilizatorilor și aplicațiilor este tipică rețelisticii moderne. Dacă traficul devine mai mare decât lățimea de bandă disponibilă, rețeaua trebuie să reacționeze fie aruncând pachetele, fie plasându-le în memorii tampon, așteptând ca banda să se elibereze. Pachetele care sunt plasate în memorii tampon experimentează întârzieri mai mari decât celelalte pachete care sunt transmise direct. Dacă pachete consecutive experimentează timpi de întârziere diferiți apare jitter-ul sau întârzierea variabilă.
Pentru a face față cerințelor tot mai mari pentru rețelele moderne Cisco și specialiștii în rețelistică au grupat toate mecanismele și tehnicile de asigurare a calității pentru rețele sub numele de QoS (Quality of Service). De asemenea, au îmbunătățit și au dus la dezvoltarea QoS pentru rețelele convergente de voce, video și date.
Prezenta lucrare este un studiu asupra mecanismelor și tehnicilor QoS pentru aplicarea practică a QoS într-o rețea locală (LAN) care trebuie să suporte date, voce și video. Prezint detaliat mecanismele QoS care țin de rețeaua LAN și mai general mecanismele QoS folosite în WAN. Pentru aplicația practică am avut nevoie de acest studiu care se bazează pe documentația oficială oferită de Cisco.
În capitolul 1 prezint modul în care a apărut și a evoluat QoS. De asemenea, am abordat în general mecanismele și tehnicile folosite de QoS.
Capitolul 2 prezintă caracteristicile traficului într-o rețea modernă. Sunt prezentate problemele care apar și tehnicile QoS care au fost create pentru a le soluționa. În detaliu sunt prezentate cerințele de trafic pentru voce și date.
Capitolul 3 descrie în detalii mecanismele QoS folosite în LAN. Sunt prezentate și exemple din CLI (Command Line Interface) pentru configurarea lor pe echipamentele de rețea Cisco.
Capitolul 4 descrie cu lux de amănunte QoS pentru rețeaua LAN. Sunt prezentate echipamentele Cisco Catalyst din seriile 6500, 4500, 3500 și este prezentată o mică rețea cu un model de configurare.
Capitolul 5 reprezintă partea practică a lucrării care descrie implementarea QoS într-o rețea LAN. Exemplele sunt reale și asigură și astăzi servicii de calitate Cisco QoS într-o rețea convergentă de voce și date.
Capitolul 1: Introducere în QoS
1.1. Evoluția QoS
Acum un secol rețeaua publică de telefonie cu comutare de circuite (PSTN) a început să se dezvolte la nivel mondial. Această rețea se compunea din lățime de bandă fixă, circuite dedicate și era concepută pentru traficul în timp real, cum ar fi vocea. Cinci decenii mai târziu, experții în rețelistică din mediul educațional și militar au introdus rețelele cu comutare de pachete pentru a evita orice punct de cădere. Rețelele cu comutarea pachetelor împart fluxul de informație în părți mai mici care pot fi transmise pe căi independente spre aceeași destinație, analog sistemului poștal.
Teoretic comunicațiile în timp real, cum ar fi vocea, pot folosi circuite virtuale indiferent de tehnologia de rețea pe care se bazează. Totuși, vocea bazată pe circuite virtuale nu a devenit o realitate comercială sau practică până când router-ele și switch-urile folosite în rețelele cu comutare de pachete nu au devenit îndeajuns de puternice pentru a conduce fluxul de pachete în timp real la costuri rezonabile.
Când puterea de procesare a ajuns la limitele care permit crearea circuitelor virtuale, au apărut alte probleme legate de caracteristicile unui trafic în timp real. De exemplu, pachetele sunt aruncate sau întârzie foarte mult din cauza umplerii tampoanelor de memorie. Soluția retransmiterii pachetelor care funcționa foarte bine pentru traficul de date nu mai asigură cerințele traficului în timp real.
Prima tehnologie pentru transferul pachetelor care a introdus conceptul de “categorie de serviciu” la Nivel 2 a fost ATM. Această tehnologie oferă tratament diferit pentru diferite tipuri de trafic. ATM minimizează întârzierile prin definirea unor celule – pachete cu lungime fixă care pot fi rutate în hardware. ATM utilizează, de asemenea, conceptul de PVC și SVC pentru a elimina întârzierile care apar pentru a stabili ruta pachetelor.
În efortul de a integra traficul de date și voce a fost inventat ISDN (Integrated Services Digital Network). Termenul de servicii integrate se referă la convergența între tipurile diferite de trafic: voce, video și date pe o singură rețea cu comutare de pachete. ISDN, care a fost prima tehnologie prin care s-a încercat aplicarea arhitecturii de rețea convergentă, definește modul de transport al traficului de date peste o rețea care suportă nativ voce.
La sfârșitul anilor 90, tehnologia bazată pe IP a câștigat lupta pentru transportul traficului convergent din cauza ușurinței cu care poate fi folosită și a avantajelor pe care le oferă pentru traficul în timp real. Factorii care au asigurat acest succes tehnologiei IP în convergența diferitelor tipuri de trafic sunt mecanismele QoS. QoS permite tratament diferențiat pentru voce față de date și pentru video față de voce. Odată cu evoluția QoS un număr mare de întreprinderi au văzut un avantaj în a avea o singură rețea convergentă pentru date, voce și video și au început să participe activ la dezvoltarea rețelelor convergente.
Rețelele IP din anii 1990 au fost rețele de tip „Best-Effort” și Internetul, ca și întreg a rămas așa până în prezent. Rețelele private ale marilor companii și furnizori de servicii Internet au evoluat de la modelul „Best-Effort” la un model mult mai complex bazat pe servicii diferențiate, care asigură pentru un anumit tip de aplicație un anumit tip de serviciu. Figura 1.1-1 prezintă evoluția QoS începând cu mijlocul anilor 1990:
Figura 1.1-1 Evoluția QoS
Prima încercare de a standardiza QoS a fost la mijlocul anilor 90, când IETF a publicat documentul oficial RFC 1633 în iunie 1994 și altele. Aceste documente tratau un singur protocol de rezervare a resurselor (RSVP). RSVP semnalizează lățimea de bandă și întârzierea necesară pentru orice sesiune discretă la fiecare nod în parte (circuit logic) pe care pachetul va trebui să-l parcurgă din momentul trimiterii până când ajunge la destinație. Inițial RSVP avea nevoie de rezervarea resurselor pe fiecare nod ceea ce era destul de greu de realizat pe fiecare switch, server, router care există pe internet și care sunt produse de diferite companii. Pentru a rezolva această problemă, au fost create alte modele de tip DiffServ în încercarea de a standardiza QoS. Modelul DiffServ descrie modul în care trebuie să se comporte fiecare nod. Nodurile pot folosi orice metodă (proprietară sau standard) pentru a se conforma. Marcarea pachetelor, de tip IP Precedence (IPP) și succesorul ei DSCP (Differentiated Services Code Points) au fost definite cu comportări specifice per hop pentru majoritatea tipurilor de trafic.
Evoluția ambelor modele nu a clarificat care dintre ele este cel care trebuie standardizat, ci doar prin împletirea și aplicarea armonioasă a mecanismelor ambelor modele se poate obține o calitate bună a serviciului de rețea. În figura de mai jos este reprezentată poziția ambelor modele pentru asigurarea eficienței unei rețele:
Figura 1.1-2 Poziția IntServ și DiffServ pentru asigurarea eficienței QoS
Scurte definiții pentru IntServ și DiffServ:
IntServ folosește conceptul de flux împreună cu un protocol de semnalizare de-a lungul căii pachetului. Protocolul de semnalizare garantează ca resursele necesare să fie disponibile la fiecare hop pentru flux înainte ca să înceapă transmiterea pachetelor.
DiffServ folosește marcarea pachetelor pentru clasificare și tratează fiecare pachet în parte. Chiar dacă acest model este scalabil (este implementat de majoritatea întreprinderilor și furnizorilor de servicii internet), el asigură o lățime de bandă stabilă pentru pachetele care aparțin unui flux și acceptă mai greu un alt flux pentru procesare.
Cu avantaje și dezavantaje de ambele părți, mecanismele QoS continuă să utilizeze o mixtură între ambele tehnologii pentru a asigura servicii de calitate rețelelor moderne.
La sfîrșitul anilor 90, tehnicile QoS au devenit mult mai sofisticate și au fost adaptate noilor tehnologii avansate cum ar fi MPLS (Multiprotocol Label Switching) și VPN (Virtual Private Networks). Ultimile tendințe în evoluția QoS sunt simplificarea și automatizarea cu scopul de a simplifica și a asigura rețele IP „inteligente” prin QoS.
1.2. Aplicarea QoS de la un capăt la altul
Indiferent de modul în care este măsurat QoS, el este un element vital pentru orice rețea convergentă. Pentru a asigura un nivel ridicat al calității traficului în rețea, QoS trebuie implementat de la un capăt la celălalt. Fiecare echipament care se ocupă de plasarea pachetelor mai departe în rețea (calculator, server, switch sau router) trebuie să implementeze QoS pentru a asigura funcționarea corectă a rețelei în toate nodurile ei.
Este un mit afirmația conform căreia QoS este aplicabil doar în rețelele lente de tip WAN sau pe Internet. Practica a demonstrat că traficul sensibil la întârzieri cum este vocea se degradează din cauza întârzierilor și a aruncării pachetelor dacă QoS nu este implementat pe echipamentele din LAN, ca de exemplu, telefoanele IP CISCO sau switch-urile CISCO Catalyst.
Figura 1.2-1 arată segmentele unei rețele industriale cu telefonie IP unde QoS trebuie aplicat pe fiecare segment:
Figura 1.2-1 QoS în rețelele industriale
1.3. Pachetele cu trafic diferit
Rețelele care nu folosesc QoS sunt descrise ca și rețele de tip Best-Effort. Acest tip de rețele tratează toate pachetele cu același tip de prioritate. Acest tip de rețea funcționează bine dacă există timpi de procesare, memorie, și lățime de bandă pentru procesarea imediată a tuturor pachetelor care traversează rețeaua imediat ce acestea sosesc pe interfață. De obicei acest lucru nu este posibil și apar următoarele probleme:
Disfuncționalități în rețea pe partea de utilizator, când mai mulți utilizatori, mai multe grupuri, încercă să acceseze aceeași resursă.
Disfuncționalități în rețea pe partea de aplicații, când mai multe aplicații de la un utilizator sau mai mulți încearcă să acceseze aceeași resursă.
Traficul are cerințe diferite de la rețea și aceasta trebuie să i le asigure diferențiat.
Figura 1.3-1 Cererile traficului de date, voce și video
Pentru soluționarea problemelor congestiei traficul trebuie tratat diferențiat. Trebuie aplicate politici și tehnici prin care să se asigure funcționarea corectă a fiecărui echipament (nod de rețea).
Conceptele QoS trebuie aplicate atât pentru traficul de încredere de voce sau video cât și pentru traficul generat de virușii de tip SPAM și trafic care poate duce la DoS. Aici intervine componenta de securitate QoS care ne permite să aplicăm diferite politici pentru tipuri de trafic diferit.
1.4. Nivelele QoS
Traficul în rețele este debitat de o varietete însemnată de aplicații de pe stațiile de capăt. Aceste aplicații diferă la cerințele de funcționare și performanțe. Cerințele fiecărui trafic depind de aplicația de care aparține traficul respectiv. Deci, înțelegerea tipului aplicației, este un lucru absolut necesar pentru a cunoaște nevoile de trafic pentru diferite servicii.
Capabilitatea rețelei de a livra servicii pentru anumite aplicații de rețea, cu control asupra indicatorilor de performanță – întârziere/jitter, lățime de bandă, pierderi – este categorizată pe 3 nivele :
1. Serviciul Best-Effort – Conectivitate de bază fără garanția livrării pachetului la destinație, sau a timpului în care acesta ar putea ajunge, deși pachetul este aruncat numai când cozile buffer-elor de intrare sau ieșire sunt pline.
Serviciul Best-Effort nu este realmente o componentă a QoS, deoarece acesta nu asigură servicii sau garanții în înaintarea traficului best-effort. Acest serviciu este însă singurul serviciu pe care îl asigură Internetul astăzi.
Majoritatea aplicațiilor de rețea, ca File Transfer Protocol (FTP), funcționează corect cu serviciul Best-Effort, cu toate că are performanțe mai reduse. Pentru funcționare bună, toate aplicațiile necesită alocare de resurse din partea rețelei, adică, bandwith, întârzieri minime și număr cât mai mic de pachete pierdute.
2. Serviciul Diferențiat – În cadrul serviciului diferențiat, traficul este grupat în clase, în funcție de cerințe. Fiecare clasă de trafic este diferențiată de rețea și servită conform mecanismului QoS configurat pentru clasa respectivă. Aceast tip de QoS este adesea întâlnit sub numele de CoS.
A se sublinia că serviciile diferențiate nu dau garanții la livrare. Aceste servicii, doar diferențiază traficul și permit tratamente preferențiale ale anumitor tipuri de clase. Din acest motiv acestui serviciu i se mai spune și Soft QoS.
Această schemă de QoS dă un randament bun atunci când avem aplicații ce folosesc intensiv banda. Este foarte important ca traficul de control al rețelei să fie diferențiat de restul traficului de date din rețea, și prioritizat astfel încât să existe conectivitate la orice moment.
3. Serviciul Garantat – Un serviciu care necesită rezervarea resurselor rețelei pentru a se asigura că rețeaua întâlnește cerințele de comunicare specifice tipului de trafic respectiv. Datorită faptului că necesită garanții rigide din partea rețelei, serviciul garantat este numit și Hard QoS.
Rezervarea căii nu se integrează bine în structura Internet-ului, care deservește mii de fluxuri de trafic simultan. Aplicațiile ce necesită astfel de servicii includ aplicații multimedia ca audio și video. Aplicațiile interactive de voce peste Internet necesită o întârziere limită de 100 ms pentru a nu afecta conversația. Această întârziere este de asemenea acceptabilă pentru un spectru larg de aplicații multimedia. Telefonia peste Internet necesită minim o bandă de 8 Kbps și maxim 100 ms întârziere „round-trip”. Rețeaua necesită alocarea de resurse pentru a putea satisface asemenea cerințe.
QoS la Nivelul 2 (Nivel din stivă OSI) se referă la toate mecanismele care țintesc sau există în tehnologiile de la nivel de link. QoS la Nivelul 3 se referă la funcțiile QoS de la nivelul rețea.
În Tabelul 1.4-1 sunt afișate cele trei nivele de servicii și funcțiile QoS corespunzătoare, la Nivelul 2 (Data Link) și la Nivelul 3 (Network).
Tabelul 1.4-1 Nivelele QoS
1.5. Modelele QoS
După cum am relatat anterior există două modele pentru asigurarea nivelelor diferite de servicii într-o rețea: IntServ și DiffServ.
IntServ caracteristici generale
Un serviciu IP de tip “Best-Effort” este asemănător cu cel de poștă tradițională. O scrisoare poate ajunge la destinație, și ajunge de obicei, dar se poate și pierde pe parcurs. Modelul IntServ este asemănător cu serviciile de curierat rapid sau poștă diplomatică unde este garantat faptul că scrisoarea ajunge în timp util la destinația stabilită. Specific, IntServ are următoarele caracteristici:
Ce trimite echipamentul transmițător (rată, MTU, etc.), descrise de niște specificații Tspec (specificațiile transmițător)
De ce are nevoie echipamentul receptor (lățime de bandă, MTU, etc.), descrise de specificațiile receptor Rspec.
Cum are loc semnalizarea pe rețeaua dintre transmițător și receptor RSVP.
Platforma pe care se bazează IntServ ia în cosiderare aplicarea tehnicilor QoS pentru IP de la capăt la capăt. Factorii cheie sunt transmițătorul și receptorul care cer un anumit serviciu din partea rețelei pentru anumite fluxuri, definite de adresa sursă, adresa destinație, protocolul de transport, portul sursă și portul destinație.
IntServ descrie trei clase de servicii de bază pe care aplicațiile le pot cere:
Servicii Garantate (RFC 2212) – asigurarea fermă că pachetul va ajunge de la un capăt la celălalt fără întârzieri și face acest lucru garantând lățimea de bandă și minimizând întârzierile.
Trafic Controlat (RFC 2211) – asigură fluxul aplicației cu o calitate a serviciului de rețea apropiată cu cea în care fluxul ar fi într-o rețea liberă sau fără mult trafic; folosește mecanismul de control al capacității pentru a se asigura că serviciul este primit chiar atunci când rețeaua e supraâncărcată.
Serviciul BestEffort – nu garantează nici un serviciu.
Avantajele modelului IntServ sunt următoarele:
Simplitatea în concept, care-i permite să se integreze în politicile de rețea.
QoS-ul discret per flux, îl face din punct de vedere al arhitecturii aplicabil pentru telefonia IP.
Capabilitățile CAC (Call Admisin Control), care indică punctelor terminale unde există lățime de bandă necesară pe flux.
Dezavantajele modelului IntServ sunt următoarele:
Toate elementele din rețea trebuie să-și mențină și să-i propage starea per flux, care poate cere o lățime de bandă considerabilă în rețelele mari.
Sunt folosite mesaje, periodic, care au nevoie de protecție împotriva pierderilor de pachete pentru a asigura sesiunea intactă.
Toate nodurile intermediare trebuie să implementeze RSVP.
DiffServ caracteristici generale
Dacă continuăm cu analogia poștei tradiționale modelul DiffServ este asemănător cu serviciile diferențiate din cadrul aceluiași serviciu poștal. Adică poșta diplomatică poate asigura servicii rapide, ultra rapide și normale pentru trimiterea unei scrisori. Acest model însă nu asigură fluxul de la un capăt la celălalt cu o calitate a serviciului, el se concentrează asupra fiecărui pachet pe nodurile pe care este implementat.
Strategia DiffServ este foarte simplă: el asigură servicii diferențiate per pachet, asigurând prioritatea unora față de celelalte fără a ține cont de flux. Pachetele dintr-un anumit serviciu aparțin de o „clasă” și tratamentul fiecărei clase de pachete este descrisă de componentele DiffServ și rețeaua trebuie să se conformeze lor. Acest lucru este posibil datorită următoarelor caracteristici:
Marcarea câmpului de IP la intrarea în rețea după o anumită limită.
Folosind această marcare determină nodurile care trebuie să trimită pachetul.
Condiționează tratamentul fiecărui pachet specific „clasei” de care aparține.
Specificațiile DiffServ:
Serviciul expediat rapid (RFC 3246) – asigură o coadă de strictă prioritate.
Serviciul expediere asigurată (RFC 2597) – asigură un serviciu de calitate ridicată aplicând tehnici precum aruncarea pachetelor și planificarea pentru traficul în exces.
Serviciul de selecție a claselor (RFC 2474) – asigură o tehnică care este folosită pentru compatibilitate cu IP Precedence.
Serviciul Best-Effort – nu asigură nimic.
Modelul DiffServ are următoarele avantaje:
Scalabilitate – nu este nevoie de informații despre stare sau flux ca să fie menținut.
Performanță – pachetul trebuie să fie cercetat doar o dată pentru procesul de clasificare. Toate deciziile următoare se fac pe baza unei singure citiri din pachet.
Interoperabilitate – este bazat pe IP.
Flexibilitate – nodul nu trebuie să aplice o tehnică anume, el poate să folosească ce tehnică dorește pentru a se conforma cerințelor descrise de DiffServ.
Dezavantajele modelului DiffServ sunt:
Nu există un control de la cap la coadă a tuturor nodurilor rețelei și pot apărea noduri unde rețeaua să nu asigure servicile dorite.
Lipsa controlului per flux poate duce la congestii. Spre exemplu, dacă există bandă doar pentru 10 telefoane IP un al 11-lea telefon poate duce la congestionarea rețelei.
1.6. Tehnici și mecanisme QoS: Prezentare generală
Există multe tehnici și mecanisme utilizate pentru a oferi o calitate mai bună a rețelelor moderne. Mai jos voi prezenta câteva dintre ele și în capitolul 3 voi prezenta detaliat funcția și rolul pe care le pot juca în anumite circumstanțe care apar într-o rețea.
În general, mecanismele și tehnicile QoS se împart în următoarele categorii:
Clasificare și marcare
Aplicare de politici și ajustare
Evitarea congestiei
Managementul congestiei
Unelte specifice legăturii
Pachetele sau frame-urile care intră într-un echipament de rețea trebuie să fie analizate pentru a determina tratamentul pe care trebuie să-l primească din partea rețelei. Această analiză este numită clasificare. Clasificarea este prima funcție QoS fără de care nu ar fi posibilă aplicarea serviciilor diferențiate. Se recomandă să se facă clasificarea traficului cât mai aproape de sursă.
Marcarea stabilește limite distincte de încredere care demarcheză punctele în rețea unde pachetele sunt admise ca atare fără a mai fi nevoie de o clasificare detaliată de nivel 3 sau 4.
Traficul de tip VoIP, HTTP sau FTP care intră în echipamentul de rețea este marcat și clasificat în diferite clase. Înainte de plasare în cozi se aplică mecanismul de evitare a congestiei WRED. Traficul este apoi plasat în cozi sau aruncat. Apoi funcție de prioritate este planificat pentru ieșirea din echipament.
În figura de mai jos voi prezenta mecanismele și tehnicile QoS:
Figura 1.6-1 Mecanismele QoS
1.7. Simplificarea QoS
La sfârșitul anilor 90, Cisco a depus un efort considerabil pentru a dezvolta și implementa un mecanism eficient QoS cu o serie de îmbunătățiri. Mecanismele QoS au devenit foarte multe și foarte complicate la nivelul implementării. Pe parcursul anului 2000, cererea clienților Cisco a fost să fie simplificate tehnicile de aplicare a QoS. Ca și răspuns la această cerere au fost dezvoltate o serie de proiecte pentru simplificarea și automatizarea QoS. Rezultatele au dus la:
Crearea modulului de QoS în linie de comandă (CLI)
Stabilirea standardului QoS
Comportarea implicită (conform standardului)
Portabilitatea pe diferite platforme
QoS automatizat (AutoQoS)
1.7.1. Modulul QoS în linie de comandă
Primul pas pentru a simplifica lucrurile a fost modularizarea configurării QoS și stabilirea aceluiași set de comenzi pentru toate platformele. La sfîrșitul acestui pas a fost introdus MQC (Modular QoS Comand-Line Interface) în versiunea 12.0(5)T a sistemului de operare Cisco IOS.
În MQC există trei componente de bază:
class-map – Un filtru de clasificare definit în cadru schemei de politici pentru a identifica traficul pentru un tratament preferențial sau diferențial. Traficul poate fi identificat după IPP sau DSCP, de asemenea, după listele de acces ACL, după parametri de nivel 2 CoS, DE, ATM CLP, MPLS.
policy-map – O comandă care definește cum trebuie să fie deservit fiecare tip de trafic clasificat de class-map. Opțiunile sunt marcarea, aplicarea de politici, ajustarea, aruncarea selectivă, comprimarea.
service-policy – O comandă care asignează politicile pe interfață și le specifică direcția.
1.7.2. Standardul QoS
Chiar dacă a fost dezvoltat MQC un pas important în simplificarea QoS, el a rezolvat doar problemele de implementare a QoS. Un alt factor în complexitatea QoS este inconsistența capabilităților QoS de-a lungul diferitelor platforme hardware și software.
În 2002, o serie de activități în cadrul Cisco au dus la crearea Standardelor Tehnologiei pentru a clarifica ce capabilități QoS sunt prezente și pe ce platforme. Specific pentru QoS, Standardul QoS este un document strategic intern scris de experți Cisco care a avut la bază unul din aceste două scopuri:
Pentru a documenta ce capabilități QoS sunt necesare pe echipamentele considerate produse cu QoS înglobat.
Pentru a asigura o analiză a capabilităților, considerate importante din punct de vedere a platformei pe care există.
Pentru produsele noi acest standard a impus inginerilor proiectanți anumite reguli și produsele deja proiectate trebuiau ajustate la noile reguli QoS.
Standardul QoS definește 11 clase de trafic care sunt folosite în toate exemplele de configurare și testare Cisco. Standardul nu cere ca firmele care folosesc QoS să folosească toate clasele imediat. Aceste clase sunt menite să asigure cerințele traficului de astăzi și cel pentru viitorul apropiat. Tabelul de mai jos oferă un rezumat al recomandărilor din standardul Cisco cu privire la QoS:
Tabelul 1.7.2-1 Clasele standardului QoS
1.7.3. Comportarea Implicită
Următorul pas spre simplificare a fost implementarea unei comportări implicite pentru fiecare nod de rețea, adică fiecare nod trebuie să facă ce are de făcut fără nici o configurare. După o serie de modificări în sistemul de operare Cisco IOS și în echipamentele care nu sunt Cisco (telefoane IP), tot traficul de voce este marcat cu DSCP EF. Prin acest lucru se elimină necesitatea de a configura ceva în plus. Aceste schimbări sunt discutate în detaliu în capitolul următor la clasificare și marcare.
Automatizarea QoS
Automatizarea QoS (AutoQoS) este în esență macro care permite administratorului de rețea să folosească două sau trei comenzi QoS pentru a activa toate capabilitățile QoS pe un anumit echipament.
De exemplu, în prima sa versiune AutoQoS pentru VoIP a asigurat cea mai bună practică pentru configurarea VoIP pe router-ele Cisco și Switch-urile Catalyst. Printr-o singură comandă pe interfață sau global (depinde de platformă) era configurat QoS pentru acel echipament.
AutoQoS există pentru LAN și WAN pe switch-urile Catalyst și pe router-ele Cisco IOS. În versiunea sa inițială QoS se putea aplica doar pentru mediile VoIP.
Pentru switch-urile din LAN, AutoQoS efectuează următoarele automatizări:
Stabilesc limitele de încredere (trust) pînă la telefoanele Cisco IP.
Stabilesc limitele de încredere (trust) cu celelalte switch-uri Cisco.
Activează o coadă strict prioritară pentru voce și coadă round-robin și de greutate pentru date.
Modifică criteriile de admitere în echipament.
Modifică dimensiunea și greutatea cozilor unde este necesar.
Modifică mapările de la Nivel 2 la Nivel 3.
Pentru router-ele Cisco IOS, AutoQoS este suportat pe Frame Relay, ATM, HDLC, PPP și legăturile între Frame Relay și ATM și execută următoarele funcții:
Aplică planificarea:
LLQ (Low-Latency Queuing) pentru voce
CBWFQ (Class-Based Weighted Fair Queuing) pentru semnalizare voce
FQ (Fair Queuing) pentru traficul normal
Activează ajustarea traficului pentru Frame Relay dacă este nevoie.
Activează fragmentarea și intercalarea pentru legăturile lente (< 768kbss).
Activează comprimarea pentru IP RTP.
Asigură alerte de tip RMON dacă pachetele IP sunt aruncate.
În cea de a doua versiune AutoQoS au fost implementate 10 clase conform standardului QoS. AutoQoS simplifică implementarea QoS pentru voce, video și date. Un alt avantaj este că această tehnologie reduce posibilitatea erorilor umane în implementarea QoS. Fiecare client Cisco poate să-și adapteze cu ajutorul MQC cerințele specifice pentru QoS.
1.8. Beneficiile QoS
Principalele beneficii al IP QoS sunt următoarele :
1. Permite ca rețeaua să suporte serviciile multimedia, împreună cu cerințele lor. Noile aplicații, ca Voice over IP (Voce peste IP) și video au cerințe specifice de la rețea.
2. Acordă operatorului de rețea controlul și utilizarea resurselor rețelei.
3. Oferă garanție serviciilor și diferențierea traficului în rețea. Este necesar să avem convergența diferitelor tipuri de trafic voce, video și date într-o singură rețea IP.
4. Permite furnizorilor de servicii de internet să ofere servicii bonus împreună cu serviciul existent „Best-Effort” – Class of Service (CoS). Un furnizor de servicii de internet poate să-și evalueze serviciul bonus ca fiind Platină, Aur sau Argint, spre exemplu, și să configureze rețeaua pentru a diferenția traficul.
5. Joacă un rol important în noile servicii de rețea oferite ca Virtual Private Network (VPN).
Capitolul 2: Caracteristicile traficului și QoS
2.1. Introducere
În rețelistică, QoS (calitatea serviciului) descrie o serie de concepte și instrumente care pot fi folosite pentru a afecta accesul pachetelor la un anumit serviciu. Mulți cred că QoS se rezumă la posibilitatea plasării pachetelor în diferite cozi de așteptare în funcție de prioritatea lor. Dar există multe alte concepte și instrumente care afectează calitatea serviciilor într-o rețea: comprimarea, politica de aruncare a pachetelor, ajustarea, politica de semnalizare, etc. În cele din urmă, utilizarea oricărui din aceste mecanisme nu face altceva decât să acorde prioritate unui pachet față de altul. Ca și în cazul unor bănci la ghișeul cărora scrie: „Persoanele juridice au prioritate.” Fiecare dintre noi, devine frustrat când trebuie să stea la coadă după diferite lucruri ce țin de satisfacerea anumitor nevoi. Ar fi minunat dacă nu am avea pe nimeni așteptând în fața noastră la bancă sau la supermarket. O soluție ar fi dublarea sau triplarea numărului de ghișee la bănci și mărirea ariei de efectuare a plăților la supermarket. O soluție costisitoare de altfel… care nu va soluționa definitiv problema. Vor exista zile, în week-end, spre exemplu, când se vor forma cozi.
Mai jos sunt prezentate câteva caracteristici ale unei rețele care nu folosește QoS.
Tabelul 2.1-1. Comportarea unei rețele fără QoS
2.2. Caracteristicile de performanță ale rețelei
În acest capitol voi prezenta patru caracteristici pe care QoS le poate afecta și de care depinde performanța unei rețele:
Lățimea de bandă (Bandwidth)
Întârzierea (Delay)
Jitter-ul (Jitter)
Pierderea pachetelor (Packet loss)
Lățimea de bandă definește capacitatea de transmisie a mediului. Comprimarea reduce lățimea de bandă necesară pentru a trimite toate pachetele, însă procesul de comprimare adaugă întârzieri per pachet și consumă din timpii de procesare ai CPU.
Jitter-ul este variația întârzierilor între pachetele consecutive, de aceea este numit uneori și „variația întârzierii.” Router-ul poate reduce jitter-ul pentru un anumit trafic însă acest lucru duce de obicei la creșterea întârzierilor și jitter-ului pentru alt trafic. Caracteristicile QoS pot rezolva problemele jitter-ului prin capacitățile plasării pachetelor în diferite cozi de așteptare în funcție de prioritatea lor.
Pierderea pachetelor poate apărea din cauza erorilor de transmisie. Totuși, multe pachete se pot pierde mai degrabă din cauza umplerii cozilor decât a erorilor de transmisie și QoS poate decide care dintre pachete să fie aruncate.
Cheia către un succes real în implementarea QoS este îmbunătățirea acelor caracteristici QoS pentru traficul care are nevoie de ele, degradând în același timp caracteristicile QoS de care acel trafic nu are nevoie. De exemplu, QoS trebuie să scadă întârzierile pentru traficul sensibil la întârzieri (voce, video), în timp ce va crește întârzierile traficului insensibil la întârzieri.
Următoarele patru secțiuni voi prezenta mai detaliat aceste caracteristici.
2.2.1. Lățimea de bandă
Termenul de lățime de bandă sau „bandwith” se referă la numărul de biți pe secundă care se așteaptă să fie transmiși cu succes într-o rețea. Termenul este mai larg dar strâns legat de un alt termen „throughput” adică lățimea reală de bandă care se referă la capacitatea reală de transmisie a mediului, adică câți biți se transferă în mod curent pe acest link. Ca formule de calcul avem:
; ;
BW – lățimea de bandă ideală;
P – lățimea de bandă reală;
S – mărimea fișierului în biți;
T – timpul de transfer al unui fișier;
Acest lucru este valabil pentru rețele punct la punct (Point-to-Point). În cazul tehnologiei Frame Relay furnizorii de servicii internet au contractată o anumită lățime de bandă chiar dacă capacitatea fizică de transmisie a rețelei este mai mare. CIR (Committed Information Rate) definește câtă lățime de bandă garantează furnizorul de servicii să asigure clientului sau de la DTE (Data Terminal Equipment) până la capătul fiecărui circuit virtual (VC).
Mecanisme QoS care afectează lățimea de bandă
Cea mai bună soluție QoS pentru soluționarea problemelor legate de lățimea de bandă este mărirea lățimii de bandă! Dar după cum am menționat anterior aceast lucru nu va rezolva toate problemele. De fapt, în rețelele convergente (date, voce, video) creșterea lățimii de bandă duce la scăderea întârzierilor care pot fi soluționate și prin alte metode QoS sau prin implementarea unui bun design QoS. Unul din aceste instrumente este comprimarea pachetelor:
Figura 2.2.1-1. Transmiterea pachetelor cu și fără comprimare
Figura 2.2.1-2. Transmiterea pachetelor cu și fără comprimare (continuare)
Lucrul care se poate întâmpla în cazul neutilizării comprimării este umplerea cozii de așteptare și aruncarea pachetelor.
Un alt instrument este CAC (Call Admision Control). Acesta poate decide dacă rețeaua mai poate accepta noi convorbiri telefonice sau transmisii video. De exemplu, rețeaua poate accepta doar trei apeluri de VOIP (voice over IP) de tip G.729A pe o anumită cale; CAC va fi folosit pentru fiecare apel și atunci cînd acestea vor depăși numărul maxim apelurile noi nu vor fi acceptate.
Tehnicile de formare a cozilor de prioritate alocă o anumită lățime de bandă pentru fiecare coadă în parte. De exemplu, alocarea 75% din trafic unei cozi și a 25% altei cozi.
Figura 2.2.1-3. Rezervarea lățimii de bandă folosind cozi de așteptare
2.2.2. Întârzierea
Într-o rețea orice pachet experimentează anumite întârzieri din momentul în care este trimis de la sursă pînă ajunge la destinație. Majoritatea conceptelor QoS sunt legate mai mult sau mai puțin de întârzierile care apar într-o rețea. Întîrzierile pot apărea în mai multe locuri într-o rețea; în anumite locuri nu se simt dar în altele au un impact negativ asupra performanțelor rețelei. Există următoarele tipuri de întârzieri:
1. De serializare (fixă)
2. De propagare (fixă)
3. De folosire a cozilor (variabilă)
4. De procesare (variabilă)
5. De ajustare (variabilă)
6. De rețea (variabilă)
7. De codec (fixă)
8. De compresie (variabilă)
Voi încerca să explic detaliat tipurile de întârzieri de mai sus pe următoarea topologie de rețea. Să presupunem că avem o rețea locală LAN în Oradea, România, care este legată prin linii închiriate de alte LAN-uri din Europa, cel mai aproape ca distanță fiind în Italia:
Figura 2.2.2-1 Topologia de rețea WAN pe care se vor calcula timpii de întârziere
1. Întârzierea de serializare – este legată de timpii de întârziere care apar la plasarea (codificarea) biților în mediu prin care se propagă. Dacă interfața e rapidă timpul de întârziere este mai mic. Folosim următoarea formulă pentru calculul acestor timpi:
#biții trimiși/ Viteza link
Să presupunem că vom trimite un pachet de 125-octeți de la Oradea spre server-ul care se află în Milano. Oradea trimite pachetul de 125-octeți echivalentul a 1000 biți, la viteza link-ului de Ethernet timpul va fi 1000 biți/100000000 bps, sau .01 ms pentru serializarea pachetului. De asemenea, se va întârzia cu .01 ms când switch-ul trimite pachetul la R1. Când pachetul părăsește R1 (Oradea) pentru R2 (București) pe un link serial de 56 kbps, întârzierea de serializare devine 1000 biți/56000 bps sau 17.85 ms. Legătura între București și Milano este o linie serială de 2 Mbps, deci vom avea o întârziere 1000 biți/2000000 bps sau 0.5 ms. La un pachet de 1500-octeți vom avea: 0.12 ms pe FastEthernet, 267 ms între Oradea și București, 0.75 ms pe seriala între București și Milano.
2. Întârzierea de propagare – ține de întârzierea care apare din momentul în care un bit părăsește sursa și momentul în care acest bit ajunge la destinație. Pentru distanțe mici aceste valori sunt neglijabile, la nivelul miilor de metri valorile cresc. Cea mai importantă variabilă care afectează întârzierea de propagare este lungimea link-ului. Astfel avem următoarele formule de calcul:
;
;
Unde este viteza luminii în vid; mulți folosesc a doua formulă atunci când este nevoie de mai multă exactitate; fiind viteza de propagare a luminii în mediul de cupru și mediu optic.
Pentru distanțele din figura de mai sus vom avea următoarele întârzieri:
Oradea – București = 3.1 ms
București – Milano = 8.75 ms
Total = 11.85 ms
3. Întârzierea de folosire a cozilor (Queuing Delay) – constă în timpul de întârziere care apare la așteptarea pachetelor în cozi, în special la ieșirea din router, așteptarea la intrare fiind minimă. Totuși, acest tip de întârziere poate fi destul de mare de ordinul sutelor de milisecunde sau chiar mai mult. Pachete fară prioritate vor aștepta mai mult facilitând astfel calitatea serviciilor de voce și video.
Să presupunem că trimitem patru pachete de 1500 octeți de la R1 (Oradea) la R2 (București). Deoarece întârzierea de serializare este de 1500*8/56,000 sau 214 ms pentru serializarea fiecărui pachet de 1500 octeți, următorul pachet fie va fi stocat în memorie fie va fi aruncat. Router-ele folosesc memoria RAM pentru păstrarea pachetelor. Cea mai simplă formă de păstrare este sub forma unei cozi FIFO (First-In, First-Out). După 856 ms, toate cele patru pachete vor fi trimise pe legătura serială. Presupunând că rețeaua nu a fost ocupată când am trimis cele patru pachete nu vom avea întârziere pentru primul pachet, cel de al doilea pachet va aștepta timpul de serializare al primului, adică 214 ms, al treilea 428 ms și al patrulea 642 ms. Fără a funcția de plasare a pachetelor în coadă ele trebuia să fie aruncate și probabil retransmise de mai multe ori.
4. Întârzierea de procesare (Forwarding delay) – se referă la întârzierea care apare la plasarea sau procesarea pachetului de la o interfață la alta și exclude întârzierea de folosire a cozilor. Aceasta se datorează timpilor de scoatere a pachetelui de nivel 3 OSI (IP) din pachetul specific interfeței de nivel 2, de exemplu, extragerea pachetului IP din frame-ul Ethernet și plasarea acestuia pe o altă interfață, spre exemplu, serială după identificarea destinației și asigurarea că acest pachet IP poate trece de listele de acces.
5. Întârzierea de ajustare (shaping delay) – se datorează tehnicilor QoS de ajustare a traficului. Ajustarea se produce atunci când traficul este mare și umple cozile de așteptare a router-ului destinație, router-ul sursă va fi astfel anunțat să încetinească trimiterea pachetelor. În cazul în care viteza de transmisie nu scade pachetele sunt aruncate și va fi nevoie de retransmiterea lor, valabil doar în cazul unui transfer cu capacități de recunoaștere a pierderilor și de retrimitere de pachete cum este TCP la Nivelul 4 OSI. Dacă această capabilitate ar lipsi, în multe cazuri în care s-ar depăși rata de transfer contractată de la furnizorul de servicii internet acesta din urmă ar arunca pachetele.
6-8. Întârzierea de codec și cea de compresie se întâlnesc mai des în rețelele de video și voce.
Tabelul de mai jos sumarizează tipurile de întârzieri.
Tabelul 2.2.2-1 Tipuri de întârzieri
Mecanisme QoS care afectează întârzierea
Soluția ideală pentru acest tip de întârziere ar fi din nou lățimea de bandă. Lățimea de bandă mai mare va diminiua întârzierea de serializare de care depinde întârzierea de așteptare în cozi. În rețelele Frame Relay o lățime de bandă contractată mai mare înseamnă diminuarea întârzierilor de ajustare.
Tabelul 2.2.2-2 Instrumente QoS ce afectează întârzierea
2.2.3. Jitter-ul
Pachetele consecutive care experimentează timpi diferiți de întârziere sunt cele care generează jitter-ul. Într-o rețea de date unde există timpi diferiți de întârziere jitter-ul există; întrebarea este unde ar fi limita la care jitter-ul existent nu ar afecta serviciile din rețea. Rețelele de voce peste date necesită o transmisie uniformă a pachetelor (de exemplu la fiecare 20ms), în caz contrar apare degradarea serviciului de telefonie IP. Aceleași instrumente care afectează întârzierea pot fi utilizate cu succes și în cazul jitter-ului.
2.2.4. Aruncarea pachetelor
O ultimă caracteristică care afectează performanțele unei rețele este aruncarea pachetelor. Router-ele aruncă pachete în multe cazuri, spre exemplu, atunci când FCS (Frame Check Sequence) nu este cel așteptat, sau pachetul respectiv nu trebuie să ajungă la destinație respectivă datorită politicilor de securitate…și cu aceste pierderi de pachete QoS nu poate face nimic. Dar exista și situații când pachetele pot fi salvate de la aruncare prin QoS și unul din aceste cazuri este atunci când aruncarea pachetelor are loc datorită umplerii cozilor sau memoriei router-elor.
Mecanisme QoS care afectează aruncarea pachetelor
Ca și în cazul celorlalte caracteristici de performanță, aruncarea pachetelor poate fi evitată prin lățimea de bandă…o mai mare lățime de bandă va duce la scăderea dimensiunii cozilor și la diminuarea riscului umplerii lor. Totuși, într-o rețea convergentă (voce, date, video) vor apărea probleme și după dublarea sau triplarea lățimii de bandă. O soluție fiabilă pusă la dispoziție de QoS este RED (Random Early Detection).
2.3. Caracteristicile traficului de voce și date
De ce am avea nevoie de QoS? QoS poate afecta lățimea de bandă, întârzierile, jitter-ul și aruncarea pachetelor. Aplicațiile au nevoie de cerințe diferite pentru parametrii enumerați anterior. Cu ajutorul QoS o rețea poate asigura mai bine fiecare aplicație cu necesarul ei de resurse.
2.3.1. Caracteristicile traficului de voce și QoS
Traficul de voce poate fi alterat repede în rețelele unde lipsește QoS. În această secțiune voi încerca să explic modul în care mecanismele QoS afectează traficul de voce. Fără QoS, cel care este sunat experimentează un apel slab. Vocea devine sacadată și de neînțeles. Întârzierile provoacă interactivitate scăzută, din cauza faptului că aceia care discută nu-și dau seama dacă interlocutorul lor a terminat sau nu fraza. Se pierde vocea, fiind auzite pauze în loc de voce. Apelul poate fi chiar intrerupt.
Bazele traficului de voce
Vocea peste date include Vocea peste IP (VoIP), Vocea peste Frame Relay (VoFr) și Vocea peste ATM (VoATM). Toate aceste trei tehnologii transportă voce dar fiecare diferit. Cea pe care vom pune accent este VoIP din cauza faptului că ea este folosită la transportul pachetelor între telefoanele IP.
În imaginea de mai jos voi prezenta un apel telefonic folosind VoIP de la Oradea în Milano.
Figura 2.3.1-1 Topologia de rețea WAN pe care se va prezenta VoIP
Înainte de a fi auzită vocea în celălalt capăt trebuie să se întâmple mai multe lucruri. Utilizatorul trebuie să formeze numărul. Router-ul conectat la telefon interpretează digiții și folosește semnalizarea pentru a crea un apel VoIP. Deoarece ambele telefoane sunt conectate prin porturi analogice la R1 și R3, router-ele vor folosi semnalizarea H.323. La o anumită etapă a procesului de semnalizare apelatul aude sunetul telefonului și după ce ridică receptorul procesul de creare a apelului se încheie. Vocea care se aude acum la telefon folosește protocolul RTP (Real-time Transport Protocol).
În figura de mai jos voi prezenta structura pachetului IP folosind RTP:
Figura 2.3.1-2 Structura pachetului IP folosind RTP
Atunci când se folosesc telefoanele analogice, router-ul va colecta semnalul analogic, va digitaliza vocea, o va codifica folosind un codec de voce și va plasa vocea codificată în câmpul de voce din figura de mai sus. Adresa sursa IP va fi cea a router-ului R1 și adresa destinație va fi adresa R3. R3 va executa procesul invers față de R1 și va plasa semnalul sonor pe interfața spre telefon.
Telefoanele pe IP vor experimenta un proces similar chiar dacă detaliile diferă puțin. Procesul de semnalizare include folosirea protocolului SSCP (Skinny Station Control Protocol) care asigură fluxul de voce între telefoane și server-ul Cisco Call Manager (CCM). După ce semnalizarea a luat sfârșit, un flux RTP a fost creat între telefoane și nu mai este nevoie de CCM el fiind necesar la stabilirea conexiunii. R1 și R3 nu au un rol în stabilirea fluxului RTP și în crearea acestor pachete, deoarece telefoanele IP sunt capabile să creeze singure aceste pachete. În final administratorul de rețea poate alege diferite metode de codificare și decodificare a vocii pentru apelurile de VoIP. Codec-urile procesează semnalul analogic și îl convertesc într-unul digital (binar). Valoarea binară a reprezentării vocii depinde de codec-ul utilizat. Fiecare codec are mai multe proprietăți, una din cele mai importante este lățimea de bandă utilizată pentru transmiterea vocii codificate.
Tabelul de mai jos listează cele mai populare codec-uri și lățimea de bandă necesară pentru fiecare.
Tabelul 2.3.1-1 Codecuri și lățimea de bandă pentru transportul de voce
De remarcat este faptul că rata utilizării de bandă conține doar partea pachetului IP ce conține voce digitalizată.
În esență traficul de voce are următoarele elemente esențiale:
mai multe tipuri de protocoale de semnalizare stabilesc o conexiune RTP între două telefoane, ca și consecință a formării numărului de telefon conexiunea RTP transmite vocea între două telefoane (sau între două echipamente VoIP). Aceste două elemente au nevoie de diferite mecanisme QoS pentru a funcționa corect. În continuare când mă voi referi la voce voi folosi termenul de trafic de voce pentru conexiunea RTP. Semnalizarea de voce este traficul pentru crearea acestei conexiuni.
Mecanismele QoS pot trata vocea în mod diferit de traficul de semnalizare voce. Pentru a face acest lucru fiecare din uneltele QoS va clasifica traficul în una din aceste două categorii. Pentru această clasificare QoS folosește informațiile din tabelul de mai jos care reprezintă protocoalele și porturile care sunt utilizate de VoIP.
Tabelul 2.3.1-2 Protocoalele utilizate de VoIP
2.3.2. Caracteristicile traficului de date și QoS
Sute de mii de aplicații există la oră actuală și fiecare dintre ele sunt diferite. Unele sunt bazate pe TCP altele pe UDP, unele sunt tolerante la întârzieri altele nu, unele trimit datele în rafale altele au nevoie de un trafic constant, etc.
Caracteristicile traficului de date variază de la o aplicație la alta. Mai mult ele variază și în cadrul mai multor versiuni ale aceleiași aplicații. Ca de exemplu o companie producătoare de componente electronice care folosit QoS pentru voce și date critice (SAP/V3) a constat că totul a merge bine aproximativ șase luni. După această perioadă au apărut plângeri ale utilizatorilor că nu puteau efectua sarcini uzuale în timp util și trebuia să aștepte enorm pentru o simplă interogare. Echipele de suport de aplicații au intervenit și au exercitat presiuni asupra echipelor de administrare a rețelei. După o investigație s-a descoperit o schimpare dramatică a caracteristicilor de trafic înversiunea nouă, proaspăt instalată de SAP.
Figura de mai jos arată aceste diferențe:
Figura 2.3.2-1 Diferențele caracteristicilor de trafic între versiunile aceleiași aplicații
În acest exemplu după ce s-a trecut de la versiunea 4.6C fără folosirea memoriei tampon la versiune 4.6C HTML a fost nevoie de 35 de ori mai mult trafic decît la versiunea anterioră. În consecință QoS a trebuit să fie adaptat noilor cerințe ale aplicației.
Din exemplul de mai sus ne putem da seama că pentru clasificarea traficului de date este nevoie de mare atenție. Din cauza acestei realități cercetătorii QoS au definit patru clase de trafic de date. Aceste clase sunt: Date tip Best-Effort, Date Mari, Date tip tranzacție sau interactive și Date definite local Critice. Fiecare din aceste clase sunt examinate mai jos:
Date Best-Effort
Atunci când aplicăm QoS pentru traficul de tip Best-Effort sunt recomandate următoarele sfaturi:
Acest trafic este marcat cu DSCP 0.
Acestui trafic trebuie acordată o lățime de bandă de aproximativ 25% din cauza
faptului că o mare parte din aplicații aparțin acestei categorii de trafic.
Traficul de date aparține implicit acestei clase doar aplicațiile care sunt selectate pentru un trafic preferențial aparțin de alte clase.
Date Mari
Implementarea QoS pentru acest tip de trafic trebuie să țină cont de următoarele reguli:
trebuie să fie marcate cu DSCP AF11; în cazul exesului de trafic se remarchează
cu AF12 sau AF13.
trebuie să-i fie garantată o lățime de bandă moderată și trebuie să fie constrâns să nu ocupe toată lățimea de bandă disponibilă.
În această clasă intră aplicații care nu sunt interactive și nu sunt tolerante la aruncarea de pachete, de obicei au o durată de transfer mai lungă a datelor prin rețea. Ca de exemplu FTP, email, aplicațiile de backup, sincronizarea bazelor de date.
Avantajul asigurării unei lățimi de bandă moderate este că în orele cînd banda este liberă acest trafic poate folosi întreaga bandă și când banda este ocupată folosesc doar limita disponibilă.
Date tip tranzacție sau interactive
Implementarea QoS pentru acest tip de trafic trebuie să țină cont de următoarele reguli:
Datele tip tranzacție/interactive trebuie să fie marcate cu DSCP AF21;traficul în exces trebuie marcat din nou cu DSCP AF22 sau AF23
Datele de acest tip trebuie să posede o lățime de bandă garantată.
Acest tip de trafic este compus din datele tranzacționale și datele interactive ale aplicațiilor client/server sau de mesagerie interactivă.
Timpii de răspuns separă alicațiile cu date tranzacționale client/server de aplicațiile generice client/server. De exemplu în aplicații precum SAP, PeopleSoft, Oracle utilizatorii așteaptă terminarea unei operații înainte de a o putea începe pe următoarea (cu alte cuvinte tranzacția e o operație care nu este ascunsă).
Date definite local Critice
Implementarea QoS pentru acest tip de trafic trebuie să țină cont de următoarele reguli:
Acest tip de date trebuie marcat cu DSCP AF31; traficul în exces trebuie marcat cu DSCP AF32 sau AF33. Traficul de semnalizare pentru VoIP folosește DSCP 31; până se va rezolva această coincidență traficul definit local critic va putea fi marcat cu DSCP 25.
Acest tip de trafic are nevoie de o garantare a lățimii de bandă pentru traficul interactiv pe care-l suportă.
Această clasă de trafic este probabil cea mai confuză în sensul determinării carui tip de trafic îi aparține. Astfel, ea se definiște ca fiind traficul critic pentru organizația respectivă care îi asigură cerințele de trafic pentru afacere și fără prioritizarea acestui trafic afacerea ar avea de suferit. Este recomandată plasarea unui număr cât mai mic de aplicații în această clasă de trafic.
Tabelul de mai jos reprezintă rezumatul caracteristicilor de trafic pentru anumite aplicații și clasa în care s-ar potrivi cel mai bine:
Tabelul 2.3.2-1 Clasa și caracteristicile de trafic pentru anumite aplicații
Capitolul 3: Mecanismele QoS
Primul pas în definirea politicilor QoS este de a identifica traficul care trebuie să fie tratat diferit (preferențial sau diferențial). Acest lucru se realizează prin clasificare și marcare.
Termenii clasificare și marcare sunt deseori interpretați ca fiind identici. Ei se disting chiar dacă sunt folosiți împreună.
Clasificarea – sortează pachetele în tipuri de trafic diferit, pe care se pot aplica diferite politici. Clasificare are loc de obicei în toate nodurile rețelei dar nu este obligatorie peste tot. Clasificarea pachetelor poate avea loc și fără marcare.
Marcarea – tipic este folosită pentru delimitarea limitelor de încredere (trust). Poate fi folosită și în alte locuri în rețea. Nu este întotdeauna legată doar de clasificare.
Aceste două mecanisme sunt puse în practică prin clasificatori și marcatori care execută efectiv operațiile de marcare și clasificare și care au corespondenți în comenșile CLI de pe Cisco IOS.
3.1. Clasificarea
Mecanismele de clasificare examinează oricare din criteriile de mai jos pentru a identifica un flux și ai asigna un tratament diferențial sau preferențial.
Parametri de Nivel 1 – interfața fizică, subinterfață, PVC, sau port.
Parametri de Nivel 2 – adresa MAC, biții CoS, identificarea VLAN, biții MPLS experimentali, CLP din ATM, Frame Relay biții DE.
Parametri de Nivel 3 – IP Precedence, codul DiffServ DSCP, adresa IP sursă/destinație.
Parametri de Nivel 4 – porturile TCP sau UDP
Parametri de Nivel 7 – semnăturile aplicațiilor sau URL-urile în pachete
După ce traficul a fost corect identificat poate fi tratat prin anumite politici. Cele mai bune practici recomandă să identificăm și să marcăm traficul cu valori DSCP cît mai aproape de sursă. Dacă clasificare are loc corect nodurile care urmeză nu vor mai trebui să examineze în detaliu fiecare pachet sau frame. În schimb ele pot aplica deja politici pentru traficul clasificat.
CLI pentru clasificare
Ca și parte integrantă a sistemului de operare Cisco IOS, modulul MQC vine cu comenzile de tip class map pentru a efectua clasificarea traficului. Comanda permite identificarea fluxului prin mai multe criterii, aceste criterii pot fi selectate toate sau separat prin cuvântul cheie match.
match-all – operația logică ȘI, care înseamnă că toate condițiile trebuie să fie adevărate în același timp pentru ca maparea să aibă loc.
mach-any – operația logică SAU, oricare din condițiile clasei care este adevărată va face ca maparea să fie validă.
Exemplul de mai jos permite înțelegerea mai ușoară a conceptului de clasificare:
Exemplul 3.1-1 Aplicarea CLI pentru clasificare pe un router Cisco
Mai sus se definesc trei mapări de clase diferite. Prima clasă, este clasa ERP, care va mapa traficul ce corespunde cu protocoalele (sqlnet, ftp, telnet). În clasa AUDIO-VIDEO, clasificarea se va efectua după traficul MIME video sau audio. Ultima clasă de trafic va filtra paginile web care au poze de tip GIF sau JPG.
AutoQoS introduce o tehnică care se numește NBAR și care este capabilă să efectueze clasificarea automată a traficului prin mecanisme de „mirosire” a rețelei.
3.2. Marcarea
Principalele tipuri de marcare folosite astăzi sunt marcarea bazată pe clase și marcarea folosind politicile de clasă. Alte tipuri de marcare mai vechi sunt CAR (Committed Access Rate) și PBR (Policy-Based Routing).
3.2.1. Marcarea bazată pe clase
Marcarea bazată pe clase a fost introdusă în versiunea 12.1(2)T și este reprezentată de comanda din MQC set în cadrul comenzii policy map pentru a marca pachete, frame-uri, celule sau ethichete. Următorul exemplu exemplifică opțiunile pe care le avem în cadrul comenzii set:
Exemplul 3.2.1-1 Utilizarea comenzii set
Este de remarcat faptul că marcarea bazată pe clase are loc după clasificarea pachetelor, adică, set are loc după ce s-a găsit o clasă (match) pentru pachet. Cu alte cuvinte dacă clasificarea are loc pe o interfață de intrare a unui echipament, marcarea va fi implementată pe interfața de ieșire din acel echipament.
3.2.2. Marcarea bazată pe politicile de clasă
Aplicarea de politici și alte mecanisme de ajustare sunt o altă cale de marcare a pachetelor. În loc de a marca fiecare pachet cu o anumită valoare, un marcator de politici va marca sau chiar va arunca orice pachet care nu este în concordanță cu politica pe care o promovează. Următorul exemplu arată sintaxa necesară pentru un limitator de rată care va transmite pachetele doar dacă ele se conformeză politicii sale:
Exemplul 3.2.2-1 Politică de limitare a traficului
Din exemplul de mai sus putem observa că în cazul în care se va viola limita de transmitere pachetele vor fi aruncate. Acest exemplu este tipic pentru configurarea conexiunilor tip Frame Realay. Acest tip de marcare poate seta IP Precedence, DSCP, MPLS EXP, Frame Relay DE, ATM CLP.
Exemplul de mai jos prezintă opțiunile pentru marcarea bazată pe politicile de clasă:
Exemplul 3.2.2-2 Opțiunile pentru marcarea bazată pe politicile de clasă
3.2.3. Marcarea de Nivel 3
Marcarea de Nivel 3 prin DSCP și IP Precedence este cea mai larg răspândită metodă de marcare implementată din cauza faptului că marcarea de Nivel 3 are o semnificație de la capăt la capăt și poate fi translată ușor în marcare de Nivel 2.
IP Precedence
Al patrulea octet din pachetul IP este octetul ToS (Type of Service). Primii trei biți sunt numiți biții IP Precedence. Biții IP Precedence, similar cu cei din standardul 802.1Q/p CoS permit opt valori diferite pentru marcare (0 la 7). Din cauza faptului că valorile 6 și 7 sunt rezervate pentru protocoalele de rutare și valoarea 0 este implicită în realitate se folosesc pentru marcare 5 valori:
IP Precedence cu valoarea 5 este recomandat pentru voce.
IP Precedence cu valoarea 4 este împărțit de video-conferință și fluxul video.
IP Precedence cu valoarea 3 este recomandat pentru semnalizare voce.
Rămân doar două valori pentru traficul de date (1 și 2). Acest lucru pare destul de restrictiv și din această cauză multe firme preferă implementarea DSCP cu 64 de valori posibile.
DSCP (Differentiated Services Code Points)
DSCP folosește aceeași trei biți ca și IP Precedence dar prin combinarea lor cu următorii trei biți din octetul ToS asigură șase biți pentru marcare. De aici valorile DSCP pot fi de la 0 (000000) la 63 (111111). Aceste valori asigură o marcare granulară a traficului.
Valorile DSCP pot fi exprimate numeric sau prin cuvinte cheie, numite PHB (Per-Hop Behaviors). Există trei clase de PHB: Best-Effort (BE sau DSCP 0), Afxy (Assured Forwarding) și EF (Expedited forwarding).
În documentul RFC 2597 este definit termenul de clasă AF, o clasă AF este reprezentă de literele AF și două cifre xy. Prima valoare x poate varia de la 1 la 4 ea formând clase compatibile cu cele IP Precedence. Al doilea digit reprezintă probabilitatea de aruncare a pachetului, spre exemplu AF33 va fi aruncat mai repede decât AF32 care va fi aruncat mai repede decât AF31.
În figura de mai jos este reprezentată maparea de la Codurile PHB la valorile binare DSCP:
Figura 3.2.3-1 Maparea de la Codurile PHB la valorile binare DSCP
3.3. Aplicarea de politici și ajustarea
Tehnicile de aplicare a politicilor și de ajustare sunt formele cele mai vechi ale QoS. Aceste unelte au același obiectiv, și anume, de a identifica și a răspunde la violarea traficului. Ceea ce au diferit este modul cum reacționează la aceste nereguli.
Tehnicile de aplicare a politicilor – sunt cele care realizează o verificare în timp real a traficului și în cazul în care detectează nereguli aplică acțiunile prescrise. De exemplu, se poate detecta excesul unei rate de trafic definit și în acest caz se vor remarca pachetele și se vor arunca. Figura de mai jos reprezintă comparația între aceste două tehnici:
Figura 3.3-1 Comparație între aplicarea de politici și ajustare
Ajustarea – este un mecanism de rearanjare și rafinare a traficului care lucrează împreună cu mecanismale de plasare în coadă. Obiectivul este ca tot traficul să fie trimis mai departe sub o anumită rată pentru a nu fi aruncat. Acest mecanism se folosește pe router-ele de la ieșirea din rețeaua privată în cea a furnizorului de servicii internet. Contractul este făcut pentru o anumită rată la tehnologia Frame Relay este numită CIR, dacă această rată ese depășită atunci pachetele care vin în exces sunt aruncate. Pentru a nu se pierde aceste pachete se folosește tehnica de ajustare.
Mai jos voi prezenta o comparație între aplicarea de politici și ajustare.
Tabelul 3.3-1 Caracteristici Aplicarea de Politici și Ajustare
3.4. Mecanismele de Management al congestiei
Dintre toate mecanismele QoS tehnicile de management a congestiei asigură cel mai mare impact asupra funcționării aplicațiilor de rețea. Aceste tehnici se numesc și tehnici de plasare în coadă și se aplică pe interfețele unde este experimentată o congestie de trafic. Întotdeauna pachetele intră pe interfață mai repede decât ies și deci riscul ca să se creeze o congestie există.
Este important de remarcat că aceste tehnici se activează atunci cînd apare congestionarea rețelei pe o interfață. Dacă nu există congestie pachetele sunt trimise mai departe imediat ce sosesc pe interfața de intrare. Atunci când are loc congestia, pachetele trebuie plasate în memorii tampon sau în cozi pentru a evita aruncarea.
Planificarea și Plasarea în Cozi
Planificarea se referă la modul în care un pachet sau un frame părăsește echipamentul de rețea. Acest termen se referă la rearanjarea pachetelor funcție de priorități la ieșire. De exemplu, intrarea pachetelor pe o interfață a unui router care separă un LAN de un WAN are loc mult mai rapid decât ieșirea. Pentru ca traficul critic să poată ajunge în timp until la destinație este nevoie de plasarea traficului fără prioritate în memorii tampon și plasarea pe interfața de ieșire a traficului prioritar.
Figura de mai jos arată acest proces:
Figura 3.4-1 Plasarea în Cozi și Planificarea
Prin definiție plasarea în cozi și planificarea sunt complementare, însă acțiunile lor se împletesc pentru a da rezultatele calității rețelelor moderne:
Plasarea în cozi – se ocupă de plasărea pachetelor în diferite cozi legate de tampoanele de memorie. Este important de remarcat că plasarea în cozi este activată doar cînd există congestie și este dezactivată în scurt timp după ce congestia dispare.
Planificarea – este mecanismul care implică decizia cu privire la ce pachet să fie trimis următorul. Planificarea are loc cînd este congestie și atunci cînd nu este congestie. Atunci cînd există congestie planificarea trebuie să decidă care din cozile deservite va furniza următorul pachet pentru trimitere. Aceste decizii se iau pe baza următorilor algoritmi:
De strictă prioritate – cozile fără prioritate sunt servite doar dacă cozile de strictă prioritate sunt goale. Acest tip de planificare crește riscul congestiei în cozile neprioritare,
Round-Robin – cozile sunt servite la rînd pentru anumite intervale de zimp. Acest tip de planificare poate duce la umplerea cozilor cu trafic strict prioritar.
Prin cântărire – pachetele sunt „cântărite” după IP Precedence și astfel anumite cozi sunt servite mai des decât altele. Acest tip de planificare rezolvă problemele celorlalte două tehnici. El însă nu rezolvă garantarea lățimii de bandă de care are nevoie traficul prioritar.
3.5. Mecanismele de Evitare a congestiei
Mecanismele de evitare a congestiei, ca de exemplu WRED, sunt complementare și dependente de tehnicile de plasare a pachetelor în cozi. Plasarea în coadă sau planificarea se ocupă de capetele cozii pe când evitarea congestiei se ocupă de mijlocul sau „corpul” cozii.
Evitarea congestiei este destinată să gestioneze traficul TCP. TCP are un mecanism de retransmisie care crește rata de transmisie a traficului până cînd are loc aruncarea de pachete. Acest lucru se întâmplă de obicei cu traficul care are date mari (fișiere mari). Dacă se încearcă retransmiterea lor se ajunge la cosumarea întregii lățimi de bandă pentru trafic neprioritar care duce la congestionarea generală a rețelei.
Mecanismul RED (Random Early Detection)
Mecanismul RED calculează efectul sincronizarii globale TCP aruncând pachete alese aleator pentru a preântâmpina umplerea cozilor. Aruncarea aleatoare de pachete este mult mai bună decât aruncarea tuturor pachetelor și retransmiterea lor din nou prin TCP.
În loc de a aștepta umplerea tampoanelor de memorie ale cozilor pentru a arunca pachete, routerul folosește RED pentru a detecta traficul care poate duce la umplere și a arunca pachete din el. La tehnologia Frame Relay se aruncă pachetele marcate cu DE (Discard Eligible) și care de obicei nu sunt prioritare și nu au impact asupra traficului critic.
Sistemul de operare Cisco IOS implementează o tehnologie evoluată din RED care se numește WRED (Weighted RED) și care face același lucru prin algoritmi mai complecși de detectare și aruncare a pachetelor ce pot duce la umplera cozilor.
Mecanismul WRED (Weighted Random Early Detection)
WRED este o tehnică îmbunătățită față de RED care are o mai mare influență asupra alegerii aleatoare a pachetelor care trebuie aruncate. WRED ia în cosiderație valorile IP Precedence pentru a selecta pachetele pentru aruncare.
Implicit, WRED aruncă pachetele cu o valoare mai mică IPP mai des decît pachetele cu o valoare mai mare.
WRED poate fi configurată pe interfață dar este recomandată utilizarea ei împreună cu setul MQC pentru că acest lucru duce la creșterea granularității și posibilității de control a algoritmului.
Mecanismul ECN (Explicit Congestion Notification)
În mod tradițional, singura cale de a informa stația care transmite că a avut loc o congestie în rețea era să arunci pachetele TCP.
RFC 3168 definește o nouă metodă mult mai eficientă pentru rețea dea a comunica congestia stației care transmite. Această metodă constă în adăugarea biților ECN la pachetul IP. Prin marcarea ultimilor doi biți ai octetului ToS din IP, echipamentele de rețea pot comunica între ele și la stațiile care transmit că ele experimentează o congestie. Acești doi biți se definesc:
bitul ECN – Capable Transport (ECT) – indică dacă acest echipament suportă ECN.
bitul CE (Congestion Experienced) – indică dacă congestia a avut log pe ruta pachetului.
În perioada congestiei, WRED și WRED bazat pe DSCP aruncă pachetele care depășesc o anumită limită de aruncare. ECN ca și extinsie a WRED marcheză pachetele, îl loc de a le arunca pentru a semnala congestia atunci cînd se depășește limita de aruncare. Routerele care sunt capabile să suporte combinația WRED și ECN au instalat sistemul de operare Cisco IOS 12.2(8)T sau mai mare. În acest fel ratele de transmisie TCP pot fi controlate fără aruncarea pachetelor sau aruncarea parțială.
Combinația WRED ECN ia următoarele acțiuni atunci când este activată:
Dacă numărul pachetelor în coadă este mai mic decît limita minimă de aruncare, pachetele sunt transmise. Acest lucru are loc dacă ECN este sau nu activat. Acest tratament este identic cu situația în care ar fi activat doar WRED.
Dacă numărul pachetelor în coadă este între limita minimă și cea maximă se pot întâmpla următoarele lucruri:
Dacă ECT arată că ambele capete ale fluxului de rețea sunt capabile ECN (ECT=1) și WRED a determinat faptul că pachetul trebuie să fie aruncat, biții ECT și CE sunt setați pe 1 și transmiși. Pachetele sunt marcate în loc de a fi aruncate.
Dacă bitul ECT este 0 adică nu este suportat ECN pe ambele capete, pachetele încep să fie aruncate conform WRED.
Dacă ambii biți sunt setați pe 1 ECT și CE atunci pachetul este transmis fără nici o setare.
Dacă limita de aruncare maximă este atinsă toate pachetele vor fi aruncate indiferent de ENC sau CE până la stabilirea traficului mai jos de limita maximă.
Pentru activarea combinației WRED și ECN vom folosi sintaxa random-detect ecn ca în exemplul de mai jos:
Exemplul 3.5-1 Folosirea WRED și ECN
Există mecanisme QoS care nu au fost abordate în acestă lucrare pentru că nu au fost efectiv utilizate la implementarea practică a QoS în rețeaua locală LAN pe care o prezint în capitolul cinci. Cisco oferă mult mai multe detalii despre aceste mecanisme și de asemenea menține dezvoltarea și evoluția lor.
Capitolul 4: QoS în rețeaua locală (LAN)
4.1. Mecanisme QoS în LAN
4.1.1. Necesitatea aplicării QoS în LAN
Aplicarea QoS în LAN este deseori înțeleasă greșit și pare lipsită de sens pentru o bună parte din administratorii de rețea. Dacă avem în plan extinderea rețelei de voce și de video-conferințe peste cea de date, ar trebui să acordăm prioritate strategiilor de QoS aplicate în rețeaua locală. Această planificare va duce la un succes sau la o nereușită a proiectului în fața utilizatorului final.
În acest capitol voi aborda nevoia pentru QoS în rețeaua locală și voi discuta următoarele noțiuni existente:
Prioritizare de nivel 2 (CoS)
Mapare între nivelul 2 și nivelul 3 (DSCP-to-CoS)
Cozi de nivelul 2
Nivele de aruncare
Limite de încredere
Umplerea memoriilor tampon
Presupunem că este luni dimineața, ora 8:30. Majoritatea colegilor de muncă, care sunt mai mulți de o sută, pornesc calculatoarele simultan și își încep ziua de muncă. Traficul generat trece printr-un switch de nivel de acces (modelul Cisco) și converge într-un switch de nivel de distribuție. Pentru un anumit interval de timp, ceea ce se întâmplă este aruncarea pachetelor la ieșirea din switch-ul de nivel de acces spre switch-ul de nivel de distribuție. Într-o rețea tipică TCP/IP acest lucru nu este o problemă deoarece pachetele sunt retransmise. Într-o rețea compusă din aplicații în timp real, așa cum este telefonia IP și conferințele video, umplerea tampoanelor de memorie poate afecta calitatea serviciilor de sunet și video.
Într-un mediu de telefonie IP Cisco, procesorul de semnal G.729 (DSP) poate reconstrui până la 30 ms din pierderea de voce. Dacă a fost adoptat standardul Cisco de 20 ms pe pachet atunci un singur pachet se poate pierde fără a afecta calitatea vocii, dacă se pierd două pachete consecutive, rezultă o pierdere de 40 ms care nu poate fi compensată de algoritmul G.729 și o degradare a vocii în conversație. În cazul în care protocolul de timp real RTP va transporta informații de la un fax sau un modem, o pierdere de pachet va însemna o resincronizare a modemului, iar două vor duce la pierderea conexiunii.
Clasificând aplicațiile de timp real în rețeaua locală și asigurându-le un nivel corespunzător de prioritate, putem evita aceste probleme. Instrumentele QoS sunt necesare pentru manipularea acestor tampoane de memorie, pentru minimizarea aruncării de pachete, întîrzierii și jiter-ului. Lățimea de bandă nu este un înlocuitor pentru QoS în LAN!
4.1.2. Clasificarea și marcarea pachetelor
Clasificarea și marcarea de nivel 2 are loc în al 3-lea bit din câmpul numit Clasa Serviciului (CoS), care este în interiorul frame-ului Ethernet. CoS există în interiorul pachetelor atunci când este utilizat mecanismul de trunking folosit pentru comunicarea între mai multe LAN-uri virtuale figura 4.1.2-1. Există două tipuri de mecanisme de marcare a pachetelor pe o legătură trunk unul este ISL (Inter Switch Link) sau 802.1q. Câmpul CoS poate fi folosit pentru setarea a opt valori binare diferite care pot fi utilizate de celelalte instrumente QoS.
Figura 4.1.2-1 Prezentarea unei legături de trunk
Traficul reprezentat în figură poate fi de la un VLAN de voce și alte două de date, sau un VLAN de voce, altul video, și un al treilea de date. Pe legătura de trunk vom avea identificatori pentru pachetele care provin din vlan-uri diferite. Astfel, după cum am menționat mai sus vom avea fie încapsularea ISL, fie 802.1q a căror format este prezentat în figura de mai jos:
Figura 4.1.2-2 Formatul pachetelor folosite pe legătura de trunk
În figură se observă ca formatul ISL nu modifică frame-ul ethernet original ci doar îi atașează informații adiționale, acest mecanism este utilizat pe echipamentele Cisco. 802.1q este un standart ANSI și este folosit pe echipamentele Cisco și alte tipuri de echipamente făcându-le compatibile. Marcarea pachetelor de Nivel 3 are loc în interiorul câmpului Tipul Serviciului (ToS) sau Serviciu Diferențiat (DS) în pachetul IP.
Mapare între nivelul 2 și nivelul 3 (DSCP-to-CoS)
Swith-urile de Nivel 2 vor aplica QoS pe baza câmpului CoS în frame-ul Ethernet fără a lua în considerare marcarea pachetelor IP. După cum am discutat anterior, când un pachet iese pe interfața unui router care nu este configurată ca și 802.1q trunk, valoarea CoS nu există. Switch-ul care va primi acest pachet va marca valoarea CoS ca și 0, de asemenea, DSCP va fi la valoarea EF. Dacă switch-ul nu va reuși să clasifice pachetele la Nivel 3 aceste pachete vor trece drept trafic normal chiar dacă fac parte dintr-un trafic prioritar.
Pentru soluționarea acestei probleme trebuie mapată marcarea pachetelor de Nivel 3 la cea de Nivel 2 pe router și plasată o legătură trunk între switch și router în așa fel încât switch-ul de Nivel 2 să fie capabil să distingă traficul prioritar de cel fără prioritate. În figura de mai jos este prezentată o configurație de pe un router care este conectat cu un switch de Nivel 2.
class-map cos3
match cos 3
!
class-map cos5
match cos 5
!
class-map EF
match ip dscp EF
!
class-map AF31
match ip dscp AF31
policy-map map-cos-to-dscp
class cos5
set ip DSCP EF
class cos3
set ip dscp af31
class class-default
set ip dscp default
!
policy-map map-dscp-to-cos
class EF
set cos 5
class AF31
set cos 3
class class-default
set cos 0
!
interface FastEthernet0/0
!
interface FastEthernet0/0.1
encapsulation dot1Q 2
service-policy input map-cos-to-dscp
service-policy output map-dscp-to-cos
!
interface FastEthernet0/0.2
encapsulation dot1Q 2 native
Figura 4.1.2-3 Configurația unui router necesară pentru maparea între Nivelul 3 și 2 OSI
În figura de mai sus definirea politicii de mapare (policy-map map-dscp-to-cos) va lua în cosiderare trei valori pentru DSCP care trebuie mapate în CoS: pentru valoarea EF se va marca CoS 5, pentru AF31 se va marca CoS 3 și respectiv pentru valoarea implicită CoS va fi 0. De asemenea, această politică se aplică pe interfața router-ului care face legătura cu switch-ul de nivel 2. Nu am folosit această mapare în cazul rețelei pe care o administrez din cauza folosirii switch-urilor de Nivel 3 care fac automat această mapare. După ce s-a stabilit din ce clasă face parte pachetul urmează ca acesta să fie direcționat spre coada corespunzătoare de celelalte mecanisme QoS.
4.1.3. Cozile de așteptare de Nivel 2
Chiar dacă există similarități între router-e și switch-uri, o perspectivă diferită ne va ajuta să înțelegem mai bine problemele care apar la cozile de așteptare în LAN. Cozile de nivel 2 sunt ca niște containere care colectează pachete înainte ca acestea să fie transportate. Cu cât e mai mare containerul cu atât încap mai multe pachete în el. Într-un switch care are o coadă, la care ne vom referi cu 1q, de exemplu, tot traficul va fi plasat într-o singură coadă fără a se ține cont de clasificare și va fi deservit după principiul FIFO (First-In, First-Out). Dacă pachetul ajunge în coadă când aceasta este supraîncărcată, el poate fi aruncat dacă coada numai poate păstra pachete.
Dacă se utilizează cozi multiple pe o interfață a unui switch acestea vor folosi aceeași memorie tampon limitată pentru a aloca spațiu de memorie pentru fiecare coadă. Putem însă proteja traficul de voce plasând pachetele sensibile la întârzieri într-o coadă și restul traficului în altă coadă. De exemplu, switch-ul care folosește două cozi la care ne vom referi ca și 2 q, este capabil să direcționeze tot traficul care îndeplinește un anumit criteriu, presupunem vocea cu valoarea CoS 5 într-o coadă și în același timp tot celălalt trafic în altă coadă. Deoarece pachetele de voce sunt mai mici este puțin probabil să se umple coada în care sunt păstrate și astfel dispare posibilitatea degradării traficului de voce.
Fiecare port are o memorie limitată, dacă vom folosi o coadă de așteptare ea va ocupa întreaga memorie, dacă vom folosi două cozi, spațiul de memorie va fi divizat în două, trei cozi vor duce la crearea a trei spații de memorie diferite din acel spațiu inițial finit…Dacă spațiul de memorie alocat unei cozi este foarte mic ea nu va face față creșterii traficului. Deoarece cozile fără prioritate sunt deservite după algoritmul Round-Robin sau Weighted Round-Robin, nu există nici o certitudine că pachetul aflat în coadă va fi transportat imediat. Astfel, poate apărea umplerea tampoanelor de memorie înainte ca pachetele să poată fi transportate din cauza spațiului mic de memorie pe care îl are o coadă.
Remediul pentru această problemă este folosirea unei cozi prioritare care va transporta pachetele imediat ce acestea sosesc în coadă. Ne vom referi la această coadă ca și la 1p – o coadă prioritară. Astfel vom avea 1p1q, adică o coadă prioritară și una standard. Tot traficul prioritar va merge direct la destinație trecând prin coada de prioritate 1 și celălalt trafic va aștepta trecerea traficului prioritar. Chiar dacă se vor pierde pachete din coada standard acest lucru nu va afecta traficul sensibil la întârzieri și acest lucru este de dorit. În tabelul de mai jos voi prezenta tipurile de cozi existente pe un switch:
Tabelul 4.1.3-1 Tipuri de cozi existente în LAN
4.1.4. Limitele de aruncare
Limitele de aruncare definesc cantitatea de memorie tampon de nivel 2 care trebuie să fie folosită înainte de a începe aruncarea unui anumit tip pachete. Cu alte cuvinte, cât de mult se pot umple memoriile tampon fără a se lua o decizie cu privire la aruncarea pachetelor. Unele switch-uri au o coadă prioritară și una standard cu patru limite de aruncare pe coada standard. Cu aceste limite de aruncare se va stabili care pachete pot fi aruncate mai agresiv funcție de valoarea CoS pe care o au.
În tabelul următor avem stabilite anumite limite pentru aruncarea pachetelor în coada standard.
Tabelul 4.1.4-1 Limitele de aruncare pentru o coadă standard
Dacă coada a ajuns la 50% din capacitate, traficul cu CoS egal cu 0 sau 1 devine eligibil pentru aruncare pentru a preântâmpina congestionarea. Dacă coada continuă să se umple în ciuda faptului că se aruncă pachete, atunci cînd ajunge la 60% din capacitate traficul care are CoS 0,1,2, sau 3 devine eligibil pentru aruncare. Dacă procesul de umplere continuă până la 80%, traficul clasificat cu CoS 0,1,2,3,4, sau 5 devine eligibil pentru aruncare pentru a se preântâmpina congestionarea rețelei.
La 100% tot traficul indiferent de clasificare este eligibil pentru aruncare. În figura de mai jos este reprezentată diagrama limitelor de aruncare într-o coadă de Nivel 2.
Figura 4.1.4-1 Limitele de aruncare a pachetelor într-o coadă de Nivel 2
Utilizarea limitelor de aruncare permite folosirea eficientă a tampoanelor de memorie disponibile pe switch. Astfel, spațiul de memorie nu va fi doar împărțit între cozi cu diferite nivele de prioritate ci și utilizat corect de traficul care are nevoie de el pentru a nu fi aruncat.
4.1.5. Limitele de încredere
Limitele de încredere sunt locurile rețelei de unde putem avea încredere în marcarea pachetelor. Acest lucru devine mai important în momentul în care unele sisteme de operare permit calculatoarelor un anumit control asupra marcării pachetelor. Multe sisteme Unix și Linux mai nou și platforme de Windows permit marcarea pachetelor pentru QoS. Din acest motiv este importantă delimitarea spațiilor de unde echipamentele de rețea pot avea încredere în marcarea traficului. Mai jos este prezentată o rețea unde limitele de încredere sunt plasate înainte de telefoanele IP care sunt capabile să ajusteze marcarea pachetelor pe care o primesc de la calculator. Astfel traficul marcat de calculator ca și prioritar va fi marcat de telefonul IP ca și trafic normal urmând ca traficul de voce să fie clasificat drept prioritar Figura 4.1.5-1:
Figura 4.1.5-1 Limitele de încredere și marcarea pachetelor
Limitele de încredere sunt utile pentru marcarea corectă a traficului. Cu ajutorul lor un administrator de rețea poate controla mai bine echipamentele care au dreptul să marcheze pachetele cu prioritate.
4.2. Capabilitățile QoS ale Switch-urilor Cisco Catalyst
Switch-urile Cisco Catalyst oferă o gamă largă de tehnici pentru configurarea QoS în LAN asigurând funcționarea corectă a aplicațiilor de timp real. În secțiunea următoare voi discuta capabilitățile QoS și componentele hardware ale următoarelor switch-uri Cisco:
Catalyst 6500
Catalyst 4500
Catalyst 3550
Pe aceste tipuri de switch-uri am aplicat și configurat QoS în rețeaua locală.
4.2.1. Capabilitățile QoS ale Switch-ului Cisco Catalyst 6500
În această secțiune voi trata aspectele ce țin de prioritizarea traficului de voce pe un asemenea echipament.
Arhitectura Cisco 6500 distribuie capabilitățile QoS pe carduri hardware, unul dintre ele se numește Supervisor și celălalt PFC (Policy Feature Card).
Supervisorul și motorul de forwardare
De tipul de supervisor și de motorul de forwardare depind capabilitățile QoS pe care le are un 6500. Există patru combinații care facilitează mai mult sau mai puțin implementarea QoS pe switch:
Tabelul 4.2.1-1 Combinații între supervisor și motorul de forwardare
Pentru a vizualiza capacitățile switch-ului mai exact combinația de supervisor și motor de forwardare este folosită comanda show module: Figura 4.2.1-1
Figura 4.2.1-1 Rezultatul comenzii show module
Swith-ul nostru face parte din prima combinație și deci are suport pentru QoS de Nivel 3 OSI, se va putea astfel implementa QoS la nivel de pachete și nu va fi nevoie de mapare între CoS și IP DSCP.
Cardul PFC (Policy Feature Card)
Capabilitățile switch-ului Cisco 6500 sunt dependente de faptul dacă au sau nu instalat un asemenea card PFC. De exemplu, motorul de forwardare de nivel 2 cu supervisorul I sau IA clasifică, marchează și prioritizează traficul bazându-se pe adresa plăcii de rețea MAC sau pe informațiile din pachetul de VLAN. Fără PFC, tot traficul va fi marcat la nivelul CoS din frame-ul Ethernet și nu va fi examinat pachetul IP, ignorându-se IP precedence și DSCP.
Cu ajutorul PFC, Cisco Catalyst 6500 este capabil să folosească instrumente avansate QoS cum ar fi marcarea și clasificarea pachetelor, planificarea și prevenirea congestiei bazându-se pe informații de nivel 2, 3 sau 4 OSI. Mai specific PFC poate efectua clasificarea, marcarea și aplicarea diferitelor politici. Cardurile de linie asigură plasarea în cozi și logica aruncării de pachete. PFC asigură forwardarea pachetelor la nivel 3, examinând conținutul pachetelor. Dacă adresa IP destinație există în memoria tampon pentru PFC acesta din urmă poate suprascrie următoarele câmpuri:
Adresa destinație de nivel 2 (MAC)
Adresa sursă de nivel 2 (MAC)
Timpul de viață TTL
CRC-ul de Nivel 3
Dacă adresa IP a destinației nu există în memoria tampon PFC, primul pachet din acest flux este forwardat la MSFC (Multilayer Switch Feature Card) pentru rutarea corectă a pachetului. Apoi întregul flux urmează interfața pe care este rutat primul pachet. Diferența este că PFC va suprascrie informațiile cu privire la marcarea QoS de Nivel 2 și 3.
Există două tipuri de PFC și anume PFC și PFC2. PFC2 are incluse mai multe capabilități pentru trafic multicast și unicast. Împreună cu Supervisor II oferă capabilități extinse de QoS pe orice tip de trafic. Este asigurată o facilitate numită ACE (Access-Control Entries) care este asemănătoare cu ACL (Access Control List) de pe routere însă care este implementată hardware și asigură filtrarea traficului de Nivel 2, adică la nivel de frame.
Interfețele Ethernet
Rolul QoS a interfețelor Ethernet pentru Catalyst 6500 include planificarea pachetelor și managementul congestiei, de asemenea, asigură pe linie curentul electric necesar pentru suportul aplicațiilor de timp real ca și telefonia IP. Capabilitățile interfețelor Ethernet trebuie înțelese corect pentru a configura QoS. Tabelul de mai jos prezintă capabilitățile QoS pe care le oferă modulele Ethernet de tipul WS-X65xx față de cele oferite de modulele mai vechi de tipul WS-X63xx:
Tabelul 4.2.1-2 Mărimea memoriilor tampon și a cozilor
Pentru switch-urile care folosesc sistemul de operare Catalyst OS comanda care afișează aceste capabilități este show port capabilities, din cauza faptului ca switch-ul disponibil în rețeaua noastră locală folosește Cisco IOS nu voi intra în detaliile acestei comenzi.
Cardurile WS-X65xx introduc capabilitățile cozilor prioritizate, de asemenea, măresc cu mult capacitatea memoriilor tampon pentru a se acomoda mai bine traficului intens. De asemenea, în afara faptului că asigură cozi de prioritate Supervisor IA și supervisor II oferă capabilități QoS mai bune față de Supervisor I pentru aplicațiile de timp real.
Programarea traficului care intră și care iese din switch se face întotdeauna pe baza valorilor CoS asociate cu frame-ul. Implicit valorile mai mari CoS sunt mapate numerelor mai mari. CoS cu valoarea 5 este asociat cu vocea peste IP VoIP și este mapat traficului cel mai prioritar.
În plus față de diferențierea între cozile standard și cele cu prioritate ridicată, fiecare coadă standard are mai multe limite de aruncare. Mai jos voi prezenta două tipuri de limite de aruncare:
Limită de aruncare tip coadă
Pe porturile pe care este setat acest tip de aruncare a pachetelor, frame-urile cu o anumită valoare CoS sunt lăsate în coadă până ce numărul asociat cu această valoare este depășit. Aici se începe aruncarea frame-urilor până se revine la valoarea admisibilă.
Pachetele cu valoarea QoS unu vor avea ca și limită de aruncare valoarea 60%, adică dacă coada va depăși 60% orice pachet cu valoarea QoS unu va fi aruncat.
Limita de aruncare tip WRED
Pe porturile cu limite de aruncare tip WRED (Weighted Random Early Detection), frame-urile cu o anumită valoare CoS sunt lăsate să intre în cozi pe baza unui algoritm de probabilitate aleator creat să preîntâmpine congestia. Probabilitatea ca un frame cu o anumită valoare CoS să fie admis în coadă depinde de greutatea și limita de aruncare atribuită cu acea valoare CoS.
Dacă CoS 2 este atribuită cozii 1, cu limita de aruncare 2 de exemplu și marginile de limitei sunt 40% cea de jos și 80% cea de sus, frame-urile cu valoarea CoS nu sunt aruncate până ce coada unu nu este 40% plină. Dacă umplerea cozii se apropie de 80%, frame-urile cu CoS 2 au o probabilitate tot mai mare să fie aruncate. Dacă se depășește limita superioară de 80% toate pachetele cu CoS 2 sunt aruncate până se revine mai jos de această limită. Frame-urile care sunt aruncate între cele două limite sunt selectate aleator nu pe bază FIFO. Această metodă funcționează eficient pentru protocoale ca și TCP care sunt capabile să-și ajusteze dimensiunea „ferestrei” de transmisie.
Fluxul QoS pe un switch Catalyst 6500
Dependența QoS de hardware-ul switch-ului este una evidentă, multe din capabilitățile QoS fiind implementate hardware. În continuare voi încerca să prezint fluxul traficului pe un 6500.
Frame-ul ajunge la portul de intrare Ethernet. Aici există trei lucruri de care depinde modul în care va fi deservit și anume: structura cozii de pe acest port, nivelul limitei de încredere pe coadă și marcarea existentă în frame. După ce s-a determinat coada de intrare și nivelul ei de umplere, portul de intrare va plasa frame-ul fie la un motor de forwardare de Nivel 2 sau la un PFC de Nivel 3 dacă este instalat (Figura 4.2.1-2).
Figura 4.2.1-2 Fluxul traficului la Cisco Catalyst 6500
Dacă nu există un PFC instalat, motorul de forwardare de Nivel 2 va plasa pachetul portului de ieșire Ethernet. Portul de ieșire va determina valoarea CoS a frame-ului pentru a-l plasa în coada cea mai apropiată. Atunci când există un PFC acesta va consulta memoria tampon pentru a determina dacă există deja o cale stabilită pentru acest pachet și dacă există PFC va plasa pachetul spre portul indicat. Din cauza capabilității PFC de operare la Nivel 3, el poate forwarda pachetele între VLAN-uri fără a pierde valorile CoS din frame și IP Precedence sau DSCP din pachet.
În cazul în care PFC nu va găsi o cale existentă în memoria tampon pentru acest pachet, el va fi plasat în MSFC pentru determinarea portului de ieșire, populând memoria tampon cu informații despre pachet pentru folosirea ulterioară. Acest lucru înseamnă că primul pachet din flux pierde valoarea CoS, din cauza faptului că este rutat la Nivel 3 prin MSFC. Totuși, celelalte pachete din flux vor fi rutate prin PFC și vor păstra totate valorile marcate în pachet.
Planificarea cozilor de intrare
Prima ocazie de a folosi QoS pentru un frame de intrare are loc când frame-ul intră în switch. Înainte ca PFC-ul să plaseze frame-ul pe una din cozile de ieșire intră în acțiune metodele QoS. De exemplu, planificarea cozilor de intrare definește modul cum este tratat pachetul sau frame-ul care intră în switch. Dacă QoS este activat și portul este marcat în interiorul spațiului de încredere (trust), switch-ul va folosi limitele de aruncare pentru a planifica intrarea frame-ului.
Figura 4.2.1-3 QoS aplicat pe un port Ethernet de intrare
Figura 4.2.1-3 arată schematic tratamentul pe care îl primește un frame sau un pachet la portul de intrare.
Prima variabilă de care se ține cont este dacă portul este unul de încredere (trust). Acest lucru este răspunsul la întrebarea: „Unde este limita de încredere?” Vrem să avem încredere în marcarea traficului de pe acest port? Dacă portul nu este de încredere atunci frame-ul este marcat cu QoS 0 și este plasat motorului de forwardare.
Dacă portul este de încredere, următoarea întrebare este: „Este acesta un port de trunk?”, „Are o încapsulare de tip ISL sau 802.1Q?” Dacă este un port Ethernet de intrare și nu este trunk, valoarea CoS configurată pe port este atribuită frame-ului. Dacă este un port de trunk, valoarea CoS marcată pe frame este acceptată.
Următoarea întrebare depinde de tipurile de carduri instalate. Dacă un PFC este instalat switch-ul are capacitatea de a clasifica ș marca traficul de Nivel 3. O altă întebare ar fi dacă dorim sau nu să avem încredere în IP precedence sau DSCP-ul de pe acest port. Dacă răspunsul este da, pachetul este forwardat la PFC. Dacă răspunsul este negativ, switch-ul va lua decizia de forwardare funcție de CoS.
După ce s-a identificat coada și limita pe care nu trebuie s-o depășească frame-ul se pune problema dacă tipul de trafic pe care el îl reprezintă mai are loc în coadă sau nu. În caz negativ frame-ul este aruncat, în cazul în care există loc acesta este alocat frame-ului care este forwardad spre PFC.
Motorul de forwardare de Nivel 2
Motorul de forwardare de Nivel 2 are mai puține opțiuni pentru aplicarea mecanismelor QoS din cauza faptului că operează la Nivel 2 OSI.
Dacă se primește un frame de la portul de intrare Ethernet, singura variabilă pe care o poate testa este adresa MAC a destinației sau adresa VLAN. Dacă frame-ul care intră îndeplinește acest criteriu, valoarea CoS poate fi suprascrisă. Dacă nu este găsită o valoare care să corespundă, frame-ul este forwardat la portul de ieșire cu valoarea CoS reținută de switch.
Motorul de forwardare de Nivel 3
PFC-ul are capacitatea de a marca, clasifica și aplica politici pe trafic bazându-se pe ambele nivele OSI, Nivelul 2 și 3. PFC-ul introduce de asemenea noțiunea de QoS ACL, care poate fi folosită pentru controlul granular peste configurația QoS. Figura 4.2.1-4 ilustrează fluxul unui frame sau pachet prin PFC:
Figura 4.2.1-4 Ruta unui pachet sau frame prin PFC
Atunci cînd pachetul ajunge în PFC, portul de intrare sau VLAN-ul de intrare este examinat pentru a vedea dacă este aplicabil un ACL. Dacă nu este aplicabil un ACL este folosit unul implicit. Un ACL implicit presupune o regulă de marcare configurabilă și o poltică configurabilă. Dacă ACL-ul implicit nu este cofigurat, ACE-ul va avea DSCP egal cu zero pentru tot traficul care intră pe portul configurat fără limită de încredere (trust). Dacă există un ACL setat pe port sau VLAN, ACL-ul va examina ACE-ul pentru a gasi o cîmpuri care se potrivesc cu cele din pachetele care intră.
Dacă PFC-ul folosește DSCP pentru fiecare pachet pe care îl procesează. Se va întreba dacă are încredere în DSCP, IP precedence, sau valoarea CoS din frame.Dacă valorile nu sunt de încredere, vloarea DSCP specificată în ACL este folosită. Dacă valorile sunt de încredere se va folosi DSCP-ul din pachetul care trece prin PFC. Pentru IP precedence sau CoS se vor folosi mapările de la DSCP la CoS sau de la IP precedende la DSCP.
Dacă a fost stabilită o anumită politică, PFC-ul va determina rata traficului și va decită să arunce pachete, să le marcheze, sau să le plaseze pe portul de ieșire neschimbate.
Planificarea pe portul de ieșire
Planificarea portului de ieșire definește cum este tratat un frame sau pachet la ieșirea din switch. Figura 4.1-11 arată calea unui pachet sau frame până la ieșirea din switch.
Când un frame ajunge pe portul de ieșire, valoarea CoS este examina pentru a determina corect coada și limita de aruncare din coda respectivă pentru acest frame. În exemplul de mai jos, switch-ul are trei cozi diferite în care poate fi plasat frame-ul: 2q2t, 1p2q2t și 1p3q1t. Pe baza valorii CoS se va determina corect coada de ieșire. Dacă se determină coada și limita de aruncare pentru acest frame se va verifica dacă mai există spațiu în coadă și dacă limita de aruncare pentru acest tip de rafic nu este atinsă. Dacă limita este atinsă și depășită frame-ul va fi aruncat în caz opus el va fi plasat în coadă pentru transport.
Figura 4.2.1-5 Tratamentul frame-ului pe un port Ethernet de ieșire
4.2.2. Capabilitățile QoS ale Switch-ului Cisco Catalyst 4500
Switch-ul Catalyst 4500 este modular și scalabil, fiind ales ca și soluție excelentă pentru rețele medii și mici. Designul modular permite configurarea echipamentului funcție de nevoile rețelei. O altă capabilitate utilă este tensiunea în linie care asigură alimentarea telefoanelor IP și punctelor de acces pentru rețele fără fir.
Configurația QoS suportată de switch depinde de supervisorul instalat pe el. Astfel, pentru switch-urile 4500 și 4000 avem disponibile patru tipuri de supervisor. Tabelul de mai jos prezintă tipurile de supervisor și switch-urile care le suportă:
Tabelul 4.2.2-1 Matricea Supervisor switch pentru seria 4500
Supervisor I și II
Modulele supervisor I și II folosesc sistemul de operare Cisco Catalyst. Folosind aceste module switch-urile din seria Catalyst 4500 și 4000 au o singură coadă de intrare de tip FIFO. Coada de transmisie constă din două cozi standard cu o singură limită de aruncare (2q1t). Ambele cozi sunt planificate pe baza algoritmului round-robin. Admiterea în cozi se face pe baza protocolului 802.1p cu valoarea CoS din frame; examinându-se 2 din 3 biți pentru a se determina valoarea CoS. Această limitare duce la grupare valorilor CoS pe perechi. Pentru maparea CoS 5 la o coadă va trebui să mapăm și CoS 4 la aceeași coadă, de exemplu, Coada 2.
Dacă QoS este activat global fără nici o altă configurare, CoS de la 0 la 7 vor fi atribuite Cozii 1, pe când traficul de brodcast și multicast va fi atribuit Cozii 2. Aceasta poate duce la degradarea performanțelor în rețea deoarece o mare parte din trafic este unicast și este plasat într-o singură coadă.
Supervisor III și IV
Aceste module folosesc sistemul de operare CISCO IOS. Ele introduc multe capabilități noi pentru seria Catalyst 4000 și 4500. Coada de transmisie include o coadă prioritară și trei cozi standard cu o singură limită de aruncare (1p3q1t). Implicit traficul de voce marcat cu CoS 5 sau DSCP 46 este mapat la coada de prioritate strictă care este în coada 3.
Admiterea traficului în coadă se face pe baza valorilor interne IP DSCP. Modulele Supervisor III și IV suportă maparea globală a acestor valori DSCP – pe baza valorilor QoS din pachete care intră, de asemenea configurarea porturilor de încredere și aplicarea de politici pe cozile de ieșire. Tabelul 4.2.2-2 afișează valorile atribuite implicit pentru un Catalyst 4500/4000 cu supervisor III sau IV.
Tabelul 4.2.2-2 Admiterea în coadă pentru Catalyst 4500/4000 cu supervisor III/IV
Implicit, toate interfețele pe un switch catalyst 4000/4500 sunt în starea de neîncredere după ce este activa QoS global. Starea de încredere (trust state) este activat pe fiecare port în parte pentru controlul granular QoS asupra traficului pentru Supervisor I și II. Modulele supervisor III și IV vin cu capabilitea de recunoaștere a portului de încredere setat în circuitul integrat al telefonului IP (ASIC), fără recunoașterea traficului calculatorului atașat acelui port.
Din cauza faptului că folosesc sistemul de operare Cisco IOS, switch-ul cu Supervisor III și IV are capabilitatea de calsificare a traficului pe baza listelor de acces (IOS ACL). Acest lucru permite switch-ului să definească fluxul de trafic pe baza altor caracteristici decât CoS, IP DSCP, sau IP Precedence și anume: numărul portului TCP, adresa sursă, adresa destinație. Cu aplicarea listelor de acces (ACL) ca și componente ale QoS este evidențiată partea de securitate a QoS care se poate aplica la nivelul de acces (modelul CISCO).
Modulul Supervisor IV introduce o capabilitate adițională numită limitare dinamică de memorie (DBL). Traficul care apare anormal și excesiv este detecat de DBL și i se limitează memoria tampon pe care acesta o poate folosi. Un trafic anormal îl putem defini ca și un trafic care încearcă să folosească toată lățimea de bandă, să cosume toată memoria tampon, să umple toate cozile și să nu răspundă la tehnicile de prevenire a congestiei cum sunt detectarea aleatoare preventivă (RED). Un flux este definit ca și o adresă IP sursă, destinație, protocolul IP, protocolul de nivel 4 TCP/UDP și VLAN-ul. Dacă utilizarea memoriei tampon depășește valoarea de memorie calculată dinamic, DBL va limita posibilitatea acestui flux de a avea acces la memoria switch-ului până la revenirea la limita cea mai mică de aruncare. DBL este implementat în hardware pe toate porturile pe un Catalyst 4500 cu Supervisor IV.
Această capabilitate are un efect positiv în lupta cu virușii de tip „spam”, care acționează ca și servere de email și care încearcă să umple traficul rețelei pentru a provoca un atac de tip DoS pe partea de rețea.
Modulele Supervisor III și IV oferă un control granular al traficului din perspectiva QoS și sunt preferate în rețelele moderne care trebuie să facă față traficului în timp real. Tabelul 4.2.2-3 arată cababilitățile QoS pentru un Catalyst 4500/4000 cu Supervisor III și IV:
Tabelul 4.2.2-3 Capabilitățile QoS Catalyst 4500/4000 cu supervisor III și IV
4.3. Configurarea unui switch Catalyst utilizând IOS
Această secțiune acoperă configurarea unui switch Catalyst pe un nivel distribuție și acces (modelul CISCO). Să presupunem că avem topologia de rețea din figura de mai jos:
Figura 4.3-1 Topologie rețea cu IP telefonie și trafic video
În acest exemplu, Managerele de telefonie sunt conectate la portul 1 și 2, zece telefoane IP sunt conectate de la portul 11 la 20. Fiecare telefon IP are atașat un calculator și serverul video este conectat la portul 10.
Switch-uriule care pot fi luate ca și exemplu în această topologie sunt 6500, 4500 cu supervisor III sau IV și 3550 cu sistem de operare Cisco IOS. Configurarea QoS care va minimiza întârzierea, jitter-ul și aruncarea de pachete pentru aceste echipamente poate fi efectuată în următorii pași sau sarcini:
Configurarea VLAN-ului de voce pentru switch-ul cu Catalyst IOS
Configurarea QoS pentru switch
Activarea cozii stict prioritare
Maparea pentru coada de ieșire a valorilor CoS
Maparea de la nivel 2 la nivel 3
Configurarea limitelor de încredere
Configuraea frame-urilor speciale (nemarcate)
Configurarea listelor de acces QoS
Conectarea la segmentul de WAN
Configurarea VLAN-ului de voce pentru switch-ul cu Catalyst IOS
Primul pas în configurarea QoS pentru nivelul de acces este separarea traficului de voce de cel de date. Telefoanele IP au capabilitatea să folosească 802.1q pentru a îndeplini această cerință. Telefoanele IP pot marca traficul de voce cu un identificator de VLAN, lăsând celălalt trafic în VLAN-ul nativ sau nemarcat. Switch-ul trebuie să fie configurat să participe în legătura de trunk cu telefonul IP. Să presupunem că pentru VLAN-ul de voce am folosit 110 și VLAN-ul de date este 10, Exemplul 4.3-1 arată configurația necesară pentru switch-urile 6500, 4500, 3550.
Exemplul 4.3-1 Configurația pentru utilizarea VLAN-ului de voce
În acest exemplu se intră pe interfața 0/11, portul pentru primul telefon IP și se specifică portului să participe în legătura de trunk cu telefonul IP folosind VLAN-ul 110 pentru traficul de voce și VLAn-ul 10 pentru traficul de date (nemarcat).
Configurarea QoS pentru switch
QoS trebuie să fie activat global în interiorul switc-ului pentru a putea folosi toate cozile disponibile. Comanda de activare QoS depinde de versiunea de switch. Pentru Catalyst 6500 și 3550 comanda este mls qos, pentru 4500 este folosită comanda qos.
Activarea cozii stict prioritare
Catalyst 6500 are configurată implicit o coadă de proritate strictă și ea este folosită pentru traficul de voce. Pentru switch-urile 4500 și 3550 coada de prioritate fixă trebuie configurată.
Pentru 3550 coada de prioritate este coada 4. Pentru a o activa vom folosi comanda priority-queue out pe interfață ca și în exemplul de mai jos:
Exemplul 4.3-2 Activarea cozii prioritare pe un 3500
Pe un switch 4500 coada prioritară este Coada 3. În continuare prezint modul de configurare a acestei cozi.
Exemplul 4.3-3 Activarea cozii prioritare pe un 4500
Maparea pentru coada de ieșire a valorilor CoS
Telefoanele IP marchează traficul cărăuș de voce cu CoS 5 și traficul de semnalizare cu CoS 3. Switch-ul Catalyst 3550 folosește Coada 4 ca și coadă prioritară; de aici apare nevoia mapării CoS 5 la coada 4 pentru ca traficul de voce să se folosească de avantajele cozii prioritare. Comanda folosită pentru acest lucru este wrr-queue cos-map 4 5.
Switc-urile Catalyst 6500 și 4500 plasează traficul cu valoarea CoS 5 în coada prioritară atunci când QoS și coada priritară au fost activate. Totuși, este nevoie de aplicarea unor comenzi pentru a ne asigura că traficul cu QoS 3 este plasat în coada a doua. Exemplul de mai jos arată configurația necesară plasării traficului de semnalizare voce (CoS 3) în coada 2 cu o singură limită de aruncare.
Exemplul 4.3-4 Maparea valorii CoS 3 și 4 la Coada 2 cu o singura limită de aruncare pe un 6500
Maparea de la Nivel 2 la Nivel 3
Cisco aplică standardul recomandat pentru setarea valorilor DSCP pentru traficul cărăuș de voce și pentru traficul de semnalizare voce. Setările recomandate sunt DSCP = AF31 (26 zecimal) pentru traficul de semnalizare VoIP și DSCP = EF (46 zecimal) pentru traficul cărăuș VoIP. Implicit aceste setări diferă de standard.
Pentru remaparea corectă a acestor valori de la CoS la DSCP trebuie modificată maparea implicită.
În exemplul de mai jos este demonstrată configurație necesară pentru remaparea valorilor Cos la DSCP pe un Catalyst 6500 și 3550.
Exemplul 4.3-5 Maparea CoS-DSCP la 6500 și 3500
În exemplul 4.3-6 este demonstrată configurația necesară pentru remaparea valorilor Cos la DSCP pe un Catalyst 4500.
Exemplul 4.3-6 Maparea CoS-DSCP la 4500
Configurarea limitelor de încredere
Limitele de încredere definesc punctele în rețea unde marcarea pachetelor cu CoS, IP precedence, sau DSCP sunt considerate de încredere sau se iau în considerare ca și valide. Aceste limite sunt definite de obicei la un switch de pe nivelul de acces. Catalyst 6500, 4500 și 3550 stabilesc limtele de încredere pe fiecare port. Implicit, toate porturile se află în starea de neâncredere. Cu alte cuvinte, orice valoare COS sau DSCP primită de switch va fi marcată cu CoS sau DSCP 0. În figura 4.3-1, managerul de telefonie IP este conectat la portul 1. Presupunem ca switch-ul este 6500 sau 3500; pentru configurarea switch-ului ca să accepte valorile DSCP pe portul 1 vom folosi comanda mpls qos trust dscp pe interfața 1. Pentru configurarea portului 10 pe care este serverul video vom folosi mpls qos trust cos, presupuunem că acesta va folosi valorile CoS. Pentru 4500 același lucru se realizează cu comanda qos trust cos.
O altă comandă pe care trebuie s-o utilizăm pentru a extinde limita de încredere până la telefonul IP și pentru a permite acestuia suprascrierea cu 0 a valorilor CoS marcate de calculatorul atașat este switchport priority extended cos. Dacă vrem să avem încredere într-o aplicație de pe calculator va fi nevoie de configurări suplimentare care să elimine degradarea performanțelor rețelei(pe partea de voce).
Exemplul de mai jos demonstrează modul de aplicare a acestei comenzi pe interfața switch-ului:
Exemplul 4.3-7 Configurarea limitei de încredere
Configurarea Frame-urilor nemarcate pentru switch-ul Catalyst IOS
Dacă echipamentul pe care îl avem la dispoziție nu suportă protocolul 802.1q pentru trunk, traficul trebuie prioritizat folosind alte tehnici. Pentru acest lucru un motor de forwardare de Nivel 3 poate oferi avantajul folosirii IP precedence sau DSCP, pentru clasificarea traficului. Întrebarea este ce facem dacă nu avem nici un motor de forwardare de Nivel 3?
Acest lucru se poate face prin specificarea valorii CoS pe portul de intrare. Prin acest mecanism vom marca traficul care intră pe port cu valoarea CoS pe care o dorim. Chiar dacă frame-ul nu are formatul ISL sau 802.1Q portul este capabil sa-i seteze acestuia valoarea CoS dorită de noi. În exemplul nostru vom marca tot traficul care vine de la Managerul de telefonie 1 și 2 cu valoarea CoS 3. Pentru acest lucru vom folosi comanda mls qos cos 3 pentru un 6500 și 3550, de asemenea pentru 4500 se va folosi comanda qos cos 3.
Din cauza faptului că am atribuit CoS pe port în acest exemplu nu contează ce echipament atașăm acestui port. Cu alte cuvinte, orice echipament conectat la interfața 1 sau 2 va avea traficul configurat cu aceste valori. Mai mult, tot traficul va fi configurat cu aceste valori. Fie că este vorba despre traficul web sau traficul de control al vocii pentru VoIP. Din aceste motive este indicată utilizarea IP DSCP pentru o diferențiere mai clară între traficul care are nevoie de prioritizare QoS și care nu are nevoie de acest lucru.
Configurarea listelor de acces QoS
Switch-urile 6500, 4500 și 3550 cu sistemul de operare IOS au capabilitatea de a implementa tehnici de filtrare a traficului avansate folosite de obicei pe routere. Acest lucru le permite să clasifice traficul pe baza examinării informației de Nivel 3 și de Nivel 4, asigurând un control granular al traficului prin QoS.
În exemplul de mai jos sunt definite trei liste de acces de tip extended (pot filtra traficul după sursă și destinație, orice protocol și orice port) pentru a filtra traficul după caracteristicile lui.
Exemplul 4.3-8 Crearea listelor de acces
După crearea listelor de acces și specificarea fluxurilor de trafic, vom folosi comanda class-map pentru identificarea acestor fluxuri de trafic. Exemplul de mai jos demonstrează maparea pe clase a listelor create mai sus:
Exemplul 4.3-9 Crearea claselor pe baza listelor de acces
Următorul pas este să alterăm comportarea implicită a acestui trafic. Acest lucru este posibil utilizând tehnicile de aplicare a politicilor QoS. Următorul exemplu demonstrează aplicarea politicilor QoS pe trafic:
Exemplul 4.3-10 Aplicarea politicilor QoS pe clasele de trafic
În acest exemplu, traficul care va intra în clasa GOLD-DATA va fi marcat cu valoarea DSCP 18, traficul de control pentru voce VOICE-CONTROL va fi marcat cu DSCP 26 și traficul cel mai prioritar de voce VOICE va fi marcat cu DSCP 46. În final este folosită comanda service-policy pentru asocierea politicilor cu traficul de intrare sau de ieșire pe interfeță. În exemplul 4.3-11 vom asocia politicile cu traficul de pe interfața gigabit 0-2.
Exemplul 4.3-11 Asocierea politicilor cu traficul pe o interfață
Conectarea la segmentul de WAN
În figura 4.3-1 (pagina 63), routerul WAN este conectat la portul 5. Avem nevoie să configurăm acest port ca să accepte ca și de încredere traficul care vine de la router. Pentru 3550 sau 6500 vom folosi comanda mls qos trust dscp. Dacă este un 4500 vom folosi comanda qos trust dscp.
Verificarea setărilor QoS pentru rețeaua locală
Câteva comenzi de tip show permit verificarea configurației QoS pe un switch Catalyst. Comanda show mls qos interface queueing permite afișarea strategiei QoS de aplicare a cozilor. În exemplul 4.1-11 coada prioritară a fost setată pe interfața gigabit 0/2. Toate frame-urile cu valoarea CoS 5, 6, 7 vor fi plasate în coada prioritară.
Exemplul 4.3-12 Comanda show mls interface queueing
Comanda show mls qos arată informația QoS specifică unei interfețe pentru 3550. Pentru 4500 comanda echivalentă este show qos interface. O altă comandă utilă este show mls qos map cos pentru 3550/6500 și show qos map cos pentru 4500.
Mai multe detalii pentru verificarea configurației vor fi prezentate în capitolul următor.
Capitolul 5: Implementarea configurațiilor QoS într-o rețea date-voce
5.1. Topologia de rețea
Partea practică a lucrării este prezentată de acest capitol, aici voi descrie și voi arăta modul în care am configurat echipamentele Cisco Catalyst 6500, 4500 și 3500 pentru a răspuunde cerințelor de trafic pentru rețeaua convergente de data și voce. Implementarea soluției de VoIP a dus la necesitatea configurării și testării QoS pentru traficul de timp real cum este vocea.
Mai jos prezint o parte din topologia de rețea pe care a fost aplicat QoS:
Figura 5.1-1 Topologia de rețea pe care am aplicat QoS
În figura de mai sus se observă că topologia conține telefoane IP conectate la stațiile de lucru care duc în două switch-uri Cisco 4500 și unul 3500 care formează nivelul de acces. Apoi traficul converge într-un switch de nivel distribuție Cisco 6500 și într-un router 2600 care reprezintă nivelul rădăcină în modelul Cisco.
Voi prezenta configurațiile și pașii utilizați pentru aplicarea configurațiilor pe aceste echipamente de rețea pentru a le face să răspundă cerințelor traficului în timp real.
În capitolul 4 am prezentat pașii necesari pentru configurarea switch-urilor Catalyst 6500, 4500, 3500. Voi începe prin a prezenta configurația VLAN-urilor pe switch-uri.
5.2. Configurarea echipamentelor
Pentru a răspunde cerințelor mari la care trebuie să facă față rețeaua: voce peste IP, video conferințe, broadcast și multicast am creat următoarea structură compusă din VLAN-uri.
Figura de mai jos arată structura de VLAN-uri:
Figura 5.2-1 Structura VLAN-urilor
După cum se poate observa din figură avem următoarele VLAN-uri:
1 – VLAN implicit pe care se setează adresa de IP pentru administrare
50 – VLAN-ul către ISP
132 – VLAN-ul pentru birouri
134 – VLAN-ul pentru producție
150 – VLAN-ul de voce
Pentru crearea VLAN-urilor am urmărit următorii pași:
1) Am setat modul VTP (VLAN Trunking Protocol) în transparent pentru a configura fiecare echipament în parte, cu comanda:
3500(config)# vtp mode transparent
Alte opțiuni pentru modul VTP sunt: server sau client. În cazul meu am folosit modul transparent pentru a fi sigur că un VLAN pe care nu vreau să-l fac public va rămâne ascuns. Adică dacă foloseam configurația server-client, era necesar să configurez un singur switch, de exemplu 6500 și să-i setez modul VTP server și toate celelalte echipamente în cazul în care le setam modul VTP client învățau automat toate VLAN-urile. În cazul în care nu am nevoie pe 3500 să am VLAN-ul de birouri și de servere acest lucru devine redundant.
2) Am creat VLAN-urile pe fiecare echipament în parte funcție de necesități. Am folosit protocolul 802.1q.
Mai jos prezint configurarea Cisco Catalyst 3500:
!
vlan 134
name Birouri
!
vlan 138
name Producție
!
vlan 150
name Voce
!
Exemplul 5.2-1 Configurarea numelor de VLAN-uri
3) Am atribuit VLAN-urile pe interfețe:
!
interface FastEthernet0/1
switchport access vlan 138 (configurarea portului în VLAN-ul de Producție 138)
switchport mode access
wrr-queue cos-map 1 0 1
wrr-queue cos-map 2 2 3
wrr-queue cos-map 3 4
wrr-queue cos-map 4 5 6 7
priority-queue out
spanning-tree portfast
!
Exemplul 5.2-2 Asignarea VLAN-urilor pe interfețe
Mai sus am prezentat un port din producție care nu este configurat să suporte voce. Pentru exemplificarea configurării VLAN-ului de voce am folosit un port de pe 4500:
interface FastEthernet2/3
switchport access vlan 134
switchport trunk encapsulation dot1q
switchport trunk native vlan 134
switchport mode trunk
switchport voice vlan 150
Exemplul 5.2-3 Configurarea interfețelor pentru VLAN-ul de voce
Ultima comandă va atribui portul cu un VLAN de voce. De asemenea, se observă faptul că interfața este trunk pentru a fi capabilă să transporte voce de la telefon (VLAN 150) și date de la calculatorul atașat acelui telefon (VLAN 134 sau 138).
4) Am creat legăturile de trunk între echipamente pentru a fi capabile să transporte trafic de la VLAN-uri diverite.
Voi prezenta legăturile de trunk dintre 6500 și 3500 de asemenea cele dintre 3500 și 4500:
Legăturile de la 6500 spre 4500 și 3500:
#sh run interf gigabitEthernet1/1
Building configuration…
Current configuration : 199 bytes
!
interface GigabitEthernet1/1
no ip address
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,132,134,138,150
switchport mode trunk
service-policy output p1
end
#sh run interf gigabitEthernet2/1
Building configuration…
Current configuration : 199 bytes
!
interface GigabitEthernet1/1
no ip address
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,132,134,138,150
switchport mode trunk
service-policy output p1
end
Exemplul 5.2-4 Configurarea legăturilor de trunk pe 6500
Legăturile dintre celelalte echipamente diferă doar prin alte caracteristici QoS care țin de funcțiile lor specifice.
5.2.1. Activarea QoS pe echipamente
Pentru activarea globală QoS am folosit comanda mls qos pentru 6500 și 3500, și comanda qos. Pasul următor este activarea unei cozi de strictă prioritate pentru traficul de voce. Pentru 6500 acest lucru este asigurat implicit de IOS. Pentru 3500 am folosit comanda priority-queue out și pentru 4500 am folosit comenzile pe interfață:
tx-queue 3
priority high
Maparea valorilor CoS pe interfețe
Pentru Catalyst 3550 a fost nevoie să mapăm valorile CoS 5 la coada prioritară 4:
!
interface FastEthernet0/14
switchport access vlan 138
switchport mode access
wrr-queue cos-map 1 0 1
wrr-queue cos-map 2 2 3
wrr-queue cos-map 3 4
wrr-queue cos-map 4 5 6 7
priority-queue out
spanning-tree portfast
!
Exemplul 5.2.1-1 Maparea traficului CoS 5 la coada prioritară 4 pe 3550
Maparea traficului de semnalizare voce trebuie realizată implicit pe 6500 și 4500. Exemplul de mai jos prezintă această mapare pe 6500:
!
interface FastEthernet5/2
no ip address
wrr-queue cos-map 1 2 2
wrr-queue cos-map 2 1 3 4
wrr-queue cos-map 2 2 5 6 7
switchport
switchport access vlan 134
switchport trunk encapsulation dot1q
switchport trunk native vlan 134
switchport mode trunk
switchport voice vlan 150
power inline auto max 7000
spanning-tree portfast trunk
end
!
Exemplul 5.2.1-2 Maparea traficului CoS 3 și 4 la coadă de prioritate 2 cu prima limită de aruncare
De asemenea, se poate observa din exemplul 5.2.1-2 maparea traficului cu CoS 5 6 7 la coada prioritară 2 cu limita de aruncare 2.
Pentru Cisco Catalyst 4500 am folosit comanda qos map dscp 3 to tx-queue 3 pentru maparea traficului de semnalizare voce spre o coadă mai prioritară:
!
qos map dscp 3 to tx-queue 3
qos map dscp 24 25 26 27 28 29 30 31 to tx-queue 4
qos map dscp 32 33 34 35 36 37 38 39 to tx-queue 4
qos map cos 3 to dscp 26
qos map cos 5 to dscp 46
qos
!
Exemplul 5.2.1-3 Maparea traficului CoS 3 la coada prioritară pe Catalyst 4500
Maparea de la Nivel 2 la Nivel 3
Pentru mapare am folosit tabelul oferit de situl Cisco:
#sh mls qos maps cos
Cos-dscp map:
cos: 0 1 2 3 4 5 6 7
––––––––––––
dscp: 0 8 16 26 32 46 48 56
Exemplul 5.2.1-4 Maparea traficului CoS la DSCP
Pentru configurarea pe 3550 și 6500 am folosit comanda mls qos map cos-dscp 0 8 16 26 32 46 48 56 și pentru 4500 am folosit comenzile:
qos map cos 3 to dscp 26
qos map cos 5 to dscp 4
Exemplul 5.2.1-5 Configurarea listelor de acces (ACL)
Cisco a creat AutoQoS care crează liste de acces implicite pentru traficul de voce, pe lângă această listă implicită am creat două liste de acces pe fiecare echipament:
1) Definirea listelor:
!
!
ip access-list extended VOICE
remark Potrivire pentru portocolul UDP folosit pentru transport voce
permit udp any any range 16384 32767
ip access-list extended VOICE-CONTROL
remark Potrivire pentru traficul de control VOIP
remark SCCP
permit tcp any any range 2000 2002
remark H323 Fast Start
permit tcp any any eq 1720
remark H323 Slow Start
permit tcp any any range 11000 11999
remark H323 MGCP
permit udp any any eq 2427
!
!
Exemplul 5.2.1-6 Definirea listelor de acces
2) Pe baza listelor au fost create clase:
!
class-map match-all VOICE-CONTROL
description VoIP Control Traffic (SCCP, H225, H254, MGCP)
match access-group name VOICE-CONTROL
class-map match-all c1
class-map match-all VOICE
description VoIP Bearer Traffic
match access-group name VOICE
!
Exemplul 5.2.1-6 Crearea claselor pe baza listelor de acces
3) Am creat politici pentru a suprascrie valorile DSCP pentru fiecare clasă:
!
policy-map CAT-IOS-IN
description Set DSCP Value for Each Class
class VOICE-CONTROL
set dscp af31
class VOICE
set dscp ef
policy-map p1
class c1
class class-default
policy-map autoqos-voip-policy
class class-default
dbl
!
Exemplul 5.2.1-7 Politicile pentru suprascrierea valorilor DSCP
4) Am atribuit politicile pe interfețe. Mai jos prezint atribuirea politicilor pe interfața gigabit 1-2:
!
interface GigabitEthernet1/2
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,132,134,138,150
switchport mode trunk
service-policy input CAT-IOS-IN
service-policy output autoqos-voip-policy
qos trust cos
auto qos voip trust
tx-queue 3
bandwidth percent 33
priority high
shape percent 33
!
Exemplul 5.2.1-8 Aplicarea politicilor pe interfeța GigabitEthernet1/2
5.3. Verificarea configurațiilor
Pentru verificarea configurațiilor am utilizat setul de comenzi show pus la dispoziție de Cisco IOS.
Verificăm dacă QoS este activat global:
a) pentru 4500:
#show qos
QoS is enabled globally
IP header DSCP rewrite is enabled
Exemplul 5.3-1 Verificarea QoS global pentru 4500
b) pentru 6500
#show mls qos
QoS is enabled globally
Microflow policing is enabled globally
Vlan or Portchannel(Multi-Earl) policies supported: Yes
Egress policies supported: No
–– Module [1] ––
QoS global counters:
Total packets: 7162
IP shortcut packets: 0
Packets dropped by policing: 0
IP packets with TOS changed by policing: 631
IP packets with COS changed by policing: 0
Non-IP packets with COS changed by policing: 0
Exemplul 5.3-2 Verificarea QoS global pentru 6500
Verificăm maparea CoS pe echipamente:
Pentru 3550:
GigabitEthernet0/1
Egress expedite queue: ena
wrr bandwidth weights:
qid-weights
1 – 25
2 – 25
3 – 25
4 – 25 when expedite queue is disabled
Dscp-threshold map:
d1 : d2 0 1 2 3 4 5 6 7 8 9
–––––––––––––
0 : 01 01 01 01 01 01 01 01 01 01
1 : 01 01 01 01 01 01 01 01 01 01
2 : 01 01 01 01 01 01 01 01 01 01
3 : 01 01 01 01 01 01 01 01 01 01
4 : 01 01 01 01 01 01 01 01 01 01
5 : 01 01 01 01 01 01 01 01 01 01
6 : 01 01 01 01
Cos-queue map:
cos-qid
0 – 1
1 – 1
2 – 2
3 – 2
4 – 3
5 – 4
6 – 4
7 – 4
Exemplul 5.3-3 Verificarea mapării CoS pe 3500
Observăm că valorile CoS 5, 6 și 7 sunt mapate la coada de strictă prioritate 4 care a fost activată pentru toate interfețele pentru a permite traficul de voce.
Petru orice interfață care are cerințe specifice QoS se poate face verificarea:
a) pentru 3500:
#show mls qos interface FastEthernet 0/2
FastEthernet0/2
trust state: not trusted
trust mode: not trusted
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
trust device: none
Exemplul 5.3-4 Verificarea mapării CoS pe interfață 3500
b) pentru 4500:
#show qos interface fastethernet 3/2
QoS is enabled globally
Port QoS is enabled
Administrative Port Trust State: 'untrusted'
Operational Port Trust State: 'untrusted'
Trust device: none
Default DSCP: 0 Default CoS: 0
Appliance trust: none
Tx-Queue Bandwidth ShapeRate Priority QueueSize
(bps) (bps) (packets)
1 N/A disabled N/A 240
2 N/A disabled N/A 240
3 N/A disabled high 240
4 N/A disabled N/A 240
Exemplul 5.3-5 Verificarea mapării CoS pe interfață 4500
Efectuând pașii de mai sus am reușit implementarea topologiei din figura 5.1-1 într-o rețea reală. Exemplele pe care le-am demonstrat în acest capitol sunt exemple reale extrase din configurațiile echipamentelor.
QoS a făcut posibilă implementarea tehnologiei VoIP și a asigurat integrarea ei cu ușurință peste rețeaua existentă de date.
Concluzii
Planificarea și implementarea unei rețele capabile să se adapteze la cerințele de trafic tot mai mari din partea aplicațiilor și să permită integrarea cu ușurință a telefoniei IP și a conferințelor video este posibilă doar prin aplicarea eficientă a tehnicilor QoS propuse de Cisco. Tehnicile și mecanismele QoS aplicate corect în rețeaua locală vor duce la creșterea fiabilității și scalabilității și nu în ultimul rând la mulțumirea utilizatorului final.
QoS a dus la schimbarea conceptului în care rețeaua IP este doar pentru transportul datelor. Datorită implementării cu succes a QoS în rețelele marilor companii se suportă vocea și conferințele video peste aceeași rețea IP. Minimizarea costurilor de implementare este evidentă când în loc de trei rețele separate folosești una existentă, de exemplu, Ethernet LAN.
După studiul și implementarea QoS într-o rețea reală LAN am avut posibilitatea să descopăr o aplicare a conceptelor existente în lumea reală, în procese economice sau industriale (clasificare, planificare) în rețelistică și anume în LAN. Modul de clasificare de la aeroport sau supermarchet este prezent în rețeaua LAN la clasificarea pachetelor. Marcarea pachetelor, aplicarea de politici, ajustarea, evitarea congestiei toate au fost implementate sau folosite de mult timp în lumea reală. Cisco a reușit să folosească aceste tehnici și să le implementeze în rețelistică și acest lucru a crescut performanța unei rețele bazate pe echipamente Cisco sau altele compatibile cu ele.
Implementarea QoS în LAN implică cunoașterea bună a echipamentelor și sistemului de operare Cisco IOS. Cisco pune la dispoziție o serie de materiale și documentații care oferă posibilitatea implementării QoS în rețeaua locală. Întotdeauna trebuie verificat în timp util impactul configurației asupra utilizatorului final. În cazul aplicațiilor cu trafic în timp real (VoIP sau supravegherea proceselor industriale) este nevoie de testarea tehnicilor QoS pentru o anumită interfață și verificarea rezultatelor; dacă ele sunt cele așteptate se poate merge mai departe și aplica QoS pe toate interfețele echipamentului. Astfel, se vor putea evita cazurile în care se produc anumite erori umane de implementare sau de planificare a implementării.
Pentru integrarea traficului de voce, video și date (chiar și critice) este nevoie de QoS. Astăzi pe lângă funcțiile pe care le-am prezentat, QoS joacă un rol important în combaterea traficului nedorit de tip spam sau a virușilor care generează trafic în rețea. Pe baza QoS, Cisco Systems a dezvoltat un software care se numește Cisco Security Agent și care monitorizează rețeaua pentru a detecta anomalii de trafic și a le combate. Cred că folosirea acestui software va fi următorul pas în implementarea QoS în rețeaua locală. De asemenea, implementarea prioritizării traficului de date critice peste cele normale este în faza de finalizare.
Recomand pentru o rețea fiabilă și scalabilă folosirea tehnologiilor de rețea propuse de Cisco și anume QoS!
Anexa 1
Configurația pilot
S-a realizat o schemă de bază prin care se exemplifică modul de funcționare a algoritmului de asigurare a calității serviciilor. Se dorește asigurarea QoS pentru un trafic de voce care se transmite printr-o rețea de date.
Pentru aceasta vom considera următoarea schemă compusă din:
două rutere Cisco 1750;
două stații telefonice analogice;
un HUB sau un Switch cu ajutorul căruia se vor face capturile pachetelor ce traversează rețeaua;
o stație (PC) pe care va rula analizorul de trafic.
Schema montajului folosit pentru demonstrație este detaliată în Figura B1.
Ruterele Cisco 1750 au următoarea configurare:
un modul cu două porturi de voce FXS;
un port FastEthernet 10/100, un port Consolă, un port AUX;
un modul cu două porturi seriale Sync/Async.
Sistemul de operare instalat pe rutere este unul care să permită QoS și trafic de voce. S-a ales un IOS cu următoarele facilități (nu toate necesare în cazul nostru):
IOS – c1700-bno3r2sv3y56i-mz.121-8.bin –
(IP/IPX/AT/IBM/VOICE/FW/IDS PLUS IPSEC 56).
Legătura dintre rutere se realizează prin Ethernet pentru a permite prin intermediul unui Hub sau Switch, analizarea traficului. Avem nevoie de o limitare a traficului pentru că aplicarea unui algoritm QoS pe o legatură de 100 sau 10 Mb este irelevantă (este greu de realizat o congestie reală pe o asemenea bandă de transmisie). Această limitare ar fi mult mai ușor și mai exact de realizat printr-o conexiune serială, însă această conexiune nu ne permite atașarea unei stații pe care să se facă analiza traficului, pe același circuit fizic.
Se limitează traficul la maximum 32 Kbps și se generează de la un ruter către altul trafic cu pachete ICMP care să asigure umplerea acestei benzi. Cum traficul de voce are nevoie de cel puțin 20 Kbps (cel puțin 10-12 Kbps pe sens) fără un bun QoS nu ar putea avea loc o convorbire normală.
Pentru a se putea face captură, legătura dintre rutere nu este făcută direct, ci prin intermediul unui Hub deoarece acest echipament funcționează la nivelul Fizic din stiva OSI și deci nu face nici o selecție a traficului în funcție de sursă și destinație. Acest Hub va trimite prin portul la care este conectat analizorul de rețea tot traficul ce va fi generat de cele două rutere.
În cazul în care va fi folosit un Switch, acesta va trebui configurat astfel încât să se poată monitoriza printr-un port (la care este conectat analizorul) cele două porturi prin care sunt conectate ruterele. Această configurație este necesară deoarece Switch-ul realizează comutarea în funcție de adresa fizică (MAC Address) a fiecărei stații.
După ce este generat trafic astfel încât să se asigure saturarea benzii de transmisie, se încearcă o convorbire telefonică mai întâi prin conexiunea serială pe care nu este setat Quality of Services și apoi prin conexiunea Ethernet, care are parametrii QoS setați. În primul rând ar trebui să se simtă o diferență în ce privește calitatea transmisiunii, iar pentru a doua situație traficul de voce va fi transmis în detrimentul celui de ICMP.
Pe analizorul de rețea se va observa evoluția traficului transmis de cele două echipamente terminale.
Configurația ruterelor din schema pilot
Ruterul NR1
NR1#
NR1#
NR1#
NR1#sh run
Building configuration…
Current configuration : 1173 bytes
!
version 12.1
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname NR1
!
logging 10.1.1.200
!
!
!
!
!
memory-size iomem 15
ip subnet-zero
no ip domain-lookup
!
ip audit notify log
ip audit po max-events 100
rlogin trusted-localuser-source local
!
!
!
!
!
voice-port 1/0
!
voice-port 1/1
!
voice-port 2/0
!
voice-port 2/1
!
!
dial-peer voice 1 pots
destination-pattern 1
port 1/0
!
dial-peer voice 10 voip
destination-pattern 2
ip precedence 5
session target ipv4:10.1.1.2
!
dial-peer voice 15 pots
destination-pattern 4
port 1/0
!
dial-peer voice 20 voip
destination-pattern 5
session target ipv4:2.2.2.2
!
!
interface Serial0
ip address 2.2.2.1 255.0.0.0
no fair-queue
clockrate 32000
!
interface Serial1
no ip address
shutdown
!
interface FastEthernet0
ip address 10.1.1.1 255.0.0.0
rate-limit input access-group 111 16000 2000 4000 conform-action transmit exceed-action drop
rate-limit output access-group 111 16000 2000 4000 conform-action transmit exceed-action drop
speed auto
!
!
!
!
!
ip classless
no ip http server
!
access-list 111 permit ip any any
!
line con 0
line aux 0
line vty 0 4
login
!
end
NR1#
Ruterul NR2
NR2#
NR2#
NR2#
NR2#
NR2#
NR2#
NR2#
NR2#
NR2#
NR2#sh run
Building configuration…
Current configuration : 1188 bytes
!
version 12.1
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname NR2
!
!
!
!
!
!
memory-size iomem 25
ip subnet-zero
no ip domain-lookup
!
ip audit notify log
ip audit po max-events 100
!
!
!
!
!
voice-port 1/0
!
voice-port 1/1
!
voice-port 2/0
!
voice-port 2/1
!
!
dial-peer voice 1 pots
destination-pattern 2
port 1/0
!
dial-peer voice 10 voip
destination-pattern 1
ip precedence 5
session target ipv4:10.1.1.1
!
dial-peer voice 20 voip
destination-pattern 4
session target ipv4:2.2.2.1
!
dial-peer voice 30 pots
destination-pattern 5
port 1/0
!
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Serial0
ip address 2.2.2.2 255.0.0.0
no fair-queue
!
interface Serial1
no ip address
shutdown
!
interface FastEthernet0
ip address 10.1.1.2 255.0.0.0
rate-limit input access-group 111 16000 2000 4000 conform-action transmit exceed-action drop
rate-limit output access-group 111 16000 2000 4000 conform-action transmit exceed-action drop
speed 10
!
ip classless
no ip http server
!
access-list 111 permit ip any any
!
line con 0
line aux 0
no exec
transport input telnet
line vty 0 4
login
!
end
NR2#
Pentru a se putea face o captură a pachetelor din rețea s-a folosit o legatură de tip ethernet (10Mbps) între cele două rutere. Cum nu este tocmai relevant un studiu pe o astfel de banda de transmisie s-a recurs la o limitare a acestei benzi la valoarea de 32 Kbps, aceeași valoare ca și pentru conexiunea serială unde nu avem QoS.
Limitarea se realizează cu ajutorul comenzilor din configurație:
rate-limit input access-group 111 16000 2000 4000 conform-action transmit exceed-action drop
rate-limit output access-group 111 16000 2000 4000 conform-action transmit exceed-action drop
……
access-list 111 permit ip any any
Astfel se coboară viteza de transmisie la 16 Kbps pe fiecare sens.
Pentru pachetele de voce care traversează conexiunea ethernet se setează câmpul IP Precedence la valoarea 5.
Capturi pachete. Diagrame. Explicații.
Pentru capturarea pachetelor se folosește un program soft ce se instalează pe o mașină (PC) care este în aceeași rețea cu cele două rutere. Acest lucru se realizează prin intermediul unui Hub sau Switch.
Se generează trafic ICMP astfel încât să se satureze banda de transmisie.
Sunt trimise 10000 de pachete cu dimensiune de 2KB la interval de o secundă.
În următoarea figură se poate observa cum este limitată această bandă.
În imaginea următoare este prezentată o captură obținută în condițiile în care prin rețea avem numai trafic ICMP.
Traficul ICMP este colorat în albastru iar cel de voce în rosu.
Avem următoarea distribuție a protocoalelor:
Se poate observa că avem numai trafic de ICMP.
După pornirea traficului de voce distribuția protocoalelor va fi următoarea:
Se observă apariția protocolului H225 care este un protocol de control pentru traficul de voce (este folosit la stabilirea conexiunii) (culoarea verde) iar cu roșu este protocolul H323 folosit pentru transmiterea de voce (nerecunoscut de acest analizor). Traficul ICMP este desenat cu culoarea albastră.
La terminalul ruterului se poate observa cum pachetele ICMP se întorc la sursă când nu avem trafic de voce (prioritar), acest lucru fiind semnalat cu „-!.!.!-“, iar când se activează o conexiune telefonică, pachetele de voce vor trece înaintea celor de ICMP care vor fi pierdute „- ……-”.
Vom avea următoarea diagramă a traficului :
Se observă cum traficul de voce este prioritizat înaintea celui de ICMP. Datorită VAD (Voice Activity Detection) vom avea o folosire a benzii mult mai eficientă. Se observă cum în timpul în care pe rețea nu se mai transmite voce, chiar dacă nu este întreruptă conexiunea, ruterul va transmite traficul cu prioritate mai mică.
Acronime
Bibliografie
Flannagan Michael and Kevin Turek, “Cisco Catalyst QoS: Quality of Service in Campus Networks”, Indianapolis, Cisco Press, 2003.
Odom Wendell, Michael Cavanaugh, “Cisco DQOS Exam Certification Guide”, Indianapolis, Cisco Press, 2003.
Schmied Gernot, ”Integrated Cisco and UNIX® Network Architectures”, Cisco Press, 2004.
Szgeti Tim, Christina Hattingh, “End-to-End QoS Network Design”, Cisco Press, 2004.
Vegesna Srinivas, “IP Quality of Service”, Indianapolis, Cisco Press, 2001.
CommWeb Tech Library: http://techlibrary.commweb.com/data/web/cweb/cweb_index.jsp.
Cisco.com QoS page: http://www.cisco.com/go/qos.
AutoQoS VoIP, Catalyst 4500, Catalyst IOS version 12.2(18): http://www.cisco.com/univercd/cc/td/doc/product/lan/cat4000/12_2_18/config/qos.htm#1281380.
AutoQoS VoIP, Catalyst 6500, Catalyst CatOS version 8.2: http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_8_2/confg_gd/autoqos.htm.
Cisco IOS QoS Configuration Guide, Cisco IOS version 12.3: http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/qos_vcg.htm.
Cisco IOS Configuration GuideConfiguring Data Link Switching Plus, Cisco IOS version 12.3: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fibm_c/bcfpart2/bcfdlsw.htm.
Understanding how routing updates and Layer 2 control packets are queued on an interface with a QoS service policy (PAK_priority): http://www.cisco.com/warp/public/105/rtgupdates.html.
Index
Lista exemplelor
Exemplul 3.1-1. Aplicarea CLI pentru clasificare pe un router Cisco…………………33
Exemplul 3.2.1-1. Utilizarea comenzii set……………………………………………………………..34
Exemplul 3.2.2-1. Politică de limitare a traficului………………………………………34
Exemplul 3.2.2-2. Opțiunile pentru marcarea bazată pe politicile de clasă……………..35
Exemplul 3.5-1. Folosirea WRED și ECN……………………………………………..41
Exemplul 4.3-1. Configurația pentru utilizarea VLAN-ului de voce………………………….64
Exemplul 4.3-2. Activarea cozii prioritare pe un 3500…………………………………64
Exemplul 4.3-3. Activarea cozii prioritare pe un 4500…………..……………………..65
Exemplul 4.3-4. Maparea valorii CoS 3 și 4 la Coada 2 cu o singura limită de aruncare pe un 6500……………………………………………………………………………….65
Exemplul 4.3-5. Maparea CoS-DSCP la 6500 și 3500………………..………………..65
Exemplul 4.3-6. Maparea CoS-DSCP la 4500…………………………………………. 66
Exemplul 4.3-7. Configurarea limitei de încredere………………………………..……66
Exemplul 4.3-8. Crearea listelor de acces……………………………………..……….67
Exemplul 4.3-9. Crearea claselor pe baza listelor de acces……………………….……68
Exemplul 4.3-10. Aplicarea politicilor QoS pe clasele de trafic………………………..68
Exemplul 4.3-11. Asocierea politicilor cu traficul pe o interfață……………..…………68
Exemplul 4.3-12. Comanda show mls interface queueing……………………………..69
Exemplul 5.2-1. Configurarea numelor de VLAN-uri……………………….…………72
Exemplul 5.2-3. Configurarea interfețelor pentru VLAN-ul de voce…………………..73
Exemplul 5.2-4. Configurarea legăturilor de trunk pe 6500……………………………74
Exemplul 5.2.1-1. Maparea traficului CoS 5 la coada prioritară 4 pe 3550………….…74
Exemplul 5.2.1-2. Maparea traficului CoS 3 și 4 la coadă de prioritate 2 cu prima limită de aruncare……………………………………………………………………………….75
Exemplul 5.2.1-3. Maparea traficului CoS 3 la coada prioritară pe Catalyst 4500……..75
Exemplul 5.2.1-4. Maparea traficului CoS la DSCP…………………………………….75
Exemplul 5.2.1-5. Configurarea listelor de acces (ACL)…….…………………………76
Exemplul 5.2.1-6. Definirea listelor de acces…………………………………………..76
Exemplul 5.2.1-7. Politicile pentru suprascrierea valorilor DSCP…………………..….77
Exemplul 5.2.1-8. Aplicarea politicilor pe interfeța GigabitEthernet1/2……….………77
Exemplul 5.3-1. Verificarea QoS global pentru 4500………………………………..…78
Exemplul 5.3-2. Verificarea QoS global pentru 6500…………………………………..78
Exemplul 5.3-3. Verificarea mapării CoS pe 3500……………………………………..79
Exemplul 5.3-4. Verificarea mapării CoS pe interfață 3500……………………………79
Exemplul 5.3-5. Verificarea mapării CoS pe interfață 4500……………………………80
Lista figurilor
Fig. 1.1-1. Evoluția QoS………………………………………………………………………………………..3
Fig. 1.1-2. Poziția IntServ și DiffServ pentru asigurarea eficienței QoS………………………4
Fig. 1.2-1. QoS în rețelele industriale……………………………………………………………………..5
Fig. 1.3-1. Cererile traficului de date, voce și video………………………………………………….6
Fig. 1.6-1. Mecanismele QoS……………………………………………………………………………….12
Fig. 2.2.1-1. Transmiterea pachetelor cu și fără comprimare……………………………19
Fig. 2.2.1-2. Transmiterea pachetelor cu și fără comprimare (continuare)…………….19
Fig. 2.2.1-3. Rezervarea lățimii de bandă folosind cozi de așteptare…………………..20
Fig. 2.2.2-1. Topologia de rețea WAN pe care se vor calcula timpii de întârziere…………………………………………………………………………………21
Fig. 2.3.1-1. Topologia de rețea WAN pe care se va prezenta VoIP…………………..25
Fig. 2.3.1-2. Structura pachetului IP folosind RTP……………………………………..26
Fig. 2.3.2-1. Diferențele caracteristicilor de trafic între versiunile aceleiași aplicații….28
Fig. 3.2.3-1. Maparea de la Codurile PHB la valorile binare DSCP…………………….36
Fig. 3.3-1. Comparație între Aplicarea de Politici și Ajustare…………………………..37
Fig. 3.4-1. Plasarea în cozi și planificarea………………………………………..…….38
Fig. 4.1.2-1. Prezentarea unei legături de trunk………………………………………………………43
Fig. 4.1.2-2. Formatul pachetelor folosite pe legătura de trunk…………………………44
Fig. 4.1.2-3. Configurația unui router necesară pentru maparea între Nivelul 3 și 2 OSI………………………………………………………………………………………45
Fig. 4.1.4-1. Limitele de aruncare a pachetelor într-o coadă de Nivel 2……………..….48
Fig. 4.1.5-1. Limitele de încredere și marcarea pachetelor………….………………….49
Fig. 4.2.1-1. Rezultatul comenzii show module………………………………………………………51
Fig. 4.2.1-2. Fluxul traficului la Cisco Catalyst 6500……………………………………54
Fig. 4.2.1-3. QoS aplicat pe un port Ethernet de intrare…………………………………55
Fig. 4.2.1-4. Ruta unui pachet sau frame prin PFC……………………………………..57
Fig. 4.2.1-5. Tratamentul frame-ului pe un port Ethernet de ieșire……………………..59
Fig. 4.3-1. Topologie rețea cu IP telefonie și trafic video…………………………………………63
Fig. 5.1-1. Topologia de rețea pe care am aplicat QoS………………………………….70
Fig. 5.2-1. Structura VLAN-urilor………………………………………………..…….71
Lista tabelelor
Tabelul 1.4-1. Nivelele QoS………………………………………………………………8
Tabelul 1.7.2-1. Clasele standardului QoS……………………………………………………………..14
Tabelul 2.1-1. Comportarea unei rețele fără QoS………………………………………17
Tabelul 2.2.2-1. Tipuri de întârzieri…………………………………………………….23
Tabelul 2.2.2-2. Instrumente QoS ce afectează întârzierea……………………………..24
Tabelul 2.3.1-1. Codec-uri și lățimea de bandă pentru transportul de voce……………27
Tabelul 2.3.1-2. Protocoalele utilizate de VoIP…………………………….………….27
Tabelul 2.3.2-1. Clasa și caracteristicile de trafic pentru anumite aplicații…………….31
Tabelul 3.3-1. Caracteristici Aplicarea de Politici și Ajustare…………………………..38
Tabelul 4.1.3-1. Tipuri de cozi existente în LAN……………………………………….47
Tabelul 4.1.4-1. Limitele de aruncare pentru o coadă standard……………….………..47
Tabelul 4.2.1-1. Combinații între supervisor și motorul de forwardare………………………50
Tabelul 4.2.1-2. Mărimea memoriilor tampon și a cozilor…….………………………..52
Tabelul 4.2.2-1. Matricea Supervisor switch pentru seria 4500…………………………………60
Tabelul 4.2.2-2. Admiterea în coadă pentru Catalyst 4500/4000 cu supervisor III/IV….61
Tabelul 4.2.2-3. Capabilitățile QoS Catalyst 4500/4000 cu supervisor III și IV………….62
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Caracteristici Qos Intr O Retea Tcpip (ID: 161204)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.