Traffic shaping - 2 (IMQ a úvod do shapingu)

20. 9. 2006 | Max Devaine | Sítě | 24025×

Imq je dlouho diskutovaná věcička. Někdo tvrdí, že není třeba, jiný zase oponuje. Jak to s ním vůbec je, co dělá a kdy je vhodné ho použít? Pokud si kladete tyto otázky, tak vám snad s nimi tento článek pomůže. Přednostně se ovšem podíváme na pravidla shapování.

Co přesněji máme dnes v plánu?

• Vysvětlení principu shapingu
• IMQ
• IMQ: nastavení modulu a kernelu
• Cesta paketu
• Finální řešení pomocí imq
• IMQ a oba směry
• Rekapitulace
• Závěr

Vysvětlení principu shapingu

Cílem shapování je nějaká úprava trafficu. Většinou se snažíme ladit jak příchozí (download), tak i odchozí (upload) traffic. Každý myslí na ladění příchozího trafficu a na odchozí se občas zapomene. Proč by se měl člověk zabývat nějakým odchozím provozem, když chce jen dobře stahovat. Ne každý si uvědomuje, že i odchozí provoz má celkem velký vliv na kvalitu celého pásma.

Shapování příchozího provozu se provádí na rozhraní, které směřuje do vnitřní (lokální) sítě (LAN). Upload se ladí na rozhraní, které směřuje do internetu nebo do nějaké jiné vnější sítě (WAN). Vždy prostě nastavíme pravidla s filtry na to rozhraní, které posílá později shapovaná data.

Tak, teď asi dost lidí napadají otázky typu: no jo, ale co když nemá router dvě síťová rozhraní, ale jen jedno, které vede přímo do internetu? Nebo naopak rozhraní přebývají. Kam se potom nastaví pravidla pro příslušný shaping?

Není mnoho možností, jak tyto situace řešit, jedno si však ukážeme.

IMQ

Jak už padlo v předchozím článku, imq je virtuální síťové rozhraní, kam se přesměruje síťový provoz, který chceme shapovat. Děláme tak z několika důvodů. Hlavním je třeba chybějící rozhraní, na kterém bychom prováděli shapování. Dalším je potom přebývající rozhraní. V neposlední řadě umožňuje lehký shaping s NATem. Nevýhodou imq je to, že provádí nečisté věcičky, a proto ho asi nikdy nenajdeme oficiálně v kernelu - a musíme patchovat. Také jeho stabilita bývala někdy sporná. Mně osobně mi jednou vytuhl PC. To ovšem nebylo za klasického provozu, ale laboroval jsem s imq, co to dá. Pokud si nějaké nastavení odzkoušíte, a nebudete provádět testy při ostrém provozu, tak pochybuji, že vám imq způsobí potíže.

IMQ: nastavení modulu a kernelu

Základem je mít opatchované jádro a iptables, což můžeme zhotovit podle minulého článku. Jako výchozí bývá v jádře nastaven počet rozhraní na dvě, takže když provedete načtení modulu bez parametrů

modprobe imq

tak se nám vytvoří dvě imq zařízení (imq0 a imq1)

ip link
...
  11: imq0: <NOARP> mtu 1500 qdisc noop qlen 30
     link/void
  12: imq1: <NOARP> mtu 1500 qdisc noop qlen 30
     link/void
...

Počet virtuálních imq zařízení můžeme také ovlivnit parametrem při připojování modulu (pro vytvoření jednoho imq zařízení):

modprobe imq numdevs=1

Další věcí, která bývá v jádře nastavena, je schéma zapojení imq v jednotlivých tabulkách před NATem či za ním. Tuto důležitou skutečnost jsem v předchozím článku nezmínil, tak jí teď zařadím.

Imq může být nastaveno takto (zakřížkovaná položka je výchozí nastavení):

Device Drivers -->
   Network device support  --->
      <M> IMQ (intermediate queueing device) support
          IMQ behavior (PRE/POSTROUTING) (IMQ BA) --->
		( ) IMQ AA
		( ) IMQ AB
		(X) IMQ BA
		( ) IMQ BB
         (2)   Number of IMQ devices 

Význam jednotlivých zkratek :

První písmeno značí nastavení v tabulce PREROUTING a druhé v POSTROUTING:

A = after (po) => imq projde paket až po natu
B = before (před) => imq projde paket před natem

Pro změnu schématu stačí jen přenastavit .config a překompilovat modul imq:

make menuconfig
make
make modules_install
rmmod imq
modprobe imq

Typ schématu potom můžeme vidět ve výpisu dmesg hned po připojení modulu imq.

Než si zvolíme schéma sobě blízké, musíme nejprve vědět, jak paket vůbec cestuje netfilterem.

Cesta paketu

Vše by mělo znázorňovat následující schéma. Jen upozorním, že toto zdaleka není kompletní schéma, ale pro naše potřeby postačí.

Paket postupně prochází přes PREROUTING. Zde a nikde jinde probíhá změna adresy na adresu příjemce (DNAT). Pak dorazí na rozhodovák. Pokud má paket IP routeru, tak vleze přes chain INPUT k lokálním procesům na serveru. Odtud dále přes chain OUTPUT, který lze použít k DNATování paketů vzniklých pouze na lokálním počítači. Pokud paket nenáleží routeru, tak jde přes chain FORWARD. Všechny pakety potom odcházejí přes POSTROUTING, kde mohou být SNATovány (změní se zdrojová IP adresa za cílovou => IP adresy, na které je aplikován SNAT, budou mít IP adresu stejnou jako má router). Toto schéma se aplikuje na každé rozhraní.

Velice jednoduchý obrázek níže by snad mohl pomoci k porozumění. PREROUTING je první věc, kterou paket potká, když vyleze z rozhraní. POSTROUTING je poslední věc, kterou paket proleze. Zelené kolečko značí vstup do "magické iptables tabulky (router)" a červené zase výstup. (Velice jednoduše a nepřesně řečeno, snad mi znalí uživatelé odpustí.) Když jsem přemítal, na co aplikovat filtry pro download apod., tak mi tento obrázek velice pomohl.

