[shicoy]

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

Изменено 28 октября, 2010 пользователем shicoy

[SokolovS]

Шейпер нужно было в разрез ставить, а ней шейпить на оборудовании с аплинками )

[shicoy]

Угу, но вот такая структура....

[red_neon]

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

 

Если все работает, то лучше оставить offload как есть, т.к. настройки, отключенные по умолчанию, как правило не оттестированы и только подрывают стабильность.

Забыл упомянуть о том что я уже писал содержимое файла рц.локал, в котором были такие строки:

/usr/sbin/ethtool -K eth0 tso off tx off sg off

/usr/sbin/ethtool -K eth1 tso off tx off sg off

 

Максимум что на шейпере надо оффлоадить -- это rx и tx checksumming, т.к. MAC-адреса все же меняются. А всякие segmentation и fragmentation не нужны, конечно.

tx off - получается нужно вернуть в on?

 

-----------------------------------

 

Есть возможность добавить?:

1.несимметричность скоростей, т.е. например входящая 10мбит, исходящая 5мбит.

2.шейпинг+полисинг на одной сетёвке (если сервер представляет собой 3в1: шлюз+шейпер+бгп).

3.табличка с приоритетами трафика с фильтрами по: протоколу, протокол+порт (в основном что бы игруны не жаловались).

 

[photon]

1.несимметричность скоростей, т.е. например входящая 10мбит, исходящая 5мбит.

Это хорошая мысль, я тоже об этом когда-то думал. Достаточно просто реализовать это дело в виде множителя, на который домножается download rate.

 

2.шейпинг+полисинг на одной сетёвке (если сервер представляет собой 3в1: шлюз+шейпер+бгп).

Странная конфигурация, но тоже можно реализовать. Чудо-комбайны 3 в 1 лучше не делать, как показывает мой опыт.

 

3.табличка с приоритетами трафика с фильтрами по: протоколу, протокол+порт (в основном что бы игруны не жаловались).

А вот это неправильно, т.к. если создавать внутри каждого пользовательского класса еще какие-то подклассы, скрипт распухнет строк на 500 минимум. Кроме того, это в разы уменьшит максимальное число обслуживаемых пользователей (если делать, скажем, по 6 классов на юзера, то мы уже ограничены примерно 10900 IP-адресами на шейпер). Приоритизацию разных типов трафика надо делать на отдельной машине, тогда все будет гораздо проще. Лучше, когда этим занимается отправитель, т.е. пользовательское приложение. Все вменяемые сетевые службы заполняют биты DSCP в IP-заголовке, и на всех узлах приоритизация делается автоматом, потому что упорядочивание трафика на основе поля DSCP забито в сетевом стеке.

Изменено 30 октября, 2010 пользователем photon

[shicoy]

Ну сделать поддержку нескольких интерфейсов довольно просто: надо в нужных местах вставить циклы вида

foreach my $oif (@o_if) { ... }

foreach my $iif (@i_if) { ... }

и заменить в правилах $o_if на $oif, $i_if на $iif.

 

Я сейчас весьма занят, поэтому некогда этим заниматься, да и незачем.

