ipfw + nat + dummynet (+ bridge)

[Petr Bezděk]

Zbyněk Burget wrote:
> Zdravim vespolek,
> 
> precetl jsem si o dane problematice, co jsem nasel (many, handbook a
> prislusne state v obou knihach, ktere u nas vysly), nicmene mam stale
> nekolik nejasnosti... Nejde mi o to, mit to jen nastavene tak, aby to nejak
> fungovalo (co je soucasny stav), ale taky bych rad vedel, jak to vlastne
> funguje. Pokud jsou me otazky popsano jeste nekde jinde, staci mi odkaz.

Nikdo neodpovida, tak ja zkusim odpovedet, i kdyz podotykam, ze co 
napisi tak nejak vylpynulo z mych pozorovani s ipfw a dummynet.

> V ipfw(8) jsem se docetl, ze po pruchodu paketu pres pravidlo dummynet se
> paket vraci do firewallu, pokud neni nastaveny jednopruchodovy ipfw. Jak je
> to v pripade pravidla divert natd ... ? Taky by se pri jednopruchodovem ipfw
> uz nevratil?

Po aplikaci pravidla divert se paket vzdycky vrati a pokracuje se na 
dalsim pravidle za divet bez ohledu na nastaveni net.inet.ip.fw.one_pass

> Pokud nemam jednopruchodove ipfw a povolim prichozimu paketu pruchod pres
> ipfw (pravidlo allow), kam ten paket potom jde? Uz rovnou na odchozi adapter
> (tedy skrz prislusne komunikacni vrstvy) nebo je jeste nejaka sance
> (nebezbeci) ze se do ipfw vrati?

Jeslize je nastaveno net.inet.ip.fw.one_pass=0, tak paket prochazi FW 
jednou pri vstupu z prichoziho media a podruhe pri vystupu do odchoziho 
media. Takze jestlize projde pres allow/deny pravidlo na vstupnim 
rozhrani, zpracovava se jeste jednou pri vystupu na vystupnim rozhrani.

V tomto si nejsem uplne jisty. Jestlize je neastaveno 
net.inet.ip.fw.one_pass=1, tak to prochazi jen jednou, jen pri prichodu 
paketu ze vstupniho media. Opravdu si nejsem jisty a musel bych to 
vyzkouset.

> K cemu jsou dobra pravidla zpracovavajici pakety v layer 2? Jde s nimi
> udelat vsechno to, co s normalnimi pravidly nebo jsou tam nejaka omezeni? To
> jsem z zadneho textu oprvadu nepochopil. Asi by pruchod takoveho paketu
> firewallem mel byt rychlejsi (jak potom funguje nat a dummynet).

Nevim, nikdy jsem nepouzil.

> K cemu je bridge(4)? Urychleni pruchodu paketu routerem? Paket se v tomhle
> pripade nijak nezmeni? Paket se nejak zmeni, pokud bridge neni aktivovany?
> Jsou v pripade pouziti bridge nejake omezene moznosti ipfw (resp. dummynetu
> a natu)?

Nevim, nikdy jsem nepouzil.

> Jak dalece je pouzitelny dummynet pro nastaveni spravedlnosti pri rozdeleni
> pasma pri prichozi traffic? Pokud budu mit napr. linku 256 a budu ji delit
> mezi 4 stroje tak, ze bude mit kazdy 64, nastavim 4 pipe po 64 - no problem.
> Ale - pokud budu chtit, aby ty stroje sdilely 256 tak, aby se delily rovnym
> dilem. Rekneme ze budou mit stejne podminky - ctyri stroje v podsiti pred
> routerem A, B, C, D a ctyri stroje v podsiti za routerem W, X, Y, Z. Stroj A
> taha z W, B z X, C z Y, D ze Z obe podsite jsou propojeny linkou, ktera ma
> fyzicky 256. I kdyz nastavim pipe 256 se 4 queue s vahami po 25 %, zacne
> tahat prvni stroj, obsadi celou sirku linky, pak zacnou tahat ostatni tri
> stroje, rozdeli dummynet pasmo spravedlive? Myslim si ze ne. Protoze pres tu
> fyzickou linku proste vic neproleze a dummynet nebude mit duvod zahazovat
> pakety. Jak by se to dalo resit? Umyslne nahodne zahazovat nejakou cast
> trafficu? Jestli je tohle cesta, kolik procent trafficu je potreba zahodit?
> Co se stane, kdybych nadefinoval 4 pipe po 256? Pripada mi to jako nesmysl,
> ale reseni nekterych problemu ne vzdy vypadaji logicky.
> Bude trafic shaping obecne fungovat v pripade fyzicke linky 512 a dvou pipe
> 256? Porad se bavim o prichozim trafficu - predpokladam ze shaping pro
> odchozi traffic je bez problemu...

Klasifikace prichoziho provozu funguje, jen kdyz je pipe_bw < sirka 
pasma linky. Tak nejak mam odzkouseno, ze ten rozdil musi byt aspon 10%, 
aby se nejake omezeni projevilo. Takze kdyz mate 256kps linku, tak bw u 
pipe nastavit priblizne na 225kbps a melo by rozdelovani byt poznat. Cim 
vetsi je rozdil, tim je vysledek lepsi. Pri sirce pasma jakou mate 
musite zvolit kompromis mezi ucinnosti dummynetu a rychlosti prichoziho 
traffiku.

-- 
Petr Bezděk