Jake zelezo na hl. router

Muzete pls nekdo poradit pripadne napsat co pouzivate za zelezo pro MK?

Hledame neco noveho protoze stare zelezo to proste nedava...

Melo by to zvladnout linku 250/250Mbps az 500Mbps a pravidla QT: 2000tis , FW, Mangle , NAT

Diky

take zelezi proste neexistuje... musis to rozdelit aspon na dva stroje. zvlast dat nat+fw a zvlast stroj, ktory bude riesit magle+qt (agregaciu)

riesil som to aj ja a aj zopar dalsich tuna na fore a kazdy dospel k tomu istemu nazoru... je to smutne, ale MK je jak brzda a zaspal dobu. z daleka nedokaze vyuzit potencial a silu HW tak ako ktorykolvek iny OS.

Tak prsne to jsem si myslel. Prochazel jsem forum a nic kloudneho jsem nenasel a muzu se teda zeptat jak to mas ty? Kolik pravidel a jak vykonne masiny?

dve masiny z vykonnejsej triedy, proste nejaky lepsi procesor s co najvacsou cache a serverova doska a ideal sietovky do pci-e stotu (supermicro skladacka).

toto dva krat za sebou s tym, ze prvy robi nat + fw a druhy cisto magnle+qt v stromovej strukture (agregacia). ak by si to nemal v stromovej strukture s tym, ze by si len rezal rychlosti userom, tak usetris neskutocne mnozstvo vykonu. prave pri vyratavani agregacnych pomerov to pada na hubu. ale bez toho sa podla mna dnes nezaobides (princip htb).

mam traffic cca 250 mbit, zhruba 2000 mangle, rx+tx packet dokopy je v spicke zhruba 60 000 - 70 000. takto ide cpu do 30 percent.

zrovna včera jsem si hrál s rychlostma skrz bránu a bez zjevný příčiny router zdechne cca při 150/100Mbit. Mikrotik neříká nic o přetížení nějakýho jádra, nic nejelo na limitu, procesory se tak nějak flákaly a prostě nic, pingy nahoru, výpadky a čágo. Teď je otázkou co to kde brzdí. Mikrotik píše že IRQ do procesoru je spousta volných atd.. a teď kde je ouzký hrdlo? FSB na s775? paměti? paměti jedou skrz FSB takže zátěž velká pro FSB kde jedou ethernety i ramky a tedy uplně všechno takže brzda je tam? Nával IRQček tomu asi taky zrovna nepomáhá. CPU evidentně zvládne víc ale tahle jediná zběrnice brzdí? Quad by tedy místo dualcore vůbec nepomohl? To je otázkou proč vlastně corei7 jede na DDR3 + ještě tři kanály, že by si byly vědomy toho že při některých operacích je úzko právě v pamětech? corei7 má ještě oddělenou zběrnici ramek a desky která je ještě navíc 2-3x rychlejší takže volba jistě na nový patice a quad a co nejrychlejší ramky a cpu s co největší cache. Víc se nejspíš dělat nedá a kupovat serverový chipsety pro mikrotika je škoda.

Takze dam aj ja nejaku skusenost... myslim ze toto je velky problem MK ze nedokaze vobec dostat z HW to co by mohol .

