zkracene: v soucasnosti se pakety klasifikuji v iptables, markuji se, a podle marku se znovu klasifikuji v tc mechanismu. Cilem je klasifikovat pakety ciste v tc mechanismu, a to za pouziti u32 hashovani http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.adv-filter.hashing.html


zvitezil "plan c.3", vsechno ostatni zde jsou vicemene nevyznamne kecy


Taktez by bylo vhodne podobne zoptimalizovat pristupova iptables pravidla.

Iface - rozhrani na qos stroji, ktere je pripojeno k internetu. Qdiscy povesene na toto rozhrani provadeji shapovani uploadu.

D/L Iface - rozhrani na qos stroji, ktere je pripojeno do vnitrni site, pokud je takovych rozhrani vice, jedna se vetsinou o imq rozhrani, na ktere je presmerovan traffic prichazejici z inetu. Qdiscy na tomto rozhrani shapuji downstream.

Access iface - rozhrani na access stroji, na ktere je pripojen qos stroj. Na toto rozhrani se vesi pristupova iptables pravidla

treti verze testovaci site:

 eth0           eth1        eth0        eth0
192.168.1.2     192.168.1.1 192.168.100.1   192.168.100.2
[[servis_ntb] <-------------> [[defractor] <-------------> [[sunka]
klient           iGWadm         >internet<

Testy: (stazeni 200M souboru pres HTTP, iGWadm = celeron 2.4GHz)

bez iGWadm - zadny qos, rychlost az 40Mbit      CPU: 15 - 30%
bez iGWadm - strop 10Mbit               CPU: <2%
bez iGWadm - strop 20Mbit               CPU: <3%
bez iGWadm - strop 35Mbit               CPU: 4 - 8% //dl rychlost pouze asi 28Mbit
iGWadm - strop 10Mbit, jedno pravidlo           CPU: <2%
iGWadm - strop 10Mbit, 250 pravidel, prvni adresa   CPU: 2 - 4%
iGWadm - strop 10Mbit, 250 pravidel, posledni adresa    CPU: 4 - 7%
iGWadm - strop 20Mbit, 250 pravidel, prvni adresa   CPU: 8 - 14%
iGWadm - strop 20Mbit, 250 pravidel, posledni adresa    CPU: 17 - 25%
iGWadm - strop 10Mbit, 500 pravidel, prvni adresa   CPU: 7 - 12%
iGWadm - strop 10Mbit, 500 pravidel, posledni adresa    CPU: 28 - 30%
iGWadm - strop 20Mbit, 500 pravidel, prvni adresa   CPU: 40 - 50%
iGWadm - strop 20Mbit, 500 pravidel, posledni adresa    CPU: 56 - 61%

Co se deje s paketem:

  • nat/PREROUTING - zjistuje se, zda-li je paket z povolene IP, jinak je presmerovan na dashboard XXX
  • mangle/FORWARD - paket je MARKovan podle sve IP adresy XXX
  • filter/FORWARD - zahozeni smtp paketu, znovu se overuje zda je IP povolena, jinak je poslana ICMP zprava port-unreachable XXX
  • nat/POSTROUTING - provadi se NAT - paketu je prepsana zdrojova adresa
  • TC FILTER - paket se klasifikuje podle marku -> QoS XXX (XXX - prohledava se seznam vsech IP adres, pripadne marku)

Plan na vylepseni:

  • mangle/PREROUTING - zjisteni jestli je ip povolena, pokud ne, MARK x, pokud port 80 tak MARK y
  • nat/PREROUTING - pokud ma paket MARK y, presmerovat na dashboard
  • filter/FORWARD - pokud ma paket MARK x, poslat ICMP port-unreachable
  • mangle/POSTROUTING - paket je poslan na imq zarizeni
  • (imq) TC FILTER - paket je klasifikovan (hash u32) a !QoSovan
  • nat/POSTROUTING - SNAT
  • TC - zajistit, at uz se pakety nijak neQoSuji - pfifo

bude to vyzadovat IMQ pre-nat patch


Plan c.2, bez IMQ:

  • vnitrni sit -> net (upstream)
  • paket je v mangle/POSTROUTING oznacen pomoci IPMARK targetu a v egress qosu je klasifikovan pomoci u32 podle marku - za vyuziti hashovani

  • net -> vnitrni sit (downstream)

  • paket v egress vnitrniho iface(v pripade vice interfacu imq) klasifikovan za pomoci u32 podle cilove ip adresy

vyzaduje:

  • kernel 2.6 s povolenym CLS_U32_MARK (u32 netfilter marks support)
  • iptables(+kernel) patchnute pro target IPMARK (nove iptables ipmark maji, kernel je nutne patchnout)
  • novejsi verzi iproute2, ktera umi u32 netfilter marks

http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/patch-o-matic-ng-20060626.tar.bz2

oops, tak se mnoha iptables pravidlum stejne nevyhnu, jelikoz na nich zavisi pocitani trafficu, grafy, fup ... nicmene takto odpada nutnost pouziti ipmarku, ale zas to budu muset nejak optimalizovat - rozsekat na vice chainu a udelat z nich "strom"


Plan c.3, bez "mnoha" iptables pravidel:

Co je potreba: