[Sysadmins] Исходящий шейпинг

[Sysadmins] Исходящий шейпинг

[ahtoh]

Привет.

Вопрос в следующем, как лучше в ALTServer сделать шейпинг исходящего траффика,
на шлюзе с двумя интерфейсами.
Сейчас у меня реализовано это через IMQ-патч. Но в сборке ядра в ALT этого 
патча по умолчанию нет. Собирал сам.
Как предпологается в ALT это делать?
Пробывал через -j MARK, но по сравнению с IMQ получал значительное увеличение 
загрузки процессора.

Re: [Sysadmins] Исходящий шейпинг

[ahtoh]

В сообщении от Четверг 10 января 2008 ahtoh@pulnet.ru написал(a):
> Привет.
>
> Вопрос в следующем, как лучше в ALTServer сделать шейпинг исходящего
> траффика, на шлюзе с двумя интерфейсами.
> Сейчас у меня реализовано это через IMQ-патч. Но в сборке ядра в ALT этого
> патча по умолчанию нет. Собирал сам.
> Как предпологается в ALT это делать?
> Пробывал через -j MARK, но по сравнению с IMQ получал значительное
> увеличение загрузки процессора.
>
> _______________________________________________
> Sysadmins mailing list
> Sysadmins@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/sysadmins

Неужели никто не знает?

Re: [Sysadmins] Исходящий шейпинг

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

В Чтв, 10/01/2008 в 00:13 +0300, ahtoh@pulnet.ru пишет:
> Сейчас у меня реализовано это через IMQ-патч. Но в сборке ядра в ALT этого 
> патча по умолчанию нет. Собирал сам.
> Как предпологается в ALT это делать?

Посмотрите в сторону IFB, по идее он должен быть в alt'е.

-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Sysadmins] Исходящий шейпинг

[ahtoh]

В сообщении от Пятница 11 января 2008 Peter Volkov написал(a):
> В Чтв, 10/01/2008 в 00:13 +0300, ahtoh@pulnet.ru пишет:
> > Сейчас у меня реализовано это через IMQ-патч. Но в сборке ядра в ALT
> > этого патча по умолчанию нет. Собирал сам.
> > Как предпологается в ALT это делать?
>
> Посмотрите в сторону IFB, по идее он должен быть в alt'е.

А что это за зверь?

Re: [Sysadmins] Исходящий шейпинг

[Denis Klimov]

On Fri, 11 Jan 2008 14:10:45 +0300 ahtoh@pulnet.ru wrote:

> В сообщении от Пятница 11 января 2008 Peter Volkov написал(a):
> > В Чтв, 10/01/2008 в 00:13 +0300, ahtoh@pulnet.ru пишет:
> > > Сейчас у меня реализовано это через IMQ-патч. Но в сборке ядра в ALT
> > > этого патча по умолчанию нет. Собирал сам.
> > > Как предпологается в ALT это делать?
> >
> > Посмотрите в сторону IFB, по идее он должен быть в alt'е.
> 
> А что это за зверь?

http://www.opennet.ru/tips/info/1421.shtml

В альте он есть и работает стабильно. я его использую для ограничения
входящего трафика на несколько ppp интерфейсов.

Если Вам необходимо шейпить исходящий трафик для небольшого количества
интерфейсов, то IFB нет смысла использовать.

--
Denis Klimov 
zver

Re: [Sysadmins] Исходящий шейпинг

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

В Птн, 11/01/2008 в 16:30 +0500, Denis Klimov пишет:
> Если Вам необходимо шейпить исходящий трафик для небольшого количества
> интерфейсов, то IFB нет смысла использовать.

А что имеет использовать?

-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Sysadmins] Исходящий шейпинг

[Denis Klimov]

On Sat, 12 Jan 2008 12:00:02 +0300 Peter Volkov wrote:

> А что имеет использовать?

почитайте LARTC. там есть примеры, которые наверняка Вам подойдут.
--
Denis Klimov 
zver

Re: [Sysadmins] Исходящий шейпинг

[Denis Klimov]

On Sat, 12 Jan 2008 12:00:02 +0300 Peter Volkov wrote:

> А что имеет использовать?

почитайте LARTC. там есть примеры, которые наверняка Вам подойдут.
--
Denis Klimov 
zver

Re: [Sysadmins] Исходящий шейпинг

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

В Пнд, 14/01/2008 в 14:36 +0500, Denis Klimov пишет:
> On Sat, 12 Jan 2008 12:00:02 +0300 Peter Volkov wrote:
> > А что имеет использовать?
> 
> почитайте LARTC. там есть примеры, которые наверняка Вам подойдут.

