Calitatea serviciilor: Întrebări privind politicile de serviciu la intrare și la ieșire care prioritizează același trafic. (Ingineria rețelelor, Qos)

MarkF a intrebat.

Această întrebare/laborator a fost creată cu hardware de rețea Cisco. Am pus această întrebare în altă parte, fără răspunsuri.

Sunt nou în domeniul QoS, dar am petrecut ultimele câteva zile cercetând și am învățat o tonă. Cu toate acestea, încă am probleme în realizarea a ceea ce vreau. Încerc să configurez QoS pentru a prioritiza două clase de trafic față de toate celelalte tipuri de trafic (prima clasă va avea mai multă prioritate față de a doua clasă). Pentru a testa această teorie și configurațiile mele, am configurat două routere, un switch și două PC-uri. Iată o imagine a topologiei pe care o folosesc… (folosesc hardware real, packet tracer este doar o demonstrație a topologiei)

Scopul meu este ca toate cele trei PC-uri să facă ping R2 în același timp, iar PC0 să aibă cea mai ușoară/rapidă transmisie. Am configurat un punct de blocaj între R1 și R2 pentru a putea testa și a mă asigura că pachetele PC0 au cel mai mic risc de a fi pierdute. Am configurat legătura R1-R2 la 10mbps, mtu 500 și hold-queue la 10 pachete atât pentru „in” cât și pentru „out”. Apoi am pus R1 să facă ping la R2 cu pachete ICMP mari și R2 să facă ping la R1 tot cu pachete ICMP mari. Ideea este că ping-urile lui R1, ping-urile lui R2 și ping-urile lui PC2 sunt toate trafic de rutină și ar trebui să fie traficul care este abandonat dacă coada este plină. Ping-urile lui PC0 nu ar trebui să fie niciodată/mai rar abandonate.

Iată un exemplu de configurare…

Configurația R1

ip access-list extended class1-out_acl
  permit ip 192.168.1.0 0.0.0.255 any
  deny ip any any
ip access-list extended class2-out_acl
  permit ip 192.168.2.0 0.0.0.255 any
  deny ip any any
ip access-list extended class1-in_acl
  permit ip any 192.168.1.0 0.0.0.255
  deny ip any any
ip access-list extended class2-in_acl
  permit ip any 192.168.2.0 0.0.0.255
  deny ip any any

class-map match-all class1-out
  match access-group name class1-out_acl
class-map match-all class2-out
  match access-group name class2-out_acl
class-map match-all class1-in
  match access-group name class1-in_acl
class-map match-all class2-in
  match access-group name class2-in_acl

policy-map QOS-OUT
  class class1-out
    priority percent 20
    set precedence 5
  class class2-out
    priority percent 20
    set precedence 3
  class class-default
    fair-queue
    random-detect
    set precedence 0

policy-map QOS-IN
  class class1-in
    police 2000000 400000 400000 conform-action transmit exceed-action drop violate-action drop
  class class2-in
    police 2000000 400000 400000 conform-action transmit exceed-action drop violate-action drop
  class class-default
    police 5000000 1000000 1000000 conform-action transmit exceed-action drop violate-action drop

control-plane
  service-policy input QOS-IN

interface GigabitEthernet0/1
  mtu 500
  speed 10
  hold-queue 10 in
  hold-queue 10 out
  service-policy output QOS-OUT

Configurația lui R2 este exact la fel, cu excepția ACL-urilor. ACL-ul pentru class1-out devine ACL-ul pentru class1-in și viceversa. Același lucru este valabil și pentru ACL-urile class2-in și class2-out. Acest lucru se face astfel încât traficul de clasă1 să aibă „prioritate” la dus-întors.

Am setat PC0 și PC3 pentru a efectua ping la R2 cu ping-uri de 5000 de ori de 300 de ori (nu am folosit PC1 în timpul acestui test). Am setat R1 să facă ping la R2 cu ping-uri de 5000 de aproximativ 15000 de ori și același lucru pentru R2 care face ping la R1.

În timpul testului, ambele routere și ambele PC-uri au pierdut pachete (așa cum mă așteptam, dar am fost puțin surprins că PC0 a pierdut pachete). Când testul a fost finalizat, am constatat că PC2 a avut cele mai bune rezultate, pierzând doar 5% la o medie de 9 ms, în timp ce PC0 a pierdut 10% cu o medie de 11 ms.

Am rulat [show policy-map interface] și pachetele mele class1 au fost selectate din flood, dar nu pare să aibă nicio prioritate. Utilizând această comandă, am observat, de asemenea, că TOATE pachetele erau clasificate la precedența IP 0 (rutină). Ceea ce este ciudat, pentru că am setat class1 la 5.

După cum am menționat mai devreme, sunt nou în domeniul QoS, așa că sunt sigur că am făcut o greșeală undeva. De asemenea, ar putea cineva să îmi explice o metodă/politică bună de utilizat la setarea valorilor „poliției”. Am ales aceste numere ușor arbitrar.

