Traffic shaping na linuxu

[DarkLogic]

Ahoj,

chtěl bych se zeptat na doporučení těch, co dělají traffic shaping na linuxu. Jaké řešení používáte, tzn. jakou konkrétní službu na linuxu? HTB nebo něco jiného? Pravidla pro třídy si píšete sami nebo máte nějaký pomocný SW, který pravidla vygeneruje? Jde mi o shapování všech zákazníků na síti pomocí linuxového routeru, který je zároveň jako hlavní gateway.

[rsaf]

Shaper už pár let provozujeme na Ciscu.
Předtím na linuxu to bylo HTB a iptables target CLASSIFY. Struktura iptables byla kvůli výkonnosti "víceúrovňová". Na nějakém slušném železe (quad core...) to pro nějakou tu tisícovku lidí fungovalo, jakmile jsme se začali ve špičkách blížít ke gigabitu, nahradilo to Cisco.

[erotel]

Ipset + tc vlastní skript na naplnění a změny.Při 1Gbit provozu 8 cpu na cca 25% zatížení,je to hlavní IGW(shaping,nat,firewall) cca 2500 přípojek.

[Dalibor Toman]

DD,

viceurovnove HTB (popisuje i strukturu linek k zakaznikovi) v tc s hash table (bez ucasti iptables). IPtables+ipset jen pro filtraci (blokovani zakaznici, zavirovani zakaznici, zakaz komunikace pro IPcka gatewayi (ochrana MT routeru), seznam aktivnich IPcek,...). CFG pro shaper generuje skript z DB...

Zatez CPU mala, dulezite je mit rozumnou sitovku rozkladajici packety na vice IRQ a ty rozhazet per CPU jadra.

[DarkLogic]

Děkuji za reakce. Byl by někdo z Vás ochoten se soukromě podělit o část svého řešení? Jde mi hlavně o ukázku, jak vypadají vygenerovaná pravidla pro tc strom.

[iTomB]

iptables, mangle, tc, classify, htb k tomu upravene jadro a L7 priorizace.

Na Atomu to pri par set Mbitech basti cca 10-15% spicka za posledni mesic 17.5% (server toho ale dela jeste vic ...).

Odhad ze by to utahnul pro par Gbit. Cely server spotreba do 20W.

[Dalibor Toman]

Odhad ze by to utahnul pro par Gbit. Cely server spotreba do 20W.

u Atomu bych o tom mel dost pochybnosti. Co se tyce zpracovani packetu, tak zatez CPU neni vzdy ten spravny indikator stavu funguje/nefunguje. Dulezitejsi jsou ruzne countery, ktere pocitaji zahozene/nezpracovane packety jak v IP stacku tak v ovladaci sitovky

[iTomB]

Odhad ze by to utahnul pro par Gbit. Cely server spotreba do 20W.

u Atomu bych o tom mel dost pochybnosti. Co se tyce zpracovani packetu, tak zatez CPU neni vzdy ten spravny indikator stavu funguje/nefunguje. Dulezitejsi jsou ruzne countery, ktere pocitaji zahozene/nezpracovane packety jak v IP stacku tak v ovladaci sitovky

Mrkni nejdriv na Avoton, na kterem mi to bezi C2750 a nove C3958 (cekam az bude deska ...).

Ten HW je na to specializovanej a mnoha pripadech je to vykonejsi nez Xeon E5 (testoval to znamy jeste s C2750)

[Dalibor Toman]

Mrkni nejdriv na Avoton, na kterem mi to bezi C2750 a nove C3958 (cekam az bude deska ...).

Ten HW je na to specializovanej a mnoha pripadech je to vykonejsi nez Xeon E5 (testoval to znamy jeste s C2750)

prijde mi, ze ty Atomy maji zbytecne malo L2 cache (0.5M resp 1M per jadro). Pokud se do ni, co je potreba vejde, pak by to problem byt nemusel. Tech jader v nich (8 resp 16) je skoro moc (akorat uziraji z cache).

mam tady 2 linux routery (ethernety bondovane po dvou, routing, shaping, filtering+sber dat pro data retention), kde tece pres 1gbps. Jeden s E3-1260L a druhy W3540. Oba to zvladaji celkem v pohode, oba maji 4jadra a 8MB smart cache a 2.9Ghz hodiny, HT vypnuty.

[iTomB]

A co myslis, ze v te cache ten CPU dela? Stejne ty packety prileti a odleti, on si je neuchovava

[Dalibor Toman]

A co myslis, ze v te cache ten CPU dela? Stejne ty packety prileti a odleti, on si je neuchovava

ono nejde az tak o to, zda je v cache ten packet, ale kod, ktery ten packet zpracovava. A toho neni zas az tak malo.

[iTomB]

A proto ma ten Avoton 4x 1MB L2 pro kazde 2 jadra
A ty tve intely maji 256k pro jadro jsem na tom porad minimalne 4x lepe na CPU...

Ano mas jeste L3, ale ta uz takovy vykon nema ...

Komprimace souboru C2750 vs Xeon E5 4 jadro ... Vitez je Atom ...

[karci]

Aké CISCO konkrétne používate ?
Čo to všetko zvládne ?

Akto teda nie je problém prezradiť ....

Shaper už pár let provozujeme na Ciscu.
Předtím na linuxu to bylo HTB a iptables target CLASSIFY. Struktura iptables byla kvůli výkonnosti "víceúrovňová". Na nějakém slušném železe (quad core...) to pro nějakou tu tisícovku lidí fungovalo, jakmile jsme se začali ve špičkách blížít ke gigabitu, nahradilo to Cisco.

[Dalibor Toman]

A proto ma ten Avoton 4x 1MB L2 pro kazde 2 jadra
A ty tve intely maji 256k pro jadro jsem na tom porad minimalne 4x lepe na CPU...

Ano mas jeste L3, ale ta uz takovy vykon nema ...

Komprimace souboru C2750 vs Xeon E5 4 jadro ... Vitez je Atom ...

v procesorech se neorientuju, muzes mit pravdu ale IMHO datasheety rikaji uplne neco jineho:

https://ark.intel.com/products/77987/In ... e-2_40-GHz
4MB L2 cache celkem, cili 4/8 = 0.5M na jadro
https://ark.intel.com/products/52275/In ... e-2_40-GHz
8MB smart cache celkem, cili 8/4 = prumerne 2MB na jadro (a to neni pevny pomer, cili kdyz nejake jadro cache nepotrebuje muzou ji dostat ostatni)

cat /proc/cpuinfo
..
model name : Intel(R) Xeon(R) CPU E3-1260L v5 @ 2.90GHz
cache size : 8192 KB
..

a co se tyce toho testu komprimaci - algoritmus na kompresi se urcite vejde s velkou rezervou do cache i kdyz je mrnava. A protoze se ten kod intenzivne vykonava stale dokola, tak v ty cache take pravdepodobne vydrzi.

[iTomB]

Precti si, co jsem psal

srovnavas L2 a L3 cache

Avoton nema L3, ty tve intely ano ... Na L2 jsem na tom daleko lepe ...