Автор Тема: Шейпър за изтeгляне (download) и качване (upload)  (Прочетена 3665 пъти)

mystical

  • Напреднали
  • *****
  • Публикации: 326
  • Distribution: Debian, FreeBSD
  • Window Manager: XFCE
    • Профил
    • WWW
Здравейте!
Видях една интересна статия за линукс шейпър, която се намира на този адрес http://itservice-bg.net/?p=1596 и от няколко дена си блъскам главата с нея, но не мога да схвана логиката в цялата работа.

Първо искам да покажа една част от кога:

Код:
###
tc qdisc add dev eth0 root handle 1: htb default 1
tc qdisc add dev eth1 root handle 1: htb default 1

iptables -t mangle -A POSTROUTING -d 192.168.0.2 -j CLASSIFY --set-class 1:100
iptables -t mangle -A POSTROUTING -s 192.168.0.2 -j CLASSIFY --set-class 1:101
 
tc class add dev eth0 parent 1: classid 1:100 htb rate 10Mbit
tc qdisc add dev eth0 parent 1:100 handle 100: sfq perturb 10
 
tc class add dev eth1 parent 1: classid 1:101 htb rate 10Mbit
tc qdisc add dev eth1 parent 1:101 handle 101: sfq perturb 10
###

Как си обеснявам нещата и къде греша.

WAN=eth0
LAN=eth1

Цитат
Upload
tc class add dev eth0 parent 1: classid 1:100 htb rate 10Mbit
tc qdisc add dev eth0 parent 1:100 handle 100: sfq perturb 10

Цитат
Download
tc class add dev eth1 parent 1: classid 1:101 htb rate 10Mbit
tc qdisc add dev eth1 parent 1:101 handle 101: sfq perturb 10

iptables -t mangle -A POSTROUTING -d 192.168.0.2 -j CLASSIFY --set-class 1:100
Защо изходящия трафик от клиента се маркира на WAN, а не на eth1?
Как става това, при положение, че -d означава "адрес на получателя" и това би трябвало да са пакети, които вече се връщат към клиента?

iptables -t mangle -A POSTROUTING -s 192.168.0.2 -j CLASSIFY --set-class 1:101
Съответно, защо входящия трафик на клиента се маркира на LAN и как става това?
-s - "адрес на източника", не трябва ли това да са пакетите, които клиента изпраща (upload)?
Ще има ли ефек от цялата работа, при положение, че пакетът вече е преминал през WAN и се е консумирал реален трафик, а в последствие (на eth1) се е образувала опашка, която изкуствено се забавя да достигне клиента.

Пробвах с обърнат WAN и LAN тогава не работи.
Активен

Ако не можеш да градиш, поне не руши!

sudo

  • Напреднали
  • *****
  • Публикации: 73
    • Профил
По принцип си прав че "iptables .... -s $PRIVATE_NET ..." е изходящия трафик (при няколко условия) а "iptables .... -d $PRIVATE_NET ..." e входящия трафик, но ти защо реши че WAN=eth0 a LAN=eth1 ?
Цитат
Ще има ли ефект от цялата работа, при положение, че пакетът вече е преминал през WAN и се е консумирал реален трафик, а в последствие (на eth1) се е образувала опашка, която изкуствено се забавя да достигне клиента.
Трафик шейпъра в Линукс "tc" работи на база egress ( man tc ... Shaping occurs on egress...) т.е. на български, работи в/у изходящ трафик, няма значение накъде ще го праща: прави опашка в/у интерфейса от където ще замине трафика и така реално го контролира.
Активен

samiboy

  • Напреднали
  • *****
  • Публикации: 66
    • Профил
Аз съм автора на поста и тъй като не рабирам точно въпроса ще копна целия скрипт който се състой от два файла.

Изпълним: /etc/init.d/netscript

