PPPoE koncentrator pre 300+ zakaznikov

[zdenek.svarc]

jen dotaz, ty timeouty lze nastavit na libovolnou hodnotu?

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

Kód: Vybrat vše

/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ů

[zdenek.svarc]

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

[zdenek.svarc]

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

Kód: Vybrat vše

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.

Kód: Vybrat vše

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.

Kód: Vybrat vše

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.

[zdenek.svarc]

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

Edit: Verze od loopiho je shodná s verzí 2)

[lvacek]

Odvolávám co jsem odvolal, slibuji co jsem slíbyl.....

Udělal jsem znova testy řešení shapingu prostřednictvím PCQ co navrhoval loopie. Zkusil jsem stahovat data prostřednictvím vícero vláken, ale PCQ to to shapovala tak jak má. Přísahám že jsem to řešil s Klímou před více nežli rokem a opravdu se to chovalo tak jak jsem popsal. Možná nějaký bug testované verze nebo sem tam měl něco špatně v těch klasifikacích.....

Konečně jsem také vykoumal jak rozlišovat jednotlivé PPPoE spojení podle toho na jakém jsou interface kvůli řazení por správné parenty. Na každý Iface se udělá zvlášť PPPoE profile a po té se pomocí incoming filter ta IP identifikuje ve firewallu. zkoušel jsem to již dříve, ale nefungovalo mi to. Ten incoming filter totiž vytvoří pravidlo v chainu ppp. Do tohoto chainu je však nutné ten provoz jumpnout ručně zadaným pravidlem

[loopie]

Jsem rád, že to chodí. Zajímalo by mě, jak při tomto shapování budeš řešit co jsem zmínil výš - tedy klienty, kteří mají přes Framed-Route naroutováno víc adres, případně klienty, kteří mají IPv6 - podle mě ani jedno nelze (v tuto chvíli a na mikrotiku - jak je to v linuxu netuším), což je důvod, proč se vrátím k SQ.

[lvacek]

Přiznám se dobrovolně, že moc atributu framed-route nerozumím. Můžeš mi prosím osvětlit co to definuje případně na co se to dá prakticky využít? Něco jsem o tom vygooglil, ale nejsem z toho moc moudrý. Mám tomu rozumně tak, že dokážeš pomocí tohoto atributu provozovat u zákazníka dual stack a honit to prostřednictvím jednoho PPPoE spojení které potom lze shapovat prostřednictvím jedné simple qeue ? V PCQ by mělo jít ten IPv6 rozsah specifikovat maskou stejně jakou u v4, ale spojení těchto dvou front asi zatím nejde nijak dynamicky spojit.

[loopie]

Atribut Framed-Route se používá, je-li potřeba klientovi dopravit víc než jednu IP adresu, což je hodně využitelné. V podstatě přes Framed-IP-Address pošlu spojovačku, přes Framed-Route subnet pro zákazníka a OSPFkem se mi to zaroutuje do sítě. Pochopitelně ale chci takového zákazníka taky shapovat, což s tím address-listem neudělám, protože do toho se přidá pouze adresa Framed-IP. Tohle se táká IPv4. IPv6 se takhle nedá řešit vůbec, protože firewally jsou pro IPv4 a IPv6 oddělené a příslušné IPv6 atributy mikrotiku zcela chybí. SQ je podstatně flexibilnější, protože shapuje PPPoE spojení a tím i všechno výše uvedené (navíc beru jako věc svojí ISP cti, že dodám klientovi konektivitu po dostatečně tlusté lince, abych nemusel agregaci na shaperu vůbec řešit;-)). IPv6 jsem zkoušel s Framed-IPv6-Prefix i DHCPv6 a zatím je to spíš na testování - do ostrého provozu bych se s tím nehrnul.

[okoun]

Mohu se zeptat jaký kind používáte na AP (NAS) pro dynamické SQ (default-small)? Zjistil jsem že když použiju to defaultní pffio tak při vícero aktivních userů je problém s omezováním rychlosti, například uživatelé vůbec nemohou dosáhnout maximální rychlosti přitom linka není vůbec zatížená...