www.SAMURAJ-cz.com 

23.04.2024 Vojtěch Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

Cisco QoS 2 - Classification and Marking, Modular QoS CLI

Pondělí, 26.01.2009 17:21 | Samuraj - Petr Bouška |
Tato část článků o Quality of Service se zaměřením na Cisco se věnuje první činnosti, kterou při aplikaci QoSu musíme provést. Jedná se o prozkoumání provozu a jeho rozdělení do tříd - classification a následně označení jednotlivých paketů touto třídou - marking.

Pozn.: Konfigurační příkazy a možností se liší podle verze IOSu (zde uvažuji novější verze) a podle zařízení (router, switch, kategorie).

Trust Boundary - hranice důvěry, odděluje v síti část, kdy ještě věříme předávaným značkám (třídám) a kdy ne, typicky edge switch, nedůvěřujeme tomu, co nám pošle klient, ale sami si provoz roztřídíme, může být výjimka třeba IP telefon.

Detailní analýza provozu (paketu) by se měla provádět při vstupu do sítě, co nejvíce na okraji, tam kde stanovíme Trust Boundary. Podle analýzy zařadíme provoz do tříd. Další aktivní prvky pak využijí toto zařazení do tříd pro směrování provozu. DiffServ pracuje způsobem, který se označuje jako Per-hop behavior, zpracovává se na každém aktivním prvku. Abychom dosáhli uceleného QoS řešení, tak musí mít všechny aktivní prvky na cestě stejné Per-hop behavior.

Classification - klasifikace

Pakety můžeme rozlišovat podle řady parametrů, některé z nich jsou:

  • ACL (access control list) pomocí access group - to zahrnuje definici podle řady parametrů, primárně IP adresa či MAC adresa
  • vstupní interface - kudy paket přišel
  • IP parametr - DSCP nebo Precedence
  • protokol - některé základní protokoly nebo celá řada při použití NBARu (ten je pouze na lepších routerech nebo největších switchích)
  • vše - veškerý provoz
  • class-map - podle zanořené class mapy
  • důvěra Cos, DSCP nebo IP precedence - akceptujeme přijaté hodnoty

Marking  - značkování

Potom, co paket zařadíme do nějaké třídy, tak mu potřebujeme tento údaj přiřadit. K tomu se používá marking a je zde řada možností, podle použitého protokolu/technologie. Zde zmiňuji pouze běžnější TCP/IP a Ethernet (a vynechávám další možnosti jako ATM, Frame Relay, MPLS).

Class of Serivce (COS) pole v 2. vrstvě OSI

COS je prioritní bit podle IEEE 802.1p uvnitř ethernetového rámce IEEE 802.1q (rozšířená hlavička rámce o 4 byte), velikost 3 bity, nabývá hodnot 0 až 7.

802.1q rámec

6B 6B 4B 2B 64 až 1500B 4B
cílová adresa (DA) zdrojová adresa (SA) 802.1q tag typ nebo délka data kontrolní součet (FCS)

Tvar 802.1q tagu

2B 3b 1b 12b
0x8100 priorita (802.1p) Canonical Format Indicator (CFI) VLAN ID
Tag Protocol ID (TPID) 2B Tag Control Information (TCI) 2B

Type of Service (TOS) pole v 3. vrstvě OSI

TOS pole je uvnitř IP hlavičky a je 8 bitů dlouhé, uvnitř se nachází hodnota Differentiated Services Code Point (DSCP) 6 bitů a tedy hodnoty 0 až 63, uvnitř je IP Precedence (IPP) o velikosti 3 bity (hodnoty 0 až 7). Původně se používala IP Precedence, pro DiffServ byla rozšířena na DSCP, které je zpětně kompatibilní s IP Precedence.

IP hlavička

4b 4b 1B 2B 2B 3b 13b 1B 1B 2B 4B 4B  
version header length ToS length ID flags offset TTL protocol FSC IP-SA IP-DA data

Pole TOS

0 1 2 3 4 5 6 7  
Precedence nepoužito standard IPv4
DiffServ Code Point (DSCP) Flow Control
(Explicit Congestion Notification)
DiffServ extensions

Hodnoty CoS, IP Precedence, DSCP

