Zdravim,
mel bych otazku na Vas, jako ISP kde se Vam zda vyhodnejsi Shapovat klienty? Jesli na hlavnim routeru , nebo na nejblizsim ke klientovi ...
❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Shaping centralne nebo na AP?
0taz0 píše:Zdravim,
mel bych otazku na Vas, jako ISP kde se Vam zda vyhodnejsi Shapovat klienty? Jesli na hlavnim routeru , nebo na nejblizsim ke klientovi ...
najlepsie je podla mna shapovat na oby dvoch
0 x
kdavid píše:0taz0 píše:Zdravim,
mel bych otazku na Vas, jako ISP kde se Vam zda vyhodnejsi Shapovat klienty? Jesli na hlavnim routeru , nebo na nejblizsim ke klientovi ...
najlepsie je podla mna shapovat na oby dvoch
Ano, mam podobny nazor. Na hlavnim routru shejpuju hlavni konekt do netu a na zbyvajicich routrech pohyb po siti apod. Je predce zbytecne aby se vsechno sirilo az k hlavnimu routru kdyz nemusi.
0 x
Lokální provoz shapuju na ap a komunikaci s netem na hlavním routeru.
Co by se mělo šířit k routeru? Můj názor je (opravte mě pokud se pletu) že pokud omezím klienta na hlavním routeru na 512kbitps tak v lokální síti nebude mít provoz 1024kbitps ale stále 512kbitps. Ale to je můj skromný názor začátečníka
Co by se mělo šířit k routeru? Můj názor je (opravte mě pokud se pletu) že pokud omezím klienta na hlavním routeru na 512kbitps tak v lokální síti nebude mít provoz 1024kbitps ale stále 512kbitps. Ale to je můj skromný názor začátečníka
0 x
Gregy píše:Lokální provoz shapuju na ap a komunikaci s netem na hlavním routeru.
Co by se mělo šířit k routeru? Můj názor je (opravte mě pokud se pletu) že pokud omezím klienta na hlavním routeru na 512kbitps tak v lokální síti nebude mít provoz 1024kbitps ale stále 512kbitps. Ale to je můj skromný názor začátečníka
Pokial trasa k dalsiemu vasmu zakaznikovi nepojede cez iGW, tak urcite pojede rychlejsie ako 1024kbps...
0 x
No treba my to delame sice lamersky, ale jede to. Zvykli jsme si na simple queue, ale spise jsme to nasadili, a od te doby nepredelavali. Shapujeme na nejblizsim uzlu i na centralnim bodu.
Co se tyce nutnosti shapovani tam nebo onam, to asi zalezi. Myslim ze Gregy ma pravdu - je sice mozna "zacatecnik", ale uvazuje imo spravne. TCP neni zadna magie. V OS je cache (napr. 64KB pro connection u W2K a vyse). Kdyz na vas nekdo zacne chrlit data, tak kdyz se zacne cache zaplnovat, zacne TCP stack snizovat parametr tzv. Window. Stahnete si Ethereal (WireShark) a odpozorujte si, jak vypada TCP komunikace. Druha strana JE POVINNA v pripade snizeneho Window parametru zpomalit zasilani dat.
Na tomto principu funguje i Tarpit - nezahodi pakety, ale podrzi si spojeni tim, ze v ACK zasle window=0, a druha strana prestane posilat data. Kdyby i presto posilala, posle se RST a spojeni bude ukonceno. Vim to proto, ze jsme na hvezdarne vyvijeli CCD cameru, a ten maly TCP stack v SX52 jednocipu na to nebyl schopen reagovat :-) Tak jsme ten stack museli modifikovat ....
Takze - podle me je fama, ze vam smerem k internetu pak lita hodne dat - lita pouze mozna nez se na centralnim routeru pro dane spojeni zaplni cache, pak se to zreguluje. Samozrejme, ze jinym smerem (mimo centralni shaping), treba mezi usery, pak takovyto user muze komunikovat naplno. Takze je na vas, zdali omezite i na nejblizsim userove bodu. My to tak delame. Dalsi otazkou je, kolik tam mate klientu a jestli a nakolik to pak vsechno brzdi treba maly RB. Ale RB532 s cca 20 - 30 klienty se SQ a routovanym trafficem z dalsiho uzlu nam slape celkem pekne ....
Toz tolik a sorry, pokud se mylim :-)
Petr
Co se tyce nutnosti shapovani tam nebo onam, to asi zalezi. Myslim ze Gregy ma pravdu - je sice mozna "zacatecnik", ale uvazuje imo spravne. TCP neni zadna magie. V OS je cache (napr. 64KB pro connection u W2K a vyse). Kdyz na vas nekdo zacne chrlit data, tak kdyz se zacne cache zaplnovat, zacne TCP stack snizovat parametr tzv. Window. Stahnete si Ethereal (WireShark) a odpozorujte si, jak vypada TCP komunikace. Druha strana JE POVINNA v pripade snizeneho Window parametru zpomalit zasilani dat.
Na tomto principu funguje i Tarpit - nezahodi pakety, ale podrzi si spojeni tim, ze v ACK zasle window=0, a druha strana prestane posilat data. Kdyby i presto posilala, posle se RST a spojeni bude ukonceno. Vim to proto, ze jsme na hvezdarne vyvijeli CCD cameru, a ten maly TCP stack v SX52 jednocipu na to nebyl schopen reagovat :-) Tak jsme ten stack museli modifikovat ....
Takze - podle me je fama, ze vam smerem k internetu pak lita hodne dat - lita pouze mozna nez se na centralnim routeru pro dane spojeni zaplni cache, pak se to zreguluje. Samozrejme, ze jinym smerem (mimo centralni shaping), treba mezi usery, pak takovyto user muze komunikovat naplno. Takze je na vas, zdali omezite i na nejblizsim userove bodu. My to tak delame. Dalsi otazkou je, kolik tam mate klientu a jestli a nakolik to pak vsechno brzdi treba maly RB. Ale RB532 s cca 20 - 30 klienty se SQ a routovanym trafficem z dalsiho uzlu nam slape celkem pekne ....
Toz tolik a sorry, pokud se mylim :-)
Petr
0 x