photon

Для этого уже есть опции bypass_int и bypass_ext. Надо будет по умолчанию туда добавить 224.0.0.0/24.

Нет, шейпится только unicast traffic, потому что классификация идет по адресам источника и назначения. Однако, можно создать специальную подсеть для multicast traffic и добавить правила для нее.

Как раз сегодня закоммитил такой патч, можете скачать из репозитория и потестировать. Имена нескольких интерфейсов разделяются пробелами: out_if = eth1 eth2 eth3 ... Если есть возможность, то лучше сделать interface bonding и работать с одним интерфейсом, чтобы не нагружать ядро лишними копиями правил.

Я реализовал это дело без псевдоустройств, с помощью полисинга входящего трафика и шейпинга исходящего: https://sourceforge.net/projects/sc-tool . Если используются только IPv4-адреса, то ipset и iptables из ссылки в предыдущем посте не нужны, все делается правилами tc и поэтому работает быстрее. Да и IPv6 вообще говоря можно точно так же побайтово хэшировать, просто это никому не надо.

"HTB: quantum of class 10001 is big. Consider r2q change." означает, что значение quantum слишком велико, но это не объясняет почему клиенты не добавлялись. Нужен хотя бы конфигурационный файл и копия сломанной базы, чтобы воспроизвести проблему. Почему не пользуетесь новой версией?

Не поможет. Либо расширяйте внешний канал, либо надо резать скорость наиболее активным качальщикам. Можно ловить их как в реальном времени, так и постфактум с помощью Netflow.

Один из последних заказов на доработку как раз был по поводу полисинга 10-гигабитного канала на много пользователей. Приоритезацию по портам можно делать оптом для всех на пограничном маршрутизаторе, после шейпера. Совмещать это с шейпером не советую. Я высылаю ее после оплаты. Там есть деление одной полосы на несколько IP. Если использовать htb для приоритезации разных видов трафика внутри пользовательских классов, то очень быстро исчерпаются доступные номера, которых всего 2^16-2. Когда у вас теряются пакеты из-за потолка на внешнем канале никакой QoS все равно не спасет.

Краевые дисциплины можно использовать какие угодно, изменив значение параметра leaf_qdisc на "esfq perturb 10". sc предназначен для шейпинга трафика, т.е. нарезки полос для нескольких десятков тысяч клиентов при минимальном расходе процессорного времени. Поэтому там нет приоритезации трафика по портам и маркам. ESFQ тоже потребляет процессор, поэтому по умолчанию стоит pfifo. Такие вещи дешевле делать на стороне пользователя, продав ему роутер с настройками QoS. Несколько IP на одну очередь и какие-то дополнительные возможности есть в коммерческой версии.

Если эти два интерфейса не для балансировки, то в локальных сетях будут разные IP. Соответственно, базы аккаунтов и экземпляры sc для каждой из сетей должны быть разными. А если интерфейсы используются для балансировки, то их проще объединить в один виртуальный (LACP bonding) и повесить sc уже на него.

Да, именно так. Иначе бы не было смысла вводить отдельную команду.

Вы пытаетесь сделать хэширование по всем четырем октетам IP-адреса. Это довольно избыточно и сложно. Я делаю максимум по двум последним октетам, и на двух гигабитах все летает.

Вся информация об изменениях есть в истории коммитов, пользуйтесь системами контроля версий.

Вот этот коммит: https://bitbucket.org/sky/sc/commits/5ff17f4581d463e11d5755d3662890e31d7354cf?at=default Начиная с каких-то версий от 2013 года, tc -batch не читал данные из пайпа без этого дефиса, поэтому пришлось добавить. А вы с какой целью интересуетесь? С последним iproute2 все работает.

Сделал так. Параметр default_policy теперь может принимать три значения: block-all (блокировать строго все, чего нет в базе), block (блокировать все, кроме самого шейпера), pass (пропускать все).

Стоит ли добавить автоматический bypass для IP-адресов сетевух шейпера, чтобы его не вырубало при загрузке правил из базы, где нет его адресов?