QoS Laboratorioharjoitus 7

QoS Laboratorioharjoitus 7 Eemeli Paananen Henrik Saari Robert Rahikainen Laboratorioharjoitus Huhtikuu 2016 Tekniikan ja liikenteen ala Insinööri (AMK), Tietoverkkotekniikan tutkinto-ohjelma

1 Sisältö 1 Johdanto... 4 2 Teoria... 4 2.1 802.1p COS merkkaus... 4 2.2 Type of Service... 5 2.2.1 Ip Precedence... 5 2.3 DSCP Merkkaus... 6 2.4 Juniper QoS yleisesti... 7 2.5 Cisco QoS... 7 2.5.1 Yleisesti... 7 2.5.2 Class maps... 8 2.5.3 Policy maps... 8 2.5.4 Service policies... 8 2.5.5 Jonot... 9 2.5.6 Hallinta... 10 3 Suunnitelmat... 10 3.1 Mittauksissa käytetty topologia... 10 4 Toteutus... 11 4.1 Mittaukset yleisesti... 11 4.1.1 Mittaus 1... 11 4.1.2 Mittaus 2... 11 4.1.3 Mittaus 3... 12 4.2 Tehtävä 1... 12 4.2.1 Mittaus 1... 12 4.2.2 Mittaus 2... 21 4.2.3 Core-R6 Core-R4 linkkivälin leikkaukset... 21

2 4.2.4 Leikkaus Juniper-ympäristössä... 24 4.2.5 Mittaus 3... 27 4.3 Tehtävä 2... 33 4.4 Tehtävä 3... 34 4.5 Tehtävä 4... 34 5 Pohdinta... 35 Lähteet... 36 Kuviot Kuvio 1. 802.1p (QoS-Laboratoriaharjoitus 6)... 4 Kuvio 2. TOS-kentät, IP Precedence ja DSCP. (Quality of Service)... 5 Kuvio 3. Juniper QoS (QoS-Laboratoriaharjoitus 6).... 7 Kuvio 4. Ciscon QoS periaate (QoS-Laboratoriaharjoitus 6).... 9 Kuvio 5. Mittauksissa käytetty topologia... 10 Kuvio 6. Juniper R2 -> R3 linkin jonostatistiikka 1... 13 Kuvio 7. Juniper R2 -> R3 linkin jonostatistiikka 2... 14 Kuvio 8. Juniper R2 -> WG2-R1 linkkivälin jonostatistiikka 1... 15 Kuvio 9. Juniper R2 -> WG2-R1 linkkivälin jonostatistiikka 2... 16 Kuvio 10. Juniper R2 -> WG2-R1 linkkivälin jonostatistiikka 3... 16 Kuvio 11. Juniper R3 -> Cisco Core R6 linkkivälin jonostastistiikka 1... 17 Kuvio 12. Juniper R3 -> Cisco Core R6 linkkivälin jonostastistiikka 2... 17 Kuvio 13. Cisco Core R5 policy-map... 18 Kuvio 14. Cisco Core R4 policy-map... 18 Kuvio 15. Cisco Core R6 policy-map... 19 Kuvio 16. JDSU-mittaustulos... 20 Kuvio 17. Centos mittaustulos... 20 Kuvio 18. Jatkuva ping... 21 Kuvio 19. Core-R6 ei leikkaa IPTV tai Data liikennettä... 22 Kuvio 20. Core-R6 leikkaa Best Effort liikennettä noin 4Mb... 22 Kuvio 21. JDSU - Stream 5 ei leikkausta... 23

3 Kuvio 22. Iftop Spider-Laptop 1 (Data-stream)... 23 Kuvio 23. Spider-Laptop 2 Network Utilization 2%... 24 Kuvio 24. Juniper R3:n konfiguraatiopätkä VOIP:n QoS-säännöistä... 25 Kuvio 25. Juniper-R3 ei leikkaa VoIP-liikennettä... 25 Kuvio 26. Juniper-R3 leikkaa IPTV-liikennettä 3 pakettia/s... 26 Kuvio 27. JDSU stream 1 (VoIP)... 26 Kuvio 28. Iftop Centos1 (IPTV-Stream)... 27 Kuvio 29. Labranetistä lähetetty ping-kysely win7-työasemalle... 27 Kuvio 30. Core-R6:n IPTV-liikenteen asetukset... 28 Kuvio 31. Core-R6:n Data-liikenteen asetukset... 28 Kuvio 32. Core-R6:n BE-asetukset... 29 Kuvio 33. JDSU:n stream-lukemat... 29 Kuvio 34. Laptop 2:n wireshark-kaappaus... 30 Kuvio 35. Laptop 1:n wireshark-kaappaus... 30 Kuvio 36. Centos2:n iftop-taulu ja wireshark-kaappaus... 31 Kuvio 37. Centos1:n wireshark-kaappaus... 32 Kuvio 38. Win7-työaseman wireshark-kaappaus... 32 Kuvio 39. Labranetistä lähetetty ping Win7-työasemalle... 33 Taulukot Taulukko 1. 802.1p kentän arvot.... 5 Taulukko 2. IP Precedence merkkauksessa käytettävät arvot ja selitteet.... 6 Taulukko 3. DSCP:n käyttämät arvot ja selitteet. (QoS-Laboratoriaharjoitus 6)... 6 Taulukko 4. Mittauksessa 1 käytetyt tietovuot... 11 Taulukko 5. Mittauksessa 2 käytetyt tietovuot... 12 Taulukko 6. Mittauksessa 3 käytetyt tietovuot... 12