COS IPP DSCP PHB typická aplikace
7 7     rezervováno
6 6 48 CS6 routing
5 5 46 EF hlas
5 5 34 AF41 video konference
4 4 32 CS4 streamované video
3 3 26 AF31 Mission critical data
3 3 24 CS3 Call Signaling
2 2 18 AF21 transactional data
2 2 16 CS2 network management
1 1 10 AF11 Bulk data
1 1 8 CS1 scavenger
0 0 0 0 Best Effort Data

Per-Hop Behaviors - PHB

PHB je termín používaný v DiffServ, který definuje politiky a priority aplikované na paket při průchodu routerem (hopem). Standardní PHB jsou:

  • Expedited Forwarding - EF - rychlý (upřednostněný) přenos, ideální pro malé datové pásmo, ale nízké zpoždění
  • Assured Forwarding - AF - zajištěný přenos, má vyhrazené pásmo, často se rozděluje na gold, silver a bronze
  • Class Selector - CS - kompatibilní s IP Precedence
  • Best Effort -BE - výchozí, nejhorší

PHB je definováno v několika RFC, ale ve skutečnosti se jedná pouze o jakési doporučení. Vše záleží na tom, jak si to na aktivních prvcích nakonfigurujeme. Uvedené třídy automaticky neexistují, takže pokud provoz omarkujeme na nějakou doporučenou hodnotu, tak se ještě nic nestane, musíme nastavit chování dané třídy.

Následující tabulka ukazuje doporučené hodnoty IP Precedence (IPP) a k nim odpovídající PHB třídy spolu s hodnotou DSCP. Velikost DSCP je 6 bitů, první 3 bity odpovídají IP Precedence. Čím větší číslo IP Precedence, tím větší priorita. Pro PHB AF se doplňuje toto číslo do názvu (a také tvoří CS). Další dva bity určují pravděpodobnost zahození, čím větší číslo, tím spíše se zahodí (AFx1 - low drop preference, AFx2 med drop preference, AFx3 high drop preference), a také se doplňují do názvu PHB EF. Poslední bit je 0.

IPP Per Hop Behavior / DSCP
0   BE
000000
   
1 CS1
001000 (8)
AF11
001010 (10)
AF12
001100 (12)
AF13
001110 (14)
2 CS2
010000 (16)
AF21
010010 (18)
AF22
010100 (20)
AF23
010110 (22)
3 CS3
011000 (24)
AF31
011010 (26)
AF32
011100 (28)
AF33
011110 (30)
4 CS4
100000 (32)
AF41
100010 (34)
AF42
100100 (36)
AF43
100110 (38)
5   EF
101110 (46)
   

Konfigurace v Cisco IOSu - MQC

V dnešní době se pro konfiguraci QoSu pod Cisco IOSem (jedno zda na routeru nebo switchi, i když se liší detailní možnosti) používá Modular Quality of Service Command Line Interface (Modular QoS CLI nebo pouze MQC). Vždy se pracuje s třídami (do kterých řadíme provoz), takže se mluví o Class-based QoS.

Pomocí MQC se provádí více činností než pouze classification a marking a pro vše se používají stejné příkazy, takže zde naznačím i další možnosti, které budou podrobněji popsány příště. Následující mechanismy můžeme použít v MQC:

  • marking - označování paketů, aplikovatelné na vstup/výstup, příkaz set
  • shaping - omezování provozu se zpožďováním (rozložením), aplikovatelné na výstup, příkaz shape
  • policing - omezování provozu pomocí zahazování paketů, aplikovatelné na vstup/výstup, příkaz police
  • weighted fair queuing (CBWFQ) - fronty pro vyhrazení (garantování) pásma, aplikovatelné na výstup, příkaz bandwidth
  • low-latency queuing (CBLLQ) - fronty pro vyhrazení (garantování) pásma a zajištění nízké čekací doby (latency), aplikovatelné na výstup, příkaz priority
  • weighted random early detection (WRED) - fronty pro vyhrazení (garantování) pásma s inteligentním zahazováním paketů, příkaz random-detect

Konfigurace v MQC se skládá ze tří kroků:

  • Traffic class definition - určím, s jakým provozem chci pracovat, vytvořím class-map
  • Policy definition - určím, co chci s vybraným provozem dělat, vytvořím policy-map a zařadím do ní jednu či více class-map
  • Policy application - aplikuji politiku na interface, tehdy začne fungovat, pomocí service-policy