După ce am rezolvat orice erori de configurare, întrebarea mea de bază este… există un standard sau o politică pe care să o pot urma pentru a „potrivi” politicile de serviciu de intrare și de ieșire pentru a oferi același nivel de QoS pentru clasele de trafic. Referindu-mă la exemplul meu de mai sus, încerc să folosesc un procent de prioritate de 20% pentru clasa1 pe interfața de ieșire, în timp ce, în același timp, controlez și interfața de intrare la 2mbps (20% din 10mbps) pentru clasa1. Aceasta este încercarea mea de a „a-lining” legătura pentru a utiliza aceeași prioritizare a traficului (atât pentru intrare, cât și pentru ieșire). Mi-aș dori să pot folosi doar un procent atât pentru politicile de servicii de intrare, cât și pentru cele de ieșire, dar cercetările mele mă fac să cred că acest lucru nu este posibil.

Comentarii

  • V-a ajutat vreun răspuns? Dacă da, ar trebui să acceptați răspunsul, astfel încât întrebarea să nu mai apară la nesfârșit, în căutarea unui răspuns. Alternativ, ați putea posta și accepta propriul răspuns. –  > Por Ron Maupin.
1 răspunsuri
Marc ‘netztier’ Luethi

TL;DR:

A. Nu folosiți Ping, folosiți UDP.

B. Faceți clasificare și marcare pe partea de intrare (potrivire ACL, protocoale, orice),

C. Faceți punerea în coadă/planificarea pe partea de ieșire, potrivindu-se doar cu biții QoS din câmpul ToS al antetului IP.

Un pic mai mult de verbalizare:

A) Utilizați UDP, nu Ping

Pentru început: ICMP sau Ping, respectiv Ping, este un instrument deosebit de nepotrivit pentru testarea părții de coadă/planificare a unei configurații QoS din două motive:

  • Ping generează același flux de date în direcția inversă și nu aveți aproape nicio modalitate de a vă da seama dacă o „pierdere de ping” a avut loc la cererea sau la pachetul de răspuns.
  • Atunci când se caută efectele cozii de așteptare, RTT-urile raportate de Ping sunt la fel de greu de interpretat – dacă există o latență crescută din cauza tamponării, nu se poate spune dacă acest lucru s-a întâmplat la cerere sau la răspuns.

ICMP poate face o treabă decentă atunci când se testează partea de clasificare/marcare a unei configurații QoS.

Prin urmare, vă sugerez să alegeți un instrument care generează unidirecțional fluxuri UDP, așa cum face iPerf (și cu siguranță și alții), iar eu execut cazurile de testare pentru fiecare direcție în parte. Este posibil să doriți să adăugați un PC la rețeaua LAN din spatele R2 pentru a servi drept sistem de recepție (cu iPerf pe UDP, rezultatele interesante sunt afișate pe partea receptorului, în timp ce cu TCP, oricare dintre părți va arăta rezultate semnificative).

UDP are, de asemenea, avantajul că puteți lucra cu ușurință cu porturile, ceea ce face ca ACL-urile pentru hărțile de clasă să fie mult mai ușor de scris (de exemplu, portul udp/5000 este implicit, 5005 primește precedența 5, portul 5003 primește precedența 3) etc.

Nu sunt foarte sigur de ceea ce intenționați cu configurația dvs. – în special în ceea ce privește rolul de control al planului de control, care este complet diferit. V-aș sfătui să lăsați asta deoparte; CoPP poate provoca mari pagube dacă este implementat greșit într-o rețea de producție.

Există trei lucruri foarte importante de reținut cu QoS:

  • QoS este un unidirecțional lucru unidirecțional, iar atunci când măsurați QoS, fiți întotdeauna conștienți de direcția traficului „interesant”. Configurații pot fi fi simetrice și chiar să împartă aceleași mape de clasă/mape de politici și ACL-uri. Dar modul în care funcționează QoS pe un router este complet independent pentru fiecare direcție. Din acest motiv, doriți să aveți scenarii de testare cu caracter unidirecțional.

  • QoS Queuing/Scheduling nu se întâmplă cu adevărat decât atunci când interfața (sau shaperul părinte) primește saturată.

  • QoS este un sistem de nedreptate gestionată (nu este citatul meu, dar de dragul de a nu-mi aminti de unde am luat acest lucru). Odată ce o legătură este saturată, TOATE clasele de trafic vor avea de suferit într-o anumită măsură. QoS stabilește doar regulile de nedreptate.

O să vă dau câteva sfaturi care urmează experienței mele cu configurări QoS, preluând fragmente așa cum le-am înțeles din postarea dvs.

De obicei, doriți să efectuați clasificarea/marcarea pe intrare interfață, eventual împreună cu o anumită poliție. Clasificarea/marcarea cu o hartă de politici legată de o ieșire este uneori nici măcar posibilă, sau doar într-un mod limitat.

