Linux за българи: Форуми

Здравейте, за да обясня точно какъв ми е проблема ще трябва да разкажа малко предистория.

Преди известно време конфигурирах една машина (Xeon X3430 + Supermicro) с около 100 потребителя които трябва да имат SNAT, DNAT и ограничение на скороста в двете посоки. Това решение го реализирах с iptables и tc:

GeSHi (Bash):
iptables -t nat -A POSTROUTING -s $ADDRESS -j SNAT --to $OUTADDRESS
iptables -t nat -A PREROUTING -d $OUTADDRESS -j DNAT --to $ADDRESS
tc qdisc del dev $DEV1 root
tc qdisc del dev $DEV1 handle ffff: ingress
tc qdisc add dev $DEV1 root handle 1 htb default 10
tc class add dev $DEV1 parent 1: classid 1: htb rate 1000Mbit
tc qdisc add dev $DEV1 handle ffff: ingress
echo tc class add dev $DEV1 parent 1: classid 1:$MARKUP htb rate $SPEEDIN burst $BURSTIN quantum 60000
echo tc qdisc add dev $DEV1 parent 1:$MARKUP sfq
echo tc filter add dev $DEV1 parent 1: protocol ip prio 1 u32 match ip dst $IPCLIENT classid 1:$MARKUP
echo tc filter add dev $DEV1 parent ffff: protocol ip prio 20 u32 match ip src $IPCLIENT police rate $SPEEDOUT burst $BURSTOUT action drop flowid :$MARKUP
 

Taka работеше доста добре но потребителите станаха около 400 и особено изходящия трафик започна да дава аномалии. Затова почетох малко и промених конфигурацията като този път включих MARK с iptables.

GeSHi (Bash):
iptables -t nat -A POSTROUTING -s $ADDRESS -j SNAT --to $OUTADDRESS
iptables -t nat -A PREROUTING -d $OUTADDRESS -j DNAT --to $ADDRESS
tc qdisc del dev $DEV1 root
tc qdisc add dev $DEV1 root handle 1: htb default 10
tc qdisc del dev $DEV2 root
tc qdisc add dev $DEV2 root handle 1: htb default 10
iptables -t mangle -A POSTROUTING -d $IPCLIENT -j MARK --set-mark 0x$MARKUP
tc class add dev $DEV1 parent 1: classid 1:$MARKUP htb rate $SPEEDIN ceil $CEIL burst $BURSTIN quantum 60000
tc filter add dev $DEV1 parent 1: protocol ip prio 1 handle 0x$MARKUP fw classid 1:$MARKUP
iptables -t mangle -A PREROUTING -s $IPCLIENT -j MARK --set-mark 0x$MARKUP1
tc class add dev $DEV2 parent 1: classid 1:$MARKUP1 htb rate $SPEEDOUT ceil $CEIL burst $BURSTOUT quantum 60000
tc filter add dev $DEV2 parent 1: protocol ip prio 1 handle 0x$MARKUP1 fw classid 1:$MARKUP1
 

Този пък вариант работеше добре до 600-ния потребител и реших да съкратя малко правила този път като използвам CLASSIFY в iptables като премахна filter в tc.

GeSHi (Bash):
iptables -t nat -A POSTROUTING -s $ADDRESS -j SNAT --to $OUTADDRESS
iptables -t nat -A PREROUTING -d $OUTADDRESS -j DNAT --to $ADDRESS
tc qdisc del dev $DEV1 root
tc qdisc add dev $DEV1 root handle 1: htb default 10
tc qdisc del dev $DEV2 root
tc qdisc add dev $DEV2 root handle 1: htb default 10
iptables -t mangle -A FORWARD -d $IPCLIENT -j CLASSIFY --set-class 1:$MARKUP
tc class add dev $DEV1 parent 1: classid 1:$MARKUP htb rate $SPEEDIN ceil $CEIL burst $BURSTIN quantum 60000
iptables -t mangle -A FORWARD -s $IPCLIENT -j CLASSIFY --set-class 1:$MARKUP1
tc class add dev $DEV2 parent 1: classid 1:$MARKUP1 htb rate $SPEEDOUT ceil $CEIL burst $BURSTOUT quantum 60000
 

