Ověření mechanismů zajištění kvality služby (diffserv) na Cisco Catalyst 3560 a průzkum rozdílů od modelu Cisco Catalyst 3550

semestrální projekt do předmětu Směrované a přepínané sítě

autoři: Lukáš Maleček (mal338) a Jan Děrgel (der014)

16. června 2007



Obsah

I. Zadání projektu
II. Návaznost na původní projekt
III. Ukázkový příklad
3.1. Základní konfigurace
3.2. Změna šířky pásma pro výstupní fronty
3.3. Zapnutí prioritní expediční fronty
3.4. Přemapování CoS pomocí CoS-DSCP mapy
3.5. Přemapování CoS na výstupní frontu pomocí CoS-egress_queue mapy
IV. Závěr
V. Literatura

I. Zadání projektu

Prakticky prozkoumejte rozdíly v zajištění kvality služby (Qos) mezi Cisco 3560 a 3550.

Zpět na obsah

II. Návaznost na původní projekt

Tento projekt navazuje na studentský projekt Podpora QoS na Cisco 3550 a 2950T, který vypracovali Petr Jaššo a Tomáš Chalupka v roce 2005. V uvedeném projektu je i podrobně rozebrána problematika Qos a zajištění služby. Také je zde řešeno, jak vůbec dochází k identifikaci a rozlišení paketů jak na 2., tak poté na 3. síťové vrstvě. Doporučejeme tedy těm, kteří ještě nemají s touto problematikou žádné zkušenosti, prostudovat nejprve tento starší projekt. Ten lze najít zde (poznámka: otevírá se v novém okně).

Cisco 3560 používá ke klasifikaci a identifikace paketů hodnotu CoS, která je v hlavičce 2. síťové vrstvy, nebo hodnotu DSCP, která se nachází v hlavičce 3. vrstvy. Provoz rozděluje do 4 výstupních front a při základním použití QoS (kdy není změněno standardní nastavení) se řadí pakety do jednotlivých výstupních front podle těchto pravidel:

číslo fronty Hodnoty CoS Hodnoty DSCP Poznámka
1 5 40-47 Tato fronta může být určena jako prioritní
2 0,1 0-15  
3 2,3 16-31  
4 4,6,7 32-39; 48-63  

tabulka 1 - přiřazování paketů do výstupních front podle hodnoty CoS, nebo DSCP

Pravidla přiřazení hodnoty CoS a DSCP k jednotlivým frontám se dají upravit v globálním konfiguračním režimu pomocí příkazů uvedených níže (blíže se k nim dostaneme v závěru projektu). Pro změnu přiřazení CoS:


  - mls qos srr-queue {input|output} cos-map

Pro změnu přiřazení DSCP:


  - mls qos srr-queue {input|output} dscp-map

Zpět na obsah

III. Ukázkový příklad

V ukázkovém příkladě si ukážeme, jak na CISCO 3560 nastavit podporu QoS a také jeho funkci ověříme. V našem testu provedeme klasifikaci paketů prostřednictvím hodnoty CoS protokolu 802.1p/802.1q (2. vrstva Ethernetu) a na vstupních rozhraních 3560 budeme důvěřovat hodnotě CoS v příchozím paketu. Za pomocí této hodnoty a převodních map se pakety zařazují do čtyř výstupních front. Demonstrujeme si, jak se v sítí projeví, když:

3.1. Základní konfigurace

Otestování funkce QoS probíhalo stejným způsobem, který použili naši kolegové v předchozím projektu (viz. obrázek 1 - použitá topologie). Nejprve si uvedeme základní nastavení a poté se podíváme na výsledky, které jsme ověřili.

Testovací zapojení bylo shodné, jako u staršího projektu. viz. [1]

Schéma zapojení

obr. 1 - Schéma zapojení (schéma převzato od našich kolegů z minulého projektu)

Konfigurace PC1:

  ifconfig eth0 0.0.0.0  -  nutné pro aktivaci eth0 a následné vytvoření VLANU
  vconfig add eth0 10    -  na rozhraní eth0 vytvoří VLAN s ID = 10 -> 
      vznikne logické rozhraní eth0.10
  ifconfig eth0.10 10.0.0.10 netmask 255.255.255.0 broadcast 10.0.0.255  -  
      přiřadí logickému rozhraní eth0.10 IP adresu
  vconfig set_egress_map eth0.10 0 [Hodnota CoS]  -  všechny odchozí pakety 
      z rozhraní eth0.10 budou mít hodnotu CoS rovnu nastavené hodnotě


