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

[photon]

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

 

Реализована простейшая схема: один IP на класс обслуживания с фиксированной полосой пропускания. В качестве источника данных может быть использована любая SQL-база, поддерживаемая Perl DBI. Для классификации трафика используются наиболее оптимальные методы: фильтр flow в связке с ipset или хэширующие фильтры u32 (по выбору). Для u32 реализованы шейпинг и полисинг. Загрузка и синхронизация правил для тысяч IP-адресов происходит за секунды благодаря использованию пакетных режимов tc и ipset.

 

Страница проекта на Sourceforge: http://sourceforge.net/projects/sc-tool/

Зеркало проекта на Bitbucket: http://bitbucket.org/sky/sc/src

Edited March 18, 2012 by photon

[Ivan Rostovikov]

Поясните, как и для чего используется ipset ?

[photon]

ipset используется для работы со списком IP-адресов, которым разрешен доступ в Internet.

[Мартен]

sub is_ip
{
        my $ip = shift;

        if ($ip =~ /^(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})/ixms) {
                if ($1 >  0 && $1 <  255 && $2 >= 0 && $2 <= 255 &&
                        $3 >= 0 && $3 <= 255 && $4 >= 0 && $4 <  255) {
                        return $ip;
                }
        }
        return 0;
}

 

проверка некорректная. предполагается, что 4й октет не достигает значения 255, однако в общем случае это может произойти (например, при клиентской маске /23 - 172.16.0.255/23 вполне нормальный адрес хоста).

под убунтой hardy не запускается -

"GetOptionsFromArray" is not exported by the Getopt::Long module
Can't continue after import errors at /usr/local/sbin/sc line 6
BEGIN failed--compilation aborted at /usr/local/sbin/sc line 6.

все пакеты установлены, как сказано в README.

 

 

[a0d75]

Уважаемый photon, вы пробовали sch_flow под нагрузкой? Производительность сопоставима с хэшфильтрами?

[Мартен]

проблема с незапуском решилась установкой Getopt::Long из CPAN.

надо бы добавить в список зависимостей.

Edited November 27, 2009 by Мартен

[vladd]

А если встречаются клиенты, у которых несколько IP-адресов, и надо делить между ними одну очередь?

[Max P]

а если нужно однозначно определять classid по всем 4м октетам ip-адреса?

[photon]

а если нужно однозначно определять classid по всем 4м октетам ip-адреса?

Максимальное число классов -- 0xFFFF, а IP-адресов -- 0xFFFFFFFF, поэтому взаимно-однозначного соответствия не получится. Для частного случая можно придумать какие-то фильтры с арифметическими операциями: http://forum.nag.ru/forum/index.php?showto...st&p=428578 . С другой стороны, с помощью фильтра u32 можно строить вложенные хэши по 256 записей и тоже покрыть необходимые адреса.

[Max P]

фильтры то может и покроешь, а вот как быть конкретно с tc class id? ведь их больше чем 0xFFFF не сделаешь, хоть какими операциями

[photon]

Уважаемый photon, вы пробовали sch_flow под нагрузкой? Производительность сопоставима с хэшфильтрами?

Производительность flow немного лучше (не в разы, softirq снизилось процентов на 10 в пиках). С другой стороны, использование u32 hf позволяет обойтись без ipset и iptables для блокирования должников, т.к. трафик можно дропать с помощью filter policies в дочерних фильтрах. На этом тоже можно сэкономить, но с такой конфигурацией я не сравнивал. Наверное в скрипте стоит реализовать оба варианта: flow и u32 hashing filters, чтобы можно было выбирать.

Edited November 28, 2009 by photon

[photon]

фильтры то может и покроешь, а вот как быть конкретно с tc class id? ведь их больше чем 0xFFFF не сделаешь, хоть какими операциями

Да, код в ядре слишком заточен под следующее представление: старшие два байта -- номер родительского класса, младшие -- дочернего.

[Max P]

если б можно было делать хотя бы так classid СТАРШИЕ:МЛАДШИЕ то было бы супер, а то только 1: :(

[photon]

Имеет ли смысл сделать генератор вложенных хэширующих фильтров, чтобы можно было классифицировать нескольких подсетей по /16? Мне самому это в production не надо, просто так, чтобы ум чем-то занять.

Edited December 4, 2009 by photon

[shicoy]

Имеет, очень часто встречаются конфигурации сетей вроде таких:

 

85.x.x.x/20

и

172.24.x.x/16

 

и тех и других надо шейпить, аксесить и т.д.

 

[photon]

85.x.x.x/20 и 172.24.x.x/16

Ну это потому что люди не перешли полностью на белые адреса, и таким образом сами себе создали проблему. Один только NAT чего стоит. Но, наверное, все сети с этого начинают, поэтому смысл действительно есть.

[shicoy]

Ну а если 2 и более диапазона белых адресов? например 85.x.x.x/20 и 89.x.x.x/19 и еще в придачу 213.x.x.x/19

 

в наше время не IPподсети по оборудование подстараивают, а наоборот.

[shicoy]

Вообщем возможность "генератор вложенных хэширующих фильтров, чтобы можно было классифицировать нескольких подсетей по /16" была бы крайне полезной.

[shicoy]

photon что нить получается?

 

[photon]

Ну, само вычисление classid, ключей и номеров хэш-фильтров и генератор правил получаются, почему бы нет. Но я иногда сталкиваюсь со странным багом в tc. После массового создания вложенных хэш-фильтров и пары-тройки классов, команда tc class show dev eth0 иногда начинает показывать какой-то мусор: кучу классов со случайными id и значениями скоростей, которые я явно не создавал. Причем, это на новых версиях tc и ядра. Надо по этому поводу багрепорт настрочить.

Edited December 9, 2009 by photon

[shicoy]

Может баг с отображением или классы реально создаются?

[Max P]

а я вот думаю распилить скажем 10.0.0.0/8 на 255 ifb по /16 маске и там уже понавешать классов, а фильтр завернуть через flow map, дабы потом скриптом только классы добавлять-удалять, а filter даже не трогать

[photon]

Может баг с отображением или классы реально создаются?

Оказывается, это я забыл, что в crontab был настроен автозапуск синхронизации правил с базой. (:

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

Edited December 9, 2009 by photon

[shicoy]

Здорово! Ждем ждем =)

[shicoy]

"Несколько IP на один класс" - каждый IP будет шейпится индивидуально? или все IP в классе будут делить полосу?