tc шейпер u32 + подсети

[SokolovS]

Есть шейпер по u32 (src/dst ip), сделан хешем как и рекомендуется, все нормально работает.

Как бы ко всему этому еще добавить возможность шейпить подсети, а не только /32 адреса, ведь каждая новая подсеть это в среднем +0.5 проверки для классификации трафика.

В случае с подсетями /30 все просто, можно шейпить только 1 адрес, а вот как быть если через эти /30 машрутизируется еще сеть /26 например.

 

Поделитесь опытом если кто-то реализовал.

[2c2i]

а чем не подходит указать для всех хостов сети одинаковый flowid в фильтре?

[SokolovS]

Вариант номер раз, в принципе приемлемый. Еще есть варианты с меньшим кол-вом строчек в шейпере :) ?

Edited March 12, 2010 by SokolovS

[photon]

Вариант номер раз, в принципе приемлемый. Еще есть варианты с меньшим кол-вом строчек в шейпере :) ?

Фильтры u32 допускают создание многоуровневых хэшей. Время прохождения пакета по правилам всегда будет O(const) для любого числа IP-адресов и подсетей. Но эти фильтры будет достаточно сложно поддерживать, если не написать скрипт, автоматически генерирующий такие хэши.

Edited March 13, 2010 by photon

[SokolovS]

Можно пример многоуровневого хеша? Кто использует?

[photon]

Можно пример многоуровневого хеша? Кто использует?

http://sourceforge.net/projects/sc-tool/

http://www.hazard.maks.net/blog/index.php?...02&blogId=1

[SokolovS]

Спс. Хороший пример.

[SokolovS]

У меня такой вопрос возник, можно ли в batch режиме не прекращать выполнение если на какой-то команде произошла ошибка. Я обычно делаю replace, а для корневой дисциплины это не прокатывает. В обычном режиме это не важно, все последующие команды выполняется.

[photon]

Для этого нужно править исходник tc.

[SokolovS]

Еще есть вопросик попутный. То что фильтры по replace не заменяются а добавляются еще раз, это косяк в iproute2 или в ядре?

[nuclearcat]

tc -force -batch

[photon]

tc -force -batch

Забыл про этот ключ, спасибо что напомнили.

[photon]

Еще есть вопросик попутный. То что фильтры по replace не заменяются а добавляются еще раз, это косяк в iproute2 или в ядре?

Если создавать краевые фильтры не в виде таблицы, а с handle $ht:key вместо $ht:$key:800, то replace с ними правильно работает. В sc используются такие правила:

tc filter replace dev eth0 parent 1: pref 10 handle $ht:$key u32 ht $ht:$key: match ip src $ip flowid 1:$cid

Edited March 18, 2010 by photon

[SokolovS]

Т.е. уникальным идентификатором в данном случае является handle, а при его отсутствии соответствия для замены не найти и запись создается снова, я правильно понял?

Кстати еще вот такие правила не реплейсятся:

filter add dev eth0 parent 1:0 prio 100 handle 15: protocol ip u32 divisor 256

 

Да и еще один момент с handle, $key я как понял в краевом фильтре это последний октет IP, так вот когда он 0, будет ошибка если такой handle уже используется, а он как раз используется под таблицу. Хотя адрес вполне допустимый.

Edited March 19, 2010 by SokolovS

[photon]

Т.е. уникальным идентификатором в данном случае является handle, а при его отсутствии соответствия для замены не найти и запись создается снова, я правильно понял?

Если не указывать параметр handle $ht:$key, то команды add и replace создадут таблицу и будут добавлять в нее фильтры со следующими номерами: $ht:$key:800, $ht:$key:801 и т.д. При наличии параметра handle будет создан единственный фильтр с handle $ht:$key.

Кстати еще вот такие правила не реплейсятся:

filter add dev eth0 parent 1:0 prio 100 handle 15: protocol ip u32 divisor 256

 

Да и еще один момент с handle, $key я как понял в краевом фильтре это последний октет IP, так вот когда он 0, будет ошибка если такой handle уже используется, а он как раз используется под таблицу. Хотя адрес вполне допустимый.

Ну в основном для того и нужно писать скрипты, чтобы не было таких конфликтов. Значение $ht может быть любым от 1 до 0x799, с ключом хэша должен совпадать $key. Ключ -- это некий байт из пакета, расположенный по некоторому заданному смещению, а не только какой-либо октет IP-адреса. Можно совершенно аналогично строить хэши по любым полям пакета. Edited March 19, 2010 by photon

[SokolovS]

Ну вот пример, дерево строится по последним 2-м октетам IP, в итоге допустим для IP xx.xx.20.0 имеем handle вида 20:0, что не есть допустимо :( Для уникальности придется похоже по твоему совету менять $ht в сторону больше 0xFF

 

P.S.: А как поступать с некраевыми фильтрами, они тоже по replace дублируются по схеме тобой описанной ($ht:$key:800, $ht:$key:801 и т.д)?

Edited March 19, 2010 by SokolovS

[photon]

Ну вот пример, дерево строится по последним 2-м октетам IP, в итоге допустим для IP xx.xx.20.0 имеем handle вида 20:0, что не есть допустимо :( Для уникальности придется похоже по твоему совету менять $ht в сторону больше 0xFF

Значение $ht может быть любым, т.к. это не ключ хэша, а всего лишь его порядковый номер. На этот номер делается ссылка из родительского хэш-фильтра в параметре link $ht:, и больше он нигде не используется. Значение октета должно совпадать только с $key. Назначение $ht разным подсетям и создание соответствующих правил с вложенными хэшами автоматизировано в скрипте sc. Use the source, Luke.

 

P.S.: А как поступать с некраевыми фильтрами, они тоже по replace дублируются по схеме тобой описанной ($ht:$key:800, $ht:$key:801 и т.д)?

Их нужно создавать один раз при инициализации правил. Добавлять/удалять нужно только краевые фильтры. Edited March 20, 2010 by photon

[SokolovS]

Мы все такие наверное про разные вещи говорим. Я пишу про handle, а ты про ht. handle как я понял это вобще просто уникальный идентификатор фильтра и никак с ht не связан или я ошибаюсь?

[photon]

Между ними есть какая-то связь. Старшие байты параметров handle и ht должны совпадать, иначе tc filter add ... выдаст ошибку. handle x:y адресует одиночный фильтр, а ht x:key: -- это элемент хэш-таблицы, к которой может быть прикреплен список фильтров {x:y:800, x:y:801, ... }. Младшие байты (y и key) могут не совпадать, т.к. они обозначают разные вещи, но для простоты их лучше тоже делать равными друг другу.

А как поступать с некраевыми фильтрами, они тоже по replace дублируются

Чтобы избежать создания списка фильтров, нужно указывать параметр handle. Но если эти фильтры не нужно как-то редактировать, то можно не указывать handle. Edited March 20, 2010 by photon

[SokolovS]

2photon: Еще к тебе вопросы :)

Вот ты в sc структуру фильтров загружаешь один раз. Как ты при последующих модификациях проверяешь что эта структура не изменилась? Или принимаешь априори условие что модификация только с помощью sc?

[photon]

Да, не проверяю, т.к. обычно модифицируются только правила, относящиеся к краевым классам/фильтрам/дисциплинам. Зачем лишний раз трогать хэш-фильтры и корневые дисциплины? Проверки вводить не хочу, т.к. они сильно снижают скорость массовой загрузки правил.