classic.ISPforum.cz

Ahoj,

rád bych požádal zkušenější o radu ohledně MK GW. Aktuálně jede CPU ve špičkách okolo 60%.
Cílem je srazit vytížení CPU, nahradit stávající GW. Tu ponechám jako backup.

Rád bych zůstal u SM, můžete mi někdo doporučit nějakou prověřenou konfiguraci?

aktuální HW:
Supermicro SGP-I4
Intel Xeon E3-1230v2 - 3.3GHz
4GB 1600MHz DDR3 ECC Unbuffered
Intel SSD DC S3700 Series
Supermicro STGN-i2S-Dual port 10GbE (SFP+)

RouterOS: 6.42.3
FW : 2200
QueueTree : 4800
NAT : 300
Mangle : 3500

linka ve špičce : 1,2G



díky
L

Ahoj, ten novy hw ma ten puvodni nahradit, nebo doplnit? Jake ulohy ma/maji zastavat?

upraveno.

služby viz, počet pravidel. tj. FW, NAT, Queue.

díky
L

používáš mangle nebo ne? resp. qt nebo sq?

doplneno. qt+mangle.

předpokládám že optimalizovaný mangle máš. Pokud ano tak ti nepomůže nic jinýho než jít do Xeonu E5 s 8 jádry. Jo a taky doporučuju tu optimalizaci udělat i ve filtru.

A pokud je optimalizované nemám, tak mi stačí E3?

hapi píše:předpokládám že optimalizovaný mangle máš. Pokud ano tak ti nepomůže nic jinýho než jít do Xeonu E5 s 8 jádry. Jo a taky doporučuju tu optimalizaci udělat i ve filtru.

Na 4 jádrové i7 s 3,5GHz máme 4000 pravidel ve firewallu, 7500 manglu a 6600 queues. Při gigabitu je zatížení do 20%.

Hmm.Linux IGW shaping , nat a firewall.

Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz + Supermicro STGN-i2S
tok 1.32Gbit , 130k packet ,CPU +- 17%

to RouterOS neumí ten HW lépe využít?

S tou optimalizací to vidím taky jako zásadní , nevhodně postavené queue tree zjednodušeně valí na jedno jádro, mangle jsou také zápřah, firewall také a mít ve firewallu 2200 pravidel a 3500 v mangli mi přijde peklo. Vše ale závisí jak rychle ten paket tím fw prochází. Pokud k jeho odbavení nestačí první řádek, ale téměř každý packet musí procházet 2200 pravidel a k tomu projít 3500 mangle nežli najde svoje správné umístění, tak to zabíjí téměř jakýkoliv cpu.

Dotaz na zkušenější: Jak je na tom aktuálně ROS na x86 s mpls/vpls (témata zde se vyjadřují, že spíše nic moc kladného, na origo fóru nic moc info), v případě virtualizace vím že s mtu problém nebývá při právném nastavení, ale jak je to s výkonem síťovek (něco jako pci pass through, sr-iov, vmdq ?). Děkuji

ludvik píše:A pokud je optimalizované nemám, tak mi stačí E3?

hapi píše:předpokládám že optimalizovaný mangle máš. Pokud ano tak ti nepomůže nic jinýho než jít do Xeonu E5 s 8 jádry. Jo a taky doporučuju tu optimalizaci udělat i ve filtru.

to těžko říct. Plně neoptimalizovaný mangle nám zabralo 60% cpu Xeon E3v5 s cca 600Mbit. Jak to šlo ke gigu tak už to hezký nebylo. Aktuálně máme v mangle jumpy podle subnetů. Máme asi 50 subnetů s cca 20-30 ip adres na subnet takže 50x25 manglů na upload + 50x25 na download což je 1250 řádků na jeden nejdelší průchod. Po optimalizaci to je 50+25 tedy 75 řádků na nejdelší průchod a zátěž spadla o takovejch 60% dolu. U někoho jinýho jsme to taky optimalizovaly a tam to šlo podobně drasticky dolu. Jo a pro filter jsem si vypujčil pravidlo z fast tracku "/ip firewall filter add chain=forward action=accept connection-state=established,related" což způsobilo ještě větší úsporu cpu. Teoreticky to pustí přes forward všechny pakety který už předtim prošly nějakým acceptem a pokud už jsou established tak je pustí dál bez procházení celým filtrem.

Rozhodně bych se zaměřil spíš na optimalizaci mangle než cokoliv jinýho.

Jj, ale tak tohle pravidlo ve vhodném tvaru patří vždy někam nahoru, aby se odbavil provoz. Další optimalizaci např při povolování lze dělat tak, že forward na accept dáváš pouze jednou pro stav new, další se odbaví přes established,related. Toho je vhodné nastavit pro všechny patřičné směry, tj i směrem z "LAN" aby se odbavovalo hned z vrchu. Další důležité je použit ipset(address list) a ve výsledku z toho máte místo 2200 pravidel třeba 100.

zkoušel někdo address list s 1000 ip adresami vs. 1000 pravidel po jednom? Tak nějak pochybuju o efektivitě jednoho nebo druhýho. Jestli má hledat ve filtru nebo v address listu mi přijde stejný. Já to bohužel vyzkoušený nemám.

hapi někde jsem na to potkal seminární práci nebo nějaký jiný test, zkusím to dohledat, snad mi to google znovu najde - ale zrychlení bylo vemi výrazné

edit: první nástřel, myslím že to je tohle https://workshop.netfilter.org/2013/wik ... public.pdf

Jinak MK pro efektivitu doporučuje address list taky ve velkém, mk podporuje address listy např u pppoe, tak se to pak dá hezky kombinovat s firewallem na "jedno" pravidlo, bohužel mk nemá implementovanou podporu address listu u simple queue .... tohle jsem si doskriptoval, takže mám per sektor vpls, v něm mám SQ s dynamicky nastavenými targety (PCQ) a nemusím řešit mangle a rychlostně je SQ na CCR velmi dobře optimalizované. Protože SQ dnes naštěstí podporují parenty, tak z radiusu se mi vytvoří v hlavní SQ třídě podtřída dle parametru v radiusu.