HOGYAN Packet Shaping

A Gentoo Linux Wiki wikiből

HOGYAN

Telepítési módok -- Portage -- Kernel és rendszerindítás -- Hálózat -- X-szel kapcsolatos -- Egyéb

Ez a leírás az angol nyelvű Gentoo Wiki-ből lett átemelve.

[szerkesztés] Bemutatkozás

Ahogy erről beszélünk a peer-to-peer programok egyre népszerűbbek lesznek. Ezek a programok telítik az internet kapcsolatokat, és megnehezítik más forgalmakat átjutását a kapcsolaton keresztül. Ha egy felhasználó lefoglalja az egész sávszélességet, akkor az internet böngészés is könnyen kínszenvedéssé válhat. Olyan programok mint a bittorrent és más P2P kliensek többnyire a kapcsolatunk feltöltési részét telítik és bár a kliensek képesek limitálni a feltöltési sebességet, mégsem teszik mindig. A megoldás a forgalom szabályzás.

[szerkesztés] A Megoldás

Mielőtt nekiállnánk előbb megkell értenünk mi az a sorbanállás (queueing). Ez a magyarázat erősen leegyszerűsített, de megérthető benne az egész lényege. Felállásunk most egy 2048/128 sebességű internet kapcsolat, egy linuxos gép két ethernet kártyával, valamint egy hálózat néhány klienssel.

• A DSL-modem belső ip címe: 192.168.2.1
• A linuxos gép ip címei: eth0 192.168.1.1, eth1 192.168.2.2 és 192.168.2.1 az átjáró
• A kliensek a következő címekkel rendelkeznek: 192.168.1.16, 192.168.1.17, 192.168.1.18 és 192.168.1.1 az átjárójuk (tehát a linuxos gép)

A következő folyamat játszódik le amikor egy kliens egy csomagot küld az internet felé:

• A csomag elhagyja a klienst (192.168.1.16)
• A csomag megérkezik az átjáró eth0 interfészére (192.168.1.1)
• Az átjáró a csomagot átereszti és berakja a kimenő sorba (output queue)
• A csomag elhagyja az átjárót az eth1-en keresztül (192.168.2.2)
• A csomag megérkezik a DSL-modemre (192.168.2.1)
• A csomag belép a DSL-modem kimenő sorába
• A csomag elhagyja a DSL-modemet

Fontos, hogy megértsük ennél a lépésnél, hogy mi a különbség a sávszélesség és a késleltetés között. A késleltetés az az időtartam amennyire szüksége van egy csomagnak ahhoz, hogy A pontból B pontba jusson. A szávszélesség pedig az az adatmennyiség amely A pontból érkezik B-be adott idő alatt. Tehát ha egy szótárat átvinnék a város másik végén lakó barátomhoz a sávszélességem jó lenne, de a késleltetésem elég rossz lenne (hogy pontosak legyünk, az utazással töltött idő). Azonban ha felhívnám a barátom telefonon és elkezdeném felolvasni neki a szótárt, a késleltetésem jó lenne, de a sávsélességem az első példánál is kevesebb lenne. Továbbá fontos megjegyezni, hogy a sávszélesség és a késleltetés nem kapcsolódnak közvetlenül. Ha ugyanannyi időbe kerülne nekem felolvasni a szótárt, mint átutazni vele a városon, akkor a sávszélességem mindkét esetben ugyanannyi lenne. Azonban a késleltetés nem változna meg!

Vissza a DSL-modem példához. Ahogy már tudjuk a DSL-modem feltöltési sebessége csak 128kbit. Ez azt jelenti, hogy a modem másodpercenként csak 128kbits adatot képes küldeni (sávszélesség). Ha az átjáró ennél több adatot küld, akkor azok egy vonalban a kimenő sorba kerülnek és kivárják a sorukat míg elküldésre kerülnek, létrehozva egy várólistát. Ekkor az történik, hogy a DSL modem kimenő sora megtelik. Ha egy csomagnak 5 másodpercre van szüksége, hogy a sor legaljáról a legtetejére kerüljön, akkor a késleltetésünk 5 másodperc lesz. Ez rosz az interaktivitásnak.

Mivel nincs befolyásunk a DSL-modem működésére ezért a sort a DSL-modemről előre kell hoznunk a linuxos gépre. A linuxos gépen az eth1 kimenő sebességét lecsökkentve a DSL-modem feltöltési sebességénél kicsivel alacsonyabbra, elérhetjük, hogy a csomagok a linuxos gépen kerülnek a várakozósorba mielőtt átkerülnének a DSL-modemre, amelynek így üres lesz a kimenő sora, tehát a beeső csomagokat remélhetőleg rögvest kézbesíteni tudja az Internet felé.

Amint a várólista sor átkerül a linuxos gépre, képesek leszünk beavatkozni, képesek leszünk szabályozni.

[szerkesztés] Előfeltételek

