Автор Тема: iptables - IPMARK + tc  (Прочетена 6060 пъти)

Slevin_

  • Напреднали
  • *****
  • Публикации: 182
    • Профил
Re: iptables - IPMARK + tc
« Отговор #15 -: Dec 25, 2010, 15:41 »
Трябва да преосмисля основно конфигурацията макар, че топологията на мрежата не мога да я пипам, остава тотална оптимизация на правила (или групиране на такива) с цел пестене на ресурси. От сега усещам как ме очакват забавни моменти по празниците тип проби-грешки. По принцип както казах вече канала тук е широк за потреблението на клиентите и няма нужда да се цепи всеки байт, спра ли qdisc в пиков час трафика стига до 600Mbit без загуби на пакети с пуснат SNAT и DNAT което ясно показва, че машината може да държи трафик и има нужда от оптимизиране на конфигурацията и.
Честно казано според мен оптимизацията на правила няма да реши проблема ти, а ще го измести на по-късен етап. Така само закърпваш ситуацията.
700 потребителя са си доволно количество, за да ги подлагаш на адресна транслация 1:1 при днешните скорости.
След време ще станат 800, след това 900, на всеки 100 ли ще търсиш оптимизация в iptables/tc или ще подменяш с по-мощен хардуер.
Когато стане неизбежно, вече ще имаш повече потребители, с които ще трябва да се съобразяваш и ще ти усложнят схемата още повече.
 
По-добре обмисляй вариант на етапи да преминеш към "чисто" маршрутизиране. Не знам каква е топологията ти, но при всички случай ще има начин да сегментираш на L2, така че да те устройва схемата.
Ако трябва подлагай временно на NAT само мрежи, които са ти през nexthop навътре, докато решиш и при тях как ще процедираш.

Търси оптимизацията в топологията, отколкото в iptables/tc.
Активен

"Две неща на този свят са безкрайни - човешката глупост и вселената. За второто не съм съвсем сигурен" А. Айнщайн

nemanema

  • Напреднали
  • *****
  • Публикации: 103
    • Профил
Re: iptables - IPMARK + tc
« Отговор #16 -: Dec 26, 2010, 00:27 »
Преди да започнеш с глобални промени по мрежата, както ти препоръчаха (аз също съм на мнение, че се нуждае от реорганизация), и чистене на правила за трафик контрол след това(това ще изцеди хардуера до максимум), ти предлагам да направиш следните неща, а дали и как решаваш ти. Принципно ми трябваше точният модел на дъното за да съм конкретен, но предполагам че си с X8SIE или X8SIE-F (ако греша, логиката е аналогична, но трябва да се внимава).
1. Ако правилно разбирам на двупортовата външна карта са ти външните връзки и това е добре, но на вградените ще им е малко трудно да поемат толкова прекъсвания и трафик. При ръчно източени ядра и оптимизация на драйвера картите на дъното трудно ще надскочат пълен дуплекс 700 мв/с. Но външната, макар и малко старичка с чип 82571ЕВ ще ти направи почти 930 мв/с в пълен дуплекс. За това първо размени портовете (т.е. картите) външната да управлява трафика за локалната ти мрежа, а вградените карти да управляват външният трафик.
2. Ако си с цитираното от мен дъно, значи си с последния наличен БИОС, и ако не си го пипал, трябва да си го настроиш. Предполагам си погледнал в БИОС на страницата Advanced Chipset Control -> PCI/PnP Configuration -> PCIE I/O Performace че стойността по подразбиране е 128, а за шейпър силно ти препоръчвам да е на 256.
Ами за "без пари" това можеш да направиш за сега на ниво хардуер. Т.е. това ще ти даде глътка въздух, за да можеш да копаш по оптимизациите на трафик контрола. Като тук е добре да се спомене режим на ядрото RT (real time).
Ако направиш това, което ти препоръчвам и видиш ефекта, ще се радвам да пием по бира ;)
Ако имаш възможност, силно ти препоръчвам да си смениш двупортовата карта с четирипортова, но да не е с по стари чипове от 82576 и да си буташ трафика през нея. А когато, или ако имаш много LAN портове на машината, прегледай възможностите за load balancing & bonding.
И не на последно место, но финансово зависим проблем е паметта. При възможност направи 8 гб, но да не е на 4 х 2 гб, а 2 х 4 гб. И не се набутвай да взимаш 1333, като ще работи на 1066. Все пак процесора повече от 2.5 GT/s не обработва, не че схемния набор може повече с тия 36 споделени линии. ;)
Успех !

