Mikrotik QoS: kontrola protoka i prioritetizacija saobraćaja

Ovo je jedno od najčešćih pitanja korisnika RouterOS-a, ali je jedno od težih za podešavanje ukoliko želimo ozbiljniju kontrolu i prioritetizaciju. Za osnovnu kontrolu protoka mogu se koristiti Simple Queues ali zbog jednostavnog podešavanja i postojanja dosta uputstava oni neće biti tema teksta. Takođe ako koristimo prioritete zasebno za svakog klijenta imaćemo problem sa uređajem koji će moći procesorski da obradi sva pravila u slučaju velikog broja istih (da bi došao do poslednjeg pravila mora da proveri sve prethodne).

Da bi mogli bilo šta da radimo u vezi sa QoS i prioretitazijom saobraćaja od esencijalne važnosti je poznavanje Packet Flow Diagram-a. Tu ćemo videti koja se radnja kada obavlja i znati gde možemo da markiramo saobraćaj, a zatim i gde da ga ograničimo. Nije neophodno a ni praktično znati napamet dijagram jer je komplikovan a sa novim verzjima RouterOS se može promeniti. Koristićemo dve slike dijagrama, jedna za Bridging (Layer 2, MAC) gde je deo o rutiranju uprošćen i jednu za Routing (Layer 3, IP), gde je deo o bridgingu uprošćen.

700px-Bridge_final

700px-IP_final

  • Input Interface – početna tačka za pakete koji idu kroz ruter (nije bitno da li je paket primljen na fizički ili virtuelni interfejs, on uvek počinje ovde).
  • Output Interface – poslednja tačka u toku paketa kroz ruter, trenutak pre nego što se paket pošalje van.

Sledeći dijagram ćemo koristiti za QoS:

QoS_Packet_Flow

Na ovom dijagramu vidimo da saobraćaj možemo markirati na pet mesta (Mangle Prerouting, Mangle Input, Mangle Forward, Mangle Output, Mangle Postrouting), dok ograničenje možemo vršiti na tri mesta (Global-in/Global-Total, Global-Out/Global-Total i Out-Interface/HTB (za svaki interfejs na ruteru)). Postavlja se pitanje da li ograničavati saobraćaj na Global-Out ili na HTB interfejsu? U slučaju SRC-NAT odnosno masquerade Global-Out će biti svestan privatnih IP adresa klijenata, dok HTB interfejs neće jer iz toka paketa vidimo da je HTB posle SRC-NAT.

Mangle opcija firewal-a nam dozvoljava da dodajemo neke oznake paketima, a kasnije da pomoću drugih opcija RouterOS-a vršimo rutiranje ili kontrolu protoka markiranih paketa. Obeleženi paketi su namenjeni samo tom ruteru i nije ih moguće prosleđivati drugim ruterima, dakle ako obeležimo paket u prerouting-u on će takav i biti do postrouting-a, odnosno dok ne napusti ruter. Postoje tri vrste “obeležavanja” paketa: Connection mark, Routing mark, Packet mark.

mikrotik-mangle-mark

Za potrebe kontrole protoka koristićemo Packet mark. Takođe sa mangle opcijom možemo menjati neka polja IP zaglavlja kao što su TTL (Time to Live, sprečava petlje u mreži, odnosno kruženje paketa u nedogled) ili ToS (Type of Services, ToS čini osam bita čija se funkcija tokom vremena menjala, ali u principu dozvoljava hostu da ukaže mreži koju vrstu servisa želi i poslednjom revizijom RFC dokumenata definisano je da prvih šest bitova služi za određivanje različitih nivoa kvaliteta servisa, dok se druga dva bita odnose na zagušenje saobraćaja).

