[photon]

Полосу родителя надо поставить равной значению аппаратной скорости интерфейса (гигабит), upstream-провайдер все равно на своей стороне режет.

 

HTB: quantum of class 10001 is big. Consider r2q change.

Наоборот, надо уменьшить значение quantum этого класса.

[codegencolix]

Полосу родителя надо поставить равной значению аппаратной скорости интерфейса (гигабит), upstream-провайдер все равно на своей стороне режет.

 

Дело как раз в том, что у upstream провайдера на оборудовании слишком маленькая очередь, ну а весь остальной трафик соответственно дропается.

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

 

Понятно дело что это не решение проблемы. Скоро будем увеличивать полочку.

[technolab]

Полосу родителя надо поставить равной значению аппаратной скорости интерфейса (гигабит)

Вот уж не согласен...

 

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

Вообще-то у него скорее всего полисинг и планка без шейпинг = потеря пакетов.

 

HTB: quantum of class 10001 is big. Consider r2q change.

http://forum.nag.ru/forum/index.php?showtopic=48277&view=findpost&p=609502 там же и пример есть.

Изменено 27 апреля, 2011 пользователем technolab

[photon]

Да, если там полисинг, то на своей стороне лучше шейпить с запасом в 3-4% от номинальной полосы. Но от потерь это не спасет, если у апстрима забивается приемный буфер. r2q -- это подгоночный параметр, причем с довольно неудачными значениями по умолчанию. Не факт, что между rate и quantum линейная зависимость. Лучше просто присваивать quantum значения, кратные MTU.

Изменено 27 апреля, 2011 пользователем photon

[technolab]

Раз такая пляска пошла, решил я sc под ipset помучить, 4-й - что-то устарел, решил 6 поставить.

Гляжу, а что-то ни наши, ни буржуи его скомпилить не могут. А в kernel-2.6.39-rc5 само собой самого

управляющего скрипта нет - все одно компилить. Вообщем...

 

Экспресс сборка kernel 2.6.38.4 + iptables-1.4.10 + ipset-6.4 на 6-ом протоколе

 

#wget -P /usr/src/ http://ftp.netfilter.org/pub/libmnl/libmnl-1.0.1.tar.bz2 \
http://ftp.netfilter.org/pub/iptables/iptables-1.4.10.tar.bz2 \
http://ftp.netfilter.org/pub/ipset/ipset-6.4.tar.bz2 \
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.38.4.tar.bz2

накачаем исходников

 

#for file in /usr/src/libmnl-1.0.1.tar.bz2 \
/usr/src/iptables-1.4.10.tar.bz2 \
/usr/src/ipset-6.4.tar.bz2 \
/usr/src/linux-2.6.38.4.tar.bz2; \
do tar jxf ${file} -C /usr/src/; done

распакум чего накачали

 

#if [ -d /usr/src/linux ]; then rm /usr/src/linux; fi; \
ln -s /usr/src/linux-2.6.38.4 /usr/src/linux

создадим символьную ссылку

 

#cd /usr/src/linux/ && make clean && make mrproper

перейдем в папку с исходниками ядра и почистим

 

#cp /boot/config-$(uname -r) /usr/src/linux/.config

возьмем конфиг от загруженной системы за шаблон

 

#make menuconfig

>> Load an Alternate Configuration File >> OK >> Exit >> Yes

загрузим "шаблон", конфигурим до "готовности"

(для этой версии ipset нужна поддержка ipv6), выходим

 

#make-kpkg clean

кстати, чистит конфиг от параметров, неактуальных для этого ядра

 

#make-kpkg -j8 --initrd --append-to-version=-\
r6-amd64 kernel_image kernel_headers kernel_source

8 - это ядер у меня, "r6-amd64" - произвольный набор букв

 

#dpkg -i ../*.deb

ну или если в /usr/src уже понакидано других пакетов - ставим по-одному

 

#reboot

грузим новое ядро

 

#cd /usr/src/libmnl-1.0.1 && ./configure && make && make install

идем в папку с библиотекой под ipset кофигурим, компилим, ставим. Сообщения,