П. Ще следя развитието на проблема ти, като може и на лична да пишеш какво и как си постигнал. Като е добре в крайна сметка да се оформи статия, която да се публикува тук за да е в помощ и на други.
Активен

---=== мир и любов ===---

VladSun

  • Напреднали
  • *****
  • Публикации: 2166
    • Профил
Re: iptables - IPMARK + tc
« Отговор #17 -: Dec 26, 2010, 00:44 »
Моят опит с доста по-слаба (поне "2 пъти") машина е:
- 2500+ потребителя;
- директно маршрутизиране на публичните ИП адреси към клиента;
- 400+Мбит up/ 400+Mbit down;
- ограничаване на трафика по 4 направления (BG/международен - upload/download);
- прекъсванията на всеки интерфейс на отделно ядро.

cpu load - макс. 60%
Активен

KISS Principle ( Keep-It-Short-and-Simple )
http://openfmi.net/projects/flattc/
Има 10 вида хора на този свят - разбиращи двоичния код и тези, които не го разбират :P

samiboy

  • Напреднали
  • *****
  • Публикации: 66
    • Профил
Re: iptables - IPMARK + tc
« Отговор #18 -: Dec 26, 2010, 02:15 »
Аз още от самото начало се бях приготвил за публични ип адреси. Затова вдигнах BGP и отделен vlan с друг доставчик освен основния да се сборя с load balancing. Исках да направя нещо надежно и стабилно. По тази причина се купи и дуал картата всеки да си има порт. Но в самото начало страстите ми бяха охладени и бях поставен в други условия а подмрежите се управляват от друг администратор. Няма смисъл повече да коментираме това защото поне засега не мога да променя политиката с NAT. Тази вечер пусках и спирах DNAT, tc upload и download, исках да съм сигурен найстина къде е проблема. Проблема се появява при 300Mbit download и 350Mbit upload и ако download-а падне на 250Mbit изчезва. Всъщност искам да повторя, че проблема се състои в подскачане на ping-a между 6 и 30 msec до dir.bg като няма загуби но не съм го и много чакал защото не искам да усетят клиентите, при нормална работа ping-а кове 4~5 msec. При премахване на DNAT няма никаква промяна но при премахването на download правилата нещата заспиват. Сега вече съм абсолютно сигурен, че проблема идва от трафик контрола.

Машината съм я сглобил сам и нямам спомен какво точно е дъното а е малко трудно да я отворя (не, че е невъзможно де). Но това с BIOS-a трябва да си нароча една нощ, че достъпа е труден до нея, заради СОТ-а. Дуал картата е PCI-E 4X, нарочно исках такава а не 1x, беше скъпичка, големия трафик минава през нея, на единия от вградените портове има www/mail server а другия е свободен.

Плана засега е проба с IPMARK и ако не успея да го направя добре flow classifier много ми хареса като идея, но пак, документацията я няма никаква ...
« Последна редакция: Dec 26, 2010, 02:22 от samiboy »
Активен

VladSun

  • Напреднали
  • *****
  • Публикации: 2166
    • Профил
Re: iptables - IPMARK + tc
« Отговор #19 -: Dec 26, 2010, 02:26 »
Ако ще пробваш с IPMARK, по-добре пробвай с IPCLASSIFY - нямa да има нужда от tc филтри и "гледане" на MARK полето.

Аз лично ползвах IPCLASSIFY в горния пример.
Активен

KISS Principle ( Keep-It-Short-and-Simple )
http://openfmi.net/projects/flattc/
Има 10 вида хора на този свят - разбиращи двоичния код и тези, които не го разбират :P

