[devel] kernel-feat-net-iptables_pom?

[devel] kernel-feat-net-iptables_pom?

[Andy Gorev]

Есть-ли какие-либо идеи у уважаемой "Kernel Maintainer Team" по поводу 
Iptables Rusty's Patch-o-matic? Или его включение в какое-либо ядро 
противоречит политике Alt? Давешние времена нестабильности с этим feat 
уже IMHO прошли. Всякие там nth & random matches были-бы весьма полезны 
для load balancing.

-- 
С Уважением,
Андрей Горев

Re: [devel] kernel-feat-net-iptables_pom?

[Sergey Vlasov]

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

On Mon, Nov 17, 2003 at 07:06:54PM +0200, Andy Gorev wrote:
> Есть-ли какие-либо идеи у уважаемой "Kernel Maintainer Team" по поводу 
> Iptables Rusty's Patch-o-matic? Или его включение в какое-либо ядро 
> противоречит политике Alt? Давешние времена нестабильности с этим feat 
> уже IMHO прошли. Всякие там nth & random matches были-бы весьма полезны 
> для load balancing.

iptables имеет одну пакостную особенность - там то и дело ломается
бинарная совместимость, в результате чего собранный iptables перестаёт
работать с другими ядрами.  В patch-o-matic есть отдельные патчи,
модифицирующие существующие модули и при этом вносящие такую
несовместимость; такие патчи не могут быть использованы.

Добавить какую-то новую функциональность в принципе можно - только нужно
учитывать, что у нас теперь несколько вариантов ядра, а пакеты (в том
числе и iptables) собираются с kernel-headers-std.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] kernel-feat-net-iptables_pom?

[Peter V. Saveliev]

On Mon, 17 Nov 2003 19:06:54 +0200
Andy Gorev <horror@altlinux.ru> wrote:

> Есть-ли какие-либо идеи у уважаемой "Kernel Maintainer Team" по поводу 
> Iptables Rusty's Patch-o-matic? Или его включение в какое-либо ядро 
> противоречит политике Alt? Давешние времена нестабильности с этим feat 
> уже IMHO прошли. Всякие там nth & random matches были-бы весьма полезны 
> для load balancing.

Боясь показаться занудным, смею всё же обратить внимание на iproute2. И
в ядро ничего лишнего вставлять не надо, опять же - всё есть.

-- 
Sincerely, Peter V. Saveliev

E-mail: peet@altlinux.ru
Jabber: peet@jabber.ru

Re: [devel] kernel-feat-net-iptables_pom?

[Andy Gorev]

Peter V. Saveliev wrote:
> On Mon, 17 Nov 2003 19:06:54 +0200
> Andy Gorev <horror@altlinux.ru> wrote:
> 
> 
>>Есть-ли какие-либо идеи у уважаемой "Kernel Maintainer Team" по поводу 
>>Iptables Rusty's Patch-o-matic? Или его включение в какое-либо ядро 
>>противоречит политике Alt? Давешние времена нестабильности с этим feat 
>>уже IMHO прошли. Всякие там nth & random matches были-бы весьма полезны 
>>для load balancing.
> 
> 
> Боясь показаться занудным, смею всё же обратить внимание на iproute2. И
> в ядро ничего лишнего вставлять не надо, опять же - всё есть.
> 

Извините, чье внимание, мое? :D

Примеры, пожалуйста, в студию. А потом мы посмотрим, как вы заНАТите 
каждый 1-й, 12-й и 25-й пакет из идущих на 80-й порт на один из четырех 
интерфейсов, которые у меня есть ;-)

-- 
С Уважением,
Андрей Горев

Re: [devel] kernel-feat-net-iptables_pom?

[Peter V. Saveliev]

On Mon, 17 Nov 2003 20:54:55 +0200
Andy Gorev <horror@altlinux.ru> wrote:

> Peter V. Saveliev wrote:
> > On Mon, 17 Nov 2003 19:06:54 +0200
> > Andy Gorev <horror@altlinux.ru> wrote:
> > 
> > 
> >>Есть-ли какие-либо идеи у уважаемой "Kernel Maintainer Team" по поводу 
> >>Iptables Rusty's Patch-o-matic? Или его включение в какое-либо ядро 
> >>противоречит политике Alt? Давешние времена нестабильности с этим feat 
> >>уже IMHO прошли. Всякие там nth & random matches были-бы весьма полезны 
> >>для load balancing.
> > 
> > 
> > Боясь показаться занудным, смею всё же обратить внимание на iproute2. И
> > в ядро ничего лишнего вставлять не надо, опять же - всё есть.
> > 
> 
> Извините, чье внимание, мое? :D
> 
> Примеры, пожалуйста, в студию. А потом мы посмотрим, как вы заНАТите 
> каждый 1-й, 12-й и 25-й пакет из идущих на 80-й порт на один из четырех 
> интерфейсов, которые у меня есть ;-)

Классификатор u32. Конкретные строчки пришлю к утру, когда время
написать будет. С nat'ом, может, и попарюсь, но уж выцепить пакет по
паттерну в заголовке - не проблема вовсе.

-- 
Sincerely, Peter V. Saveliev

E-mail: peet@altlinux.ru
Jabber: peet@jabber.ru

Re: [devel] kernel-feat-net-iptables_pom?

[Andy Gorev]

Peter V. Saveliev wrote:
> On Mon, 17 Nov 2003 20:54:55 +0200
> Andy Gorev <horror@altlinux.ru> wrote:
> 
> 
>>Peter V. Saveliev wrote:
>>
>>>On Mon, 17 Nov 2003 19:06:54 +0200
>>>Andy Gorev <horror@altlinux.ru> wrote:
>>>
>>>
>>>
>>>>Есть-ли какие-либо идеи у уважаемой "Kernel Maintainer Team" по поводу 
>>>>Iptables Rusty's Patch-o-matic? Или его включение в какое-либо ядро 
>>>>противоречит политике Alt? Давешние времена нестабильности с этим feat 
>>>>уже IMHO прошли. Всякие там nth & random matches были-бы весьма полезны 
>>>>для load balancing.
>>>
>>>
>>>Боясь показаться занудным, смею всё же обратить внимание на iproute2. И
>>>в ядро ничего лишнего вставлять не надо, опять же - всё есть.
>>>
>>
>>Извините, чье внимание, мое? :D
>>
>>Примеры, пожалуйста, в студию. А потом мы посмотрим, как вы заНАТите 
>>каждый 1-й, 12-й и 25-й пакет из идущих на 80-й порт на один из четырех 
>>интерфейсов, которые у меня есть ;-)
> 
> 
> Классификатор u32. Конкретные строчки пришлю к утру, когда время
> написать будет. С nat'ом, может, и попарюсь, но уж выцепить пакет по
> паттерну в заголовке - не проблема вовсе.
> 

Вы не поняли проблему. Упростим задачу. Нет никаких паттернов, нет даже 
src адресов, потому что они все разные, src порты тоже разные, dst 
адреса тоже разные, одинаков только порт dst. Так вот из этого трафика 
_безотносительно_ от нагрузки канала надо отделить поток в 35% и 
что-нибудь с ним сделать. Не важно НАТ или нет. Можете быть покойны - 
ip&tc не решат эту задачу. Есть сторонние приблуды типа multipath 
routing и вообще множество рецептов. Только с помощью iptables это можно 
сделать проще.

-- 
С Уважением,
Андрей Горев

Re: [devel] kernel-feat-net-iptables_pom?

[Peter V. Saveliev]

On Mon, 17 Nov 2003 20:54:55 +0200
Andy Gorev <horror@altlinux.ru> wrote:

<skip /> 
> Примеры, пожалуйста, в студию. А потом мы посмотрим, как вы заНАТите 
> каждый 1-й, 12-й и 25-й пакет из идущих на 80-й порт на один из четырех 
> интерфейсов, которые у меня есть ;-)

Или ещё смешнее... Вам, кажется, load balancing нужен? Если на входящем
потоке, то - ingress policier, если на исходящем - то цельный набор от
HTB до CBQ.

Например, исходя из приведённого ТЗ я могу просто дропнуть пакеты 2..11,
13..24, 26..<макс. значение счётчика заголовке пакета>, если они идут на
80 порт.

