PPPoE koncentrator pre 300+ zakaznikov

[hapi]

to je zajímaví, tohle ukazovaly na IPTV konferenci a ty snad o tom něco vědí ne?

[honzam]

Škoda že se musíte hned hádat které řešení je lepší. Každej používá něco a je dobré dozvědět se i jiné možnosti realizace...
Díky

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

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

tak to je sila najprv napisete ze na vasej topologii switchov ide nasadit IPTV multicast uplne bez problemov. a potom napisete ze nemate switche ktore s tym su kamarati.. vy tu budete asi za miestneho komika, ze...

[hapi]

a to je problem vyměnit 10 switchů? dejte už pokoj kuva.

[Tomáš Nesrsta]

pixall: +1

[DarkLogic]

Také +1 pro pixalla.

[honzam]

[predpokladam ze ked pises ze u teba "zakaznik se nestara, sit se o nej postara", tak tam mas DHCP pripadne inu dynamiku (napriklad nejake UAM ktore umozni fungovat aj s akoukolvek nastavenou ip/mask/gw/dns). toto riesenie "sit se o nej postara" ma podla mna obrovsku nevyhodu v (ne)zabezpeceni pristupu resp jeho ochotnom promiskutinom povoleni kazdemu kto ide naokolo. nevidim ziadny technicky problem v tom, aby niekto cvakol v stupackach ethernet ktory ide k niekomu do bytu, nahodil na neho switch, a tak jak pises - "sit se o nej postara". nam sa podobne pripady stali uz nie raz, ze si niekto vylomil rack a dotiahol si vlastny kabel do switcha a hladal, skusal, scannoval, kradol IPcky, prehadzoval kable, alebo presne tak jak pisem, hodil si na kabel switch a spravil si "odbocku", dokonca bol pripad ze takto k sebe vytiahol konekt a potom ho susedovi vratil tak preNATovany, ze sused ani nevedel ze sa mu na pripojku neikto napichol, proste mu to bedalo dalej... vzhladom na to ze v SR (a mam dojem ze rovnako v CR) je provider povinny jednoznacne vediet identifikovat uzivatela pripojky na ziadost policie, tak nie je velmi vhodne aby mohol ktokolvek bez overenia vojst do siete a aby sa "sit o neho postarala". v slovenskom zakone o el. komunikaciach ma poskytovatel povinnost zabezpecit svoje siete a sluzby pred neopravnenym pouzivanim, a to ze si otvorim rack so switchom alebo sa napojim na nejaky kabel a sit se o mne postara, mi ako nejake zabezpecenie nepripada.

Dneska se internet krade spíš způsobem že klient má doma NAT wifi router a KEY dá sousedovi a skládají se na linku 50 / 50
Tomu nezabrání PPPoE ani naše VLAN řešení. Řekl bych že se to děje dost často. Těžko donutit klienta aby měl router v Bridge. To by jsme museli hlídat TTL a omezovat ho. Třeba nedávno jsme na sdílení přišli díky policii, přišli za námi jakou má klient IP adresu. Bohužel v systému jsme takového uživatele nenašli. Ale paní byla tak "blbá" že policii vykecala že nám dala vypověd s skládá se se sousedem na internet. Čili měla IP adresu souseda který měl NAT wifi router.

[lukas-svk]

zalezi kolko mas klientov...u mna na lankách je povinnosť mať wifi router s WAN do ktorého mám prístup len ja. Teda zákazník nemusí nič riešiť s IP a podobne.

Příklad: máš připojené důchodce kteří mají jen jeden stolní PC a na internet jdou 2x za týden. Budeš je nutit kupovat wifi router?

Naco kupovat router? Ved ukoncim linku a mozu nastat 2 pripady
1.) uzivatel nema router. Pripoji kabel do PC, z DHCP dostane IP Adresu a to bud: verejnu alebo neverejnu.
V pripade verejnej je na kazdom userovi aby si koncovu stanicu zabezpecil, v pripade neverejnej vykonavat nat pre cely subnet, tam tie bezpecnostne rizika su mensie
2.) uzivatel ma router. Pripoji kabel do routra, z DHCP dostane IP adresu a to bud: verejnu alebo neverejnu
V pripade verejnej si tam uzivatel na routri robi asi nat, ale to uz je jeho vec, V pripade neverejnej treba mat neverejny subnet idealne zvoleny nejaky ktory nekoliduje so standardnymi subnetmi na LAN strane beznych soho routrov (cize nie 192.168.0.0/24 , .1.0/24, .. napr 10.50.0.0/24 a pod )

