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

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

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

Edited by photon

Share this post


Link to post
Share on other sites

Несколько IP на одну очередь и какие-то дополнительные возможности есть в коммерческой версии.

Любопытно. Значит таки есть коммерческая версия. Скажите, какой доп. ф-ционал и плюшки в ней есть, по сравнению со свободной?

Сколько стоит?

Share this post


Link to post
Share on other sites

Какой тип нарезки использовать это дело вкуса и потребностей. Я думаю, что мало у кого один роутер

нарезает поровну полосу для десятков тысяч ИП. 10-30 ц классов на мой взгляд оптимальная нагрузка на сервер.

Для большинства необходимы индивидуальные настройки скоростей по ип,

но еще более важны на мой взгляд классы htb. Я у себя использую несколько классов

по тарифам и задействую параметр ceil. Наследование полосы когда сосед не качает наиболее важная функция.

В данной версии эта возможность htb не используется. Относительно коммерческой версии - где можно с ней ознакомиться?

Относительно портов и марок они нужны буквально для нескольких записей - 80 25 порт итд. но они явно не будут лишними для сетей определенных масштабов.

Edited by Nekto

Share this post


Link to post
Share on other sites

Какой тип нарезки использовать это дело вкуса и потребностей. Я думаю, что мало у кого один роутер

нарезает поровну полосу для десятков тысяч ИП.

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

 

Относительно коммерческой версии - где можно с ней ознакомиться? Относительно портов и марок они нужны буквально для нескольких записей - 80 25 порт итд. но они явно не будут лишними для сетей определенных масштабов.

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

Edited by photon

Share this post


Link to post
Share on other sites

Это понятно.

Я думаю вам интересно будет узнать, что ваш скрипт прекрасно работает в режиме hybrid + u32 с кучей вланов (простейшие изменения что бы указывать в конфигурации несколько интерфейсов одновременно, при этом на всех интерфейсах прописываются одинаковые правила), к примеру есть сервер в одной богом забытой деревне:

 

in_if =  eth0.127 eth0.128 eth0.129 eth0.130 eth0.131 eth0.132 eth0.133 eth0.134 eth0.135 eth0.136 eth0.137 eth0.138 eth0.139 eth0.140 eth0.141 eth0.142 eth0.143 eth0.151

sc list | wc -l
433

+ на той же машинке ipt_NETFLOW + nat + nfq_filter + куча правил фильтрации/бината в iptables + активное использование списков ipset.

 

Никаких проблем никогда не было, разве что подбор оптимальных параметров для полисера...

Так что, боюсь вы малость недооцениваете SC..в конце-концов, он просто генерит правила, а уж дальше как там TC будет глючить от него не зависит :)

 

А какие изменения в код вносили??? Тоже интересно, только в режиме полисер

Edited by Antares

Share this post


Link to post
Share on other sites

Это понятно.

Я думаю вам интересно будет узнать, что ваш скрипт прекрасно работает в режиме hybrid + u32 с кучей вланов (простейшие изменения что бы указывать в конфигурации несколько интерфейсов одновременно, при этом на всех интерфейсах прописываются одинаковые правила), к примеру есть сервер в одной богом забытой деревне:

 

in_if =  eth0.127 eth0.128 eth0.129 eth0.130 eth0.131 eth0.132 eth0.133 eth0.134 eth0.135 eth0.136 eth0.137 eth0.138 eth0.139 eth0.140 eth0.141 eth0.142 eth0.143 eth0.151

sc list | wc -l
433

+ на той же машинке ipt_NETFLOW + nat + nfq_filter + куча правил фильтрации/бината в iptables + активное использование списков ipset.

 

Никаких проблем никогда не было, разве что подбор оптимальных параметров для полисера...

Так что, боюсь вы малость недооцениваете SC..в конце-концов, он просто генерит правила, а уж дальше как там TC будет глючить от него не зависит :)

 

А какие изменения в код вносили??? Тоже интересно, только в режиме полисер

Возьмите уже ipt_ratelimit. Обвязка за 15 минут пишется....

Share this post


Link to post
Share on other sites

Это понятно.

Я думаю вам интересно будет узнать, что ваш скрипт прекрасно работает в режиме hybrid + u32 с кучей вланов (простейшие изменения что бы указывать в конфигурации несколько интерфейсов одновременно, при этом на всех интерфейсах прописываются одинаковые правила), к примеру есть сервер в одной богом забытой деревне:

 