Tak, teď jistě chápete, proč je zvolený typ schématu velice důležitý.

Pokud tedy používáte SNAT/maškarádu, tak by bylo asi nejlepší, kdybyste si zvolili typ AB. Paket přiletí do PREROUTINGu, tam NAT převede IP na zdrojovou a potom se aplikuje imq - takže potom ve filtru pracujeme se zdrojovými adresami a jsme za vodou. Když chceme aplikovat shapovací skript na upload, tak imq umístíme do POSTROUTINGu před (before) NAT.

Když používáme klasický SNAT/maškarádu, tak nemusíme aplikovat imq na PREROUTING s tím, že shapovací skript hodíme přímo na rozhraní do LANu. To má ovšem jeden malinkatý háček/výhodu/nevýhodu. Takový skript nám neumožní shapovat lokální traffic na routeru, protože se filtr aplikuje až někde u POSTROUTINGu na rozhraní do LAN a tudy lokální provoz na serveru neprotéká.

Finální řešení pomocí imq

Tak, dost teorie a jdeme konečně něco nahodit. Nejprve se podíváme k problému s chybějícími rozhraními. Do vytvořeného virtuálního imq0 přesměrujeme traffic, který proudí z internetu k nám (eth0 = WAN; eth1 = LAN).

iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0

Kde číslo za --todev značí očíslované imq, v našem případě imq0.

Teď, když máme přesměrovaný provoz z internetu přes naše imq, tak můžeme celé virtuální imq rozhraní nahodit:

ip link set imq0 up

Když si pak spustíte např. nějaké stahování z internetu, tak byste měli vidět, jak přes imq0 cestují pakety. To zjistíte např. příkazem:

ifconfig
....
Zapouzdření:NEZNÁM HWadr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
AKTIVOVÁNO BĚŽÍ NEARP MTU:1500 Metrika:1
RX packets:879774 errors:0 dropped:0 overruns:0 frame:0
TX packets:879338 errors:0 dropped:0 overruns:0 carrier:0
kolizí:0 délka odchozí fronty:30
RX bytes:369590578 (352.4 MiB) TX bytes:369321146 (352.2 MiB)
...

Pozor - když se na něj zkusíte podívat s tcpdumpem pomocí:

tcpdump -i imq0

tak nic neukáže.

Celé naše snažení by pak mělo vypadat nějak takto :

Druhý příklad je o dva řádky delší (eth0 = WAN; eth1, eth2, eth3 = LAN):

iptables -t mangle -A POSTROUTING -o eth1 -j IMQ --todev 0
iptables -t mangle -A POSTROUTING -o eth2 -j IMQ --todev 0
iptables -t mangle -A POSTROUTING -o eth3 -j IMQ --todev 0
ip link set imq0 up


Tímto jsme vlastně přesměrovali veškerý odchozí provoz do LANu přes imq. Shapování downloadu by teď měla být hračka.

Vnímavější by možná napadlo hodit na LAN 1, 2 a 3 bridge br0. Tím by se vytvořilo jedno virtuální zařízení, které by dokonce umožňovalo, aby byly všechny podsítě ve stejném rozsahu. Je to velice dobrý nápad, avšak má jednu drobnou chybku. Na br0 se nedá provádět shapování, protože iptables na něj neplatí (i když někdo tvrdí, že mu to iptables dokáže) a je k dispozici pro konfiguraci balíček ebtables. Takže pokud má někdo nakonfigurovaný bridge, tak bude stejně asi muset sáhnout po imq.

IMQ a oba směry

Jak vidíte, tak do imq zařízení se dá přesměrovat více než jeden provoz. IMQ zařízením nemusí být přesměrován jen jednosměrný provoz, můžete do něj přesměrovat jak odchozí, tak příchozí traffic:

iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0
iptables -t mangle -A POSTROUTING -o eth0 -j IMQ --todev 0
ip link set imq0 up

Nyní můžeme na jednom imq zařízení shapovat jak download, tak upload.

Rekapitulace

Co nám ten dnešek nakonec dal?:

• Víme, že imq umí nahrazovat chybějící rozhraní, umí spojovat více rozhraní, a dokonce umožňuje shaping přímo se zdrojovými IP a to i v přítomnosti NATu.
• Měli bychom vědět, kdy a jak použít imq (každá akce navíc způsobuje ztrátu času).
• Obecnou cestu paketu bychom měli umět přeříkat i o půlnoci s dudlíkem v puse.

Dodatek:

IMQ lze umístit např. i do chainu FORWARD. Na druhou stranu nelze provozovat více imq zařízení v jednom směru. Pokud tak učiníme, bude fungovat poslední vytvořené.

Závěr

V závěru bych se chtěl omluvit za prozatímní absenci skriptů, které byly slibovány minule v závěru. Bohužel došlo minule k drobnějšímu nedorozumění, takže ničeho se nebát, skripty budou příště :-). Stále mám takový pocit, že jsem někde udělal nějakou chybu, ale to vy určitě v diskusi opravíte.

       

Komentáře

[NbS]

jednim slovem Super :)

[Thunder.m]

IMQ mi snižuje stabilitu routerů dost zásadním způsobem na jádrech 2.6, jinak je to skvělá věc, ale uptime okolo 7-14 dnů je dost bída :(

[Heron]

Zkus raději CBQ.

[b42]

Muzu se zeptat jak lze pomoci cbq nahradit imq, popripade co maji vubec spolecneho?:)

[Heron]

CBQ je řekl bych standardní nástroj a v mnohých distribučních jádrech už je, společně třeba s HTB, QOS. Takže odpadnou problémy s patchováním jádra a především je stabilní. Jedniná "nevýhoda" oproti IMQ je složitější nastavení.

[Max]

