Перейти к содержимому
Калькуляторы

sc: скрипт для управления Linux-шейпером

Наладилось на 4.0.0-rc5

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сделал релиз 1.5.5, где немного изменился конфиг (некоторые параметры теперь сгруппированы в секции) и добавлена возможность устанавливать для шейпера default policy: block или pass.

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Хочу сразу сказать автору огромное спасибо за проделанную работу. И сразу к проблеме, мне надо чтоб на определенном тарифном плане менялась скорость, я в биллинге указал время переключения, указал новую скорость, все тут отрабатывает, НО иногда вылетает вот такая ошибка

sc sync

verbose = 1

* 176.111.xxx.xxx 12288kibit -> 51200kibit

Error: argument "invalid class ID" is wrong: 1:176.111.xxx.xxx

если не убрать глюкнувший ip адрес руками из базы sdc dbdel 176.111.xxx.xxx то все последущие за этим адресом ip не будут попадать в базу и соответственно у людей отваливается инет. Удаляю руками ip (ip каждый раз разные (я еще вот понаблюдаю)), потом делаю sc sync все ip попадают в базу, полосы нарезаются и все работает, как избавиться от этого глюка, куда можно посмотреть? не хочется каждый вечер сидеть за консолью и делать sc sync, sc dbdel ip. шейпер отдельная машина настроенная бриджом.

Скорость меняю вот так

ssh root@192.168.0.8 sc dbdel $3

ssh root@192.168.0.8 sc add $3 $5Mibit

ssh root@192.168.0.8 sc sync

P.S пробовал менять скорость и через sc change $3 $5Mibit ; sc sync тоже самое.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вы пользуетесь неправильными командами. В документации и sc help есть примеры. Зачем добавлять знаки $ перед вводимыми данными? Удалять нужно по IP-адресу, а не по номеру класса: sc dbdel 176.111.x.x. Добавление адреса делается командой sc add 176.11.x.x 5Mibit. Номера классов вычисляются автоматически, т.к. есть однозначное соответствие с IP-адресами.

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

$ эти параметры передаются скрипту из биллинга (lanbilling) $3-это выданный абоненту ip адрес, $5-скорость тарифного плана. вот пример абонента (vpn1593-логин eMoTo043-пароль 176.111.251.103 255.255.255.255 45-скорость тарифного плана)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Надо писать ${5}Mibit, чтобы отделить имя переменной от текста. В какой версии sc это происходит? В 1.5.0, когда я существенно обновил код, действительно были проблемы с синхронизацией, но они были исправлены в последующих версиях. Я не могу у себя воспроизвести этот баг, скорее всего он возникает из-за каких-то проблем с запросами к базе или промежуточными скриптами.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если у вас доступ осуществляется через VPN-сервер, и у каждого юзера свой PPP-интерфейс, то нет смысла использовать sc и хэш-фильтры. Достаточно повесить простой tbf и полисер на каждый виртуальный интерфейс.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Приветствую!

 

Shaper Control Tool (version 1.5.5, 1.5.1)

Debian Jessie, ядро 3.16.0-4-amd64

сообщения в dmesg:

[ 7157.573144] htb: packet reclassify loop rule prio 0 protocol 800
[ 7162.490394] net_ratelimit: 730 callbacks suppressed
[ 7162.490405] htb: packet reclassify loop rule prio 0 protocol 800
[ 7162.491936] htb: packet reclassify loop rule prio 0 protocol 800
[ 7162.492108] htb: packet reclassify loop rule prio 0 protocol 800
[ 7162.493219] htb: packet reclassify loop rule prio 0 protocol 800
[ 7162.498290] htb: packet reclassify loop rule prio 0 protocol 800
[ 7162.498386] htb: packet reclassify loop rule prio 0 protocol 800
[ 7162.511801] htb: packet reclassify loop rule prio 0 protocol 800
[ 7162.519259] htb: packet reclassify loop rule prio 0 protocol 800
[ 7162.525164] htb: packet reclassify loop rule prio 0 protocol 800
[ 7162.536743] htb: packet reclassify loop rule prio 0 protocol 800

Изменено пользователем technolab

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Какие параметры в конфиге? Есть ли NAT и псевдоустройства?

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В конфиге только network девятнадцатая и двадцать четвертая, остальное по умолчанию. Один интерфейс с тегом (влан). Никакого NAT.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тег добавляет 4 байта и смещает все поля в пакете на 4, поэтому ошибки и валятся. Надо в коде поменять смещение для dst IP c 16 на 20.

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

- Shaper Control Tool (version 1.3.4, 1.5.5) + Debian Squeeze, ядро 3.2.0-4-amd64 проблемы с

tb: packet reclassify loop rule prio 0 protocol 800

нет;

- Shaper Control Tool (version 1.5.5, 1.5.1) + Debian Jessie, ядро 3.16.0-4-amd64, конфигурация sc по умолчанию, добавлены две сети: 19 и 24. Не классифицированный траффик блокируется, пакеты с src|dst для которых созданы фильтры, заворачиваются в свой кудиск. Даже на физических интерфейсах поверх которых есть вланы, с оффсетом по умолчанию фильтры отрабатывают корректно, поведение шейпируемого траффика соответствует ожиданиям, но в dmesg

tb: packet reclassify loop rule prio 0 protocol 800

. Если изменить оффсет (добавить смещение на тег), то пакеты перестают попадать под фильтр и блокируются. Разтегировал интерфейс, т.е. вланов больше нет, ситуация не меняется:

tb: packet reclassify loop rule prio 0 protocol 800

 

Кто виноват и что делать?

 

Бугагага! Восемь лет назад это уже было Надо во всех фильтрах аргумент "action drop" заменить на просто "drop".

Изменено пользователем technolab

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это баг или так теперь будет во всех новых версиях?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Как я понял, это плавающий между версиями iproute2 "нюанс" - просто "drop" работает всегда "action drop" в некоторых версиях игнорируется из-за "action" и тогда работает действие по умолчанию - "reclassify". Проще говоря лучше аргумент "action" опускать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

photon Приветствую, а не подскажите, можно ли include-ить файлы конфигурации?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

to admf вместо include:

sed -i 's/^rate_ratio.*=.*/rate_ratio = 1.5/g' /etc/sc/sc.conf

или

sed -i 's/^bypass_int.*=.*/bypass_int = 10.0.254.0\/24 10.208.240.1\/24/g' /etc/sc/sc.conf

Изменено пользователем technolab

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

photon Приветствую, а не подскажите, можно ли include-ить файлы конфигурации?

Не совсем понял вопрос. Можно указывать путь к конфигурационному файлу в командной строке: sc -f sc-night.conf. Т.е. если ночью у вас другие тарифы, то можно переключаться между несколькими конфигами. Также можно переопределять любые параметры конфига из командной строки: sc --<parameter>=<value>, т.к. они обрабатываются по тем же хэшам.

 

Для парсинга используется библиотека AppConfig::File http://search.cpan.org/~abw/AppConfig-1.56/lib/AppConfig/File.pm .

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

technolab,photon спасибо за информацию.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

День добрый!

Имеется машинка на Xeon E3-1245 с 2-мя 10G портами, которые в мосте, на машинке centos 6.7 полностью обновленная.

Установлен sc для шейпинга. Онлайн примерно 3-4 тыс. хомяков.

хотелось бы узнать ваше мнение/комментарии .... есть ли смысл убрать (для улучшения в плане производительности) ip адрес с интерфейса br0 и управлять машинкой через не задействованный в шейпинге интерфейс!?

может быть кто подскажет оптимальные настройки sc ( filter_method .....), для достижения максимальной производительности/отклика у клиентов.

Изменено пользователем ikoctya

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Коммутация теоретически быстрее, чем маршрутизация, но если в том и другом случае задействован 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, а если это не поможет, то подобрать их эмпирически и прописать в коде.

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день!

Поставил sc-1.5.6 и замечаю с ней странную штуку.

После добавления ip в базу команда sc sync выдает такое:

 

* 10.10.0.87 19530kibit -> 19531kibit

* 10.10.2.112 19530kibit -> 19531kibit

* 10.10.2.130 19530kibit -> 19531kibit

* 10.10.2.232 19530kibit -> 19531kibit

* 10.10.4.133 97655kibit -> 97656kibit

* 10.10.4.29 8191kibit -> 8192kibit

* 10.10.30.19 97655kibit -> 97656kibit

* 10.10.0.129 19530kibit -> 19531kibit

* 10.10.21.97 97655kibit -> 97656kibit

* 10.10.3.137 19530kibit -> 19531kibit

* 10.10.0.187 19530kibit -> 19531kibit

* 10.10.4.227 51199kibit -> 51200kibit

* 10.10.6.190 51199kibit -> 51200kibit

* 10.10.5.194 97655kibit -> 97656kibit

* 10.10.11.210 5119kibit -> 5120kibit

 

(весь список ip базы)

 

Если ввести sc sync еще раз, выдаст то же самое (ну, только в другом порядке).

 

root@shaper1-1:~# sc sync | grep 10.10.11.210

* 10.10.11.210 5119kibit -> 5120kibit

root@shaper1-1:~#

root@shaper1-1:~# sc sync | grep 10.10.11.210

* 10.10.11.210 5119kibit -> 5120kibit

 

 

В базе значения именно с правой стороны.

 

upd: а, нет, вот так, где 19530kibit - такое значение в базе.

 

С чем это может быть связано?

Изменено пользователем bydunai

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

БД создавалась командой sc dbcreate.

Дополню еще вот чем, вдруг поможет.

Такое поведение происходит и со старой бд (скопирована с продакшена (sc 1.3.5)) и с новой.

Сейчас еще чуток покопался, создал новую бд через sc dbcreate.

Создал 4 ip -

10.10.0.1 10Mbit
10.10.0.2 100Mbit
10.10.0.3 10Mbit
10.10.0.4 50Mbit
10.10.0.5 80Mbit

 

Добавились нормально, но если еще раз делать sc sync, выпадают следующие:

root@shaper1-1:~# sc sync
* 10.10.0.4 48827kibit -> 48828kibit
* 10.10.0.2 97655kibit -> 97656kibit

 

Не думаю, что это помешает работе, но как-то непонятно.

 

Отвечая на ваш вопрос:

sqlite> .schema rates

CREATE TABLE rates (ip UNSIGNED INTEGER PRIMARY KEY, rate UNSIGNED INTEGER NOT NULL);

Изменено пользователем bydunai

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.