Traffic class definition

Vytvoříme pojmenovanou třídu, do které (nebo pomocí které) budeme vybírat provoz. Uvnitř třídy vybíráme provoz pomocí příkazu match, ten může být použit jednou nebo vícekrát. V definici třídy můžeme určit, zda se na více match příkazů má použít logické AND nebo logické OR, pomocí match-all nebo match-any parametru.

ROUTER(config)#class-map test-class            // definice class-mapy se jménem test-class, defaultně se použije match-all
ROUTER(config)#class-map match-all test-class  // stejné jako výše
ROUTER(config)#class-map match-any test-class  // alespoň jeden match musí platit 

Vybírat provoz můžeme podle řady parametrů (viz. výše), záleží na typu zařízení, co vše podporuje.

ROUTER(config-cmap)#match any                    // vyber vše, nefunguje na všechny aplikace 
ROUTER(config-cmap)#match access-group 10        // to co vyhodnotí ACL číslo 10 
ROUTER(config-cmap)#match ip precedence critical // co má nastaveno IP Precedence = 5
ROUTER(config-cmap)#match vlan 100 - 105         // VLAN 100 až 105
ROUTER(config-cmap)#match destination-address mac 00-16-EA-E4-D0-96 // cílová MAC adresa
ROUTER(config-cmap)#match input-interface fa1    // co přišlo přes interface fa1
ROUTER(config-cmap)#match protocol ip            // podle protokolu 

Zajímavá možnost je využití příkazu match not, kdy se vybírá podle všech ostatních hodnot zadaného kritéria mimo uvedené hodnoty.

ROUTER(config-cmap)#match not protocol ip  // všechny protokoly mimo IP 

Class-mapy můžeme také zanořovat do sebe pro složitější výběry

ROUTER(config)#class-map match-any test-class 
ROUTER(config-cmap)#match class-map test-class-1 
ROUTER(config-cmap)#match class-map test-class-2

Klasifikace pomocí ACL

Často se pro nalezení zajímavého provozu využívá ACL (Access Control List). Můžeme využít standardní IP ACL, extended IP ACL nebo L2 MAC ACL. Více o tvorbě ACL v článku Cisco IOS 8 - Access Control List.

Je třeba vědět, jak se ACL vyhodnocují, pokud jsou přiřazena do class-map. Využívá se následujících pravidel:

  • pokud se nalezne shoda s permit akcí, tak se použije přiřazená QoS akce
  • pokud se nalezne shoda s deny akcí, tak se ACL přeskočí a pokračuje se dalším
  • pokud se nenalezne žádné permit pravidlo, nezpracovává se QoS a použije se Best-Effort
  • pokud je definováno více ACL, tak se hledání zastaví po první permit shodě

Policy definition

V prvním kroku jsme vybrali, jaký provoz nás zajímá, a nyní musíme určit, co s ním budeme provádět. Možností je celá řada a v tomto kroku vlastně uplatníme všechny možnosti QoSu. Můžeme označit provoz, provést marking, (nastavit IP precedence, DSCP, apod.) nebo pracovat přímo s provozem, omezit či vyhradit pásmo pro provoz, řešit fronty, apod.

Vytvoříme pojmenovanou politiku s názvem test-policy.

ROUTER(config)#policy-map test-policy 

Dále určíme, které class-mapy se bude týkat naše nastavení. Do jedné policy-map můžeme zařadit více class-map a nastavit jim různé chování. To je třeba proto, že na interface a směr můžeme aplikovat pouze jednu policy-map.

ROUTER(config-pmap)#class test-class  

V rámci class-mapy již určujeme danou politiku, může se jednat i o více nastavení.

ROUTER(config-pmap-c)#set cos 3         // označíme provoz jako COS 3
ROUTER(config-pmap-c)#set precedence 3  // označíme provoz jako IPP 3
ROUTER(config-pmap-c)#set dscp 24       // označíme provoz jako DSCP 24
ROUTER(config-pmap-c)#police 128000 8000 exceed-action drop // omezení provozu
ROUTER(config-pmap-c)#police aggregate test-policer // omezení provozu pomocí předem vytvořené politiky
ROUTER(config-pmap-c)#shape average 512000 // shaping provozu
ROUTER(config-pmap-c)#priority 16000    // prioritizace a vymezení pásma v kbps
ROUTER(config-pmap-c)#bandwidth 1024    // vymezení pásma v kbps
ROUTER(config-pmap-c)#log               // logování

