Трафик контрол с високоскоростна hash таблица

[Тодор Лазаров]

Този пост в насочен към всички Linux потребители който искат да оптимизират своя shaper.

За целта ще използваме HTB+u32 hash таблица.

Ако имате нужда от хиляди правила, ако имате много клиенти или компютри, всички с различни спецификации, QoS, може да откриете, че ядрото прекарва много време за да отговаря на всички тези правила.

По подразбиране, всички филтри пребивават в една голяма верига, която се съчетава в низходящ ред по приоритет. Ако имате 1000 правила и 1000 проверки могат да бъдат необходими доста време и ресурс за да се определи какво ще се прави с обработката на всеки пакет.

Но ако използваме u32 hash съвпадението ще отиде много по-бързо.

Hashing прави това възможно.

Ето и нашия пример

Имам клиент с адресно пространство: 213.91.178.254/32 и 213.91.179.0/24

на който даваме 100Мбит-а като тази скорост в дели на 80Мбит-а български трафик и 20 Мбит-а международен маркиран с tos 0x20

#Създаване на коренен клас на интерфейс eth1

tc qdisc del dev eth1 root

tc qdisc add dev eth1 root handle 1: htb r2q 2

tc class add dev eth1 parent 1: classid 1:1 htb rate 1000Mbit ceil 1000Mbit burst 2340570b cburst 2340570b prio 0

#Създаване на клиенски клас 1:1002

tc class add dev eth1 parent 1:1 classid 1:1002 htb rate 100Mbit ceil 100Mbit burst 292571b cburst 292571b prio 0

tc qdisc add dev eth1 parent 1:1002 handle 1002: sfq perturb 10

    #Създаване на клас 1:1003 BG трафик, който е дете на клас 1:1002

    tc class add dev eth1 parent 1:1002 classid 1:1003 htb rate 80Mbit ceil 80Mbit burst 234057b cburst 234057b prio 0   

    tc qdisc add dev eth1 parent 1:1003 handle 1003: sfq perturb 10

    #Създаване на клас 1:1004 WORD трафик, който е дете на клас 1:1002

    tc class add dev eth1 parent 1:1002 classid 1:1004 htb rate 10Mbit ceil 10Mbit burst 29257b cburst 29257b prio 0   

    tc qdisc add dev eth1 parent 1:1004 handle 1004: sfq perturb 10

#Създаване на u32 класификатор

tc filter add dev eth1 parent 1:0 prio 5 protocol ip u32

#Създаване на таблица с номер 100 и съдържаща 256 записа в hash-a за 213.91.0.0 с маска /16

tc filter add dev eth1 parent 1:0 prio 1 handle 100: protocol ip u32 divisor 256

tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 ht 800:: match ip dst 213.91.0.0/16 hashkey mask 0x0000ff00 at 16 link 100:

    #Създаване на таблица с номер 201 подчинена на таблица 100 и съдържаща 256 записа в hash-a за 213.91.178.0 с маска /24

    tc filter add dev eth1 parent 1:0 prio 1 handle 201: protocol ip u32 divisor 256   

    tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 ht 100:b2: match ip dst 213.91.178.0/24 hashkey mask 0x000000ff at 16 link 201:

        #Филтриране за down traffic към 213.91.178.254 който е маркиран с tos 0x20/word traffic/ и пращане към клас 1:1004

        tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 ht 201:fe: match ip dst 213.91.178.254/32 match ip tos 0x20 0xff flowid 1:1004

        #Филтриране за down traffic към 213.91.178.254 и пращане към клас 1:1003

        tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 ht 201:fe: match ip dst 213.91.178.254/32 flowid 1:1003

    #Създаване на таблица с номер 202 подчинена на таблица 100 и съдържаща 256 записа в hash-a за 213.91.179.0 с маска /24

    tc filter add dev eth1 parent 1:0 prio 1 handle 202: protocol ip u32 divisor 256

        #Филтриране за down traffic към 213.91.179.0/24 който е маркиран с tos 0x20/word traffic/ и пращане към клас 1:1004

        tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 ht 100:b3: match ip dst 213.91.179.0/24 match ip tos 0x20 0xff flowid 1:1004

        #Филтриране за down traffic към 213.91.179.0/24 и пращане към клас 1:1003

        tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 ht 100:b3: match ip dst 213.91.179.0/24 flowid 1:1003[/]

---

Post Merge: [time]1258581600[/time]

---

Някой ще каже и какво толкова ... толкова писане за нищо.

Идеята на u32 hash е че няма последователно обхождане на правилата и всичко е насочено дирекно.

И разбира се смисъла е тогава когато има хиляди правила.

Цялата идея е че има разделяне на отделни таблици в който се описват съвпаденията. Така че кернела да се справи по бързо с тази задача.

Например ако трябва да ограничим клиенти в мрежа 192.168.4.0/24 е нужно да направим следното.

tc filter add dev eth1 parent 1:0 prio 5 protocol ip u32

tc filter add dev eth1 parent 1:0 prio 1 handle 100: protocol ip u32 divisor 256

tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 ht 800:: match ip dst 192.168.0.0/16 hashkey mask 0x0000ff00 at 16 link 100:

tc filter add dev eth1 parent 1:0 prio 1 handle 201: protocol ip u32 divisor 256

tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 ht 100:4: match ip dst 192.168.4.0/24 hashkey mask 0x000000ff at 16 link 201:

tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 ht 201:1: match ip dst 192.168.4.1/32 flowid 1:1001

...

tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 ht 201:fe: match ip dst 192.168.4.254/32 flowid 1:1254

тука с 201:1: описваме това съвпадение че сочи към адрес 192.168.4.1

а с 201:fe: че сочи към 192.168.4.254

важното е да се знае че числата са в hex вид.

ето и някой страници в интернет в което е показано как се използва:

http://lartc.org/howto/lartc.adv-filter.hashing.html

http://brownian.org.ua/?page_id=6

http://www.hazard.maks.net/blog/index.php?op=ViewArticle&articleId=181&blogId=1

http://vcalinus.gemenii.ro/?p=9

---

Post Merge: [time]1258581600[/time]

---

Ето и един реален тест:

Real-world testing has shown troughputs of 1300Mbps / 250.000 pps (aggregated in+out)  for a 2.6.20 linux shaping bridge on a quad-core Xeon X3210 (2.13GHz, 8M  L2 cache), 2GBs of RAM using Intel PCI Express Gigabit NICs.  At this traffic level, CPU utilization averages varied between 25 – 50 % for every core.  Almost 8.000 prefixes of various lengths were being shaped, with a roughly equal number of htb classes.

http://vcalinus.gemenii.ro/?p=9

[Велин]

интересно и полезно всеки с линукс сървър  който не ползва някакъв профи софт е добре да се възползва от такова решение, рано или късно листата набъбва и сървъра почва да тлачи.