Řekl bych, že CBQ bylo na světě a v jádře mnohem dřív, jak HTB. CBQ nemá nic funkčně společného s IMQ. Tvoje dvě věty mi připonýnají jedno howto, co jsem četl, akorát tam bylo místo IMQ napsáno HTB :-/ ...
Zdar Max

[b42]

Pro upresneni:

CBQ je classful qdisc (queueing discipline), ktery umoznuje shapovani trafficu - ten se pomoci filtru klasifikuje do trid a cbq mu podle urciteho algoritmu prideluje sirku pasma. Mezi dalsi qdiscy patri treba htb, sfq, tbf, ...

IMQ je specialni zarizeni, na ktere je mozno presmerovat traffic a ten je pak mozno pripojenymi qdiscy shapovat ... a to casto v situacich, ktere moc dobre standartnimi postupy nejde vyresit - napr. shapovani prichoziho trafficu ci sdileni trid classful qdiscu mezi vice rozhranimi.

Jeste zjednoduseneji receno IMQ je bez qdiscu nanic a CBQ nema s IMQ prakticky nic spolecneho, takze bych si dovolil tvrdit ze ho nemuze nijak nahradit.

OT: pekny clanek s peknymi obrazky:)

[Max]

Hehe, mě to nemusíš říkat, já to vím, viz. moje reakce :)
Zdar Max
PS:díky za OT :)

[Michal Kubeček]

CBQ je skutečně starší, HTB totiž dokonce vznikl jako náhrada za CBQ, která by netrpěla jeho neduhy.

[Pavel Janousek]

Neduh = slozitost, presnost, flexibilita? Devik to totiz psal (dle vlastnich slov) jako nahrada za CBQ, a z duvodu aby to bylo snazsi... - ja jsem spise slysel narky, jak HTB neni dost presne pri vyssich (nad 512kbps) rychlostech... nevim, nejak jsem zamrzl v ere CBQ a nikdo si nikdy na moji implementaci nestezoval...

[_]

> Tvoje dvě věty mi připonýnají jedno howto, co jsem četl, akorát tam bylo místo IMQ napsáno HTB

jj. vselijaky howto na qos jsou dost bida.

mozna by stalo za to kdyby si uz konecne nekdo dal praci s tim, aby vysvetlil co je to v linuxu sitove zarizeni, jak se mu podoba imq a co je to ingress a egress qos scheduleru a ze se vaze na zarizeni.

co v ingressu nejde a co v egressu proti ingressu a co nejde ani v ingressu ani egressu, kdyz se nepouzije imq na forwardovanych paketech.

[Max]

Nejni to taková bída. Myslel jsem tím, že je to jak vystřižené z jednoho howto, co jsem četl, ale tam nebylo o imq ani slechu. Prostě to bylo CBQ vs. HTB a úplně stejná věta. Prostě mi to připadalo, jako kdyby byla okopírovaná a bylo zaměněno slovíčko HTB na IMQ. Nic víc. Návodů je dost. Dokonce i v češtině, ale většinou je to tak nějak nepříliš dobře podané a hlavně né moc komplexně. Všude je to vzaný tak nějak obecně a počítá se s tím, že ty pojmy jsou známý apod.
Zdar Max

[Opičák]

řekl bych že jsi malinko mimo ...CBQ ani HTB nemají s IMQ nic společného.

[Heron]

A to jsem někde tvrdil?

Článek hovoří o shapování, konkrétně pomocí IMQ. Já psal, že na shapovaní je lepší použít CBQ nebo HTB. Navíc je zbytečné vytvářet nějaké virt. rozhraní (což dělá IMQ), to k shapování není potřeba.

[Max]

Když používáš nat a nechceš / nemůžeš využívat markování packetů (které údajně v tisících velice markantně snižují výkon pc, latencí apod.), tak rozhodně není zbytečné vytvářet imq zařízení, které ti zajistí manipulaci ještě před natem . Také nevím, jak by jsi efektivněji shapoval např. na více výstupních zařízeních. Myslím, že asi docela ztuha. Jsou hold případy, kdy se použití imq nevyhneme. Nelze říci, že je imq zcela zbytečné a k shapování není třeba. Jsou případy, kdy třeba je a případy, kdy třeba není. To jsem se snažil vysvětlit v článu. Tvoje rekce je celkem zavádějící a nepřesná.
Zdar Max

[Opičák]

Po pravdě s tím markováním nevím nevím (prakticky to ověřeno sice nemám) ale projekt Prometheus (czfree) používá právě markování a ten umí opravdu tisíce klientů. Je ale fakt, že to nějak hashuje, aby to iptables rychlej stíhaly.

[Max]

Také to bohužel nemám v tisících ověřeno, takže opravdu nevím. Toto se říká ( nebo říkalo a je to minulostí ) :-/.
Zdar Max

[Max]

A to jsem někde tvrdil?

Ano, tady :

Jedniná "nevýhoda" oproti IMQ je složitější nastavení.

Z čehož vyplynulo, že porovnáváš CBQ vs. IMQ. Nebo to bylo velice, velice špatně podáno, čemuž podle tvých dřívějších reakcí moc nevěřím ...
Zdar Max

[Michal]

Tak mi ukaž jinej způsob, jak oshapujes upstream s downstremem dohromady, než pomocí IMQ + [HTB|CBQ] (např když máš 1 Mbps linku a nechceš pevně definovat kolik dáš na downstream a kolik na upstream a chceš to přiřazovat podle požadavků a zachovat QoS). K tomu potřebuješ up i down dostat na jedno rozhraní a IMHO jedinej způsob je IMQ (a když ne jedinej, tak aspoň nejpoužívanější). BTW zajímalo by mě jak chceš použít IMQ pro shapovaní bez CBQ, HTB nebo ostatních queuing disciplines.

[Heron]

Pomocí CBQ jde docela dobře omezovat několik interfaců, jak down tak up. Veřejné IP jsou bez problémů, neveřejné je nutné nejdřív omarkovat. Opravdu v tom nevidím problém (jak bych taky mohl, když nám tohle řešení funguje no problem ).

[Opičák]

Aby se ti například mezi třemi rozhraními spravedlivě půjčovala volná kapacita a to jen pomocí CBQ? Mohl bys mi to prosím ukázat? Pokud vím, tak ty zařízení o sobě vůbec nevědí.

[_]

a pointa je jaka? ze ty interface jsou vsechny zapojeny do sft bridge qdisc je poveseny na bridge a shaping je provedeny do toho rozhrani ktery neni v bridge ale do kteryho se to routuje?

[Heron]

Pointa je taková, že každá IP adresa (nebo mark, jedná-li se o neveřejnou IP), za příslušným rozhaním dostane přesně tu rychlost, kterou má mít.

[Opičák]

A už jsi někdy shapoval ingress? Bez IMQ to jde docela blbě. Schválně to zkus bez použití IMQ nebo něčeho podobného. Jinak článek se jmenuje IMQ a úvod do shapingu. Pokud jsem dobře četl, tak nehovoří o shapování pomocí IMQ, ale o tom, jak si pomocí IMQ shaping zjednodušit, což je docela rozdíl.

[..]

Napada mne jedinne: eh?

[Dan Ohnesorg]

To se mi moc nezda, na tomhle obstaroznim jadre 2.6.12.4 udelam s imq pres ktere tece 10Mbps klidne 100 dni uptime. Nemate tam spise hostap nebo madwifi?

[Libor Chocholaty]

$ uptime
 14:11:45 up 66 days, 21:26,  1 user,  load average: 0.46, 0.45, 0.32

pouzivam IMQ pro shapovani provozu pres 4 rozhrani.

[thiemel]

Ahoj, napsal jsem si vlastní patch... Je to sice psané "intuitivně", ale očividně to funguje a "soft lockup detected on cpu#0" mi už nevyskakuje... Jinak jedu na AMD X2 3800+ a po patchnutí si nemůžu stěžovat

--- imq.c.orig  2006-11-18 00:08:42.000000000 +0100
+++ imq.c       2006-12-17 23:34:03.000000000 +0100
@@ -201,13 +201,14 @@
                        ret = 0;
                }
        }
-       if (spin_is_locked(&dev->xmit_lock))
-               netif_schedule(dev);
-       else
-
-        while (!netif_queue_stopped(dev) &&
-               qdisc_restart(dev)<0)
-                /* NOTHING */;
+
+
+if (spin_trylock(&dev->xmit_lock)) {
+    qdisc_run(dev);
+    spin_unlock(&dev->xmit_lock);
+}else{
+    netif_schedule(dev);
+}
 
        spin_unlock_bh(&dev->queue_lock);
 

[Thunder.m]

A patch pro jádro 2.6.18 máte?

[Thunder.m]

Díky, upravil jsem si to tak aby to chodilo na jádře 2.6.18.2, bohužel kernel-panicem to při dhclient stále trpí, ale jinak to funguje parádně, hodím odkaz na patch někam do blogu.

[pasmen]

Moc hezky clanek.

[Glin]

Asi tak 4 roky zpet jsem potreboval IMQ pro spojeni dvou sitovek v routeru, na ktery jsem potreboval udelat shaping. Brzy to nejspis budu potrebovat znovu, proto jsem se koukal, jestli uz neni nejaka nahrada, protoze patchovat jadro bych jeste prezil, ale jeste dalsi 2 baliky (iproute2 a iptables), to uz je trochu moc.

Prvni vec kterou jsem nasel, byla naprogramovana tusim clovekem s jmenem Jamal Hadi Salim, se zajimavym napadem: Doprogramoval funknost IMQ jako rozsireni vlastnosti dummy zarizeni. Bohuzel jsem uz nenasel zadnou zpravu, zda se to do kernelu dostalo ci nikoliv. Diskuze dummy

Druou vec, kterou jsem nasel je nove zarizeni IFB (Intermediate Functional Block). O tom vim, ze uz se do kernelu dostalo.

Nemate s IFB zkusenot? Mozna by to bylo dobre tema pro dalsi clanek. Diskuze o IFB

[Max]

Patchovat se musí jen iptables a kernel (pokud jde pouze jen o imq). Jinak na IFB chci mrknout, docela mě jeho funkčnost zajímá ...
Zdar Max

[PSIkappa]

Dost zaujimavy napad, i ked nie celkom riesiaci tvoj problem je pouzitie "ppp-pipe"

Internet (eth0) <-> ppp0 ----- ppp1 <-> LAN (eth1)

kde ppp0 a ppp1 je na lokalnej masine spravene cez fifo device, viac o tom:

http://mailman.ds9a.nl/pipermail/lartc/2004q1/011477.html

[b42]

Pokud jsem to dobre pochopil tak z funkcionality IMQ umoznuje IFB pouze shapovani prichoziho trafficu. Navic si nejsem jisty jestli pres ifb prochazeji pakety pred (de)NATem, nebo po.

Nebo se pletu? Neexperimentoval s nim nekdo? Budu vdecny za kazdou informaci, jelikoz jich po netu neni mnoho:)

[Orrie]

Problem s IFB je v tom, ze se hookuje pred netfilter, takze neni mozno pouzivat iptables, je nutno pouzit tc filtry. Vice info treba tady http://linux-net.osdl.org/index.php/IFB.

[Trevor]

Dodatek:

IMQ lze umístit např. i do chainu FORWARD. Na druhou stranu nelze provozovat více imq zařízení v jednom směru. Pokud tak učiníme, bude fungovat poslední vytvořené.

Ja by som zase potreboval urobit nieco take ze z forwardu by som z jedneho smeru posielal pakety na imq 1 a z druheho smeru na imq0 napr je to mozne ?

[Max]

Myslím, že ano, bohužel jsem na samostatném PC a nemohu to odzkoušet, takže zkus toto :

iptables -t mangle -A FORWARD -i eth0 -j IMQ --todev 0
iptables -t mangle -A FORWARD -i eth1 -j IMQ --todev 1
ip link set imq0 up
ip link set imq1 up

Zdar Max

[Opičák]

Spojování dvou směrů do jednoho IMQ zařízení jsem zkoušel na jádře 2.4 a nepochodil jsem. Ale je pravdou, že každý směr byl z jiného rozhraní.

[Max]

Jak se zdá, tak nefungují dvě imq v jednom směru(jsem zkoušel). A ani přesměrování do jednoho imq z dvou interfaceů, i když v různých směrech (zkoušel tady někdo na abc). Funguje snad jen přesměrování dvou opačných provozů vztahující se k jedné síťovce. :-/. Ale myslím, že se to dá přežít
Zdar Max

[Opičák]

přežít se to dá, vyřešil jsem to jinak a zatím to nedělá problémy

[Radek]

Tak nevim asi jsem natvrdlej a nebo mi to nejak nemysli :(

Jak by to mnelo bejt v pripade ze chci sloucit oba smery jak upload tak download pro vice lan rozsahu?

Vystupni rozhrani je eth0

A pak eth1,eth2 eth3 jsou vnitrni site.

spravne reseni je toto:

iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0
iptables -t mangle -A POSTROUTING -o eth1 -j IMQ --todev 0
iptables -t mangle -A POSTROUTING -o eth2 -j IMQ --todev 0
iptables -t mangle -A POSTROUTING -o eth3 -j IMQ --todev 0
ip link set imq up

a nebo jen toto:

iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0
iptables -t mangle -A POSTROUTING -o eth0 -j IMQ --todev 0

[Max]

To první nefunguje, jak už jsem psal výše v komentáři :

Jak se zdá, tak nefungují dvě imq v jednom směru(jsem zkoušel). A ani přesměrování do jednoho imq z dvou interfaceů, i když v různých směrech (zkoušel tady někdo na abc). Funguje snad jen přesměrování dvou opačných provozů vztahující se k jedné síťovce. :-/.

Takže tvůj první případ si odporuje s tím, co jsem řekl. Takže buď můžeš udělat to, co jsi napsal jako druhé řešení :

iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0
iptables -t mangle -A POSTROUTING -o eth0 -j IMQ --todev 0

Nebo použít dvě imq zařízení :

iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0
iptables -t mangle -A PREROUTING -i eth1 -j IMQ --todev 0
iptables -t mangle -A PREROUTING -i eth2 -j IMQ --todev 0
iptables -t mangle -A PREROUTING -i eth3 -j IMQ --todev 0

Tvůj první případ by ti omezil (kdyby to fungovalo) jen jeden směr. Říká, že příchozí traffic z eth0 bude posílat do imq0 a odchozí traffic do ostatních interfaceůbude posílán také do imq0. Je to prostě jeden směr. Asi jsi myslel něco, jako je můj druhý příklad. Prostě nasypat vše do PREROUTINGů
Zdar Max

[Max]

Ach jo, samozřejmě jsem to vysvětlil dobře, ale příklad zkazil, druhý případ by měl být takto :

iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0
iptables -t mangle -A PREROUTING -i eth1 -j IMQ --todev 1
iptables -t mangle -A PREROUTING -i eth2 -j IMQ --todev 1
iptables -t mangle -A PREROUTING -i eth3 -j IMQ --todev 1

Zdar Max

[studna]

Chodi tento priklad tak ze sa da shapovat osobitne upload a download? Ma to niekto odskusane?

[Pepe]

TCP shapuju pomoci iptables znacek, filtru a HTB, ale ikdyz se mi UDP provoz zarazuje do spravnych classu, ignoruje jejich rychlostni limity. Je mi jasne, jak funguje UDP a ze neni zas tak dobre ho omezovat, ale prece kdyz mi nekdo ve svem classu udela napr. "VPN prez UDP", pojede vesele na plny kotel, co mi da moje lajna. Tusite, kde mi sedi na reseni bug? Pep.

[petr_p]

Prichozi nebo odchozi?

V prvnim pripade mas smulu a lajnu neuvolnis, protoze ji zahlcuje tvuj ISP, i kdyz prijemce v lokalni siti bude mit pocit, ze to jde pomalu.

V druhem pripade to bude fungovat.

[LFCIB]

Díky Maxi za super článek, těším se na pokračování.

LFCIB

[mior]

Ako to celé spolupracuje so squidom?

[Opičák]

nijak. Tohle slouží pro dělení/QoS. Podle mého názoru používat v dnešní době squid je už trošku přežitek.

[mior]

Nemyslim, ze je to zbytocne... Ako by ste chceli v skole blokovat zakazane stranky? Ako urcit, kto a kedy moze na ktoru stranku, ak nie squidom? Squid nie je len cache...

[Opičák]

no budeš se divit, ale jsou i jiné způsoby.

[Pavel Janousek]

Takovy clanek by mel smysl a nikoli prekladat uz po X-te Advanced Routing Howto...

[Max]

Hmm, na co je teď naráženo? ( Že to má být holý překlad Advanced Routing Howta? To je asi nějaký vtip, ne? ) Vaše věta totiž trošku postrádá smysl :-/ ...
Zdar Max

[Pavel Janousek]

Sledujte genezi/vyvoj, aspon pak Vase nepochopeni a kritika nebude vypadat tak naivne... Mluvim o koncepcni zmene s tim, ze CBQ, HTB spolu s IMQ (RedHat asi vi, proc ho nedodadava ve svem enterprise kernelu, ackoli ma spoustu jinych vychytavek, vcetne treba ipt_recent - relativne nova vec v teto oblasti) a podobnymi ostruvky bez ladu a skladu neni jiz nejaky patek treba... jenze to radsi budeme debatovat nad vecmi leta starymi s dobrou dokumentaci, tutorialy atd. (uvadene demostrace jsou stejne spise teoreticka "zakladni" cviceni... a takovych cookbooku na slusny dotaz Googleho najdeme hafo) misto toho abychom psali opravdu o novych, uzitecnych a zajimavych vecech (u kterych je dokumentace poskrovnu a o cookboocich nemuze byt vubec rec) a to nejen z pohledu "kernel trafficu", ale predevsim z pohledu praktickeho vyuziti neceho, co uz je v produkcni fazi od jadra 2.6.11 (?)... Psat takto o IMQ melo smysl pred 2 lety, kdy se v LinuxCz konfere kazdou chvili vyskytoval dotaz na reseni shappingu, ktery inklinoval na vyuziti IMQ (pak by ten clanek mel smysl, protoze zdroju na IMQ bylo malo a mnoha lidem by to pomohlo, dnes se ten smysl znacne vytraci - krome nutnosti vydat denne aspon jeden clanek a odmeny autora), dnes, kdyz mame moderni a ve std. jadre obsazenou alternativu je to mysim trochu zastarale... - je mi lito, ze jsem Vam to musel takto po lopate nasazet a nejste schopen se dovtipit z kratkeho a presne vystizneho sdeleni... A pokud Vam to stale nesecvaklo nevadi, bud mate opravdovy zajem a najdete si podrobnosti, o kterych hovorim, a nebo to stejne nema smysl...

[Max]

Vím, co tím myslíte. Také vím, že je v jádře alternativa k imq, ale nemyslím si, že by bylo imq úplně mimo hru a že by na něj existovalo hodně článků a howto, které polopatě vysvětlují jeho funkce méně znalejším uživatelům apod. a ještě navíc v češtině :-/. Zatím jsem všude našel postup typu modprobe AND iptables na pár řádcích a tím to haslo. Proto jsem se také uchýlil k trošku širšímu rozepsání o imq. Samozřejmě mám v plánu také něco napsat o alternativě, ale na to teď nemám dostatek času :-/. Na nutnost vydávání článků každý den bych to moc nesváděl a na odměnu autora už vůbec ne ( Robert ví, o čem mluvím ) ..
Zdar Max

[Opičák]

Jo jo, už je to tu zas....kecat a kritizovat článek umí každý, napsat ho málokdo. Člověk co jej psal na tom strávil jistý čas a bylo by slušné jej ocenit tím, že mu nebudeme podrážet nohy. Nemyslíš?

[Pavel Janousek]

A co jste na charitu venoval Vy, ze mate plna usta kecu?

[Max]

Snad se tu nechcete začít předhánět s tím, kdo toho nejvíc pro něco / někoho udělal ?
Zdar Max

[Opičák]

Zatím tu máš plná ústa keců jen ty. Viz. příspěvek o kousek výš. Aneb chtěl jsem tím naznačit, že napadáš slovně autora, což mi na vzdělaného člověka, za kterého se vydáváš, moc nepasuje. Ale alespoň pro příště vím s kým mám tu čest.

PS: k charitě .... A TY??

[Pavel Janousek]

Desitky diskusi a debat nad praktickymi implementacemi vyse uvedenym zdrojem informaci... napr.

Clanky budu psat az to bude mit smysl a na tema, ktere jednak precizne ovladam (povrchni "zurnalista" jsem nikdy nebyl a znizovat se na stara kolena k tomu nebudu) a jednak bude zajimave... verim, ze jemne nuance a porodni bolesti J2EE serveru pod Apache licenci (Geronimo) asi nebude majoritni casti zde prijmut s nadsenim... stejne jako technologie okolo J2EE, kdyz vetsina nevyrostla z rise PHP (jen se podivejte na sledovanost a uspesnost clanku na jakem "systemu" bezi zdejsi server - uz jen z popularniho hlediska, bez odborneho, by to mohlo zdejsi navstevniky zajimat... - statistika vsak hovori jinak)

Bud prispivame do odborneho periodika, ktere by melo byt urcitym garantem kvality a zejmena vecne spravnosti - bohuzel na ceskem "trhu" neni takovy casopis nebo e-zin zamereny na IT.. - srovnejte treba se zdravotnictvim, vedou (ona existuje i computer science)... nebo do popularniho platku, kde se na vecnou spravnost az tak nehledi a bud se to dela pro prachy nebo z charity... - pro prachy to delat nebudu, protoze clanek bez vecne zcela rigorozne spravnych a overenych poznatku zabere tolik casu a usili, ze se z nuzne odmeny autora stava charita stejne...

Dalsi tema k debate na tema charita a co kdo dela/dokazal?

PS: A s tou charitou, docela jste mi nabeh na smec, kupodivu mezi nase reference lze zaradit dve charitativni organizace... (se specialnimi smluvnimi podminkami) - tak zas tak nevyskakujte...

[Opičák]

My my my....ptal jsem se na tebe ne na skupinu lidí. Opět hromada odborných slovíček, naučených frází a prakticky nic nového co by člověka zajímalo. "Tož díky"

[Pavel Janousek]

Hele opicaku, co kdyby sis nejprve zjistil s kym mas tu cest nez takhle (znacne hloupe) vystartujes?

PS: Kdyz Te neco nezajima, tak se na to neptej... pro priste!

[Opičák]

Mě je to absolutně jedno s kým mám tu čest. Můžeš být třeba papež a "neposeru se". Zatím si myslím, že jsem narazil na značně arogantního a sebestředného člověka. A pro příště nevybuřuj, když nehodláš odpovědět na srozumitelně položenou otázku!

[Max]

Pánové, pánové, Vy už to máte za pár ...
Zdar Max

[Opičák]

Já možná ano jenže asi jinak než myslíš :) Jakožto člověka s rakovinou mě nemůže nějaký Pavel Janousek rozhodit Zatím jsem se nedal zubaté, tak proč bych měl nějakému prudiči

To víš, někteří lidé neocení ani snahu ani čas vynaložený pro ty, co nemrskají anglinu jak bozi, potřebují to polopatě ale rádi by tomu přišli na kloub. Já ti děkuju za smysluplné, pěkně ilustrované a hlavně ČESKÉ články, kterých je opravdu málo.

[Nosík]

Nevíte někdo co by mohlo způsobovat to, že když zavedu imq pomocí mod_probe tak mi přestanou fungovat ostatní síťová rozhraní a musím restartovat server.??

[Max]

Co je to mod_probe? Nejni myšleno modprobe? Jaké jádro používáš? Distribuční (jaké?), nebo vanilla (jaké?) ? Používáš imq patch, který odpovídá pro danou verzi jádra?
Zdar Max

[Nosík]

jo, sorry jasné že modprobe :o) Jádro mám Vanilla 2.6.16.27. postupoval jsem přesně podle návodu(1.díl tohoto seriálu). Verze patchů by měli souhlasit.

[Max]

Takže hned po načtení modulu se jakoby vypnou ostatní síťová rozhraní? Takže ani nestačíš imq zařízení ani nahodit pomocí ip (nebo ifconfig) ? A co říká výpis dmesg po připojení modulu imq? Co když modul znovu potom odpojíš? Stále nejdou?
Zdar Max
PS:opravdu musíš restartovat server? Nevyřeší to ani reload modulů apod. ?

[iTomB]

Jo tak tohle jsem taky zazil. IMQ bylo blble patchle v jadre. Kdyz jsem se podival pres konzoli, tak IMQ melo jeden z udaju 0B (ted nevim zda Tx nebo Rx). Normalne si jsou rovmy, co prijme to odesle. Patch neni pro jadro 2.6.18.1 ale jen pro starsi 2.6.17. Tak jsem si musel upravit zdrojaky jadra (zmena v sch_generic). Po upravach se vse rozbehlo jak melo a ja doufam ze to pojede i na ostrem provozu.

A ted trochu k te stabilite IMQ. Provozuji server s pomerne vetsim trafickem. Pred nedavnem se na nem zvedl trafik a jaksi zacalo padat jadro: BUG: soft lockup detected on CPU#0! CPU 0: Modules linked in: Pid: 0, comm: swapper Not tainted 2.6.16.16 #16

Takze jsem server odstavil a predelal na jadro 2.6.18.1. Bohuzel vydrzelo to bezet cca 2h 45min nez hodilo opet soft lock. Po vypnuti shaperu to bezelo dobre, po par upravach to ted bezi tez dobre - vypnul jsem IMQ.

Predtim bezel server beze zmeny bez problemu pres 1 mesic. Ale jakmile se zvedl trafick, tak zacalo padat IMQ (typuju, protoze ted na novem to tez padalo a co jsem vypl IMQ uz nepada).

Takze jsem hodne pro clanek o necem novem. Napriklad IFB. Moc jsem o nem takt nenasel a bohate by asi stacilo malej popis a jak to nahodit tak, aby se to chovalo plne jako IMQ - kde by se shapoval cely opacny trafik.

iTomB

[Thunder.m]

Taky bych chtěl něco o IFB, o víkendu to zkusím implementovat, IMQ už nechci používat protože se pro nová jádra špatně schání patch a je to fakt nestabilní.

[Orrie]

http://mailman.ds9a.nl/pipermail/lartc/2006q3/019371.html a http://linux-net.osdl.org/index.php/IFB Tady mas vse podstatne. Pomoci ifb imq zcela nahradit nelze. Klasicky pripad je shaping prichoziho provozu z netu do LAN s NATem, kde shapujes na imq (imq after NAT) a klasifikujes pomoci cilove adresy klienta v LAN za NATem. Toto s ifb neni mozne, protoze paket prichozim smerem nejdrive prochazi pres ifb a az pak jde pres NETFILTER. Z pochopitelnych duvodu pak samozrejme nelze ani klasifikovat markovanim pres iptables. Vypada to asi nejak takto: [net] .... [ethx IN]->[IFBx]->[ethx NF_PREROUTING][DNAT] ... [lan]

[Thunder.m]