in_if =  eth0.127 eth0.128 eth0.129 eth0.130 eth0.131 eth0.132 eth0.133 eth0.134 eth0.135 eth0.136 eth0.137 eth0.138 eth0.139 eth0.140 eth0.141 eth0.142 eth0.143 eth0.151

sc list | wc -l
433

+ на той же машинке ipt_NETFLOW + nat + nfq_filter + куча правил фильтрации/бината в iptables + активное использование списков ipset.

 

Никаких проблем никогда не было, разве что подбор оптимальных параметров для полисера...

Так что, боюсь вы малость недооцениваете SC..в конце-концов, он просто генерит правила, а уж дальше как там TC будет глючить от него не зависит :)

 

А какие изменения в код вносили??? Тоже интересно, только в режиме полисер

Возьмите уже ipt_ratelimit. Обвязка за 15 минут пишется....

ratelimit не работает на centos 6

Share this post


Link to post
Share on other sites

Приветствую всех и разработчика тоже!

Имеем sc версии 1.3.5, фактически подключенных к сети одновременно примерно 3500-4000 клиентов, 4 сетки /22 , 2 по /23 и одна по /24.

Конечно же траффик режет sc.

Все работало как часы до вчерашнего дня. Sc почему-то перестал добавлять клиентов в свои правила. Перезапуск не помогал, выходила куча ошибок (сами ошибки, к сожалению, не сохранил).

но есть кусок dmesg:


HTB: quantum of class 10001 is big. Consider r2q change.
u32 classifier
   Performance counters on
   input device check on
   Actions configured
HTB: quantum of class 10001 is big. Consider r2q change.

 

Пришлось удалить базу, создать новую, только после этого все завелось.

Что такое произошло и как этого избежать в дальнем может кто знает? Photon? Может быть какое-то ограничение на количество?

Edited by ikoctya

Share this post


Link to post
Share on other sites

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

Edited by photon

Share this post


Link to post
Share on other sites

Пока еще не обновился до новой, в планах есть. Копии базы уже нет, могу скинуть в личку актуальную базу.

 

# sc.conf - configuration file for shaper control tool
tc = /sbin/tc
iptables = /sbin/iptables
ipset = /sbin/ipset

out_if = eth3
in_if = eth2

filter_method = u32

limit_method = shaping

debug = 1
verbose = 3
quiet = 0
colored = 1
joint = 0

network = 43.171.182.0/23 42.38.33.0/24 41.148.100.0/22 43.170.180.0/22 45.46.116.0/22 43.171.40.0/22 10.0.0.0/23 10.10.10.0/24 10.1.0.0/24

filter_network = 43.171.182.0/23 42.38.33.0/24 41.148.100.0/22 43.170.180.0/22 45.46.116.0/22 43.171.40.0/22 10.0.0.0/23 10.10.10.0/24 10.1.0.0/24

#bypass_int = 43.171.182.0/28 43.171.183.0/5
#bypass_ext = 1.1.1.1/24

policer_burst_ratio = 0.2
#0.3?????????????

quantum = 1500
rate_unit = kibit
rate_ratio = 1.0
leaf_qdisc = "pfifo limit 50"

db_driver = SQLite
db_host = 127.0.0.1
db_name = /etc/sc/sc.db
db_user = root
db_pass = 123456
query_create = "CREATE TABLE rates (ip UNSIGNED INTEGER PRIMARY KEY, rateUNSIGNED INTEGER NOT NULL)"
query_load = "SELECT ip,rate FROM rates"
query_list = "SELECT ip,rate FROM rates WHERE ip=?"
query_add = "INSERT OR REPLACE INTO rates VALUES (?, ?)"
query_del = "DELETE FROM rates WHERE ip=?"
query_change = "REPLACE INTO rates VALUES (?, ?)"

syslog = 1

Edited by ikoctya

Share this post


Link to post
Share on other sites

Господа, поделитесь рецептом, как уломать sc на несколько интерфейсов ouf_if и in_if?

Share this post


Link to post
Share on other sites
В 12/11/2017 в 10:40, tartila сказал:

Господа, поделитесь рецептом, как уломать sc на несколько интерфейсов ouf_if и in_if?

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

Edited by photon

Share this post


Link to post
Share on other sites