Konfigurace PC2:

  ifconfig eth0 0.0.0.0
  vconfig add eth0 10
  ifconfig eth0.10 10.0.0.20 netmask 255.255.255.0 broadcast 10.0.0.255
  vconfig set_egress_map eth0.10 0 [Hodnota CoS]


Konfigurace PC3:

  ifconfig eth0 10.0.0.30 netmask 255.255.255.0 broadcast 10.0.0.255


Konfigurace Cisco 3560:

  ; vstoupíme do privilegovaného režimu
  enable
  
  ; vstoupíme do globálního konfiguračního režimu
  # configure terminal
  
  ; Zapnutí funkce QoS globálně
  (config)# mls qos
  
  ; vytvoření VLAN
  (config)# vlan 10
    (config-vlan)# name vystup
    (config-vlan)# exit
	
  ; rozhraní fastEthernet 0/1 nastavíme jako trunk
  ; s 802.1q a povolíme důvěru v CoS
  (config)# interface fastEthernet 0/1
    (config-if)# switchport trunk encapsulation dot1q - zde pozor, oproti 3550
         je nutné prohodit tyto dva řádky
    (config-if)# switchport mode trunk - druhý prohozený řádek
    (config-if)# mls qos trust cos
    (config-if)# exit
	
  ; rozhraní fastEthernet 0/2 nastavíme jako trunk
  ; s 802.1q a povolíme důvěru v CoS	
  (config)# interface fastEthernet 0/2
    (config-if)# switchport trunk encapsulation dot1q
    (config-if)# switchport mode trunk
    (config-if)# mls qos trust cos
    (config-if)# exit
	
  ; rozhraní fastEthernet 0/3 nastavíme pro přístup 
  ; do VLAN 10 rychlostí 10Mb/s	
  (config)# interface fastEthernet 0/3
    (config-if)# switchport mode access
    (config-if)# switchport access vlan 10
    (config-if)# speed 10
    (config-if)# exit
	
  ; na všech rozhraních fastEthernet vypneme flowcontrol
  ; (pro správný průchod paketů switchem)	
  (config)# interface range fastEthernet 0/1 - 24
    (config-if)# flowcontrol receive off
    (config-if)# exit

Zpět na obsah

3.2. Změna šířky pásma pro výstupní fronty

Zde jsme vyzkoušeli, jak se změnilo množství přenesených paketů z PC1 a PC2, při změně šířky pásma pro jednotlivé výstupní fronty. Rozdělení šířky pásma mezi čtyři výstupní fronty na rozhraní se nastavuje poměrově tak, že součet 1/[nastavená hodnota] pro všechny 4 fronty nesmí překročit 1 (čili 100%). Parametr [shape] v níže uvedeném příkazu určuje, že po vyčerpání kapacity jednotlivých front se budou pakety, které se již nepodaří odeslat bufferovat (ukládat do paměti) a v případě jejího zahlcení se budou zahazovat, ikdyby byly ostatní fronty prázdné a na výstupní lince jsme měli ještě dostatečnou kapacitu. Opakem tohoho parametru je [share], kdy se po vyčerpání kapacity může použít volná kapacita jiné (jiných) front.

Pro změnu šířky jednotlivých pásem se používá příkaz:

    (config-if)# srr-queue bandwidth shape <weight1> <weight2> <weight3> <weight4>

Při našem testování jsme prozkoumali všechny kombinace přiřazení počítačů 1 a 2 do jednotlivých front i změny šířek pásma v těchto jednotlivých frontách. Výsledky jsou níže v tabulce. Jelikož programy, které jsme při testování používali, mají elegantní textový výstup, vždy jsme přesměrovali jejich výstup do souboru a ten si uložili pro další studování. Z důvodu velkého počtu testů jsou v tabulce vždy odkazy na daný soubor s výstupem, který je možné použít pro podrobnější prozkoumání chování (poznámka: testy se otevírají v novém okně).

Ještě je dobré si jednou připomenout, že při nastavování jednotlivých vah pro fronty určujeme jmenovatele zlomku 1 / váha. Takže čím větší číslo je u dané fronty přiřazeno, tím méně paketů bude z této fronty odcházet. Pro změnu hodnoty CoS je třeba provést změnu v konfiguraci počítače 1 nebo 2 pomocí příkazu


  -  vconfig set_egress_map eth0.10 0 [Hodnota CoS]