HTB predstavlja Hierarchical Token Bucket i na njemu se zasniva sva kontrola protoka u RouterOS-u. On nam omogućava da se kreira struktura redosleda ograničenja i odredi odnos između samih redova. Postoje tri virtuelna HTB-a: Global-In, Global-Out i Global Total i još jedan pre svakog izlaznog interfejsa. Kada paket putuje kroz ruter on prolazi sva četiri HTB-a. Ukoliko paket ide ka ruteru prolazi samo global-in i global-total i u poslednjem slučaju kada paket ide od rutera prolazi kroz global-out, global-total i interfejs HTB što možemo i videti na poslednjem toku paketa (QoS packet flow). Neke karakteristike HTB su:

  • Kada queue ima barem jedan child queue on automatski postaje parent queue
  • Svi child queues su na istom HTB nivou
  • Child queues će prvo dobiti limit-at (ako je on podešen)  a zatim će ostatak saobraćaja da se distribuira preko parents
  • HTB ima dva limita, limit-at i max-limit, HTB će prvo pokušati da namiri svaki child limit-at, a tek zatim da pokuša dostizanje max-limit ako ima resursa
  • HTB prioriteti rade samo za child queues, parents nemaju prioritete
  • 8 je najniži prioritet, 1 je najveći
  • Queue sa većim prioritetom će prvi da ostvari max-limit
  • Prioritetizacija će raditi isključivo ako su ograničenja postavljena (ako nema limita nema razloga ni da se paketi odbacuju, a samim tim ni prioritetizacija neće raditi, jer ona ne preuređuje niz paketa već neke propušta dok druge odbacuje)
  • Prioritetizacija nema uticaja na limit-at saobraćaj

Maksimalna brzina roditeljskog reda bi trebala da bude veća ili jednaka zbiru limit-at brzina svih potomaka i maksimalna brzina bilo kog potomka bi trebala da bude manja ili jednaka maksimalnoj brzini roditeljskog reda.

Mnogi se žale da im QoS ne radi jer su stavili jedno ograničenje a na interfejsu vide veću količinu saobraćaja. To se dešava zato što je global-in posle input interfejsa i ne može ograničiti koliko će saobraćaja stići na sam interfejs (ako klijent pošalje saobraćaj on mora stići negde, ne može jednostavno nestati). Jedini način da se vidi QoS na delu je praćenje TX interfejsa “sa druge strane”. Još jedna bitna stavka je da sam QoS ne zna koliki mu je propusni opseg dostupan zato što su svi HTB pre izlaznog interfejsa koji prvi može (u većini slučajeva neće) znati koliki je propusni opseg, tj. može znati maksimalni propusni opseg ali ako je stvarni limit manji jedini način da obezbedimo QoS je da taj limit sami postavimo.

Da bi uspešno koristili queues moramo još znati i koji tip queue izabrati. Mi ćemo koristiti PCQ (Per Connection Queue) koji je unapređen od verzije 5.0RC4 (dodata je podrška za IPv6, povećane su performase i što je vrlo bitno dodat je burst). PCQ je uveden da bi se oslobodili glomaznih rešenja za QoS gde je većina queue bila ista samo za različite sub-stream-ove. Sa dva PCQ-a možemo zameniti praktično neograničen broj simple queues, kažem dva jer nam jedan treba za upload, a drugi za download saobraćaj. PCQ podržava četiri classifier-a i to po odredišnom i izvornom portu kao i po odredišnoj i izvornoj IP adresi.

mikrotik-pcq

Kada smo se upoznali sa osnovnim stvarima koje je neophodno znati da bi podesili QoS možemo preći na praktične zadatke i pitanja koja će vas najviše interesovati. U primeru koji sledi videćemo da je QoS neophodan kako za firme tako i za “obične” korisnike. Evo i kućne mreže koju ćemo obraditi:

QoS_01_blog

Koristićemo ADSL modem koji je u modu bridge i Mikrotik koji poziva pppoe konekciju, a sa  NAT / Masquarade opcijom ćemo obezbediti internet svim klijentima(ovo je i najčešći način ostvarivanja konekcije kod nas prilikom korišćenja MT). Deo uređaja nije prikazan, kao i drugi WiFi koji služi za goste a u cilju pojednostavljenog prikaza (ukoliko uspešno odradite ovaj deo apsolutno ne bi trebalo da bude problema u poboljšanju rešenja za vaše potrebe). Uređaji koji se koriste i potencijalni servisi su:

  1. desktop računar (surf, Counter-Strike, skidanje podataka, youtube…)
  2. telefon/tablet koji je preko AP konektovan na istu mrežu (skajp, e-mail, čitanje rss feed-ova)
  3. dreambox satelitski risiver (CS, youtube, surf, torrent)
  4. laptop (telnet, ssh, ftp, remote desktop…)

Kao što vidimo postoji dosta različitih servisa na samo četiri prikazana uređaja koji koriste sasvim drugačije internet protok. Ovde već vidimo da jednostavno deljenje ravnopravno protoka nema smisla, jer ako i rezervišemo određeni saobraćaj za npr Dreambox a ne podelimo ga po prioritetu, najvažniji servis, odnosno CS neće raditi u trenutku kada se skida neki torrent jer je p2p saobraćaj dosta agresivniji pa iako za CS treba par Kb/s slika na televizoru će seckati. Ovakvih “problema” možemo imati na svakom klijentu i tu na scenu stupa QoS.

