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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Edited by SokolovS

Share this post


Link to post
Share on other sites

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

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

Edited by photon

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

tc -force -batch

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

Share this post


Link to post
Share on other sites
Еще есть вопросик попутный. То что фильтры по 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 by photon

Share this post


Link to post
Share on other sites

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

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

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

 

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

Edited by SokolovS

Share this post


Link to post
Share on other sites
Т.е. уникальным идентификатором в данном случае является 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 by photon

Share this post


Link to post
Share on other sites

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

 

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

Edited by SokolovS

Share this post


Link to post
Share on other sites
Ну вот пример, дерево строится по последним 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 by photon

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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