Nos sokmindenre nem lesz szükségünk. Egy számítógép amelyen fut gentoo/linux, és kettő hálózati csatolóval rendelkezik. A szerzőnek sikerült gond nélkül futtatnia egy 200 MHz-es gépen és úgy gondolja ennél lassabb is képes megbírkózni a feladattal.

[szerkesztés] Kernel

Először is szerezd be a legutóbbi 2.4-es vagy 2.6-os kernelt és rakd a /usr/src könyvtárba, majd készíts egy szimbolikus linket róla /usr/src/linux néven.

Ha 2.4-es kernelt használsz, szükséged lesz a POM patchekre a http://netfilter.org/ oldalról, amivel meg kell foltozni a kernelt. A jelszó: cvs. (cvs-en keresztüli hozzáférés jelen pillanatban nem működik...)

 cvs -d :pserver:cvs@pserver.netfilter.org:/cvspublic login
 cvs -d :pserver:cvs@pserver.netfilter.org:/cvspublic co netfilter/userspace netfilter/patch-o-matic
 ./netfilter/patch-o-magic/runme extra

Ha kész vagy a patcheléssel, akkor még néhány módosítást kell eszközölnöd a kernelben. Ha az alábbi opció nem létezik, akkor alkalmazd a POM patchet mégegyszer.

Networking options  --->
  QoS and/or fair queueing  --->
    [*] QoS and/or fair queueing
    <M>   HTB packet scheduler
    <M>   SFQ queue
    [*]   QoS support
    [*]     Rate estimator
    [*]   Packet classifier API
    <M> Firewall based classifier
    [*] Traffic policing (needed for in/egress)
  IP: Netfilter Configuration  --->
    <M> Connection tracking (required for masq/NAT)
    <M> IP tables support (required for filtering/masq/NAT)
    <M>   limit match support
    <M>   MAC address match support
    <M>   Packet type match support
    <M>   netfilter MARK match support
    <M>   Multiple port match support
    <M>   TOS match support
    <M>   random match support
    <M>   recent match support
    <M>   ECN match support
    <M>   DSCP match support
    <M>   AH/ESP match support
    <M>   LENGTH match support
    <M>   TTL match support
    <M>   tcpmss match support
    <M>   Helper match support
    <M>   Connection state match support
    <M>   Connection mark match support
    <M>   Connection tracking match support
    <M>   Unclean match support (EXPERIMENTAL)
    <M>   Owner match support (EXPERIMENTAL)
    <M>   Packet filtering
    <M>     REJECT target support
    <M>     MIRROR target support (EXPERIMENTAL)
    <M>   Full NAT
    <M>     MASQUERADE target support
    <M>     REDIRECT target support
    <M>     Basic SNMP-ALG support (EXPERIMENTAL)
    <M>   Packet mangling
    <M>     TOS target support
    <M>     ECN target support
    <M>     DSCP target support
    <M>     MARK target support
    <M>   LOG target support
    <M>   CONNMARK target support
    <M>   ULOG target support
    <M>   TCPMSS target support
    <M> ARP tables support
    <M>   ARP packet filtering
    <M>   ARP payload mangling

Device Drivers  --->
  Networking support  --->
    Networking options  --->
      QoS and/or fair queueing  --->
        <M>   HTB packet scheduler
        <M>   SFQ queue
        [*]   QoS support
        [*]     Rate estimator
        [*]   Packet classifier API
        <M> Firewall based classifier
        [*] Traffic policing (needed for in/egress)
      [*] Network packet filtering (replaces ipchains)  --->
        IP: Netfilter Configuration  --->
          <*> Connection tracking (required for masq/NAT)
          <*> Userspace queueing via NETLINK
          <*> IP tables support (required for filtering/masq/NAT)
          <*>   limit match support
          <*>   IP range match support
          <*>   MAC address match support
          <*>   Packet type match support
          <*>   netfilter MARK match support
          <*>   Multiple port match support
          <*>   TOS match support
          <*>   recent match support
          <*>   ECN match support
          <*>   DSCP match support
          <*>   AH/ESP match support
          <*>   LENGTH match support
          <*>   TTL match support
          <*>   tcpmss match support
          <*>   Helper match support
          <*>   Connection state match support
          <*>   Connection tracking match support
          <*>   Owner match support
          <*>   Packet filtering
          <*>     REJECT target support
          <*>   LOG target support
          <*>   ULOG target support
          <*>   TCPMSS target support
          <*>   Full NAT
          <*>     MASQUERADE target support
          <*>     REDIRECT target support
          <*>     NETMAP target support
          <*>     SAME target support
          <*>   Packet mangling
          <*>     TOS target support
          <*>     ECN target support
          <*>     DSCP target support
          <*>     MARK target support
          <*>     CLASSIFY target support
          <M>   raw table support (required for NOTRACK/TRACE)
          <M>     NOTRACK target support
          <*> ARP tables support
          <*>   ARP packet filtering
          <*>   ARP payload mangling

A beállítások kicsit máshova kerültek. Itt van, hogy engedélyezd.

Networking  --->
  Networking options  --->
    [*] Network packet filtering (replaces ipchains)  --->
      IP: Netfilter Configuration  --->
        <*> Connection tracking (required for masq/NAT)
        <*> Userspace queueing via NETLINK
        <*> IP tables support (required for filtering/masq/NAT)
        <*>   limit match support
        <*>   IP range match support
        <*>   MAC address match support
        <*>   Packet type match support
        <*>   netfilter MARK match support
        <*>   Multiple port match support
        <*>   TOS match support
        <*>   recent match support
        <*>   ECN match support
        <*>   DSCP match support
        <*>   AH/ESP match support
        <*>   LENGTH match support
        <*>   TTL match support
        <*>   tcpmss match support
        <*>   Helper match support
        <*>   Connection state match support
        <*>   Connection tracking match support
        <*>   Owner match support
        <*>   Packet filtering
        <*>     REJECT target support
        <*>   LOG target support
        <*>   ULOG target support
        <*>   TCPMSS target support
        <*>   Full NAT
        <*>     MASQUERADE target support
        <*>     REDIRECT target support
        <*>     NETMAP target support
        <*>     SAME target support
        <*>   Packet mangling
        <*>     TOS target support
        <*>     ECN target support
        <*>     DSCP target support
        <*>     MARK target support
        <*>     CLASSIFY target support
        <M>   raw table support (required for NOTRACK/TRACE)
        <M>     NOTRACK target support
        <*> ARP tables support
        <*>   ARP packet filtering
        <*>   ARP payload mangling
    QoS and/or fair queueing  --->
      <M>   HTB packet scheduler
      <M>   SFQ queue
      [*]   QoS support
      [*]     Rate estimator
      [*]   Packet classifier API
    <M> Firewall based classifier
    [*] Traffic policing (needed for in/egress)

Fordítsd le a kernel, telepítsd és bootold be.

[szerkesztés] Szabályzási stratégia

Ha egy csomag beérkezik, az iptables segítségével több dolgot is tudsz csinálni vele. Álljon itt néhány példa, hogy mi alapján tudsz szabályozni:

• Port
• Csomag méret
• Forgalom típusa

Mondjuk szeretnél a bittorrentnek alacsonyabb prioritást adni. Tudjuk, hogy a 6881-tól 6889-ig terjedő portokat használja. Iptables-szel könnyen nyomonkövethetjük ezt, de amint a felhasználó rájön, hogy ezeknek a portoknak alacsonyabb prioritásuk van, egyszerűen átállítja a bittorrentet, hogy más portokat használjon. Nincs SEMMILYEN LEHETŐSÉG arra, hogy megtudjuk a P2P programok milyen portokat használnak.

A csomag méret alapján történő szabályzásnak is vannak előnyei. A kisebb csomagoknak magasabb prioritást tudsz adni, mint a nagyobb csomagoknak. Mivel sok adatot küldeni célszerű nagyméretű csomagok formájában küldeni, nem meglepő, hogy a P2P programok is így tesznek. De ismét, a kliens megváltoztathatja az MTU értékét a kimenő interfészen, így kisebb csomagokat küldve megkerülheti a szabályzást.

Amit igazából szeretnénk, az hogy felismerjük a csomagokat tartalmuk alapján. Szükségünk van arra, hogy az iptables belenézzen minden egyes csomagba és analizálja a tartalmát, hogy kiderítse vajon P2P programtól származik vagy sem. Jelenlegi állás szerint két projektről tudok, amely képes erre.

• ipp2p http://www.ipp2p.org
• l7-filter http://l7-filter.sourceforge.net/

Mindkettő jó projekt, én csak a ipp2p-t használom. Eddig csak bittorrenten alkalmaztam és remekül működik. Lesd meg az utolsó részt bővebb infókért vagy kövesd a linkeket.

[szerkesztés] Priorizálás

Ebben a hogyanban négy prioritási szintet fogunk létrehozni:

1. Interaktív
2. Egyéb
3. Böngészés
4. P2P

• Interaktívat a kisméretű csomagokhoz használjuk, amelyeknek nagyon alacsony késleltetésre van szükségük. Ilyen csomagok lehetnek például az icmp vagy ssh csomagjai. (ez magában foglalja a ACK-s TCP csomagokat is)

• Egyebet azoknak a csomagoknak, amelyek egyik kategóriába se fértek be.

• Böngészést azoknak a csomagoknak, amelyeknek alacsonyabb késleltetés szükséges a P2P csomagokénál, de nem igazán szabadna nagyobb prioritást élvezniük az ssh-nál. Ez lehet például http vagy smtp.

• P2P-t a P2P programoknak illetve olyan programoknak, amelyek sok adatot akarnak feltölteni. Ezek a lehető legkisebb prioritást kapják.

Jegyezzük meg, hogy például ha a P2P-nek alacsonyabb prioritást adunk mint a Böngészésnek, az nem jelenti azt, hogy a P2P kevesebb sávszélességet is kapna. Annyit jelent, hogy a rendszer előnyben részesíti a Böngésző csomagjait a P2P csomagjainál. Csak ha kitöltötted a feltöltési streamet, akkor rughat labdába a P2P a rendelkezésre álló sávszélességgel.

