PPPoE koncentrator pre 300+ zakaznikov

[Caleb]

Myslim ze zasadni hapiho problem je, ze se asi nesetkal s problemy ktere vyvstavaji u vetsich siti. Kouzlo PPPoE + Radiusu je prave v tom, ze s vzrustajicim poctem uzivatelu praci ulehcuje.

Prijde mi dost nerealne, ze bych pro kazdeho usera resil nejake i predem preddefinovane DHCP servery. Zajimave je, ze mit tisice PPPoE tunelu je prasecina, ale tisice VLAN a tisice DHCP serveru je zcela v poradku

Dale mi neni jasne, jak v one VLAN/DHCP siti bude clovek resit rendundanci. Nejvetsi vyhoda PPPoE je v tom, ze topologii site muzu mit naprosto libovolnou. U mnoha poruch se mi osvedcilo, ze sem poskozeny segment site odklonil jinam, treba i pres ne plne transparentni bridge a PPPoE tunely tim velese projdou a klienti jedou dal. Hapi PPPoE porad chape jako berlicku pro reseni spatne topologii site.

Pro providera, ktery neni ve stadiu jeden admin + jeden monter a ucetni prinasi RADIUS ohromnou vyhodu Pro me neni predstavitelne, ze by se monteri nekde hrabali v mikrotiku pri kazdem overovani, zda je problem u klienta nebo u providera. To same ucetni, je schopna v informacnim systemu okamzite videt, zda je uzivatel online, kolik stahnul dat, kdy internet pouzival a kdy ne. Muze klienta libovolne pripojovat, odpojovat, menit mu rychlost bez toho, aby se nekdo logoval do jakehokoliv sitove zarizeni.
Nerikam, ze tohle v reseni VLAN/DHCP nelze naprogramovat, ale RADIUS ma pro tyto ucely vse hotove.
Dale nic nebrani tomu, PPPoE pouzit v libovolne infrastrukture, tj. klidne i u reseni s VLANama.

Vyhoda jednotne spravy jak bezdratovych, tak dratovych klientu je myslim zcela jasna. V pripade, ze by se do budoucna nasazovala libovolna technologie, clovek nemusi nic vymyslet, nasadi PPPoE a ma vyresene AAA.

Uplne mimo je pak uvaha s krabickama. Pokud uzivatel ma doma krabicku, nevidim duvod proc misto switche nenasadit dratovy router a misto tupeho AP bridge (to se jeste prodava?) dat WiFi router. Jak uz tu nekdo podotknul, pro duchodce s jednim PC je tu moznost si PPPoE vytacet na PC. V IS vidim, ze zakaznik ma PPPoE vytocene, tj. problem je v jeho vnitrni siti. A to nevidim jenom ja, ale kazdej zamestnanec, bez ohledu na to, zda umi nekde v mikrotiku prohlizet logy a zkoumat DHCP leases.

[hapi]

tohle si ani nezaslouží reakci... a už jsem reagoval

takže podle tebe lidi co nepoužívaji pppoe tak nemůžou odstřihnou lidi od netu, nemůžou jim měnit rychlosti a tohle podle tebe nezvládne účetní.

nic hele, tohle nikam nevede. Tady okolní firmy pochopili že vytáčet net z pc usery totálně štve. Dřív to tu někdo používal ale dneska po tom neštěkne ani pes.

Reakci na redundanci ani nebudu zmiňovat protože jestli máš z principu zakruhovanou síť, tak v mém podání při výpadku nějakýho spoje mi OSPFko zařídí cestu jinudy bez toho aniž bych cokoliv na síti změnil.

Vaše názory se neslučují s mímy zkušenostmi... bohužel

[Caleb]

Konecne smysluplna reakce, diky za ni

takže podle tebe lidi co nepoužívaji pppoe tak nemůžou odstřihnou lidi od netu, nemůžou jim měnit rychlosti a tohle podle tebe nezvládne účetní.

Pouze sem narazel na to, ze RADIUS ma tohle vse uz vyresene a naprogramovane. Nevim jak vase ucetni, ale vetsina ucetnich se zakaznikem nezvladne udelat nic vic, nez co umoznuje informacni system. A dle meho nazoru je radove obtiznejsi vytvorit IS, ktery bude primo komunikovat s mikrotikem, nez vyuzit reseni s RADIUSem.

nic hele, tohle nikam nevede. Tady okolní firmy pochopili že vytáčet net z pc usery totálně štve. Dřív to tu někdo používal ale dneska po tom neštěkne ani pes.

Tohle se ale tyka naprosto zanedbatelneho mnozstvi lidi, resp. u nas v siti nikdo takovy neni. Pouze podotykam, ze je zde moznost je jednoduse a i pohodlne (automaticke vytaceni ve windows) pripojit i bez nutnosti mit u zakaznika aktivni prvek.

Reakci na redundanci ani nebudu zmiňovat protože jestli máš z principu zakruhovanou síť, tak v mém podání při výpadku nějakýho spoje mi OSPFko zařídí cestu jinudy bez toho aniž bych cokoliv na síti změnil.

Zde sem mel namysli redundanci bud na urovni posledni mile, nebo naopak redundanci na urovni zdvojenych sitovych prvku (PPPoE koncetrator). Zdvojovat DHCP/VLAN koncetrator predpokladam je opet radove obtiznejsi.
To dnes vetsina wifi provideru ma pater zakruhovanou pres OSPF je vicemene samozrejme.

Vaše názory se neslučují s mímy zkušenostmi... bohužel

Nepisu to sem kvuli tomu, abych nekoho presvedcoval, doufal sem v diskuzi, kde se ukazou vyhody/nevyhody onoho ci jineho reseni. Misto toho jde o klasicke hadani ze jedine takto to je dobre a druhy zpusob je z principu spatne.

[hapi]

tak jistě že je špatně. Já mám ethernetový MTU 1500, jaký je vaše? 1480? To je první problem kterej nejsem schopnej akceptovat. Jo asi to ničemu nevadí ale proč bych to dělal?

Vy máte svůj system, my máme svůj system, pokud vám to vyhovuje, nám taky hezký den

[Caleb]

V poradku, my mame PPPoE zatim nasazeny na bezdratu a ja ted resim co pouzit v panelakach. Vicemene to same co resi zakladatel threadu rachotiak. Ale ze bych vyrabel DHCP/VLAN koncetrator a VLANoval kazdej port switche, kvuli tomu abych mel MTU 1500 se mi moc nechce. Pochopitelne, pokud by tu zaznela nejaka nesporna vyhoda reseni bez PPPoE, tak se tomuto zpusobu rozhodne nebranim.

[soooc]

V poradku, my mame PPPoE zatim nasazeny na bezdratu a ja ted resim co pouzit v panelakach. Vicemene to same co resi zakladatel threadu rachotiak. Ale ze bych vyrabel DHCP/VLAN koncetrator a VLANoval kazdej port switche, kvuli tomu abych mel MTU 1500 se mi moc nechce. Pochopitelne, pokud by tu zaznela nejaka nesporna vyhoda reseni bez PPPoE, tak se tomuto zpusobu rozhodne nebranim.

Ja vidim velkou nevyhodu vaseho reseni s PPPoE v tomto -

delame rozvody v panelaku, do kazdeho bytu tahnu kabel (zasuvka za dvermi). Pokud budu pouzivat PPPoE, tak klient, co se tam pripoji jen tak, protoze se pristehoval/cokoli, tak uvidi velke hnede a nez mu ten net zaktivuju, tak mu musim bud vysvetlit, jak si nastavi PPPoE v pocitaci (asi z toho bude nakrivo, tohle prece u stareho ISP nemusel delat/neni to nejaky pochybny dial-up?), nebo mu musim vnutit router, kde to zase zaklada podezreni, ze mu cpu predrazeny HW. Dale u nas je velmi casta praxe, ze lidi si router koupi sami a taky zapoji - chci videt, jak vsechny ty tupe hlavy presvedcis, ze PPPoE musi nastavit a ze nestaci jenom zabodnout kabel do portu WAN, jak pravi navod.

A jak uz tu nekde psal - sponzorovat lidem routery ... u nas by to bylo 3500*400 + plus kdyz se jim pokazi, tak vymenit, navic je to problem na nasi strane, takze jeste sleva ... hmmm, tohle je duvod, proc nejdem to FTTH. Myslim, ze PPPoE zacina mit dobrou TOC az od radove jineho poctu uzivatelu.

[Caleb]

Tak neni problem do tech switchu pustit i DHCP server, aby se lidem co se pripoji jen tak zobrazila stranka, ze pro internet maji zavolat tam a tam.

Pokud ma nekdo vlastni router, tak "komplikovanost" nastaveni PPPoE uz neni moc argument.
Zatim jako jedinou vyhodu VLAN/DHCP vidim moznost mit kabel ciste do pocitace bez krabicky, a ano v panelakach bude penetrace lidi, kteri to takto budou chtit vyssi. Na druhou stranu pri cene zasitovani panelaku uz me krabicka za 260Kc/klient nezabije a pokud uvazuju takto, tak zase o to levnejsi muzu pouzit switche ve vchodech. Krabicka u klienta je ale dalsi zarizeni ktere se muze podelat, to je pravda.

Spise by me zajimalo, jake procento lidi co chteji internet v panelaku si stejne poridi wifi router.