Na jeden shaper cize mangle+qt+fw kde je kazda IP viazana na MAC po prekroceni mangle cez cca 1800pravisiel to zacina robyt divociny typu ping cez router z 1 ms na 40-50-ms ,pritom cpu sa flaaka a myslim ze to nebude ani hw zalezitost ,ale bude to skor zalezitost systemova v MK jednoducho to nezvlada. Skusane asi na 5tich typoch serverov silne ,slabe, bolo to zhruba to iste. Co sa tyka ramky tiez sme skusali menit rychlejsie ,pomalsie mensie-vacsie to mu bolo uplne jedno ci tam dam 256mb alebo 4gb a 4x rychlejsiu.Co bolo poznat bolo nahodenie pcie ethernetov ale nejaky velky rozdiel to nebol ,mozno ak by bol traffic nbiekde okolo 300mbit tak by bola nutnost pcie sietoviek. Cize jedine rozdelit na viacej masinach inac sa neda .,pokial tam chces MK.Ja na GW do netu idem nasadit vyattu ,ale shapovat musime na MK koli superveryniceadminu :( ,ktory keby sa dal vratit tak uz ho maju naspet.

Nevím, možná se zeptám hloupě, ale proč používáte Mikrotik na shapování, když má takovýhle potíže? Počítám, že když potřebuješ odroutovat 200+Mbit nejseš Fanda z Horní Dolní a máš buďto člověka na Linux nebo prostředky na to někoho zaplatit. V současný době používáme jako hraniční router se shaperem a NATem HP DL 360G5 s Xeonem E5420 - tedy 4 jádra. Celkem 46tis. pravidel v TC, 41tis. v mangle a 750pravidel v NAT tabulce. Při trafficu okolo 600Mbit (tj. cca. 75tis. paketů) je load na 2 jádrech do 50%, ostatní nedělají "nic". Naprosto stabilní ping, žádné ztráty, žádné tuhnutí. Verze s pořádnýma síťovkama a 2CPU E5420 utáhne bez potíží 1Gbit fullduplex. Není to lepší řešení než tohle s...í s Mikrotikem?

no tak počkat. Je to sice už nějakej ten rok ale taky jsem měl na bráně linux a dokonce s přímo kompilovanym jádrem pro ten danej HW a v tvim podání by tenkrát P4 2.4GHz nedělala vůbec nic ale dělala a docela dost. Pak se docela logicky ptám, jestliže používáš TC, tak tam máš nejspíš jednoduchý pravidla bez stromu ne? No a pak taky nechápu použití 41 tisíců pravidel, k čemu to je? Rozepiš to. Ono je to sice pěkný ale pochybuju o tom jak to vlastně máš.

MImo to, ta tvoje deska má ethernety s tzv. TCP/IP Offload Engine kterej dělá skoro všechno za procesor a v tom bude ten ftip. Další ftip je v tom, že pokud výrobce k tomu nedodá extra routovací software, tak si to doma na linuxu těžko rozchodíš.

Tady jsou moje zkušenosti: Tok 300-400Mb (30-50tis. pac.). Hlavní router s MK 3.30, 2x quadcore xeon (takt jádra 2133MHz), 15tis. mangle, 16tis. QT, routing celé sítě, nat, vytížení cca. 15-20%. Na MK bych se nebál ani 1Gb toků. Takže asi tak.

no a teď jak máš postavený QT. Strom nebo ne?

A proc to neudelat na linuxu jako takovym?Ja mam na linuxu cca 7000 pravidel + brzdeni atd a chodi to v poho i 250mbit....a to nepocitam co se hodilo bokem jeste na NAT server kterej predtim vubec neby...Je tam Xeon 3450 a Asus P7F deska..

hapi: "kamaráde" ... to že něčemu příliš nerozumíš ještě neznamená, že jsou ostatní lháři. Takto nějak vyzněla Tvoje odpověď. Ale teď už k věci :

Používáme samozřejmě TC (co jiného). Pro samotný shapping pak HTB, ESFQ a FIFO. Protože se shapují oba směry na jednom stroji včetně NATu pak ještě IMQ. Nepoužíváme hash tabulky ale klasické manglování v iptables a rozdělení pomocí filter pravidel v TC v jednoduchém stromu. 41tis. pravidel proto, že náš shaper umožňuje omezit maximální rychlost na každém segmentu sítě a také zajišťuje základní QoS (4 třídy pro každého usera). Těch 41tis. pravidel obsahuje i vlastní filtry v TC.

Tolik k Tvým pochybnostem a nyní k Tvým znalostech toku paketů v kernelovém jádře ;)

Z principu obsluhy paketů v kernelu je implementace off-loadingu v linuxu velmi obtížná, pokud je vůbec možná. Je to z důvodu, že veškeré filtrační, natovací i manglovací tabulky iptables jsou uloženy v paměti PC stejně tak jako routovací tabulky a konec konců i nastavení pro shaping a tudíž k nim vlastní síťová karta nemá jednostranný přístup.

Pokud to chceš realizovat na linuxu, stačí celkem jednoduše nakonfigurovanej a opatchovanej kernel, iptables a iproute. Správný rozdělení irq na jednotlivá jádra (což je podle mého názoru problém, který Vás trápí ve Vašich příspěvcích) a skript, kterej vygeneruje pravidla ze zdrojových IP uživatelů a jejich rychlostí. Toť vše.

Pokud máte nějakej dotaz k funkčnosti, rád k tomu řeknu co vím. Pokud máte příliš nabubřelé ego k tomu, abyste zkusili jak se to dá dělat jinak, poradit nedokážu ;)

no a co jsem napsal jinýho že píšeš že tomu nerozumim? Taky jsem jasně napsal že si to doma těžko rozchodíš tedy rozumněj 99.99% ISPíků si to těžko rozchodí. Já tomu rozumim hodně dobře a proto jsem hned psal že normálními věcmi to neni možný a opatchovaný věci nejsou normální věci a ethernety s off-loadingem už vůbec ne. Mimo to, kdy jsi všem chtěl napsat že používáš off-loading kterej je pro 99.99% lidí nedostupnej? (ve smyslu toho že do toho nepude a neumí to nakonfigurovat)

Taky jsem míval iptables, tc a htb a je fakt že to chodí ale patchovat uplně všechno kvůli tomu by se mi nechtělo i když to hodně přinese ale odlazování může bejt noční můra.

Takže ještě jednou polopaticky :

patche v kernelu pouze pro implemetaci IMQ a ESFQ - nic jiného. Dá se vystačit jen s SFQ (ve standardním kernelu, tedy bez patche) a IMQ. Offloading NEPOUŽÍVÁME a podle mého názoru v linuxu pro shapování ani použít nejde. To udělá i člověk, kterej dokáže přeložit jádro. Pokud to nedokáže tak máš pravdu a evidentně domu nerozumí. V tom případě by byl dobrý nápad utrousil nějakou tu korunku za práci člověka, kterej to nakonfiguruje. Pro člověka (firmu) která potřebuje shapovat 250Mbit+ by to snad neměl bejt problém. Já se taky neučím opravovat auto i když s ním umím jezdit a natankovat do něj benzín.