Všechen ostatní provoz, který jsme nezařadili do nějaké třídy, se automaticky zařadí do defaultní třídy, na kterou se neuplatňuje QoS - použije se Best-effort. Tato třída se jmenuje class-default a její chovní můžeme změnit.

ROUTER(config)#policy-map test-policy 
ROUTER(config-pmap)#class class-default    
ROUTER(config-pmap-c)#queue-limit 10    // velikost fronty 10 paketů

Policy application

To, že jsme vytvořili policy-map ještě nezpůsobí, že se začne provádět. Nejprve je třeba ji namapovat na interface, v rámci kterého se začne provádět. A navíc určit, zda se týká příchozích nebo odchozích paketů (obdobně jako u ACL).

ROUTER(config)#interface gigabitEthernet1/0/1       // vybereme interface
ROUTER(config-if)#service-policy input test-policy  // aplikujeme policy map se jménem test-policy na příchozí pakety

Můžeme také vytvářet hierarchické politiky tak, že nějakou politiku aplikujeme uvnitř jiné politiky pod třídou.

ROUTER(config)#policy-map test-policy 
ROUTER(config-pmap)#class test-class  
ROUTER(config-pmap-c)#police 512000 
ROUTER(config-pmap-c)#service-policy test-inner-policy  // v rámci politiky aplikujeme politiku

Show příkazy - kontrola

Pro kontrolu našeho nastavení můžeme použít následující show příkazy:

ROUTER#show running-config    // zadané příkazy nalezneme v běžící konfiguraci
ROUTER#show class-map         // zobrazí všechny definované class-map
ROUTER#show class-map class1  // zobrazí class-map class1
ROUTER#show policy-map        // zobrazí všechny definované policy-map (nezobrazuje jednotlivé příkazy)
ROUTER#show policy-map policy1 class class1 // zobrazí konfiguraci určené třídy v dané policy-map
ROUTER#show policy-map interface s0/0  // zobrazí statistiky, jak se uplatňuje politika na interface
zobrazeno: 28235krát | Komentáře [6]

Autor:

Související články:

Cisco IOS

Velký seriál o operačním systému aktivních prvků firmy Cisco.

QoS - Quality of Service

Tato série článků se věnuje obsáhlé problematice zajištění kvality při přenosu dat, tedy Quality of Service. Vše je řešeno s přihlédnutí k aktuálním trendům používaným na Cisco aktivních prvcích, spolu s příklady konfigurace.

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže.

