PPPoE koncentrator pre 300+ zakaznikov

[zdenek.svarc]

Jakoze to bude tunel v tunelu? hmm to bude asi hodne spolehlive a hlavne rychle... to je asi nejhorsi vlasntost PPPoE: bezi na L2, je tedy potreba pouizvat bridge. Od te doby, co jsem v siti zrusil veskere mozne bridge a vse routuju, vsechny predesle problemy ustaly, takze to rozhodne neni pro me. jako reseni v ramci rozsahle LAN v nejakem panelaku nebo v opticke siti prosim, ale pro wifi se to IMO nehodi.

Chlapi prosím vás mějte rozum. Když nemáte s nějakým tématem osobní zkušenosti, tak se nevyjadřujte. Sice vaše perly občas pobaví, ale celkově je ztráta času pro každého, kdo ty vaše žvásty uvádí na pravou míru.

1) GRE aka mikrotikácký EoIP, je zkratka pro Generic Routing Encapsulation. Schválně píšu generic tučným. Co to znamená, a proč se mýlíš, se dočteš v RFC 2784.
2) Jakákoliv (!!!) přístupová služba, poskytovaná na ethernetu, musí začínat na L2.
3) Nikdo netvrdí, že v síti, kde běží PPPoE, musí být nasazeny bridge. Stačí používat PPPoE koncetrátor per WIFI sektor. Tomáš položil otázku na řešení pro svou topologii, tak dostal odpověď.

[zdenek.svarc]

Proto me napadlo misto tunelu a bridge udelat pppoe server na ap. A cely to ridit radiusem. Coz je stejne nutnost.

ted je otazka jak moc bude ten PPPoE server zatezovat to APcko a jak to bude snizovat rychlost na wifi a pripadne jak moc to bude padat kdyz bude hrosi signal/ruseni.

Tohle se v aktuálním vlákně řešilo, stačí jej pročíst. AP, které zároveň dělá PPPoE, může mít dokonce menší vytížení než AP, které neautorizuje. Neboť paket prochází jen takovým počtem pravidel, které odpovídá aktuálně autorizovaným klientům.

[hapi]

což je zavádějicí protože při vypnutí conn. trackingu jsem výkonem o kus dál. Jak už říkal okoun, pokud to chce někdo dělat na APčkách i se shapingem tak má dost smolíka co se týče výkonu.

[zdenek.svarc]

Stando, používáme téměř 100 APček s PPPoE a zapnutým connection trackingem, a žádný problém s výkonem nemáme. Abych tvůj argument mohl brát vážně, pověz mi, kolik AP s PPPoE používáš ty a v jakých konfiguracích? Určitě spolu přijdeme na to, proč ti tvoje síť nefunguje v pořádku.

[hapi]

no zátěži na AP se už bojím mám omnitika a 10 pppoe účtů a už tam jde CPUčko někdy na 85%, každý má svojí queue cca 6Mb a 11Mb burst, takže když se to sejde tam tam jede cca 40Mb

[zdenek.svarc]

Aha, takže sám PPPoE nepoužíváš, ale rozumy rozdáváš

[hapi]

ale za to ty nepustíš ani chlup.

[zdenek.svarc]

ale za to ty nepustíš ani chlup.

Stando, pročti si tohle vlákno od začátku. Podívej se, kolik jsem (nejen já) investoval času do vyvracení těch vašich blábolů, liskni si a běž studovat RFCéčka. Opravdu už mě začínáš s těma pindama znovu srát. Říkám ti to zas a znova, nekafrej do věcí, které nemáš sám vyzkoušené. Zbytečně ztrácíme všichni čas.

[hapi]

Člověk nemusí bejt ani moc chytrej aby věděl že PPPoE server na RBčku musí logicky zatížit procesor víc než samotnej routing či bridging. Ono to stejně musí routova a bridgovat že? PPPoE je tam jaksi navíc a všechno navíc žere výkon. Pak jistě že pokud člověk shapuje na RBčku musí se smířit s podstatnou zátěží obzvlášť když tam má MIPS 400MHz a zapnutý NV2 nebo NSTREME. Tady je spíš otázka jaký tam máš průtoky.

Já neříkám že je PPPoE špatně ale ten procesor to prostě zatíží víc a obzvlášť když tam i shapuješ. Nevzniklo náhodou tohle vlákno právě z obavy přetížení centrálního PPPoE serveru? Takže jaký pindy?

a jestli se chceš hádat tak bych poprosil o vysvětlení okouna zatížení. děkuji.

[zdenek.svarc]

Člověk nemusí bejt ani moc chytrej aby věděl že PPPoE server na RBčku musí logicky zatížit procesor víc než samotnej routing či bridging.

Stando, proboha, nemusí! Běží jenom tolik pravidel, kolik je aktuálně autorizovaných klientů. Pokud bys měl vždy 100% klientů autorizovaných, což nikdy nemáš, tak ano, nároky u PPPoE by byly v řádu nějakých pár procent nahoru. Ale to je naprosto zanedbatelné zvýšení oproti nárokům, které vznáší na výkon bezdrátová režie.

Ono to stejně musí routova a bridgovat že?

Nemusí! Pokud tomu chceš přijít na kloub, bude opravdu nutné, abys prostudoval, jak PPP, resp. PPPoE pracuje. To jsou právě ty /32 sítě, o kterých se psalo na předcházející stránce.

PPPoE je tam jaksi navíc a všechno navíc žere výkon. Pak jistě že pokud člověk shapuje na RBčku musí se smířit s podstatnou zátěží obzvlášť když tam má MIPS 400MHz a zapnutý NV2 nebo NSTREME. Tady je spíš otázka jaký tam máš průtoky.

Stando, pochop, že pokud budeš usilovat o maximálně "neprůstřelnou" službu ethernetové přístupové sítě, tak se nevyhneš ničemu, co "neroste od L2". To znamená DHCP nebo PPPoE. A protože podvrhnout MAC adresu není nic těžkého, tak PPPoE je lepší volba. Podotýkám, že se bavíme v rovině WIFI přístupové sítě.

Já neříkám že je PPPoE špatně ale ten procesor to prostě zatíží víc a obzvlášť když tam i shapuješ. Nevzniklo náhodou tohle vlákno právě z obavy přetížení centrálního PPPoE serveru? Takže jaký pindy?

Znovu opakuju, zanedbatelně.

Co se týká toho přetíženého Omnitiku, problém není v PPPoE, ale na 90% v režii bezdrátu, případně v "přepravidlování" Jaká je konkrétní konfigurace?

[hapi]

konečně si rozumíme.

[zdenek.svarc]

nevie niekto poradit preco mi PPPoE server disasociuje klientov ? neak neviem to vycitat z logu co je v prilohe

Tohle jsem nedávno řešil, byla to nějaká prkotina, kdybych si ale vzpomněl Jaká je verze RouterOS, která běží na PPPoE koncetrátoru?

[zdenek.svarc]

konečně si rozumíme.

Stando, kdybys nebyl uličník bakaný, tak si rozumíme pořád

[pmaster]

nevie niekto poradit preco mi PPPoE server disasociuje klientov ? neak neviem to vycitat z logu co je v prilohe

Tohle jsem nedávno řešil, byla to nějaká prkotina, kdybych si ale vzpomněl Jaká je verze RouterOS, která běží na PPPoE koncetrátoru?

5.19 a poriesil som to hlavne disasociovanie (nemal som transarentnu siet) ale ako pises mam teraz problem ze mii bezi ako hotspot tak sucasne pppoe na ros obcas sa stane ak sa snazi niekto lognut(je jedno ci hotspot alebo ppoe) ze to zhodi komplet klientov na pppoe hotspot ostavaju vpohode

[Walkeer]

Jakoze to bude tunel v tunelu? hmm to bude asi hodne spolehlive a hlavne rychle... to je asi nejhorsi vlasntost PPPoE: bezi na L2, je tedy potreba pouizvat bridge. Od te doby, co jsem v siti zrusil veskere mozne bridge a vse routuju, vsechny predesle problemy ustaly, takze to rozhodne neni pro me. jako reseni v ramci rozsahle LAN v nejakem panelaku nebo v opticke siti prosim, ale pro wifi se to IMO nehodi.

Chlapi prosím vás mějte rozum. Když nemáte s nějakým tématem osobní zkušenosti, tak se nevyjadřujte. Sice vaše perly občas pobaví, ale celkově je ztráta času pro každého, kdo ty vaše žvásty uvádí na pravou míru.

1) GRE aka mikrotikácký EoIP, je zkratka pro Generic Routing Encapsulation. Schválně píšu generic tučným. Co to znamená, a proč se mýlíš, se dočteš v RFC 2784.
2) Jakákoliv (!!!) přístupová služba, poskytovaná na ethernetu, musí začínat na L2.
3) Nikdo netvrdí, že v síti, kde běží PPPoE, musí být nasazeny bridge. Stačí používat PPPoE koncetrátor per WIFI sektor. Tomáš položil otázku na řešení pro svou topologii, tak dostal odpověď.

Omlouvam se za svoji nekonecnou hloupost. Presto si neodpustim par poznamek: kdyz na fyzicke vrstve, ktera je, jak se asi dohodneme, nutna, pustim EoIP (jak zde zaznelo), coz je i podle wiki tunel a na tom pustim dalsi tunel, tedy PPPoE, tak to neni tunel v tunelu, jak jsem tvrdil? Reknu to asi takhle: klidne si na tom jeste pust OpenVPN, pripadne to muzes pro jistotiu jeste hnat pres IPsec, pripadne pro jistotu, jeste treba SSH tunel. Sichr je sichr
Me pripada jednoduzsi, kdyz chces zabezpecit wifi nezavisle pro jednotlive uzivatele, pouzit nejaky ustaleny industry standard, coz rozhodne neni PPPoE over wifi, ale napr. radius. Miliony firem po svete to pouziva a funguje to, kazdy wifi klient to umi. vyhody josu zrejme: zadna dodatecna zatez routeru a hlavne zadny overhead, zadne tunely.