Возникла проблема с чтением конфига :(

 

out_if = ('uplink0','uplink1')

in_if = ('downlink0','downlink1')

 

 

# sc init

Not a SCALAR reference at /usr/local/sbin/sc line 334.

Изменено 29 октября, 2010 пользователем shicoy

[photon]

Предлагаю оставить $out_if и $in_if скалярными переменными, но парсить их как comma-separated lists:

out_if = eth0,eth1

 

my @o_if = split(/,/ixms, $out_if);

Изменено 30 октября, 2010 пользователем photon

[shicoy]

При загрузке большого кол-ва правил (около 5к) из БД получаем следующее:

 

RTNETLINK answers: Invalid argument

We have an error talking to the kernel

Command failed (null):6173

 

при этом загружается порядка 1200 правил.

 

[photon]

При загрузке большого кол-ва правил (около 5к) из БД получаем следующее:

 

RTNETLINK answers: Invalid argument

We have an error talking to the kernel

Command failed (null):6173

 

при этом загружается порядка 1200 правил.

Это в моей или в пропатченной вами версии? Загружайте правила следующей командой, чтобы увидеть, где он спотыкается: sc -v 2 -d 1 load

[shicoy]

в патченой.

через полчаса запущу с дебагом посмотрю

Изменено 30 октября, 2010 пользователем shicoy

[shicoy]

RTNETLINK answers: Invalid argument
We have an error talking to the kernel
/sbin/tc filter replace dev eth5 parent ffff: pref 20 handle 208:0 u32 ht 208:0: match ip dst 109.248.132.0 police rate 20480kibit burst 1500Kb drop flowid ffff:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
/sbin/tc filter replace dev eth6 parent ffff: pref 20 handle 208:0 u32 ht 208:0: match ip dst 109.248.132.0 police rate 20480kibit burst 1500Kb drop flowid ffff:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
/sbin/tc filter replace dev eth3 parent ffff: pref 20 handle 208:0 u32 ht 208:0: match ip src 109.248.132.0 police rate 20480kibit burst 1500Kb drop flowid ffff:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
/sbin/tc filter replace dev eth4 parent ffff: pref 20 handle 208:0 u32 ht 208:0: match ip src 109.248.132.0 police rate 20480kibit burst 1500Kb drop flowid ffff:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
/sbin/tc filter replace dev eth5 parent ffff: pref 20 handle 206:0 u32 ht 206:0: match ip dst 109.248.130.0 police rate 10240kibit burst 1500Kb drop flowid ffff:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
/sbin/tc filter replace dev eth6 parent ffff: pref 20 handle 206:0 u32 ht 206:0: match ip dst 109.248.130.0 police rate 10240kibit burst 1500Kb drop flowid ffff:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
/sbin/tc filter replace dev eth3 parent ffff: pref 20 handle 206:0 u32 ht 206:0: match ip src 109.248.130.0 police rate 10240kibit burst 1500Kb drop flowid ffff:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
/sbin/tc filter replace dev eth4 parent ffff: pref 20 handle 206:0 u32 ht 206:0: match ip src 109.248.130.0 police rate 10240kibit burst 1500Kb drop flowid ffff:

 

С одной стороны может показаться странным использование IP с адресом .0, но это нормально т.к. подсеть больше чем /24

 

Изменено 30 октября, 2010 пользователем shicoy

[photon]

С одной стороны может показаться странным использование IP с адресом .0, но это нормально т.к. подсеть больше чем /24

А какие значения параметров network и filter_network указаны в конфиге sc.conf? Это нужно, чтобы воспроизвести у себя создание фильтров.

 

[shicoy]

network = 91.197.172.0/22 109.248.128.0/17

filter_network = 91.197.172.0/22 109.248.128.0/17

 

[photon]

Воспроизвел это дело. Помимо 109.248.130.0 есть проблемы с такими IP: 109.248.129.0, 109.248.131.0, 91.197.173.0, 91.197.174.0, 91.197.175.0. Лучше не использовать IP с нулевыми октетами, т.к. я подозреваю, что нулевой ключ в параметре ht 208:0: использовать нельзя. Это ограничение, накладываемое tc.

Изменено 30 октября, 2010 пользователем photon

[shicoy]

Понятно. Спасибо.

Кстати, а чем вызвана необходимость вешать правила на аплинк интерфес? Нельзя ограничиться только интерфейсом в сторону абонентов?

[photon]

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

[shicoy]

насколько сложно? или может быть подскажите в каком направлении копать? сам попробую (хотя с tc не очень дружу)

[photon]

насколько сложно? или может быть подскажите в каком направлении копать? сам попробую (хотя с tc не очень дружу)

Ну с tc разбираться вообще не придется, т.к. все нужные правила уже есть. Надо исправлять sc. Начинать надо с функции set_ptrs, которая определяет, какие правила будут создаваться. Нужно ввести новое значение limit_method = hybrid, добавить код для обработки этого случая и создать функции rul_*_hybrid, в которые следует скопировать часть кода из rul_*_u32 и rul_*_policer, чтобы правила создавались только на интерфейсе in_if. Работать лучше с последним коммитом sc, в котором я сделал отдельные функции для создания правил на интерфейсах.

Функции rul_*_hybrid будут выглядеть примерно так:

sub rul_add_hybrid {
  ...
  dev_add_policer($in_if, ...);
  dev_add_u32($in_if, ...);
  ...
}

Изменено 30 октября, 2010 пользователем photon

[shicoy]

т.е. если мы создаем правила только на In интерфейсе то у нас будет лимитироваться трафик в сторону юзеров?

а если на Out То в сторону аплинка?

но почему нельзя заюзать что то типа

 

tc qdisc add dev eth_in handle ffff:xxxx ingress

tc filter add dev eth_in parent ffff:xxxx protocol ip prio 50 u32 police rate ${upload}kbit burst 1536kb drop flowid :1

 

для трафика со стороны юзера?

 

 

т.е. что бы тупо дропнуть трафик на интерфейсе который смотрит на абонентов и который превышает указанные лимиты?

[photon]

но почему нельзя заюзать что то типа

 

tc qdisc add dev eth_in handle ffff:xxxx ingress

tc filter add dev eth_in parent ffff:xxxx protocol ip prio 50 u32 police rate ${upload}kbit burst 1536kb drop flowid :1

Я так и предлагаю. На внутреннем интерфейсе in_if (который смотрит в вашу сеть) создаются правила для полисинга и для шейпинга. В этом случае, исходящий от юзера трафик полисится, а идущий к юзеру -- шейпится.

Изменено 30 октября, 2010 пользователем photon

[shicoy]

все теперь понял, на днях буду пробовать.

[photon]

все теперь понял, на днях буду пробовать.

За пару часов слабал shaping + policing на одном интерфейсе. Включается с помощью limit_method = hybrid в конфиге. Качайте версию 1.3.0. Туда остается добавить только код по поддержке нескольких интерфейсов. Я не стал это делать, т.к. не вижу смысла в поддержке экзотических конфигураций.

Изменено 31 октября, 2010 пользователем photon

[shicoy]

Спасибо :)

В настройке соотвественно указывам только in интерфейс?

Изменено 31 октября, 2010 пользователем shicoy

[SokolovS]

Если сетевуха интел то неплохо бы разделить на очереди tx/rx. А то все softirq свалятся на одно ядро.

[photon]

Вообще, было бы интересно сравнить эффективность shaping + shaping на двух интерфейсах и shaping + policing на одном. Если не сложно, отпишитесь потом по поводу нагрузок.