[pixall]

V poradku, my mame PPPoE zatim nasazeny na bezdratu a ja ted resim co pouzit v panelakach. Vicemene to same co resi zakladatel threadu rachotiak. Ale ze bych vyrabel DHCP/VLAN koncetrator a VLANoval kazdej port switche, kvuli tomu abych mel MTU 1500 se mi moc nechce. Pochopitelne, pokud by tu zaznela nejaka nesporna vyhoda reseni bez PPPoE, tak se tomuto zpusobu rozhodne nebranim.

ak mate pppoe na wifinach a ste s tym spokojni, nie je nic lahsie ako si to vyskusat na ethernete. ked mate dobry pppoe server (koncentrator) tak to pojde rovnako dobre ako samotny ethernet. samotne data ktore prenasame, sa tak ci tak musia najprv rozdelit na pakety, potom sa im musia pridat ip hlavicky, ethernet hlavicky, musi prebehnut spusta udaklosti na fyzickej vrstve.... pri sietarine sa deje s tymi datami take mnozstvo veci, ze tych par bajov overheadu kvoli pppoe, je uz len kvapka v mori.

nespomenul som, ze my na ethernete mame okrem pppoe aj CoovaChilli UAM (universal access method). je to hodne "ukuteny" softver, ktory funguje ako router, shaper, DHCP server, DNS forwarder, inteligentne NATko (mozete si nastavit hocijaku staticku IP/mask/gw/dns a on vas prenatuje na IP ktoru mate mat)... ak by bol hapi nahodou nas uzivatel, nemusel by sa autorizovat len cez pppoe, ktore z duse nenavidi, mohol by pouzit aj milovane dhcp, alebo prist k nasej zasuvke alebo wifi APcku aj so zariadenim, ktore ma lubovolnu staticku IP, a bez jej zmeny by sa u nas dostal na net.... overime ho nielen pppoe menom/heslom, ale aj podla dohodnutej MAC, alebo pri prvom pristupe na web redirectom na prihladovaciu stranku, kde zada to iste meno/heslo co dostal pre pppoe - a jedee... myslim ze plusminus tu istu feature ako spominany CoovaChilli najdete v miktoriku ako neaky hotspot, alebo ako uam, captive portal, chilli, alebo cosi take. pppoe a coovachilli spolu velmi dobre koexistuju, nie je problem bezat obe naraz nad tym istym ethernet segmentom. my sme toto rozbehali kvoli tomu, aby sme dostali userov so statickymi a DHCP priopjkami do radiusu a mohli ich autorizovat a accountovat hromadne na mnohych nasich routroch, switchoch, apckach, atd... podstata je v tom, ze kazdy z tychto sposobov sa overuje cez ten isty radius server - my len klientovi pridelime konto (vytvorime zaznam v databaze) a moze sa prihlasovat ktorymkolvek sposobom, a dokonca na ktoromkolvek mieste siete (ak sme mu to neobmedzili). je to cele hlavne o tom, ze to bezi cez radius.

captive portal je podla mna na nudzove pripojenie, ked nemam pppoe. u nas to pouziva tak 10-20% userov... predovsetkym ti, ktori z nejakeho dovodu este nie su zmighrovani na pppoe. user si velky rozdiel nevsimne, ale ja viem ze ta linka cez UAM nie je az taka dobra, ze nema tak stabilny ping, ze shaping nie je taky presny a semtam pusta chvilu viac a potom zase pusta chvilu menej, priemer sedi ale kolise to hore dole... to je vecou toho ako je chilli / coova / a zrejme aj hotspot v mikrotiku rieseny, ze tam tie pakety su obsluhovane cez userland... a to musi na latenciach utrpiet. bfu si to nevsimne, ale profik by si to vsimnut mohol. preferujem pppoe, pretoze sluzba je s tym ovela kvalitnejsia, aspon na nasom serveri (linux + kernel mode pppoe). shaping a QoS ktore mame spravene nad pppoe robi velmi prijemnu linku (inspirovane wondershaper-om), ma to cele rychle odozvy, velmi male a stabilne latencie, vieme na tom velmi pohodlne ovplyvnit userovi aku dostane IP (verejnu vnutornu dynamicku staticku), vieme na usera naroutovat dalsie verejne subnety (bez akehokolvek NAT)... a to vsetko iba tym, ze vytvorime konto pre usera v radiuse a nastavime si v nom tieto udaje, to je vsetko. nekonfigurujeme toho usera uz niekde inde. nema zapisany udaj v ziadnom routeri, v ziadnom serveri, len v jedinej centralnej databaze. a ked userovi konci zmluva, staci ze mu nastavime do profilu datum deaktivacie, a v ten moment ho to odhlasi, a viac sa do siete nedostane. pripojku nerusi ziadny admin, nikto nikde nic nekonfiguruje. len holky v kontaktnom centre zadaju do systemu datum vypovede. toto cele, tie moznosti ktore to prinasa a jednoduchost s ako sa to potom cele ovlada bez rodielu ci je tam 300 alebo 300.000 klientov, je pre nas ovela dolezitejsie, nez ci to ma mtu 1500 alebo 1492....

[pixall]

tak na mojí topologii switchů jde nasadit IPTV, myslim tu správnou IPTV šířenou multicastem naprosto bez problemu. Je to jenom věc těch switchů.

a ktore ze switche to tam vlastne mate? uz ste na nich to IPTV aj skusal, alebo tieswitche maju multicast v zoznam vlastnosti, tak by to tam akoze urcite malo chodit?

Navíc se silně nedoporučuje tahat IPTV s internetovími daty po jedný topologii.

a staci aby to islo samostatnym vlaknom, alebo treba aj samostatnym optickym kablom a pre istotu ich dat aspon neter od seba?

Zákon taky hovoří o logování provozu. Když vím čí jsou vnitřní IP adresy, lehce si z logu vytahnu spojení. Z databáze userů si vytahnu detail usera.

nam zatial pri kazdom doziadani policia dala vediet iba IP adresu, a chcela vediet komu patri. nevedeli tcp/udp port, neriesia ho. log spojeni je v takychto pripadoch k nicomu... a to boli vsetky pripady doziadani ktore som zazil. je to logicke - vacsina softwarov (webservery, mailservery) loguju iba IP adresu, nie konkretne porty, takze ked dojde k incidentu, IP adresa byva jediny udaj, ktory je znamy. podla mna ma dostat kazdy user od providera verejnu IP... asi preco to robia velki provideri? je to dobro usera aj providera... neotravujete usera nejakym povinnym NATkom, vam to NATko nezerie CPU, nemusite logovat ziadne velke logy spojeni ktore su potom aj tak k nicomu... ked sa poponahlate tak este nejake IPv4 verejne IPky zo zeniete, a v isp-servis.cz vam ich vybavia za par drobnych, su tam sikovni, ochotni, odporucam.

To nejsou brutální věci. Brutální věc je mít 1000+ PPPoE tunelů.

no, to jo... ale zato mat 1000 VLAN a 1000 DHCP serverov, a natovat 1000 privatnych C-cok za jednu alebo par veeejnych IPiek, to je v pohode... hodit na kazdy zo 170 kusov 24-portovych switchov po 24 vlan, a vsetky ich zapojit do nemanazovaneho switcha, cez ktory to pojde do routera s nahodenymi 4096 vlanami, to je v pohode... a este tvrdite, ze by vam nad tym akoze bezalo aj IPTV a multicast, ale dodavate ze to sa aj tak ma tahat v samostatnej topologii... tak ja tu koncim, to je pod moju uroven ale pobavil som sa vyborne, dakujem

Takže jsme se k tomu dobraly že, používáte PPPoE proto, že vaše topologie sítě je tak "zmrvená" to se pak nedivim

no... asi to uz tak bude

[hapi]

na iptv kašlem v podobě multicastu takže tam nemáme switche který jsou s tim kamarádi.

Jo dělej si prdel ale i velcí hráči poskytující multicast IPTV dospěli k závěru že IPTV je lepší oddělovat od zbytku sítě. Proto se taky dělaji krabičky typu triple play se 3 světly na optice kde jsou dvě světla pro download a jedno z nich je extra pro IPTV.

Teď tu nemluvim o HTTP IPTV v mnoha směrech překodovanou do kostičkovýho formátu tak jak to vidim u jiných firem poskytující "televizi" s přípojkou.

[miract]

Proto se taky dělaji krabičky typu triple play se 3 světly na optice kde jsou dvě světla pro download a jedno z nich je extra pro IPTV.

Hele a neni jedno svetlo pro IPTV malo?

[hapi]

proč by mělo?

[miract]

to jako ze je to halfduplexni?

[hapi]

a multicast neni jednosměrnej? Jediný co potřebuješ říkat serveru s iptv se vyřídí přes normální datovej okruh a iptv server ti pošle program po televizním vláknu. Sakra lidi, IPTV mánie je ani ne rok mrtvá a už se všechno zapomíná.

[miract]

To co jsi popsal ty, tak je pro kabelovku typu analog nebo DVB-C. IPTV potrebuje dva smery, nehlede na to, ze spousta komunikace mezi settopboxem a serverem funguje normalne na TCP. Bych chtel videt, jak bys mastil odchozi smer pres jine vlakno s jinym provozem. Neco si o tom precti, nez zacne rozumovat o necem, co vubec nevis, jak funguje...