Kde nastavovat QS

[vojtasan]

Zdravím,
kde je lepší provádět QS a další nastavení ohledně řízení rychlostí klientů,maškarády atd..Na hlavním routeru,nebo na APčkách a nebo rovnou u klientů?Mám téměř celou sít na MK.Kde tedy např.nastavit QS apod.Na foru jsem četl spoustu informací,ale nic konkrétního,resp.jednoznačného, jsem nezjistil.Dík za případné reakce.

[pepulis]

Zdravím,
kde je lepší provádět QS a další nastavení ohledně řízení rychlostí klientů,maškarády atd..Na hlavním routeru,nebo na APčkách a nebo rovnou u klientů?Mám téměř celou sít na MK.Kde tedy např.nastavit QS apod.Na foru jsem četl spoustu informací,ale nic konkrétního,resp.jednoznačného, jsem nezjistil.Dík za případné reakce.

100 lidí, 100 chutí. Zvolit si to musíte sám, to vám nikdo neporadí. Za mě je lepší řídit rychlost na jednom centrálním místě a rozdělovat celou konektivitu mezi všechny uživatele, než to řídit na jednotlivých sektorech a tím si vyčleňovat konektivitu do různých směrů.

[vojtasan]

To je právě to...100 lidí,100 chutí....a nějaké pro a proti?Třeba podle mého názoru,pokud klienta omezím už na jeho jednotce,tak pro sít by to mělo znamenat menší zátěž,než když je budu omezovat až na centrálním routru.Je to tak,nebo se mýlím?

[pepulis]

To je právě to...100 lidí,100 chutí....a nějaké pro a proti?Třeba podle mého názoru,pokud klienta omezím už na jeho jednotce,tak pro sít by to mělo znamenat menší zátěž,než když je budu omezovat až na centrálním routru.Je to tak,nebo se mýlím?

A jak by jste to řídil, pokud by bylo omezeni nastaveni primo u klienta. Smyslem centralniho rizeni rychlosti je to, ze jakmile je linka vytizena na max. tak se ridi dle nastavenych pravidel v QT rovnomerne (dle rychlosti, priority apod.). Pokud by bylo omezeni u klienta, nebylo by nikde zadne centralni rizeni a kazdy klient by si urval, co by slo, tj. klient s torrent stahovanim by si urval vice, nez nekdo, kdo si bude prehravat youtube (obrazne receno). Na co roste pozadavek je jen centralni server / pc, ktery to bude ridit, coz pri dnesnich cenach za HW neni zadna velka polozka. Nevim jake mate rychlosti, kolik uzivatelu budete ridit, ale s nejakou intel i3 sestavou, ssd diskem, super mikro 1Gbit kartou, uridite 100 vky uzivatelu.

[Dalibor Toman]

To je právě to...100 lidí,100 chutí....a nějaké pro a proti?Třeba podle mého názoru,pokud klienta omezím už na jeho jednotce,tak pro sít by to mělo znamenat menší zátěž,než když je budu omezovat až na centrálním routru.Je to tak,nebo se mýlím?

musis se na to kouknout z obou stran. Pokud bude klient z nejakeho duvodu posilat UDP packety 100mbps smerem do site tak budes rad, ze shaper je hned u klienta. Packety se zahodi hned u nej. Pokud ale pobezi stejny tok z Internetu tak Ti probehne celou siti a omezi se az (pokud ho nerizne nejaka ucpana linka driv) na CPE u klienta a az tam se ty nadbytecne packety zahodi. CIli takovy tok Ti muze zbourat i dalsi cast site.

Centralni shaper ma IMHO tyhle vlastnosti:
+ pobezi na silnejsim CPU, takze bude stihat
+ umozni slozitejsi CFG - napr rizeni i toku linek k zakaznikum
+ je flexibilnejsi. Muzes jej prekonfigurovavat snadno na zaklade nejakych podnetu z DB (zmeny tarifu, zpomaleni neplaticu,...)
+ nejses vazany na typ a vlastnosti shaperu na CPE. To pripadne shapovat ani umet nemusi
+ pokud bude treba, muzes vymenit HW i operacni system na centralnim shaperu (MT vymenit treba za Linux) , abys mohl realizovat to, co starsi HW/SW neumi. Plosna vymena CPE obvykle boli vic.
+ centralni shaper je obvykle zaroven i router a firewall. Takze na nem muzes realizovat dalsi veci - blokovani neplaticu podle DB, filtrace skodicu (open SMTP/DNS atd), sber dat pro data retention...
- problemove bude reseni skodicu (zavirovany PC, ktery chrli packety, muze ucpat linky az k centralnimu shaperu). Ale da se zkombinovat s nejakym bezpecnostnim statickym shaperem na CPE