Nechapem ake problemy, cokolvek za ukoncenim linky neriesime, proste ma tam zakaznik router? OK, linkuje koncovy port? OK, nevidim komunikaciu? (ziadna mac na koncovom porte)? OK, neodpoveda na arpy? rieste si router.

Aj ked tu je stale jedno ale, moze byt chybovost na fyzickej vrstve, ktora sa ale neprejavi na nasom switchporte, ale na menej kvalitnom routri pouzitom na opacnej strane linky sa moze. Toto je osemetna vec, ale stale sa to da povazovat za problem u zakaznika. Resp v takomto pripade ak zakaznik trva na vyjazde, tak ho upozornime ze sa to moze klasifikovat ako neopravneny vyjazd.

Btw: velmi sa mi paci riesenie s PPPoE, najpr skalovatelnost ako tu bola spomenuta
- pridavanie koncentratorov a automaticka(?) distribucia zataze medzi nich. Je to potom super, pretoze mozem mat jednu zdielanu VLAN na ktoru budu pripojene 2 a viac pppoe koncentratorov a neriesim nic viac ohladom redundancie.

V pripade klasickych VLAN musim riesit nejake VRRP/HSRP/GLBP resp nejake FHRP s ktorymi vychadzaju na povrch dalsie problemy.
2.) Ak chcem userom davat verejne IP adresy, musim nejaky vacsi celko rozsubnetovat a nasledne smerovat uz do jednotlivych VLAN, v pripade hapiho riesenia to ale asi nei je mozne, ked kazdy user ma vlastnu vlanu, kazda vlan by mala mat nejaky verejny subnet ... to je plytvanie ktore tu spominal pixall. Otazka je, to potom robis nat 1:1? Ved to su dalsie problemy. (IPSEC + AH a podobne...)

Ak by som mal nejaku vlanu s viacerymi usermi, zasa sa vystavujem riziku nejakych utokov priamo na L2, MITM ..atd Toto je riesitelne v pripade ME sieti nejakymi bepecnostnymi mechanizmami. (DHCP Snooping, DAI, IP Source guard) ale opat musis mat na to zelezo

Btw staticke ipcky su nedostacujuce. 1.) ludia to nevedia nastavit a vyzaduju vyjazd technika. 2.) Ak je router vo vlastnictve zakaznika, nedokazate ovplyvnovat IP adresu na wan strane routra, kedze sa do mgmt nedostanete. DHCP je na tom lepsie, viete zmenit ip adresu na wan rozhrani, resp. sfunkcnit novo-rozbaleny zakaznicky router na dialku. Vacsina zariadeni ma na wan strane by default DHCP klienta a zakazany pristup k mgmt z wan strany. Korektne nastavenu LAN stranu s DHCP servrom a NAT-om.

To DHCP sa da viazat na fyzicke porty cez option 82 (v kombinacii s DHCP snoopingom, IP source guardom a DAI) to bude asi aj bezpecne.

Toto si vyzaduje HW, co predstavuje naklady. Preto mi pixallove riesenie pride ak onajsofistikovanejsie z tych sofistikovanejsich moznych . To hapiho mi pride byt na tom horsie, z jedneho dovodu, nie je skalovatelne. resp je len tym ze pridam dalsi router a na nom opat ukoncujem VLAN-y, ale pride mi to neprakticke a z pohladu redundancie nie moc sikovne.