Átgondolhatod, hogyan használod a hálózatodat és a prioritásokat annak megfelelően definiálhatod, vagy megváltoztathatod a sorrendet, de ez a példa mindenféleképpen egy jó kiindulási alapot jelent.

[szerkesztés] Iptables

Gondolom már nem okozok meglepetést, hogy iptables-re lesz szükségünk:

 emerge net-firewall/iptables

Arra fogjuk használni az iptables-t, hogy megjelöljük a csomagokat a későbbi szabályzás érdekében. Azonban előbb egy alap NAT-os routert kell beállítanunk. Ez a beállítás egyátalán NEM biztonságos, ez csupán csak egy példa, amely bemutatja, hogyan állítsunk be NAT-ot:

# Konstansok
LOCALNET="192.168.1.0/255.255.255.0"

# Policy beállítása (az alapértelmezett policy az ACCEPT, így nem igazán
# van szükséged erre a részre, hacsak nem állítottad az alap policyt DROP-ra;
# utóbbi NEM ajánlott más láncra kivéve az INPUT és FORWARD láncokra
# a filter táblában és ESETENKÉNT az OUTPUT láncon)
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P PREROUTING ACCEPT

# Összes tábla kiürítése
iptables -t filter -F
iptables -t mangle -F
iptables -t nat    -F
iptables -t raw    -F # (opcionális)

# Maszkolás
iptables -t nat -A POSTROUTING -s $LOCALNET -o eth1 -j MASQUERADE
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -d $LOCALNET -j ACCEPT

# Kernel forward engedélyezése
echo 1 > /proc/sys/net/ipv4/ip_forward

Mégegyszer, nem igazán ajánlom, hogy a fenti scriptet használd. Csak a teljesség érdekében raktam be. Jobban teszed ha elolvasod a "Linux 2.4 alapos tűzfal tervezés"(jó a 2.6-os kernelhez is) leírást a gentoo.org-on, amely végigvezet egy megfelelően biztosított tűzfal létrehozási folyamatán.

A Shorewall pedig egy olyan csomag amely bekonfigurálja az iptables-t neked. Ajánlott ezt használni (vagy valami hasonlót) ha nem szeretnél könyékig turkálni az iptables szintakszisában.

Következő lépés a csomagok megjelölése a prioritásokkal:

MARKPRIO1="1"
MARKPRIO2="2"
MARKPRIO3="3"
MARKPRIO4="4"

# Prioritás jelek beállítása

# Prio 1
# icmp
iptables -t mangle -A FORWARD -p icmp -j MARK --set-mark $MARKPRIO1
iptables -t mangle -A OUTPUT -p icmp -j MARK --set-mark $MARKPRIO1
# ssh
iptables -t mangle -A FORWARD -p tcp --dport 22 -j MARK --set-mark $MARKPRIO1
iptables -t mangle -A OUTPUT -p tcp --dport 22 -j MARK --set-mark $MARKPRIO1
# nem tcp
iptables -t mangle -A FORWARD -p ! tcp -j MARK --set-mark $MARKPRIO1
iptables -t mangle -A OUTPUT -p ! tcp -j MARK --set-mark $MARKPRIO1

# Prio 2

# Prio 3
# http
iptables -t mangle -A FORWARD -p tcp --dport 80 -j MARK --set-mark $MARKPRIO3
iptables -t mangle -A OUTPUT -p tcp --dport 80 -j MARK --set-mark $MARKPRIO3
# https
iptables -t mangle -A FORWARD -p tcp --dport 443 -j MARK --set-mark $MARKPRIO3
iptables -t mangle -A OUTPUT -p tcp --dport 443 -j MARK --set-mark $MARKPRIO3
# smtp
iptables -t mangle -A FORWARD -p tcp --dport 25 -j MARK --set-mark $MARKPRIO3
iptables -t mangle -A OUTPUT -p tcp --dport 25 -j MARK --set-mark $MARKPRIO3

# Prio 4
# packets > 1024 bytes
iptables -t mangle -A FORWARD -p tcp -m length --length 1024: -j MARK --set-mark $MARKPRIO4
# bittorrent
iptables -t mangle -A FORWARD -i eth0 -p tcp --sport 6881:6889 -j MARK --set-mark $MARKPRIO4
iptables -t mangle -A FORWARD -i eth0 -p tcp --dport 6881:6889 -j MARK --set-mark $MARKPRIO4

# A kimaradt csomagokat pedig megjelöljük a TOS-nek megfelelően ('''T'''ype '''O'''f '''S'''ervice)
iptables -t mangle -A FORWARD -p tcp -m tos --tos Minimize-Delay -m mark --mark 0 -j MARK --set-mark $MARKPRIO1
iptables -t mangle -A FORWARD -p tcp -m tos --tos Maximize-Throughput -m mark --mark 0 -j MARK --set-mark $MARKPRIO2
iptables -t mangle -A FORWARD -p tcp -m tos --tos Minimize-Cost -m mark --mark 0 -j MARK --set-mark $MARKPRIO4

