Pokud tam nebylo to poslední, tak to házelo tu hlášku ... a v mangle vše zůstalo (resp. "něco tam bylo a bylo toho hodně").
Já promethea (pokud si mě z diskusí pamatuješ) používám docela dlouho - cca od srpna minulého roku (ale verzi 0.5). Tj. konfigurák tvořím z naší databáze - furt stejně. Dřív jsem si této chyby nevšiml (minimálně tenkrát nebyla určitě, jenže to těch adres byla tak třetina). Nedávno ovšem jsem chtěl něco otestovat a ono nic, mangle zůstalo ... nezkoumal jsem to, nebyl čas.
Až teď dělám nový server, tak to celý překopávám. Včetně posledního promethea.
Taky jsem tam objevil zmínku, že současný shapping a NATkování není moc výkonově dobrý ... Nenašel jsi (nemáš) nějaký testy? Já jenom jestli mi to Core2Duo (4200 bogoMips) s intelovýma Gbit sí?ovkama bude vůbec stačit (zatím 36Mbit provozu)... nebo naopak, jestli není moc předimenzovaný, když budu stejně muset natkovat někde jinde ... Vlastně každou IP musím prohnat SNATem a některé (asi sto) taky DNATem.
Mimochodem - spuštění promethea trvá na tomto stroji cca 7 minut. Není to trochu moc? Můj firewall, který vlastně jenom vytváří SNAT a DNAT pravidla (nepočítal jsem to, ale do iptables zapíše cca 2000krát) je hotov cca do minuty.
Ještě něco: až na tento nový servřík jsem si troufnul dát hotsanic, takže zanedlouho ti sem postnu nějaké lepší statistiky z provozu.
Informace, co jsem kdysi sem psal. nebyly moc správné - sledoval jsem to hotsanicem z jiného stroje přes snmp a ten kokotko mi dělal stejný grafy, jako stroje kde běžel ten hotsanic ... vůbec jsem nepochopil, proč.
Až později jsem si všimnul, že cca 70% CPU bere "kernel". a to skoro furt ... přitom to nebylo žádný extra ořezávátko, P4 na 2.4GHz. To nemluvím vůbec o procesu ksoftirgd, kterej sežral snad co mohl.
Mam jeste takovyto dotaz:
Je mozne, kdyz nastavim ruznym lidem min a max rychlost aby mi nekteri lide spadli do sdileneho pasma ?
Pr:
1. 64-256
2. 64-512
3. 96-512
4. 128-1024
atd.
Koukal jsme prave ze ve vzorovem hostu je to podobne a prave proto je mi to divne ?
Prometheus QoS automaticky tvoří tak hluboký (nebo spíš vysoký ? :-) ) strom hashovacích tabulek v iptables, aby v žádné sub-tabulce nebylo více jak 8 položek. Hashování používáme jak u tabulky NAT, tak i u tabulky mangle. U tabulky NAT to není součást prometheus.c, ale jsou to standalone skripty v bashi, které ještě nejsou součástí distribučního .tar.gz.
O použití iptables-restore místo iptables uvažuju v další verzi. Ta incializace teď probíhá fakt nechutně pomalu.
Je fakt, že třeba přidělování rychlosti celým subnetům by Promethea asi zefektivnilo a zrychlilo. Problém ovšem je aby to bylo kompatibilní právě se stávajícím systémem hashovacích tabulek.
U NATu nebo QoSu už prakticky nemá smysl traffic sledovat v Mbps, ale jenom kpps (tisícovky packetů za sekundu). Každý packet totiž vyvolá interrupt a ten zase vyvolá nějaký kód v kernelu. Na velikosti packetu už potom tolik nezáleží...
Ok, já si taky všiml, že souvislost mezi počtem irq a počtem pps je na různých routerech... různá :-)
Obecně je ale asi jedno, jestli karta vygeneruje nebo nevygeneruje interrupt: podstatné je, že každý packet představuje event, který musí kernel ošetřit spuštěním nějakého iptables kódu, qos kódu, routovacího kódu a arp kódu. Jediné co jako userspace programátor můžu nějak výrazněji ovlivnit, jsou právě jenom ty iptables. Délku route a arp tabulky může ovlivnit administrátor - tím, že nějak zagreguje prefixy a nevymýšlí nesmyslné LAN topologie.
Xchaos zda se na tom dela tak dlouho, ze uz si nepamatuje uplne presne, co kde jak napsal, a jak zmenil prochazeni kterymi tabulkami.
Nechci zas byt moc rejpavy, ale mam pocit, ze tc muzes pouzit pouze v pripade, ze na masine s rizenim provozu nedelas NAT, ale ze je pruchozi. Pokud totiz delas NAT, nemuzes to oznacovat pomoci TC, a tim padem stejne nevyuzijes zadne hash tabulky programu tc. Takze iptables zas tak blbe na markovani uz z tohot duvodu nejsou, i kdyz je dost pravdepodobne, ze je to tak pomalejsi co se tyka CPU. Jenze je fakt, ze treba ja filtry pres tc jedine mazu, protoze jsou silene neprehledne, kdezto iptably s v klidu dovolim rucne upravovat. TC si dovolim akorat vygenerovat cele znova.
Jestli to chapu dobre, pro vysoky vykon by bylo dobre mit nejvetsi sosace na zacatku kazde tabulky, a za kazdym delat poctive return, aby to nemuselo prolezt celou zbyvajici tabulku. Az nakonec bych asi prihodil obecne oznacovani pro ostatni uzivatele. Nevim jak presne jsou ty tabulky udelane v iptablech, ale je skakani mezi tabulkami fakt nejake pomale z principu? Protoze treba pokud pri prechodu na jinou tabulku akorat zmenim adresu base pointeru, tak podle me k zadnemu zpomaleni (ok, jednotky istrukci tam budou rozhodne uz kvuli pocitadlum atd) dochazet nemusi. Otazka je, jak se s tim vyporadali autori iptablu.
21.11.2006 v 20:57
