tc, htb и проблема с ifb

[disappointed]

ppp99 аплинк.

 

tc qdisc add dev ppp99 ingress

 

tc filter add dev ppp99 parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0

 

Action 4 device ifb0 ifindex 1130

RTNETLINK answers: Operation not supported

We have an error talking to the kernel

 

Linux gw1.oborona.net 2.6.21.7

 

Чем лечить?

[nuclearcat]

Граблей целое море с этим mirred.

В ядре CONFIG_NET_ACT_MIRRED включен?

[disappointed]

модулем он,

 

[root@gw1 sched]# modprobe act_mirred
FATAL: Error inserting act_mirred (/lib/modules/2.6.21.7/kernel/net/sched/act_mirred.ko): Unknown symbol in module, or unknown parameter (see dmesg)

 

dmesg

act_mirred: Unknown symbol tcf_hash_check
act_mirred: Unknown symbol tcf_hash_create
act_mirred: Unknown symbol tcf_unregister_action
act_mirred: Unknown symbol tcf_hash_insert
act_mirred: Unknown symbol tcf_hash_search
act_mirred: Unknown symbol tcf_register_action
act_mirred: Unknown symbol tcf_generic_walker
act_mirred: Unknown symbol tcf_hash_destroy
act_mirred: Unknown symbol tcf_hash_check
act_mirred: Unknown symbol tcf_hash_create
act_mirred: Unknown symbol tcf_unregister_action
act_mirred: Unknown symbol tcf_hash_insert
act_mirred: Unknown symbol tcf_hash_search
act_mirred: Unknown symbol tcf_register_action
act_mirred: Unknown symbol tcf_generic_walker
act_mirred: Unknown symbol tcf_hash_destroy

 

Буду ковырять ядро.

[disappointed]

Проблему убрал, фильтр ставится, только не вижу перенаправления на ifb

mirred egress redirect dev ifb0 фактически не работает.

[nuclearcat]

у меня выглядит так

$TC filter add dev $2 parent ffff: protocol ip prio 10 u32 \

match u32 0 0 flowid 1:1 \

action mirred egress redirect dev ifb0

 

(Убрал ipt action MARK)

 

Я надеюсь ifconfig ifb0 up сделан?

 

Смотрим статистику

Интересует подобное rule hit 3 success 3

 

Xpernet ~ # tc -s -d filter show dev ppp0 parent ffff:

filter protocol ip pref 5 u32

filter protocol ip pref 5 u32 fh 800: ht divisor 1

filter protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 (rule hit 3 success 0)

match 02020266/ffffffff at 16 (success 0 )

filter protocol ip pref 5 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:1 (rule hit 3 success 0)

match 02020269/ffffffff at 16 (success 0 )

filter protocol ip pref 5 u32 fh 800::802 order 2050 key ht 800 bkt 0 flowid 1:1 (rule hit 3 success 0)

match 0202026a/ffffffff at 16 (success 0 )

filter protocol ip pref 5 u32 fh 800::803 order 2051 key ht 800 bkt 0 flowid 1:1 (rule hit 3 success 0)

match c2929918/ffffffff at 16 (success 0 )

filter protocol ip pref 5 u32 fh 800::804 order 2052 key ht 800 bkt 0 flowid 1:1 (rule hit 3 success 0)

match c292991a/ffffffff at 16 (success 0 )

filter protocol ip pref 10 u32

filter protocol ip pref 10 u32 fh 801: ht divisor 1

filter protocol ip pref 10 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:1 (rule hit 3 success 3)

match 00000000/00000000 at 0 (success 3 )

action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING

target MARK set 0x64

index 11562 ref 1 bind 1 installed 2635 sec used 2234 sec

Action statistics:

Sent 228 bytes 3 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

 

action order 2: mirred (Egress Redirect to device ifb0) stolen

index 9783 ref 1 bind 1 installed 2635 sec used 2234 sec

Action statistics:

Sent 228 bytes 3 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

[disappointed]

Ага заворачивается, разобрался.

Теперь бы живой пример, не могу ставить эксперименты на машине в продакшне.

