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

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

А если используется полисер, куда надо аналогичний кусок кода встатвить?

В функцию pol_dev_init (строка 1578), перед аналогичным фильтром, который режет весь неклассифицированный входящий трафик.

 

И если не сложно черканите код, который будет аналогично маркированые в iptables пакеты пропускать без ограничений.

Я подозреваю, что маркировка iptables модифицирует не пакет как таковой, а структуру данных skbuff, которая существует только в пределах памяти ядра. Поэтому для входящего трафика это бессмысленно, т.к. он не содержит никаких меток iptables. Если нужно разрешать исходящий маркированный трафик, используйте фильтр fwmark.

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

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


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

А если всё-таки надо организовать тарифы с ассиметричной скоростью, как лучше сделать? Могу сделать две копии sc, но надо же два интерфейса для конфига...

Создавать дополнительный виртуальный интерфейс?

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


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

А если всё-таки надо организовать тарифы с ассиметричной скоростью, как лучше сделать? Могу сделать две копии sc, но надо же два интерфейса для конфига...

Создавать дополнительный виртуальный интерфейс?

Проще всего ввести множитель для скоростей на разных интерфейсах. Либо придется вводить в базу скорость на втором интерфейсе.

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

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


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

Я правильно понимаю что подобное с этим скриптом быстро организовать не получится?

 

10.10.164.0/23 - 5 Мбит/с, т.е. для любого хоста подсети /23 5 Мбит/с

10.10.168.0/24 - 10 Мбит/с, для любого хоста подсети /24 10 Мбит/с и т.д.

10.10.175.0/23 - 20 Мбит/с

10.10.184.0/24 - 20 Мбит/с

10.10.200.100 - 1 Мбит/с

10.10.200.200 - 2 Мбит/с

 

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

 

ОС Linux.

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

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


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

Если можно можно было б множитель - нас полностью устроило. Только подскажите, какую функцию/секцию редактировать :) И я готов на любые дополнительные базы данных.

Просто смотрю на самописные конфиги и скрипты от шейпера, который раньше использовали коллеги (и который сейчас надо серьёзно переделывать под новые задачи), потом открываю "man sc" - и меня переполняет непередаваемая тоска.

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


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

Если можно можно было б множитель - нас полностью устроило. Только подскажите, какую функцию/секцию редактировать :) И я готов на любые дополнительные базы данных.

Просто смотрю на самописные конфиги и скрипты от шейпера, который раньше использовали коллеги (и который сейчас надо серьёзно переделывать под новые задачи), потом открываю "man sc" - и меня переполняет непередаваемая тоска.

С множителем легко безклассовый tbf + ingress qdisc полисер на /dev/ppp делать, а nat уже на следующей железке по цепочке стоит, но когда речь про ipoe, то тут как бы другая песня.

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


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

Я правильно понимаю что подобное с этим скриптом быстро организовать не получится?

 

10.10.164.0/23 - 5 Мбит/с, т.е. для любого хоста подсети /23 5 Мбит/с

10.10.168.0/24 - 10 Мбит/с, для любого хоста подсети /24 10 Мбит/с и т.д.

10.10.175.0/23 - 20 Мбит/с

10.10.184.0/24 - 20 Мбит/с

10.10.200.100 - 1 Мбит/с

10.10.200.200 - 2 Мбит/с

 

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

 

ОС Linux.

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

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


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

Я правильно понимаю что подобное с этим скриптом быстро организовать не получится?

 

10.10.164.0/23 - 5 Мбит/с, т.е. для любого хоста подсети /23 5 Мбит/с

10.10.168.0/24 - 10 Мбит/с, для любого хоста подсети /24 10 Мбит/с и т.д.

10.10.175.0/23 - 20 Мбит/с

10.10.184.0/24 - 20 Мбит/с

10.10.200.100 - 1 Мбит/с

10.10.200.200 - 2 Мбит/с

 

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

 

ОС Linux.

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

 

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

 

Поэтому генерировать конфиг по куче хостов как бы не очень хотелось. Ставить БД и заполнять ее хостами тоже не прельщает.

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

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


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

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

 

