classic.ISPforum.cz

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

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

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

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

preci system4isp

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

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..

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

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.

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... ???

net.work píše: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).

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.

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.

hapi píše: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...

midnight_man píše: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