У нас есть аплинк пока это ppp, будет eth.

Я помечу в iptables помеговых и анлимщиков разными MARK, ну или можно отфильтровать их по адресам, разные подсети на framed_ip.

 

Нужно дать помеговым пользователям максимальный приоритет и максимально 75% полосы в пике от rate-а аплинка,

25 оставшихся процентов нужно гарантировать сумарно всем анлимщикам, ну и вешать на каждый ppp анлимщика rate его тарифа.

 

Не могу найти нормальное описание такой схемы, всё не то.

 

Сейчас просто ставится tbf на клиентские ppp.

Edited December 27, 2007 by disappointed

[nuclearcat]

#Заворачиваем входящий траффик eth1 на ifb0
$TC qdisc del dev eth1 ingress 1>/dev/null 2>/dev/null
$TC qdisc add dev eth1 ingress
${TC} filter add dev eth1 parent ffff: protocol ip prio 10 u32 \
      match u32 0 0 flowid 1:1 \
      action mirred egress redirect dev ifb0

Выглядеть будет приблизительно так
BW=100000

#########################
#100% BW 
tc qdisc del dev ifb0 root
tc qdisc add dev ifb0 root handle 1: htb default 1000
tc class add dev ifb0 parent 1: classid 1:10 htb rate ${BW}Kbit ceil ${BW}Kbit quantum 1514 

#75% High Priority metered users
tc class add dev ifb0 parent 1:10 classid 1:15 htb rate 75000Kbit ceil ${BW}Kbit quantum 1514 prio 0
tc qdisc add dev ifb0 parent 1:15 handle 15: bfifo limit 200000

#25% unlimited users
tc class add dev ifb0 parent 1:10 classid 1:20 htb rate 25000Kbit ceil ${BW}Kbit quantum 1514 prio 1
tc qdisc add dev ifb0 parent 1:20 handle 20: bfifo limit 200000

tc filter add dev ifb0 parent 1:0 protocol ip prio 50 u32 match ip dst 1.2.3.4/32 flowid 1:15

tc filter add dev ifb0 parent 1:0 protocol ip prio 50 u32 match ip dst 1.2.3.5/32 flowid 1:20

 

Ессно натишь всех помеговиков на 1.2.3.4 или прописываешь адреса, если у них реальники в дополнительные фильтры.

Ну и анлимщиков в 1.2.3.5, если хочешь для каждого правила - превращаешь 1:20 в "родителя" и пишешь ему подклассы для каждого. Не забудь - сумма rate "детей" не должна превышать rate родителя.

[disappointed]

Буду пробовать ночью,

а возможно ли при нат-е использовать

u32 match ip src 1.2.3.0/24 ?

мне удобнее так было бы

то есть фильтр классифицирует ДО замены src или после?

Edited December 27, 2007 by disappointed

[nuclearcat]

ifb0 не будет видеть адресов которые "за NAT"

[disappointed]

Проблема такая.

 

на ifb0 на данный момент я не могу разделить помеговых и анлимитед по match ip dst 1.2.3.4/32 т.к они за одним адресом.

Это скоро будет неактуально но сейчас именно так.

Поэтому не вижу возможности классифицировать однозначно для кого пришёл определённый пакет на ifb0...

Какие возможны решения?

[I3rain]

Проблема такая.

 

на ifb0 на данный момент я не могу разделить помеговых и анлимитед по match ip dst 1.2.3.4/32 т.к они за одним адресом.

Это скоро будет неактуально но сейчас именно так.

Поэтому не вижу возможности классифицировать однозначно для кого пришёл определённый пакет на ifb0...

Какие возможны решения?

В твоем случае придется юзать IMQ. linuximq.net

 

/sbin/ip link set imq0 up

/sbin/tc qdisc add dev imq0 root handle 1: htb default 2

/sbin/tc class add dev imq0 parent 1: classid 1:1 htb rate 80000Kbit

/sbin/tc class add dev imq0 parent 1: classid 1:2 htb rate 80000Kbit

/sbin/tc class add dev imq0 parent 1:1 classid 1:10 htb rate 256kbit ceil 384kbit

