Chci se zeptat zda někdo shapuje a routuje velký trafik na mikrotikovi ... my máme průtok přes 20 Mbit ... má okolo těchto rychlostí nějaké zkušenosti ??? Shaping jsem už rozhodil na více routerů ... ale zdá se mi že to nemá až takový efekt ... je pravda že tam mám ještě jeden Linuxový firewall ... a ten to může dělat ... takže hledám někoho kdo má podobný trafik ... a může se podělit o zkušenosti ...
Linux mi ukazuje conntrack 46359 a Mikrotik jen kolem 32 000 spojení přenosy něco přes 20 Mbit jedním směrem a 8 Mbit druhým směrem ... na mikrotikovi je kolem 500-1000 SimpleQueues na Linuxu vůbec neshapuju ... jen tam mám firewall ... Linux je na nějakém AMD Athlon 2500+ a Mikrotik na Intel PIV 3GHz ... mikrotik je vytížený až na 60% a Linux jen na max 5% ...
může vytíženost mikrotika na 60% omezovat propustnost datového toku ???
asi polovina datového toku přes mikrotik už není shapovaná ... to zařizují jiné routery ...
❗️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
Shapování a routování velkého trafiku
McCall píše:Chci se zeptat zda někdo shapuje a routuje velký trafik na mikrotikovi ... my máme průtok přes 20 Mbit ... má okolo těchto rychlostí nějaké zkušenosti ??? Shaping jsem už rozhodil na více routerů ... ale zdá se mi že to nemá až takový efekt ... je pravda že tam mám ještě jeden Linuxový firewall ... a ten to může dělat ... takže hledám někoho kdo má podobný trafik ... a může se podělit o zkušenosti ...
Linux mi ukazuje conntrack 46359 a Mikrotik jen kolem 32 000 spojení přenosy něco přes 20 Mbit jedním směrem a 8 Mbit druhým směrem ... na mikrotikovi je kolem 500-1000 SimpleQueues na Linuxu vůbec neshapuju ... jen tam mám firewall ... Linux je na nějakém AMD Athlon 2500+ a Mikrotik na Intel PIV 3GHz ... mikrotik je vytížený až na 60% a Linux jen na max 5% ...
může vytíženost mikrotika na 60% omezovat propustnost datového toku ???
asi polovina datového toku přes mikrotik už není shapovaná ... to zařizují jiné routery ...
Ked porovnavam s tymto viewtopic.php?t=80
tak tam je nejaky problem...
Ake mas sietovky v MK
0 x
kdavid píše:
Ked porovnavam s tymto viewtopic.php?t=80
tak tam je nejaky problem...
Ake mas sietovky v MK
3Com 3c59x PCI je driver v mikrotikovi ... kupovali jsme tam docela slusne sitovky ... ted konkretne tam tece 20+12 Mbit ... obe sitovky jsou v PCi ... procesor je servrove reseni, stejne tak deska ... neni to obyc PC ...
v tom odkazu je receno ze to zvlada 450 Mbit ... a to je trochu rozdil
... jen me zarazi ze sitovky jsou nastaveny na 100 Mbit FD ... jeste poznamka ze to je hozeno jako bridge ...
0 x
SW správa sítě Hlucin.net
Sice s takto velkým trafficem nemám skušenosti, ale rozhodně bych doporučoval přejít z bridgování na routování.. myslím si, že změnu rozhodně poznáš ve vytížení CPU...
viz: http://forum.promedia.cz/routeros.cz/viewtopic.php?t=634
viz: http://forum.promedia.cz/routeros.cz/viewtopic.php?t=634
0 x
McCall píše:kdavid píše:
Ked porovnavam s tymto viewtopic.php?t=80
tak tam je nejaky problem...
Ake mas sietovky v MK
3Com 3c59x PCI je driver v mikrotikovi ... kupovali jsme tam docela slusne sitovky ... ted konkretne tam tece 20+12 Mbit ... obe sitovky jsou v PCi ... procesor je servrove reseni, stejne tak deska ... neni to obyc PC ...
v tom odkazu je receno ze to zvlada 450 Mbit ... a to je trochu rozdil
Jednoznacne suhlasim ... Treba prejst na routing... Bridge o vela viac vytazi CPU.
0 x
net.work píše:Sice s takto velkým trafficem nemám skušenosti, ale rozhodně bych doporučoval přejít z bridgování na routování.. myslím si, že změnu rozhodně poznáš ve vytížení CPU...
viz: http://forum.promedia.cz/routeros.cz/viewtopic.php?t=634
Celá sí je routovaná ... tohle je shaper na konci ... který je jen na shaping ...
navíc jsem už víc jak polovinu shapingu rozhodil na 10 slabších strojů ... které routují určité body sítě ...
0 x
SW správa sítě Hlucin.net
mikrotik na shaping nepouzivam,
ale mam podobny zkusenosti na linuxu.
nevim jak ma shaping vyreseny mikrotik,
ale predpokladam klasicky htb a pakety jsou
znaceny pres tc filter a sfq poveseny na kazdej tride.
problem tohohle schematu je mnozstvi pravidel, pri urcity
hranici uz to zacina byt silne znat, nebot pakety pro posledni
tridy musi projit v podstate vsema pravidlama.
tenhle problem se projevi cca od 20Mbitu a >600 trid, zavisi
to taky hodne na CPU, desce, sbernici, konfiguraci jadra, ale vicemene
to plati.
dusledkem tohohle problemu je snizena propustnost,
neprenosti v qosu pro tridy smerem dal od zacatku pravidel a rozlitana
latence paketu.
reseni znam jenom na linuxu: pouzit pro tc filter hasovani
http://lartc.org/howto/lartc.adv-filter.hashing.html
ale mam podobny zkusenosti na linuxu.
nevim jak ma shaping vyreseny mikrotik,
ale predpokladam klasicky htb a pakety jsou
znaceny pres tc filter a sfq poveseny na kazdej tride.
problem tohohle schematu je mnozstvi pravidel, pri urcity
hranici uz to zacina byt silne znat, nebot pakety pro posledni
tridy musi projit v podstate vsema pravidlama.
tenhle problem se projevi cca od 20Mbitu a >600 trid, zavisi
to taky hodne na CPU, desce, sbernici, konfiguraci jadra, ale vicemene
to plati.
dusledkem tohohle problemu je snizena propustnost,
neprenosti v qosu pro tridy smerem dal od zacatku pravidel a rozlitana
latence paketu.
reseni znam jenom na linuxu: pouzit pro tc filter hasovani
http://lartc.org/howto/lartc.adv-filter.hashing.html
0 x
megy píše:mikrotik na shaping nepouzivam,
ale mam podobny zkusenosti na linuxu.
nevim jak ma shaping vyreseny mikrotik,
ale predpokladam klasicky htb a pakety jsou
znaceny pres tc filter a sfq poveseny na kazdej tride.
problem tohohle schematu je mnozstvi pravidel, pri urcity
hranici uz to zacina byt silne znat, nebot pakety pro posledni
tridy musi projit v podstate vsema pravidlama.
tenhle problem se projevi cca od 20Mbitu a >600 trid, zavisi
to taky hodne na CPU, desce, sbernici, konfiguraci jadra, ale vicemene
to plati.
dusledkem tohohle problemu je snizena propustnost,
neprenosti v qosu pro tridy smerem dal od zacatku pravidel a rozlitana
latence paketu.
reseni znam jenom na linuxu: pouzit pro tc filter hasovani
http://lartc.org/howto/lartc.adv-filter.hashing.html
právě proto jsem přešel z linuxu na Mikrotik ... na Linuxu "nešlo" shapovat víc jak 15 Mbit při 1000 třídách ... na Mikrotiku dělám i přes 20 Mbit ... při vytížení procesoru 60% ...
je 60% vytížení procesoru kritické ??? u mých Linux serverů někdy vydrží i dlouhodobě 100% vytížení ... u 64 bit procesorů ...
0 x
SW správa sítě Hlucin.net
McCall píše:megy píše:mikrotik na shaping nepouzivam,
ale mam podobny zkusenosti na linuxu.
nevim jak ma shaping vyreseny mikrotik,
ale predpokladam klasicky htb a pakety jsou
znaceny pres tc filter a sfq poveseny na kazdej tride.
problem tohohle schematu je mnozstvi pravidel, pri urcity
hranici uz to zacina byt silne znat, nebot pakety pro posledni
tridy musi projit v podstate vsema pravidlama.
tenhle problem se projevi cca od 20Mbitu a >600 trid, zavisi
to taky hodne na CPU, desce, sbernici, konfiguraci jadra, ale vicemene
to plati.
dusledkem tohohle problemu je snizena propustnost,
neprenosti v qosu pro tridy smerem dal od zacatku pravidel a rozlitana
latence paketu.
reseni znam jenom na linuxu: pouzit pro tc filter hasovani
http://lartc.org/howto/lartc.adv-filter.hashing.html
právě proto jsem přešel z linuxu na Mikrotik ... na Linuxu "nešlo" shapovat víc jak 15 Mbit při 1000 třídách ... na Mikrotiku dělám i přes 20 Mbit ... při vytížení procesoru 60% ...
je 60% vytížení procesoru kritické ??? u mých Linux serverů někdy vydrží i dlouhodobě 100% vytížení ... u 64 bit procesorů ...
Dle meho 60% je ¨jeste v pohode, zalezi, jestli to nevybiha do spicek..... Ja shaping delam u kazdeho pristupoveho bodu, takze mi na to staci daleko pomalejsi masiny a take si setrim P2P paterni spoje, jelikoz MK zahazuje packety, a proc by je mel zahazovat az za P2P spojem a tim ho vice vytizovat, kdyz muze rovnou na AP a prez paterni spoje prochazeji only uz shapovane data, ktere maji daleko mensio velikost.....
0 x