типа: "Цель `install-data-am' не требует выполнения команд." игнорируем.

 

#cd /usr/src/linux/ && patch -p1 -f < /usr/src/ipset-6.4/netlink.patch

возвращаемся к исходникам ядра и патчим

 

#cd /usr/src/ipset-6.4 && ./autogen.sh && ./configure && make && make modules && make install && make modules_install

собственно собираем ipset

 

# ipset -v

ipset v6.4, protocol version: 6

проверили

 

#cd /usr/src/iptables-1.4.10 && ./configure && make && make install

ну, научим iptables с этим добром работать

 

Зависимости (debian 6):

#aptitude install kernel-package ncurses-dev module-init-tools initramfs-tools automake libtool pkg-config

остальное вытянется само.

Если хотите - можно ридми почитать и исходники почистить от патча и прочего мусора. Если чего не

получается - в ридми все есть... почти.

Изменено 2 мая, 2011 пользователем technolab

[photon]

Вы сравнивали конфигурации с flow+ipset и хэш-фильтры u32 по производительности (расход процессорного времени и пакетрейт)? Это было бы интересно.

[technolab]

не обещаю в ближайшее время, но обязательно расскажу

[technolab]

К сожалению, пришлось отложить сравнение:

 

1. Изменения синтаксиса iptables с ipset:

$iptables -A $chain_name -p all -m set --match-set $set_name src -j ACCEPT

set --match-set вместо set --set

 

open my $IPH, '-|', "$ipset -L $set_name"

$ipset -L вместо $ipset -nsL

Это поправил.

 

2. flow+ipset. Каждый init и sync добавляют новые правила в iptables не зависимо от их наличия, что приводит к бесчисленному множеству идентичных записей.

Пока не решил, что с этим можно сделать, вернее как это проверять.

 

3. flow+ipset. Есть проблема с созданием и удалением chain_name.

Пока не готов точно сформулировать суть, но работает с ошибками.

 

Зато есть sc-1.3.2.add.11.05.02 с добавленным ceil и root class'ом, соответственно новые переменные в sc.conf:

grate = ширина канала

r2q = коэффициент для расчета quantum root qdisc'а (qdisc не имеет ключа quantum)

ceil_ratio = ровно то, что и rate_ratio, только для ceil

Параметр ceil - новая колонка в db, соответствено синтаксис sc dbadd 192.168.1.1 1024kibit 1024kibit.

Правил код для всех режимов, но адекватно тестил только на u32. Описания и примеры нигде не правил. Тут же изменения указанные в п. 1

 

Название: sc-11.05.02.tar.gz

Размер: 21.35 кб

Доступен до: 2011-06-01 20:04:38

Ссылка для скачивания файла: http://ifolder.ru/23295806

Пароль: nag

[technolab]

да, еще добавил leaf qdisc = 'sfq perturb 10'

[photon]

Для синхронизации ваших изменений с моими рекомендую сделать fork проекта на https://bitbucket.org/sky/sc/

Изменено 3 мая, 2011 пользователем photon

[technolab]

Я только за, только я не знаю, что это такое и с чем его едят :( Посвятите, если не сложно.

[photon]

Основы работы с Mercurial: http://habrahabr.ru/blogs/development_tools/108658/

Для начала, нужно установить себе Mercurial, зарегистрироваться на bitbucket.org, зайти на https://bitbucket.org/sky/sc/ и нажать ссылку fork.

[aran]

Не работает опция переопределения дефолтного конфига (-f/--config). Оно и понятно - разбор командной строки (GetOptions) производится уже после чтения самого конфига ;)

 

Поэтому GetOptions всё же лучше выполнить дважды (до и после чтения конфига)

--- sc.orig	2011-03-05 03:17:46.000000000 +0200
+++ sc	2011-08-17 14:52:53.000000000 +0300
@@ -320,6 +320,9 @@
# Main routine
#