CLASSIFY помогна малко, но сега потребителите са 700 и се появи проблем който се състои в повишено латенси на пинга в натоварен момент като 350-400Mbits трафик например. Загуби почти няма но е явно, че пак трябва да се прави някаква оптимизация на трафик контрола. Реших да пробвам FLATTC обаче при мен е нереализуемо по простата причина, че аз имам 9 B class мрежи:
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
в които има около 40 C class в който имам потребители като:
10.121.5.4/24
10.123.23.12/24
10.125.3.2/24
10.129.8.13/24 и така нататък .....
Това защо е така мисля, че няма нужда да обяснявам да приемем, че е по исторически причини и няма възможност за промяна.
И така, компилирах ipset, поиграх си малко с него разбрах как работи. После компилирах xtables-addons-modules (това e готов пакет p-o-m в Debian) но тук модула на IPMARK гръмна и след неравна борба разбрах, че версията на iptables ми е стара. Така инсталирах версия iptables v1.4.10 и модулите на p-o-m тръгнаха но пък интерфейса на ipset се счупи защото явно не съвпада с версията на iptables но това не е темата сега. Въпроса е за IPMARK. Принципно не съм човек който се дава лесно но сагата IPMARK ми дойде в повече. В документацията на Netfilter има 5 реда от който нищо не отбирам а в Интернет има толкова малко и все грешни или под въпрос примери, че не стигнах до никъде. Разглеждах FLATTC но там примерите са за C class мрежи а и така и не разбрах and и or маските всъщност какво правят и как се връзват с filter.

Ако някой е наясно и може да помогне ще съм благодарен да ми даде само пример или насока как всъщност работи IPMARK и дали има реализация в моя случай с тези 9 B class мрежи ?

Само да те попитам: как определи кои мрежи са клас B, и кои клас C ? Ти изобщо нямаш клас B или C, а само A.

Защото мрежите 10.xxx.xxx.xxx са от клас A. При теб само маската е различна (/16 или /24), но класовете на всички са все A.


Class A comprises networks 1.0.0.0 through 127.0.0.0. The network number is contained in the first octet. This class provides for a 24-bit host part, allowing roughly 1.6 million hosts per network.

Class B contains networks 128.0.0.0 through 191.255.0.0; the network number is in the first two octets. This class allows for 16,320 nets with 65,024 hosts each.

Class C networks range from 192.0.0.0 through 223.255.255.0, with the network number contained in the first three octets. This class allows for nearly 2 million networks with up to 254 hosts.

Classes D, E, and F addresses falling into the range of 224.0.0.0 through 254.0.0.0 are either experimental or are reserved for special purpose use and don't specify any network. IP Multicast, which is a service that allows material to be transmitted to many points on an internet at one time, has been assigned addresses from within this range.

П.С. И за 700 клиента пак през същия този гейтуей, не е ли много ? Дали се оправя сървъра ти нормално с този баз-бая голям трафик ? Защото 700 клиента са сериозно нещо. Дали успява гейта да смята всичките тия трафици ? В пъти се е увеличило всичко, а като знам лапетиите с тия торенти и с по много едновременни конекции. Нормално е да лагва повече. Дали не трябва да сложите още машини за гейтове.

FlatTC e "настроен" да ползва /24 мрежи, но нищо не ти пречи да разгледаш сорса и да го промениш според твоите нужди.

Разгледай:
http://www.linux-bg.org/cgi-bin/y/index.pl?id=advices&key=380752598&page=article
и
http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=386924398

И за 700 клиента пак през същия този гейтуей, не е ли много ? Дали се оправя сървъра ти нормално с този баз-бая голям трафик ? Защото 700 клиента са сериозно нещо. Дали успява гейта да смята всичките тия трафици ? В пъти се е увеличило всичко, а като знам лапетиите с тия торенти и с по много едновременни конекции. Нормално е да лагва повече. Дали не трябва да сложите още машини за гейтове.

Според мен не е толкова проблем броят на потребителите в случая (според мен е твърде малък), колкото наличието на SNAT/DNAT - товари с connection-tracking-a.

Освен това 700 потребителя зад едно ИП са твърде много, ако няма ограничение на броя на връзките (connlimit).

Добре ..., явно попаднах на подходящия човек.
SNAT и DNAT не са зад едно ип, всяко private ip се транслира с public. Под исторически причини имах впредвид, че в началото беше една публична 93.155.130.0/24 мрежа с няколко 10.121.x.x/24 частни които се намират физически на отдалечени места и не са заети изцяло от клиенти. Така сглобих един баш скрипт /etc/init.d/netscript

