Provoz neuvedený v QT

[Rosak]

Ahoj, prosím Vás o vysvětlení.
QT, „global“ s Max limitem, podřízená pravidla pro každou IP adresu (up i down zvlášť). Některá pravidla dostanou MAX limit, jiná nikoli, ale všechna budou mít nastavenou nějakou prioritu. Jak bude RoS nakládat s provozem IP adresy, která nebude v QT uvedena? Dostane přednost před ostatním provozem uvedeným v QT, nebo je to jinak?

[patrik_]

Neomanglované IP adresy, která nemá queue si vůbec nebude všímat (stejně jako omanglované bez queue).
Řeší se to tak, že vezmeš celou svoji sít, tedy pokud je to třeba 256 adres, tak v ip firewall mangle
a) u každého předchozího mangle omangluješ spojení a packet, potom nesmí mít passthru povoleno-jeho cesta končí v tom konkrétním maglu
b) protože manglování probíhá sekvenčně, omangluješ veškerý provoz sítě řekněme 192.168.1.0/24 a tento mangle dáš až na konec manglovacích pravidel
c) vytvoříš queue která bude childem hlavní queue a tam nastavíš prio a rychlost pro neoznačené IP adresy.
Typicky se to dělá pro IP adresy, které nemáš v síti použity a jedou "black" pomalou rychlostí třeba 128k, a to z toho důvodu,
že kdybys připojoval další klienty a tento neznámý provoz zahazoval, musel bys vždycky přidávat nového klienta na whitelist,
což je při větší síti a servisech klientů, kdy je taky někdy přepojuješ na jiný sektor/ap šílenej vopruz.
I když u nového klienta jedeš pooomalinku, na terminály ve kterých si tu rychlost následně nastavíš, to bohatě stačí.

Jinými slovy ROS bude s provozem z IP adres které nejsou nijak označeny nakládat velmi podobně jako HTB a iptables.

[Rosak]

Patriku, děkuji za odpověď.
Z pohledu ISP tomu takhle rozumím, spíš jsem uvažoval (a neupřesnil) o teorii, kdy MT dělá pouze router (třeba ve firmě), rychlost je vyhrazených 10M, ale ISP dává většinou více. Hlavní queue bude mít max-limit těch 10M a queue pod ní dostanou různou prioritu podle uživatele (sekrterářka, obchodníci, účetní, sklad..), případně bude ještě některá z nich omezena svým max-limitem. Pokud chci pro jednu IP (majitel) nechat dostupnou rychlost (tedy více než těch 10M, pokud jsou aktuálně k dispozici), neuvedu ji v QT. A teď co se stane, začne-li tato IP a některá z IP z QT stahovat maximální dostupnou rychlostí? Jakou bude mít prioritu IP neuvedená v QT proti IP v QT uvedené? A tím pádem jak se budou o dostupnou rychlost dělit? Bude záležet na protokolu, nebo bude schema vždy stejné?
Jednou jsem tento model řešil tak, že jsem na hlavní queue nedal max-limit, pod ni strčil queue s vysokou prioritou a žádným max-limitem pro "vyvolenou" IP a druhou queue s max-limitem (řekněme těch 10M) a nižší prioritou a do ní pak nasázel všechny ostatní IP a těm opět rozdělil priority v rámci této queue. Moc jsme to neřešil, ale myslím, že to fungovalo dobře. Ale zajímá mě jak by to vypadalo podle prvního modelu s neuvedenou IP adresu
A ještě mi, prosím, pověz jaký je rozdíl mezi tím, když mangluji spojení a paket, nebo rovnou pouze paket.

[patrik_]

IP neuvedená v QT vůbec nebude shapována, což způsobí, že pokud bude požadovat data, pojede naplno, což způsobí, že na vstupu QT nebudeš mít předpokládanou garantovanou rychlost k přerozdělování, což způsobí, že ti celý ten shaping nebude fungovat korektně, v krajním případě vůbec.
Tohle se řeší pomocí limit-at (CIR) a priority. Shapovat tak aby to fungovalo správně, musíš všechny adresy a ne se na nějaké vykašlat s tím že automaticky budou mít nejvyšší rychlost a prio.
Lze to tak, ale pro správnou funkci musí být VŽDY na vrcholu stromu doručena a zaručena rychlost max-limit, jinak celý strom počítá s hausnumery a přiděluje klientům rychlosti, které na vstupu nemá takže to nefunguje dobře.
http://wiki.mikrotik.com/wiki/Manual:HTB#Example_1_:_Usual_case

[Rosak]

Děkuji. Vidím, že jsem dříve při studiu nedával pozor
Tím pádem lze využít konektivitu, kterou mám negarantovanou pouze tak, že u nějaké IP adresy na chvíli vypnu její queue (pojede mimo QT), ale tím zbořím zbytek QT.
A pokud neuvedu limit-at u jednotlivých queue, IP adresy s vyšší prioritou vyžerou konektivitu IP adresám s nižší prioritou úplně.

[patrik_]

Jojo, tak to je.
Další z možností máš udělat shaping tak, že prvních X bytes definovaných konexí, např. http dostane vyšší prio a rychlost, čímž dosáhneš rychlého načítání stránek i když někdo bude sosat na plno v síti.
Pokud na vstupu nemáš garantovanou rychlost, tak si jako maximum zvol nějakou střední, pod kterou to typicky nepadá.. a stejně to nakonec bude chodit líp než bez shapingu

[Rosak]

Děkuji za rady.