classic.ISPforum.cz

Mám Mikrotik RB751G-2HnD s procesorem taktovaným na 400MHz a nedávno jsem si nechal zrychlit internet na 50/5 Mb/s (přes VDSL). Od té doby však mám problém dosáhnout té maximální rychlosti, jelikož to brzdí právě Mikrotik. Jak jsem zjistil, když vypnu pravidla v mangle a také queues tree, jede to na max, ale jakmile to zapnu, spadne to na 30 Mb/s a to při pouhém testu rychlosti na webových stránkách (např. rychlost.cz, speedtest.net a další), když nic jiného přes něj v podstatě neteče. Samotná QT bez pravidel v mangle to srazí o 10 Mb/s a zapnutí mangle pravidel to srazí o dalších 10Mb/s.

Z tohoto důvodu jsem se začal zajímat o optimalizaci pravidel v jednotlivých tabulkách. Mám 65 pravidel v mangle tabulce, 26 pravidel ve firewallu a 6 pravidel v NAT tabulce. Předpokládám, že největším problémem bude asi mangle tabulka, ale zoptimalizovat by asi potřebovali všechny, protože to jsem nečekal, že to nezvládne ani blbých 50 Mb/s.
V mangle mám pouze pravidla pro prioritizaci provozu, přičemž nejprve nastavuji značku spojení a na základě této značky pak označuji jednotlivé pakety. Největší část značkování probíhá dle čísla cílového portu, ale mám tam i několik pravidel založených na L7 a na address listech. Chtěl bych se zeptat, zda existuje nějaké obecné doporučení (např. co doporučují na školeních Mikrotiku), jak poskládat ta pravidla za sebe a případně, zda a za jakých podmínek je dělit na uživatelské chainy a podobně. Ideální by bylo vytvořit takovou zjednodušenou "kuchařku", jak při optimalizaci postupovat, aby to vedlo ke snížení zátěže procesoru (aby se pouze nezkomplikovala samotná pravidla a nesnížila jejich čitelnost a přehlednost bez pozitivního výsledku ohledně zatížení procesoru).

Nebo myslíte, že optimalizací to nepůjde odstranit a že bude potřeba pořídit novější a výkonnější router?

Poněkud hnidopišská, ale přesto: RB751G-2HnD neexistuje. Máš tedy RB751U-2HnD, RB951-2n, RB951Ui-2HnD, RB951G-2HnD, nebo ještě něco jiného? Na tom pak záleží, jestli je tvůj router dostatečně výkonný. Pokud ovšem nemáš RB951-2n, tomu by mohlo dát zahulit už QT sama, obecně ale těžko říct bez konfigurace, bylo by vhodno, abys ji sem uvedl. Spusť v terminálu RB tyto příkazy:


Výstup zkopíruj do texťáku a vlož sem, samozřejmě citlivé údaje co nechceš zveřejňovat nějak skryj (třeba IP adresu jako A.B.C.2/24 místo 172.16.0.2/24, ale ať je poznat, která je která a podobně). Co se optimalizace obecně týče, prvně se rozhodni, jestli opravdu chceš/potřebuješ využívat všechny funkce. Počty pravidel ve firewallu a NATu jsou v pohodě, mangle s QT už něco udělají a L7 to zabíjí jistě nejvíce.

Nebo se na všechno vy**r, kup RB2011 (musíš-li mít v RB wifi) nebo RB3011 (pokud jako wifi používáš něco jiného nebo použiješ své stávající RB), nalij to tam a vystaráno.

Kuchařka asi neexistuje. Každý, kdo s tím dělá déle a více má své určité postupy, založené jak na znalosti interních věcí, tak prostě praxe. Sepsat to by bylo dost složité (tím netvrdím, že to neexistuje). A při hledání nezapomeň na to, že se jedná o Linux, netfilter, iptables a htb ... pro linux asi najdeš lepší informace.

