Ahoj,
po roce a několika měsících usilovné práce jsme zřídili novou optickou 20M přípojku do města. Běží nám tam (3 dny :=)) prometheus 8.2.
Na staré přípojce byla opatchovaná verze 0.6 aby uměla 2x WAN a 2x LAN interface (Brr).
Na stroji běží OSPG, BGP, NAT, sonda bandwidthd která ukládá měření do postgresu na jiném stroji. Také se tam dělá redirect na Dashboard. Tříd přibližně 300, privátních ipek bude k 1000.
Pro zajímavost pár testů propustnosti před nasazením PCka za 10000 kc s DPH:
propustnost routing bez ničeho (halfduplex):
LAN -> WAN 64B packet přibližne 100 Mbps
(důvod limitu: plné vytížení dvou jader procesoru)
LAN -> WAN 1500B packet přibližne 350 Mbps
(důvod limitu: propustnost PCI32 sběrnice)
iperf na loopback :=) přibližně 10Gbps
fullduplex = half / 2
!!!!!!! režie kernelu na síťování není vidět v loadu systému, nutno použít třeba nástroj htop
Konfigurace:
Linux version 2.6.28.7 (gcc version 4.3.3 (Debian 4.3.3-5) )
AMD Phenom(tm) 8450 Triple-Core Processor, 2G RAM DDR2 1066, 2x PCI32 1G realtek RTL-8169
Zatím zjištěné problémy:
Zatím neumíme vysvětlit ani odstranit "prosakování" privátních ipek NATem na WAN rozhraní. Vše funguje, ale občas projde packet s privátní adresou. Jedná se některé ICMP, některé TCP z již neexistujících spojení ...
no, jen dodávám, že ten problém s NATem fakt vůbec nesouvisí s Prometheus QoS, který ani sám o sobě žádná NAT pravidla nesestavuje (byť v balíčku je přiložena ukázka skriptu, který je umí vygenerovat ze stejného konfiguráku)
asi jsem skopiroval spatnou hlasku se ted divam, kazdopadne mam pres 1000 PC a z duvodu jednoduchosti shapingu mam pro kazdeh PC jedni centralni tridu xxx0 a pod ni nekolik dalsich pro ruzne provozy xxx1, xxx2... kde xxx je pro kazda pc vyhrazene cislo.
tc class add dev imq0 parent 1:1 classid 1:10010 htb rate 256kbit
Error: argument "invalid class ID" is wrong: 1:10010
No ja to napsal sem, protoze je to aktivni vlakno ke shapingu a jak pises, muze k tomu dojit i s promethem. Ja to mel drive jako hexa, ale taky jsem daval 0x10001 coz bude asi to same jako 10001. Tudis muze byt trid 65635, ale musi se to zadavat v hexa.
Chtělo by to tady kapku oživit diskuzi :-)
Já mám pořád jen problémy s hraničním, routerem, ale nevím čím to je, protože dodavatel konektivity není zase tak úplně 100% :-(
Mám trochu problém, ve špičce prometheus nevyužije plně pásmo, máme linku 12 Mbps a ve špičce mi to jede třeba jen 256 kbit!!! a přitom když se podívám iftopem, tak má linka ještě 2 Mbps rezervu, Občas to taky začně ztrátovat. Někdy jako by to úplně přestalo komunikovat na pár vteřin do netu i do lokálu (monitoruju to smokepingem z obou směrů) i z ospf mně router vypadne občas.
Teď se nesmějte, ale zkouším být GREEN :-) Je to alix 2D3, zátěž je ve špičce na maximálně 25%, může to dělat špatný HW, nebo to je vlastnost shaperu? Když shaping vypnu, jede to rychleji, ale ping po kabelu do LAN routeru občas ztrátuje stejně....
Mám tam dát pořádný kilowatyžroucí železo, nebo je to jen nějaká kravina v konfiguraci? Dík moc všem za rady
Tak momentálně jede Alix NATuje a shapuje 221 ip adres ve 142 třídách, trafik cca RX 8 Mbps/ TX 3 Mbps a htop ukazuje CPU na 30%, občas to vzskočí až na 50, ale pořád je tam rezerva až až.
loadavg 0.35 0.33 0.18
a smokeping z venku ukazuje 12 % PL
BTW jaké máte zkušenosti s firmou Coprosys ?
Pokud provoz lossí, nebo laguje i když by člověk řekl, že je rezerva, tak tam rezerva většinou není. Typický problém agregovaných linek ...
Osobně si myslím, že by s touto rychlostí i s počtem tříd neměl mít alix nijak zvláštní problém. Ale nikdy jsem to takto netestoval. I když si nemůžu vzpomenout přesně, tak jsme začínali okolo 30Mbit a na silnějším stroji než je alix.
Ale pokud máš problém i po kabelu z vnitřku sítě, problém v prometheovi bych snad ani nehledal. A pro čistý routing (bez shapingu, natky) by mu stomego nemělo činit nijak zvláštní problém. Ale my ho nepoužíváme, tak nemůžu sloužit praktickými zkušenostmi.
Ještě jeden problém mě napadá - conntrack tabulka. Buď úplně přeplněná, nebo jsou tam velké (a rychlé) špičky. To udělá průser na libovolném PC.
17.04.2009 v 10:38