/sbin/tc class add dev imq0 parent 1:1 classid 1:20 htb rate 512kbit ceil 648kbit

/sbin/tc filter add dev imq0 parent 1: protocol ip prio 1 u32 match ip dst aaa.aaa.aaa.aaa/bb match ip src ccc.ccc.ccc.ccc/dd flowid 1:10

/sbin/tc filter add dev imq0 parent 1: protocol ip prio 1 u32 match ip dst ddd.ddd.ddd.ddd/ee match ip src fff.fff.fff.fff/gg flowid 1:20

/usr/sbin/iptables -t mangle -A PREROUTING -i ppp0 -j IMQ --todev 0

/usr/sbin/iptables -t mangle -A PREROUTING -i ppp1 -j IMQ --todev 0

 

 

/sbin/ip link set imq1 up

/sbin/tc qdisc add dev imq1 root handle 2: htb default 2

/sbin/tc class add dev imq1 parent 2: classid 2:1 htb rate 80000Kbit

/sbin/tc class add dev imq1 parent 2: classid 2:2 htb rate 80000Kbit

/sbin/tc class add dev imq1 parent 2:1 classid 2:10 htb rate 256kbit ceil 384kbit

/sbin/tc class add dev imq1 parent 2:1 classid 2:20 htb rate 512kbit ceil 648kbit

/sbin/tc filter add dev imq1 parent 2: protocol ip prio 1 u32 match ip dst ccc.ccc.ccc.ccc/dd match ip src aaa.aaa.aaa.aaa/bb flowid 2:10

/sbin/tc filter add dev imq1 parent 2: protocol ip prio 1 u32 match ip dst fff.fff.fff.fff/gg match ip src ddd.ddd.ddd.ddd/ee flowid 2:20

/usr/sbin/iptables -t mangle -A POSTROUTING -o ppp0 -j IMQ --todev 1

/usr/sbin/iptables -t mangle -A POSTROUTING -o ppp1 -j IMQ --todev 1

[disappointed]

Отпишусь по результатам tc + htb + ifb.

В целом доволен, работает устойчево и предсказуемо. Не понравилось то что в реальных условиях приходится жертовать минимум 10% полосы аплинка иначе в моменты резкой активности помегобайтников происходит неконтролируемый выброс за потолок нашего флэта, а ISP вышестоящий судя по всему юзает шейпинг с большой очередью. Отклик резко ухудшается.

Хотя с ними ещё порешаем это.

[Max P]

Подниму ка старую тему. Вобщем есть NAT и шейпер на tc, на данный момент аплоад от клиентов завернут в tc ingress с тупым policy, хотелось бы перенести на ifb и сделать с хэш-таблицами. Может ли ifb отлавливать пакеты до ната дабы можно было просто указывать src ip 10.20.64.2/32 например? или оно такого не умеет и далее только imq?

[2c2i]

Ну если вы шейпите на интерфейсе который смотрит к юзеру, то должно работать.

[DemYaN]

Подниму ка старую тему. Вобщем есть NAT и шейпер на tc, на данный момент аплоад от клиентов завернут в tc ingress с тупым policy, хотелось бы перенести на ifb и сделать с хэш-таблицами. Может ли ifb отлавливать пакеты до ната дабы можно было просто указывать src ip 10.20.64.2/32 например? или оно такого не умеет и далее только imq?

может, просто делайте action mirred egress redirect для ingress фильтра на внутреннем интерфейсе

 

[Max P]

хм... понятно, значит всё таки где то ошибка у меня в хэшах, пойду дальше разбираться

[photon]

Просто разносите задачи по разным машинам, шейпер как мост отдельно, stateful firewall с NAT -- на бордере, и не будет никаких проблем с псевдоустройствами.

Edited November 10, 2009 by photon

[Max P]

да, просто ошибся в hask key

 

Просто разносите задачи по разным машинам, шейпер как мост отдельно, stateful firewall с NAT -- на бордере, и не будет никаких проблем с псевдоустройствами.

ну это на будущее уже запланировано, на данный момент у нас пока масштаб небольшой