B) QoS la intrare

Să începem cu intrare partea de intrare. (Vă rog să fiți conștienți de faptul că am compus acest text la mână liberă, nu de la un dispozitiv real. Este posibil să existe mici erori de sintaxă sau de suport al funcțiilor pe platforma respectivă)

  • definiți class-maps cu ACL-urile lor pentru a identifica traficul (1):

    class-map match-any CMAP_QOS_CLASS1,
    match access-group ACL_CLASS1-TRAFFIC
    class-map CMAP_QOS_CLASS2
    match access-group ACL_CLASS2-TRAFFIC

  • definiți o hartă de politică numită PM_QOS_INGRESS, care conține clasele de mai sus.

  • în acea policy-map, setați doar valoarea precedenței sau DSCP, opțional, polițializați traficul de intrare.

    policy-map PMAP_QOS_INGRESS
    class CMAP_QOS_CLASS1
    set precedence 5
    class CMAP_QUE_CLASS2
    set precedence 3
    class class-default
    set precedence 0

  • se leagă acest policy-map de interfața pe care vine traficul care urmează să fie supus QoS-ului de la (2)

Acum, pachetele care intră în acel router primesc marcajul dorit în byte ToS.

C) QoS la ieșire

Acum, pentru ieșire partea de ieșire.

  • definiți un set de hărți de clasă care au criterii de potrivire pentru marcajele din octetul ToS (DSCP sau precedență). Nu se potrivesc aici adresa IP (cu o ACL), protocolul sau portul.

    class-map match-any CMAP_QUE_CLASS1
    match precedence 5
    class-map match-any CMAP_QUE_CLASS2
    match precedence 3

  • definiți o hartă de politici care decide ce trebuie să se întâmple cu fiecare clasă (3):

    policy-map PMAP_QUE_EGRESS
    class CMAP_QUE_CLASS1
    priority level 1
    police <some upper limit you want to give to that class>
    class CMAP_QUE_CLASS2
    priority level 2
    policy <some upper limit you want to give to that class>
    class class-default
    random-detect precedence-based

  • legați această hartă de politici de interfața pe care traficul care urmează să fie clasificat QOS părăsește R1.

Apoi, porniți un anumit trafic (care nu saturează încă legătura sau limitele superioare ale poliției) de la toate cele trei PC-uri. Utilizați show policy map interface gig0/1 out pe R1 pentru a vedea dacă obțineți contoare cu valori diferite de zero pentru diferitele clase.

Apoi, începeți să creșteți lățimea de bandă a fluxurilor udp până când acestea încep să satureze punctul de înecare. Uitați-vă din nou la harta politicii de ieșire (de data aceasta, căutați contoarele de cădere pe clasă) și uitați-vă la statisticile receptorului de flux pentru pierderi și jitter. Asigurați-vă că comparați jitterul pentru clasele prioritare cu jitterul clasei implicite.

ATENȚIESe pare că aveți un Catalyst 2960 între PC-uri și R1. Chiar dacă este irelevant în scenariul actual (clasificarea/marcarea se întâmplă pe R1), vă recomand cu tărie să …

  • (fie) să vă asigurați absolut sigur că catalizatorul are mls qos dezactivat
  • (sau, dacă mls qos este activat) să vă asigurați că toate porturile switch-ului care acceptă trafic cu stegulețe QoS (adică valori de precendență sau DSCP în octetul ToS) sunt setate pe mls qos trust

În caz contrar, catalizatorul va anula byte-ul ToS al tuturor pachetelor IP (da, chiar dacă acționează doar ca un comutator de nivel 2) și s-ar putea să vă confruntați cu efecte neașteptate.

(1) Pe platformele Cisco Nexus, hărțile de clasă și hărțile de politici utilizate pentru clasificare și marcare (de intrare) sunt de type qos, , cele pentru (egress) punerea în coadă și programarea sunt de type queuing. Mi s-a întâmplat să îmi placă acest lucru, deoarece oferă claritate și, prin urmare, am ales să reflectez în denumirea sa utilizarea preconizată a hărților de clasă/politică, chiar și pe IOS. Strategia dvs. de denumire a hărților de clasă/politică poate fi diferită, desigur.

(2) într-o rețea de campus, clasificarea și marcarea s-ar face pe portul switch-ului de acces la care sunt conectate PC-urile. De dragul exercițiului, ați putea dori să faceți acest lucru pe interfața routerului către PC-urile (sursă).

(3) Voi renunța la exemplul unui Policy-Map ierarhic cu un părinte și copil policy map. Dacă este necesar, voi edita răspunsul.

Comentarii

  • Pe police comandă, există, de asemenea, opțiuni pentru ceea ce trebuie făcut în cazul încălcărilor. ceva de genul: police cir percent <upper percentage> conform-action transmit exceed-action drop. –  > Por Ron Maupin.

Tags: