tc classid - ограничение

[Nallien]

в принципе тривиальный вопрос:

linux, tc (traffic control) classid - это значение имеет ограничение в 6 символов, причем первые два обычно еще и указывают на родителя. как увеличить это значение ? я хочу использовать 8 или более символов.

 

логично предполагаю что рыть в исходниках, но есть подозрение что ему это может не понравится, или менять придется во многих местах.

 

может кто прокомментировать, или подсказать ?

 

пс. все для унификации этого самого айди, чтобы оно было читаемое, например для айпи 10.100.13.84 это айди в идеале должно быть 101001384, ну или к примеру 1:101001384.

 

спасибо за внимание.

[nuclearcat]

1)В новых ядрах ограничение убирают, но там еще достаточно много работы

2)65536 правил достаточно, проще создать где-то у себя таблицу соответствия номера класса - юзеру и написать простенький парсер

[Nallien]

проблема не в количестве правил, проблема в максимальном номере правила :)

[nuclearcat]

Просто тупо поменять размерность переменной класса - геммороя немеряно, плюс неизвестно какой overhead выйдет...

[nickD]

Интересно кто и как сейчас решает данную проблему.

 

 

 

[Max P]

тупо добавлением нового роутера :) один роутер на 4 тыщи клиентов

[nuclearcat]

Вообще-то там ffff классов. Т.е. 65K

[photon]

в принципе тривиальный вопрос:

linux, tc (traffic control) classid - это значение имеет ограничение в 6 символов, причем первые два обычно еще и указывают на родителя. как увеличить это значение ? я хочу использовать 8 или более символов.

Сейчас пока что используют для хэширования два последних октета IP-адреса, т.к. больше не получается. Примерно так: tc filter add ... flow map key dst and 0xffff Выходом из положения была бы возможность классификации с помощью ключей из iphash (это такой тип таблицы IP-адресов в ipset). Во FreeBSD примерно так оно и делается (см. pipe tablearg). Edited August 29, 2009 by photon

[shicoy]

Я для шейпинга тоже планирую использовать ipmap, но мне надо шейпить 2 диапазона адресов, реальную сеть и серую перед NAT.

Ломаю голову как выйти из положения.

[nickD]

в принципе тривиальный вопрос:

linux, tc (traffic control) classid - это значение имеет ограничение в 6 символов, причем первые два обычно еще и указывают на родителя. как увеличить это значение ? я хочу использовать 8 или более символов.

Сейчас пока что используют для хэширования два последних октета IP-адреса, т.к. больше не получается. Примерно так: tc filter add ... flow map key dst and 0xffff Выходом из положения была бы возможность классификации с помощью ключей из iphash (это такой тип таблицы IP-адресов в ipset). Во FreeBSD примерно так оно и делается (см. pipe tablearg).

Можно по подробнее про метод с "tc filter add ... flow map key dst and 0xffff".

Для этого нужен патч к ядру или какую нибудь опцию включить?

У меня на команды (kernel 2.6.30)

tc filter add dev imq0 protocol ip pref 32 parent 1:0 flow map key dst and 0xffff

We have an error talking to the kernel

tc filter add dev imq0 protocol ip parent 1:0 handle 2 flow hash keys src,dst divisor 1024

We have an error talking to the kernel

[nickD]

Подскажите у divisor'a предел 256 или это както меняется сейчас использую вот так:

 

$TC filter add dev $DEV_IMQ parent 800:0 prio 5 handle $IP2_HEX: protocol ip u32 divisor 256

....

$TC filter add dev $DEV_IMQ parent 800:0 protocol ip prio 5 u32 ht 800: \

<------> match ip $DEST $IP_NET/16 \

<------> hashkey mask 0x0000ff00 at $DEST_OTET \

<------> link $IP2_HEX:

 

Хочу вот так:

$TC filter add dev $DEV_IMQ parent 800:0 prio 5 handle $IP2_HEX: protocol ip u32 divisor 1024

Получаю:

We have an error talking to the kernel

[photon]

Можно по подробнее про метод с "tc filter add ... flow map key dst and 0xffff".

Для этого нужен патч к ядру или какую нибудь опцию включить?

У меня на команды (kernel 2.6.30)

tc filter add dev imq0 protocol ip pref 32 parent 1:0 flow map key dst and 0xffff

We have an error talking to the kernel

tc filter add dev imq0 protocol ip parent 1:0 handle 2 flow hash keys src,dst divisor 1024

We have an error talking to the kernel

Вообще говоря, я несколько месяцев назад публиковал ссылку на скрипт, в котором реализован этот метод шейпинга: http://forum.nag.ru/forum/index.php?showto...=0&p=394522

 

Ядро должно быть собрано с поддержкой классификатора flow, и пакет iproute2 должен быть достаточно свежий. Команда, добавляющая фильтр, имеет следующий вид:

tc filter add dev imq0 parent 1:0 protocol ip handle 1 pref 32 flow map key dst and 0xffff

 

Альтернативный синтаксис:

tc filter add dev imq0 parent 1:0 protocol ip handle 1 pref 32 flow map key dst addend -192.168.0.0 divisor 65536

 

Это правила для интерфейса, смотрящего внутрь сети и шейпинга входящего трафика из Интернета, для исходящего должно быть src вместо dst. Тогда адресу x.x.0.1 будет соответствовать класс 1:2, x.x.0.2 -- 1:3 и т.д. Наряду с and 0xffff и addend -192.168.0.0 можно применять еще какие-то операции и таким образом сделать проекцию двух пересекающихся диапазонов IP-адресов (например, 10.0.0.0/16 и 192.168.0.0/24) на разные номера классов.

 

Пока единственный источник информации по flow -- комментарий к коммиту в ядро: http://www.mail-archive.com/netdev@vger.ke...g/msg60638.html

Edited August 31, 2009 by photon

[vitalyb]

Подскажите у divisor'a предел 256 или это както меняется сейчас использую вот так:

Предел.

 

Но никто не запрещает сначала прохешировать, например, по 0x1f00 divisor 32, а потом каждый по 0xff divisor 256. В итоге получится divisor 8192.

 

[photon]

У хэширующих фильтров u32 какой-то слишком сложный синтаксис. Хорошо бы сделать классификацию по хэш-ключам заранее созданной таблицы IP-адресов (как pipe tablearg во FreeBSD). В принципе, для этого достаточно сделать target-модуль iptables, который бы понимал такие таблицы и имел синтаксис типа -m set --set table1 src -j CLASSIFY. Проблема еще и в том, что таблицы реализованы в ipset, который поддерживается каким-то кретином, до сих пор не добившимся его включения в ванильное ядро.

Edited August 31, 2009 by photon

[nuclearcat]

photon - а что вы такого гениального сделали, чтоб кого-то кретином называть?

[photon]

photon - а что вы такого гениального сделали, чтоб кого-то кретином называть?

Не сказал бы, что это особо гениально... Опубликовал несколько научных работ и недавно получил степень кандидата физико-математических наук.

 

ipset -- это адаптация ippool для веток 2.4 и 2.6. Вот сколько лет по-вашему нужно тянуть достаточно необходимый людям код поддержки таблиц, и при этом все еще не внести его в ванильное ядро? Другой пример неадекватности: http://www.securitylab.ru/opinion/263620.php. Вот из-за таких безответственных людей FOSS все еще воспринимают как поделки, написанные студентами в свободное время.

Edited August 31, 2009 by photon

[nuclearcat]

photon - я имел в виду для линукса и общества. Научные работы и степень - это вы делали лично для своего я.

Чрезвычайно не люблю когда кто-то оскорбляет авторов FOSS софта (он вам ничем не обязан), не сделав хотя бы аналогичного вклада.

 

[vitalyb]

А у меня нет научных работ, но синтаксис u32 осилил без особого труда. Уж простите за флуд....

 

photon, всё просто - реализуйте свой вариант, сделайте сайт, напишите документацию, а мы обсудим ;)

 

u32 - очень простой, очень быстрый и очень могучий классификатор. Если не "хочется странного" его как правило вполне достаточно.

 

[azlozello]

+1

u32 + хеш могут творить чудеса.

А если "хочется странного" то исходники вам в руки :)

[vladd]

Странного хочется, хотя на самом деле это не странное, а реальная ситуация из жизни. У клиента несколько IP-адресов, часто в разных подсетях, могут быть и реальные, и серые на одной учетке. И скорость тарифа должна делиться между всеми ними. Т.е. одна очередь на несколько IP.

 

Как такое правильно сделать при помощи iptables+tc+ipset, ума не приложу. Кроме тысяч последовательных правил в iptables или фильтров в tc, в голову ничего не приходит.

 

Единственный разумный выход - перейти на фрю и использовать tablearg, тоже не вызывает энтузиазма. Все шустро, и очень даже красиво, но под реальной нагрузкой работает не больше пары часов - и уходит в ребут. Смена железа не помогает. С iptables никогда такого не было.

[photon]

Странного хочется, хотя на самом деле это не странное, а реальная ситуация из жизни. У клиента несколько IP-адресов, часто в разных подсетях, могут быть и реальные, и серые на одной учетке. И скорость тарифа должна делиться между всеми ними. Т.е. одна очередь на несколько IP.

 

Как такое правильно сделать при помощи iptables+tc+ipset, ума не приложу. Кроме тысяч последовательных правил в iptables или фильтров в tc, в голову ничего не приходит.

Таких ситуаций надо по возможности избегать и внушить начальству, что это неоптимально. Ставьте клиентам роутеры для подключения нескольких машин через один IP, берите больше белых адресов, чтобы не мучаться с двумя адресными пространствами. Вообще говоря, с помощью u32 hashing filters можно заворачивать несколько IP в одну очередь, если дочерние фильтры указывают на один и тот же класс. Однако, если у вас есть адреса с одинаковыми последними октетами, появляются проблемы. Фряшные pipe tablearg или динамические пайпы с маской 0xffffffff работают только по схеме "один IP на очередь". Edited November 28, 2009 by photon

[vitalyb]

У клиента несколько IP-адресов, часто в разных подсетях, могут быть и реальные, и серые на одной учетке. И скорость тарифа должна делиться между всеми ними. Т.е. одна очередь на несколько IP.

Если все эти адреса ходят через один интерфейс на Вашем роутере, тогда в чем проблема? Всё работает, берете и делаете "как обычно": хешируете по N последним битам, а потом по IP адресу отправляете в нужый класс. Типа такого:

...
tc filter add dev DEV protocol ip parent 1:0 prio 10 u32 ht 800:: \
        match u32 0x00000000 0x00000000 at 16 hashkey mask 0x00001f00 at 16 \
        link 2:
...
tc filter add dev DEV protocol ip parent 1:0 prio 10 u32 ht 2:7: \
        match u32 0x00000700 0x00001f00 at 16 hashkey mask 0x000000ff at 16 \
        link 17:
...
tc class add dev DEV parent 1:11 classid 1:4cfa htb rate 588kbit ceil 588kbit prio 2
tc qdisc add dev DEV parent 1:4cfa handle 4cfa: pfifo limit 150
tc filter add dev DEV protocol ip parent 1:0 prio 10 u32 ht 24:e2: match ip dst 10.10.180.226/32 flowid 1:4cfa
tc filter add dev DEV protocol ip parent 1:0 prio 10 u32 ht 17:10: match ip dst 172.16.7.16/32 flowid 1:4cfa