Naprosto základní věc: každý paket jde v každé tabulce odshora dolů, dokud není akceptován, nebo zahozen. Čili optimalizace spočívá v tom, aby šel jen naprosto minimálním počtem pravidel. Klasická technika je "stromeček" (většinou se hodí pro Mangle kvůli QT) - první úroveň jsou odskoky podle sítí do chainů, kde už jsou jednotlivé IP a konec každého listu je accept.

Čím méně pravidel, tím výkonnější. Např. než kontrolovat každou IP zvlášť tak udělat address-list. Nebo prostě složitější podmínky, ale v rámci jednoho pravidla.

Pak se lze vůbec zamyslet nad tím, jak je ADSL stabilní na rychlosti a zda má vůbec nějaký smysl provádět QOS (mohlo by stačit to značkovat DSCP a nechat to na modemu - třeba to umí; nebo prostě nic).

A jak psal Myghael - L7 je vrah.

Lze se naučit pracovat (já to nepoužívám ...) s fast-path, nebo spíš fasttrack neboť máš NAT a QT. To dokáže též hodně ušetřit.

A rozhodně se špatně radí, když nevidíme konfiguraci.

Ok, beru. Ale moc jich asi nebude, však? Těch co jsem zmínil, mi rukama prošly desítky, ne-li stovky, ale tohle jsem v ruce nikdy neměl.

Níže můžete vidět pravidla, která mám v mangle. Ten model routerboardu je skutečně ten, co jsem napsal, protože jsem to zkopíroval přímo z winboxu. Co se týká potřeby těch pravidel, dokud jsem je neměl vytvořené, nešlo mi pořádně přehrávat ani internetové rádio. Když jsem třeba stahoval aktualizace do mobilu, začalo rádio škytat a pak se to utrhlo úplně. Je pravda, že to dělalo na wifině, ale takové rozdělení podle služeb je asi potřeba v každé síti.

Tak s touhle nudlí ... to jsem na někoho zvědavý

Ber to tak, že naprostá většina těch pravidel je konzultována s prakticky každým paketem. A ještě podpořena tím L7 na nejpoužívanějších portech. Být tebou tak to řeším hrubou silou a pořídím si něco výkonnějšího jako router.
Ty L7 ti stejně asi moc nefungují, protože:

L7 matcher collects the first 10 packets of a connection or the first 2KB of a connection and searches for the pattern in the collected data.

A když to omezíš na connection-state=new, tak vidí jen jeden paket.

Pokus se alespoň o ten stromeček. Spoustu portů máš skoro shodných. Tedy např. pro 80,443 udělat odskok do extra chainu, tam si udělat ty svoje marky a na konci accept. A tak podobně. Těmi pravidly pak nepolezou jiná spojení, třeba SSH ... Plus se to pokus seřadit tak, aby to víc používané bylo víc na začátku. A minimalizuj potřebu passthrough=yes
Typická ukázka je také hned ten první řádek. Tamtudy projde vždy všechno (byť jen první paket), ale nějak významně je to potřeba jen pro DNS. Bych to dal spíš až na konec ve smyslu výjimky "když nic nezabralo, zkus ještě tohle".
Třeba DHCP se neroutuje. Je to jen input na tom routeru. Nějaká priorizace je zbytečnost (když ten paket už přijde, tak přijde, to neovlivníš).

Vymysli si nějaké spojení a jeď si prstem, kolik pravidel bude konzultováno.

Spoustu těch pravidel tam máš dost zbytečně. Vyber si jen to pro tebe opravdu důležité. Opravdu potřebuješ priorizovat jabber nebo whatsapp? Nebo dokonce DLNA, což je stejně funkční jen na lokále. TFTP asi mimo domácnost nepoužíváš a FTP asi také ne, klidně může být zahrnuté v "ostatním nespecifikovaném".

Je to prostě moc podrobný. Když to shodíš jen na pár tříd a ještě rozhodíš tím "stromečkem", tak to možná bude stačit. Možná.

A možná to zkus všechno (mangle i QT) vypnout a použít jen SQ se sfq. Třeba ti to nakonec bude stačit ...

