[RootConf] IPFW: несколько наборов правил и другие предполагаемые изменения

[nuclight]

===
В марте, помнится, я написал в ipfw@ предложения по архитектурным улучшениям ipfw, как кандидат на GSoC 2008. Никто не отреагировал (многабукаф, фигли). Дальше, в конце мая в RU.UNIX.BSD разгорелся спор - народ хотел изменения "как Cisco ACLs, но лучше", однако конкретики не было, хотя со временем что-то уже вырисовалось, я поглядел на идеи для

Comments

[zed_0xff]

еще бы неплохо научить ipfw формировать из правил вида
allow tcp from any to 10.1.1.1, 10.1.1.2, 10.10.2.3, 10.11.12.3, ... etc
автоматом внутри себя таблички(table), ибо руками бывает лень из-за 8-10 айпишников табличку городить, а иначе получаем замедление скорости пропорционально количеству адресов. если я правильно понимаю внутренности ipfw

[nuclight]

Тут вопрос не такой однозначный. Сложные алгоритмы, оптимизированные для больших значений, плохо работают на очень небольших, когда буквально несколько. Два-три адреса практически наверняка будут сравниваться быстрее, чем они же, но в таблице. Так что вам не зря лень. Правда, где проходит граница, как будут именно 8-10 айпишников, не знаю. Замерять надо.

[zed_0xff]

ну для 2-3 адресов естественно неактуально, у меня вот сейчас есть и по 11 и по 17 адресов в строке

Для 17 адресов уже однозначно таблицу

[nuclight]

А алгоритм назначения номеров этим вновь создаваемым таблицам предложите? Чтоб учитывалось, если какие-то табдицы явно у вас уже используются.

next_hop

[q_zmich]

Не секрет, что иногда производительности одного FreeBSD сервер в качестве маршрутизатора не хватает. Очень любят кушать NAT, DUMMYNET и т.д., поэтому иногда хочется разделить работу на несколько серверов, а не покупать "Циска двамильёнатристатыщ".
Например: два шейпера <-> два ната <-> три bgp-роутера, и всё это обложено динамической маршрутизацией

QoS dummynet

[q_zmich]

Обычно при использовании шейпера делают либо "один большой канал в wf2q и пусть дерутся", либо "каждому по мегабиту, директору и мне - по четыре".

Хотелось бы совместить одно с другим, реализовав CIR/PIR (а возможно и прочие IRы)
Например:

Есть канал/пайпа 100 мегабит.
А его нарезаю на пайпы (mask dst-ip) по 1 мегабиту CIR и 2 мегабита PIR.
При этом на dummynet работает не один шедулер, а два последовательно: первый шедулер обрабатывает как обычно, выдирая из "личных" пайпов необходимое количество пакетов для реализации нижнего предела - 1 мегабит. Как только доработал первый шедулер - в дело включается второй, и если суммарная толщина канала (100 мегабит) еще не израсходована первым шедулером - по алгоритму wf2q выдирает из "личных" пайпов следующие пакеты.

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

[terrakots]

Там пару писем в личке, относительно Москвы. Ответь, плиз, надо, не надо, я подкорректирую планы.

[nuclight]

C 8 числа я ехал поездами пересадками, так что ни на какие сообщения ответить не мог :) Сейчас вот вернулся обратно, буду потихоньку разгребаться...

[jabrusli]

Слушаю твой доклад. Очень интересно.

Пожелание - пиши больше статей.