QT na bráně nebo na bodech?

[okoun]

Prosím jeslti se můžete podělit názorama pro a proti jestli je lepší mít QT na bodech, či jen na hlávní bráně? jednalo by se o síť kde je internet, kde jsou datové okruhy a kde je někde IPTV, na síti je i vícero konektů a používal by se radius. děkuji

[Tomáš Nesrsta]

vsechno ma svoje pro a proti. Otazak co pouzivas na bodech za HW protoze RB shapingem usmazis. Asi idealni stav je mit QT centralni a pak jeste jednou u klienta na jednotce

[hapi]

ideální to je ale kdo bude měnit nastavení v cpečkách při nějaký změně.

[tom-tom]

ispadmin nebo systems4isp ještě neumí hromadný konfig cpe?

[Tomáš Nesrsta]

preci system4isp

[okoun]

tak trochu z toho děláte OT ale jde hlavně o to jaké železo na ty omezováky a hlavně se nějak nezamotat v nastavení, toho se bojím. a hlavně zajistit aby někde něco nejelo na doraz a nebyly lagy

[hapi]

no tak nejsou zase tak mimo ale o něco podobnýho se pokouší ispadmin a všichni známe jak to funguje/nefunguje a jaký to přináší průsery když se script uscriptuje. Pro zjednodušení by šlo omezovat na APčku ale zase ne všichni máme APčka který by něco takovýho zvládly a to vůbec nepočítám omezení zápisů flash pamětí atd..

Jo jasný, nejlepší je omezení u zdroje tedy v netu a u klienta. Jedno neni reálný a druhý je těžce závislí na hardware. Proto většina znás volí bezpečnej kompromis v podobě jedný silný GW která to obstará vše. I když za shaping na APčku v případě IPv6 by se hodil jelikož to teprve přijde a lidi budou tahat mezi sebou a bude to dělat problemy. S tim narazíte na to že když budou lidi tahat mezi sebou na jednom APčku, neomezíte to pokud nepoužijete WDS a zase je tu problem s tim že APčko bude muset bejt výkonější a bude se při opakovanym nastavování opotřebovávat flashka.

Pak někdo namítne nedavný flame pomocí pptp over ethernet což je asi pro tohle optimálnější ale zase tam jsou jiný průsery atd..

[okoun]

no právě a zajímá mě jaké jsou průsery na pptp over ethernet

[hapi]

no zkus si to rozchodit a dojde ti to co musíš všechno udělat aby ti šel u klienta net. Vem si že postavíš nad aktuální vrstvu IP další vrstvu kterou tuneluješ. Pokud máš u klientů mkčka, seš celkem vysmátej a zvládneš to na dálku. Ale pak se ti občas stane že budeš hledat verze Mkčka kde pppoe funguje korektně, nebo držet seznam userů na bráně. Těžko i použiješ nějak smysluplně backup gateway když hlavní pptpoe server chcípne atd.. jako nejsou to jenom mínusy ale je třeba je říct.

[net.work]

vy z vas, kteri mate centralni shaping - mate tedy nejak poreseno to sosani klientu v ramci site (ted nemyslim v ramci AP, tam je stejne komunikace mezi klienty na AP zakazana), ale treba klient z vesnice A bude pres ICQ posilat klientovi z vesnice B nejaky soubor a zjisti ze to vali rychle (diky P2P mezi PC ve stejne siti) a vesele si zacnou posilat a sdilet filmy... ???

[miract]

vy z vas, kteri mate centralni shaping - mate tedy nejak poreseno to sosani klientu v ramci site (ted nemyslim v ramci AP, tam je stejne komunikace mezi klienty na AP zakazana), ale treba klient z vesnice A bude pres ICQ posilat klientovi z vesnice B nejaky soubor a zjisti ze to vali rychle (diky P2P mezi PC ve stejne siti) a vesele si zacnou posilat a sdilet filmy... ???

Nevim jak u tebe, ale ja jsem se snad s tim to problemem setkal snad jednou. Da se to resit kombinaci centralniho shapovani downloadu a upload resit primo na klientskych mikroticich nebo ubnt. Preci jen upload je oproti download v pomeru minimalne 1:10(kdyz nepocitam srackovy torrenty).

[hapi]

hmm, no ale download má zase ten druhej ne? Matně si vzpomínám že schopnost využít vnitřní ip adresy pro komunikaci zvládne pouze torrent čehoš se dá využít. ICQ a podobný věci snad kromě ještě hamachi to nezvládnou a vždy to teče přes nějaký server v netu. Jo omezováním u klientů to vyřeší celkem dobře až na to že na tu chvíly stejně přetíží APčko když tam jsou i další useři. Řešením by bylo doplňkovým shapingem na APčku. Otázkou je jestli to nějak řešit když NV2ka se postará o rovnorměrný rozložení zátěže a do budoucna s nstremem moc počítat nelze na duálních věcech.

Ale jinak v prvotních letech sítě jsme taky pozorovaly brutální tahání mezi klienty jenomže dneska? lidi jsou hloupější, pošlou to přes uložto nebo nějakýho im klienta a tedy v posledních letech jedinej problem je že zřídka kdy někdo zaseká apčko uploadem torrentu v udp. Jinak neni třeba nic řešit a i to zasekání torrentem řeší NV2ka.

[midnight_man]

U nas shapujeme lokalne pre kazdu dedinu, pripadne cast dediny samostatne...vacsinou su to nejake AH boardy. Obcas sa stretnem s nepríjemným faktom....na AHčko tečie 10mbps no klientom idu len 4 . Takyto bordel vedia narobit nejake UDP sracky v torentoch.

[miract]

hmm, no ale download má zase ten druhej ne? ...

APcko pretizi v pripade, ze by klient z vnitrni site, od ktereho stahuje, mel nastavenou velkou rychlost uploadu, coz u nas na optice mame rychlosti soumerne, tak by to urcite nebyl problem. Ale jak rikam, setkal jsem se stim jen jedenkrat, tak to asi nema cenu resit...

[okoun]

U nas shapujeme lokalne pre kazdu dedinu, pripadne cast dediny samostatne...vacsinou su to nejake AH boardy. Obcas sa stretnem s nepríjemným faktom....na AHčko tečie 10mbps no klientom idu len 4 . Takyto bordel vedia narobit nejake UDP sracky v torentoch.

no jo no ale když máš duální páteře třeba tok 40-60Mb down tak nevim nevim, jedině dávat na body RB1000 a to se podle mě dost prodražuje protože za rok budou rb1000 šity