Ked mi spadne router ktory obsluhuje 500 VLAN tak je to problem a musi to ist ihned riesit technik co najrychlejsie.

Hapi: ako toto riesite teraz? Ked by som mal 500 roznych subnetov na jednom routri a chcel zaistit redundanciu tak am napada opat VRRP na mikrotiku, ale robit 500 vrrp rozhrani mi pride divne (ale nie nemozne.)

Tiez sme prave vo faze kedy rozhodujeme co s terajsim riesenim spravit.

Riesenia su 2, Jedno klasicka VLAN + bezpecnostne mechanizmy + DHCP
Druhe: PPPoE.

Btw zmensene MTU v pripade PPPoE. Neda sa toto obist tym ze budem mat switche (co je dneska uz vcelu bezne) budu podporovat JUMBO ramce? Ved PPPoE pridava 16B, nemal byto toto kazdy rozumny switch preniest? Lebo my vlastne PPPoE potrebujeme len od koncoveho usera k PPPoE koncentratoru, a tam ked bude siet ktora prenesie 9000k MTU tak kde je problem? Vedel by niekto vysvetlit?

[Majklik]

Když to vezmu odzadu. Prakticky všechny implementace PPPoE jedou podle původní specifikace, ta předpokládá vyjednání maximálního MTU 1492. Existuje aktualizace RFC, specifikující postup pro vyjednání delšího MTU, ale nikdo to skoro nepodporuje. Druhá věc je, že pro to potřebuješ mít podporu jumbo frames v celé síti až po to koncové PPPoE zařízení u zákazníka, což většina nezvládá a končí s klasickým Ethernetem s MTU1500.
Jinak PPPoE přidává 8 bajtů (6 bajtů vlastní PPPoE taškařice a 2 bajty hlavička s typem PPP dat, pak už jde dle typu přímo vložený IP rámec nebo něco z řídících protokolů).
Co se týče té bezpečnosti, tak varianta PPPoE nebo jedna VLANa na zákazníka nebo jedna VLANa na barák jsou na tom obdobně dobře/špatně. Všechny varianty vyžadují určitou spolupráci od prvků v síti, aby se bránilo MiM útokům, zabránění zneužití sítě pro další nežádoucí provoz atd. Pokud tam namlátím to nejtupější a nejlepvnější co existuje, tak si z té sítě udělá trošku znalý člověk holubník a v nějaké části bude schopen posílat co chce a kudy chce. U toho VLAN per uživatle mi stačí jen switche, co umí VLANy, ale ty VLANy musí být dusledně použity v celé trase až po router (takže aktuální verze udělaná u Hapiho s ttím switchem v roli koncentrátoru bez VLAN podpory je kapánek průstřelná)!
PPPoE vyžaduje zase na konci mít switche, které minimálně obsahují něco na styl izolace portů, takže access porty klientů komunikují jen proti uplinku, který vede VLANou dál ke koncentrátorům (ale opět důsledně až ke koncentrátorům).
Na duhé straně by ty switche měly obsahovat filtrování druhu provozu, v jenom povolit jen IP protokol/ARP, v druhém jen PPPoE discovery/PPPoE session.
Nejnáročnější na switche je varianta, kdy používám VLANu per barák, pak ten switch buď k tomu musí minimálně podporovat izolaci portů (pak není možná přímá komunikace klientů mezi sebou, ale dá se vést přes nadřízený prvek) nebo obsahovat hromádku zmíněných funkcí typu DHCP, ARP, IP guard/snooping, aby si lidi vzájemně nemohli dělat vtípky a krást data. A přiznejme si, že implementace v levnějších switchích buď chybí nebo je totálně mizerná, často funguje jen některé funkce a ne všeho, co je potřeba.
Co se týče toho vychvalovaného monitoringu na PPPoE. Ano, je to hotovka v jedné bedně. Podobného se dá dosáhnout i v tom VLAN režimu, když ty switche napojím na Radius, tak budu mít také pěkně přehled na podobné úrovni. Jen ujž budu muset skládat data v Radiusu z víc míst.
To s tím routerem jde udělat i jinak, než těch 500 VLAN do něj. Agregační switch (raději dva vedle sebe), co spojuje linky z baráků, pokud bude aspoň trochu L3 schopný, tak ukončím VLANy v něm a dám nad něj dva routery, které už jen řeší hromadně provoz ke klientům k tomu switchi, ten už to odroutuje do VLAN a nemusím dělat 500x VRRP a podobné voloviny, je to tam 1x. Switch musí vyřídit i DHCP relay, který pošle k routerům (a ty to můžou mít klidně napojeno na radius, takže to mám stejně jak u PPPoE). Dá se vrobit spousty víc a méně použitelných kombinací. Každá má svoje pozitiva/negativa. Hlavně je dáno, co umí ty switche a kolik do nich chci nacpat peněz...

[zdenek.svarc]

Ahojte,
Moje otazky:
1. Zvladne to 300+ zakaznikov a traffic spolu cca 200+ mbit/s s pouzitim QT shapingu? //myslim Mikrotik ako SW
2. Bude taketo PPPoE spojenie sifrovane? /koncove zariadenia TP-link routre 340g, 741nd/
3. Zabrani to attacku man-in-the-middle a ARP spoofing?
4. Bude na to dostatocny server: Server Dell PE R210 II //procesor: Quad-Core INTEL Xeon E3-1220 Processor (3.1GHz, 4C/4T, 8M Cache, 80W, Turbo),

1. Úplně v pohodě v případě dynamických simple queues, které si vytváří PPPoE koncentrátor. Jejich kombinace s QT zvýší procesorovou zátěž a to tak, že trvale, neboť bude statická.
2. MPPE 128, pokud je potřeba. Také v tomto případě se zvýší procesorová zátěž koncetrátoru.
3. Prakticky skoro ano, v teoretické rovině ne (podstrčený PPPoE server).
4. Naprosto.

Předpokládám, že toto je odpověď, kterou chtěl tazatel znát.

[zdenek.svarc]

Trvale spojeny dvojdrat potrebuje vytacanie, to da rozum. A kedze ten dvojdrat a ta siet ktora je z nich tvorena nie je ethernet, ale (na Slovensku) ATM, tak si nad tou sietou najprv ISP naemuluje ethernet, aby nad tym ethernetom pustil PPPoE, ktore tam ale vlastne vobec nepotrebuje a ma ho tam len preto, lebo si tam predtym ten ethernet naemuloval, a uz s tym holt musi nieco spravit, aby to chodilo.

PPPoA

[zdenek.svarc]

To pixall:
ADSL se identifikuje u operátora loginem? Nějak sem si toho nevšimnul. Pokud vim tak ADSL modem se identifikuje jednoduše podle kabelu od koho vede do ústředny a žádnej login tam neni protože je k hovnu. U ethernet routerů se jasně používá PPPoE protože na světě je nejvíc xDSL providerů a do toho routeru připíchneš už jenom DSL modem v bridge a PPPoE obstará ethernet router kterej v sobě má PPPoE funkci. Lidi jako ty to používaji proto, že nejsou schopni pochopit jiný fungování sítě, jinou topologii sítě. Proto cpou na ethernetovou síť PPPoE ačkoliv je to naprosto zbytečný. Proč to dělat lehce když to je jde složitě že. To je jako kdybych si postavil dálnici abych jí mohl používat pro výstavu polňačky která povede vedle. Něco jinýho je když to má spojit zaměstnance s firmou ale ne zákazníka k netu kuva. To je na hlavu.

a neodpovedal si mi kolko to mas userov

Když se k tomu Standa sám nemá, dovolím si odpovědět za něj:

http://www.internetprovsechny.cz/wifi/poskytovatel/419