Komentáře

  1. [1] joe07

    Chcel by som sa spytat na analyzu trafficu. Tu: http://www.opalsoft.net/qos/ sa pise, ze prave analyzou zistime nase potreby. Niekto s tym pravdepodobne mate skusenosti ako (velmi by som ocenil presnejsi navod) sa analyzuje traffic na sieti?

    Na tej stranke sa pise, ze stacia free aplikacie a jeden linuxovy stroj konkretne: tcpdump, awk, gnuplot, and of course, an unexpensive Linux box.

    Viete niekto poradit konkretny postup? Dakujem

    Pátek, 12.06.2009 00:36 | odpovědět
  2. [2] tomfi

    odpověď na [1]joe07:

    Hodně záleží na tom co přesně myslíte...když se omezím na linux tak pro operativní analýzu (kdo co právě dělá) jsou dobré:

    tcpdump

    iptraf

    iftop

    iptables

    wireshark

    Pro sledování trendů a přehled co kdo dělá:

    mrtg

    ntop

    a speciální "home-made" skripty, které umí shromáždit a analyzovat "na co máte políčeno"... ale to je právě už případ těch awků, gnuplotů, rrdtoolů a podobných věcí :)

    Nejsem si jistý co si představujete pod návodem na analýzu trafficu... analýza má vždy nějaký důvody... takže většinou hledáte něco konkrétního... případně sledujete pro odhalení abnormalit... ale takový nakousnutí:

    když po spuštění iptraf uvidíte že broadcast v síti vám tvoří 50% trafficu, tak možná něco v pořádku, když uvidíte jeden broadcast rámec pomocí tcpdump 2x, tak máte v síti pravděpodobně taky nějaký problémek... to je traffic analysis zaměřený na nízkou úroveň.. dále můžete pomocí analýzy sledovat dobu odezvy aplikací, chybové stavy v síti, trendy v síťovém provozu, hledat příznaky útoku apod.

    Sobota, 13.06.2009 22:55 | odpovědět
  3. [3] joe07

    Dakujem skusim s tym trochu poexprerimentovat.

    Myslel som spociatku zakladnu analyzu: Pocet broadcastov(mozno aj multicastov), TCP vs. UDP a napokon zistenie ake protokoly sa skryvaju v UDP.

    Na tie dalsie udaje ako odozva, chybove stavy som zatial nepomyslel

    Neděle, 14.06.2009 12:13 | odpovědět
  4. [4] Zaram

    Mám dotaz ohledně té default class (u CBWFQ) - tím ,že jsou všechny zbývající packety obsluhovány best-effort tím se míní že jsou zařazeny do jedné jediné FIFO? Nebo se pro každý flow vytvoří vlastní queue? To už ale nebude best-effort...

    Viz. "Inside Cisco IOS Software Architecture" str. 145):

    "A default class also can be configured; if no default class is configured, packets that are not otherwise classified into a user-defined class are sorted by flow and are given best-effort treatment."

    Překládám si to tak, že všechen traffic spadající do default class se chová jako legacy WFQ. Co si o tom myslíte?

    Jinak pěkný seriál

    Středa, 23.09.2009 01:37 | odpovědět
  5. [5] Samuraj

    odpověď na [4]Zaram: Já myslím, že vše co se neurčí jinak, padá do class-default a ta má jednu frontu (u té můžeme konfigurovat chování). Něco ukazuje tento obrázek www.cisco.com/en/US/i/000001-100000/60001-65000/60001-61000/60595.jpg.

    Pátek, 25.09.2009 08:54 | odpovědět
  6. [6] Zaram

    to Samuraj: Nejspíše je to tak, jak jsem psal na konci. V tomto dokumentu to sice není explicitně napsáno, ale dá se to z toho odvodit:

    http://www.cisco.com/en/US/tech/tk543/tk544/technologies_tech_note09186a0080094612.shtml#undqu

    Dle mého to funguje následovně:

    Queues 1- 256 - Defalt class - obsluhovaná jako WFQ (stejný schedul. alg.) - tedy se počítá hash z IP packetů - dělí se do samostatných flows, těm se následně přiděluje samostatná Queue a ta je posléze obsluhována dle vypočteného sequence number. Odeslaný packet ale nejde na (např. do Tx ringu) interface, ale ocitá se vlastně v další frontě která se obsluhována dalším schedulerem - ten obsluhuje priority queue(pro cdp protokol, a další control trafic, nebo pokud se v police map nadefinována "priority" tak všechen traffic v definované třídě/class), námi vytvořené reserved queue.

    To jsou queues vyšší než 256.

    Zkoušel jsem aplikovat police map s použitím CBWFQ:

    Service-policy output: PK

    Class-map: PK (match-all)

    41 packets, 14022 bytes

    5 minute offered rate 0 bps, drop rate 0 bps

    Match: protocol rtp audio

    Queueing

    Strict Priority

    Output Queue: Conversation 264

    Bandwidth 5 (%)

    Bandwidth 77 (kbps) Burst 1925 (Bytes)

    (pkts matched/bytes matched) 0/0

    (total drops/bytes drops) 0/0

    Class-map: class-default (match-any)

    347 packets, 9924 bytes

    5 minute offered rate 0 bps, drop rate 0 bps

    Match: any

    A ve výpisu z interface jde vidět, že těch 256 front z class default zůstává:

    Queueing strategy: Class-based queueing

    Output queue: 0/1000/64/0 (size/max total/threshold/drops)

    Conversations 0/2/256 (active/max active/max total)

    Reserved Conversations 0/0 (allocated/max allocated)

    Available Bandwidth 1081 kilobits/sec

    Neděle, 27.09.2009 23:03 | odpovědět
Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách