Rozumna prezentace acoutingu.

Ondrej Filip feela na gin.cz
Úterý Únor 5 15:39:31 CET 2002


On Tue, 5 Feb 2002, Dalibor Toman wrote:

> >
> > > mam tomu rozumnet tak, ze vlastni mereni dat neprobiha na centralnim
> > > routeru (routerech) ale na "malych" linux routerech u zakazniku?
> >
> >   Ne, IPEX (GIN) to počítá na poslední mašine v cestě k zákazníkovi, která je
> > pod jeho správou. Každopádně pod pojmem router si můžete představit jakoukoli
> > mašinu.
> >
> > > To mi neprijde jako stastne reseni (pri velkem mnozstvi
> > > takovych routeru to musi byt pekna smrst dotazu/odpovedi kazdych
> > > 5 minut).
> >
> >   Jaké s tím máte zkušenosti, že Vám to nepřijde jako šťastné řešení? Už jste
> > někdy něco takového dělal?
> 
> delal. Nase reseni je takove, ze pred Access pointem je Linux router,
> ktery routuje toky na jednotlive LRP u zakazniku (ale nekteri windowsari
> jsou pripojeni i primo) Ten hlavni Linux router pred AP meri i tok.

Casto maji Ti lide jeste backup a pak je vyhodnejsi merit primo u nich. 
Navic je pak mozna, ze lide sosaji i mezi sebou.

> Pokud nemate nejakou gateway u AP, pak Vam lokalni toky klientu z
> jednoho AP chodi po napajeckach tam a zpatky - my se snazime tyhle
> bludny toky omezit. Proto je snadne merit "centralne" pro dany AP

Jake toky mate namysli? Nejak nerozumim.

> >Už jste viděl mašinu, která chuděrka routuje toky
> > v řádech desítky Mbitů a vy ji chcete "zahltit" pravidlama na počítání?
> 
> Nevim jak Vy, ale my neumime protlacit 11Mbps radiem vic nez nekolik
> Mbps

11Mbps radiem, to asi mysli DSSS ve 2.4G, coz? Ale to ani teoreticky 
nemuze protlacit 11Mbps dat! Ta 11 neni propustnost!

Nicmene kdo rika, ze nejrychlejsi radio je prave tohle?

> Podle mych zkusenosti chytre navrzene mereni (ipchains) neni na zatezi
> CPU znat.
> Samozrejme desitky mbps nam tim netecou...

Podle mych zkusenosti je ipchains znat. Rozhodne neni rozumne s pravidly 
prilis plytvat. Mame masiny, kde toky dosahuji rychlosti PCI sbernice!

> >Asi
> > ne, jinak by jste tak nemluvil. Ještě jste zapomněl ve vaší teorii
> na shapery,
> > atp. zákazník by Vás asi hnal.
> 
> nezapomnel, shapery (az na par vyjimek) nepouzivame. Proc taky -
> pocitana
> data jsou od toho aby jich co nejvic za co nejkratsi dobu klient
> nasosal, ne?

OK, tomu rozumim. My jdeme jinou cestou a garantujeme rychlosti.

> >   Proč smršť? Stejně jako velikost daných programů je minimální, i
> nároky na
> > přenos jsou minimální a je úplně jedno jestli to táhám z 10, 50,
> 100,
> > ... routerů či jednoho a to nemluvím o tom, když by se s ním něco
> stalo.
> >   Pokud to porovnám s kapacitou páteří, je to naprosto zanedbatelná
> položka.
> 
> jedna vec je kapacita pateri, druha kapacita vlastniho AP

? Proste toky z accountingu jsou zanedbatelne. Pokud nestaci nejake AP, 
prida se dalsi. :-)

> > > A Pri prodlouzeni casu zase hrozi nebezpeci, ze nejaci
> > > vykukove budou bootovat svuj router aby smazali data...
> >
> >   Nevidím důvod to prodlužovat a nemám pocit, že by nějaký vykuk mohl smazat
> > data. Jinak je tam další kontrola, která zjišťuje, jestli data od
> nějaké linky
> > jsou všechny, atd. atd.
> >   Ještě nějaký Sci-fi příběh máte? :)
> 
> ja nechtel to reseni zatracovat, zajimaly me spis Vase argumenty proc
> jste to udelali
> takhle.
> 
> PS: premyslel nekdo na bezdratech o pouziti PPPoE ci nejake podobne
> tunelovaci technologie umoznujici authentifikaci uzivatele? (enkrypci
> dat,...) Cas od casu se vyskytne nekdo, kdo tvrdi, ze nami namerena data
> neprososal (vetsinou se prokaze, ze nejakej ten Morfeus/KazAA a spol u
> nej bezel, ale kdyz se to vezme do dusledku, tak moc dukazu nekdy clovek
> podat nemuze)

Arpwatch?

> 
> D. Toman
> 

			Ondrej Filip

-- 
 (  IPEX s.r.o.  /  GIN internet communications  )
 -------------------------------------------------
  Ondrej Filip                 Technical Director
 
  Office : Siroka 37,  Ceske Budejovice,    37001 
  Tel.   : +420-38-635 75 94    +420-38-635 76 23
  Email  : ondrej.filip na gin.cz  http://www.gin.cz     
 -------------------------------------------------



Další informace o konferenci Linux