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-адресов сетевух шейпера, чтобы его не вырубало при загрузке правил из базы, где нет его адресов?

Маршрутизацией занимается маршрутизатор, а не мост.

Нет, в sc так делать нельзя. Это сожрет классы, которых всего 2^16-2, и их не хватит на всех клиентов. Приоритеты внутри очереди лучше делать на стороне клиента, например, продав ему пренастроенный маршрутизатор или услуги по такой настройке. В Винде оно настраивается через консоль Local Group Policy Editor. Для совсем тупых некоторые игровые материнки уже из коробки имеют софт для управления сетевым трафиком.

Это хорошо, что линейная зависимость сохраняется даже при высоких скоростях. Поставлю 0.2 как значение по умолчанию.

Это известная особенность полисинга. По большому счету, им можно регулировать только пакетрейт, а не битрейт. Надо эмпирически настраивать burst и полосу для того, чтобы скорость соответствовала номиналу, и контролировать это дело iperf'ом. Если у вас полоса до 2 Гбит/с, то можно спокойно сидеть на шейпинге. У знакомого процессор уходил в потолок из-за глобального лока в HTB начиная где-то с 4-х Гбит/с.

Задача поставлено неправильно. Что делать: 1. Избавиться от Mikrotik в пользу Linux. 2. Избавиться от PPTP в пользу IPoE. 3. Делать приоритезацию на border gateway для всего трафика по его типу (номера портов), а не внутри клиентских классов.

Был у меня похожий вопрос к программистам ядра несколько лет назад. Сказали, что нужно всегда указывать handle и лучше использовать replace вместо add. tc filter replace dev em2 parent 1: handle 10:d8:800 u32 ht 10:d8: match ip dst 10.0.10.216/32 flowid 1:1772

Это какой-то баг в конвертации единиц, который может быть в вашей версии tc. Используйте единицы IEC, кратные 1024: Mibit и kibit, тогда разночтений не будет.

Какая у вас СУБД и тип данных у поля скорости? Я тестирую на SQLite с типом "UNSIGNED INTEGER NOT NULL", там такого нет.

Коммутация теоретически быстрее, чем маршрутизация, но если в том и другом случае задействован CPU, то разница невелика. Оптимальные настройки зависят от того, насколько загружен канал и каков пакетрейт в часы пиковой нагрузки. Если нагрузка до 3 Гбит/с, то при таком числе пользователей еще можно использовать шейпинг: limit_method = shaping root_qdisc = htb default_rate = 10gibit quantum = 30000 leaf_qdisc = "pfifo limit 1000" Если нагрузка от 3.5 Гбит/с и более, то следует перейти на полисинг: limit_method = policing Для полисинга близко к номинальной скорости нужно найти правильные размеры приемных буферов, т.е. подвигать параметр policer_burst_ratio, а если это не поможет, то подобрать их эмпирически и прописать в коде.

Т.е. ситуация такая: нужно либо убирать локи из multiq, либо добавить в mq возможность повесить фильтр с action skbedit queue_mapping. Иного выхода, как допилить самому или обращаться к разработчикам я не вижу. В той рассылке появлялся некто John Fastabend, скорее всего он за это и отвечает. Вот тут человек что-то пытается сделать с помощью ipset: http://www.spinics.net/lists/netdev/msg318787.html . Попробуйте полисеры для разнообразия, они хоть и менее качественно нарезают, но работают без глобального лока, в отличие от HTB.