Поэтому генерировать конфиг по куче хостов как бы не очень хотелось. Ставить БД и заполнять ее хостами тоже не прельщает.

С помощью скрипта genbase можно сгенерировать SQLite-файл /etc/sc/sc.db, где скорости будут распределены по принципу принадлежности хостов к подсетям. SQLite не требует наличия каких-либо демонов СУБД. Либо нужно сделать переработанную версию скрипта, где генераторы правил останутся, а код для работы с базой заменен на вашу схему раздачи скоростей.

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

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


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

Если можно можно было б множитель - нас полностью устроило. Только подскажите, какую функцию/секцию редактировать :) И я готов на любые дополнительные базы данных.

Просто смотрю на самописные конфиги и скрипты от шейпера, который раньше использовали коллеги (и который сейчас надо серьёзно переделывать под новые задачи), потом открываю "man sc" - и меня переполняет непередаваемая тоска.

 

Множитель можно ввести как глобальную переменную, и в функции u32_add передать домноженную скорость при вызове u32_dev_add для нужного интерфейса. Параметр $rate -- это строка вида "10Mibit", так что надо отделить число с помощью регулярного выражения.

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

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


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

Ок, буду пробовать. Глянул код sc - всё красиво, с комментариями. Наверно, даже я смогу разобраться.

Спасибо за нужный проект и проделанную работу :)

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


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

я так понял что реализованы только симметричные тарифы (download/upload) - верно?

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


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

Да, но в рамках существующего кода достаточно легко реализовать несимметричные тарифы с помощью множителя.

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


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

photon Приглянулся Ваш скрипт. Хорошая работа. :)

Скажите, небыло ли где патча для случая когда не нужно шейпить трафик вовсе для определённых сегментов, а весь отдельный тарифик шейпить в соответствии с тарифом. Потребовалась такая возможноть.

Если я правильно вижу её реализацию, это будет выглядеть как:

класс со скоростью интерфейса.

правила будут для сегмента(ов), до тех, что будет строить шейпер автоматом, они же будут отправлять трафик, что не доложен шейпиться в класс, описанный выше.

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

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


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

Патча не было, но я собираюсь сделать похожую возможность в следующей версии. В конфиге будет параметр со списком сетей, которые должны заворачиваться в класс по умолчанию: pass_network = 172.16.0.0/24 172.16.100.0/24

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


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

photon

НУ я пологаю, что будет единственное понятие "класс по умолчанию". Предлагаю ещё ввести такое понятие, как spec_net, например. Трафик этих сетей будет попадать в класс который имеет определённую скорость. К примеру:

- трафик внутри сети/определённые сегменты (скорость одна) - класс (spec_net)

- при подключении абонента, трафик заворачивается в список по умолчанию.

- при его заведении (абонента к примеру в биллинг), его трафик убирается из "по умлчанию", и делится между "spec_net" и личным классом (тариф).

Т.е. класс "По умолчанию", оставить как какой то промежуточный или "default"...

 

Что то подобное, только без умолчания, сейчас делаю из Вашего скрипта. + воспользовался патчем от Петрович-2012 , немного переработав. :)

 

да, к стате, простите что забегаю вперёд, когда ориентировочно патч можно ждать, может вся моя работа будет бесполезной ))))))

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

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


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

По поводу spec_net не знаю. Такая возможность не нужна в большинстве случаев. Новая версия будет скорее всего в середине лета.

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


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

photon Не спорю. Это больше частный случай организации, просто как вариант пердложил на Ваше усмотрение, с которым пришлось столкнуться.

Ждём.

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

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


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

В последнее время я довольно часто пишу на Python и размышляю, не переписать ли sc на этом языке в объектно-ориентированном стиле.

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


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

photon Почему бы и нет, если Вам это ближе. Я бы так и поступил. К тому же лишний опыт. :)

Вот было б исключительно ещё RPC прикрутить к нему, раз уж на Python. Благо там это реализуется весьма не сложно. Ну или сделать это как ДЗ для интузиастов. Удобно было бы управлять шейпером извне.

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


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