Magyarázatok és megjegyzések:

• -t mangle: Szeretnénk módosítani (mangle) a csomagokat, azzal, hogy megjelöljük őket.
• -A FORWARD/OUTPUT: A szabály láncok, amelyen a csomagok átutaznak. Az OUTPUT ahol a csomagok kilépnek ebből a gépből, míg a FORWARD amin keresztül más gépeknek küldünk csomagokat
• -p icmp: csak icmp csomagok (ugyanez tcp-re stb.)
• -p ! tcp: csomagok amelyek nem csak tcp-k. Jegyezzük meg, hogy az icmp sem tcp, most mégis külön kezeljük. Ez valójában szükségtelen, de növeli az olvashatóságot
• -dport 22: Egyezés (tcp, nyílvánvalóan) azokra a csomagokra amelyek a 22 portra mennek (cél port)
• -j MARK --set-mark $MARKPRIO1: -j jelöli azt a műveletet amelyet alkalmazni akarunk, és a --set-mark jelzi az iptables-nek mivel jelöljön
• -m tos --tos ... : Egyezés a csomag tos-se szerint

• -m mark --mark 0: Egyezik azokra a csomagokra, amelyek még nem lettek megjelölve
• A mellékelt bittorrent példa valószínűleg nem fog úgy működni, ahogy kellene. Ezenkívül fixen bedrótozzuk az eth0 interfészt, hogy a DSL modem felől 6881-6889 portokon érkező átmenő forgalmat megjelöljük, azonban fontos megjegyezni, hogy a bittorrent nem mindig a 6881-6889 portokat használja. Nézd meg a layer7 és ipp2p programokat, velük könyebben megoldhatod ezt a problémát.

Alternatív módszer: CLASSIFY target

Ahelyett, hogy a MARK célt használnánk a FORWARD vagy OUTPUT láncokon, használhatjuk helyette a CLASSIFY célt is a POSTROUTING láncban. A következő egy példa a kimenő ssh forgalom osztályozására (22-es port) a HTB 1:101 osztályba (magas prioritást jelent, ahogy későbbiekben is láthatod ebben a hogyanban):

iptables -t mangle -A POSTROUTING -p tcp --sport 22 -j CLASSIFY --set-class 1:101

Bővebb információkat a CLASSIFY célról az alábbi hivatkozáson találhatsz:

Iptables Tutorial: CLASSIFY Target

[szerkesztés] A HTB megértése

Valójában mit is csinál a HTB? HTB egy rendszer, amely szétosztja a sávszélességet különálló sorokra. Fontos emlékezni arra, hogy a HTB azért készítették, hogy garantálja a sávszélességet, és NEM arra, hogy garantálja az interaktivitást. A HTB nem számolja a csomagokat, hanem byteokat számol! Ezért szükséges némi okoskodás, hogy kicsikarjuk belőle az interaktivitást. Álljon itt egy rövid magyarázat a belső működéséről.

[szerkesztés] Qdisc-ek

Qdisc a Queue Discipline rövidítése, amely egy speciális stratégiát takar, amellyel a várósorokat lehet menedzselni. Egy sor a postán és egy sor a kórházban ugyanúgy sorok abban az értelemben, hogy "elemek" sorát alkotják, de a stratégia (vagy qdisc) amelyet a menedzselésükhöz használnak teljesen különbözőek.

A legegyszerűbb qdisc a pfifo, amely egy sima FIFO tároló, amely nem végez feldolgozást, csak tárolást, amikor a hálózati csatoló leterhelt.

[szerkesztés] Classes (Osztályok)

Egy HTB Qdisc a csomagokat osztályokba rendezi szűrők segítségével. A mi példánkban szűrőként a megjelöléseket fogjuk használni. Minden osztály egy várólista, amely egy saját menedzsert használ (SFQ a példánkban). Úgy gondolhasz az osztályokra mint ajtókra, amin keresztűl halad a sávszélesség. Be kell "terelned" a forgalmat a megfelelő ajtóba, amely limitálja majd azt a fajta forgalmat.

[szerkesztés] Rates (Ráták)

A ráta az a sávszélesség mennyiség, amelyet egy qdisc garantál. Például egy ideális világban a 128kbit/s feltöltési ráta azt jelentené, hogy az internet szolgáltató (ISP) mindig legalább ennnyi sávszélességet ad nekünk, vagy többet ha elérhető

[szerkesztés] Ceil

"Ceil" (Bandwidth Ceiling) az a maximum sávszélesség mennyiség amivel egy qdisc rendelkezhet. Az előző példa folytatásaként, egy valós világban, a 128kbit/s "feltöltési ráta" valójában azt jelenti, hogy az ISP beállított egy limitet, a maximum szávszélességet amelyet használhatunk, még ha több is elérhető lenne.

[szerkesztés] Bursts

Két féle burst létezik - burst, és cburst.