Денис, мне доводилось читал LARTC, поэтому и возник вопрос: что вы
имеете ввиду? Какая существует альтернатива IMQ / IFB (последнего, между
прочим, в lartc нет), пусть даже для двух интерфейсов?

-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Sysadmins] Исходящий шейпинг

[ahtoh]

В сообщении от Вторник 15 января 2008 Peter Volkov написал(a):
> В Пнд, 14/01/2008 в 14:36 +0500, Denis Klimov пишет:
> > On Sat, 12 Jan 2008 12:00:02 +0300 Peter Volkov wrote:
> > > А что имеет использовать?
> >
> > почитайте LARTC. там есть примеры, которые наверняка Вам подойдут.
>
> Денис, мне доводилось читал LARTC, поэтому и возник вопрос: что вы
> имеете ввиду? Какая существует альтернатива IMQ / IFB (последнего, между
> прочим, в lartc нет), пусть даже для двух интерфейсов?

Можно только метить пакеты с помощью -j MARK
А уже на исходящем интерфейсе фильтровать по марке с помощью tc filter.
Тогда не нужны псевдоинтерфейсы.
INGRESS можно не рассматривать т.к. он ограниченный.

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

Re: [Sysadmins] Исходящий шейпинг

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 3475 bytes --]

В Втр, 15/01/2008 в 20:16 +0300, ahtoh@pulnet.ru пишет:
> В сообщении от Вторник 15 января 2008 Peter Volkov написал(a):
> > В Пнд, 14/01/2008 в 14:36 +0500, Denis Klimov пишет:
> > > On Sat, 12 Jan 2008 12:00:02 +0300 Peter Volkov wrote:
> > > > А что имеет использовать?
> > >
> > > почитайте LARTC. там есть примеры, которые наверняка Вам подойдут.
> >
> > Денис, мне доводилось читал LARTC, поэтому и возник вопрос: что вы
> > имеете ввиду? Какая существует альтернатива IMQ / IFB (последнего, между
> > прочим, в lartc нет), пусть даже для двух интерфейсов?
> 
> Можно только метить пакеты с помощью -j MARK
> А уже на исходящем интерфейсе фильтровать по марке с помощью tc filter.
> Тогда не нужны псевдоинтерфейсы.

Извините, но каким местом это заменяет IMQ/IFB? Как в этом случае
реализовать общую балансировку нагрузки когда трафик исходит через
несколько интерфейсов?

> Но у меня это работало медленно на несколько тысяч абонентов.

Эта проблема может возникать из-за огромного количества фильтров. И
решение как раз описано в LARTC:
http://lartc.org/howto/lartc.adv-filter.hashing.html
Вешаются поверх IMQ, если надо... Но это не связано.

> Думаю если их не много, то такой вариант вполне хорош, т.к. не требует доп. 
> модулей и интерфейсов.
> С IMQ нормально, но когда сервер уже не справлялся...

И как IMQ облегчал вашу задачу? Могу лишь предположить, что с
маркировкой, вы заставляли ядро парсить таблицу iptables длиной в
несколько тысяч записей, а потом ещё и фильтры... Конечно это дольше...
Но что мешало вам сразу на интерфейс повесить u32 фильтры?

>  падало ядро
> Причём ошибка возникала в модуле IMQ.

А Вы пробовали написать в список рассылки
(http://tech.groups.yahoo.com/group/linuximq/), желательно с oops'ом и
всем что после...?



И всё-таки, уже не уповая на ответ, но повторю вопрос Денису. Пусть
интерфейсов мало, скажем два. Как "шейпить исходящий трафик для
небольшого количества интерфейсов"? Но похоже, что то ли Вы что-то
перепутали, то ли просто так сказали. А жаль, учитывая не очень надёжную
ситуацию с IMQ не плохо было бы иметь альтернативу.

-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Sysadmins] Исходящий шейпинг

[ahtoh]

В сообщении от 16 января 2008 Peter Volkov написал(a):

> Извините, но каким местом это заменяет IMQ/IFB? Как в этом случае
> реализовать общую балансировку нагрузки когда трафик исходит через
> несколько интерфейсов?

А никто и не говорил, что интерфейсов несколько.
Потом, можно иметь один интерфейс и балансировать с помощью
ip route, ip rule.
А uplink'и подключать через L3 или маршрутизатор.
Главное мы получаем пакеты, которые отличаются друг от друга меткой, которые 
можно фильтровать на любых интерфейсах, как хочется.
Вот так и заменяет...

> > Но у меня это работало медленно на несколько тысяч абонентов.
>
> Эта проблема может возникать из-за огромного количества фильтров. И
> решение как раз описано в LARTC:
> http://lartc.org/howto/lartc.adv-filter.hashing.html
> Вешаются поверх IMQ, если надо... Но это не связано.

