PPPoE / RADIUS / Shaping / QoS

Hálózatok egyéb

Csinaltam egy fasza kis pppoe-server / radius / mysql kombot, mukodik is szepen, winxp-vel tesztevel, authol radiuson keresztul. Ez a resze okay.

Meg kell viszont valositani az upload/download savszelessegek kiosztasat user/pw alapjan. SQL-ben el tudom tarolni a min-ul, max-ul, min-dl, max-dl ertekeket ez ok. Kerdes erre milyen shaping megoldas lenne a legjobb? htb-t szeretnek, cronbol egy script percenkent generalja le a shaping tablat? Vagy ki hogy oldana meg? Thx.

  • 3963 megtekintés

( cookie | 2007. 02. 01., cs – 22:47 )

a megoldást majd oszd meg velünk is.köszi.

( gyu v | 2007. 02. 01., cs – 23:44 )

pppd-nek van radattr modulja. Még nem használtam, de pont hasonló témakörhöz néztem: amikor ppp-t felépíti, radius attributumokat bele tudja pakolni egy fajlba, hogy a etc/network/if*.d scriptekből ezt felhasználhasd.

Innentől már csak annyi, hogy az interfész "felépülése" után beállítod az adott pppN interfészre a ratelimiteket, azt hali. Itt nyilván kell egy kis kézi scriptelés, de az gondolom már menni fog.

A radattr egy file-ba (/var/run/radattr.pppx, ahol pppx az aktualis ppp interfesz neve, pl. ppp0) teszi le a megkapott RADIUS attributumokat. Ha az en radattr pluginomat hasznalod (ftp://ftp.kite.hu/muszi/sources/radattr.c), akkor annak meg lehet mondani, hogy egy garantaltan egyedi nevu file-ba tegye le (mkstemp(3)-pel hozza letre), mert kulonben elofordulhat, hogy az egyik pppd letorli a masik altal letrehozott file-t. A file nevet egy RADATTR_FILE nevu environment valtozoban kapod meg, es az /etc/ip-up szkriptben felhasznalhatod. Jo fel eve mukodik hibatlanul egy kis ISP-nel (~170 user).

Felhasznalas: a pppd konfigjaba kell egy:

plugin radattr.so
radattr-unique-filenames

(a radattr persze nem megy a radius plugin nelkul, az utan kell szerepeljen a konfigban).

Szivi. A shaping ugy keszul, hogy az ip-up szkript megkapja a RADIUS-tol a juzer {down,up}load sebesseget (erdemes sajat attributumot letrehozni a RADIUS-ban), es ez alapjan konfiguralja be az adott interfeszt (lefele tbf, felfele ingress police). Azert jo, mert amikor eltunik az interfesz, akkor magatol eltunteti a sebessegkorlatozasokat is.

Nalam igy nez ki az /etc/freeradius/users-ben egy user: 

"username"	Auth-Type := Local, User-Password == "password", Service-Type == Framed-User, Framed-Protocol == PPP
		Max-Download-Speed = 256, Max-Upload-Speed = 64,
		Fall-Through = Yes

A kovetkezoket pedig bele kell tenni a RADIUS serveren az /etc/freeradius/dictionary-ba, meg a PPPoE serveren az /etc/radiusclient/dictionary-ba (nem art, ha tudja, hogy mi az a 192-es attributum :-) 

ATTRIBUTE	Max-Download-Speed	192	integer
ATTRIBUTE	Max-Upload-Speed	193	integer

Azert 192 es 193, mert az RFC2138 szerint 192-223 reserved for experimental use, 224-240 reserved for implementation-specific use, 241-255 reserved and should not be used. A freeradius leirasa szerint csak az 1000 alattiakat teszi bele a valaszcsomagba, de ugy emlekszem, nekem 500-zal sem ment.

Koszonom, persze, hogy kihagytam a sok dictionary kozul az egyiket (ez egy Gentoo, ahol van egy par)

/etc/radiusclient/dictionary
/etc/ppp/radius/dictionary
/usr/share/freeradius/dictionary

Szuper most mar visszakapom az erteket, bekerul a radattr fileba is. Innentol akkor shaping... hm.

( adamx | 2007. 02. 01., cs – 23:46 )

Ha sok felhasználót akarsz így kiszolgálni, akkor nem biztos, hogy a HTB a legjobb. Nem ismerem a számokat (és nem is vagyok igazán a téma szakértője), de néhány nagyságrend felett én már sokkal inkább mondjuk egy sima TBF -t használnék.

http://lartc.org/howto/lartc.qdisc.classless.html

TBF is very precise, network- and processor friendly. It should be your first choice if you simply want to slow an interface down!

Ha szeretnéd, hogy a min és max közötti sávszélesség jól / igazságosan legyen elosztva, akkor szerintem ezeket az egyéni max-ra korlátozások után még beköthetsz valami "okosabb" dolgot, mondjuk a te általad említett HTB-t, de itt már sokkal kevesebb class is elég lesz.

A lényeg az, gondold meg mielőtt _sok_ HTB class-t csinálsz. Sajnos nem tudom mennyi a sok, de ezt szerintem te el tudod dönteni.

A megvalósítással kapcsolatban pedig az jutott eszembe, hogy még arra vigyázz, hogy ha cron-ból generálod is a shaping táblát, akkor se húzd újra teljesen percenként, mert ha egy class-t törölsz és újra visszaraksz, akkor
1, egy kis ideig nincs megfelelő szabályozás
2, törlöd a class-okban található adatokat is (pl. htb-nél maradva mennyi "sávszélesség" van kölcsön az adott class-nál), ez minden alkalommal nemkívánatos ingadozásokat okozhat

Szerintem .. bár nem tudom pontosan hogyan lehetne csinálni, egy valamilyen hook kellene a connect / disconnect eseményekhez, és pontosan akkor kerüljön be a szabályzó táblába egy sebesség-fogó szabály, amikor arra szükség van, és amikor már nincs, akkor törlődjön.

Ebben az esetben nem kell az automatikus frissítésekből eredő ingadozásoktól tartani, viszont arra figyelni kell, hogy ne maradjanak a táblában elhagyott szabály-sorok (ha valamiért nem futna le a disconnect esemény kezelője), mert ezek felszaporodása könnyen megölheti az egész szabály-rendszert.

Ha tényleg sok szabály van, akkor esetleg megpróbálhatod az iptables "limit" nevű választóját. Ezt chain-ekkel valamilyen fába szervezve egész jó, kb. logaritmikus skálázhatóságot kaphatsz.

Ennyi jutott most eszembe. Még egyszer mondom, nem vagyok a téma szakértője, ezek csak ötletek / érzések. De azért remélem hasznosnak találod.

Koszi a reszletes valaszt, sok erdekes kerdest vetettel fel. A cronos mokat el szeretnem vetni, mert tobb gond is van vele, te is irtal parat. Nagysagrend kb. 150 account, egyidejuleg talan a fele -- bar ez csak hasrautes, nincs mogotte komoly marketingkutas. :) A TBF-et megnezem, koszi. Ez a hook-os modszer lenne a legkezenfekvobb, talan gyu tud bovebb infoval szolgalni. :)

( elod v | 2007. 02. 02., p – 13:08 )

Hasonlot csinaltam HTB-vel, sok class-nel valoszinuleg docog.

En az aszinkron modot valasztottam. Beteszi az adatbazisba, egy flag-et 1-re tesz.
Python script percenkent lefut, megnezi, hogy melyik flagek vannak 1-en (hozzaadas, torles, modositas)
es elvegzi a piszkos munkat a HTB-vel. Mukodott kerek egy evig egy kb 500-as felhasznalotaboron, most valtottak le, nem tudom, hogy jobb e az uj. Egy masik ugyfelnel meg mindig ez mukodik.

Nalad annyival komplikaltabb a mese, hogy egy log file-t kell parse-olni, amibol kiszeded oket, es sokkal jobb volna, ha szinkron menne az egesz. Egy script ami allandoan fut, es a log file-t figyeli, es kuldi a message-eket pl. egy pipe-on keresztul egy masik processznek, ami elvegzi a munkat (kiolvassa az adatbazisbol, es belovi a htb-be, vagy akarmibe). Sokkal elegansabb megoldas, ha az elso reszt SNMP Trap-ekkel oldod meg, de akkor is kell egy program.

Programozasi keszseg kell hozza, es kb egy het munka, debugolassal, dokumentalassal, tervezessel. A lenyeg, hogy HTB-bol lehet menet kozben torolni, hozzaadni, modositani, tehat egyaltalan nem elegans cron-bol 5 percenkent mindent lenullazni es megvarni mig magahoz ter.

Most ott all a dolog, hogy Muszi es adamx javaslatara tbf-fel megfogtam a letoltest, ingress-el a feltoltest. Ezzel meg tudtam adni maximum fel/letoltesi sebesseget, es mukodik is. De garantalt minimumot nem. Erre pedig htb kepes. Nincs savszelessegkolcsonzes sem tbf-fel. 170 felhasznalo kb. de egyidejuleg ennyi talan sosem lesz.

tbf es ingress megy ip-up fajlbol mindig az adott iface-re, s gondoltam jo lenne egy global az eth0-ra (amin az atjaro kapja a netet) prioritassal, htb-vel stb. Na most az van, hogy komolyabb teszt kornyezet kellene, mert jelenleg van a pppoe server es egy xp vmwareben, de meg vagy tiz kliens elkelne tesztelni.

Ha valamit elbaxok vagy nem jol gondolok, szoljatok. :)

( LiRul v | 2007. 02. 28., sze – 21:43 )

No kicsit eltuntem, csinalom csak most par hetig nem volt ra kapcitas. Jelenleg itt tartok:

pppX interface-eken ingress/tbf-fel bekorlatozom maximalis savszelesseget (le/fel).

A globalis eth0 iface-n (ezen kapja a publikus netet a gep) felallitottam 7 classidt kulonbozo proioritasokkal, s ebbe flowid szerint (netfilter jelolessel) bekerulnek a csomagok, pl. icmp, dns, ssh magas prioritas, smtp alacsony stb.

Ez mind szep es jo, mukodik is. Viszont a helyzet nem ilyen egyszeru. A link (amit kapunk az ISP-tol) rettento mertekben ingadozik (elvileg 10 mbit, neha a meg otode sem, pl. ha jon egy szelvihar). Ezert csak a tbf-re nem hagyatkozhatok, mert ha jon negy user, akik tbf szerintm 512k-t kapnak max., akkor ez a 4 user azonnal kihasznalta csutkara a 2 mbitet, a tobbinek gyakorlatilag nem jut semmi. tbf sajnos nem tud borrowing-et es garantalt minimumot sem -- nyilvan nem is ezert hoztak letre.

Szoval ott vagyok bajban, hogy hogy hozzam ossze a generikus prioritizalo szabalyokat a per user savszelessegkorlatozassal. Irtatok fentebb, hogy nem jo a tul sok szabaly, es en is igy gondolom. A savszelessegmegosztas/kolcsonzes csak azonos iface-n megy, pppX-ek egymas kozt nem tudnak, igaz?

Minden otletet szivesen fogadok, szoljatok, ha valami nem vilagos, lehet h en gondolom rosszul. Thx.

Az inga nagyon nem jó, mert sosem tudod hányadán állsz. Mérni sem tudod.

A másik gondodra (több interfész kölcsönzés) az imq (intermediate queue) a megoldás, de meg kell patchelni a kernelt, és iptables-t is kell fordítani. Egyelőre ez a megoldás, volt/van valami más kezdeményezés is, de fogalmam nincs hogy áll.