4 1 Johdanto Harjoitusta varten oli rakennettu valmis mittausympäristö laboratorioinsinöörien ja opettajien toimesta. Harjoituksen tarkoituksena oli suorittaa erilaisia mittauksia. Mittausten jälkeen tuli perustella mittaustulosten ja laitekonfiguraatioiden perusteella eri tietovoiden käyttäytyminen eri tilanteissa. Mittauksia suoritettiin yhteensä kolme kappaletta ja kysymyksiä on yhteensä viisi kappaletta. Kysymyksien vastaamiseen käytetään kaikkien kolmen mittauksen tuloksia. 2 Teoria 2.1 802.1p COS merkkaus Ethernet kehyksessä voidaan merkata paketin prioriteetti kehyksen 802.1Q osaan. Merkintää kutsutaan COS (Class of Service) merkkaukseksi. Kuviossa 1 on esitetty Ethernet kehyksen osio johon prioriteetti voidaan asettaa. (QoS-Laboratoriaharjoitus 6) Kuvio 1. 802.1p (QoS-Laboratoriaharjoitus 6) Priority kenttä koostuu kolmesta bitistä. Kolmella bitillä voidaan asettaa prioriteetti taulukon 1 mukaisesti. (QoS-Laboratoriaharjoitus 6)

5 Taulukko 1. 802.1p kentän arvot. Kentän arvo Prioriteetti Akronyymi Liikenne tyyppi 000 0 BK Background 001 1 BE Best Effort 010 2 EE Excellent Effort 011 3 CA Critical Applications 100 4 VI Video 101 5 VO Voice 110 6 IC Internet Control 111 7 NC Network Control 2.2 Type of Service Type of service (TOS) kentällä IP-kehyksessä voidaan merkata pakettien prioriteetti käyttäen joko IP Precedence merkkausta tai DSCP (DiffServ Code Point) merkkausta. Kuviossa 2 on esitelty IP Precedence ja DSCP:n käyttämät kentät. Kuvio 2. TOS-kentät, IP Precedence ja DSCP. (Quality of Service) 2.2.1 Ip Precedence IP Precedence käyttää TOS kentästä kolmea ensimmäistä bittiä (0-2) antaen kahdeksan eri luokitusta liikenteelle. Biteillä 3-6 voidaan myös pyytää paketilla parempaa viivettä, kaistaa ja luotettavuutta tai säätää paketin hintaa, mutta näitä kenttiä ei pääsääntöisesti ole käytetty. IP Precedence merkkauksessa käytetyt arvot ja selitteet on esitetty taulukossa 2. (QoS-Laboratoriaharjoitus 6)

6 Taulukko 2. IP Precedence merkkauksessa käytettävät arvot ja selitteet. Kentän arvo (Luokka) Selite 000 (0) Best Effort 001 (1) Priority 010 (2) immediate 011 (3) Flash (Video/Ääni) 100 (4) Flash Override 101 (5) Critical 110 (6) Internetwork Control 111(7) Network Control 2.3 DSCP Merkkaus Differitiated Services Code Point merkkaus käyttää pohjana samoja arvoja ensimmäisessä kolmessa bitissä mitä IP Precedence ja tämän lisäksi DSCP-merkkauksessa käytetään bittejä 3-5 luotettavuuden hallintaan. Biteillä 3-5 ohjataan paketin pudottamisen todennäköisyyttä. Taulukossa 3 on esitetty DSCP:n käyttämät arvot ja seliteet. Taulukko 3. DSCP:n käyttämät arvot ja selitteet. (QoS-Laboratoriaharjoitus 6)

7 2.4 Juniper QoS yleisesti Juniper QoS koostuu määrittelemällä Classifierit eli luokittelijat, joilla liikenne tunnistetaan eri rajapinnoissa. Tämän jälkeen määritetään Forwarding-classit, joilla liikennevuo ohjataan jonoihin. Näitä jonoja palvelllaan schedulerien avulla ja schedulerit kootaan scheduler-mapilla yhteen. Scheduler-map liitetään rajapintaan, johon halutaan muodostaa palvelunlaatua. Rewrite säännöillä voidaan kiinniotettua liikennettä merkata eri arvoilla. (QoS-Laboratoriaharjoitus 6.) Kuviossa 3 esitetään Juniper J-Series QoS-prosessointi. Kuvio 3. Juniper QoS (QoS-Laboratoriaharjoitus 6). 2.5 Cisco QoS 2.5.1 Yleisesti Harjoituksen puitteissa Ciscon Quality of Service toteutus ja taustalla vallitseva filosofia ovat varsin suoraviivaisia. Ciscon palvelulaatu toteutetaan tunnistamalla haluttu

8 liikenne, luokittelemalla se ja luokittelun jälkeen priorisoimalla haluttu liikenne. Priorisoidulle liikenteelle valitaan sopiva QoS-mekaniikka, esimerkiksi haluttu jonotustapa ja tämän asetukset sidotaan verkkolaitteen rajapintaan halutun liikenteen suunnan mukaisesti. (QoS-Laboratoriaharjoitus 6.) 2.5.2 Class maps Class maps on Ciscon tapa määritellä se liikenne, jolle halutaan toteuttaa palvelunlaatua. Class map tehdään jokaiselle eri halutulle liikenneluokalle ja liikenneluokkia voidaan myös yhdistellä käyttämällä komentoja match-all tai match-any riippuen halutaanko asettaa luokalle useampi ehto ja halutaanko näille suorittaa AND vai OR operaatio. Liikenne voidaan luokitella Ciscon valmiilla tunnisteilla tai määritellä oma ja tarkempi tunnistuslista käyttämällä pääsylistaa. (QoS-Laboratoriaharjoitus 6.) 2.5.3 Policy maps Policy map sitoo aikaisemmin luodut liikenneluokat (Class maps) ja kertoo, mitä liikenneluokalle tehdään. Liikenneluokka voidaan esimerkiksi merkata tai sille voidaan määrittää priorisointia tai esimerkiksi jonotustapa. (QoS-Laboratoriaharjoitus 6.) 2.5.4 Service policies Service policy määrittää, minne ja mihin suuntaan halutut palvelulaatuasetukset vaikuttavat. Service policy sitoo policy mapin verkkolaitteen rajapintaan, joko sisääntulevalle tai ulosmenevälle liikenteelle. (QoS-Laboratoriaharjoitus 6.) Kuviossa 4 esitetään yleisellä tasolla edellä käyty Cisco QoS periaate. Kuviosta käy selkeästi ilmi, miten palvelulaatuasetusten rakenne koostuu selkeistä vaiheista, mikä auttaa konfiguroijaa pysymään selvillä siitä mitä on tekemässä.

9 Kuvio 4. Ciscon QoS periaate (QoS-Laboratoriaharjoitus 6). 2.5.5 Jonot Jonot ja liikenteen priorisointi suoritetaan liikenneluokkakohtaisesti policy mapin avulla. Cisco suosittelee best practices toteutuksena käytettävän LLQ+CBWFQ eli low-latency queue + class based weighted fair queue yhdistelmää. Tämä koostuu priorisoitavasta jonosta ja muista halutuista jonoista, joille toteutetaan luokkapohjaista painotusta. Priorisoitava jono voi olla esimerkiksi puheliikenne, sillä puheliikenne vaatii pienet latenssit ja vapaata kaistaa. Priority jono on siis jono, joka tyhjennetään aina ennen muita palveltavia jonoja ja se asetetaan käyttämällä policy mapissa liikenneluokalle priority komentoa. Muiden luokkien jonotus asetetaan CBWFQ:ksi käyttäen policy mapissa bandwidth komentoa ja best effort luokalle Cisco suosittelee käytettävän weighted fair queue jonotusta, joka otetaan käyttöön luokalle fair-queue komennolla policy mapissa. (QoS-Laboratoriaharjoitus 6.)