Я хешем не пользовался. Надо будет попробывать.
Но проблема также решается покупкой более термоядерного сервера.

> > Думаю если их не много, то такой вариант вполне хорош, т.к. не требует
> > доп. модулей и интерфейсов.
> > С IMQ нормально, но когда сервер уже не справлялся...

> И как IMQ облегчал вашу задачу? Могу лишь предположить, что с
> маркировкой, вы заставляли ядро парсить таблицу iptables длиной в
> несколько тысяч записей, а потом ещё и фильтры... Конечно это дольше...
> Но что мешало вам сразу на интерфейс повесить u32 фильтры?

Я писал про то, когда нет IMQ или IFB.
Тогда на исходящем интерфейсе за NAT мы получаем внешний адрес, на котором 
висит ещё до кучи абонентов. И как откличить что пакет исходит именно от 
этого абонента? Только по метке.

> >  падало ядро
> > Причём ошибка возникала в модуле IMQ.
>
> А Вы пробовали написать в список рассылки
> (http://tech.groups.yahoo.com/group/linuximq/), желательно с oops'ом и
> всем что после...?

К сожалению это было не реально.

> И всё-таки, уже не уповая на ответ, но повторю вопрос Денису. Пусть
> интерфейсов мало, скажем два. Как "шейпить исходящий трафик для
> небольшого количества интерфейсов"? Но похоже, что то ли Вы что-то
> перепутали, то ли просто так сказали. А жаль, учитывая не очень надёжную
> ситуацию с IMQ не плохо было бы иметь альтернативу.

Через IFB. Алтернатива IMQ. Тем более в ALTLS4 есть только IFB.
Когда немного компов, вообще без псевдоинтефейсов, по меткам например.
Кажется я уже написал и мы пошли по кругу.

Re: [Sysadmins] Исходящий шейпинг

[Denis Klimov]

On Wed, 16 Jan 2008 22:28:39 +0300 Peter Volkov wrote:

> И всё-таки, уже не уповая на ответ, но повторю вопрос Денису. Пусть
> интерфейсов мало, скажем два. Как "шейпить исходящий трафик для
> небольшого количества интерфейсов"? Но похоже, что то ли Вы что-то
> перепутали, то ли просто так сказали. А жаль, учитывая не очень надёжную
> ситуацию с IMQ не плохо было бы иметь альтернативу.
> 
> -- 
> Peter.

Я писал что вам нет смысла тогда использовать ifb для _исходящего_
трафика, используйте HTB например на каждом интерфейсе.

я использую ifb для ограничения скорости _входящего_ трафика для пользователей, которые на ppp* интерфейсах:
DEV - это интерфейс в инет.

# Перенаправляем трафик с интерфейса, который смотрит в инет на ifb0
tc qdisc del dev $DEV handle ffff: ingress
tc qdisc add dev $DEV handle ffff: ingress
tc filter add dev $DEV parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0

# А дальше уже как хотим можем резать _входящий_ трафик.

tc qdisc del dev ifb0 root handle 1:
tc qdisc add dev ifb0 root handle 1: htb default 20 r2q 10
# Main class
tc class add dev ifb0 parent 1: classid 1:1 htb rate 100mbit quantum 6000
# For local traff, ssh etc
tc class add dev ifb0 parent 1:1 classid 1:5 htb rate 10mbit quantum 6000 burst 5k cburst 5k
# For fast traff
tc class add dev ifb0 parent 1:1 classid 1:10 htb rate 128kbit ceil 230kbit quantum 1600 burst 0k
# For other traff
tc class add dev ifb0 parent 1:1 classid 1:20 htb rate 64kbit ceil 230kbit quantum 1600 burst 0k
# Very low
tc class add dev ifb0 parent 1:1 classid 1:30 htb rate 32kbit ceil 100kbit quantum 1600 burst 0k

# User1
tc filter add dev ifb0 protocol ip parent 1:0 prio 2 u32 match ip dst 192.168.117.4/32 flowid 1:30
tc filter add dev ifb0 protocol ip parent 1:0 prio 2 u32 match ip src 192.168.117.4/32 flowid 1:30

#WEB
tc filter add dev ifb0 protocol ip parent 1:0 prio 2 u32 match ip sport 80 0xffff flowid 1:10
tc filter add dev ifb0 protocol ip parent 1:0 prio 2 u32 match ip sport 6667 0xffff flowid 1:10
#SSH
tc filter add dev ifb0 protocol ip parent 1:0 prio 2 u32 match ip sport 22 0xffff flowid 1:5
tc filter add dev ifb0 protocol ip parent 1:0 prio 2 u32 match ip dport 22 0xffff flowid 1:5
tc filter add dev ifb0 protocol ip parent 1:0 prio 2 u32 match ip src 192.168.1.202/32 flowid 1:5
tc filter add dev ifb0 protocol ip parent 1:0 prio 2 u32 match ip dst 192.168.1.202/32 flowid 1:5


--
Denis Klimov 
zver

Re: [Sysadmins] Исходящий шейпинг

[ahtoh]

В сообщении от 17 января 2008 Denis Klimov написал(a):
> On Wed, 16 Jan 2008 22:28:39 +0300 Peter Volkov wrote:
> > И всё-таки, уже не уповая на ответ, но повторю вопрос Денису. Пусть
> > интерфейсов мало, скажем два. Как "шейпить исходящий трафик для
> > небольшого количества интерфейсов"? Но похоже, что то ли Вы что-то
> > перепутали, то ли просто так сказали. А жаль, учитывая не очень надёжную
> > ситуацию с IMQ не плохо было бы иметь альтернативу.
> >
> > --
> > Peter.
>
> Я писал что вам нет смысла тогда использовать ifb для _исходящего_
> трафика, используйте HTB например на каждом интерфейсе.

Я полностью согласен.
С VPN вообще всё очевидно.
Можно шейпить исходящий на отдельном ppp интерфейсе.

Re: [Sysadmins] Исходящий шейпинг

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 4795 bytes --]

