Dotaz: Nefukcni sharping po prechodu Debian Sagne na Etch.

[Jan Matuska]

Zdravim, provedli jsme s kolegou presun firewallu (NAT apod.) ze stareho stroje (Debian Sagre, 2.4.x) na nove zelezo s Debianem Etch (2.6.x). Temer vsechny sluzby pracuji tak jak maji, krome sharpingu, ktery se chova naprosto nepredvidatelne. Podotykam, ze na puvodnim stroji pracoval sharping zcela bezchybne. Vsechno je na Etchi stejne, jako bylo na Sarge. Predpokladam, ze vliv sitovych karet zde neni, to uz by bylo hodne divne. (100M vs 1G).

Pravidla mame tvorene velmi primitivne. V podstate pouze a jenom nastavuji uzivatelum strom, k zadnym vypujckam nevyuziteho pasma nedochazi. Sit mame postavenou na lokalnich IP 192.168.0.0/16. Nize uvedeny kod trochu zjednodusuji.

#-----------------------
WIFIIF="eth1"
INETIF="eth0"
#-----------------------

# Vytvoreni stromu pro Wifinu
tc qdisc del dev $WIFIIF root
tc qdisc add dev $WIFIIF root handle 1:0 htb default 999

# Vytvoreni stromu pro vystup na Internet
tc qdisc del dev $INETIF root
tc qdisc add dev $INETIF root handle 1:0 htb default 999


# UPLOAD: uzivatel
tc class add dev $INETIF parent 1:0 classid 1:1533 htb rate 512kbit
tc qdisc add dev $INETIF parent 1:1533 handle 11533:0 sfq perturb 5
iptables -t mangle -A FORWARD -o $INETIF -p ! icmp -s 192.168.10.2 -d ! 192.168.0.0/16 -j MARK --set-mark 2533
tc filter add dev $INETIF parent 1:0 protocol ip handle 2533 fw flowid 1:1533

# DOWNLOAD: uzivatel
tc class add dev $WIFIIF parent 1:0 classid 1:1533 htb rate 512kbit
tc qdisc add dev $WIFIIF parent 1:1533 handle 11533:0 sfq perturb 5
iptables -t mangle -A POSTROUTING -p ! icmp -d 192.168.10.2 -s ! 192.168.0.0/16 -j MARK --set-mark 1533
iptables -t mangle -A OUTPUT -p tcp -d 192.168.10.2 --sport 3128 -j MARK --set-mark 1533
tc filter add dev $WIFIIF parent 1:0 protocol ip handle 1533 fw flowid 1:1533

Projevy jsou asi takove, ze pokud nastavim uzivateli rychlost napr. 512kbit, jede trebas 300-400kBytes, pokud nastavim 100kbit, uzivatel jede tak 50-80kB. Jsou to radove rozdily hrube neodpovidajici ani naznakem nastavene rychlosti. Je zde ale videt, ze sharping pracuje, ale otazkou je, proc tak divne a kde hledat chybu, kdyz to na predchozi masine pracovalo idealne. Nema jadro 2.6.x nejake jine vlastnosti co se tc a htb tyce?

Odpovědi

[Jan Matuska]

Popletl jsem nazvy, samozrejme to ma byt Debian Sarge

[vrx]

A nebude chyba v tom ako máte nastavené triedy a markovanie?
Čo som si všimol tak trieda pre upload aj download je rovnaká (1533), ale forward markujete inač ako postrouting (forward má mark 2533)
Nemôže byť to "divné správanie" nakoniec správne vykonané vašou chybou?
Inač to vyzeerá byť v ceku dobré..

[vrx]

pardon už som si to všimol lepšie ja som to najskôr zle pochopil, ešte raz sa ospravedlňujem za zmätky :)

[Jan Matuska]

Tak jsem zjistil, tuto zavislost:

debianetch:/etc/firewall# tc -s -d class show dev eth1
class htb 1:1533 root prio 0 quantum 2500 rate 200000bit ceil 200000bit burst 1699b/8 mpu 0b overhead 0b cburst 1699b/8 mpu 0b overhead 0b level 0
 Sent 22724107 bytes 1895 pkt (dropped 0, overlimits 0 requeues 0)
 rate 1234Kbit 12pps backlog 0b 5p requeues 0
 lended: 1890 borrowed: 0 giants: 3412
 tokens: -82128 ctokens: -82128

Vyse je uvedeny vypis tridy v prubehu prenosu pres FTP. V dany moment bylo skutecne preneseno cca 22MB dat, ovsem realna rychlost 1234kbit. Rate je vsak nastaveno na 200kbit.