10 2.5.6 Hallinta Cisco käyttää jonojen ruuhkanhallintamekanismina weighted random early detection eli WREDiä. Käytännössä WRED tiputtaa jonosta satunnaisia paketteja, ettei ruuhkaa pääse syntymään. Weighted nimitys kertoo, että tiputus kohdistuu aggressiivisemmin vähemmän tärkeisiin paketteihin. WRED voidaan sitoa CBWFQ toiminteeseen tai käyttää erikseen. Luokille WRED otetaan käyttöön lisäämällä random-detect komento policy mapiin. Lisäksi täytyy asettaa raja-arvot eri random-detect profiileille, eli eri liikenneluokkiin sidottuihin profiileihin. WRED käyttää tunnistuksessa IP precedenceä tai DSCP arvoa. (QoS-Laboratoriaharjoitus 6.) 3 Suunnitelmat 3.1 Mittauksissa käytetty topologia Mittauksissa käytetty topologia on esitetty kuviossa 5. Liikennettä generoidaan JDSU ja Fluke Optiview lähettimillä ja vastaanottavina päinä toimivat topologiakuvassa esitetyt päätelaitteet Spidernet-tilassa. Kuvio 5. Mittauksissa käytetty topologia

11 4 Toteutus 4.1 Mittaukset yleisesti Tulkittavamme mittaukset jaettiin kolmeen eri simuloituun tilanteeseen. Ensimmäisessä mittauksessa ei verkkoon syntynyt pullonkaulaa eikä näinollen ruuhkatilanteita. Tehtävänämme olikin siis selvittää, miten valmiit asetukset palvelivat tietovoita tässä tilanteessa. Toisessa mittauksessa Juniper Corelle menevä linkki ja Juniper Core itse riittivät vielä palvelemaan WG2 työryhmälle vietävää liikennettä, mutta WG4 työryhmälle kuljetettu liikenne ruuhkautui. Tehtävänä oli selvittää miten Cisco Core käsitteli tilannetta. Kolmas mittaus simuloi ruuhkatilannetta koko verkossa. Tehtäväksi jäi tulkita, miten koko verkon end-to-end QoS asetukset selviytyivät tilanteesta. 4.1.1 Mittaus 1 Taulukossa 4 on esitetty liikennevuot ja määrät ensimmäisessä mittauksessa. Liikenne kulki molempiin kohdetyöryhmiin ja liikennemäärät olivat pieniä. Taulukko 4. Mittauksessa 1 käytetyt tietovuot Tietovuo Lähettäjän merkkaus Nopeus Kohde JDSU - Stream 1 IP-Precedence 5 (Critical) 2 Mbit/s JDSU - Loopback 1 JDSU - Stream 2 IP-Precedence 4 (Flash-over.) 2 Mbit/s Centos 1 JDSU - Stream 5 IP-Precedence 3 (Flash) 2 Mbit/s JDSU - Loopback 2 WG5-SW2-WS PING 1 ICMP ECHO /s Win7 -työasema 195.0.0.98 4.1.2 Mittaus 2 Taulukossa 5 esitetään mittauksessa 2 käytetyt liikennevuot ja määrät. Liikenne WG4 työryhmään aiheutti pullonkaulan Core R6 <-> Core R4 linkkivälille, joka oli asetettu 10 Mbit/s nopeuteen Speed komennolla. WG5 ja WG4 työryhmien välinen suora linkki oli määritetty ip ospf cost komennolla toissijaiseksi linkiksi.

12 Taulukko 5. Mittauksessa 2 käytetyt tietovuot Tietovuo Lähettäjän merkkaus Nopeus Kohde JDSU - Stream 1 IP-Precedence 5 (Critical) 4 Mbit/s JDSU - Loopback 1 JDSU - Stream 2 IP-Precedence 4 (Flash-over.) 4 Mbit/s Centos 1 JDSU - Stream 3 IP-Precedence 4 (Flash-over.) 4 Mbit/s Spider-Laptop 1 JDSU - Stream 5 IP-Precedence 3 (Flash) 4 Mbit/s JDSU - Loopback 2 JDSU - Stream 6 BEST EFFORT 6 Mbit/s Spider-Laptop 2 WG5-SW2-WS PING 1 ICMP ECHO /s Win7 -työasema 195.0.0.98 4.1.3 Mittaus 3 Taulukossa 6 on esitetty mittauksessa 3 käytetyt liikennevuot ja määrät. Mittaus simuloi koko verkon ruuhkatilannetta, jossa myös Cisco ja Juniper Core verkkojen välillä on hieman ristiriitaa merkkauksessa. Taulukko 6. Mittauksessa 3 käytetyt tietovuot Tietovuo Lähettäjän merkkaus Nopeus Kohde JDSU - Stream 1 IP-Precedence 5 (Critical) 4 Mbit/s JDSU - Loopback 1 JDSU - Stream 2 IP-Precedence 4 (Flash-over.) 5 Mbit/s Centos 1 JDSU - Stream 3 IP-Precedence 4 (Flash-over.) 5 Mbit/s Spider-Laptop 1 JDSU - Stream 4 IP-Precedence 3 (Flash) 5 Mbit/s Pöytä Win7 JDSU - Stream 5 IP-Precedence 3 (Flash) 5 Mbit/s JDSU - Loopback 2 JDSU - Stream 6 BEST EFFORT 6 Mbit/s Spider-Laptop 2 Fluke 100 Mbit/s Centos 2 WG5-SW2-WS PING 1 ICMP ECHO /s Win7 -työasema 195.0.0.98 4.2 Tehtävä 1 4.2.1 Mittaus 1 Mittausten tietovuot on esitetty aikaisemmissa taulukoissa 4,5,6 ja niille tehdyt palvelunlaatuasetukset esitetään seuraavissa kuvioissa 6-15. Varsinaiset mittaustulokset esitetään kuvioissa 16 ja 17. Juniper Coren jonostatistiikasta nähdään, mihin luokkiin liikenne osuu käytetyillä linkkiväleillä. Ensimmäisessä mittauksessa 10 Mbit/s nopeuksisille linkkiväleille asetettiin taulukon 4 tietovuot. Juniperin jonostatistiikoista nähdään vain minimaalista Tail-droppia IPTV streamille työryhmään saapuessa.