GeSHi (Bash):
ADDRESS=$(grep -v \# /etc/ipclient | cut -d":" -f1);
for ADDRESS in $ADDRESS; do
OUTADDRESS=$(grep -v \# /etc/ipclient | grep -w -n $ADDRESS | cut -d":" -f3)
iptables -t nat -A POSTROUTING -s $ADDRESS -j SNAT --to $OUTADDRESS
iptables -t nat -A PREROUTING -d $OUTADDRESS -j DNAT --to $ADDRESS
done;
 
DEV1=vlan100
DEV2=vlan149
SPEEDIN=30Mbit
SPEEDOUT=5Mbit
SPEEDIN2=45Mbit
SPEEDOUT2=10Mbit
CEILIN=40Mbit
CEILOUT=5Mbit
BURSTIN=10Mbit
BURSTOUT=2Mbit
tc qdisc del dev $DEV1 root
tc qdisc add dev $DEV1 root handle 1: htb default 10
tc class add dev $DEV1 parent 1: classid 1:1 htb rate $CEILIN
tc qdisc del dev $DEV2 root
tc qdisc add dev $DEV2 root handle 1: htb default 10
tc class add dev $DEV2 parent 1: classid 1:1 htb rate $CEILOUT
 
IPCLIENT=`grep -v \# /etc/ipclient | grep speed1 | cut -d":" -f1`;
for IPCLIENT in $IPCLIENT; do
MARK=$(grep -v \# /etc/ipclient | grep -w -n $IPCLIENT | cut -d":" -f1)
MARKUP=$(($MARK + 2000))
MARKUP1=$(($MARK + 4000))
iptables -t mangle -A FORWARD -d $IPCLIENT -j CLASSIFY --set-class 1:$MARKUP
tc class add dev $DEV1 parent 1:1 classid 1:$MARKUP htb rate $SPEEDIN ceil $CEILIN burst $BURSTIN quantum 60000
tc qdisc add dev $DEV1 parent 1:$MARKUP handle $MARKUP: sfq perturb 10
iptables -t mangle -A FORWARD -s $IPCLIENT -j CLASSIFY --set-class 1:$MARKUP1
tc class add dev $DEV2 parent 1:1 classid 1:$MARKUP1 htb rate $SPEEDOUT ceil $CEILOUT burst $BURSTOUT quantum 60000
tc qdisc add dev $DEV2 parent 1:$MARKUP1 handle $MARKUP1: sfq perturb 10
done;
 

който от един текстов /etc/ipclient файл взима даните:

GeSHi (Bash):
# privateIP:publicIP:speed
10.127.10.2:93.155.130.41:speed1
10.122.2.9:93.155.130.42:speed1
10.123.4.6:93.155.130.43:speed1
10.127.1.5:93.155.130.44:speed2
10.126.9.13:93.155.130.45:speed1
10.125.21.5:93.155.130.46:speed2
10.126.20.13:93.155.130.47:speed1
 

С течение на времето публините мрежи станаха 4 и частните ип адреси нараснаха до 700. Знам, че звучи странно защо досега е съм махнал NAT-a и затова ще обясня. От една страна частните ип адреси са на отдалечени физически места тоест рутирани през един а някой и през два хопа, за да премахна NAT трябва да нарежа маските на публичните адреси и това ще е ад а също и факта, че една част от клиентитие са магазини, нон стопи или обекти за наблюдения с асоциирани вече ип адреси дадени на клиентитие и така нататък. А що се тонася до контрака съм приложил това решение:

GeSHi (Bash):
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 20000000 > /proc/sys/net/nf_conntrack_max
echo 2048 > /proc/sys/net/netfilter/nf_conntrack_expect_max
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/default/arp_filter
echo 1 > /proc/sys/net/ipv4/conf/all/promote_secondaries
echo 0 > /proc/sys/net/ipv4/conf/default/accept_source_route
echo 0 > /proc/sys/kernel/sysrq
echo 1 > /proc/sys/kernel/core_uses_pid
echo 4194303 > /proc/sys/kernel/pid_max
echo 20000000 > /proc/sys/net/core/rmem_max
echo 20000000 > /proc/sys/net/core/wmem_max
echo 4096 87380 20000000 > /proc/sys/net/ipv4/tcp_rmem
echo 4096 87380 20000000 > /proc/sys/net/ipv4/tcp_wmem
echo 1 > /proc/sys/net/ipv4/tcp_no_metrics_save
echo 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal
echo 0 > /proc/sys/net/ipv4/tcp_syncookies
echo 5 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent
echo 5 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent2
echo 5 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_recv
echo 86400 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
echo 10 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
echo 10 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
echo 10 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
echo 10 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack
echo 10 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
echo 10 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
echo 180 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream
echo 10 > /proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout
echo 600 > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
 

Проблема с пинга се появява вечер когато трафика нарасне до 350Mbits или най вече когато се изравни и в двете посоки. Изчистя ли с qdisc del dev и проблема ичезва. Нека да мина направо на въпроса. Както вече си забелязал аз не деля трафика на БГ и ИНТ защото международния канал тук е широк. Прегледал съм това което си написал но не мога да разбера как работи IPMARK и по точно за какво са маските or и and. Ако може да ми помогнеш с един пример с няколко реда:

как може да се направи марк на мрежа 10.0.0.0/8 dst и ограничаване на ип адреси 10.125.3.2 и 10.126.5.5 например ?

Предварително благодаря.

Прегледал съм това което си написал но не мога да разбера как работи IPMARK и по точно за какво са маските or и and.

IPMARK премахва нуждата от tc филтри - създаваш един единствен "празен" филтър за всеки интерфейс:

GeSHi (Bash):
tc filter add dev eth0 parent 1:0 protocol ip prio 1 fw

Когато филтърът е "празен fw", то TC гледа MARK полето на пакетите и ги насочва къ съответните класове:

IPMARK: маркира пакетите, като за стойността на маркера използва стойността на самото IP;
IPMARK: приема като параметри 3 неща - IP-то по което ще маркираме и 2 параметъра за управление на получения MARK;
IPMARK: IP-то по което ше маркираме се взима директно от пакета и в зависимост от това дали --addr параметъра е src или dst, се взима съответно src IP-то или dst IP-то;
IPMARK: 2-та параметъра за управление на получения MARK реализират побитово И и ИЛИ върху стойността на IP адреса;

Ако може да ми помогнеш с един пример с няколко реда:

как може да се направи марк на мрежа 10.0.0.0/8 dst и ограничаване на ип адреси 10.125.3.2 и 10.126.5.5 например ?

не ми става много ясно какво точно искаш - явно имаш клиенти, които не са с един ИП адрес, а цяла (или част) субмрежа.

Тъй като нямаш разделение на трафика, то най-лесно ще ти е да направиш глобално маркиране:

GeSHi (Bash):
iptables -t mangle -A FORWARD -d 10.0.0.0/16 -j IPMARK --addr=dst --and-mask=0x0000FFFF --or-mask=0x00010000

С един единствен ред маркираш целия download трафик, но за /16 субмрежа, тъй като не трябва да "влизаме" в major частта на МАРК полето, което от своя страна определя major номера на tc класа.

т.е взимаш последните 4 шестнайсетични числа от ИП адреса (който в 16 вид e FF.FF.FF.FF) и те стават де факто MARK полето на пакетите.

IPCLASSIFY е съшото като IPMARK - аналогията е CLASSIFY-MARK. Така отпада и "празния" филтър и остава свободата да ползваш MARK полето за собствени нужди.

Как разпределяш прекъсванията?

SNAT и DNAT не са зад едно ип, всяко private ip се транслира с public.

Може би ще ти е интересно да видиш NETMAP target-a.

Как разпределяш прекъсванията?

Хех, това ми беше следващият въпрос :)

Предполагам за прекъсванията и колко се товари машината това е някаква информация.
http://data.itservice-bg.net/screenshot/core2-htop-bmon.png
http://data.itservice-bg.net/screenshot/core2-top-interupts.png

IPMAP е красиво нещо но е огледало на две мрежи. Аз имам 4 публични/24 и доста частни мрежи от рода на 10.121.x.x/24, 10.122.x.x/24, 10.125.x.x/24, 10.125.1.x/24, 10.125.2.x/24, 10.125.3.x/24 и така нататък иначе идеята "кърти".

А за IPMARK нека да опитаме така. Имаш тези ип адреси: http://data.itservice-bg.net/documents/ip.txt ,какви са правилата които ти би използвал ?

След като не може с 10.0.0.0/8 ще го направя 9 правила с 10.121.0.0/16, 10.122.0.0/16, 10.123.0.0/16
..................
На мястото на въпросителните какви стойности да задам и като имам две тарифи съответно две скорости как мога да разделя адресите  ::)

GeSHi (Bash):
iptables -t mangle -A FORWARD -d 10.121.0.0/16 -j IPMARK --addr=dst --and-mask=0x0000FFFF --or-mask=0x00000000
 
tc qdisc add dev $DEV1 root handle 1: htb default 10
tc class add dev $DEV1 parent 1:10 classid $?? htb rate 10Mbit ceil 1000Mbit prio 5
tc qdisc add dev $DEV1 parent 1:0$?? handle $?? sfq perturb 10
tc filter add dev $DEV1 parent 1: protocol ip prio 1 fw
 

SNAT/DNAT на всяко ИП е голям товар за машината ти - имаш адски много правила (мин. 2 х броя на ИП-тата).  Замени го с NETMAP:

GeSHi (Bash):
iptables -t mangle -A PREROUTING -i eth1 -s 10.121.x.x/24 -j NETMAP --to 93.155.130.0/24
iptables -t mangle -A PREROUTING -i eth0 -s 93.155.130.0/24 -j NETMAP --to  10.121.x.x/24

и.т.н.

Две правила за всяка /24 мрежа! И всъщност ще направиш "пълен" ДМЗ (със SNAT/DNAT трудно ще го направиш). А най-добре е да преминеш към маршрутизиране на публични ИП адреси към клиентите за да отпадне и connection tracking-a.

А за IPMARK нека да опитаме така. Имаш тези ип адреси: http://data.itservice-bg.net/documents/ip.txt ,какви са правилата които ти би използвал ?

След като не може с 10.0.0.0/8 ще го направя 9 правила с 10.121.0.0/16, 10.122.0.0/16, 10.123.0.0/16
..................
На мястото на въпросителните какви стойности да задам и като имам две тарифи съответно две скорости как мога да разделя адресите  ::)