jj, toto jsem zjistil bohužel včera, když jsem zkoušel IFB vedle na routeru, MARK pomocí iptables prostě nechodí :(

[Thunder.m]

Neexistuje nějaká možnost jak na IFB aplikovat rozdělení pomocí layer7 filtru?

[Orrie]

Obavam se, ze neni. Je vsak otazkou na co ti imq slouzi. Pokud na tom routeru co shapujes nebezi zadne sluzby (squid, apache, ftp, router sam negeneruje ani neprijma zadny provoz) a imq pouzivas pouze pro spojeni odchoziho provozu do lan pres vice rozhrani tak to s ifb lze take udelat. V odchozim smeru se provoz presmeruje do ifb az po NETFILTER, takze uz mas DNATovane pakety a muzes je omarkovat pomoci L7 filteru.

[Thunder.m]

nenapověděl bys mi trochu nějakým příkazem jak to udělat?

[Thunder.m]

Jinak samozřejmě že používám IMQ hlavně na tranzitních routerech, takže jediný lokální traffic bude snmp, ssh a dns, což mi nevadí.

[Orrie]

Neco takoveho by mohlo fungovat:
modprobe ifb numifbs=1
ifconfig ifb0 up
# presmerovani odchoziho provozu z eth 1,2,3 do ifb0
tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0
tc filter add dev eth2 parent 1: protocol ip prio 1 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0
tc filter add dev eth3 parent 1: protocol ip prio 1 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0
# na ifb0 asi povesit nejaky classful qdisc
tc qdisc add dev ifb0 root handle 1 htb default 90 r2q 1
tc class add dev ifb0 parent 1: classid 1:2 htb rate 256Kbit
tc class add dev ifb0 parent 1:2 classid 1:10 htb rate 192Kbit ceil 256Kbit prio 0
tc qdisc add dev ifb0 parent 1:10 handle 10 pfifo limit 32
tc filter add dev ifb0 parent 1:0 protocol ip prio 10 handle 0x110 fw classid 1:10
tc class add dev ifb0 parent 1:2 classid 1:90 htb rate 64Kbit ceil 256Kbit prio 7
tc qdisc add dev ifb0 parent 1:90 handle 90 sfq perturb 10

Osobne jsem to nezkousel, je to ciste teorie. Vyzkousej a dej vedet jestli to funguje.

[Thunder.m]

Ano to funguje tak jak má, jen je ještě nutné předem vytvořit na daném rozhraní (eth1 eth2 eth3)

"$TC qdisc add dev eth1 root handle 1:0 prio"

hlavní třídu (jestli jsem to napsal správně). Problém je pouze ten že já QoS nechci používat na hlavní bráně. QoS chci použít na router kde každé rozhraní bude komunikovat s každým rozhraním a to ještě o různých rychlostech, tam se toto použít bohužel nedá.

[Orrie]

IFB (drive dummy) je relativne mlada vec a tyto "nedostatky" se mozna casem vyresi. Vzhedem k tomu jak IFB pracuje si to ovsem nemyslim. Myslim, ze kazdemu kdo cte nas minithread je jiz jasne, ze v soucasne dobe je v urcitych situacich IMQ nenahraditelne. Mozna dalsi namet pro autora tohoto serialu. Osobne s IMQ problemy nemam, ale pravdou je, ze se jedna o boxy kde traffic nepresahuje 4mbps. Ze zacatku jsem mel problemy v kombinaci IMQ s NETKEY (native ipsec stack), ale to je znamy problem a je zdokumentovano jak to obejit.

[Thunder.m]

Já potřebuju routovat a omezovat traffic v desítkach Mbitů, případně i ve stovkách, zároveň například pro kernel 2.6.18 ještě patch ani není. Jako další nedostatek je to že asi neni možné shapovat poloduplexní zařízení, což s IMQ taktéž jde. Jediné co mě teď napadá jak vyřešit tento problém je přepsat celý skript aby místo layer7 filtru používal pro třídění paketů tc, ale moc si nedokážu představit jak to snadno udělat, nebo filtrovat jen jeden směr a ten druhý pouze omezit na určitou rychlost.

[Margi]

Neposkytl bys, pls, ten upraveny patch? Ta nestabilita se nemusi projevit vsude a ja nyni nutne potrebuju 2.6.18 jadro a v nem imq. Dik Ke stabilite - na 2.6.17.11 mam 8 imq rozhrani s celkovym traffikem hodne pres 100mbit a uptime 50dni od posledniho rucniho rebootu, nepadlo mi to nikdy...

[thiemel]

Dobrý den, chyba je přímo ve zdrojáku IMQ... "Intuitivně" jsem ho "patchnul" a očividně mi server (AMD X2 3800+) jede bez dalších "SOFT LOCKUP DETECTED on CPU#O"

Patch je zde:

--- imq.c.orig 2006-11-18 00:08:42.000000000 +0100 +++ imq.c 2006-12-17 23:34:03.000000000 +0100 @@ -201,13 +201,14 @@ ret = 0; } } - if (spin_is_locked(&dev->xmit_lock)) - netif_schedule(dev); - else - - while (!netif_queue_stopped(dev) && - qdisc_restart(dev)<0) - /* NOTHING */; + + +if (spin_trylock(&dev->xmit_lock)) { + qdisc_run(dev); + spin_unlock(&dev->xmit_lock); +}else{ + netif_schedule(dev); +} spin_unlock_bh(&dev->queue_lock);

[thiemel]

--- imq.c.orig 2006-11-18 00:08:42.000000000 +0100
+++ imq.c 2006-12-17 23:34:03.000000000 +0100
@@ -201,13 +201,14 @@
ret = 0;
}
}
- if (spin_is_locked(&dev->xmit_lock))
- netif_schedule(dev);
- else
-
- while (!netif_queue_stopped(dev) &&
- qdisc_restart(dev)<0)
- /* NOTHING */;
+
+
+if (spin_trylock(&dev->xmit_lock)) {
+ qdisc_run(dev);
+ spin_unlock(&dev->xmit_lock);
+}else{
+ netif_schedule(dev);
+}

spin_unlock_bh(&dev->queue_lock);

(mezery si budete muset asi bohužel dosadit sami)

[Tomáš]

Zajímalo by mě, když používám v síti VLANky, jestli musím IMQ přiřadit ke každé VLANce? Díky

[h/atack]

"Vnímavější by možná napadlo hodit na LAN 1, 2 a 3 bridge br0. Tím by se vytvořilo jedno virtuální zařízení, které by dokonce umožňovalo, aby byly všechny podsítě ve stejném rozsahu. Je to velice dobrý nápad, avšak má jednu drobnou chybku. Na br0 se nedá provádět shapování, protože iptables na něj neplatí (i když někdo tvrdí, že mu to iptables dokáže) a je k dispozici pro konfiguraci balíček ebtables. Takže pokud má někdo nakonfigurovaný bridge, tak bude stejně asi muset sáhnout po imq."

Toto neni pravda, pokud mate linux jako router (a o tom tenhle serial je, ne?) a udelate si na nem bridge z nekolika (ne vsech) fyzickych rozhrani, br0 bude mit ip adresu a je to stejne zarizeni jako napr. ethernet a muzete na nej tedy pouzivat i iptables a QoS (ja to takto provozuji bez problemu s HTB). Vase pripominka plati pouze v pripade, ze z linuxu delate switch a ne router, tedy neprochazi "skrz" nej zadna data a ani nemusi mit IP adresu (i kdyz kvuli vzdalene sprave si ji tam zrejme date).

Jinak hezky clanek, uz o pouziti IMQ uvazuji dost dlouho, ale stale cekam, az se to vic usadi a pripadne dostane do distribucniho jadra.