samiboy

  • Напреднали
  • *****
  • Публикации: 66
    • Профил
Re: iptables - IPMARK + tc
« Отговор #20 -: Dec 26, 2010, 22:04 »
Простете ми невежеството но този код как може да се преобразува в bash ?
Код
GeSHi (Perl):
  1. #!/usr/bin/perl
  2.  
  3. ($ip) = @ARGV;
  4. $id = sprintf("%X", $ip + 0x100);
  5. $class = "tc class add dev vlan100 parent 1:10 classid 1:0".$id." htb rate 30Mbit ceil 1000Mbit burst 1Mbit";
  6. $qdisc = "tc qdisc add dev vlan100 parent 1:0".$id." handle 0".$id." sfq perturb 10 ";
  7.  
  8. `$class`;
  9. `$qdisc`;
  10.  
Активен

VladSun

  • Напреднали
  • *****
  • Публикации: 2166
    • Профил
Re: iptables - IPMARK + tc
« Отговор #21 -: Dec 26, 2010, 22:49 »
Явно не съм чак толкова добър (да не казвам хич) на bash - доста време ми отне :)

Код
GeSHi (Bash):
  1. #/bin/bash
  2.  
  3. offset=$(printf "%d" 0x100)
  4. id=$(printf "%x" $(($offset+$1)))
  5.  
  6. tc class add dev vlan100 parent 1:10 classid 1:0${id} htb rate 30Mbit ceil 1000Mbit burst 1Mbit
  7. tc qdisc add dev vlan100 parent 1:0${id} handle 0${id} sfq perturb 10
Активен

KISS Principle ( Keep-It-Short-and-Simple )
http://openfmi.net/projects/flattc/
Има 10 вида хора на този свят - разбиращи двоичния код и тези, които не го разбират :P

samiboy

  • Напреднали
  • *****
  • Публикации: 66
    • Профил
Re: iptables - IPMARK + tc
« Отговор #22 -: Dec 28, 2010, 00:22 »
Ами..., аз още съм на ниво IPMARK (евентуално за в бъдеще IPCLASSIFY) но пак се нацелих в първоначалната греда - многото подмрежи, тоест нестандартната топология която ако не беше такава отдавна да съм инсталирал това FLATC и да съм забравил какво съм правил някога ...

Реших да сглобя примерен скрипт с IPMARK за мрежи /24 и се роди това:
Код
GeSHi (Bash):
  1. #!/bin/bash
  2.  
  3. iptables -A FORWARD -t mangle -d 10.125.3.0/24 -j IPMARK --addr=dst --and-mask=0xff --or-mask=0x10100
  4.  
  5. tc qdisc del dev vlan100 root
  6. tc qdisc add dev vlan100 root handle 1 htb default 1
  7. tc filter add dev vlan100 parent 1:0 protocol ip prio 1 fw
  8.  
  9. IP=`grep -v \# /etc/ipclient | grep speed1 | grep 10.125.3. | cut -d":" -f1 | cut -d"." -f4`;
  10. for IP in $IP; do
  11. offset=$(printf "%d" 0x100)
  12. id=$(printf "%x" $(($offset+$IP)))
  13. tc class add dev vlan100 parent 1:10 classid 1:0${id} htb rate 10Mbit ceil 1000Mbit burst 1Mbit
  14. tc qdisc add dev vlan100 parent 1:0${id} handle 0${id} sfq perturb 10
  15. done;
  16.  
В сътворението по горе променливата IP грепва от един файл наличните ип адреси от мрежа 10.125.3.0/24 и ги прекарва през class и qdisc. Така нещата заработиха и видях светлинката в тунела. Обаче когато преброих мрежите с /24 се оказаха, че са 139 което ще рече, че трябва да имам 278 марка в двете посоки. Със сигурност това ще олекоти трафика на машината защото 278 марка не са 1400 все пак но се замислих не мога ли да имам по глобален марк. Както казах преди тези 139 мрежи /24 са подмрежи на 9 със /16, тоест намират се в:
10.121.0.0/16
10.122.0.0/16
10.123.0.0/16
10.124.0.0/16
10.125.0.0/16
10.126.0.0/16
10.127.0.0/16
10.128.0.0/16
10.129.0.0/16