Код

GeSHi (Bash):
iptables -t mangle -A FORWARD -d 10.121.0.0/16 -j IPMARK --addr=dst --and-mask=0x0000FFFF --or-mask=0x00000000
 
tc qdisc add dev $DEV1 root handle 1: htb default 10
tc class add dev $DEV1 parent 1:10 classid $?? htb rate 10Mbit ceil 1000Mbit prio 5
tc qdisc add dev $DEV1 parent 1:0$?? handle $?? sfq perturb 10
tc filter add dev $DEV1 parent 1: protocol ip prio 1 fw
 

Можеш да го направиш с няколко правила, но трябва да използваш --or-mask различна от нула за да не навлезеш в старшата тетрада:

GeSHi (Bash):
iptables -t mangle -A FORWARD -d 10.121.5.0/24 -j IPMARK --addr=dst --and-mask=0x0000FF --or-mask=0x00010100
iptables -t mangle -A FORWARD -d 10.122.8.0/24 -j IPMARK --addr=dst --and-mask=0x0000FF --or-mask=0x00010200
iptables -t mangle -A FORWARD -d 10.19.2.0/24 -j IPMARK --addr=dst --and-mask=0x0000FF --or-mask=0x00010300
 

и т.н.
Т.е. тъй като не използваш цялата 10.0.0.0/8 мрежа, делиш я на /24 мрежи (кото и в момента правиш) и я "номерираш" с --or-mask-ата. Имай предвид, че това е шестнайсетичен код, а не десетичен. Видът й е винаги 0001ХХ00 в твоя случай.