A "burst" olyan bájtban megadott mennyiség, amennyivel egy qdisc túlléppheti a rátáját, míg a "cburst" ugyanezt jelöli, csak a ceil túllépésekor.

A burst az a bájt mennyiség, amelyet az osztály számára engedélyezünk, hogy a ceil sebességén küldjön. Fontos emlékezni arra, hogy a ceil egy "ráta" tehát bytes/sec-ben mérik, míg a burst egy bájtban mért mennyiség. Úgy is tekinthetsz a burstre mint egy kosár méretre, ekkor a ceil az a maximum amennyivel kivehetsz tokeneket a kosárból, a ráta pedig az a sebesség amennyivel a kosár újratöltődik. Tehát ha van egy 5000-es burst értékünk, a rátánk 1000, a ceil értékünk pedig 2500, akkor képesek leszünk fenntartani egy 1000 bytes/sec kapcsolatot, így amikor valamely ponton hirtelen "megszaladt" adat érhető el, képesek leszünk azt 2500-tel elküldeni (5000/2500=) 2 másodpercen keresztül. Miután a "kosár" kiürült, elkezd újratöltődni 1000 bytes/sec sebességgel.

[szerkesztés] Quantum

A quantum az a bájt mennyiség, amennyit egy osztály még elküldhet, ha már elérte az előre bekonfigutált rátáját. Ennek az értéknek nagyobbnak kell lennie 1500-nél (MTU) és kisebbnek 60000-nél. Ez az érték felülbírálható, ha egy htb osztályt hozzáadunk. A Quantum lényegében leírja azt, hogy a sávszélesség hogyan oszlik el a qdisc-ek között. Körülbelül így működik:

Tételezzük fel, hogy van két osztályunk azonos szülővel:

• Szülő : ceil = rate = 100
• osztály 1 : rate = 40 és ceil = 100
• osztály 2 : rate = 20 és ceil = 100

(a megadott számok csak tájékoztató jellegűek, a megértést segítik)

Mindkét osztály annyi adatot küld, amennyit csak bír. Először engedélyezve van nekik, hogy elég csomagot küldjenek ahhoz, hogy kitöltsék a beállított rátát, függetlenül az esetleg különböző beállított prio-knak. De a szülőnek van még maradék sávszélessége : 100 - 40 - 20 = 40. A maradék sávszélesség a quantumoknak megfelelően oszlik szét. Mindegyik osztály "quantum" mennyiségű bájtot küldhet felváltva.

A quantumokat ekkor rátaként számítják ki.

• Az összes qdisc összes quantumja összeadódik és az összeget jegyzik meg
• Mindegyik qdisc a prioritását az következő képlet alapján kapja <math>\frac{quantum}{sum}</math>

Ezt akkor használjuk amikor két qdisc-ed van ugyanakkora rátával és ceil értékkel, de különböző prioritást akarsz adni nekik.

SFQ használatakor, az adatmennyiséget bájtokban mérik, nem csomagokban, ezért a quantum érték megegyezik azzal a bájt mennyiséggel, amennyit az adott qdisc engedélyezett elküldeni egy körben.

[szerkesztés] r2q

Az r2q értéket használják a quantumok kiszámításához. Az alapértelmezett értéke: 10. A quantum rate-ként kerül kiszámításra (bájtban) / r2q. Ez felülbírálható, ha hozzáadunk egy htb qdisc-et.

1. ábra

[szerkesztés] Prio

Pont azt jelenti, ahogy hangzik. Rendeljünk prioritásokat az osztályokhoz. Ez határozza meg azt a sorrendet, ahogy az osztályok több sávszélsséget kérhetnek a szülőtől miután már az előre beállított rátán forgalmaztak. Minél kisebb a szám, annál nagyobb a prioritás. A legalacsonyabb prio érték kapja a legkisebb késleltetést. De ha az alacson prio-val rendelkező osztály több adatot küld a beállított rátánál, akkor a késleltetés növekedni fog. Prio értéke 0 és 7 között változhat.

[szerkesztés] Az SFQ megértése

Egy megjegyzendő dolog, hogy az SFQ önmagában is remek munkát végez azzal, hogy eloszt "mindent" mindenféle konfigurálás nélkül.

A legjobb ha az SFQ qdisc-eket ugyanolyan adattípusú osztályokhoz csatoljuk, pl. HTTP forgalmat, hogy elkerüljük a különböző típusú adatfolyamok közötti elosztást.

"Csomagok átvitelét ütemezi, 'folyamokon' alapján."

"A cél az, hogy biztosítsák a korrektséget, így mindegyik folyam képes adatokat küldeni felváltva, ezáltal meggátolva, hogy egyetlen folyam leszívja az egész sávszélességet."

http://lartc.org/manpages/tc-sfq.html

[szerkesztés] Iproute2

A HTB beállításához szükséged lesz az iproute2-re.

emerge sys-apps/iproute2  

Valójában a tc nevű programra van szükséged, az viszont az iproute2 csomagban található meg.

Futtasd ezt a szkriptet, hogy létrehozd a 4 qdisc-et és beállítsad őket:

#Konstansok

# Interfész, amelyiken szabályozni akarsz:
# eth2, eth1 a közvetlen kapcsolatokhoz; ppp0 vagy hasonló a DSL-hez
# és más betárcsázós kapcsolathoz (lásd ifconfig kimenetét)
IFACE=eth2

# Prioritás jelzők
MARKPRIO1="1"
MARKPRIO2="2"
MARKPRIO3="3"
MARKPRIO4="4"

# Ráták (a qdics-ek számára elérhető maximális sávszélesség)
UPRATE="152kbit"
#P2PRATE=$UPRATE
P2PRATE="128kbit"
PRIORATE1="65kbit"
PRIORATE2="46kbit"
PRIORATE3="27kbit"
PRIORATE4="8kbit"

# Quantum (adott qdisc által egy körben elküldhető adatok mennyisége)
QUANTUM1="12187"
QUANTUM2="8625"
QUANTUM3="5062"
QUANTUM4="1500"

# Burst
BURST1="6k"
BURST2="4k"
BURST3="2k"
BURST4="0k"
CBURST1="3k"
CBURST2="2k"
CBURST3="1k"
CBURST4="0k"

#reset (töröljük a meglévő qdisc-te)                                                                                                                                                 
tc qdisc del dev $IFACE root htb 

# Várólista hosszának beállítása IFACE számára
# (ezzel veszi át a belső interfész a várósort, ezáltal kicsit lassabb lesz az áteresztőképessége az eth0-nál)
ifconfig $IFACE txqueuelen 16

# queue discipline specifikálása (lásd r2q megjegyzést)
tc qdisc add dev $IFACE root handle 1:0 htb default 103 r2q 1

# Osztályok deklarálása
# root osztály megadása (ez rendelkezik a net kapcsolat maximumával)
tc class add dev $IFACE parent 1:0 classid 1:1 htb rate $UPRATE burst $BURST1 cburst $CBURST1
# alosztályok megadása (1:1 osztály ID szülőosztálynak az alosztályai -> fa szerkezetet képzeljünk el)
tc class add dev $IFACE parent 1:1 classid 1:101 htb rate $PRIORATE1 ceil $UPRATE quantum $QUANTUM1 burst $BURST1 cburst $CBURST1 prio 0
tc class add dev $IFACE parent 1:1 classid 1:102 htb rate $PRIORATE2 ceil $UPRATE quantum $QUANTUM2 burst $BURST2 cburst $CBURST2 prio 1
tc class add dev $IFACE parent 1:1 classid 1:103 htb rate $PRIORATE3 ceil $UPRATE quantum $QUANTUM3 burst $BURST3 cburst $CBURST3 prio 2
tc class add dev $IFACE parent 1:1 classid 1:104 htb rate $PRIORATE4 ceil $P2PRATE quantum $QUANTUM4 burst $BURST4 cburst $CBURST4 prio 3

# Csomagok szűrése
tc filter add dev $IFACE parent 1:0 protocol ip prio 0 handle $MARKPRIO1 fw classid 1:101
tc filter add dev $IFACE parent 1:0 protocol ip prio 1 handle $MARKPRIO2 fw classid 1:102
tc filter add dev $IFACE parent 1:0 protocol ip prio 2 handle $MARKPRIO3 fw classid 1:103
tc filter add dev $IFACE parent 1:0 protocol ip prio 3 handle $MARKPRIO4 fw classid 1:104

# queuing discipline-ek hozzáadása
tc qdisc add dev $IFACE parent 1:101 sfq perturb 16 quantum $QUANTUM1
tc qdisc add dev $IFACE parent 1:102 sfq perturb 16 quantum $QUANTUM2
tc qdisc add dev $IFACE parent 1:103 sfq perturb 16 quantum $QUANTUM3
tc qdisc add dev $IFACE parent 1:104 sfq perturb 16 quantum $QUANTUM4

[szerkesztés] l7-filter

A L7-filter sokkal általánosabb osztályozó próbál lenni mint a ipp2p. A minta definíciók user space-ben tárolódnak, szóval kernel újrafordítás nélkül lehet őket módosítani. Ahogy feljebb is említettem, nem próbáltam a l7-filter-t. Ettől függetlenül telepítheted őket:

emerge l7-protocols
emerge l7-filter

Amint telepítve van, megkell tanulnod, hogyan állítsd be őket és írd meg a tapasztalataidat ebbe a hogyanba ;-)

Miután telepítetted a l7-filter-t, tedd a következőt

echo "net-firewall/iptables extensions" >> /etc/portage/package.use
emerge --newuse iptables

A megosztott objektumok eléréséhez szükséges használni a l7-filter-t. Továbbá aktiválni kell a l7 egyezést a kerneledben (pl. modulként)

Device Drivers -->
 [*] Network support
   Network options -->
    [*] Network packet filtering -->
      IP: Netfilter configuration -->
       [*]   Connection tracking flow accounting
       <M> FTP protocol support
       <M> Userspace queueing via NETLINKa
       <M> Layer 7 match support (EXPERIMANTAL)

