Jump to content
Калькуляторы

tc проблема с reclassify loop куча непонятных записей в логах

Добрый день.

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

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:

Share this post


Link to post
Share on other sites
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 by photon

Share this post


Link to post
Share on other sites

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

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

Edited by pchol

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Edited by pchol

Share this post


Link to post
Share on other sites

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

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

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

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

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

 

Edited by pchol

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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

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

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this