PPPoE koncentrator pre 300+ zakaznikov

hatatitla

Ano každe NAsko sa pripaja na dva radius servery , každy z radiusov sa pripaja do SQL clustra odkial si taha /zapisuje údaje. Každy znich ma iny pristupovy server k SQL clusteru.

Synchronizovať dva Radius servery ručne nieje dobrý nápad , stým si koleduješ o problémy.

okoun

Prosím někoho kdo používá pppoe a ospf, jestli by se mi nevyjádřil k tématu <--- l -->viewtopic.php?f=5&t=9987<--- l -->

Díky

Trnec

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

jsem na 11ty strance tohodle topicu a jeste jsem necetl dal (urco budu), tak jsem se chtel zeptat, co se stane s celou siti, kdyz ti zdechne RADIUS server?

predpokladam, ze bude komplet cela sit v riti...

hapi

pokud urdžuješ i backup server tak ne.

okoun

ano, bude cela v řiti, i když pppoe se hned neodpojí když už je zaasociované, dá se tam někde nastavit timeout po kterém si znovu šahne na radius.

jak bylo psáno, je třeba mít backup servery, to je myslím samozřejmí pokud to myslíš s jakým-koli ověřováním vážně.

my máme asi 3 backup servery a jeden primár v serverhousu.

Trnec

ano, bude cela v řiti, i když pppoe se hned neodpojí když už je zaasociované, dá se tam někde nastavit timeout po kterém si znovu šahne na radius.

jak bylo psáno, je třeba mít backup servery, to je myslím samozřejmí pokud to myslíš s jakým-koli ověřováním vážně.

my máme asi 3 backup servery a jeden primár v serverhousu.

je možné provozovat radius server primo na routeru nebo dejme tomu, na routerech, ktere se s hlavnim routerem nejakym zpusobem synchronizuji? jedna se o MK (usermanager) a o cca 30 klientech (CPE/notebooky)? nebo nejake lepsi reseni? pppoe? :)

okoun

no s usermanagerem nemám moc dobré zkušenosti, ano dá se, ale nemám dobré zkoušenosti.

raději si vyhranit nějaký linux s ldapem a freeradiusem, nemusí to být ani moc náročný stroj, na routeru bych to nedělal.

Trnec

no s usermanagerem nemám moc dobré zkušenosti, ano dá se, ale nemám dobré zkoušenosti.

raději si vyhranit nějaký linux s ldapem a freeradiusem, nemusí to být ani moc náročný stroj, na routeru bych to nedělal.

diky za reakci, mohl by jsi prosim napsat konkretni nedobre zkusenosti, prosim?

zdeneksvarc

jsem na 11ty strance tohodle topicu a jeste jsem necetl dal (urco budu), tak jsem se chtel zeptat, co se stane s celou siti, kdyz ti zdechne RADIUS server?

predpokladam, ze bude komplet cela sit v riti...

Kdepak. Ověření klienti jedou nerušeně dál, akorát se jim nebude v interim updatech aktualizovat accouting. Nový klient a klient, kterému spojení sletí, se samozřejmě už nepřipojí. A těmi backup severy bych to nehrotil. Nejsou k zahození, ale u nás máme max 24 hodin staré zálohy kompletního OpenVZ hosta. Takže není problém to kdykoliv na dálku nahodit na kterýkoliv ze tří uzlů virtualizačního clusteru, které máme k dispozici. U backup severu je totiž trošku háček v synchronizaci accouting dat, pokud každý RADIUS server používá svoji SQL.

ano, bude cela v řiti, i když pppoe se hned neodpojí když už je zaasociované, dá se tam někde nastavit timeout po kterém si znovu šahne na radius.

Ne, nebude. To jsou interim updaty, které nerozpojují spojení mezi klientem a koncetrátorem.

Trnec

jsem na 11ty strance tohodle topicu a jeste jsem necetl dal (urco budu), tak jsem se chtel zeptat, co se stane s celou siti, kdyz ti zdechne RADIUS server?

predpokladam, ze bude komplet cela sit v riti...

ano, bude cela v řiti, i když pppoe se hned neodpojí když už je zaasociované, dá se tam někde nastavit timeout po kterém si znovu šahne na radius.

Ne, nebude. To jsou interim updaty, které nerozpojují spojení mezi klientem a koncetrátorem.

diky, jen dotaz, ty timeouty lze nastavit na libovolnou hodnotu?

zdeneksvarc

jen dotaz, ty timeouty lze nastavit na libovolnou hodnotu?

Jasně, většinou pět nebo deset minut:

/ppp aaa> set interim-update=10m

/ppp aaa> print

use-radius: yes

accounting: yes

interim-update: 10m

okoun

nevím, ale toto číslo bych moc nezvedal, potom se z toho stane dost taková ne pružná síť

raději šahnout po backup serverech, myslím že jsou dost podstatné pro použití radiusu s pppoe či hotspotů

zdeneksvarc

To je skutečně takový problém odolat nutkání za každou cenu napsat do vlákna sebevětší ptákovinu? Znovu opakuju, ztrapňujete sami sebe a občas tím i pobavíte, ale nejsme tu od toho, abysme neustále vyvraceli žvásty samozvaných odborníků, kteří se i stydí za své jméno.

okoun

hmm, aha tak si tam nastav třeba 20 min....

zdeneksvarc

Výborně Lukáši, takže sis právě vykoledoval ban na sedm dní za opakované porušení Pravidel v bodě 3) "Odpověď na jakýkoliv příspěvek musí být věcná". A nemůžeš říct, že jsem neměl trpělivost. Budiž to demonstrací, že i trpělivost se sviněním vlákna má své meze.

lvacek

Již delší čas pozoruji tuto diskuzi. Jenom ve stručnosti. Radius využíváme na ověřování techniků pro přístupy techniků do síťových zařízení. Převážně MK. Plánuji to rozběhat i se switchy. Každý technik po sobě v logu krásně zanechává stopy a pokud mu chcete sebrat přístup nebo změnit práva tak je to jeden záznam v MySql. Škoda že tento standard nepodporuje UBNT. Myslím tím AAA autentifikaci.

Další využití nastalo při přidělování IP přes DHCP na základě MAC, Postupně však přecházíme na PPPoE a doufám se brzy dočkám kompletní implemetace v celé naší síti.

Chtěl bych se zeptat asi Hlavně Zdeňka jak řeší shaping. Je mi jasné že mohu vracet radiusem atribut rate-limit který mi vytvoří simple qeue nicméně každé zařízení má svoje technologické stropy a především u bezdrátů je žádoucí abychom zákazníky řadily do nějaké stromové struktury pod nějakého parenta abychom se nedostaly s celkovou rychlostí tech qeue nad kapacitu sectoru. Momentálně to řeší pomocí identifikace zákazníka na konkrétním interface kde packety projdou různými výhybkami ve firewallu až jsou správně omanglováni.Konfigurace shapingu je poměrně pracná a pokud tam potřebuji něco přidat, tak mě to docela zaměstná, než rozmotám jak to tam mám udělané. Zvažoval jsem použít simple qeue přidávané radiusem a k tomu vytvořit statickou tree která by řešila maximální rychlost sector. Nicméně dle Klímy a údajně Janise z MK simple a tree qeue nelze kombinovat. Další možnost by bylo nabouchat tam qeue tree na každého zákazníka a pomocí atributu Framed-IP jim vracet IP. Toto řešení je však kontraproduktivní vůči celé pointě radiusu který by měl být scopen maximum věcí řešit dynamicky. Umí shaping na MK řešit takovéto záludnosti nebo to řešíte nějakým linuxovým shaperem?

loopie

Pokud chcete používat Queue Tree a ovládat ho radiusem, je to poměrně jednoduché. U nás používáme s pcq. Vytvoří se queues, uvádím pouze jeden směr

name="5M-DOWNLOAD" kind=pcq pcq-rate=5M pcq-limit=50 pcq-classifier=dst-address pcq-total-limit=2000 pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-src-address-mask=32 pcq-dst-address-mask=32

Sestaví se strom, pro každý tarif jedna větev.

name="5M-down" parent=global-down packet-mark=5M-down limit-at=0 queue=5M-DOWNLOAD priority=8 max-limit=0 burst-limit=0 burst-threshold=0 burst-time=0s

V manglích se označkuje.

chain=forward action=mark-packet new-packet-mark=5M-down passthrough=yes dst-address-list=5M

V radiusu se nastaví u klienta reply atribut Mikrotik-Address-List = 5M a je to.

lvacek

Díky za rychlou odpověď. Podobné řešení jsem testoval. Dokonce někde na tiktube o tom má Janis přednášku. Nicméně má to to zádrhel. Ten mangle neidentifikuje na jakém je ten dotyčný interface, což je důležité pro správnou agregaci na daném sectoru. To PCQ funguje jinak než prezentují. Byť tam dáte pcq-src-address-mask=32 tak to klasifikuje každý stream zvlášť. Pokud bude zákazník např. tahat z ulož to, z uschovny a u toho čučet na youtube, tak bu to dá těch 5 mbit 3x :( začal jsem toto PCQ implemetovat, nicméně sem to ukázal Klímovy a on mě navedl na tento nedostatek. Udělaly jsme testy na stole a skutečně se to tak chová. Je to tak dokonce popsané i v manuálu. http://wiki.mikrotik.com/wiki/Manual:Queues_-_PCQ Byl bych velice rád kdyby to bylo tak jednoduché jak popisuješ výše, ale bohužel to nefunguje :(

Mikrotici něco uvádějí že ve ver 6 dochází k nějakým vylepšení v simple quee. Zkoušel jsem si instalovat nějakou betu, ale zaznamenal jsem akorát přesun některých parametrů na jinou záložku ve winboxu.

loopie

To mě docela vyděsilo a radši jsem si to ještě zkontroloval a funguje to správně. Klient nemůže překročit nastavenou rychlost ani když stahuje z více svých PC najednou. Důležité je nevytvářet pcq pro každého klienta, ale pouze pro každý tarif. Jednotliví klienti pak jsou ty substreamy a funguje to tak jak chci. Toto řešení má spíš jiná úskalí, kvůli kterým se budu vracet k simple queues - IPv6 a klienti, kterým se routuje víc IP.

zdeneksvarc

Každý technik po sobě v logu krásně zanechává stopy a pokud mu chcete sebrat přístup nebo změnit práva tak je to jeden záznam v MySql.

Ověřování operátorů proti RADIUSu je jasná věc, ale opravdu krásnou stopu zanechá každý technik až v syslogu (topic: SYSTEM), viz viewtopic.php?f=79&t=10103

Chtěl bych se zeptat asi Hlavně Zdeňka jak řeší shaping...

U nás jedeme pouze simple queue + burst, ale granulárnější shaping se dá řešit několika způsoby. Jeden tady zazněl od loopiho a další můžou vycházet z těchto myšlenek:

1) Centrální shaper v core sítě (například něco od bratrů Kazíků, Luhačovice/Jezerka, zasvěcení ví), který zákazníka identifikuje podle IP adresy, kterou porovná proti RADIUS serveru.

2) Lokální shaper, klienta rozhodí do address listu s příslušnými pravidlem podle attributu Mikrotik-Address-List, viz viewtopic.php?f=77&t=10061

« Předchozí stránka Další stránka »