A člověk, kterej všechno bastlí doma na gauči asi nepotřebuje shapovat 250Mbit+.

Ja mam na linuxu to same jako mac78 od zacatku. Mám tedy mene uzivatelu a konekt 160Mbit, ale zase mi to nejede na nejakem exptra stroji(nejake 1U IBM s dvoujadrovym xeonem 3050 @2.13GHz 2MB cache a 1GB RAM). To mi ten stroj dela kompletni monitoring site(nagios, smokeping, mrtg, ipfm, rosinfo...), web a smtp server... A vse zvlada bezproblemu. RoterOS patri na strechu nebo jako holej router, ale ne na centralni server.

Ja mam na linuxu to same jako mac78 od zacatku. Mám tedy mene uzivatelu a konekt 160Mbit, ale zase mi to nejede na nejakem exptra stroji(nejake 1U IBM s dvoujadrovym xeonem 3050 @2.13GHz 2MB cache a 1GB RAM). To mi ten stroj dela kompletni monitoring site(nagios, smokeping, mrtg, ipfm, rosinfo...), web a smtp server... A vse zvlada bezproblemu. RoterOS patri na strechu nebo jako holej router, ale ne na centralni server.

ámen ;) běží nám tam taky ještě nagios a bind, ale chci to z toho všechno vyházet a nechat tam jen oholenej router.

tak jinak. Co ty patche vylepší že to jede až takhle hodně dobře? mikrotik teď už má taky rozdělení zátěž mezi jádra a revoluce se nekoná. Napadá mě hlavní vylepšení pouze v optimalizaci kodu na danej procesor, na danou architekturu která by mohla sakra pomoct a udělat z toho takhle výkonej stroj. Pak nějaký drobnosti při kompilaci jádra co budou víc optimalizovaný pro sítový provoz. Tohle všechno by teoreticky neměl bejt problem provést na téměř jakýkoliv distribuci a když se k tomu udělá rozumný api, je to hotovej výrobek :-)

Co tam máš za distro a verzi jádra?

Takže ještě jednou polopaticky :

patche v kernelu pouze pro implemetaci IMQ a ESFQ - nic jiného. Dá se vystačit jen s SFQ (ve standardním kernelu, tedy bez patche) a IMQ. Offloading NEPOUŽÍVÁME a podle mého názoru v linuxu pro shapování ani použít nejde. To udělá i člověk, kterej dokáže přeložit jádro. Pokud to nedokáže tak máš pravdu a evidentně domu nerozumí. V tom případě by byl dobrý nápad utrousil nějakou tu korunku za práci člověka, kterej to nakonfiguruje. Pro člověka (firmu) která potřebuje shapovat 250Mbit+ by to snad neměl bejt problém. Já se taky neučím opravovat auto i když s ním umím jezdit a natankovat do něj benzín.

A člověk, kterej všechno bastlí doma na gauči asi nepotřebuje shapovat 250Mbit+.

IMHO není ani nutné použít patche s IMQ ale IFB, které je standartní součástí jádra :

Tak jestli tomu rozumíš dobře, jak si psal, tak snad víš k čemu je ESFQ a IMQ. Pro ty ostatní :

ESFQ je pouze opravená verze SFQ, které je v jádře a jedná se pouze o způsob jakým budou pakety propouštěny skrze frontu v shaperu. Má možnost definovat z čeho se budou vytvářet hash tabulky na základě kterých se pak rozhoduje, jaké pakety se zahodí v případě, že je třída saturována. Vliv na rychlost nula, na QoS dle konfigurace.

IMQ umožňuje vytvořit virtuální rozhraní do kterýho se směřuje odchozí traffic z routeru do netu. Shapping je totiž na linuxu obecně možnej jen na (tuším) výstupní straně rozhraní. Můžeš použít i IFB, který je součástí kernelu ale nezkoušel jsem ho.

Takže ty patche nejsou nezbytně nutný, ale umožní vytvořit řešení, který dělá lépe svojí práci. V kernelu pouze vymezíš např. 2 jádra, na každé pověsíš přerušení jedné síťovky. Na těchto 2 jádrech nebudou přerušení ničeho jiného (ani žádné procesy) a je nanejvýš ideální počítat s interní architekturou cache procesoru, tedy používat jádra, která sdílí stejnou cache. Taky musíte použít síťovku (samozřejmě jen PCIe nebo PCI-X 64 bit) která podporuje přerušení přes MSI a nevolá si přerušení při každym paketu kterej dorazí nebo chce odejít. Toť kouzlo celé záležitosti.

Jestli tohle nedokáže nastavit 99.99% ISP, dobrovolně se vzdávám občanství naší republiky a odcházím do vyhnanství :)

Distro OpenSuSE, vanilla kernel 2.6.24.7