Podle mě je moc nízko nastavené "rate". Neboli "garantovaná" rychlost. Nebo jejich součet (dle "hosts" konfiguráku) je víc, než "wan" rychlost.
Prostě bych to svedl na kravinu v konfiguraci.
A obecně bych na ten stroj nedával moc věcí, které by mohli generovat lokální provoz. A už vůbec ne směrem do pomalejší strany ... Prostě nechat to pouze pro forward.
Jojo, to je pravda, jeste zkusim prolet changelogy a cele to prokoumat a prijit tomu na kloub. Zainteresoval sem do toho i dalsiho naseho technika (bohuzel taky vysokoskolak ,ale aspon je FIT). Jak na neco pridem, urcite to tady postnem.
Mam dotaz - nevim co stim uz mam delat, ale prometheus mi shapuje i qos-free-zone i kdyz tam mam nastaveno 10.0.0.0/8 - jakmile neni ipadresa v prometheovi tak mi to vsechno spadne do sdilene linky - potrebuji, aby to co prijde z vnitrni site na pc s prometheem tak aby se vubec neshapovalo ale jen odchozi linka z pc do netu - dela to nekomu taky - nebo ma se nekde jeste neco nastavit krome qos-free-zone ?
Jediné co mě napadá - nemáš náhodou definovanou (v prometheovi, tj. "to co se rozděluje") větší kapacitu, než skutečně máš od ISP? Taky jsem si jednou naběhnul ... oni ti neprodají 7Mbit/s, ale 7000000bit/s. No buffer mi to ale myslím nehlásilo, jenom šly pingy sakra nahoru.
Případně (trochu vařím z vody) - pro 7Mbit a 414 adres mi to od oka vychází nějakých 16kbit na jednu (neuvažuju sharingy), což by teoreticky mohlo při burstu 16 problémy dělat mohlo (zkus experimentovat s tímto parametrem). Ale jak říkám ... nevím.
Jakou máš hodnotu TXQUEUELEN na síťovkách?
Pro zkoumání by se také hodilo vidět výstup promethea ... tedy /var/log/prometheus (nebo ještě lépe skutečnost: tc class show dev ethX). Pomůže si na papír rozepsat ten stromeček TC pravidel, možná hned uvidíš nesrovnalost.
Kdysi se tvrdilo, že součet RATE podřízených tříd nesmí být větší než RATE nadřízené. Na to mám stavěné generování našeho konfigu, takže statistika promethea tvrdí, že neagreguju ... Což je vlastně pravda - všichni mají "garantované" minimum, které tam na ně prostě musí zbýt i kdyby jeli všichni najednou.
Závěr: nemám rád odpovědi typu "chyba tam není, mě to nedělá". Ale teď to sedí ... Pro ostatní - prometheus je JENOM GENERÁTOR. Nedělá shapping, natož QOS, to dělá HTB&SFQ. Pro zkoumání, co z něj vylejzá, mu předhoďte zkrácený hosts a koukejte do výstupu "-d" (a když použijete moje classify, tak se to čte lépe - nejsou tam iptables).
napadla me jeste jedna moznost, a to plna conntrack tabulka.
Napravy se da dosahnout nekolika zpusoby, nakonec asi skoncite u aplikace vsech
1. zjistit, kolik spojeni je v conntracku aktualne
2. zjistit, jaka je maximalni velikost conntrack tabulky, pripadne ji zvetsit pomoci sysctl parametru net.ipv4.netfilter.ip_conntrack_max (tez dostupne pres proc)
3. je treba vzit v uvahu, ze kazde spojeni vezme 300-500 bytu pameti jadra, je treba mit dostatek RAM, swap nepomuze
4. snizit cas timeoutu tcp spojeni (defaultne je tyden), k nalezeni v net.ipv4.netfilter.ip_conntrack_tcp_timeout_established
CONNLIMIT používáme na apčkách. Jenže ono je to takový dvousečný ... buď nechám některé služby povolené a pak se to dle uživatelů "chová divně", nebo nenechám a pak kvůli torrentu "je už zase výpadek". Jenže vysvětli jim to ...
A jak napotvoru z historických důvodů máme skoro všude staros, kde nezměním timeout na tcp_established.
Na APčkách neděláme NAT, takže tam modul ip_conntrack vůbec není (a pokud je, tak je to omyl a bug a zadání pro vývojáře našeho systému :-).
ze všech strojů po cestě od klienta na internet máme ip_conntrack jen na stroji který dělá NAT, s tím že gateway je rozdělená na dva stroje: jeden dělá jen QoS (Prometheus QoS) a ten nemá ip_conntrack pro jistotu ani v kernelu, a druhý dělá jen NAT. ani na jednom z nich neběží OSPF (tedy zatím, ale asi to tak zůstane i v budoucnu).
pak máme ještě centrální router, na kterém běží OSPF, ale neběží tam NAT ani QoS.
rozdělení gateway na 3 stroje na bázi PC, z nichž každý provádí jen něco, je dlouholetá zkušenost, ke které původní Deuova Freegate (ze které myšlenkově pořád vycházíme) dospěla už asi před pěti lety (v době, kdy my jsme to měli všechno div né na jediném routeru...)
20.11.2007 v 19:42