Kuvio 6. Juniper R2 -> R3 linkin jonostatistiikka 1 13

14 Kuvio 7. Juniper R2 -> R3 linkin jonostatistiikka 2 Juniper R2 Forwarding class: Data oli tyhjä.

Kuvio 8. Juniper R2 -> WG2-R1 linkkivälin jonostatistiikka 1 15

16 Kuvio 9. Juniper R2 -> WG2-R1 linkkivälin jonostatistiikka 2 Kuvio 10. Juniper R2 -> WG2-R1 linkkivälin jonostatistiikka 3

17 Kuvio 11. Juniper R3 -> Cisco Core R6 linkkivälin jonostastistiikka 1 Kuvio 12. Juniper R3 -> Cisco Core R6 linkkivälin jonostastistiikka 2

18 Cisco Coren policy-map asetuksista nähdään core-reitittimille asetetut palvelunlaatukonfiguraatiot. Ensimmäisessä mittauksessa asetetut tietovuonopeudet mahtuivat hyvin määritettyjen priority jonojen ja CBWFQ jonojen sisään. Kuvio 13. Cisco Core R5 policy-map Kuvio 14. Cisco Core R4 policy-map Core R6 reitittimelle on asetettu lisäksi liikenteen muokkausta. Police ratella määritetään ylin raja, jonka jälkeen liikenne tiputetaan. Traffic shapingilla viedään ylimääräinen SLA:n ulkopuolinen liike puskuriin ja puskurin verran liikennettä voidaan lähettää, kun linjalla on tilaa.

19 Kuvio 15. Cisco Core R6 policy-map Kymppimegaisille linkkiväleille tuotiin yhteensä 8 Mbps verran liikennettä. JDSU ja Centos iftop tuloksista havaitaan, että 2 Mbps sujahtaa läpi kaikille hyvin ja pitäisikin sujahtaa, sillä asetukset sen sallivat.

20 Kuvio 16. JDSU-mittaustulos Kuvio 17. Centos mittaustulos

Työasemien välillä kulkeva jatkuva ping sai ensimmäisen mittauksen tuloksilla vielä tarpeeksi kaistaa ja edestakainen viive pysyi vielä pienissä arvoissa. 21 Kuvio 18. Jatkuva ping Ensimmäisen mittauksen tulokset eivät vielä heijasta erityisemmin jonotuksen ja leikkaamisen tapahtumia, koska ruuhkatilainteita ei pääse syntymään kun käytössä on vasta 8 megaa 10 megan kapasiteetista. 4.2.2 Mittaus 2 4.2.3 Core-R6 Core-R4 linkkivälin leikkaukset Topologian ja linkkinopeuksien perusteella ensimmäiset paikat missä liikennettä leikataan on Core-R6 Core-R4 linkkivälillä ja Juniper-R3 laitteella. Core-R6 Core-R4 linkkivälillä kulkee JDSU-Streamit 3, 5 ja 6 joka ovat nähtävissä luokissa Core-R6 laitteella IPTV, Data ja Best Effort. Tietovoita lähetetään nopeuksilla 4Mb, 4Mb ja 6Mb. Linkkivälin nopeus on 10Mb joten 4Mb pitäisi leikkaantua pois. Kuviossa 19 huomaamme, että Core-R6 ei leikkaa IPTV tai Data liikennettä ja kuviossa 20 huomaamme, että laite leikkaa Best-Effort liikenteestä.