-- 
Sincerely, Peter V. Saveliev

E-mail: peet@altlinux.ru
Jabber: peet@jabber.ru

Re: [devel] kernel-feat-net-iptables_pom?

[Andy Gorev]

Peter V. Saveliev wrote:
> On Mon, 17 Nov 2003 20:54:55 +0200
> Andy Gorev <horror@altlinux.ru> wrote:
> 
> <skip /> 
> 
>>Примеры, пожалуйста, в студию. А потом мы посмотрим, как вы заНАТите 
>>каждый 1-й, 12-й и 25-й пакет из идущих на 80-й порт на один из четырех 
>>интерфейсов, которые у меня есть ;-)
> 
> 
> Или ещё смешнее... Вам, кажется, load balancing нужен? Если на входящем
> потоке, то - ingress policier, если на исходящем - то цельный набор от
> HTB до CBQ.
> 
> Например, исходя из приведённого ТЗ я могу просто дропнуть пакеты 2..11,
> 13..24, 26..<макс. значение счётчика заголовке пакета>, если они идут на
> 80 порт.

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

ЗЫ Вы будете смеятся, но 
http://www.opennet.ru/base/net/adv_route_qos.txt.html - это я написал. :)

-- 
С Уважением,
Андрей Горев

Re: [devel] kernel-feat-net-iptables_pom?

[Peter V. Saveliev]

On Mon, 17 Nov 2003 21:10:04 +0200
Andy Gorev <horror@altlinux.ru> wrote:

<skip /> 
> Вы не поняли проблему. Упростим задачу. Нет никаких паттернов, нет даже 
> src адресов, потому что они все разные, src порты тоже разные, dst 
> адреса тоже разные, одинаков только порт dst. Так вот из этого трафика 
> _безотносительно_ от нагрузки канала надо отделить поток в 35% и 
> что-нибудь с ним сделать. Не важно НАТ или нет. Можете быть покойны - 
> ip&tc не решат эту задачу. Есть сторонние приблуды типа multipath 
> routing и вообще множество рецептов. Только с помощью iptables это можно 
> сделать проще.
<skip />

Ок, проблему понял, возможно, я не прав. Хотя попробую порыть, всё же -
просто для успокоения :)

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

Фишки фишками, но надо иногда обеспечить некоторую тривиальную
функциональность, и REJECT для меня был тем же, что и /proc, к примеру.
Т.е., неотъемлимой частью рабочей среды ;)

-- 
Sincerely, Peter V. Saveliev

E-mail: peet@altlinux.ru
Jabber: peet@jabber.ru

Re: [devel] kernel-feat-net-iptables_pom?

[Andy Gorev]

Peter V. Saveliev wrote:
> On Mon, 17 Nov 2003 21:10:04 +0200
> Andy Gorev <horror@altlinux.ru> wrote:
> 
> <skip /> 
> 
>>Вы не поняли проблему. Упростим задачу. Нет никаких паттернов, нет даже 
>>src адресов, потому что они все разные, src порты тоже разные, dst 
>>адреса тоже разные, одинаков только порт dst. Так вот из этого трафика 
>>_безотносительно_ от нагрузки канала надо отделить поток в 35% и 
>>что-нибудь с ним сделать. Не важно НАТ или нет. Можете быть покойны - 
>>ip&tc не решат эту задачу. Есть сторонние приблуды типа multipath 
>>routing и вообще множество рецептов. Только с помощью iptables это можно 
>>сделать проще.
> 
> <skip />
> 
> Ок, проблему понял, возможно, я не прав. Хотя попробую порыть, всё же -
> просто для успокоения :)

Я буду очень признателен за любое решение, отличающееся от pom или 
http://www.ssi.bg/~ja/nano.txt

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

Именно поэтому я и спросил многоуважаемую "Kernel Maintainer Team", как 
с этим обстоят дела сейчас.

> Фишки фишками, но надо иногда обеспечить некоторую тривиальную
> функциональность, и REJECT для меня был тем же, что и /proc, к примеру.
> Т.е., неотъемлимой частью рабочей среды ;)

Да, понимаю.

-- 
С Уважением,
Андрей Горев