CLOUD CORE ROUTER (CCR1036)

[hapi]

http://www.cybermole.cz/forum/CCR%20LN.jpg

ano, a tohle je ten problem. Ty máš skoro 2000 queue a ani jedna nedosahuje já nevim, 10kpps? asi těžko co? No a mě jedna dosahuje 50kpps a chtěla by i víc třeba 100kpps nebo 500kpps. Jakmile chce, tak se losuje. Já to přičítal předtim infrastruktůře za ccrkem ale teď vim že to dělá ccrko když queue chce víc jak cca 50kpps.

[Radek Úlehla]

Jak to myslíš nedosahuje?

[hapi]

no že jednou queue neteče 10kpps.

[Radek Úlehla]

pomozte mi to někdo pochopit

[Tomáš Nesrsta]

Radku, proste Hapi na tom asi neshapuje klienty ale lokality a kdyz nejaka lokalita prekroci 50kkps tak mu CCRko zacne blbnout. A nebo Hapi shapuje klienty ale ma tam nejaky ultra mega geeky ktery maji na trafficu vice nez 50kpps.

[Radek Úlehla]

Jo teď už to chápu, on mluví o packetech... to jsem přehlídl. No to je pak jasné, to je totální hovadina, to řešit takto

[hapi]

když tohle řeknu ciscu tak se mi vysmějí že? protože tam nebude nejspíš problém.

Dalo se CCRko protože má sílu, teda aspoň to tak uváději. Cloud core router, už ten název, že teda na páteře a nějaký vostrý páteře pro globální řízení vysokých toků a zase hovno. Už chápete proč jsem CCRko ještě než vyšlo kritizoval? Protože jsem podobnej kiks čekal ne-li úplně stejnej. Nemůžu prostě chtít po slabém výkonu na jádro aby dělal něco takovýho. Jak už jsem řek, ten procesor má generovat trafik a ne ho řídit což si někdo u mkček zase asi nepřečet. 36 kalkulaček prostě nemůže pokořit jednu věděckou kalkulačku.

mimochodem... monitoruješ latence přes to ccrko? já z toho nadšenej teda nejsem. Každou chvilku mi volá z dohledu že je vysokej ping. Upřimně, dělá to to samí jako RB1100AHx2 když je pod tlakem a výkonem se to moc neliší. Akorát 1100AHx2 jde do kopru mnohem dříve.

[hapi]

Radku, proste Hapi na tom asi neshapuje klienty ale lokality a kdyz nejaka lokalita prekroci 50kkps tak mu CCRko zacne blbnout. A nebo Hapi shapuje klienty ale ma tam nejaky ultra mega geeky ktery maji na trafficu vice nez 50kpps.

ano, chci od toho pouze přibrždění provozu ether1 -> erhet2 a zpět. Nic víc. A ani to ccrko nezvládne.

Zajímalo by mě co na to lidi kteří tim chtěji brzdit tok pomocí jednoho PCQ pro tisíc lidí. Ano, i tací jsou a neni jich málo. Tak už to bude dělat paseku.

[hapi]

teď jsem si to zkoušel znova. Bohatě stačí 40kpps na to aby jakákoliv queue s tim zamávala k zemi.

[Pintero]

teď jsem si to zkoušel znova. Bohatě stačí 40kpps na to aby jakákoliv queue s tim zamávala k zemi.

A dela to queue nebo mangle?
Protoze kdyz koukam na ten screen od cybermole tak tam u tech nadrazenych queue jde okolo 40-50k pps. Predpokladam, ze ty manglovany nejsou.

[hapi]

mangle to nedělaji. Zapnu QT nebo SQ a konec. Manglů tam můžu mít kolik chci. Ono to při 40kpps ještě moc bordelu nenadělá. Jak to stoupá tak to jde víc do kopřiv. Ono to moc poznat neni. Stopuje se torch, rozhraní občas načítá pomalu, nepravidelně posílá data, traffic v grafu má dost mezer atd..

[Radek Úlehla]

Jo to všechno o optimalizaci konfigurace ... PCQ pro 3000 userů

http://www.cybermole.cz/forum/CCR_CV_fiber.jpg

[hapi]

Já chtěl pouze fifo jednu frontu. To zvládá RB1200 bravurně a líp než tohle. Tam o žádnou optimalizaci nejde. Navíc opět ti neteče koncovou queue víc jak 50kpps. Vo ničem.

Ok vemu to z jiný strany. Mám blade server s tokem 100kpps a chci ho ochránit proti přetížení konektivity resp. chci ochránit konektivitu proti přetížení tak aby nejela na strop.. dejme tomu na 300Mbit. Ukaž se.

[Radek Úlehla]

Nastavim serveru portovou rychlost na switchy.

[Radek Úlehla]

A místo řešení důsledků, vyřeším problém koupením konektivity nebo přesunu server tam, kde ta konetivita je