Ten novy stroj je quadcore, cili spis zaciname doufat, ze to mozna muze byt i tim. Tedy i kdyz je to hodne divne. Ale u mnoha testu jsem docilil zvyseni realne rychlosti 4-6x oproti puvodni nastavene hodnote.

[anyd]

opravim vas, ale nazyva se to "traffic shaping" (ne sharping). co sem mel do docineni s htb tak sem mel stejny problem (nehlede na to, ze to dost vytezovalo pocitac) a resenim bylo zrusit shaping a zavest denni rezimy blokovani portu. (pres den blokovani vsech portu krome zakladnich sluzeb a pres noc povoleny vsechny p2p porty). Kupodivu to pro sit(4MB/4MB) a vsechy uzivatele(120 pocitacu v siti) fungovalo dobre a lide jsou spokojeni. Vim, ze to neresi vas problem a sem uplne offtopic, ale mozna zkuste zvazit tuto variantu ;o)

[Jan Matuska]

Dekuji za opravu, tam tech chybek bylo vice Vite, ono ani tak nejde o PTP, ale obecne o cely provoz. Sit mame cca 2x vetsi jako vase, na puvodni masine HTB stihalo uplne bezproblemove - vytizeni radove jednotky procent. Duvod vymeny byl v podstate ten, ze puvodni stroj bylo obycejne PC, 3 roky v 24x7 provozu. Cili nikdo nedokazal odhadnout, co by se mohlo stat. Vsechny sluzby nyni jedou vyrazne svizneji, je vyreseno zalohovani, proste vsechno je nyni zn. ideal - az na HTB. Omezovani portu neni IMHO moc vhodny zpusob. Mame tu koumaky, kteri jsou schopni protlacit pres "povolene" porty nejake ISO a ono to vypada, jako stahovani posty pres POP3

[anyd]

jasny plne chapu vasi situaci ;o) ja sem mel ulehcenou situaci, ze 90% uzivatelu te site byly holky co pouzivaly jen web + icq a zbytek sem si dokazal ohlidat vystraznyma odpojeni od internetu na urcitou dobu a pote pochopili, ze porno se da stahovat i v noci kdyz to nikomu nevadi ;o)

zajimave je, ze opet zapracovalo stare *nixove pravidlo - kdyz to funguje tak do toho nehrabej. tedka uz nemam tolik casu se tomu venovat takze se budu tohoto pravidla drzet a vam preju at ten problem s htb vyresite a podelite se s nami o reseni

[pavlix]

No... :D takže koukám, že traffic elektronický taffic shaping nefungoval... tak jsi musel používat vydírání a fyzický shaping :D.

[pavlix]

To byli asi velmi nenároční uživatelé, když Internet používali kromě několika služeb jenom v noci, navíc jim nevadilo, že to jede systémem best effort (=kdo se víc tlačí)... a ani přes den nezatěžovali linku stahováním na běžných portech a nebo jim nevadilo, že to někdy běhá jak šnek.

Asi velmi specifická síť.

[anyd]

jak sem psal 90% holky a zbytek kluci co hledali zpusoby jak vyuzit tu linku vic. ti rozumejsi prisli za mnou, ze chtej povolit port XY s duvodem, ze chtej hrat hry po netu/nejaka sluzba/cokoliv ti hloupejsi zkouseli cestu sobeckosti stylem "linka je moje!!!" a ti potom byli par dni bez netu.

pokud si vydelis 4MB linku 120 lidmi tak aby to bylo uplne spravedlive a kazdemu garantovat kousek pasma aby si mohl rychlosti sotva par kilo stahovat 24/7/365 porno z dc++ nebo garantovat to, ze pres den omezeny rezim, ktery se nedotkne 99% lidi a ze od 1 v noci do 7 rano jim v tom nebudu branit.

s timto opatrenim byla linka pres den vyuzita ze 60-80% s tim, ze kazdy mel garantovano, ze se dostane na net (kupodivu to predtim nebylo az tak normalni - holt par lidi si nevypinalo dc++) a v noci ocekavanych 100%. pozdeji sem na routeru stahoval z wish listu uzivatelu i pres den.

ano, velmi specificka sit ... pokud mate zajem o dalsi informace jak to funguje rad se s vami podelim ;o)

[pavlix]

Kupodivu :) :D.

No... vzhledem k tomu, že v tom není žádné zajímavé technické opatření, tak nevím. Ty porty pořád vidím jako dost nesmyslné (i přes http můžu stahovat přes mnoho spojení apod), to odpojování od netu samozřejmě funguje, že :).