Cos PC1 (fronta) Cos PC2 (fronta) Váhy front Poměry front Příkaz Pakety/s z PC1 Pakety/s z PC2 Poměr paketů Výsledky
7 (4) 5 (1) 4 8 16 32 1/32:1/4 (1:8) srr-queue bandwidth shape 4 8 16 32 611 4883 1:7,992 4_1_vahy_4_8_16_32.txt
7 (4) 5 (1) 8 16 32 4 1/4:1/8 (2:1) srr-queue bandwidth shape 8 16 32 4 4882 2442 2:1 4_1_vahy_8_16_32_4.txt
7 (4) 5 (1) 16 32 4 8 1/16:1/8 (2:1) srr-queue bandwidth shape 16 32 4 8 2442 1220 2,002:1 4_1_vahy_16_32_4_8.txt
7 (4) 5 (1) 32 4 8 16 1/16:1/32 (2:1) srr-queue bandwidth shape 32 4 8 16 1222 610 2,003:1 4_1_vahy_32_4_8_16.txt
7 (4) 0 (2) 4 8 16 32 1/32:1/8 (1:4) srr-queue bandwidth shape 4 8 16 32 610 2442 1:4,003 4_2_vahy_4_8_16_32.txt
7 (4) 0 (2) 8 16 32 4 1/4:1/16 (4:1) srr-queue bandwidth shape 8 16 32 4 4883 1220 4,002:1 4_2_vahy_8_16_32_4.txt
7 (4) 0 (2) 16 32 4 8 1/8:1/32 (4:1) srr-queue bandwidth shape 16 32 4 8 2442 609 4,010:1 4_2_vahy_16_32_4_8.txt
7 (4) 0 (2) 32 4 8 16 1/16:1/4 (1:4) srr-queue bandwidth shape 32 4 8 16 1220 4883 1:4,002 4_2_vahy_32_4_8_16.txt
7 (4) 2 (3) 4 8 16 32 1/32:1/16 (1:2) srr-queue bandwidth shape 4 8 16 32 611 1220 1:1,997 4_3_vahy_4_8_16_32.txt
7 (4) 2 (3) 8 16 32 4 1/4:1/32 (8:1) srr-queue bandwidth shape 8 16 32 4 4883 610 8,005:1 4_3_vahy_8_16_32_4.txt
7 (4) 2 (3) 16 32 4 8 1/8:1/4 (1:2) srr-queue bandwidth shape 16 32 4 8 2442 4883 1:1,999 4_3_vahy_16_32_4_8.txt
7 (4) 2 (3) 32 4 8 16 1/16:1/8 (1:2) srr-queue bandwidth shape 32 4 8 16 1220 2441 1:2,001 4_3_vahy_32_4_8_16.txt

tabulka 2 - naměřené hodnoty při testování různých konfigurací výstupních front

V tabulce jsou uvedeny pouze výsledky pro variantu příkazu s parametrem [shape], tedy, kdy je provoz přesně limitován pomocí nastavených vah v příkazu a nikdy nebude větší. To znamená, že ikdyž jsme z obou PC odesílali provoz s maximální možnou rychlostí, linka k PC3 nebyla nikdy zaplněna na 100%. To bylo dáno tím, že jsme měli vždy provoz jen ve 2 frontách a pro zbylé 2 byla na lince vymezena kapacita, která se nikdy nevyužila.

Kdybychom chtěli zamezit takovémuto "plýtvání", poté by bylo dobré použít příkazy ve tvaru


  - srr-queue bandwidth share váha1 váha2 váha3 váha4

Při použití sdílení je provoz garantován podle nastavených vah (nebude nikdy menší), ale není jimi limitován. Pokud bychom použili sdílený režim v našem případě, potom by se začala využívat i volná kapacita pro námi nevyužité 2 fronty a provoz z obou PC by se zrychlil. Tuto skutečnost jsme také prakticky ověřili a výsledky potvrdili toto tvrzení. Zkoušeli jsme různé váhy front a také různě nastavené hodnoty CoS na jednotlivých PC a v porovnání s tabulkou 2 byl počet odesílaných paketů vždy vyšší. Zajímavým zjištěním také bylo, že poměr propouštěných paketů nebyl konstantní, takže při použití parametru [share] není možné garantovat poměr propouštěných dat podobně, jako u parametru [shape].

3.3. Zapnutí prioritní expediční fronty

Zde jsme vyzkoušeli priorizovat pakety odcházející z PC1 na PC3 prostřednictvím prioritní expediční fronty. Pokud na rozhraní zapneme prioritní režim, jsou vždy nejprve vyprázdňovány pakety z fronty s nejvyšší prioritou (tou je fronta číslo 1). Až se tato fronta vyprázdní, přistoupí se k vyprázdňování zbylých tří front s nižší prioritou. Tímto zajistíme, že určité pakety budou mít prioritu před všemi ostatními. Zapnutí prioritního režimu na rozhraní fastEthernet 0/3 provedeme tímto příkazem:

    (config)# interface fastEthernet 0/3
      (config-if)# priority-queue out

Pro připomenutí: PC1 musí odesílat pakety s CoS hodnotou 5, která je implicitně mapována na 1. výstupní frontu, tedy tu s nejvyšší prioritou. Potom se PC2 nedostane, až do zastavení provozu z PC1, vůbec ke slovu. Při ověřování této funkce se nám bohužel nepodařilo zjistit, jestli a jak se dá změnit číslo prioritní fronty. Nejsme si tedy ani jisti, zdali to jde. Více informací lze nalézt třeba ve [2].

Po provedení tohoto příkazu jsme na PC3 naměřili tyto hodnoty:

  pakety z PC1/s pakety z PC2/s
před příkazem 4884 2441
po příkazu - provoz generuje PC1 i PC2: 7323 0
po příkazu - provoz generuje pouze PC2: 0 7324

tabulka 3 - naměřené hodnoty před a po příkazu priority-queue out

Je vidět, že teprve po úplném vyprázdnění prioritní fronty (do které patřil provoz z PC1) se vůbec dostalo na další počítač(e). Je zde vidět potencionální nebezpečí zavádění prioritní fronty. Pokud dojde nějakým způsobem (ať už náhodou, či úmyslně) k zaplnění prioritní fronty díky i pouhému jednomu zdroji, nemusí se provoz ostatních síťových klientů vůbec dostat ke svému cíli. Je proto vždy potřeba zvážit, jestli zapnutí prioritní fronty náhodou více neuškodí, než pomůže.

Je proto dobré zabránit úplnému zahlcení linky provozem přes prioritní frontu. Lze nastavit limit pro každý port, takže provoz i z prioritní fronty lze omezit. Tímto limitem je omezeno využití linky provozem z prioritní fronty. Příkaz je uveden níže, jen je třeba podotknout, že limit může být 10 až 90 (tj 10% až 90%). Standardně je limit vypnutý (tj. nastaven na 100%). V praxi je tedy dobré při použití prioritní fronty nastavit i limit, kolik procent z přenosové kapacity linky může být pro tuto frontu použito. Tím se zabrání možnému úplnému odstavení počítačů, jejichž provoz nespadá do prioritní fronty.

  - srr-queue bandwidth limit [omezeni]
Zpět na obsah

3.4. Přemapování CoS pomocí CoS-DSCP mapy

Do této chvíle jsme pro určení typu (priority) provozu používali pouze hodnotou CoS, která je přítomna v hlavičce druhé vrstvy síťového provozu. Ovšem Cisco 3560 hodnotu CoS pro práci v rámci QoS nepoužívá. Pracuje vždy s hodnotou DSCP (která je záležitostí třetí síťové vrstvy). To, že pro klasifikaci provozu můžeme použít hodnotu CoS je pouze usnadnění.

Pro vnitřní potřeby switche je vždy hodnota CoS převáděna na hodnotu DSCP a teprve podle této hodnoty se provoz posuzuje (více informací viz. [2], např diagram 32-3 na straně 32-6 - strana 654 v pdf souboru). Proto existuje možnost, jak ovlivnit převod hodnoty CoS na hodnotu DSCP. Pro tento převod se používá tzv. CoS_to_DSCP mapa. Standartní definice této mapy je uveden v tabulce č. 4.

hodnota CoS 0 1 2 3 4 5 6 7
hodnota DSCP 0 8 16 24 32 40 48 56

tabulka 4 - Standartní CoS - DSCP mapa