[ppp76]

Zatim se mi jevi jako nejlepsi kombinace obou , neco u klienta (trebas pocet connection) neco centralne

[frito]

V našem IS se dá nastavit aby QT pro download házel na Hlavní bránu a QT pro upload nejblíže ke klientovi takže AP

- Download máš pak rozdělenej centrálně
- Nad uploadem pak nemáš takovou kontrolu ale ten je výrazně nižší takže by nemělo docházet k saturaci.

Honza

[vojtasan]

Tak teď jsem z toho jelen

[frito]

Tak teď jsem z toho jelen

Je to možné .
Specifikuj z čeho přesně .

Honza

[ludvik]

QoS se dělá tam, kde má ochránit nějaké nedostatkové zdroje, tedy kapacitu linek. Máš-li páteřní síť dostatečně dimenzovanou, stačí ti QoS u klientů. Nemáš-li, potřebuješ centrální.

V našich prostředích potřebuješ oboje.

Centrální je lepší na správu. Máš to všechno pěkně na jednom místě, dokážeš si ty třídy pro klienty pěkně uspořádat. Nevýhodou může být problematické řešení pro >1Gbit. Uroutovat 10G zvládne leccos ... ale QoS+PAT už moc ne moc.

Už se ti na něm ovšem špatně (nemožně, podle mě) definují QoS v případě, kdy máš všelijak řetězené omezené spoje a ještě k tomu zakruhované nějakými ještě omezenějšími. Pak nastupuje QoS blíže ke klientu, aby si pořešila tu poslední (a předposlední) míli. Tam už to může být pořešeno jen nějakým univerzálním způsobem, aby jeden klient nedokázal síť zahltit.

Pro PAT platí skoro to samé - centrální má obrovskou výhodu v agregaci veřejných IP. Prostě máš jeden velký segment, který si můžeš až na úroveň jedné IP rozhazovat libovolně po síti. Ale opět - s počtem IP, počtem paketů, počtem megabitů roste chuť na výkon takového stroje.
Nebo můžeš routovat přímo veřejné po své síti a PAT mít vysunutý až klidně na úroveň jednotlivých access pointů. Jenže pak buď musíš mít těch IP dostatek, abys to dokázal rozumně rozsegmentovat, nebo to děláš po jedné a pak ti bobtná routovací tabulka (což s podivem nemusí být až takový problém).
U centrálního si dokážeš poradit dokonce ručně (okopírovat jeden řádek a reloadnout iptables zvládne i cvičená opice). Pokud to rozdistribuuješ, bez řídícího systému se neobejdeš. Nebo se z toho zblázníš.
Centrální je pro změnu úzké místo sítě z hlediska spolehlivosti. Routing si pořešíš dublovaně, ale QoS+PAT už hodně blbě. Skončíš u toho, že maximálně máš jeden router ve skříni jako studenou zálohu.

Nebo máš všechny klienty řešené nějakým tunelem (PPPoE třeba) a pak v podstatě PAT neprovádíš ... to je na klientské jednotce. Ale v tunelech se moc neorientuju.

A jak ti řekli ostatní, na tohle kuchařku nikde nedostaneš. Souvisí to s topologií sítě, možnostech hardware, schopnostech administrátorů ... schopnostech účetních. A už vůbec je hloupé tohle chtít v diskusním fóru. Nastiň jeden konkrétní problém, poskytni dostatek informací - a nejspíš se ti dostane odpovědi. Ale řešit odpověď na základní otázku života, vesmíru a vůbec ... nevím nevím

[info@adambalko.cz]

Ale řešit odpověď na základní otázku života, vesmíru a vůbec ... nevím nevím

42

[vojtasan]

Všem děkuji za reakce.
Prokousávám se tím a začínám chápat.
Dík

[zeroNET]

Za nás je lepší dělat shaping na jednom kvalitním stroji. Nám běží na postarším 4 jádru s routerOS, zatížení ani nemá smysl zmiňovat, je nízké... Zkoušeli jsme dělat shaping na koncových ap, ale pak při větším toku nestačí ani 493AH...

[info@adambalko.cz]

Za nás je lepší dělat shaping na jednom kvalitním stroji. Nám běží na postarším 4 jádru s routerOS, zatížení ani nemá smysl zmiňovat, je nízké... Zkoušeli jsme dělat shaping na koncových ap, ale pak při větším toku nestačí ani 493AH...

Přesně tak. Nám se tu už pomalu zadýchávala i 2011-ka na site se čtyřmi MIMO sektory, takže jsme to v systému přepnuli na jeden hlavní shaper (12jádro Dell PowerEdge 2950) a ten se ani nezapotí