Utána újra kell fordítanod a kernelt (pl. genkernellel):

genkernel --no-clean --no-mrproper all

Ezekután hozzá kell adni a szabályokat. De légy óvatos, úgy kell a szabályokat hozzáadni, hogy a csomagok mindkét irányban áthaladjanak a l7-filter szabályon. Ez azt jelenti, hogy benne kell lennie az INPUT-ban és az OUTPUT-ban is. Ez az egyik legtrükkösebb dolog amit megkell oldanod ;-)

Itt egy példa aminek működnie kell.

iptables -t filter -A INPUT -m layer7 --l7proto edonkey -j ACCEPT
iptables -t filter -A OUTPUT -m layer7 --l7proto edonkey -j ACCEPT

Vagy azoknak a rendszergazdáknak, akik egyátalán nem akarnak p2p-t engedélyezni:

iptables -t filter -A FORWARD -m layer7 --l7proto edonkey -j DROP

Ez veszélyes, mert van esély fals pozitív esetre, amikor hasznos forgalmat dobunk el. Olvasd el a l7-filter oldalán a protokollok részt, hogy képben legyél arról, hogy vállalod-e a rizikót vagy sem. Biztonságosabb a sávszélességet limitálni helyette. Először jelöljük meg a csomagokat:

iptables -t mangle -A FORWARD -m layer7 --l7proto edonkey -j MARK --set-mark 123

Aztán használjuk a tc-t hogy elkapjuk az egyezéseket.

Bővebb információkért http://l7-filter.sourceforge.net

Jó szórakozást.

Emlékeztető: l7-filter nem működik a hardened-sources 2.6.11-r15-val.

[szerkesztés] Tesztelés

[szerkesztés] Grafikonok

Mostanra készek vagyunk, azonban vajon működik is? Ez valóban jó kérdés. Hogy megválaszoljam, készítettem egy perl szkriptet, amely néhány grafikont rajzol ki. Ezt mindig futtatom a szerveremen, ahol meg is nézheted a saját szemeddel a grafikonokat és le is töltheted a szkriptet script

A szkriptnek szüksége van a gnuplot-ra a grafikonok rajzolásához

emerge media-gfx/gnuplot

Szerkesztheted is a szkriptet, beállíthatod hogy mekkora időközönként rajzolja ki a grafikonokat és azt is, hogy hány grafikont rajzoljon meg. Valójában nem igényel webszervert, de a legjobban úgy működik ha van webszerver is.

[szerkesztés] Feltöltési ráta beállítása

Egyik legfontosabb dolog, hogy a feltöltési rátánkat megfelelően állítsuk be. Ha túl magasra állítod, akkor a várósor a linuxos gépről a DSL modemre megy át. Ha túl alacsonyra állítod, akkor nem használod ki a sávszélességed. Pontosan megfelelőnek kell lenni.

Így teszteld:

• Izzíts be egy bittorrent-et
• Kezdj el pingelni egy szervert
• Ssh-val lépj be egy szerverre

Most figyeld meg a ping időket miközben állítod a feltöltési rátádat bittorretben. Próbálj beírni valamit közben az ssh sessionba. Ígérem rögtön látni fogod, ha a feltöltési rátád túl magas.

Végül tesztként futtass le egy játékot, pl. Enemy Territory. A játékok az interaktivitás érdekében rengeteg kisméretű csomagot kell elküldenie rendkívül rövid idő alatt. Tartsd lenyomva a Tab billentyűt, hogy lásd a késleltetésed.

[szerkesztés] Hivatkozások

Össze vagy kavarodva, vagy csak szeretnél többet megtudni a témáról? Teljesen érthető. A QOS dokumentációja teljesen szétvan szórva az interneten és több helyen is elavult. Miközben a QOS-t saját magam tanultam (eredeti szerző), a következő linkeket gyűjtöttem össze:

• iptables
• Linux Advanced Routing & Traffic Control
• l7-filter
• ipp2p
• QOS graphs
  • combined with Munin
  • combined with Nagios
• QOS graphs
• HTB Linux queuing discipline manual
• http://www.docum.org/docum.org/
• ADSL Bandwidth Management HOWTO
• Jim diGriz's QoS Script
• Fair NAT for Linux Routers
• http://www.ssi.bg/~ja/
• The WRR scheduler
• http://www.adsl-optimizer.dk/
• Traffic Control HOWTO

Thinking of traffic shaping multiple interfaces as one in kernel 2.6? Or want to packet shape ingress? IMQ could be the answer, but it might not be stable. Or is it? There is next to no online documentation.

• IMQ ported to 2.6 discusion http://groups.google.com/group/linux.kernel/browse_thread/thread/31ba3f19dc66c4ef/2e755f4dc73da1c5?lnk=st&q=Intermediate+queueing+device+Patrick+McHardy&rnum=1&hl=en#2e755f4dc73da1c5
• IMQ usage example http://www.lartc.org/howto/lartc.imq.html