Pokud nám toto přiřazení nevyhovuje, je možné mapu změnit pomocí níže uvedeného příkazu. Význam osmi hodnot (v rozmezí 0 až 63) uvedených za příkazem je seznam hodnot DSCP, které se mají přiřadit jednotlivým hodnotám CoS (první hodnota v příkazu odpovídá hodnotě DSCP, na kterou má být převedena hodnota CoS rovna nule, druhá hodnota odpovídá CoS jedna atd. Syntaxe příkazu je následující:

    (config)# mls qos map cos-dscp <dscp1> <dscp2> <dscp3> ... <dscp8>

Vše bude zřetelnější na příkladu. My se nyní pokusíme přemapovat pakety z PC2 s CoS=5 na DSCP=0, namísto původní DSCP=40. Musíme tedy za příkazem uvést seznam osmi hodnot DSCP, které se mají přiřadit jednotlivým hodnotám CoS. Ikdyž chceme změnit pouze jednu hodnotu, musí být seznam kompletní.

    (config)# mls qos map cos-dscp 0 8 16 24 32 0 48 56

To, že příkaz funguje, jsme si ověřili prozkoumáním hlaviček příchozích paketů paketovým analyzátorem na PC3. Z tohoto je taky patrné, že switch nepoužívá hodnotu DSCP pouze pro své vnitřní potřeby, ale uvádí tuto hodnotu i v odchozích paketech. Hodnotu CoS zachovává nezměněnu a hodnotu DSCP buď doplňuje, nebo mění podle své aktuální mapy. Z tohoto vyplývá další možné nebezpečí. Pokud místo hodnoty CoS budeme v příchozích paketech důvěřovat hodnotě DSCP, musíme být opatrní. Pokud na cestě paketu k námi konfigurovanému zařízení bude ještě další switch, nebo jiné zařízení, které změní hodnotu DSCP podlé své vlastní mapy, může dojít k nesprávnému posouzení takto pozměněných paketů. Vždy ovšem záleží na posouzení aktuální situace v síti, jestli tato skutečnost nějak ovlivní její provoz.

Zpět na obsah

3.5. Přemapování CoS na výstupní frontu pomocí CoS-egress_queue mapy (CoS - výstupní fronta)

Úprava CoS-egress_queue mapy (hodnotu CoS přiřazuje na výstupní frontu) se u 3560 neprovádí na rozhraní, ale, na rozdíl od Cisco 3550, v globálním konfiguračním režimu, jak již bylo zmíněno dříve. To znamená, že tato volba ovlivní všechna rozhraní zařízení. Příkaz pro nastavení tohoto mapování je následující:

  (config)# mls qos srr-queue output cos-map queue <číslo fronty (1..4)>
                     threshold <1..3> <výčet hodnot cos, 
                          které zařadit do této fronty (0..7)>

Pro použití hodnoty DSCP je také možné použít podobné přemapování výstupních front. Příkaz je podobný, jeho syntaxe je:

  (config)# mls qos srr-queue output dscp-map queue <číslo fronty (1..4)>
                     threshold <1..3> <výčet hodnot dscp (0..63), max 8 hodnot>

Jako příklad poslouží ukázka, jak mapovat DSCP hodnoty 10 a 11 na frontu číslo 1

  Switch(config)# mls qos srr-queue output dscp-map queue 1 threshold 2 10 11
Zpět na obsah

IV. Závěr

Závěrem lze říci, že funkce QoS na switchi Cisco Catalyst 3550 i 3560 se ukázala být až překvapivě spolehlivá. V podmínkách laboratoře ale není možné ověřit všechny možné podmínky a situace, které mohou v síti nastat, proto by tento projekt a projekt našich kolegů z minulých let měl být brán pouze jako úvodní informace, jak na QoS na Cisco 3550 a 3560. Všechny zde uvedené (a vesměs základní) věci kolem QoS byly odzkoušeny a je tedy možné předpokládat, že budou fungovat i v budoucnu (např. při změně verze Cisco IOS atd). Abychom zachovali podobnost v obou projektech, použili jsme stejně, jako naši kolegové, jejich vlastní programy pro odesílání a analýzu provozu v síti. Programy jsou dílem našich předchůdců a jejich zdrojové kódy jsou k dispozici zde.

Zpět na obsah

V. Literatura

[1] Petr Jaššo, Tomáš Chalupka: Studentský projekt: Podpora QoS na Cisco 3550 a 2950T. Klasifikace, priorizace na 2. vrstvě, 802.1p, vazba na 3. vrstvu (IP DSCP).
Projekt je dostupný online na http://www.cs.vsb.cz/grygarek/SPS/projekty0405/QoS-switch/QoS.htm (poznámka: kontrolováno 21.6.2007, odkaz se otevírá v novém okně).

[2] Cisco Systems, Inc.: Catalyst 3560 Switch Software Configuration GuideCisco IOS Release 12.2(35)SE December 2006
Příručka je dostupná online nawww.cisco.com (poznámka: kontrolováno 21.6.2007, odkaz se otevírá v novém okně).

Zpět na obsah