22 Kuvio 19. Core-R6 ei leikkaa IPTV tai Data liikennettä Kuvio 20. Core-R6 leikkaa Best Effort liikennettä noin 4Mb

23 Päätelaitteilta voimme varmistaa tämän ja kuviosta 21 ja 22 voidaan huomata, että liikennettä ei leikata. Kuviosta 23 voimme huomata, että 6M liikenteestä on vastaanotettu 2M. Kuvio 21. JDSU - Stream 5 ei leikkausta Kuvio 22. Iftop Spider-Laptop 1 (Data-stream)

24 Kuvio 23. Spider-Laptop 2 Network Utilization 2% 4.2.4 Leikkaus Juniper-ympäristössä Juniper ympäristöön saapuu Core-R6 laitteen kautta kolme tietovuota. JDSU-Streamit yksi (VoIP) ja kaksi (IPTV), lisäksi yksi ICMP-ECHO kysely per sekunti WG5-SW2-WS työasemalta. Juniper-R3 laitteella oli taattu 2Mb liikennettä Streamille 1 ja ruuhkattomassa tilanteessa kaistaa annetaan enintään 3Mb. Streamille 2 Juniper-R3 takaa 4Mb jonka jälkeen kaikki ylimenevä liikenne leikataan pois. Streamit 1 ja 2 liikkuvat kokonaan linkkivälillä Juniper-R3 Juniper-R5. Rajapinnasta GE1/0/1 on havaittavissa molemmat vuot. Konfiguraation mukaan VOIP:lle annetaan 2Mb kiinteää kaistaa 1500Kb purskeella. Kaistan salliessa VOIP voi kuitenkin käyttää maksimissaan 3Mb 1500Kb purskeella, jonka ylittävä liikenne leikataan (katso kuvio 24). Kuviossa 25 on havaittavissa, että VoIP liikennettä asetetaan jonoon 3Mb ja kuviossa 26 huomamme, että IPTV:tä leikataan hyvin vähän (3 pakettia/s).

25 Kuvio 24. Juniper R3:n konfiguraatiopätkä VOIP:n QoS-säännöistä Kuvio 25. Juniper-R3 ei leikkaa VoIP-liikennettä

26 Kuvio 26. Juniper-R3 leikkaa IPTV-liikennettä 3 pakettia/s Sama voidaan huomata myös JDSU:n peilien antamasta datasta. Kuviossa 27 näkyy, että JDSU:n stream 1 saa 3Mb/s, eli huomataan 1Mb leikkaus. Kuviossa 28 puolestaan Centos1 työasema saa vähän vajaa 4Mb/s, eli leikkausta tapahtuu hyvin vähän. Kuvio 27. JDSU stream 1 (VoIP)

27 Kuvio 28. Iftop Centos1 (IPTV-Stream) Tämän mittauksen aikana ei vielä älytöntä ruuhkaa syntynyt, jolloin labranetistä lähetetty ping-kysely Win7-työasemalle meni vaivatta läpi pienillä ping-heitoilla (katso kuvio 29). Kuvio 29. Labranetistä lähetetty ping-kysely win7-työasemalle 4.2.5 Mittaus 3 4.2.5.1 Leikkaukset Cisco-ympäristö Cisco-R6 leikkaa tässä mittauksessa vain linkkivälillä Core-R4:lle. Siihen on asetettu 10Mb/s nopeus ja sinne pusketaan 16Mb/s dataa. IPTV-dataa saapuu Core-R6:lle

28 5Mb/s, Data-liikennettä 5Mb/s ja BE-liikennettä 6Mb/s. Liikennettä joudutaan siis leikkaamaan 6Mb/s pois. Kuvioiden 30 ja 31 konfiguraatioista nähdään, että IPTVliikenteelle on taattu 4Mb/s ja 4,5Mb/s mikäli kaista niin sallii. Data-liikenteelle on taattu 2Mb/, mutta sitä on muokattu siten, että se voi käyttää 4Mb/s mikäli sitä arvokkaampaa liikennettä ei näy. Kuvioissa 30, 31ja 32näkyy Core R6:n asetukset näille kahdelle luokalle ja BE-liikenteelle. Kuvio 30. Core-R6:n IPTV-liikenteen asetukset Kuvio 31. Core-R6:n Data-liikenteen asetukset

