tc проблема с reclassify loop

[pchol]

Добрый день.

Ситуация следующая.

Debian, kernel 2.6.31.4, сервер представлет собой nat-сервер + шейпер (tc).

В kern.log вываливается куча записей следующего вида.

Nov 27 17:10:23 shaper kernel: [2620259.510149] rule prio 0 protocol 800 reclassify loop, packet dropped

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

Если бы это было пара записей я бы может и забил. Но за день накапливается лог размером на пару мегабайт.

 

Не подскажете ли где искать корень проблемы ?

 

Шейпер выглядит вот так:

#! /bin/sh
echo "del qdisc"
tc qdisc del dev eth3 root      2> /dev/null > /dev/null
tc qdisc del dev eth3 ingress   2> /dev/null > /dev/null

echo "create root handle"
tc qdisc add dev eth3 root handle 10: htb default 9000 r2q 20
tc class add dev eth3 parent 10: classid 10:1 htb rate 500mbit ceil 550mbit
tc qdisc add dev eth3 handle ffff: ingress


#Hash filter
echo "create hash filter"
tc filter add dev eth3 parent 10: prio 5 protocol ip u32
tc filter add dev eth3 parent 10: prio 5 handle 2: protocol ip u32 divisor 256
echo "Load rules"

#192.168.51.126
tc filter add dev eth3 protocol ip parent 10: prio 5 u32 ht 2:7E match ip dst 192.168.51.126/32 flowid 10:611
tc class add dev eth3 parent 10:1 classid 10:611 htb rate 272kbit ceil 272kbit
tc filter add dev eth3 protocol ip parent ffff: prio 5 u32 match ip src 192.168.51.126/32 police rate 10240kbit burst 1024k flowid :611

#192.168.51.41
tc filter add dev eth3 protocol ip parent 10: prio 5 u32 ht 2:29 match ip dst 192.168.51.41/32 flowid 10:612
tc class add dev eth3 parent 10:1 classid 10:612 htb rate 272kbit ceil 272kbit
tc filter add dev eth3 protocol ip parent ffff: prio 5 u32 match ip src 192.168.51.41/32 police rate 10240kbit burst 1024k flowid :612

....

echo "create match map"
tc filter add dev eth3 protocol ip parent 10: prio 5 u32 ht 800:: match ip dst 192.168.0.1/16 hashkey mask 0x000000ff at 16 link 2:
tc filter add dev eth3 protocol ip parent 10: prio 4 u32 ht 800:: match ip dst 10.0.0.0/16 hashkey mask 0x000000ff at 16 link 2:

[photon]

nat-сервер + шейпер (tc).

Не стоит совмещать шейпер и NAT. Кроме того, фильтры для полисинга

tc filter add dev eth3 protocol ip parent ffff: prio 5 u32 match ip src 192.168.51.126/32 police rate 10240kbit burst 1024k flowid :611

не хэшируются и поэтому создают нагрузку. Нужно делать шейпинг на двух разных интерфейсах. Далее, хэш-фильтр

tc filter add dev eth3 protocol ip parent 10: prio 4 u32 ht 800:: match ip dst 10.0.0.0/16 hashkey mask 0x000000ff at 16 link 2:

указывает на те же дочерние фильтры, что и для сети 192.168.0.0/16. IP из сети 10.0.0.0/16 будут ходить по фильтрам с match ip dst 192.168.x.x/32, что тоже неправильно.

Edited November 28, 2009 by photon

[pchol]

Какие есть варианты поправить ситуацию ?

Имею ввиду кроме разноса NAT'а и шейпера.

Edited November 28, 2009 by pchol

[2c2i]

повернуть ингресс с eth3 на ifb и сделать правильно хеш?

[pchol]

Проблема в неверном хешировании.

Буду исправлять.

Спасибо за подсказки.

Edited November 28, 2009 by pchol

[photon]

Могу подкинуть ссылку на правильный пример хэширования по двум октетам: http://brownian.org.ua/?page_id=6&langswitch_lang=en

[pchol]

photon cпасибо за статью.

Проблема всё же оказалась не в хешировании, а в ingress policing, я так понял, что не хватает потоков (максимально используемый id 5100).

Но их же должно быть ffff тоесть 65к. Или я что то снова не так понимаю ?

Ни кто не знает как решить эту проблему без выноса НАТа на отдельный сервер или редиректа исходящего трафика на вирт. интерфейсы (imq / ifb) ?

Хотелось бы продолжить использовать ingress в том виде в котором он есть.

 

Edited November 30, 2009 by pchol

[photon]

Еще нужно заметить, что все номера ключей хэширующих фильтров должны быть в шестнадцатеричном формате. Делать редирект на IFB при per user shaping более оптимально, т.к. для классификации можно сделать такой же хэш, как и для исходящего трафика.

[voron]

+ использование ifb даёт возможность продавать пакеты вида не "1мбит вход/1мбит исход" а например "1.5мбит суммарной полосы". И клиент как хочет, так и утилизирует.

[Oleg Gawriloff]

tc filter add dev eth3 protocol ip parent ffff: prio 5 u32 match ip src 192.168.51.126/32 police rate 10240kbit burst 1024k flowid :611

Проблема тут.

Ибо по умолчанию если пакет попадает под шейпер то он реклассифицируется. Т.е. если посмотреть конфигурацию фильтра:

lark ~ # tc filter add dev vlan40 parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate 128kbit burst 102400

lark ~ # tc -s filter show dev vlan40 parent ffff: protocol ip prio 50

filter u32

filter u32 fh 800: ht divisor 1

filter u32 fh 800::800 order 2048 key ht 800 bkt 0 terminal flowid ??? (rule hit 3 success 3)

match 00000000/00000000 at 12 (success 3 )

police 0x3 rate 128000bit burst 100Kb mtu 2Kb action reclassify overhead 0b

ref 1 bind 1

 

Если создать фильтр:

lark ~ # tc filter add dev vlan40 parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate 128kbit burst 102400 action drop

lark ~ # tc -s filter show dev vlan40 parent ffff: protocol ip prio 50

filter u32

filter u32 fh 800: ht divisor 1

filter u32 fh 800::800 order 2048 key ht 800 bkt 0 terminal flowid ??? (rule hit 2 success 2)

match 00000000/00000000 at 12 (success 2 )

police 0x4 rate 128000bit burst 100Kb mtu 2Kb action drop overhead 0b

ref 1 bind 1

Тогда в логах пусто.