Prvo pitanje koje mi klijenti i korisnici postavljaju da li se torenti mogu blokirati, a zatim sledi razočarenje kada dobiju odgovor da to nije moguće (MT uspešno poznaje p2p saobraćaj do trenutka kada on počne da se kriptuje). Većina pokušava da blokira p2p saobraćaj što nije dobar pristup već je potrebno imati drugi način razmišljanja. Prvo ćemo obeležiti sav koristan saobraćaj a zatim ga prioritetizovati i odvojiti željenu količinu protoka a sve što nam ne treba ćemo staviti na najniži prioritet ili eventualno blokirati. Postoji više načina za markiranje željenog saobraćaja, pa ćemo krenuti redom kojim bi to trebali i da radite. Prvo ćemo markiranje vršiti po portovima i IP adresama a tek nakon toga treba obeležavanje saobraćaja treba raditi po L7 pravilima (ona su procesorski najzahtevnija pa ih treba ostaviti za kraj da bi što manje saobraćaja prolazilo kroz njih, inače će svaki od trenutno dostupnih routerboard uređaja će “zakucavati” pri malo većem protoku, testirano i na RB1000, RB1100…). Ovde se nećemo baviti dodavanjem svih pravila, L7 regxp, markiranja jer bi to oduzelo dosta prostora a svodi se na jednostavne akcije ako se zna princip koji pokazujemo. Prvo ćemo markirati icmp i dns pomoću source i destination porta.

/ip firewall mangle
add action=mark-packet chain=prerouting comment="DNS - Domain Name System " \
in-interface=pppoe-out1 new-packet-mark=DNS_in passthrough=no protocol=udp src-port=53
add action=mark-packet chain=postrouting dst-port=53 new-packet-mark=dns_out \
out-interface=pppoe-out1 passthrough=no protocol=udp
add action=mark-packet chain=prerouting comment="Ping Internet Control Message Protocol" \
in-interface=pppoe-out1 new-packet-mark=icmp_in passthrough=no protocol=icmp
add action=mark-packet chain=postrouting new-packet-mark=icmp_out \
out-interface=pppoe-out1 passthrough=no protocol=icmp

Treba obratiti pažnju na protokole koji koriste i TCP i UDP kao što je slučaj sa DNS-om pa bi ovde trebalo dodati još jedno pravilo sa TCP protokolom (većina protoka će biti po UDP-u jer DNS zbog brzine primarno njega koristi, ali bez obzira treba podesiti što preciznije markiranje). Kao što vidite na dva mesta u toku paketa vršimo markiranje, jer ukoliko budemo samo koristiti prerouting onda nećemo biti u mogućnosti da kasnije u queue tree koristimo global-out interfejs. Sa prerouting markom možemo ograničiti saobraćaj na global-in i fizičkom interfejsu. Ukoliko imamo saobraćaj koji nije moguće uhvatiti pomoću porta ili L7 izraza a znamo IP odredišnu adresu možemo nju koristiti (za ovaj primer sam uzeo internet radio, a pošto sam hteo više stanica da markiram i prioritetizujem koristio sam address list opciju unutar zaštitnog zida MT-a, koja nam omogućava jedno pravilo i kasniji lakši menadžmet IP adresa).

/ip firewall address-list
add address=193.243.169.34 list=radio
add address=217.26.211.136 list=radio
add address=195.252.107.194 list=radio
add address=77.105.38.192 list=radio

A zatim i markiranje po listi odredišnih IP adresa:

/ip firewall mangle
add action=mark-packet chain=prerouting comment=Radio in-interface=pppoe-out1 \
new-packet-mark=Radio_In passthrough=no protocol=tcp src-address-list=radio
add action=mark-packet chain=postrouting dst-address-list=radio \
new-packet-mark=Radio_Out out-interface=pppoe-out1 passthrough=no protocol=tcp

Ostalo je da markiramo saobraćaj po L7 izrazima a koji nije moguće uraditi na drugi način, u ovom slučaju ćemo prikazati Skype i MSN. Prvo dodamo L7 RegEx (kompletnu listu možete naći ovde):