И така, от скрипта за мрежи /24 набързо преправих ситуацията за мрежи /16 без да грепва от файл а с променлива $1 и $2 където се намират в 10.125.$1.$2 например и за да добавим адрес 10.125.3.2 изпълняваме ./script 3 2
Код
GeSHi (Bash):
  1. #!/bin/bash
  2.  
  3. iptables -t mangle -A FORWARD -d 10.125.0.0/16 -j IPMARK --addr=dst --and-mask=0xffff --or-mask=0x10000
  4.  
  5. tc qdisc del dev vlan100 root
  6. tc qdisc add dev vlan100 root handle 1 htb default 1
  7. tc filter add dev vlan100 parent 1: protocol ip prio 1 fw
  8.  
  9. offset=$(printf "%d" 0x00)
  10. id1=$(printf "%x" $(($offset+$1)))
  11. id2=$(printf "%02x" $2)
  12. tc class add dev vlan100 parent 1:1 classid 1:${id1}${id2} htb rate 10Mbit ceil 1000Mbit burst 1Mbit
  13. tc qdisc add dev vlan100 parent 1:${id1}${id2} handle ${id1}${id2} sfq perturb 10
  14.  
И тази ситуация се оказа работеща но само за мрежа 10.125.0.0/16 защото явно не ми стига маската за повече или поне аз така го разбирам. Какво ли не правих, не намерих вариант да добавя другите мрежи. Та въпроса ми е след като имам марк и работещи tc правила на мрежа 10.125.0.0/16 в горния вариант възможно ли е по някакъв начин да направя същото и за останалите мрежи ? Все пак блазни ме варианта с мрежи /16 защото на 9 такива в двете посоки правят 18 марка което със сигурност ще олекне товара на желязото.
Активен

VladSun

  • Напреднали
  • *****
  • Публикации: 2166
    • Профил
Re: iptables - IPMARK + tc
« Отговор #23 -: Dec 28, 2010, 01:50 »
139 /24 мрежи?!?
139*254 = 35306 хоста?!?

А ти имаш 700 ...
Говори с шефа :) Дет се вика - имаш повече мрежи отколкото хостове :)

Единствено се сещам да пробваш с няколко подкласа на root класа с различни major номера. Тогава ще можеш да работиш с /16 мрежи (даже и с /8).

Но не съм сигурен дали ще стане и доколко ще те устройва разпределението на скоростите - първо ще се разпределят по мрежи и след това по ИП-та.
« Последна редакция: Dec 28, 2010, 01:53 от VladSun »
Активен

KISS Principle ( Keep-It-Short-and-Simple )
http://openfmi.net/projects/flattc/
Има 10 вида хора на този свят - разбиращи двоичния код и тези, които не го разбират :P

samiboy

  • Напреднали
  • *****
  • Публикации: 66
    • Профил
Re: iptables - IPMARK + tc
« Отговор #24 -: Jan 01, 2011, 16:04 »
Проблема поне засега е решен, може би не толкова елегантно но резултата е повече от добър и целта е постигната.

След като прокарах всички варианти с IPMARK и разбрах, че с моята мулти нефункционална конфигурация на мрежата нещата няма да тръгнат защото ако ползвам маска /24 мога да контролирам 99 мрежи а аз имам 139 а с маска /16 само една а аз имам 9 почти се бях отказал когато ми светна една идея. Тъй като аз имам 139 частни мрежи с маска /24 в които има 700 ип адреса които пък са твърдо зад 4 публични мрежи /24 SNAT не мога ли да огранича трафика на публичните адреси. В предишен мой пост бях показал, че информацията се грепва от текствов файл със синтаксис:
Код
GeSHi (Bash):
  1. lan_ip:wan_ip:speed1 # платил клиент на по ниска тарифа
  2. lan_ip:wan_ip:speed2 # платил клиент на по висока тарифа
  3. #lan_ip:wan_ip:spee2 # неплатил клиент (скрипта го пропуска и не създава за него правила)
  4.  