Předpokládám, že tam máš novou verzi ROS. Oni tam mikrotici občas nějaké optimalizace zavedou.

Toto moc nechápu.
DNS prostě ve firewallu dropnu hned prvním pravidlem ( tedy pokud nemáš vlastní DNS server za mikrotikem ). Proč značkovat?
Značkovat DHCP, ICMP, IGMP - proboha proč? Jaber, Whatsapp, DLNA, TFTP můžeš rovnou odstranit.
Jak už zde padlo, smaž všechna pravidla služeb které nepoužíváš.
V podstatě mikrotik přetěžuješ naprosto zbytečně.

Díky za nakopnutí. To řazení těch pravidel jsem udělal na základě myšlenky, že co "nepropadne" jemným sítem na L7, to se dostane do HTTP se stejným portem, ale je pravda, že pro ten procesor je to asi záhul. Mimochodem ta kontrola těch prvních 10 paketů u L7 probíhá automaticky nebo je nutno to explicitně nějakou podmínkou v pravidlu omezit?
Ještě se zeptám, je pro procesor více zatěžující jedno složitější pravidlo nebo více jednoduchých pravidel (tedy, když by se to složité rozhodilo na více jednoduchých)? Někde na wiki Mikrotiku jsem viděl ukázku rozhození paketů podle typu spojení (TCP a UDP) do dvou chainů a následné testování jednotlivých paketů už bez této podmínky a bylo tam napsané, že to je také méně zatěžující, protože ten test typu spojení se provede jen jednou a ne v každém pravidlu. Jaký na to máš názor, resp. zkušenost?

A simple queue by zvládlo prioritizovat provoz? Na několika místech na internetu jsem se dočetl, že to na to není určené (nebo vhodné) a že se má používat právě QT s manglováním.

Co se týká toho výkonnějšího routeru, co bys řekl na ten nejnovější model pro domácnost hAP ac2? Ten mě docela zaujal. Jak Myghael doporučoval ten RB2011 a 3011, ty jsou bez wifi a to bych potřeboval. Navíc při porovnání těch výkonnostních tabulek u jednotlivých modelů by ten nový routerboard měl být výkonnější než ty dva.

Sutrus:
DNS se může dropnout? To pak přece nebude fungovat nebo jo? WhatsApp tam mám kvůli tomu, že když přes něj voláme, tak aby tam nebylo velké zpoždění a pak také aby se neztráceli pakety, protože pak té protistraně není rozumět.
Jinak to značkování těch dalších síťových služeb (jako je ICMP a spol) jsem udělal podle několika munstrů na internetu, přičemž ve všech bylo ukázáno, že služby sítě by měli mít nastavenou nejvyšší prioritu.

Jak píšu, pokud neprovozuješ vlastní dns server na síti tak se dokonce musí dropnout.
Jinak se jedná o bezpečnostní díru a mikrotik lze zneužít k DDOS útoku.
Mimochodem pak dochází ke zpomalení internetu.
Toto platí za předpokladu že máš v DNS mikrotiku zapnuto Allow remote request, což defaultně je.


ether1 je port do internetu


Služby sítě a jejich priority doma vůbec neřeš.
Pokud neprovozuješ velkou páteřní síť tak to nedělá vůbec nic.
Nikdy se nedostaneš na limity propustnosti domácí sítě.

Takhle jak to popisuješ je to vytržené z kontextu.

sutrus píše:Jak píšu, pokud neprovozuješ vlastní dns server na síti tak se dokonce musí dropnout.

Byly nám ukázány jen mangle pravidla. Ale už ne filter tabulka. Čili nevíme, jak to vlastně je. A je předpoklad, že na MK není DNS resolver a jsou používány přímo DNS z venku. Pak už je priorizace (když už to dělá ...) na místě.

Ale jinak ano. Pokud má zapnutý DNS resolver v ROS (nebo v LAN), musí zároveň zajistit, aby nešel použít přes WAN rozhraní.