В Срд, 16/01/2008 в 23:42 +0300, ahtoh@pulnet.ru пишет:
> А никто и не говорил, что интерфейсов несколько.

Перечитайте, пожалуйста, первое письмо, которое, между прочим Вы и
написали. :D

> Потом, можно иметь один интерфейс и балансировать с помощью
> ip route, ip rule.

Именно. Когда один интерфейс IMQ/IFB не нужны.

> А uplink'и подключать через L3 или маршрутизатор.

Это уже совсем не важно, как там uplink подключён.

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

Что ж. Возможно вас это и устраивает. Но тогда не понятно зачем вам
вообще весь огород с IMQ? IMQ нужен, например, если вы хотите сделать
так, чтобы не зависимо через сколько интерфейсов вытекает с сервера
трафик он шейпировался одинаково. И что более важно, чтобы вы могли
перераспределять трафик (borrowing) с одного интерфейса на другой. В
остальных случаях IMQ, конечно, не нужен.


> Я писал про то, когда нет IMQ или IFB.
> Тогда на исходящем интерфейсе за NAT мы получаем внешний адрес, на котором 
> висит ещё до кучи абонентов. И как откличить что пакет исходит именно от 
> этого абонента? Только по метке. 

Про NAT вы здесь первый раз сказали.

Думаю, вы так же могли сильно улучшить ситуацию уменьшив количество
правил iptables. Возможно ipset может вам тоже чем-то поможет...

> > И всё-таки, уже не уповая на ответ, но повторю вопрос Денису. Пусть
> > интерфейсов мало, скажем два. Как "шейпить исходящий трафик для
> > небольшого количества интерфейсов"? Но похоже, что то ли Вы что-то
> > перепутали, то ли просто так сказали. А жаль, учитывая не очень надёжную
> > ситуацию с IMQ не плохо было бы иметь альтернативу.
> 
> Через IFB. Алтернатива IMQ. Тем более в ALTLS4 есть только IFB.
> Когда немного компов, вообще без псевдоинтефейсов, по меткам например.
> Кажется я уже написал и мы пошли по кругу.

Мда. Метки это способ классифицировать трафик, а псевдоинтерфейсы нужны
не столько для классификации, сколько для ... Да что мы правда по кругу?
Читаем FAQ:

http://wiki.nix.hu/cgi-bin/twiki/view/IMQ/ImqFaq#What_can_I_do_with_IMQ

What can I do with IMQ? 

The IMQ device has two common uses:

* Ingress shaping, using egress qdiscs:
* Shaping over multiple interfaces:

Ну как сделать первое или второе с помощью меток???


В Чтв, 17/01/2008 в 13:46 +0300, ahtoh@pulnet.ru пишет: 
> Я полностью согласен.
> С VPN вообще всё очевидно.
> Можно шейпить исходящий на отдельном ppp интерфейсе.

Хм. *мысли в слух* Вот только пользователей одновременно подключённых
около 300 и каждому нужно не меньше, чем по 2 мегабита. А канал 50
Мегабит... Да, а ещё не анлимным пользователям не плохо было бы выделить
хотя бы 20 мегабит... Действительно с VPN всё очевидно... ;)


Всё, закрываю дискуссию. Для себя я понял: пока IMQ/IFB альтернатив,
пока, нет.

WBR,
-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]