29 Kuvio 32. Core-R6:n BE-asetukset Kuvio 33 alla todentaa, että JDSU:n stream 5 tosiaan saa 4Mb/s kaistaa. Ylimääräinen kaista on leikattu BE-liikenteestä. Kuvio 33. JDSU:n stream-lukemat Kuviot 34 ja 35 todentavat Laptop1:n ja Laptop2:n merkkauksen.

30 Kuvio 34. Laptop 2:n wireshark-kaappaus Kuvio 35. Laptop 1:n wireshark-kaappaus

31 4.2.5.2 Leikkaukset Juniper-ympäristö Juniper R3:lle tulee Cisco Coresta päin 5 eri liikennevuota. JDSU stream 1 (VoIP) lähetetään 4Mb/s nopeudella. JDSU stream 2 (IPTV)- ja JDSU stream 4 (Data)-liikennettä lähetetään 5Mb/s kumpaakin. Fluke lähettää 100Mb/s cos 1 merkattua liikennettä, joka on merkattu uudelleen Core-R6:lla precedence 1:nä. Precedence 1:stä ei kuitenkaan oteta kiinni Juniperin konfiguraatioissa, jolloin se heitetään BE-luokkaan. Alla kuviossa 36 näkyy kun Centos2:lle tullut BE-data ei saa kuin reilut 740Kb/s kaistaa. Kuvio 36. Centos2:n iftop-taulu ja wireshark-kaappaus Kuvioissa 37 ja 38 on todennettu merkkaukset Centos1- ja Win7-työasemilla.

32 Kuvio 37. Centos1:n wireshark-kaappaus Kuvio 38. Win7-työaseman wireshark-kaappaus

33 Kun labranetin koneelta lähetettiin ping-kyselyä win7-työasemalle, huomattiin kun data-liikenne alkoi olemaan melko tukossa. Tämä näkyi sekä Centos2:n iftop-kuvasta, mutta myös ping-kyselyn viiveestä, joka näkyy alla kuviossa 39. Kuvio 39. Labranetistä lähetetty ping Win7-työasemalle 4.3 Tehtävä 2 Mittauksissa suoritettiin sekä passiivista, että aktiivista mittaamista. Esimerkiksi työasemien välinen ICMP echo mittaa hetkellistä kaksisuuntaista saatavuutta ja kertoo näin verkon luonteesta. Koska se näin ollen luo liikennettä verkkoon, on mittaaminen aktiivista. JDSU testidata on myös aktiivista mittaamista, sillä verkkoon generoidaan liikennettä. Aktiivinen mittaaminen ei kuitenkaan välttämättä suoraan kerro siitä miten verkko käyttäytyy oikeiden liikennevirtojen alla. (Kuismanen & Martikainen, 2006.) Passiivista mittaamista suoritettiin reitittimien rajapintalaskureilla, wiresharkilla ja iftop/network activity monitoroinnilla. Passiivinen mittaaminen kertoo lähinnä verkon liikenteestä, eli siitä mitä liikennevirroissa kulkee. (Kuismanen & Martikainen, 2006.) Mittauksia voimme jakaa myös ajallisesti jatkuviin ja näytteistettyihin. Rajapintalaskurit, kuten Juniperin show interfaces queue ja Ciscon show policy-map interface, ovat esimerkki jatkuvasta mittaamisesta ja näytteistettyä mittaamista on esimerkiksi viiveen mittaaminen, kuten työasemien välisessä jatkuvassa ICMP echossa. (Kuismanen & Martikainen, 2006.)

