Mikrotik shaping 5Gbps

hapi

15-20x CCR1036... no to je hodně pěkná cena na to že to sfoukne jedno výkonnější x86. A to vadný CCRko není náhodný stav.

mato11

ano, ale k tomu X86 potrebujes este rozumny switch a nehovorim o problemovosti SSD diskov s MK.
to spolu zabera uz 2U v racku a su to dva HW, ktore sa mozu / nemusia pokazit.

Mame aj my este miesta kde su PC koli potrebnemu vykonu, ale tam kde netreba tolko vykonu, tak davame RB4011 alebo CCR1036

hafieror

A jak je na tom procesor v tomto?
MikroTik Cloud Core Router CCR2004-1G-12S+2XS

cmgn

hafieror Na h..... ověřeno. Mám 2 kusy, jestli chceš, rád prodám. Měsíc staré.

hafieror

cmgn mě jde čistě o bgp+ospf a par pravidel ve filtrech.

cmgn

hafieror pokud BGP na default route, cajk. Full table zapomeň. NAT v pohodě. 3 Gbps umí. Ověřeno. Ale jestli chces, oba budou tvoje. Jak se mi ozve Hapi a dotáhnu s ním servery.

jenya

cmgn Jako 3Gbit NAT ok a co shaping a nejaky firewall?

cmgn

jenya Řeknu to asi takhle - mám to na malé části sítě, kde je 700 PPPoE spojení, tím pádem 700 simple queue, žádný firewall, žádný NAT a dělá to 75-85% CPU. Čili, dost na hovno. Datový tok cca 1,5 Gbps. Za mě naprosto tragický, nepoužitelný a naprosto k ničemu...... firmware 6.47.2

jenya

cmgn To je dost uzitecna informace. Chtel jsem to nasadit na 1Gbit ,300 SQ, NAT a par pravidel FW, ale koukam radeji pujdu do x86. Tohle zvladne i i3.

cmgn

jenya Souhlasím. Já čekám na zpětný kontakt od Hapiho a taky tam dáme x86.... Tohle půjde rychle pryč nebo k nějakému zákazníkovi.

helapc

peckma
Chci zrovna tohle nasazovat a potřebuji aby to u NATovalo přes 5Gbps na Linuxu s NFTable. Máš stím zkušenost pod Linuxem? Trochu se obáváme jak budou procházet pakety přes PCIexpres sběrnice, když je každá napojená na jiný CPU.

pgb

helapc hash mapa na nftables to dá levou zadní 🙂 ... záleží na pps. Mám tu jednoprocesorovou desku s šestijádrem, nat(nftables)+shaper pro cca 130kpps a zátěž při necelých 2Gbps je cca 10%. Pokud vypnu netflow tak to klesne asi na 6%

helapc

Dík. nftables je pro nás novinka, tak se těším jak to bude makat.

kamilj

helapc
Linux Shaping 10Gbps
https://ispforum.cz/d/30408-shaping-na-linuxu-problem/10

helapc

kamilj
OK, tyhle věci jsem četl. Mě zajímal konkrétní názor na konrétní server.

L_F

hapi Pobavilo jako, že je to opravdu opravdu pravda. Bohužel.

Tyhle starý mrchy dokážou jenom jednu věc dělat opravdu dobře a tou je převod elektřiny na teplo :-)

helapc

Na tom jsem se taky zarazil, ale nechtěj vědět co mí teď vyrábí teplo a na ipatables to přes 2Gbps u NATuje.
Já bych se tam spíš bál strčit CCRko

L_F

helapc U nás to děláme tak, že qosení máme decentralizované přímo na jednotlivých vysílačích. Důvody jsou historické, ale i praktické například dynamický routing a více vstupů do sítě. možná utratíme o malinko více peněz za stroje v lokalitách, ale zatím jsme s tímto modelem problém neměli.
Jinak o topení taková 3 servrová IBM která jsme měli na gw před lety si vzala za elektriku asi 10000 měsíčně. 🙂 🙂 Dnes tam je 2x 1036 a 1x 1072 a elektrika je celkem za nějakých 1500 Kč měsíčně.

basty

Jeste kdyztak k jumpum. Mame v manglu /27-/28 jumpy a pak klienty, dobry funguje dobre. Zkousime ted viceurovnovy JUMP, ktery rekneme ma jednu/24, z ni to pak skoci do 2 /25 a tak dal to pokracuje dal az k /30 - /31. Mato to nekdo takto vyzkouseno? Jak jsou vykonove narocne operace JUMP vs. mangl? Diky

pgb

Nejde ani tak o rozdílnost jump vs mangle, ale o matematický počet těch porovnání nežli narazíš narazíš na shodu.

blbě se mi to popisuje....

ale třeba když máš 1024 marků, tj nejhorší najde shodu po 1024 krocích)
když to rozdějíš po /24, tak nejhorší choda bude po 256+4 krocích
když rozdělíš ještě tu /24 na /26, tak nejhorší shoda bude po 64+8
když rozdělíš ty /26 na /27, tak nejhorší choda bude 32+12
pak už se to láme, protože při /27 bude muset projít nejhůře 16 úrovní pro skupinu po 16 hostech
PS: celé to má logickou díru v tom, že počítám s nejhorším průchodem a to statisticky není úplně správně

« Předchozí stránka Další stránka »