Dotaz: IMQ a pomíchaný IN/OUT traffic

[......]

Řeším jedno dilema ohledně QoS a shapingu. Mám dva směry IN a OUT na nějaký router. Běží na něm i nějaké služby jako ssh a mailserver. Oba tyto směry mají nějakou rychlost, dejme tomu 1 Mbit.

Aby mi to správně shapovalo, musím uživatelský traffic směrem dovnitř sítě a vše co mi přichází router jako ingress řadit do společné třídy, protože je to jeden směr (IN). Rozdělil bych-li to na dva (na eth0 download a na imq0 ingress) tak o sobě nejvyšší třídy nebudou vědět a budou špatně půjčovat rychlost ostatním podtřídám.

Napadlo mě tedy narvat oba tyto druhy traffiku do IMQ. Narvu tam tedy jeden postrouting (data k uživatelům) a jeden prerouting (data na server), jak je psáno v manuálu od IMQ. Pro opačný směr provedu totéž, jen zaměním síťovky. Pak stačí jen správně filtrovat, teda podle mého názoru.

Otázka je, zkoušel to už někdo? Je to možné takto prakticky provést? V manuálu od IMQ dávájí dohromady vždy jen postrouting nebo jen prerouting, neviděl jsem, že by to tam míchali. Skript jako takový mám napsaný, jen bych ho bez konzultace nerad hodil do provozu a pak se nestačil divit.

Díky za každou radu nebo postřeh.

Odpovědi

[Jirka Chráska]

Dobrý den.
Pošlete prosím onen skript, IMQ používám v ostrém provozu. Zkusíme se na to společně podívat.

[......]

No já používám taky IMQ v ostrém provozu, ovšem v opačném případě, než jsem popsal. Tohle by mělo být "vychytanější", jen nevím jak se zachová IMQ. Jestli nespadne celý router, nebo se to nezačne chovat podivně. Proto se ptám na radu. Skript bohužel nepošlu, protože mi zabral jistou dobu mého času a je v něm zahrnuto kde co. Zkrátka kompletní QoS a shaping pro celou jednu síť. Nerad bych ventiloval do světa to, co mi dalo tolik práce a musím uznat je opravdu funkční. Tohle byla jen taková další vychytávka, co mi ležela delší dobu v žaludku. Jde mi zkrátka jen o to, zda IMQ virtuální zařízení rozdýchá, když do něj budu posílat přes iptables data jak z preroutingu tak postroutingu. V manuálu IMQ jsem takové použití neviděl.

Každopádně děkuji za vstřícnost.

[xxl]

IMQ na kernelu 2.4 zvládá mixnutý prerouting i postrouting. Na kernelu 2.6 s tím byl nějaký problém, který už je snad vyřešen.

[Max]

Přesně asi nechápu, o co se snažíš (že by router s nějakýma lokálníma službama a chceš, aby i ty lokální služby spadaly do shapingu ?). Snažíš se umístit jakoby dvě imq do jednoho směru? Nebo hnát přes jedno imq jak prerouting, tak postrouting? To první fungovat nebude, víc jak jedno imq zařízení v jednom směru způsobí vypnutí/znefunkčnění těch ostatních a bude fungovat pouze poslední vytvořené. Přesměrování jak prerouting, tak postrouting do jednoho imq jsem nezkoušel. Abych pravdu řekl, tak ani nevím, k čemu by to mohlo být dobré :-/. Když přesměruješ do imq provoz v preroutingu, tak už je zbytečné do něj přesměrovávat i v postroutingu (myslím tím prerouting na eth z netu a postrouting na eth do vnitřní sítě. Prerouting a postrouting na jednom eth je omezování v obou směrech, takto to asi nemyslíš). Taky je možné, že jsem tě nepochopil. Jen doufám, že jsem se teď do toho příliš nezamotal :)
Zdar Max

[......]

Chci do jednoho IMQ zařízení házet postrouting z eth0 a prerouting z eth1 a do druhého IMQ zařízení házek postrouting z eth1 a prerouting z eth0 (je to simulace jednoho a druhého směru).

Můsím totiž rozlišovat různé věci v každém směru:

1) Ve směru od ISP na můj router je to ingress provoz na můj router a pak data co forwarduji do vnitřní sítě včetně traffiku, který je lokální (např. lokální ftp).

2) Opačným směrem je to pak obráceně. Tj. ingress na lokálu, to co forwarduji od uživatelů k ISP a vše co jde přímo z routeru do netu (ssh, maily, icmp).

Proto jsem chtěl vědět, jestli IMQ zařízení rozdýchá narvu-li do něj jak prerouting tak postrouting a to z různých zařízení.

[......]

Abych upřesnil co jsem chtěl říct. Pokud hodím do IMQ jen prerouting, tak v něm není obsažen provoz vznikající na routeru. Hodím-li tam jen postrouting, tak tam není obsažen provoz mířící na router. To je přesně to co jsem chtěl říct. Pokud by ten router neposkytoval žádné jiné služby a jen routoval, tak tahle komedie odpadá.

[secido]

Ja mam v routeri 4 sietovky na eth1 je jedna siet na eth2 je druha, eth0 do netu. Lokalna adresa servera je 192.168.1.1.

iptables -t mangle -A PREROUTING -d ! 192.168.1.1 -i eth1 -j IMQ --todev 0
iptables -t mangle -A PREROUTING -d ! 192.168.1.1 -i eth2 -j IMQ --todev 0

iptables -t mangle -A POSTROUTING -s ! 192.168.1.1 -o eth1 -j IMQ --todev 1
iptables -t mangle -A POSTROUTING -s ! 192.168.1.1 -o eth2 -j IMQ --todev 1

Takto mi to bezi bez problemov. Myslim, ze funkcnost imq je celkom jasna a jednoducha, na zariadenie napchas pakety a potom shapujes. Inak je skvele, ze chces od inych aby radili a ked chcu nieco od teba, tak povies, ze nedas .

[......]

To co jsi napsal, tak něco podobného používám i já jenže má to tu nevýhodu, že mám zvlášť traffik na router a traffik do sítě (forward). Jestli to nechápeš tak problém je tu:

Každé IMQ zařízení má nastavenou nějakou rychlost (dejme tomu 1Mbit).
ISP mi dává v obou směrech 1Mbit ....do teď je to pohoda.

Jenže:
Traffik jdoucí od ISP k uživatelům jde přes imq0 a traffik na router mi míří do imq1. Protože jak je psáno v manuálu od IMQ, v imq zařízení kam míří prerouting se omezuje ingress. Takže každé tohle zařízení má nastavený strop na 1Mbit a půjčuje ho podle nastavení. Problém nastává v tom, že navzájem o sobě neví, ale z pohledu ISP je to furt směr směrem k mému routeru. Takže já půjčuju 2x 1 Mbit, který nemám. A o to mi celou dobu jde.

K tomu dávání/nedávání. Shlédl-li jsi někdy ve svém životě můj web, tak jistě víš, že tam takovýchto skriptů vedu plnou pr**l. Jakmile považuju skript za funkční a nějakou dobu ho mám v provozu, tak ho mrsknu na web.

Jinak taky nevím, jak by se ti líbilo, kdyby jsi třeba měsíc nad něčím seděl, přečetl tuny manuálů, how-to, man stránek a pak ti někdo řekl dej mi to. Je to kompletní QoS celé sítě i se shapingem, zahrnující jak LAN síť, tak Wi-Fi tak upřednostnění internetového provozu a VoIP.

Za další myslím, že jsem ho odmítl slušně.

[Max]

Abych pravdu řekl, tak cpát do něj jak PREROUTING, tak POSTROUTING z různých zařízení jsem nezkoušel :-/. To asi ještě pořádně prošetřím :). Ale myslím, že je to tak nějak skoro zbytečné .
eth0 = net; eth1 = vnitřní síť

iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0
iptables -t mangle -A POSTROUTING -o eth0 -j IMQ -todev 1 (nebo 0)

Pokud máš imq zkompilované ve schématu AB => after nat on PREROUTING and before nat on POSTROUTING, tak ti půjde omezovat jak download, tak i upload na vnitřní síti a na lokálu na serveru na dvou imq0 a 1 , nebo ne jednom imq0, podle toho, kam budeš chtít nacpat ten upload v druhém příkazu. To by jsi mohl i za normálních okolností, ale pokud použiješ schéma AB, tak můžeš na imq zařízení shapovat s pomocí u32 a zdrojových ip a nemusíš používat markování.(pokud ho nyní používáš).
Včera jsem poslal článek o imq a teorii shapingu Robertovi, tak snad by mohl někdy v příštím týdnu vyjít.
Zdar Max

[......]

Díky za poznatky. Na to jaké používám schéma IMQ se nechci spoléhat. Chci to udělat univerzálně, abych to mohl kdykoli, kdekoli nasadit, ať je tam IMQ jaké chce. Ano markuji pomocí iptables. Přijde mi to tak nějak lepší...ani nevím proč. Asi kvůli přehlednosti a pak stejně to markování využívám ještě jinak.

Dneska se na to asi vrhnu a dodělám to do konce a asi to na drzo prubnu na nějakém routeru, který nemá takové prio. Dám vědět jestli je možné pomíchat prerouting a postrouting z různých zařízení do jednoho IMQ.

[Max]

Markování je super věc, to ano, ale uvádí se (ozkoušené to nemám, nemám kde), že je to náročnější na výkon PC apod. Takže při markování v tisících už je markování tabu. Taky nevím, jaký je rozdíl v latencích mezi u32 filtrem a markováním. Zkusím to doma nějak otestovat.
Zdar Max

[Max]

Jinak překopání schéma imq je otázkou 5 minut (na mém PC to mám za 2 min)
Zdar Max

[......]

Překopání IMQ je opravdu snadné....mám zde zahrnut imq-nat.diff patch, takže v IMQ jsou pakety ještě před samotným NATem, ale jak jsem psal chci to dělat univerzálně. Takže na tohle nechci spoléhat.

Shapuju-li ale jako doposud na 4 zařízeních a chci-li shapovat jen na dvou, tak musím celý návrh shapingu značně přepracovat. Většinu za mě sice udělají cykly, ale i tak základní návrh tříd musím udělat ručně.

K markování paketů: nevyužívám jej jen na správné řazení do tříd, ale i na různé statistiky, počítadla a různé krávoviny, které pomáhají při provozu na síti. Výkon mě až tak netrápí, protože dnešní PC to v pohodě stíhají

[Max]

Já ten patch nepoužívám. Jsem vybaven jen tím, co jsem psal v minulém článku. Myslím, že už je dávno aplikován v offic patchi, od toho je taky to schéma imq zapojení, že :), to by asi potom nemělo smysl, kdyby to nefungovalo.
Tak aspoň nahoď nějakou statistiku, ne? procesor / paměť / datový tok ve špičkách + vytížení pc / počet ip, které shapuješ / jaké služby ti tam běží (mail? http? statistiky apod. ?)
Nebo si myslíš, že tyto údaje by mohly ohrozit bezpečnost tvého serveru? Snad ne :). Díky ..
Zdar Max

[......]

Běží tam ssh, mail, dns, lokální ftp a web. Tu kde to testuju je to jen síťka o něco málo přes dvě desítky IP a megabitem připojení do netu. Ovšem nasazovat to chci i ve dvou firmách, kde je těch PC podstatně víc a potřebuju, aby s tím bylo co nejméně starostí. To že mi to ohrozí bezpečnost, to se nebojím, spíš potřebuju aby to fachalo, protože v těch firmách bude i VoIP a provoz z/na server.

[Max]

To že mi to ohrozí bezpečnost, to se nebojím, spíš potřebuju aby to fachalo, protože v těch firmách bude i VoIP a provoz z/na server.

Myslel jsem ty informace o serveru / serverech, který spravuješ ...
Ale to je jedno ...
Zdar Max

[......]

jeden je postarší dvouprocesorový PIII 500 MHz, a druhý je P4 2 GHz. Nevím co víc bys chtěl vědět....pamětí je v obou případech dost, disky dostačující. Ovšem nevím, nač ti taková informace je a co má společného s IMQ.

[Max]

Už jsem to psal, chtěl jsem vědět vytížení těch strojů a kolik IP na tom vlastně shapuješ apod. Zajímalo mě to vzhledem i markování. To, co jsi teď napsal, je opravdu k ničemu, když jsi neudal počet těch ip a vytížení serverů ... Ale raději toho nechme, čtvrtý upřesňující příspěvek kvůli jendomu dotazu opravdu nechci psát
Zdar Max

[......]

Myslím, že pokud se neshapují stovky IP tak je tato diskuze bezpředmětná. A shapovat se tolik IP adres nebude, takže přemýšlet jestli MARK přes iptables nebo U32 přes tc je vcelku jedno. Každopádně MARK i tak vypouštět nehodlám, protože dělá, jak jsem psal výše, více věcí. Takže je zbytečné zatěžovat stroj ještě dalšími zbytečnými U32 filtry.

[......]

Tak jsem to dneska prubnul a nelze to takto udělat. IMQ spadne a zamrzne celé jádro. Je to škoda

[Max]

Když markuješ, tak je to na nastavení schématu imq stejně jedno, takže to můžeš nechat v preroutingu
Zdar Max
PS:taky myslím, že je stále asi potřeba imq-nat patch pro tan prerouting :-/, zdá se, že to bez něj v preroutingu nejde(u32, markovýání ok v každý situaci) a imq je pořád před natem :-/