По поводу RPC не знаю. Мне всегда хватало управления через командную строку по SSH. Под RPC скорее всего придется менять принцип работы с базой данных: вместо периодических SQL-запросов от шейпера управление по событиям со стороны биллинг-сервера.

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

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


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

не совсем понял , вышла новая версия , а возможности на один класс вешать несколько ip так и не появилось , ладно проблем нет , наложил патч для добавления , да оно добавляется , НО нет правильного кода для вывода правильного списка по сабу cmd_list , т.е если в одной группе находится несколько записей , то покажет последнюю добавленную, как я понял нужно добавить кусок кода в котором должен показывать все записи в классах , а не уникальные (это что бы лишний раз не нагружать дополнительными циклами сам скрипт).

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


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

не совсем понял , вышла новая версия , а возможности на один класс вешать несколько ip так и не появилось , ладно проблем нет , наложил патч для добавления.

Я и не обещал, что там появится функция добавления нескольких IP. Из-за этого придется держать в базе двусвязный список и дописывать кучу кода для корректной работы с ним. Пользователю лучше давать один IP, желательно белый, а все его компьютеры подключать через роутер, которыми заодно можно и приторговывать. В новой минорной версии будет только возможность passthrough, которая позволяет пропускать трафик из определенных сетей без шейпинга. Если найду время, перепишу все на Python в объектном стиле. Тогда можно будет поднять уровень абстракции и добавить управление шейпингом с помощью ipfw/dummynet.

 

да оно добавляется , НО нет правильного кода для вывода правильного списка по сабу cmd_list , т.е если в одной группе находится несколько записей , то покажет последнюю добавленную, как я понял нужно добавить кусок кода в котором должен показывать все записи в классах , а не уникальные (это что бы лишний раз не нагружать дополнительными циклами сам скрипт).

В хэше %rul_data вместо одного IP надо создавать массив всех IP, прицепленных к данному классу.

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

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


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

photon, подскажите как лучше сделать в такой ситуации. Текущая схема в сети: [юзеры]---[шлюз]---[шейпер]---[бгп]---[интернет]. На шлюзе и бгп по несколько гигабитных интерфейсов. При этом сеть от шлюза до бгп распараллелена по нескольким подсетям (что бы поделить трафик по гигабитным каналам, т.к. суммарный уже не помещается в один гигабит). Возникла идея убрать из этой схемы шейпер, а вместо этого шейпировать (методом шейпинга) входящий трафик на бгп (на интерфейсах в сторону шлюза), а исходящий - на шлюзе (интерфейсах в сторону бгп).

 

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

 

Т.е. нужно добиться работы шейпера в двух новых режимах, а именно:

- шейпировать только исходящий трафик (относительно юзеров) = входящий для данного сетевого адаптера

- шейпировать только входящий трафик (для юзеров) = входящий для данного сетевого адаптера, но уже другого маршрутизатора

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


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

Можно поставить несколько шейперов в режиме моста, чтобы не было проблем с пробрасыванием LACP (или чем там у Вас распараллелено). Если нужно шейпить именно на разных машинах, то бгп будет шейпить входящий трафик на внутреннем интерфейсе, а шлюз - исходящий на внешнем. Тогда нужно сделать два скрипта (sc-in, sc-out), в которых будут выборочно закомментированы вызовы функций, создающие правила на внутреннем или внешнем интерфейсе. На интерфейсе $i_if шейпится входящий трафик, на $o_if - исходящий. Типичная функция, создающая правила шейпинга, выглядит так:

sub u32_add
{
       my ($ip, $cid, $rate) = @_;
       my $ceil = $rate;
       my ($ht, $key) = ip_leafht_key($ip);
       u32_dev_add($i_if, $cid, $rate, $ceil, "ip dst $ip", $ht, $key);
       u32_dev_add($o_if, $cid, $rate, $ceil, "ip src $ip", $ht, $key);
       return $?;
}

Чтобы шейпился только входящий трафик, нужно убрать строку, содержащую $o_if, для исходящего - строку c $i_if. Так лучше сделать сразу во всех функциях.

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

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


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

Join the conversation

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

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

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

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

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

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

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