/ip firewall layer7-protocol
add name=msnmessenger regexp="ver [0-9]+ msnp[1-9][0-9]\? [\t-\r -~]*cvr0\r\
    \n\$|usr 1 [!-~]+ [0-9. ]+\r\
    \n\$|ans 1 [!-~]+ [0-9. ]+\r\
    \n\$"
add name=skypetoskype regexp="^..\02............."

Treba primetiti da za Skype i MSN imamo po još jedno pravilo ukoliko hoćemo da obeležimo pozive na telefon i file transfer respektivno. Sada možemo i izvršiti markiranje sa naprednom opcijom L7:

/ip firewall mangle
add action=mark-packet chain=prerouting \
comment="Skype to Skype - UDP voice call " in-interface=pppoe-out1 \
layer7-protocol=skypetoskype new-packet-mark=skype2skype_in \
passthrough=no protocol=udp
add action=mark-packet chain=postrouting layer7-protocol=skypetoskype \
new-packet-mark=skype2skype_out out-interface=pppoe-out1 \
passthrough=no protocol=udp
add action=mark-packet chain=prerouting comment="MSN Messenger " \
in-interface=pppoe-out1 \
layer7-protocol=msnmessenger new-packet-mark=msn_in passthrough=no
add action=mark-packet chain=postrouting layer7-protocol=msnmessenger \
new-packet-mark=msn_out out-interface=pppoe-out1 passthrough=no

Kada smo obeležili nama sav interesantan saobraćaj potrebno je postaviti pravila koja će markirati preostali deo protoka, naravno ona moraju biti na poslednjem mestu:

/ip firewall mangle
add action=mark-packet chain=prerouting comment=Other-Traffic-In \
in-interface=pppoe-out1 new-packet-mark=Other-Traffic-In passthrough=no
add action=mark-packet chain=postrouting comment=Other-Traffic-Out \
new-packet-mark=Other-Traffic-Out out-interface=pppoe-out1 passthrough=no

Posle toga pristupamo ograničavanju i davanju priotitata određenom tipu saobraćaja. Već smo rekli da ćemo koristiti PCQ queue type:

/queue type
add kind=pcq name=PCQ_download pcq-classifier=dst-address \
pcq-limit=150 pcq-total-limit=5000
add kind=pcq name=PCQ_upload pcq-classifier=src-address \
pcq-limit=150 pcq-total-limit=500

Dodali smo jedan za upload i jedan za download bez podešavanja burst opcije koja može biti vrlo korisna, naručito za ubrzanje klasičnog http “surfa”. Ostalo je još da podesimo queue tree za upload i download:

/queue tree
add limit-at=6M max-limit=6M name=total_adsl_down parent=global-in
add limit-at=650k max-limit=650k name=total_adsl_up parent=global-out
add limit-at=256k max-limit=3M name=skype2skype_down \
packet-mark=skype2skype_in parent=total_adsl_down priority=2 queue=PCQ_download
add limit-at=128k max-limit=512k name=skype2skype_up packet-mark=skype2skype_out \
parent=total_adsl_up priority=2 queue=PCQ_upload
add limit-at=16k max-limit=32k name=icmp_down packet-mark=icmp_in \
parent=total_adsl_down priority=1 queue=PCQ_download
add limit-at=16k max-limit=32k name=icmp_up packet-mark=icmp_out \
parent=total_adsl_up priority=1 queue=PCQ_upload
add limit-at=32k max-limit=5M name=other_down packet-mark=Other-Traffic-In \
parent=total_adsl_down queue=PCQ_download
add limit-at=16k max-limit=512k name=other_up packet-mark=Other-Traffic-Out \
parent=total_adsl_up queue=PCQ_upload

A evo kako bi to izgledalo sa malo više pravila:

IP_FireWall_QoS

Treba obratiti pažnju da je ruter tek restartovan pa zato nema obeleženog saobraćaja u svim pravilima. Sledeća slika je data kao primer, ali pošto je uzeta prilikom testiranja prioriteti i ograničenja možda nisu onakvi kakvi vama odgovaraju pa ih je potrebno promeniti u skladu sa zahtevima.

QueueTree_FireWall_QoS

Ovaj tekst bi trebalo da vam služi samo kao uvod u QoS i mogućnosti Mikrotika a kao što sam rekao, varijanti da se ovaj zadatak reši postoji dosta. Više detalja možete saznati ako poslušate neko od Janisovih predavanja vezanih za QoS.

Leave a Reply

Your email address will not be published. Required fields are marked *