Така ще получиш:

GeSHi (Bash):
tc class add dev $DEV1 parent 1:10 classid XX{IP}  htb rate 10Mbit ceil 1000Mbit prio 5
tc qdisc add dev $DEV1 parent 1: handle XX{IP} sfq perturb 10

където XX{IP} е номерът от --or-mask-ата (XX) и последната група от IP-то ({IP}). Всичко пак в шестнайсетичен код!

Цялата сметка е всъщност набор от побитови операции - първо побитово И върху ИП адреса, след това побитово ИЛИ върху резултата от предходната операция. Съветвам те да вникнеш по-дълбоко в това. В статиите по-горе доста обширно съм обяснявал.

Здрасти !
Не подлагам на съмнение помощта на Владо, и съм сигурен, че много може да се научи от практическият му опит, но за да се улеснят нещата нека питащия да даде малко повече инфо за точния модел дъно !
Т.е. имам идея за нещо и съмнението ми е в чип-а 82574L.
Ако се окажа прав за ситуацията, знам решение и ще го предложа.
В кръга на шегата, решението ще го кажа само и единствено срещу една бира ;)

Весели празници !

Така, поизясниха се нещата с IPMARK. Незнам дали ще мога да го приложа (разбира се ще има тест) но поне разбрах как работи. Трябва да преосмисля основно конфигурацията макар, че топологията на мрежата не мога да я пипам, остава тотална оптимизация на правила (или групиране на такива) с цел пестене на ресурси. От сега усещам как ме очакват забавни моменти по празниците тип проби-грешки. По принцип както казах вече канала тук е широк за потреблението на клиентите и няма нужда да се цепи всеки байт, спра ли qdisc в пиков час трафика стига до 600Mbit без загуби на пакети с пуснат SNAT и DNAT което ясно показва, че машината може да държи трафик и има нужда от оптимизиране на конфигурацията и. Първтото нещо за което си мисля е, че DNAT не е нужен на всички, може да се направи списък на клиентитие само на които и трябва макар и да не знам това дали ще олекоти положението (тази операция мога да я направя чак след нова година). Второто което ми идва на ум е трябва ли да маркирам download трафика, ако използвам u32 класификаторите вместо CLASSIFY дали ще олекоти положението. В краен случаи мога да групирам download трафика в цели мрежи защото така и така върви на половината на uploada (все пак това е в случаи, че не намеря правилното решение с IPMARK)

