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?
❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Optimalizace pravidel
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.
Kód: Vybrat vše
/system routerboard print
/export compact
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.
0 x
Si vis pacem, para bellum.
MikroTik, UBNT, Cisco, TP-Link... rozhoduje vhodnost toho či onoho pro konkrétní použití, ne jaké logo nalepili v Číně na krabici. Na tomto fóru vystupuji jen a pouze sám za sebe.
MikroTik, UBNT, Cisco, TP-Link... rozhoduje vhodnost toho či onoho pro konkrétní použití, ne jaké logo nalepili v Číně na krabici. Na tomto fóru vystupuji jen a pouze sám za sebe.
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.
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.
1 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
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.
0 x
Si vis pacem, para bellum.
MikroTik, UBNT, Cisco, TP-Link... rozhoduje vhodnost toho či onoho pro konkrétní použití, ne jaké logo nalepili v Číně na krabici. Na tomto fóru vystupuji jen a pouze sám za sebe.
MikroTik, UBNT, Cisco, TP-Link... rozhoduje vhodnost toho či onoho pro konkrétní použití, ne jaké logo nalepili v Číně na krabici. Na tomto fóru vystupuji jen a pouze sám za sebe.
-
- Příspěvky: 162
- Registrován: 13 years ago
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.
Kód: Vybrat vše
/ip firewall mangle
add action=jump chain=prerouting comment="Odskok na chain Sitove sluzby z duvo du oznaceni spojeni vsech sitovych sluzeb" connection-state=new jump-target="Sitove sluzby"
add action=add-dst-to-address-list address-list=Skype address-list-timeout= 1w3d chain=prerouting comment= "Komunikace VoIP v realtime provozu - Skype" connection-state=new dst-address-list=!Lokalni_adresy dst-port=80,443,1024-65535 layer7-protocol="Skype ACK" protocol=tcp
add action=add-dst-to-address-list address-list=Skype address-list-timeout= 1w3d chain=prerouting connection-state=new dst-address-list= !Lokalni_adresy dst-port=80,443,1024-65535 layer7-protocol= "Skype to Skype" protocol=tcp
add action=add-dst-to-address-list address-list=Skype address-list-timeout= 1w3d chain=prerouting connection-state=new dst-address-list= !Lokalni_adresy dst-port=80,443,1024-65535 layer7-protocol= "Skype to Skype" protocol=udp
add action=mark-connection chain=prerouting connection-state=new dst-address-list=Skype new-connection-mark=Skype passthrough=no protocol= tcp
add action=mark-connection chain=prerouting connection-state=new dst-address-list=Skype new-connection-mark=Skype passthrough=no protocol= udp
add action=mark-connection chain=prerouting comment= "Komunikace VoIP v realtime provozu - WhatsApp" connection-state=new dst-address-list=WhatsApp dst-port=80,443,4244,5222,5223,5228,5242 new-connection-mark=WhatsApp passthrough=no protocol=tcp
add action=mark-connection chain=prerouting connection-state=new dst-address-list=WhatsApp dst-port=80,443,4244,5222,5223,5228,5242 new-connection-mark=WhatsApp passthrough=no protocol=udp
add action=mark-connection chain=prerouting comment= "Komunikace VoIP v realtime provozu - protokol SIP" connection-state=new dst-port=5060,5061,5064 layer7-protocol=SIP new-connection-mark=SIP passthrough=no protocol=tcp
add action=mark-connection chain=prerouting connection-state=new dst-port= 5060,5061,5064 layer7-protocol=SIP new-connection-mark=SIP passthrough=no protocol=udp
add action=mark-connection chain=prerouting comment= "Realtime provoz - prehravani audio streamu" dst-port=80,443,8000 layer7-protocol="Audio playback" new-connection-mark="Audio stream" passthrough=no protocol=tcp
add action=mark-connection chain=prerouting connection-state=new dst-port= 8000 new-connection-mark="Audio stream" passthrough=no protocol=tcp
add action=mark-connection chain=prerouting comment= "Realtime provoz - prehravani video streamu" dst-port=80,443 layer7-protocol="Video playback" new-connection-mark="Video stream" passthrough=no protocol=tcp
add action=mark-connection chain=prerouting comment= "Realtime provoz - UPnP (DLNA)" connection-state=new new-connection-mark= DLNA passthrough=no port=2869,50002,50001 protocol=tcp
add action=mark-connection chain=prerouting connection-state=new dst-port= 1900 new-connection-mark=DLNA passthrough=no protocol=udp
add action=mark-connection chain=prerouting comment= "Prehravani medialniho obsahu z mistniho NAS serveru na KODI" connection-state=new dst-address=10.0.3.100 dst-port=137-139,445,3020 new-connection-mark=DLNA passthrough=no protocol=tcp src-address= 10.0.3.10
add action=mark-connection chain=prerouting comment= "Komunikacni sluzby - protokol HTTP(S)" connection-bytes=0-1000000 connection-state=new dst-port=80,443 new-connection-mark="HTTP a HTTPS" passthrough=no protocol=tcp
add action=mark-connection chain=prerouting connection-bytes=0-1000000 connection-state=new dst-port=80,443 new-connection-mark="HTTP a HTTPS" passthrough=no protocol=udp
add action=mark-connection chain=prerouting comment="Komunikacni sluzby - spra va a administrace ruznych zarizeni (NAS, router, KODI a jine)" connection-bytes=0-1000000 connection-state=new dst-port= 5000,5001,8291,9090 new-connection-mark=Administrace passthrough=no protocol=tcp
add action=mark-connection chain=prerouting comment= "Komunikacni sluzby - protokoly POP3, IMAP, SMTP" connection-state=new dst-port=25,110,143,993,995 new-connection-mark="POP3, IMAP, SMTP" passthrough=no protocol=tcp
add action=mark-connection chain=prerouting comment= "Datovy provoz - protokol SMB" connection-state=new dst-port= 137-139,445,3020 new-connection-mark=SMB passthrough=no protocol=tcp
add action=mark-connection chain=prerouting connection-state=new dst-port= 137-139,445,3020 new-connection-mark=SMB passthrough=no protocol=udp
add action=mark-connection chain=prerouting comment= "Datovy provoz - protokol FTP" connection-state=new dst-port=20,21 new-connection-mark=FTP passthrough=no protocol=tcp
add action=mark-connection chain=prerouting comment= "Datovy provoz - protokol TFTP" connection-state=new dst-port=69,1758 new-connection-mark=TFTP passthrough=no protocol=udp
add action=mark-connection chain=prerouting comment= "Datovy provoz - protokol SSH, SCP, SFTP" connection-state=new dst-port= 22 new-connection-mark=SSH passthrough=no protocol=tcp
add action=mark-connection chain=prerouting comment= "Datovy provoz - protokol HTTP (download)" connection-bytes=1000000-0 connection-mark="HTTP a HTTPS" dst-port=80,443,5000,5001 new-connection-mark="HTTP download" passthrough=no protocol=tcp
add action=mark-connection chain=prerouting comment= "Datovy provoz - Windows Update a Google Play" connection-state=new dst-port=5223,5228,8530,8531 new-connection-mark=Aktualizace passthrough= no protocol=tcp
add action=mark-connection chain=prerouting comment= "Ostatni provoz - Peer to Peer (Bittorrent)" connection-state="" new-connection-mark="Peer to peer" passthrough=no port=55000 protocol=udp
add action=mark-connection chain=prerouting comment= "Ostatni nespecifikovany a neoznaceny provoz" connection-mark=no-mark connection-state=new new-connection-mark="Ostatni provoz" passthrough=no
add action=jump chain=output comment="Pravidlo pro oznaceni veskereho odchozih o provozu ze samotneho routeru (obvykle sitove sluzby) - odskok na chain S itove sluzby" connection-state=new jump-target="Sitove sluzby"
add action=mark-packet chain=postrouting comment="Pravidla pro oznaceni jednot livych paketu podle znacky spojeni - ostatni provoz" connection-mark= "Ostatni provoz" new-packet-mark="Ostatni provoz" passthrough=yes
add action=mark-packet chain=postrouting connection-mark="Peer to peer" new-packet-mark="Ostatni provoz" passthrough=yes
add action=mark-packet chain=postrouting comment="Pravidla pro oznaceni jednot livych paketu podle znacky spojeni - datovy provoz" connection-mark=SMB new-packet-mark="Datovy provoz" passthrough=yes
add action=mark-packet chain=postrouting connection-mark=FTP new-packet-mark= "Datovy provoz" passthrough=yes
add action=mark-packet chain=postrouting connection-mark=TFTP new-packet-mark="Datovy provoz" passthrough=yes
add action=mark-packet chain=postrouting connection-mark="HTTP download" new-packet-mark="Datovy provoz" passthrough=yes
add action=mark-packet chain=postrouting connection-mark=Aktualizace new-packet-mark="Datovy provoz" passthrough=yes
add action=mark-packet chain=postrouting comment="Pravidla pro oznaceni jednot livych paketu podle znacky spojeni - komunikacni sluzby" connection-mark= "HTTP a HTTPS" new-packet-mark="Komunikacni sluzby" passthrough=yes
add action=mark-packet chain=postrouting connection-mark=Administrace new-packet-mark="Komunikacni sluzby" passthrough=yes
add action=mark-packet chain=postrouting connection-mark="POP3, IMAP, SMTP" new-packet-mark="Komunikacni sluzby" passthrough=yes
add action=mark-packet chain=postrouting comment="Pravidla pro oznaceni jednot livych paketu podle znacky spojeni - prehravani audio a video streamu" connection-mark="Audio stream" new-packet-mark=Audio-video passthrough= yes
add action=mark-packet chain=postrouting connection-mark="Video stream" new-packet-mark=Audio-video passthrough=yes
add action=mark-packet chain=postrouting connection-mark=DLNA new-packet-mark=Audio-video passthrough=yes
add action=mark-packet chain=postrouting comment="Pravidla pro oznaceni jednot livych paketu podle znacky spojeni - realtime VoIP komunikace" connection-mark=Skype new-packet-mark=VoIP passthrough=yes
add action=mark-packet chain=postrouting connection-mark=WhatsApp new-packet-mark=VoIP passthrough=yes
add action=mark-packet chain=postrouting connection-mark=SIP new-packet-mark= VoIP passthrough=yes
add action=mark-packet chain=postrouting comment="Pravidla pro oznaceni jednot livych paketu podle znacky spojeni - sitove sluzby" connection-mark=DNS new-packet-mark="Sitove sluzby" passthrough=yes
add action=mark-packet chain=postrouting connection-mark=DHCP new-packet-mark="Sitove sluzby" passthrough=yes
add action=mark-packet chain=postrouting connection-mark=ICMP new-packet-mark="Sitove sluzby" passthrough=yes
add action=mark-packet chain=postrouting connection-mark=IGMP new-packet-mark="Sitove sluzby" passthrough=yes
add action=mark-packet chain=postrouting connection-mark=NTP new-packet-mark= "Sitove sluzby" passthrough=yes
add action=mark-packet chain=postrouting connection-mark=MNDP new-packet-mark="Sitove sluzby" passthrough=yes
add action=set-priority chain=postrouting comment="Pravidlo pro nastaveni prio rity jednotlivych paketu podle znacky paketu pro Peer to Peer a ostatni ne specifikovany a neoznaceny provoz" new-priority=0 packet-mark= "Ostatni provoz" passthrough=yes
add action=set-priority chain=postrouting comment="Pravidlo pro nastaveni prio rity jednotlivych paketu podle znacky paketu pro datovy provoz - SMB, FTP, \_CIFS a podobne" new-priority=1 packet-mark="Datovy provoz" passthrough= yes
add action=set-priority chain=postrouting comment="Pravidlo pro nastaveni prio rity jednotlivych paketu podle znacky paketu pro komunikacni sluzby" new-priority=3 packet-mark="Komunikacni sluzby" passthrough=yes
add action=set-priority chain=postrouting comment="Pravidlo pro nastaveni prio rity jednotlivych paketu podle znacky paketu pro streamovani, prehravani a udio a video a podobne" new-priority=4 packet-mark=Audio-video passthrough=yes
add action=set-priority chain=postrouting comment="Pravidlo pro nastaveni prio rity jednotlivych paketu podle znacky paketu pro VoIP komunikace v realtim e provozu - Skype, WhatsApp a podobne" new-priority=5 packet-mark=VoIP passthrough=yes
add action=set-priority chain=postrouting comment="Pravidlo pro nastaveni prio rity jednotlivych paketu podle znacky paketu pro vsechny sitove sluzby" new-priority=7 packet-mark="Sitove sluzby" passthrough=yes
add action=change-dscp chain=postrouting comment= "Pravidlo pro zmenu DSCP dle nastavene priority" new-dscp= from-priority-to-high-3-bits passthrough=yes
add action=mark-connection chain="Sitove sluzby" comment= "Sitove sluzby - protokol DNS" dst-port=53 new-connection-mark=DNS passthrough=no protocol=udp
add action=mark-connection chain="Sitove sluzby" comment= "Sitove sluzby - protokol DHCP" dst-port=67,68 new-connection-mark=DHCP passthrough=no protocol=udp
add action=mark-connection chain="Sitove sluzby" comment= "Sitove sluzby - protokol ICMP" new-connection-mark=ICMP passthrough=no protocol=icmp
add action=mark-connection chain="Sitove sluzby" comment= "Sitove sluzby - protokol IGMP" new-connection-mark=IGMP passthrough=no protocol=igmp
add action=mark-connection chain="Sitove sluzby" comment= "Sitove sluzby - protokol NTP" dst-port=123 new-connection-mark=NTP passthrough=no protocol=udp
add action=mark-connection chain="Sitove sluzby" comment= "Sitove sluzby - protokol MNDP" dst-port=5678 new-connection-mark=MNDP passthrough=no protocol=udp
0 x
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:
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.
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:
A když to omezíš na connection-state=new, tak vidí jen jeden paket.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.
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.
1 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
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ě.
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ě.
0 x
-
- Příspěvky: 162
- Registrován: 13 years ago
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.
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.
0 x
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ě.
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.
Kód: Vybrat vše
/ip firewall filteradd chain=input in-interface=ether1 protocol=udp dst-port=53 action=drop
add chain=input in-interface=ether1 protocol=tcp dst-port=53 action=drop
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ě.
1 x
Takhle jak to popisuješ je to vytržené z kontextu.
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í.
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í.
Naposledy upravil(a) ludvik dne 23 May 2018 15:55, celkem upraveno 1 x.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
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.
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š.
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š.
1 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
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.
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.
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 ...
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.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
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
0 x
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.
0 x