След като грепвам локалните ип адреси преди първото двуеточие няма да има проблем да правя същото и след второто но този път с публичните ип адреси. И ако нещата проработят щях да спестя само в едната посока в случая download от 700 правила CLASSIFY на 4 с IPMARK което хич не е малко защото общо правилата само за марка в iptables от 1400 ще станат 704. Както вече стана ясно ограничаването на скороста на публичните адреси проработи само във веригата PREROUTING и то само в посока "към" мрежата която маркирам тоест download. Пробвах всички останали вериги за да маркирам трафика посока "от" тоест upload но iptables прихващаше само някакви kb-та. И така при създалата се ситуация аз ограничавам upload на частните адреси а download на публичните. Колкото и да звучи неправилно като решение аз изчаках два дена за да наблюдавам за аномалии но такива не се получиха. Машината омекна и след дълги наблюдения мисля, че спестих някъде около 8~10 % натоварване на CPU. В скриптово положение се получи нещо такова:

Публичните адреси - download в който имаме 4 IPMARK, 700 tc class и един tc filter
Код
GeSHi (Bash):
  1. tc qdisc del dev $DEV1 root
  2. tc qdisc add dev $DEV1 root handle 1: htb default 10
  3. tc filter add dev $DEV1 parent 1:0 protocol ip prio 1 fw
  4.  
  5. NET=93.155.130.
  6. ID=1
  7. iptables -A PREROUTING -t mangle -d ${NET}0/24 -j IPMARK --addr=dst --and-mask=0xff --or-mask=0x10${ID}00
  8. IP=$(grep -v \# /etc/ipclient | grep speed1 | cut -d":" -f2 | grep ${NET} | cut -d"." -f4  | sort -nu)
  9. for IP in $IP; do
  10. OFFSET=$(printf "%d" 0x${ID}00)
  11. MARK=$(printf "%x" $(($OFFSET+$IP)))
  12. tc class add dev $DEV1 parent 1:1 classid 1:0${MARK} htb rate $SPEEDIN ceil $CEIL burst $BURSTIN
  13. tc qdisc add dev $DEV1 parent 1:0${MARK} handle 0${MARK}: sfq perturb 10
  14. done;
  15.  
Частните адреси - upload в който имаме 700 CLASSIFY, 700 tc class
Код
GeSHi (Bash):
  1. tc qdisc del dev $DEV2 root
  2. tc qdisc add dev $DEV2 root handle 1: htb default 10
  3.  
  4. ADDRESS=`grep -v \# /etc/ipclient | grep speed1 | cut -d":" -f1`;
  5. for LANIP in $ADDRESS; do
  6. MARK=$(grep -v \# /etc/ipclient | grep -w -n $LANIP | cut -d":" -f1)
  7. MARKUP=$(($MARK + 1000))
  8. iptables -t mangle -A FORWARD -s $LANIP -j CLASSIFY --set-class 1:$MARKUP
  9. tc class add dev $DEV2 parent 1:1 classid 1:$MARKUP htb rate $SPEEDOUT burst $BURSTOUT
  10. tc qdisc add dev $DEV2 parent 1:$MARKUP handle $MARKUP: sfq perturb 10
  11. done;
  12.  
Такааа, обаче радоста ми беше кратка защото на третата вечер пак в пиков час download 250Mbit upload 350Mbit пинга подскочи. Този път беше доста по различно като на всеки 7-8 пакета стоиноста ковеше на 4-5 msec и следваха 2-3 пакета на 16-20 msec. Ситуацията не приличаше на предишния вариант защото стоиностите тогава скачаха до 40-50 msec и така си седяха постоянно, явно имаше оптимизация на машината но не съвсем. Премахваики правилата на IPMARK и получавайки същия резултат аз разбрах, че проблема ми не е само в многото правила на iptables. Провокиран от въпроса на Vladsun за прекъсванията (благодаря за което) се заех да наблюдавам процесора с програмите top, htop и sar и с изненада открих, че при определено натоварване от четирите ядра започва да работи само едно на 100% като се сменя с друго на няколко секунди. Явно при силно натоварване ядрата нямат време да се разберат кое какво ще смята. Ратърсих се из google и попаднах на една статия от 2003 година в която един пич обясняваше, че когато асоциираш една лан карта само към едно ядро времето за отговор към ланката се увеличава. Тъй като имам един сокет и 4 физически ядра (нямам Hyper Threading)
Код
GeSHi (Bash):
  1. core2:~# lscpu
  2. Architecture:          x86_64
  3. CPU op-mode(s):        32-bit, 64-bit
  4. CPU(s):                4
  5. Thread(s) per core:    1
  6. Core(s) per socket:    4
  7. CPU socket(s):         1
  8. NUMA node(s):          1
  9. Vendor ID:             GenuineIntel
  10. CPU family:            6
  11. Model:                 15
  12. Stepping:              11
  13. CPU MHz:               2394.473
  14. Virtualization:        VT-x
  15. L1d cache:             32K
  16. L1i cache:             32K
  17. L2 cache:              4096K
  18.  
Асоциирах всяка една лан карта лъм отделно ядро:
Код
GeSHi (Bash):
  1. cat /proc/interrupts
  2.            CPU0       CPU1       CPU2       CPU3      
  3.  76: 2771150251 1012606526  962392960  943110592   PCI-MSI-edge      eth0
  4.  77: 1244924306 1301792799 2976287726 1227333165   PCI-MSI-edge      eth1
  5.  78:   75135051   92587862   75365891   74809000   PCI-MSI-edge      eth2
  6.  79:     401492     390144     397369     475879   PCI-MSI-edge      eth3
  7.  
По следния начин най натоварените портове eth0 ще се обработват от първото ядро на процесора а eth1 от третото.
Код
GeSHi (Bash):
  1. echo 1 > /proc/irq/76/smp_affinity #eth0
  2. echo 4 > /proc/irq/77/smp_affinity #eth1
  3. echo 2 > /proc/irq/78/smp_affinity #eth2
  4. echo 8 > /proc/irq/79/smp_affinity #eth3
  5.  
И за да стане още по ефективно програмите който работят на машината ги асоциирвам към второто(в случая 1) и четвъртото(в случая 3) ненатоварени ядра:
Код
GeSHi (Bash):
  1. taskset -cp 1,3 820350 #apache
  2. taskset -cp 1,3 1135433 #zebra
  3. taskset -cp 1,3 1135437 #bgpd
  4. taskset -cp 1,3 1323014 #squid
  5. taskset -cp 1,3 1476645 #dnsmasq
  6. taskset -cp 1,3 1666 #snmpd
  7. taskset -cp 1,3 1636 #ntp
  8. taskset -cp 1,3 3835254 #cron
  9.  

Така проблема с пинга окончателно е решен макар и първото и третото ядро които обработват натоварените портове да са на 60-70 % натоварване факт е, че не съм ги виждал досега на 100% но все пак до къде ли са възможностите. Не съм забравил за човъркането в BIOS и съм го планирал за края на тази седмица. По нова година трафика малко спадна но чаквам още довечера да има пик и да видим до къде сме я докарали с тия оптимизации :)

С най добри пожелания за новата година и благодарности на участниците в темата.
« Последна редакция: Jan 01, 2011, 18:59 от samiboy »
Активен

Подобни теми
Заглавие Започната от Отговора Прегледи Последна публикация
Iptables
Настройка на програми
mozly 1 4025 Последна публикация Dec 10, 2002, 23:48
от Vency
iptables
Настройка на програми
sunhater 3 3853 Последна публикация Apr 23, 2003, 15:02
от sunhater
iptables
Настройка на програми
dumdum 4 4470 Последна публикация Apr 30, 2003, 10:40
от dumdum
IPTABLES
Настройка на програми
achird 2 4549 Последна публикация May 20, 2003, 14:14
от achird
Ipmark и ipset едновременно
Хардуерни и софтуерни проблеми
VladSun 0 1003 Последна публикация Jul 27, 2006, 01:32
от VladSun