SQ jako takové nepriorizuje. Ale dělá to právě to SFQ - snaží se držet "balanc" v rámci jednotlivých spojení. Ono to většinou stačí ...
Pokud by se např. použilo PCQ, tak to balancuje podle IP.

Radek.Kovacik píše:A simple queue by zvládlo prioritizovat provoz? Na několika místech na internetu jsem se dočetl, že to na to není určené (nebo vhodné) a že se má používat právě QT s manglováním.

Ber to tak, že se stejně snažíš řídit něco, co se řídí špatně - tedy tvůj download. Pokud ti ten paket někdo pošle, tak ti prostě přijde - teprve potom v tom děláš nějaké brikule a snažíš se to míchat tak, abys to jednou věcí nezahltil. Což je prostě problematické. Vcelku schopně to funguje pro TCP, ale už ne pro UDP. Tu slabou linku mezi DSLAM a tvým modemem prostě pod kontrolou nemáš.


Dobře dokážeš řídit jen to, co posíláš ty. Čili prakticky vzato řídíš buď upload do internetu nebo upload z tvého routeru do LAN (a tam už problém být nemusí, LAN bude mít větší kapacitu). Na wifi si to pak komplikuješ tím, že nikdy nevíš jakou rychlost vlastně řídíš. No prostě bordel.


Tím nechci říci, že to nejde ... ale že jednodušší možnost může být dostatečná, protože dokonale to nedokážeš.

Já tvrdím, že jedno složitější bude výkonnější. Ten test sám o sobě asi může být složitější - ale zase je proveden jen a pouze jednou.
Typicky je to vidět třeba ve filter tabulkách, kde na prvním místě je accept pro established,related a pak máš jistotu, že všechny ostatní pravidla se týkají jen stavu new (resp. těch ostatních stavů, z hlavy teď nevím). Nemusí se tedy stav nejenom testovat, ale zároveň to zajistí, že všechny pakety chodí jen jedním pravidlem - a pouze první z každého spojení projde i tím zbytkem.

Radek.Kovacik píše:Ještě se zeptám, je pro procesor více zatěžující jedno složitější pravidlo nebo více jednoduchých pravidel (tedy, když by se to složité rozhodilo na více jednoduchých)?

Neporovnával jsem. Ale papírově je řádově výkonnější, než co máš teď.
RB2011 se podle mě s wifinou ovšem vyráběl.

Radek.Kovacik píše:Co se týká toho výkonnějšího routeru, co bys řekl na ten nejnovější model pro domácnost hAP ac2? Ten mě docela zaujal. Jak Myghael doporučoval ten RB2011 a 3011, ty jsou bez wifi a to bych potřeboval. Navíc při porovnání těch výkonnostních tabulek u jednotlivých modelů by ten nový routerboard měl být výkonnější než ty dva.

Pokud priorizuješ a používáš nějaký voip, tak ho tam nějak zabudovat musíš.
Ale věci typu ICMP tebe jako koncového uživatele nijak zvlášť netrápí. Akorát pak ten ping vypadá lépe, než by ve skutečnosti měl ...

Radek.Kovacik píše:WhatsApp tam mám kvůli tomu, že když přes něj voláme, tak aby tam nebylo velké zpoždění a pak také aby se neztráceli pakety, protože pak té protistraně není rozumět.
Jinak to značkování těch dalších síťových služeb (jako je ICMP a spol) jsem udělal podle několika munstrů na internetu, přičemž ve všech bylo ukázáno, že služby sítě by měli mít nastavenou nejvyšší prioritu.

ludvik píše:RB2011 se podle mě s wifinou ovšem vyráběl.

Záleží na konkrétním typu. Třeba tento ji má, ale většina ne:
https://mikrotik.com/product/RB2011UiAS-2HnD-IN

Kdyby si měl zájem mám na prodej RB1100ahX2, ten zvládne tohle všechno a bude se přitom ještě štourat v nose... V případě zájmu sz.