HTB shaping v oboch smeroch

[Rybarik, Michal]

hello,

> > > ip filter add blabla u32 match ip src vnutorna_siet/mask 
> flowid 1:9
> > nie je mi to celkom jasne, ale asi vies co hovoris, mohol 
> by si to pls trochu
> > rozviest?
> Jednoducho traffic zo source adresami nepatriacimi internetu 
> ale lokalu
> presmerujes na klasu, ktoru nebudes shapovat (resp. budes 
> shapovat inac).

... uz vidim ze toto neushapeuje ani boh. mudro hovoris, ale tie
inet linky su tam dve, shapeovana ma byt len jedna. ked budem shapeovat
na vnutornom interface podla toho ci je to z internetu, oshapujem si obe
naraz. musel by som na vonkajsom, ale tam neoshapeujem downstream, lebo
afaik budem shapovat este kym maju pakety verejnu adresu a nemozem ich 
odlisit. jedine ze by som to shapeoval na vnutornych if, a markom by som
odlisil markom internetovy interface z ktoreho to prislo. ale este vcera
mi pri pokusoch trklo, ze medzi viacerymi vnutornymi interfejsmi si asi 
_dost_ tazko budem moct poziciavat pasmo, takze aj toto zda sa neriesi cely
problem.

btw stravil som na tom cez vikend hodnu chvilu, podarilo sa mi cez htb
oshapovat ingress, htb.init to sice nepodporuje, ale tc ano. :o) keby to
niekoho zaujimalo, treba vytvorit qdisc ingress a ten oshapovat. google 
pomoze "htb qdisc ingress" a po prvych troch odkazoch clovek vie ako na to.
vyzera to byt vcelku undocumented, aj devik sa o tom zmienuje len na par 
riadkoch. da sa to pouzit akurat na shaping, na nic ine, prehadzovat pakety 
s tym velmi nema zmysel. a ak stroj forwarduje, je odporucane shapeovat na
vnutornom rozhrani, a toto pouivat iba na input.

> routovanie nemusis robit cez fwmark, mozes aj cez source 
> adresu. Tym si
> odstranis jednu vrstvu markovania a markovanie mozes pouzit 
> na shaping.

tusil som ze si to niekto vsimne. ale nechcel som zahumusovat konferu celou
situaciou, lebo by to bolo tak dlhe ze by to do noveho roka nikto nedocital.

userov vo vnutornej sieti je teraz malo (jednotky), predpokladany narast je
na dost vela (stovky). aby mal router co najmenej roboty s rozhodovanim, nemam
source routu pre kazdeho zvlast, ale cez divoku masku. useri su cislovani
v tvare 10.x.y.z, pricom X je cislo subnetu a meni sa podla interface, Y je
cislo defaultrouty (podla neho sa markuju pakety), Z je cislo stroja. maska
na markovanie je potom 255.0.7.0, jednicky v nej nie su spojite. (ked chcem
userovi zmenit defaultroute, dam mu na C poziciu v IP adrese ine cislo. na 
routeri je na forwarde kontrolovana vazba MAC-IP, takze sam sa user neprerobi,
musel by udrbat cudziu IPcku aj s MAC adresou.) konkretne markovanie potom vyzera
tak (opat trochu zjednodusim), ze 10.0.1.0/255.0.7.0 davaj do routing table 10, 
10.0.2.0./255.0.7.0 do routing table 20, 10.0.3.0./255.0.7.0 do routing table 30. 
no, a s takouto nespojitou maskou je ochotny robit akurat iptables, tc aj ip chcu 
masku len v pocte jedniciek (a.b.c.d/N), tam takuto masku nenravem. preto markujem. 
mozem robit aj podla konkretnej suorce IP, ale hrozim sa toho ze by mal paket 
zakazdym preliezat stovky pravidiel, ked to ide s ovela mensim poctom, ktory btw
vobec nezavisi od poctu userov, takze cely routing je _ovela_ prehladnejsi, len
si treba zvyknut na tu divoku masku a vediet co ktora znamena (mam ich takychto
divokych viac, vravel som ze opat zjednodusujem :o)).

> > inde, kvoli ostatnym divokostiam v routovani.
> Ako som povedal, "odklon" lokalny traffic do ineho classu.

zatial som vzdy uvazoval len nad shapeovanim jedneho z internetov, zacat rozmyslat
o tom ako shapeovat ine smery (hoc na 100 megabit) je celkom dobry napad. dakujem
za vnuknutie :o)

> > ako sa da poriesit ingress shaping, inak nez cez IMQ? 
> Hmm neviem :-)

ako som si uz odpovedal, HTB qdisc ingress. pod svieckou najvacsia tma. qdisc 
ingress z principu nie je vhodny na triedenie a prioritizaciu, ale na shaping 
postacuje a chodi ok.

> Pokial mas "typov rychlosti" len malo, mozes skusit wrr, ten 
> vie shapovat
> podla MAC-adresy, cim ojebabres NAT, a markom (alebo cez ip 
> rule) mozes urcit,
> kam (route+shapovacia klasa) kto pojde.

uz som ho napchal do googla a idem studovat, thanx.

ale cim viac nad tym dumem, tym viac mam dojem ze chcem dost narocnu vec, 
takpovediac mission impossible. dost pravdepodobne budem kvoli stabilite menit 
DSL modem (USB) za DSL router (ethernetovy), takze by som nechal NATko robit 
router, a na linuxe budem mat taky cas aj na internetovom rozhrani vzdy vnutorne 
IPcky, a mozem shapeovat bez nutnosti premarkuvavat (a co je zrejme, s NATkom 
na linuxe neodlisim pri prichodzich paketoch vnutornych userov ani nahodou, lebo 
na vnutorne ip-cky sa prenatuju az po shapingu).

problem ktory som si uvedomil vcera je ten, ze medzi vnutornymi ifaces sa nebude
dat poziciavat pasmo (afaik HTB sa vzdy vztahuje ku jednemu interface). takze bud 
budem shapovat LEN na vonkajsom if (co vidim realne, ak by som NATko presunul mimo
tento router), alebo druha moznost, hodim tam dalsiu krabicu ktora bude jednym
interfacom zavesena za terajsi router, a do nej pojdu aj obe LANky. tak budem moct 
vsetkych userov shapeovat na jednom rozhrani, nie na viacerych. novy box by len 
rozhadzoval pakety do prislusnych LANiek.

p