Код
GeSHi (Bash):
  1. #!/bin/bash
  2.  
  3. clear
  4. LOG=/var/log/router.log
  5. DB=/etc/ipclient
  6. DEV1=eth0
  7. DEV2=eth1
  8. SPEED1_IN=50Mbit
  9. SPEED1_OUT=30Mbit
  10. SPEED2_IN=70Mbit
  11. SPEED2_OUT=45Mbit
  12. BURST=2Mbit
  13. TUN="1 2 3 4";
  14.  
  15. echo "check duplicate LAN ip address"
  16. DUPLICATE=$(cat $DB | awk '{ print $1 }' | cut -d"#" -f2 | sort | uniq -d)
  17. for i in ${DUPLICATE}; do
  18.    if [ "$DUPLICATE" = "$DUPLICATE" ]; then
  19.        echo "Duplicate IP address: ${i} Script will not run"
  20.        exit 1
  21.    fi
  22. done;
  23.  
  24. echo "flush GLOBAL FIREWALL rules"
  25. iptables -F
  26. iptables -F -t nat
  27. iptables -F -t mangle
  28. iptables -X
  29. iptables -X -t nat
  30. iptables -X -t mangle
  31. iptables -P INPUT ACCEPT
  32. iptables -P FORWARD ACCEPT
  33. iptables -P OUTPUT ACCEPT
  34.  
  35. echo "start NAT clients rules"
  36. ADDR=$(grep -v \# $DB | grep speed | awk '{ print $1 }')
  37. for IP in $ADDR; do
  38. WAN=$(grep -v \# $DB | grep -w $IP | awk '{ print $2 }')
  39. iptables -t nat -A POSTROUTING -s $IP -o $DEV2 -j SNAT --to $WAN
  40. iptables -t nat -A PREROUTING -d $WAN -i $DEV2 -j DNAT --to $IP
  41. done;
  42.  
  43. echo "start table T1 clients rules"
  44. ADDR=$(grep -v \# $DB | grep T1 | awk '{ print $1 }')
  45. for IP in $ADDR; do
  46. iptables -A PREROUTING -t mangle -s $IP -j MARK --set-mark 101
  47. done;
  48.  
  49. echo "start GLOBAL TRAFFIC SHAPER rules"
  50. tc qdisc del dev $DEV1 root 2>/dev/null
  51. tc qdisc add dev $DEV1 root handle 1: htb r2q 625 default 65
  52. tc class add dev $DEV1 parent 1: classid 1:1 htb rate 1000Mbit
  53. tc qdisc del dev $DEV2 root 2>/dev/null
  54. tc qdisc add dev $DEV2 root handle 1: htb r2q 625 default 65
  55. tc class add dev $DEV2 parent 1: classid 1:1 htb rate 1000Mbit
  56.  
  57. echo "start TRAFFIC SHAPER IP speed1"
  58. ADDR=$(grep -v \# $DB | grep speed1 | awk '{ print $1 }')
  59. for IP in $ADDR; do
  60. MARK=$(cat $DB | grep -w -n $IP | cut -d":" -f1)
  61. UP=$(($MARK + 1000))
  62. DOWN=$(($MARK + 3000))
  63. iptables -t mangle -A POSTROUTING -d $IP -j CLASSIFY --set-class 1:$UP
  64. tc class add dev $DEV1 parent 1:1 classid 1:$UP htb rate $SPEED1_IN
  65. tc qdisc add dev $DEV1 parent 1:$UP handle $UP: sfq
  66. iptables -t mangle -A POSTROUTING -s $IP -j CLASSIFY --set-class 1:$DOWN
  67. tc class add dev $DEV2 parent 1:1 classid 1:$DOWN htb rate $SPEED1_OUT
  68. tc qdisc add dev $DEV2 parent 1:$DOWN handle $DOWN: sfq
  69. done;
  70.  
  71. echo "start TRAFFIC SHAPER IP speed2"
  72. ADDR=$(grep -v \# $DB | grep speed2 | awk '{ print $1 }')
  73. for IP in $ADDR; do
  74. MARK=$(cat $DB | grep -w -n $IP | cut -d":" -f1)
  75. UP=$(($MARK + 1000))
  76. DOWN=$(($MARK + 3000))
  77. iptables -t mangle -A POSTROUTING -d $IP -j CLASSIFY --set-class 1:$UP
  78. tc class add dev $DEV1 parent 1:1 classid 1:$UP htb rate $SPEED2_IN
  79. tc qdisc add dev $DEV1 parent 1:$UP handle $UP: sfq
  80. iptables -t mangle -A POSTROUTING -s $IP -j CLASSIFY --set-class 1:$DOWN
  81. tc class add dev $DEV2 parent 1:1 classid 1:$DOWN htb rate $SPEED2_OUT
  82. tc qdisc add dev $DEV2 parent 1:$DOWN handle $DOWN: sfq
  83. done;
  84.  
  85. echo "start TRAFFIC SHAPER tunnels"
  86. for i in $TUN; do
  87. iptables -t mangle -A POSTROUTING -o tun$i -j CLASSIFY --set-class 1:600$i
  88. tc qdisc del dev tun$i root 2>/dev/null
  89. tc qdisc add dev tun$i root handle 1: htb r2q 625 default 65
  90. tc class add dev tun$i parent 1: classid 1:600$i htb rate $SPEED1_IN
  91. tc qdisc add dev tun$i parent 1:600$i handle 600$i: sfq
  92. tc qdisc del dev tun$i handle ffff: ingress 2>/dev/null
  93. tc qdisc add dev tun$i handle ffff: ingress
  94. tc filter add dev tun$i parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 \
  95. police rate $SPEED1_OUT burst $BURST drop flowid :1
  96. iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o tun$i -j TCPMSS --clamp-mss-to-pmtu
  97. done;
  98.  
  99. echo "start LOGING"
  100. SP1=$(grep -v \# $DB | grep speed1 | wc -l)
  101. SP2=$(grep -v \# $DB | grep speed2 | wc -l)
  102. T1=$(grep -v \# $DB | grep T1 | wc -l)
  103. ALL=$(grep -v \# $DB | wc -l)
  104. echo "$(date +'%F %T')" netscript Sp1:$SP1 Sp2:$SP2 T1:$T1 All:$ALL Conn:"$(conntrack -C)" >> $LOG
  105. echo Sp1:$SP1 Sp2:$SP2 T1:$T1 All:$ALL
  106.  

конфигурационен: /etc/ipclient
Код:
10.123.7.24     93.155.130.65   speed1
10.127.10.8     93.155.130.66   speed1
10.124.3.2       93.155.130.67   speed1
10.129.13.8     93.155.130.68   speed1
10.129.3.7       93.155.130.69   speed2
10.123.11.2     93.155.130.70   speed2

eth0 е LAN а eth1 е WAN
Активен

mystical

  • Напреднали
  • *****
  • Публикации: 326
  • Distribution: Debian, FreeBSD
  • Window Manager: XFCE
    • Профил
    • WWW
Трафик шейпъра в Линукс "tc" работи на база egress ( man tc ... Shaping occurs on egress...) т.е. на български, работи в/у изходящ трафик, няма значение накъде ще го праща: прави опашка в/у интерфейса от където ще замине трафика и така реално го контролира.
sudo, благодаря ти за пояснението.

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

От доста години използвам линукс, но повърхностно и вече реших да навляза малко по-навътре в нещата. Това е първата ми среща с iproute2 и по конкретно tc. В момента всичко ми изглежда объркано, но се надявам с времето всичко да си дойде на мястото.

В момента чета за tc и все още не мога да преценя, кой е по-добрия метод за да направиш работещ и грамотен шейпър. Разбрах само, че повечето избягват " tc filter", но незнам защо и предпочитат "iptables  ... --set-mark". Също видях, че има вариант за приоритизиране на пакетите с TOS "iptables -t mangle -A CHKTOS -p icmp -j TOS --set-tos Minimize-Delay".
Има много варианти, но незнам кой е по-добрия и защо да избера точно него, а не някой от станалите. Ако някой сподели опита си ще се радвам.
Активен

Ако не можеш да градиш, поне не руши!

samiboy

  • Напреднали
  • *****
  • Публикации: 66
    • Профил
В този вариант на shaper няма никакви приоритизации. Може да се добави prio 0 за по голямата тарифа и prio 7 за по малката с цел да може да се гарантира по някакъв начин трафика на хората които плащат повече. Когато клиентите минаха бройката 500 и 400mb/s трафик shaper-a не се чупи но CPU-то (Quad Core) започва да влиза в 60-70% load. Просто правилата стават много (около 4000) и това е границата на непрофесионалните решения. Между другото скрипта на vladsun е съвършенно различен и работи в пъти по добре защото съкращава правилата (намалява с около 30% load на CPU) но този скрипт изчезна и няма намиране. Същата тази машина в момента е с около 700 клиента и е с това решение на MIkroTik

Код
GeSHi (Bash):
  1. /ip firewall mangle
  2. add action=mark-connection chain=forward comment=50Mbits new-connection-mark=50M src-address-list=50M
  3. add action=mark-packet chain=forward connection-mark=50M new-packet-mark=50M passthrough=no
  4. add action=mark-connection chain=forward comment=70Mbits new-connection-mark=70M src-address-list=70M
  5. add action=mark-packet chain=forward connection-mark=70M new-packet-mark=70M passthrough=no
  6.  
  7. /queue type
  8. add kind=pcq name=PCQ_down_50M pcq-classifier=dst-address pcq-rate=50M
  9. add kind=pcq name=PCQ_up_50M pcq-classifier=src-address pcq-rate=50M
  10. add kind=pcq name=PCQ_down_70M pcq-classifier=dst-address pcq-rate=70M
  11. add kind=pcq name=PCQ_up_70M pcq-classifier=src-address pcq-rate=70M
  12.  
  13. /queue tree
  14. add name=Download parent=ether1 priority=1
  15. add name=down_50M packet-mark=50M parent=Download queue=PCQ_down_50M
  16. add name=Upload parent=ether2 priority=1
  17. add name=50M packet-mark=50M parent=Upload queue=PCQ_up_50M
  18. add name=down_70M packet-mark=70M parent=Download queue=PCQ_down_70M
  19. add name=70M packet-mark=70M parent=Upload queue=PCQ_up_70M
  20.  
  21. /ip firewall address-list
  22. add address=10.123.3.10 list=50M
  23. add address=10.123.1.18 list=50M
  24. add address=10.127.6.11 list=50M
  25. add address=10.123.2.22 list=70M
  26. add address=10.123.8.22 list=70M
  27.  

Това решение е уникално защото с 10-тина правила въртим трафик на address-list-а от 700 клиента. load на CPU в случая е 25~30% при 70 000~100 000 connections и 100 000~120 000 pps при 350~400mbits трафик.

Ролята на iptables в комбинация с shaper в Linux освен, че маркира пакета следи за състоянието на връзката а filter в tc не прави това. Поради тази причина стрелката в speedtest кове с iptables и шари с filter в tc.

Приотизирането на трафика все още е спор дали е правилен ход или не защото на теория си мислиш едно но на практика излиза съвсем друго. Най елементарния пример е, че ограничаваш едни клиенти за един ресурс които в 99% процента от случайте е свободен. Аз например единствената приоритизация която признавам е VOIP за другото няма никакъв смисъл !!!

Моят съвет е да си избереш една network OS от рода на vyatta, mikrotik, pfsence да и прочетеш документацията и да си свършиш работа.
Активен

mystical

  • Напреднали
  • *****
  • Публикации: 326
  • Distribution: Debian, FreeBSD
  • Window Manager: XFCE
    • Профил
    • WWW
Благодаря за информацията.

Между другото скрипта на vladsun е съвършенно различен и работи в пъти по добре защото съкращава правилата (намалява с около 30% load на CPU) но този скрипт изчезна и няма намиране.

Видях, че има сатия писана от vladsun във форума " Използване на IPSET, IPTABLES и IPMARK и Оптимизация на iptables и tc правила " , но незнам дали става въпрос за същото или има и нещо по-ново.
Даже да става въпрос за същото, в момента ми е мъгливо с tc, а за нещата които са писани там, ще ми трябва още време.

Приотизирането на трафика все още е спор дали е правилен ход или не защото на теория си мислиш едно но на практика излиза съвсем друго. Най елементарния пример е, че ограничаваш едни клиенти за един ресурс които в 99% процента от случайте е свободен. Аз например единствената приоритизация която признавам е VOIP за другото няма никакъв смисъл !!!

Напълно съм съгласен.
Можеби проблема идва от това, че ако си малък доставчик или доставчик от малък град, чисто финансово не можеш да си позволиш, да оставиш клиентите да ползват скорости без шейпър. Понеже цените на трафика са страшно високи все още, ако не си в голям град. Иначе кой доставчик иска да налива пари за оборудване, и да се занимава с безсмислени неща, вместо клиентите да са доволни и да идват други понеже могат да позват интернет на воля.
 
Моят съвет е да си избереш една network OS от рода на vyatta, mikrotik, pfsence да и прочетеш документацията и да си свършиш работа.

Като идея е добре, но от доста години ползвам debian и там ми е по-конфортно.
« Последна редакция: Jun 29, 2013, 23:25 от mystical »
Активен

Ако не можеш да градиш, поне не руши!

mystical

  • Напреднали
  • *****
  • Публикации: 326
  • Distribution: Debian, FreeBSD
  • Window Manager: XFCE
    • Профил
    • WWW
След дълго четене и ровене в интернет, реших, че варианта, който е описал VladSun е добър избор (линковете към неговите статии може да намерите в предишния пост), а именно използване на IPMARK.
IPMARK не идва като част от iptables, поради което трябва да се инсталира допълнително. За да тествам как работи IPMARK написах едно малко скрипче на Python, но възникнаха някои въпроси по време на този процес.
За тези, които искат да използват IPMARK и се борят, да разберат на какъв принцип работи всичко, искам да обясня на кратко какво съм разбрал.

Система: Debian 3.2.46-1 x86_64

Инсталиране на IPMARK (copy-paste):
--------------------------------------------------------------------------------
aptitude update
aptitude install module-assistant xtables-addons-source xtables-addons-common
m-a prepare
m-a auto-install xtables-addons-source
depmod -a
--------------------------------------------------------------------------------
Източник: Установка модуля IPMARK для iptables в Debian Squeeze и shaper tc без нагрузки на процессор - See more at: http://linuxsnippets.net/ru/node/268#sthash.TbbGwjXr.dpuf

Исталиране на необходим модул за Python:
apt-get install python-ipcalc

Ето и тестовия скрипт:
Код
GeSHi (Python):
  1. #!/usr/bin/env python
  2.  
  3. import ipcalc
  4.  
  5. IFACE_INTERNAL = "eth0"
  6. IFACE_EXTERNAL = "eth1"
  7.  
  8. DOWN_SPEED = "8Mbit"
  9. UP_SPEED = "4Mbit"
  10.  
  11. ip = "10.111.1.2"
  12. mask = 24
  13.  
  14. net = ipcalc.Network(ip, mask)
  15. ip_version = net.version()
  16.  
  17. if ip_version == 4:
  18.    ip = ipcalc.IP(ip)
  19.    ipmark_hex = ip.hex()[4:8]
  20.  
  21.    # Upload Speed Rule
  22.    ipmark_up = 'iptables -t mangle -A FORWARD -s ' + "10.111.1.0/24" + ' -j IPMARK --addr=src --and-mask=0xffff --or-mask=0x10000'
  23.  
  24.    tc_up = []
  25.    tc_up += ['tc qdisc add dev ' + IFACE_EXTERNAL + ' root handle 1: htb']
  26.    tc_up += ['tc filter add dev ' + IFACE_EXTERNAL + ' parent 1:0 protocol ip prio 1 fw']
  27.  
  28.    tc_up += ['tc class add dev ' + IFACE_EXTERNAL + ' parent 1: classid 1:' + ipmark_hex + ' htb rate ' + UP_SPEED]
  29.    tc_up += ['tc qdisc add dev ' + IFACE_EXTERNAL + ' parent 1:' + ipmark_hex + ' handle ' + ipmark_hex + ' sfq perturb 10']
  30.  
  31.    # Download Speed Rule
  32.    ipmark_down = 'iptables -t mangle -A FORWARD -d ' + "10.111.1.0/24" + ' -j IPMARK --addr=dst --and-mask=0xffff --or-mask=0x10000'
  33.  
  34.    tc_down = []
  35.    tc_down += ['tc qdisc add dev ' + IFACE_INTERNAL + ' root handle 1: htb']
  36.    tc_down += ['tc filter add dev ' + IFACE_INTERNAL + ' parent 1:0 protocol ip prio 1 fw']
  37.  
  38.    tc_down += ['tc class add dev ' + IFACE_INTERNAL + ' parent 1: classid 1:' + ipmark_hex + ' htb rate ' + DOWN_SPEED]
  39.    tc_down += ['tc qdisc add dev ' + IFACE_INTERNAL + ' parent 1:' + ipmark_hex + ' handle ' + ipmark_hex + ' sfq perturb 10']
  40.  
  41.    print '==========='
  42.    print 'hex.......:', ip.hex()
  43.    print '==========='
  44.    print 'IPMARK Rule UP:', ipmark_up
  45.    print 'TC Rules UP:', tc_up
  46.    print '==========='
  47.    print 'IPMARK Rule DOWN:', ipmark_down
  48.    print 'TC Rules DOWN:', tc_up
  49.    print '==========='
  50.  

Изхода от скрипта е:
Цитат
===========
hex.......: 0a6f0102
===========
IPMARK Rule UP: iptables -t mangle -A FORWARD -s 10.111.1.0/24 -j IPMARK --addr=src --and-mask=0xffff --or-mask=0x10000
TC Rules UP: ['tc qdisc add dev eth1 root handle 1: htb', 'tc filter add dev eth1 parent 1:0 protocol ip prio 1 fw', 'tc class add dev eth1 parent 1: classid 1:0102 htb rate 4Mbit', 'tc qdisc add dev eth1 parent 1:0102 handle 0102 sfq perturb 10']
===========
IPMARK Rule DOWN: iptables -t mangle -A FORWARD -d 10.111.1.0/24 -j IPMARK --addr=dst --and-mask=0xffff --or-mask=0x10000
TC Rules DOWN: ['tc qdisc add dev eth0 root handle 1: htb', 'tc filter add dev eth0 parent 1:0 protocol ip prio 1 fw', 'tc class add dev eth0 parent 1: classid 1:0102 htb rate 8Mbit', 'tc qdisc add dev eth0 parent 1:0102 handle 0102 sfq perturb 10']
===========

Искам да уточня, че скрипта не изпълнява командите, а само събира стойностите и ги извежда в удобен вариант за copy-paste.

Какво прави скрипта?
Имаме едно тестово IP - 10.111.1.2, за което предварително сме дигнали рутиране. На 19-ти ред от скрипта взимаме това IP и го превръщаме в hex (hex.......: 0a6f0102) след което от тази стойност взимаме и използваме само последните 4 символа (0102). Това ми стана ясно от статията, която посочих по-горе, но от това което е обяснил VladSun за траснирането не можах да разбера нищо. Ако някой може да обясни разликата между този начин на прихващане на пакетите и този на VladSun, ще е полезно.
В коя верига е по-добре да се прихванат пакетите - PREROUTING, POSTROUTING или FORWRD и защо?
Също не ми стана ясно, защо добавяме "tc qdisc add dev eth1 parent 1:0102 handle 0102 sfq perturb 10" при положение, че шейпъра работи и без това правило, каква е идеята.

Благодаря!
« Последна редакция: Jun 30, 2013, 00:36 от mystical »
Активен

Ако не можеш да градиш, поне не руши!

mystical

  • Напреднали
  • *****
  • Публикации: 326
  • Distribution: Debian, FreeBSD
  • Window Manager: XFCE
    • Профил
    • WWW
Видях интересна програма (и преди я бях видял, но не обърнах внимание), която генерира u32 хеш филтри http://vcalinus.gemenii.ro/

Някой да я е пробвал?
Активен

Ако не можеш да градиш, поне не руши!

edmon

  • Гост
Хората предпочитат IPMARK щото не могат да разберат как работи hash  функцията на tc filter.
Ето сега една моя измишльотина.

Код:
#!/bin/bash
tc="/sbin/tc"
#tc="/bin/echo /sbin/tc"

$tc qdisc del dev eth1 root
$tc qdisc del dev eth0 root


$tc qdisc add dev eth1 root handle 1: htb default 90
$tc class add dev eth1 parent 1:0 classid 1:1 htb rate 1000mbit

$tc qdisc add dev eth0 root handle 1: htb default 90
$tc class add dev eth0 parent 1:0 classid 1:1 htb rate 1000mbit


$tc filter add dev eth1 parent 1:0 prio 10 protocol ip u32
$tc filter add dev eth1 parent 1:0 protocol ip prio 10 handle 8: u32 divisor 8


for i in {1..7}; do
        $tc filter add dev eth1 parent 1:0 prio 10 handle ${i}: protocol ip u32 divisor 256
done


$tc filter add dev eth1 parent 1:0 protocol ip prio 10 u32 ht 800:: match ip dst 101.101.172.0/24 hashkey mask 0x000000ff at 16 link 7:

for i in {1..7}; do

$tc filter add dev eth1 parent 1:0 protocol ip prio 10 \
                u32 ht 8:$[i]: \
                match ip dst 192.168.${i}.0/24 \
                hashkey mask 0x000000ff at 16 \
                link $i:

done


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


# class 1: 1000 --- parent for clients' classes:
$tc class add dev eth1 parent 1:1 classid 1:1000 htb rate 220mbit quantum 1500
$tc qdisc add dev eth1 parent 1:1000 handle 1000 sfq perturb 10

$tc class add dev eth1 parent 1:1 classid 1:3000 htb rate 200mbit quantum 1500
$tc qdisc add dev eth1 parent 1:3000 handle 3000 sfq perturb 10

#
# particular client:
for i in {1..7}
 do
        for y in {2..254}
                do
                hy=$(printf "%x\n" $y)
                l=1000
                k=3000
                m=$((m+1))
                z=$(($l+$m))
                x=$(($k+$m))
#echo $z
                $tc class add dev eth1 parent 1:1000 classid 1:${z} htb rate 100kbit ceil 25mbit  burst 1600kb cburst 1600kb
                $tc qdisc add dev eth1 parent 1:${z} handle ${z}: sfq perturb 10
                $tc filter add dev eth1 protocol ip parent 1:0 prio 100 u32 ht ${i}:${hy}: match ip tos 0x00 0xff match ip dst 192.168.${i}.${y} flowid 1:${z}

                $tc class add dev eth1 parent 1:3000 classid 1:${x} htb rate 28kbit ceil 20mbit  burst 1600kb cburst 1600kb
                $tc qdisc add dev eth1 parent 1:${x} handle ${x}: sfq perturb 10
                $tc filter add dev eth1 protocol ip parent 1:0 prio 100 u32 ht ${i}:${hy}: match ip tos 0x20 0xff match ip dst 192.168.${i}.${y} flowid 1:${x}

                $tc class add dev eth0 parent 1:232 classid 1:${z} htb rate 1mbit ceil 18mbit
                $tc qdisc add dev eth0 parent 1:${z} handle ${z}: sfq perturb 10
                $tc filter add dev eth0 protocol ip parent 1:0 prio 100 handle ${m} fw flowid 1:${z}

                echo -ne i ${i} y ${y} z ${z} x ${x} z ${z} hy ${hy}  m ${m} \\r

        done

done

for y in 7 12 13 {19..27} {33..64}
                do
                hy=$(printf "%x\n" $y)
                l=5000
                k=7000
                m=$((m+1))
              z=$(($l+$m))
                x=$(($k+$m))

                $tc class add dev eth1 parent 1:1000 classid 1:${z} htb rate 215kbit ceil 25mbit  burst 1600kb cburst 1600kb
                $tc qdisc add dev eth1 parent 1:${z} handle ${z}: sfq perturb 10
                $tc filter add dev eth1 protocol ip parent 1:0 prio 100 u32 ht 7:${hy}: match ip tos 0x00 0xff match ip dst 101.101.172.${y} flowid 1:${z}

                $tc class add dev eth1 parent 1:3000 classid 1:${x} htb rate 48kbit ceil 20mbit  burst 1600kb cburst 1600kb
                $tc qdisc add dev eth1 parent 1:${x} handle ${x}: sfq perturb 10
                $tc filter add dev eth1 protocol ip parent 1:0 prio 100 u32 ht 7:${hy}: match ip tos 0x20 0xff match ip dst 101.101.172.${y} flowid 1:${x}


                $tc class add dev eth0 parent 1:232 classid 1:${z} htb rate 1mbit ceil 18mbit
                $tc qdisc add dev eth0 parent 1:${z} handle ${z}: sfq perturb 10
                $tc filter add dev eth0 protocol ip parent 1:0 prio 99 u32 match ip src 91.201.172.${y} flowid  1:${z}


done


Имаше и някви правила за uplad обаче там нещата са грозни и трябва да се слагат марки за всики потоци към ип от лана и после да се слагат правила с fwmark
:)
Има по два родителски класа, защото интернет идва по БГ и ИНТ, като на интерфейсите с аиптейбълс са маркирани с ТОС. :)
« Последна редакция: Apr 15, 2015, 09:02 от edmon »
Активен