Автор полгода не появляется на форуме. Может, у кого-нибудь есть его альтернативные контакты?

Share this post


Link to post
Share on other sites
В 25.05.2018 в 19:43, Antares сказал:

есть jabber, phonon@jabber.ru 

К сожалению, и там недоступен. Надеюсь, с ним все хорошо.

 

Однако вопрос по фичам из коммерческой версии актуален, возможно, кто-нибудь возьмется дописать недоставющие фичи?

Share this post


Link to post
Share on other sites

А знает ли кто-то режет ли sc multicast траффик от/до хостов имеющих разрешающие правила и заданой скоростью?

Share this post


Link to post
Share on other sites
On 10/12/2018 at 1:10 PM, ikoctya said:

А знает ли кто-то режет ли sc multicast траффик от/до хостов имеющих разрешающие правила и заданой скоростью?

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

Share this post


Link to post
Share on other sites
4 минуты назад, photon сказал:

назначения

Да, разобрался уже. Не пропускал, пока не добавил мультикастовую подсеть в конфиг не сделал sc add 224.0.0.x 10Mibit

 

Может быть ему прикрутить настройку, чтобы он по-умолчанию любой мультикаст пропускал!?

Edited by ikoctya

Share this post


Link to post
Share on other sites
2 hours ago, ikoctya said:

Может быть ему прикрутить настройку, чтобы он по-умолчанию любой мультикаст пропускал!?

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

Share this post


Link to post
Share on other sites

Подскажите где можно ознакомится с описанием коммерческой версии? И насколько реально реализовать приоритизацию трафика по классам внутри полосы к абоненту.

Share this post


Link to post
Share on other sites

Скажите, а можно ли как-то на летц у всех поменять rate_ratio?

В доке есть следующее 

Цитата

The following example of cron instructions shows the realization of "night
rates", when you set rate_ratio = 1.5 at 02:00 and change it back to 1.0 at
07:00 every day.

0 2 * * * root sed -i 's/^rate_ratio.*=.*/rate_ratio = 1.5/g' /etc/sc/sc.conf
0 7 * * * root sed -i 's/^rate_ratio.*=.*/rate_ratio = 1.0/g' /etc/sc/sc.con

...но я так понимаю это будет работать для вновь добавляемых правил.

Share this post


Link to post
Share on other sites
13 часов назад, ikoctya сказал:

Скажите, а можно ли как-то на летц у всех поменять rate_ratio?

В доке есть следующее 

...но я так понимаю это будет работать для вновь добавляемых правил.

3. Periodic synchronization of rules with database

To perform the synchronization of the shaping rules with the database entries
you should edit your crontab file. The following example of crontab(5) entry
creates the cron(8) task which performs the synchronization of the rules every
10 minutes:

*/10 * * * * root /usr/local/sbin/sc sync

4. Night rates and similar stuff

If you want to have the rates, which differ from stored in the database, you
should set the rate_ratio parameter in the sc.conf file with the suitable cron
instruction. There is no need to reload the rules manually, if you use the
task for synchronization every 10 minutes from the example above.

The following example of cron instructions shows the realization of "night
rates", when you set rate_ratio = 1.5 at 02:00 and change it back to 1.0 at
07:00 every day.

0 2 * * * root sed -i 's/^rate_ratio.*=.*/rate_ratio = 1.5/g' /etc/sc/sc.conf
0 7 * * * root sed -i 's/^rate_ratio.*=.*/rate_ratio = 1.0/g' /etc/sc/sc.conf

 

Ну либо sc sync вручную или в кроне пропишите sync каждые 10 минут.  Вообще посмотрите модуль  ipt_ratelimit -  правила обновляет мгновенно и машину грузит не так сильно как шейпер. 

Share this post


Link to post
Share on other sites

А он машину вообще почти не грузит, ее грузит тупо перекладывание пакетов с интерфейса на интерфейс "кернел-софт-ирки"

Share this post


Link to post
Share on other sites

out_if = p2p3
in_if = p2p4
 

В последнее время после запуска системы или sc reload вижу такое в выводе команды ip address:

8: p2p3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 10000
9: p2p4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP qlen 10000
 

т.е. mq стоит, и при этом правила не загружаются из базы командой sc reload, хотя добавляются sc add, но вот с такой ошибкой:

RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: Invalid argument
We have an error talking to the kernel

 

Кто-то сталкивался?
 

Edited by ikoctya

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