Tok cca 100 Mbit - bridge

[jahoo]

10 000 manglů nic neni, muj komp je vitiozenej na cca 20% naprazdno a pri 20 000 manglu na 30% cca 80Mbit, horsi jeto s ques tech ja tam par tisic a us to jde do kytek , docela hodne pomuze PCQ

queues tam mam ted 6000, pro kazdy ip mam 6 radku v queues, jeden nadrazenej-p2p-ostatni pro up a to same pro down, tohle potrebuju nejak poradne vyresit, abych to za pul roku nemusel resit znovu.

Co myslis tim PCQ?

[Petr Vlašic]

Nevim, kde jsi prisel na to omezeni poctu spojeni, 65k je pouze portu. Jenze spojeni se vytvari na kazdou ip atd. takze pamet je potreba. A za tim strojem je hodne IP, pred nim taky atd. 65000 spojeni je limit pouze pro jednu IP / jeden stroj muze udelat nejvyse 65000 spojeni.

Ok. Berme příklad, že máme jeden stroj jakožto jeden centrální router s NAT. A představme si situaci kdy na rozhraní WAN jsou všechny src-porty třeba na TCP obsazeny(Pro každé spojení o různých src-portech už existuje jedna položka v connection trackingu). A vezněme si příklad kdy klient chce přistupovat k serveru, který už jednou v tabulce je. Jak potom bude router vědět který z paketů patří tomu či tomu klientovi? Samozřejmě nejsem neomylný, a je možné že se mýlím a, tak jsem provedl test(i když to bude nejspíše nějaká blbost a vím, že bych se toho asi neměl dopouštět):

Kód: Vybrat vše

:put ("Plna:" . [/system resource get free-memory ] . "kB\n\rPocet spojeni:" . [/ip firewall connection tracking get total-entries ] . "\n\r");
/ip firewall connection tracking set enabled=no ;
:delay 1s;
:put ("Prazdna:" . [/system resource get free-memory . "kB"])

Plna:12832kB
Pocet spojeni:142
Prazdna:12816kB

Tedy potom prostým kupeckým počtem:
12832kB - 12816kB = 16384B
16384B / 142spojení = 115B na jedno spojení

Což se mi zdá i tak moc pokud to vezmu takto:

src-address=4B
src-port=2B
dst-address=4B
dst-address=2B
protocol=1B-2B(nechce se mi to tady počítat)
time = něco
.
.
.

Je mi jasné, že se to také takto lehce nedá brát, protože to platí jen u spojení které nepoužívají con-mark,atd., ale i kdybych hodně přeháněl a řekl že na jedno spojení je potřeba 10kB, tak při 20000spojení dělá vytížení nějakých 195MB. Prostě jen chci říct, že se mi zdá 2GB zbytečně moc.

[fra.iesus]

asi tak...souhlas. to uz kdyby se to melo resit az do takovych zbytecnosti, jako mnohanasobne predimenzovavani pameti, tak spise doporucim se starat trochu vice o zakazniky s neverejnyma ip adresama a rozdelovat jejich traffic na vice verejnych, at si mohou trochu vice uzit treba rapidshare atd... no a koneckoncu nejsem si jisty, jak je to presne s natovanim, ale muj predpoklad je ten, ze NAT navazuje connectiony z nejakych volnych portu na jine servery a pokud by se mu to melo "krizit" (potkaji se dva), tak bud nebude nic resit do momentu, nez se nejaky port uvolni, nebo bude neocekavana situace - takze pri tom velkem poctu connectionu, ktery predpokladate, bych spise fakt resil rozlozeni na vice verejnych ip adres, nez nehoraznou ramku - a to i ty verejne ajpiny muzou byt zbytecne

[soooc]

Nevim, kde jsi prisel na to omezeni poctu spojeni, 65k je pouze portu. Jenze spojeni se vytvari na kazdou ip atd. takze pamet je potreba. A za tim strojem je hodne IP, pred nim taky atd. 65000 spojeni je limit pouze pro jednu IP / jeden stroj muze udelat nejvyse 65000 spojeni.

Ok. Berme příklad, že máme jeden stroj jakožto jeden centrální router s NAT. A představme si situaci kdy na rozhraní WAN jsou všechny src-porty třeba na TCP obsazeny(Pro každé spojení o různých src-portech už existuje jedna položka v connection trackingu). A vezněme si příklad kdy klient chce přistupovat k serveru, který už jednou v tabulce je. Jak potom bude router vědět který z paketů patří tomu či tomu klientovi? Samozřejmě nejsem neomylný, a je možné že se mýlím a, tak jsem provedl test(i když to bude nejspíše nějaká blbost a vím, že bych se toho asi neměl dopouštět):

Kód: Vybrat vše

:put ("Plna:" . [/system resource get free-memory ] . "kB\n\rPocet spojeni:" . [/ip firewall connection tracking get total-entries ] . "\n\r");
/ip firewall connection tracking set enabled=no ;
:delay 1s;
:put ("Prazdna:" . [/system resource get free-memory . "kB"])

Plna:12832kB
Pocet spojeni:142
Prazdna:12816kB

Tedy potom prostým kupeckým počtem:
12832kB - 12816kB = 16384B
16384B / 142spojení = 115B na jedno spojení

Což se mi zdá i tak moc pokud to vezmu takto:

src-address=4B
src-port=2B
dst-address=4B
dst-address=2B
protocol=1B-2B(nechce se mi to tady počítat)
time = něco
.
.
.

Je mi jasné, že se to také takto lehce nedá brát, protože to platí jen u spojení které nepoužívají con-mark,atd., ale i kdybych hodně přeháněl a řekl že na jedno spojení je potřeba 10kB, tak při 20000spojení dělá vytížení nějakých 195MB. Prostě jen chci říct, že se mi zdá 2GB zbytečně moc.

Nepredpokladam, ze masina techto parametru s 10000 mangle pravidel atd. bude cela natova do jedne IP adresy Ale samozrejme, ze jedna masina, na ktere je NAT, muze produkovat jenom 65k spojeni na tu svoji jednu IP. Jakmile pridam dalsi, tak jich mam za dalsich 65k atd.

[Petr Vlašic]

Nepredpokladam, ze masina techto parametru s 10000 mangle pravidel atd. bude cela natova do jedne IP adresy

Taky bych potřeboval poradit, co za stroj jako
hlavní router.

Já se zase divím, že jsi tak svědomitý a o více strojích uvažuješ. Proto jsem také doporučoval alespoň IBM BlueGene/L. Ale už to nechme plavat.