Бирата ти я пращам още сега  [_]3 също в кръга на шегата  :D Ще е интересно ако споделиш все пак какво имаш впредвид.

С CLASSIFY/u32 само ще пренесеш филтрирането в iptables/tc - няма много смисъл.

Можеш да погледнеш http://lartc.org/howto/lartc.adv-filter.hashing.html
Преди няколко години го разглеждах, но май имах проблем със SNAT-а ...

Също така Patrick McHardy е имплeментирал tc flow classifier, провокиран от наличието на IPMARK/IPCLASSIFY -
http://www.mail-archive.com/netdev@vger.kernel.org/msg60638.html

http://nfws.edenwall.com/en/?p=92

Patrick MCHardy, NFtables
Posted on September 30, 2008 by regit

Iptables and Netfilter problems (bashing iptables)
- Full dump during ruleset update. Userspace is very primitive. Extentions build a blob which is passed to the core. There is no optimisation
- Very little abstraction: UDP and TCP ports for example don’t share port matching code
- Inconsistencies among matches: negation, range, prefixes support defer.
- Iptables parsing code is not in the core and it introduces inconsistencies in command line
- One target per rule: It requires rule duplication and duplicated changes (ex: LOG + DROP, MARK + ACCEPT)
- Static target module parametrization: option of the target expands to constant. You can not use flexible settings of the variable. It leads to build specific modules such as IPMARK, IPCLASSIFY and could lead to a TCPPORTCONNMARK module

Трябва да преосмисля основно конфигурацията макар, че топологията на мрежата не мога да я пипам, остава тотална оптимизация на правила (или групиране на такива) с цел пестене на ресурси. От сега усещам как ме очакват забавни моменти по празниците тип проби-грешки. По принцип както казах вече канала тук е широк за потреблението на клиентите и няма нужда да се цепи всеки байт, спра ли qdisc в пиков час трафика стига до 600Mbit без загуби на пакети с пуснат SNAT и DNAT което ясно показва, че машината може да държи трафик и има нужда от оптимизиране на конфигурацията и.

Честно казано според мен оптимизацията на правила няма да реши проблема ти, а ще го измести на по-късен етап. Така само закърпваш ситуацията.
700 потребителя са си доволно количество, за да ги подлагаш на адресна транслация 1:1 при днешните скорости.
След време ще станат 800, след това 900, на всеки 100 ли ще търсиш оптимизация в iptables/tc или ще подменяш с по-мощен хардуер.
Когато стане неизбежно, вече ще имаш повече потребители, с които ще трябва да се съобразяваш и ще ти усложнят схемата още повече.
 
По-добре обмисляй вариант на етапи да преминеш към "чисто" маршрутизиране. Не знам каква е топологията ти, но при всички случай ще има начин да сегментираш на L2, така че да те устройва схемата.
Ако трябва подлагай временно на NAT само мрежи, които са ти през nexthop навътре, докато решиш и при тях как ще процедираш.

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

Преди да започнеш с глобални промени по мрежата, както ти препоръчаха (аз също съм на мнение, че се нуждае от реорганизация), и чистене на правила за трафик контрол след това(това ще изцеди хардуера до максимум), ти предлагам да направиш следните неща, а дали и как решаваш ти. Принципно ми трябваше точният модел на дъното за да съм конкретен, но предполагам че си с 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 споделени линии. ;)
Успех !

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

Моят опит с доста по-слаба (поне "2 пъти") машина е:
- 2500+ потребителя;
- директно маршрутизиране на публичните ИП адреси към клиента;
- 400+Мбит up/ 400+Mbit down;
- ограничаване на трафика по 4 направления (BG/международен - upload/download);
- прекъсванията на всеки интерфейс на отделно ядро.

cpu load - макс. 60%

Аз още от самото начало се бях приготвил за публични ип адреси. Затова вдигнах 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 много ми хареса като идея, но пак, документацията я няма никаква ...