+# get options from command line
+GetOptions(%optd) or exit E_PARAM;
+
# read configuration file
if (-T $cfg_file) {
	my @args = keys %optd;

[photon]

Исправил, спасибо.

[aran]

Часто бывает нужно часть классифицированного трафика пропустить без ограничения скорости. Неплохо бы по какому- либо критерию (например, скорость = 0) просто заворачивать такой траф в корневую дисциплину (flowid 1:) без создания соответствующего класса. Потому как городить для такого трафа кучу бессмысленных классов с заведомо большими скоростями... как-то оно некошерно...

 

Для u32 где-то так:

--- sc.orig     2011-08-19 14:01:52.402334144 +0300
+++ sc  2011-08-19 14:24:35.000000000 +0300
@@ -686,7 +686,7 @@
       my ($num, $unit);

       if (($num, $unit) = $rate =~ /^([0-9]+)([A-z]*)$/xms) {
-               return 0 if $num == 0;
+               # return 0 if $num == 0;
               if (nonempty($unit)) {
                       foreach my $u (keys %units) {
                               if ($unit =~ /^(?:$u)$/xms) {
@@ -1360,7 +1360,9 @@
sub u32_dev_add
{
       my ($dev, $cid, $rate, $ceil, $match, $ht, $key) = @_;
-
+       my ($num, $unit) = $rate =~ /^([0-9]+)([A-z]*)$/xms;
+
+       if($num) {
       $TC->(
               "class replace dev $dev parent 1: classid 1:$cid htb ".
               "rate $rate ceil $ceil quantum $quantum"
@@ -1368,6 +1370,10 @@
       $TC->(
               "qdisc replace dev $dev parent 1:$cid handle $cid:0 $leaf_qdisc"
       );
+       }
+       else {
+           $cid = 0;
+       }
       $TC->(
               "filter replace dev $dev parent 1: pref $pref_leaf ".
               "handle $ht:$key:800 u32 ht $ht:$key: match $match flowid 1:$cid"

Ругаться, правда, будет потом при удалении несуществующего класса/дисциплины, но это несущественно.

Изменено 19 августа, 2011 пользователем aran

[kapa]

А можно пропустить без шейпинга/полисинга трафик только в одну сторону?

[photon]

Часто бывает нужно часть классифицированного трафика пропустить без ограничения скорости. Неплохо бы по какому- либо критерию (например, скорость = 0) просто заворачивать такой траф в корневую дисциплину (flowid 1:) без создания соответствующего класса. Потому как городить для такого трафа кучу бессмысленных классов с заведомо большими скоростями... как-то оно некошерно...

Можно создать один класс с большим rate и ceil под завязку, и отправлять туда трафик от нескольких IP. Такие вещи выходят за пределы применимости данного скрипта. Несколько IP на класс потребуют хранения в базе двусвязного списка, с которым намного сложнее работать.

 

А можно пропустить без шейпинга/полисинга трафик только в одну сторону?

Да.

Изменено 19 августа, 2011 пользователем photon

[aran]

Можно создать один класс с большим rate и ceil под завязку, и отправлять туда трафик от нескольких IP. Такие вещи выходят за пределы применимости данного скрипта. Несколько IP на класс потребуют хранения в базе двусвязного списка, с которым намного сложнее работать.

А зачем отдельный класс? Несколько IP на класс? Я же написал выше - для IP со скоростью скажем 0 просто заворачивать траф в корневую дисциплину, не создавая класса. В этом случае траф пойдёт через корень минуя классы, соответственно без ограничения скорости. Из патча же видно...

+ else {

+ $cid = 0;

+ }

$TC->(

"filter replace dev $dev parent 1: pref $pref_leaf ".

"handle $ht:$key:800 u32 ht $ht:$key: match $match flowid 1:$cid"

 

Кроме того, неплохо бы иметь возможность задания подсетей, трафик которых опять же проходит минуя шейпер без ограничений. Живой пример: у меня своя AS и 2 аплинка. Шейпить мне нужно подсети своей АС.НО! На аплинках тоже ведь есть IP адреса. И эти адреса отнюдь не принадлежат моей АС, а ппринадлежат АС магистрального провайдера, нужны только для обеспечения BGP маршрутизации и к шейпингу никакого отношения не имеют. Тем не менее, чтобы всё работало, я вынужден рисовать в конфиге шейпера какие-то подсети для этих IP, указывать эти IP в базе, для них будут создаваться никому не нужные классы... Не маразм ли? Просто ввести параметр, скажем nonshapednets = ... где перчислить такие IP. И трафик с/на них опять же заворачивать в корневую дисципдину без всяких классов.

 

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

Изменено 20 августа, 2011 пользователем aran

[photon]

А зачем отдельный класс? Несколько IP на класс? Я же написал выше - для IP со скоростью скажем 0 просто заворачивать траф в корневую дисциплину, не создавая класса. В этом случае траф пойдёт через корень минуя классы, соответственно без ограничения скорости. Из патча же видно...

Я не совсем понимаю, что значит "для IP со скоростью 0". Имеется в виду, что трафик от IP, у которых в базе указана нулевая скорость, нужно направлять в корневой класс? Мы все равно приходим к схеме "несколько IP на один класс", просто этот класс корневой. Если список таких подсетей или IP-адресов будет указан в каком-то параметре конфига, а не в базе, то будет проще.

 

Кроме того, неплохо бы иметь возможность задания подсетей, трафик которых опять же проходит минуя шейпер без ограничений. Живой пример: у меня своя AS и 2 аплинка. Шейпить мне нужно подсети своей АС.НО! На аплинках тоже ведь есть IP адреса. И эти адреса отнюдь не принадлежат моей АС, а ппринадлежат АС магистрального провайдера, нужны только для обеспечения BGP маршрутизации и к шейпингу никакого отношения не имеют.

Шейпить лучше на отдельной машине (на мосту перед бордером), тогда эти проблемы отпадут.

Изменено 20 августа, 2011 пользователем photon

[aran]

Я не совсем понимаю, что значит "для IP со скоростью 0". Имеется в виду, что трафик от IP, у которых в базе указана нулевая скорость, нужно направлять в корневой класс?

Не в корневой класс, а в корневую дициплину!...flowid 1:0 И классы для таких IP вообще не создавать!

Мы все равно приходим к схеме "несколько IP на один класс", просто этот класс корневой.

Не приходим! По указанной выше разнице между классом и дисциплиной.

Шейпить лучше на отдельной машине (на мосту перед бордером), тогда эти проблемы отпадут.

Ясен пень, что лучше... Только вот шейпинг на аплинки-то раздельный! Один аплинк смотрит в IX, а другой - во внешний мир. И скорости на ресурсы IX и на всё остальное - разные! А в какой аплинк уйдёт пакет станет известно только после решения о BGP маршрутизации на бордере!

 

Вот и выходит, что шейпить аплоад можно только на аплинках, а даунлоад - на привязанных к ним IFB. Схема следующая:

 

vlan1553 - аплинк в UA-IX

vlan1552 - аплинк во внешний мир

 

на vlan 1552:

 

tc filter ls dev vlan1552 parent ffff:

filter protocol ip pref 10 u32

filter protocol ip pref 10 u32 fh 800: ht divisor 1

filter protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1

match 00000000/00000000 at 0

action order 1: mirred (Egress Redirect to device ifb1552) stolen

index 1 ref 1 bind 1

 

на vlan 1553:

 

tc filter ls dev vlan1553 parent ffff:

filter protocol ip pref 10 u32

filter protocol ip pref 10 u32 fh 800: ht divisor 1

filter protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1

match 00000000/00000000 at 0

action order 1: mirred (Egress Redirect to device ifb1553) stolen

index 1 ref 1 bind 1

 

Соответственно 2 конфига и 2 базы sc (для ua-ix и мира)

 

uaix.conf

...

# Network interfaces

out_if = vlan1553

in_if = ifb1553

...

# Database name (or filename for SQLite driver)

db_name = /etc/sc/uaix.db

 

world.conf

...

# Network interfaces

out_if = vlan1552

in_if = ifb1552

...

# Database name (or filename for SQLite driver)

db_name = /etc/sc/world.db

 

Ну и запускается вот так:

 

sc -f /etc/sc/world.conf start

sc -f /etc/sc/uaix.conf start

 

Впрочем, всё вышесказанное про IP с нулевой скоростью (нешейпируемые IP из своих сетей), и нешейпируемые IP из чужих сетей я уже практически допилил. Сегодня отлажу и выложу патч.

 

ЗЫ: А зачем полисинг делается именно в ингрессе? Делали бы уже в егрессе, как и шейпинг, для совместимости. А в качестве корневой дисциплины - какую-нибудь дефолтную прио или пфифо... А то как быть ежли у меня, например, в ингрессе стоит редирект на IFB?

 

ЗЫ2: И вообще... зачем для полисинга 2 ифейса? О.О. В ингрессе - полисинг даунлоад, в егрессе - аплоад... :D

Изменено 21 августа, 2011 пользователем aran

[photon]

Не в корневой класс, а в корневую дициплину!...flowid 1:0 И классы для таких IP вообще не создавать!

Это терминологически некорректно. Дисциплина -- это алгоритм обработки пакетов, а класс -- это очередь. Нельзя перенаправить пакеты в алгоритм. В общем, я понял.

 

ЗЫ: А зачем полисинг делается именно в ингрессе?

1) На егрессе некоторые люди делают NAT. что затрудняет классификацию. Собственно, конфигурация policing+shaping на внутреннем интерфейсе для этого случая и была реализована, а не для штатного использования. Всегда лучше шейпить, т.к. полисинг тупо отбрасывает пакеты, это может создать проблемы для трафика, чувствительного к потерям.

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

 

Впрочем, всё вышесказанное про IP с нулевой скоростью (нешейпируемые IP из своих сетей), и нешейпируемые IP из чужих сетей я уже практически допилил. Сегодня отлажу и выложу патч.

Хорошо. Это деловой подход.

 

ЗЫ2: И вообще... зачем для полисинга 2 ифейса? О.О. В ингрессе - полисинг даунлоад, в егрессе - аплоад... :D

Полисинг вешается на егресс? Пруф (рабочий набор правил) или не было. Отправлять не все пакеты из очереди как-то нелепо.

Изменено 21 августа, 2011 пользователем photon

[aran]

Дисциплина -- это алгоритм обработки пакетов, а класс -- это очередь.

Да, дисциплина - это алгоритм обработки... + очередь... а вот классы как раз никакого отношения к очередям не имеют. Привязянные к классам краевые дисциплины - да, но никак не классы.

Нельзя перенаправить пакеты в алгоритм

Повторюсь - в алгоритм + очередь. Очень даже можно... и часто и густо - нужно. Между прочим, сама дисциплина HTB, для которой не задан дефолтный класс, весь неклассифицированный траф как раз и заворачивает в корень - в себя ;)

Полисинг вешается на егресс? Пруф (рабочий набор правил)

Лёгко

tc qdisc add dev eth0 root handle 1: prio
tc qdisc add dev eth0 ingress handle ffff:
tc filter add dev eth0 parent 1: prio 1 proto ip u32 match ip src 1.2.3.4 police rate 1mibit burst 100kb action drop flowid 1:
tc filter add dev eth0 parent ffff: prio 1 proto ip u32 match ip dst 1.2.3.4 police rate 1mibit burst 100kb action drop flowid ffff:

tc qdisc ls dev eth0
qdisc prio 1: root refcnt 9 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc ingress ffff: parent ffff:fff1 ----------------

tc -p filter ls dev eth0 parent 1:
filter protocol ip pref 1 u32
filter protocol ip pref 1 u32 fh 800: ht divisor 1
filter protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:
 match IP src 1.2.3.4/32
police 0x7 rate 1049Kbit burst 100Kb mtu 2Kb action drop overhead 0b
ref 1 bind 1

tc -p filter ls dev eth0 parent ffff:
filter protocol ip pref 1 u32
filter protocol ip pref 1 u32 fh 800: ht divisor 1
filter protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid ffff:
 match IP dst 1.2.3.4/32
police 0x8 rate 1049Kbit burst 100Kb mtu 2Kb action drop overhead 0b
ref 1 bind 1

Симметричный чистый полисинг на 1 ифейсе без всяких классов. Или вы считаете, что такое не будет работать? Обоснуйте ;)

 

Вот я и говорю, что чистый полисинг нужно делать на 1-м ифейсе, а в зависимости от того, какой ифейс прописан в конфиге (out_if или in_if) делать привязку даунлоад/аплоад (match src/match dst).

На егрессе некоторые люди делают NAT. что затрудняет классификацию.

А в случае NAT'а на шейпируемом ифейсе монопенисуально егресс или ингресс. Исходящий пакет на таком ифейсе будет с уже транслированным адресом, а входящий - с ещё не детранслированным (адресованным маршрутизатору) :D

 

ЗЫ: Возникла мысль в качестве краевой дисциплины ещё и RED прикрутить с вычислением параметров в зависимости от скорости... Очень интересная дисциплина ;)

Изменено 22 августа, 2011 пользователем aran

[photon]

Симметричный чистый полисинг на 1 ифейсе без всяких классов. Или вы считаете, что такое не будет работать? Обоснуйте ;)

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

 

Вот я и говорю, что чистый полисинг нужно делать на 1-м ифейсе, а в зависимости от того, какой ифейс прописан в конфиге (out_if или in_if) делать привязку даунлоад/аплоад (match src/match dst).

На егрессе некоторые люди делают NAT. что затрудняет классификацию.

А в случае NAT'а на шейпируемом ифейсе монопенисуально егресс или ингресс. Исходящий пакет на таком ифейсе будет с уже транслированным адресом, а входящий - с ещё не детранслированным (адресованным маршрутизатору) :D

Я имел в виду, что NAT делается на внешнем интерфейсе, поэтому шейпинг+полисинг сидят на внутреннем. Я считаю, что NAT (если от него все еще не избавились) лучше делать не на шейпере, а на бордере и не морочить себе голову с полисингом. Какие преимущества у других конфигураций, по сравнению с теми, что уже реализованы? Зачем раздувать скрипт, в котором и так более 2000 строк кода, ради экзотических конфигураций, которые нужны 1% пользователей? Надо бы на модули его побить и тогда уже что-то добавлять.

 

Возникла мысль в качестве краевой дисциплины ещё и RED прикрутить с вычислением параметров в зависимости от скорости... Очень интересная дисциплина ;)

В RED есть смысл, когда ширина внешнего канала уже поджимает и когда очереди на шейпере заполняются из-за того, что юзер интенсивно качает. Дефицитным ресурсом в случае нагруженного PC-шного шейпера является процессорное время, а не память, а RED расходует его больше, чем FIFO. Можно получить и отрицательный эффект из-за перегруженности процессора.

Изменено 22 августа, 2011 пользователем photon

[aran]

Не работает опция переопределения дефолтного конфига (-f/--config). Оно и понятно - разбор командной строки (GetOptions) производится уже после чтения самого конфига ;)

 

Поэтому GetOptions всё же лучше выполнить дважды (до и после чтения конфига)

Исправил, спасибо.

Там ещё, если так делать, то перед вторым вызовом GetOptions @ARGV нужно взад возвращать, ибо

The command line options are taken from array @ARGV. Upon completion of GetOptions, @ARGV will contain the rest (i.e. the non-options) of the command line.

:)

[SokolovS]

Вот хочу посоветоваться. У меня трафик до 900 Мбит, 150kpps, 8к хэшироанных правил.

Ради интереса решил переключить с sfq на pfifo, график по трафику резко упал почти в два раза, благо ночью тестил. В один поток скорость прекрасная, странички быстро отдаются, а вот торрент раскачать сложнее. Вернул обратно sfq, трафик опять в норму вернулся... ох уж эти торренты. Это нормальное поведение? Или чо-то нужно подкрутить?

 

Есть ли смысл перейти совсем на ingress полисинг, на двух интерфейсах, чтобы нагрузку от прерываний по ядрам более равномерно раскидать? Если что, НАТ не нужен, есть аппаратная поддержка на бордере. Минимальный тариф 3 Мбит.

Изменено 16 октября, 2011 пользователем SokolovS