Obecně se ví, že velká část příspěvků od Standy snižuje profesní úroveň fóra. Avšak jeho příspěvky v tomto vlákně bez zaváhání doporučím zcela ignorovat. Je to ztráta času.

[hapi]

dobrá, zkusím si cvičně měsíc sem nic nepsat a uvidíme jak ty moje příspěvky jsou neprofesionální a jak se toto forum pohne k profesionalitě tvořenou neprofesionálními amatery

Pokud vim, nikdo jinej sem nenapíše nic na úrovni a každej si jenom tahá triko jak mu něco krásně funguje i když je to totálni kravina a nebo sem přispívaji pouze pokud něco chtějí a očekávaji jednoduché řešení.

Ale tak jako ok, prosím tímto všechny aby si mě hodili do ignore listu a moje příspěvky tímto nebyli pro ně viditelné protože se někomu nelíbí když jeho super ultra řešení ip protokolu v ip protokolu alias PPPoE pošlapu relevantními podklady včetně reakcí i ostatních zastávající stejný názor jako já atd.. a pak jako obranu tuneláři vytahujou už naprosto nesmyslné věci a rejpaji do netunelářů už jenom proto že došly argumenty k jejich počinu.

...rozhodovat o zkušenostech podle počtu userů v síti je mimo.


Asi bych se měl začít chovat jako někteří účastníci na školeních pana Klímy. Oni vědí, rozumí, znají, chápou... neporadí!

Děkuji Zdeňku za osvětu toho že znalosti se mají prodávat a ne rozdávat

[zdenek.svarc]

K problematice autorizace xDSL v telefonních sítích, jak tady zaznělo za dotazy. Uživatel je obecně identifikovaný číslem okruhu (circuit-id). Což může vyhovovat v případě, kdy incumbent operátor neposkytuje wholesale, resp. wholesale poskytuje formou unbudnlingu (holý drát). V případě, kdy incumbent poskytuje bitstream wholesale, je nutné posunout autorizaci zákazníka na vyšší vrstvu, proto PPPoE/PPPoA. To je moje úvaha, nejsem telekomák, takže budu rád za doplnění.

A kabelovky. Ano, nepoužívají PPPoE, protože datovová vrstva je řešena DOCSIS standardem a ten PPP k ničemu nepotřebuje. To však neznamená, že CMTSka není navázaná, stejně jako v případě datových služeb nad telefonní sítí, na RADIUS.

Tohle je rozsáhlá problematika, jejíž pointa v tomto vlákně navíc vůbec nezazněla. A tou je princip standardizované centrální správy přes RADIUS nebo Diameter. A rozhodně pod pojmem standardizovaná centrální správa nemám na mysli různé bastly typu ISPadmin. Pak je totiž zcela jedno, jak fyzicky vypadá vaše přístupová síť, zda-li je na ethernetu nebo ne, protože bez výrazných obtíží na RADIUS naroubujete co je třeba - MAC autentizaci, DHCP autentizaci, DSLAM, DOCSIS/CMTS, GPON, PPPoE/PPPoA, WIFI, Hotspot/Captive portal, 802.1x, WPA2-Enterprise atd.

Komu chci tímto poděkovat, ja pixall. Bohužel, stejně jako on se domnívám, že výčet všech výhod centrální správy by většinu osazenstva nudil.

[zdenek.svarc]

Stando není důvod se hned urážet. Netvrdím, že všechny tvé příspěvky jsou od věci. V tomto vlákně bohužel ano. Ty jen prostě trpíš nehasnoucí touhou se vyjadřovat naprosto ke všemu. A bohužel i k tomu, čemu navzdory svému přesvědčení, nerozumíš. To by samo o sobě nebylo nic strašného, kdyby pak zcestné myšlenky neovlivňovali nezkušené a začínající ISPíky. A lidé jako pixall nemuseli věnovat čas k tomu, aby tvoji demagogii vyvraceli. Místo toho, aby se věnovali užitečnějším věcem.