[Jan Matuska]

Takze kolega problem vyresil a jeho postup je nasledujici:

HTB rizeni datoveho toku a jeho podivne chovani na vicejadrovych CPU (Pavel Dobry)

Problem sitove komunikace mezi vice sitovymi kartami na MultiCore CPU systemech je zpusoben presunovanim dat mezi jednotliva CPU v prubehu datovych prenosu, kdy diky tomu dochazi k velkemu poctu preposilani TCP paketu. Tento problem resi presunuti rizeni hw preruseni sitovych karet pod jedno CPU, nejlepe to prvni, ktere ridi i ostatni hw preruseni.

Je nutne vyradit z cinnosti IRQ balancing. IRQ balancing rozklada zatez HW preruseni pro zvyseni vykonu systemu pomoci presunu systemovych IRQ mezi jednotliva CPU. Kontrolu provadi po urcitem case a dynamicky takto nastavuje smp_affinity u IRQ. To je duvod, proc se rucni nastaveni smp_affinity po case zmeni.

Jsou tri moznosti jak irq_balancing vyradit a to:

1.) Zkompilovat jadro s vypnutym timto nastavenim:

 
Processor type and features ->
          [ ] Enable kernel irq balancing (2.6.x kernels)
Kernel hacking ->
          [ ] Kernel debugging

2.) Pokud nechcete kompilovat jadro a je jadro od dodavatele distribuce kompilovano s irq_balance povolenym, je nutne pri startu systemu nastavit kernelu parametr NOIRQBALACE. Napr. v pripade GRUB bootloaderu na Debian Etch:

title           Debian GNU/Linux, kernel 2.6.18-6-686 - hd0
root            (hd0,0)
kernel         /vmlinuz-2.6.18-6-686 root=/dev/md1 ro noirqbalance
initrd          /initrd.img-2.6.18-6-686
savedefault

3.) Nektere distribuce pouzivaji irqbalance deamon, ktery kazdych 10 sekund meni nastaveni prideleni hw preruseni mezi jednotliva CPU dle jejich vytizeni. Je nutne ho bud odinstalovat, nebo zakazat jeho spousteni napr. u RHEL

chkconfig --level 2345 irqbalance off

Dalsim krokem je nastaveni smp_affinity (prideleni urciteho CPU) pro IRQ, ktera obsluhuji sitove karty.

Vylistujeme si konkretni cisla IRQ pres: cat /proc/interrupts

           CPU0       CPU1       CPU2       CPU3
  0:   57382568          0          0          0    IO-APIC-edge  timer
  1:      11306          0          0          0    IO-APIC-edge  i8042
  9:          0          0          0          0   IO-APIC-level  acpi
 12:      37661          0          0          0    IO-APIC-edge  i8042
169:   34020827   35662622   30391040   35111186   IO-APIC-level  uhci_hcd:usb1, ehci_hcd:usb3, eth2
177:    7418529    7550686    4920178    9752439   IO-APIC-level  uhci_hcd:usb2, eth3
185:   15086267   14261889   14179602    4938130   IO-APIC-level  eth0
193:   25489867   18938703   15520529   10852850   IO-APIC-level  libata, eth1
NMI:          0          0          0          0
LOC:   56775697   56775659   56791204   56791230
ERR:          0
MIS:          0

Z tohoto vypisu zjistime, ze IRQ 169, 177, 185 a 193 obsluhuji nase ctyri sitove karty. Pak uz staci zadat na konzoli prikazy:

echo 1 > /proc/irq/169/smp_affinity
echo 1 > /proc/irq/177/smp_affinity
echo 1 > /proc/irq/185/smp_affinity
echo 1 > /proc/irq/193/smp_affinity

Timto zajistime obsluhu techto IRQ jen jednim prvnim CPU. Aby nam toto nastaveni fungovalo i po restartu systemu, je nutne si vytvorit skript s timto nastavenim smp_affinity a tento skript spoustet jako prvni systemovy skript napr. Debian Etch v /etc/rc2.d jako symlink S10set-smp_affinity

File: set-smp_affinity

#!/bin/sh

# by Pavel Dobry
#
# Setup of smp_affinity settings for StarHill server with Intel Quad CPU
#
#
# We need also disabled kernel irqbalance services:
# in GRUB at kernel statement by parametr : noirqbalance

echo 1 > /proc/irq/169/smp_affinity
echo 1 > /proc/irq/177/smp_affinity
echo 1 > /proc/irq/185/smp_affinity
echo 1 > /proc/irq/193/smp_affinity

exit 0