tc class add... количество классов в одной корневой дициплине и производительность

's/+ 5000 фильтров к каждому классу/+ по фильтру к каждому классу/'

А такое обязательно делать на PC?

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

Насчёт цысок: прочитал недавно пару интересных статей...

http://asterisk.org.ru/index.php?option=com_content&task=view&id=252&...

http://asterisk.org.ru/index.php?option=com_content&task=view&id=257&...

Например цитата: " Если бы большинство из них хоть иногда интересовалось, а что за аппаратные средства применяет Cisco в своих маршрутизаторах, то обнаружили бы в самом производительном процессорном модуле 72й серии маршрутизаторов Cisco(а ведь эта серия далеко не попса для офиса и позиционируется как решение для сервис-провайдеров) NPE-G1 всего-то процессор Broadcom BCM1250 с частотой 700! МГц и шину PCI!. Никаких специализированных чипов и модулей там нет. Вот и все их хваленое аппаратное ускорение. Чистой воды надувательство, если учитывать непомерные цены на это оборудование. То же самое в еще более дорогой серии 7300."

И потом, никто денег на нормальную циску не даст.

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

В статье явно указано серии 72хх и 7300 маршрутизаторов cisco.

Но суть не в этом. Цыски у меня нет и не будет. Задачу надо решить на PC. Погуглив немного я нашёл на статью http://www.nixp.ru/articles/iproute2, там среди прочего написано:

"е) существует также возможность создания хешей фильтров (т.е. групп фильтров, которые применяются при прохождении определенных других фильтров), но это применяется лишь в случаях тысяч правил, когда обработка всех фильтров занимает значительное процессорное время. Объем этой статьи не позволяет мне рассказать и об этой возможности, поэтому при возникновении этой проблемы нужно почитать HOWTO — www.lartc.org."

HOWTO здесь имеется ввиду Linux Advanced Routing & Traffic Control HOWTO.

Почитав HOWTO, русский перевод: http://gazette.linux.ru.net/rus/articles/lartc/index.html наткнулся на такую вещь:

"Глава 12. Расширенная фильтрация.

...

12.1. Классификатор u32.

Фильтр U32 наиболее гибкий из доступных в текущей конфигурации. Он целиком основан на хеш-таблицах, которые повышают устойчивость фильтра при значительном количестве правил фильтрации.

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

12.1.1. Селектор U32.

Селектор U32 содержит определение шаблона, который будет сопоставляться с обрабатываемым пакетом. Если быть более точным, он определяет -- какие биты в заголовке пакета будут проверяться и не более того, но, не смотря на свою простоту, это очень мощный и гибкий метод. "

Источник: http://gazette.linux.ru.net/rus/articles/lartc/c1452.html

Вот только мне не понятно, является ли фильтрация по ip с помощью классификатора u32 и селектора общего назначение u32 созданием хешей фильтров, что советуется использовать в случае больше тысячи правил фильтрации в выдержке из статьи выше.

А, всё, нашёл про хеши фильтров: http://gazette.linux.ru.net/rus/articles/lartc/x1661.html

Вывод: спать надо больше, сразу не увидел )

Буду пробовать с хешами фильтров писать правила.

Только вопрос про количество классов остаётся открытый.

Читаю про хеш фильтры:

http://gazette.linux.ru.net/rus/articles/lartc/x1661.html

Цитата:

"Если у вас возникла потребность в большом количестве правил, например, когда у вас много клиентов, причем все имеют различные спецификации QoS (от англ. Quality of Service -- Качество Обслуживания), то может сложиться ситуация, когда ядро будет тратить недопустимо большое количество времени на поиск подходящего правила в наборе.

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

Не понятен такой момент: если у всех моих правил фильтрации одинаковый приоритет, то ядро будет среди правил фильтрации "хопом" искать, или в порядке написания правил фильтрации. Если "хопом", то какой смысл при одинаковом приоритете использовать хеш фильтры?

И ещё:

"Все это выглядит довольно сложным, но действительно работает и дает ошеломляющую производительность. Обратите внимание, этот пример может быть оптимизирован еще больше и сведен к идеальному случаю, когда каждая цепочка содержит 1 фильтр!"

Если у меня будет 5 тыс цепочек, и в каждой цепочке по одному фильтру не будет ли ядро перебирать по порядку написания цепочек ища нужное для определённого фильтра?

И сколько времени займёт это перебирание цепочек для определённого фильтра.

цепочки тоже можно оптимизировать. только не спашивай как;)