Ако ще пробваш с IPMARK, по-добре пробвай с IPCLASSIFY - нямa да има нужда от tc филтри и "гледане" на MARK полето.

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

Простете ми невежеството но този код как може да се преобразува в bash ?

GeSHi (Perl):
#!/usr/bin/perl
 
($ip) = @ARGV;
 $id = sprintf("%X", $ip + 0x100);
$class = "tc class add dev vlan100 parent 1:10 classid 1:0".$id." htb rate 30Mbit ceil 1000Mbit burst 1Mbit";
$qdisc = "tc qdisc add dev vlan100 parent 1:0".$id." handle 0".$id." sfq perturb 10 ";
 
`$class`;
`$qdisc`;
 

Явно не съм чак толкова добър (да не казвам хич) на bash - доста време ми отне :)

GeSHi (Bash):
#/bin/bash
 
offset=$(printf "%d" 0x100)
id=$(printf "%x" $(($offset+$1)))
 
tc class add dev vlan100 parent 1:10 classid 1:0${id} htb rate 30Mbit ceil 1000Mbit burst 1Mbit
tc qdisc add dev vlan100 parent 1:0${id} handle 0${id} sfq perturb 10

Ами..., аз още съм на ниво IPMARK (евентуално за в бъдеще IPCLASSIFY) но пак се нацелих в първоначалната греда - многото подмрежи, тоест нестандартната топология която ако не беше такава отдавна да съм инсталирал това FLATC и да съм забравил какво съм правил някога ...

Реших да сглобя примерен скрипт с IPMARK за мрежи /24 и се роди това:

GeSHi (Bash):
#!/bin/bash
 
iptables -A FORWARD -t mangle -d 10.125.3.0/24 -j IPMARK --addr=dst --and-mask=0xff --or-mask=0x10100
 
tc qdisc del dev vlan100 root
tc qdisc add dev vlan100 root handle 1 htb default 1
tc filter add dev vlan100 parent 1:0 protocol ip prio 1 fw
 
IP=`grep -v \# /etc/ipclient | grep speed1 | grep 10.125.3. | cut -d":" -f1 | cut -d"." -f4`;
for IP in $IP; do
offset=$(printf "%d" 0x100)
id=$(printf "%x" $(($offset+$IP)))
tc class add dev vlan100 parent 1:10 classid 1:0${id} htb rate 10Mbit ceil 1000Mbit burst 1Mbit
tc qdisc add dev vlan100 parent 1:0${id} handle 0${id} sfq perturb 10
done;
 

В сътворението по горе променливата 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):
#!/bin/bash
 
iptables -t mangle -A FORWARD -d 10.125.0.0/16 -j IPMARK --addr=dst --and-mask=0xffff --or-mask=0x10000
 
tc qdisc del dev vlan100 root
tc qdisc add dev vlan100 root handle 1 htb default 1
tc filter add dev vlan100 parent 1: protocol ip prio 1 fw
 
offset=$(printf "%d" 0x00)
id1=$(printf "%x" $(($offset+$1)))
id2=$(printf "%02x" $2)
tc class add dev vlan100 parent 1:1 classid 1:${id1}${id2} htb rate 10Mbit ceil 1000Mbit burst 1Mbit
tc qdisc add dev vlan100 parent 1:${id1}${id2} handle ${id1}${id2} sfq perturb 10
 

И тази ситуация се оказа работеща но само за мрежа 10.125.0.0/16 защото явно не ми стига маската за повече или поне аз така го разбирам. Какво ли не правих, не намерих вариант да добавя другите мрежи. Та въпроса ми е след като имам марк и работещи tc правила на мрежа 10.125.0.0/16 в горния вариант възможно ли е по някакъв начин да направя същото и за останалите мрежи ? Все пак блазни ме варианта с мрежи /16 защото на 9 такива в двете посоки правят 18 марка което със сигурност ще олекне товара на желязото.

139 /24 мрежи?!?
139*254 = 35306 хоста?!?

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

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

Но не съм сигурен дали ще стане и доколко ще те устройва разпределението на скоростите - първо ще се разпределят по мрежи и след това по ИП-та.

Проблема поне засега е решен, може би не толкова елегантно но резултата е повече от добър и целта е постигната.

След като прокарах всички варианти с IPMARK и разбрах, че с моята мулти нефункционална конфигурация на мрежата нещата няма да тръгнат защото ако ползвам маска /24 мога да контролирам 99 мрежи а аз имам 139 а с маска /16 само една а аз имам 9 почти се бях отказал когато ми светна една идея. Тъй като аз имам 139 частни мрежи с маска /24 в които има 700 ип адреса които пък са твърдо зад 4 публични мрежи /24 SNAT не мога ли да огранича трафика на публичните адреси. В предишен мой пост бях показал, че информацията се грепва от текствов файл със синтаксис:

GeSHi (Bash):
lan_ip:wan_ip:speed1 # платил клиент на по ниска тарифа
lan_ip:wan_ip:speed2 # платил клиент на по висока тарифа
#lan_ip:wan_ip:spee2 # неплатил клиент (скрипта го пропуска и не създава за него правила)
 

След като грепвам локалните ип адреси преди първото двуеточие няма да има проблем да правя същото и след второто но този път с публичните ип адреси. И ако нещата проработят щях да спестя само в едната посока в случая 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):
tc qdisc del dev $DEV1 root
tc qdisc add dev $DEV1 root handle 1: htb default 10
tc filter add dev $DEV1 parent 1:0 protocol ip prio 1 fw
 
NET=93.155.130.
ID=1
iptables -A PREROUTING -t mangle -d ${NET}0/24 -j IPMARK --addr=dst --and-mask=0xff --or-mask=0x10${ID}00
IP=$(grep -v \# /etc/ipclient | grep speed1 | cut -d":" -f2 | grep ${NET} | cut -d"." -f4  | sort -nu)
for IP in $IP; do
OFFSET=$(printf "%d" 0x${ID}00)
MARK=$(printf "%x" $(($OFFSET+$IP)))
tc class add dev $DEV1 parent 1:1 classid 1:0${MARK} htb rate $SPEEDIN ceil $CEIL burst $BURSTIN
tc qdisc add dev $DEV1 parent 1:0${MARK} handle 0${MARK}: sfq perturb 10
done;
 

Частните адреси - upload в който имаме 700 CLASSIFY, 700 tc class

GeSHi (Bash):
tc qdisc del dev $DEV2 root
tc qdisc add dev $DEV2 root handle 1: htb default 10
 
ADDRESS=`grep -v \# /etc/ipclient | grep speed1 | cut -d":" -f1`;
for LANIP in $ADDRESS; do
MARK=$(grep -v \# /etc/ipclient | grep -w -n $LANIP | cut -d":" -f1)
MARKUP=$(($MARK + 1000))
iptables -t mangle -A FORWARD -s $LANIP -j CLASSIFY --set-class 1:$MARKUP
tc class add dev $DEV2 parent 1:1 classid 1:$MARKUP htb rate $SPEEDOUT burst $BURSTOUT
tc qdisc add dev $DEV2 parent 1:$MARKUP handle $MARKUP: sfq perturb 10
done;
 

Такааа, обаче радоста ми беше кратка защото на третата вечер пак в пиков час 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):
core2:~# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
CPU(s):                4
Thread(s) per core:    1
Core(s) per socket:    4
CPU socket(s):         1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 15
Stepping:              11
CPU MHz:               2394.473
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              4096K
 

Асоциирах всяка една лан карта лъм отделно ядро:

GeSHi (Bash):
cat /proc/interrupts 
            CPU0       CPU1       CPU2       CPU3       
  76: 2771150251 1012606526  962392960  943110592   PCI-MSI-edge      eth0
  77: 1244924306 1301792799 2976287726 1227333165   PCI-MSI-edge      eth1
  78:   75135051   92587862   75365891   74809000   PCI-MSI-edge      eth2
  79:     401492     390144     397369     475879   PCI-MSI-edge      eth3
 

По следния начин най натоварените портове eth0 ще се обработват от първото ядро на процесора а eth1 от третото.

GeSHi (Bash):
echo 1 > /proc/irq/76/smp_affinity #eth0
echo 4 > /proc/irq/77/smp_affinity #eth1
echo 2 > /proc/irq/78/smp_affinity #eth2
echo 8 > /proc/irq/79/smp_affinity #eth3
 

И за да стане още по ефективно програмите който работят на машината ги асоциирвам към второто(в случая 1) и четвъртото(в случая 3) ненатоварени ядра:

GeSHi (Bash):
taskset -cp 1,3 820350 #apache
taskset -cp 1,3 1135433 #zebra
taskset -cp 1,3 1135437 #bgpd
taskset -cp 1,3 1323014 #squid
taskset -cp 1,3 1476645 #dnsmasq
taskset -cp 1,3 1666 #snmpd
taskset -cp 1,3 1636 #ntp
taskset -cp 1,3 3835254 #cron
 

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

С най добри пожелания за новата година и благодарности на участниците в темата.