34 Mittaustuloksissa tuli olla tarkkana, mitä laskurit itse asiassa ilmoittivat. Esimerkiksi iftop ilmoittaa throughputtia eikä näin kerro täysin fyysisen linkin bittimäärästä. Muita virheitä saattavat aiheuttaa aktiivilaitteiden kellosignaalien synkronointi tai sen mahdollinen puute. Aikaleimoihin perustuva tarkastelu esim. viiveen mittaamisessa ei ole yhtä luotettava yksisuuntaisilla mittauksilla ilman hyvää synkronointia. Tarkempia valmisteluja emme tällaisten asioiden suhteen tehneet sillä saavuimme ns. valmiiseen pöytään, joten meille on jälkeenpäin hankala arvioida systemaattisen ja satunnaisen virheen suhdetta mittaustuloksiin. 4.4 Tehtävä 3 Mittauksessa 3 fluke lähettää WG1:stä 100mb/s dataa verkkoon. Extreme coressa ei ollut mitään QoS:iin liittyvää konfiguraatiota, joten siitä data menee läpi kaistan salliessa best efforttina. Core-R6:lle tullessa R6 sallii access-listoilla paketit mistä tahansa IP-osoitteesta precedence arvoilla flash, flash-override, critical, internet ja network. Fluke osaa ilmeisesti itse määrittää datansa cos-arvon 1, koska sisääntuleva data portissa ge0/1.10 käytettävässä policy-map:ssa matchataan cos arvoon 1. R6:n portissa ge0/1.10, joka on extreme coreen päin menevä portti, on sisääntulevalle datalle sääntö, jossa liikenne merkataan precedence 1:llä, eli internettinä. Kun mittauksessa 3 katsoimme fluken kohteen Centos2:n wireshark-kaappausta, huomasimme että data tulee best efforttina, eli merkkaus on muuttunut ja dataa tuli läpi vain reilut 740Kb/s. Tämä viittaa siihen, että Juniper-coren qos-asetusten politiikka poikkeaa cisco-coren politiikasta ja kyseinen liikenne on merkattu uudestaan. Todellisuudessa Juniperin laitteistolla, kun precedence 1 arvoa ei otettu kiinni konfiguraatiossa, se heitettiin BE-luokkaan. Lopulta Centos2:lle mennyt paketti saa huonompaa palvelunlaatua, kuin mitä cisco-coren asetukset antaisivat ymmärtää. 4.5 Tehtävä 4 Valmistelut = samat Mittauslaitteistojen IP-osoitteet = samat

35 Ennen mittausta: Tutustu sekä Cisco Core- että Juniper Core laitteiden konfiguraatioihin ja miten niille on määritelty merkkaus ja jonotusmekanismit. Luo taulukko, johon arvioit paljonko mittausten liikennevuot todellisuudessa saavat kaistaa laitteiden konfiguraatioilla. Tällä tavalla tulisi ennen mittausta kotona tai koululla oikeasti tutkia ja pohtia jonojen ja merkkausten toimintaa. Samalla mittausten aikana ja viimeistään niitä dokumentoidessa alkaa todellisuus laitteiden toiminnasta hahmottumaan ja samalla sen muistaisi pitempään, kun voi joko todeta omat ennakkoluulot oikeiksi tai vääriksi. Samalla tulisi selvittää miksi asiat ei mennyt niin kuin ennalta luuli, mikäli ei mennyt. Mittaus 1 = samalla tavalla Mittaus 2 = samalla tavalla Mittaus 3 = samalla tavalla Mittauksissa olisi tosin hyvä käyttää sekä TCP, että UDP-dataa. Muun muassa FIFO suosii UDP:tä, joten olisi hauska nähdä vaikuttaako nämä protokollat mittaustuloksiin ja kuinka paljon mikäli yhtään. 5 Pohdinta Viimeinen laboratorioharjoitus oli hyvä summaamiskokemus kaikelle sille, mitä olimme aikaisemmissa laboratorioharjoituksissa itse toteuttaneet. Juniper Coren konfiguraatiot myös paljastivat, missä oma toteutuksemme oli mennyt metsään, joten saimme myös puuttuvat opit pääkoppiimme. Valmistelevat tehtävät viimeiseen labraan voisivat nostaa vielä motivaatiota ja suoritustasoa ja näistä teimmekin mittaussuunnitelmaan ehdotuksen. Nyt tieto valmiista pöydästä ja nopeat mittausten suorittamiset saattoivat hieman viedä terävintä kärkeä siitä, mitä kaikkea harjoituksesta olisi voinut saada irti.

36 Lähteet IP Precedence and DSCP values. Viitattu 06.04.2016. https://networklessons.com/quality-of-service/ip-precedence-dscp-values/ Junos QoS. 2008. Juniper Networks J-series Services Routers Quality of Service (QoS). Viitattu 20.4.2016. https://kb.juniper.net/library/customerservice/technotes/350141.pdf Kuismanen, R. & Martikainen, H. 2006. IP-verkon suorituskyvyn monitorointi heterogeenisessä ympäristössä. Tietotekniikan pro gradu tutkielma. Jyväskylän yliopisto. Viitattu 29.4.2016. http://research.jyu.fi/laila/ip_perf_gradu.pdf. Rhys Haden. Ethernet Virtual LANs (VLANs), Viitattu 03.04.2016. http://www.rhyshaden.com/eth_vlan.htm#802.1p Rhys, Haden. Quality of Service. Viitattu 6.4.2016. http://www.rhyshaden.com/qos.htm Introduction. Viitattu 03.04.2016. http://flylib.com/books/en/2.873.1.34/1/ Rahikainen, R. & Paananen, E. & Saari, H. 2016. QoS-Laboratoriaharjoitus 6. Viitattu 29.04.2016.