LINUX.ORG.RU

NPF: новый пакетный фильтр в NetBSD

 , , npf


0

0

В NetBSD-current появился новый пакетный фильтр npf, написанный с нуля литовцем Миндаугасом Расюкевичиусом (Mindaugas Rasiukevičius). Основные возможности:

  • фильтр разработан с учётом многопроцессорных машин и без использования блокировок для получения масштабируемой производительности — теперь пакетный фильтр не является узким местом на многопроцессорном маршрутизаторе;
  • быстрый поиск по хеш-таблице и красно-чёрному дереву;
  • динамическая фильтрация пакетов (на основе информации о соединениях), преобразование сетевых адресов и портов (NAPT) и шлюзы уровня приложений (ALG);
  • новый «движок» N-Code, написанный по основным принципам BPF: N-Code использует для нахождения соответствия в пакетах основные RISC-подобные инструкции и несколько CISC-подобных инструкций для обычных шаблонов наподобие адресов IPv4;
  • уже знакомые синтаксис конфигурирования и утилиты;
  • модульность и расширяемость: пользователи могут расширить NPF путём загрузки модуля ядра; NPF предоставляет разработчикам API, а правила NPF могут использовать специальный метод для активизации расширения.

Таким образом, к январю пользователи NPF получат все те возможности, которые они получают от других пакетных фильтров:

  • повторная сборка пакетов IPv4;
  • двунаправленные NAT и перенаправление портов;
  • поддержка прокси FTP;
  • чистка флагов в заголовке IP;
  • блокировка пакетов ICMP и TCP RST;
  • сохранение и восстановление состояния;
  • журналирование пакетов, настраиваемые правила фильтрации.

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

>>> Подробности

★★★★★

Проверено: annoynimous ()
Последнее исправление: MuZHiK-2 (всего исправлений: 3)

Ответ на: комментарий от ventilator

Дублирование - это не совсем то, что я имел в виду. Меня интересовало SMP/ASMP. Я так понял, что таковые отсутствуют, так?

Естественно, он не занимается форвардингом. Не понятно только как это связано с тем, о чем я говорил. Простой пример - делаем железку, которая форвардит IP пакеты в железе, но когда ей попадается пакет, содержащий опции, ей приходится обрабатывать это процессором общего назначения. Вообще, есть нюанс, что дизайн и реализация могут различаться и часто различаются на практике. И разделение на control и forwarding оно условно, в реале запросто может быть layering violation, то есть с одной стороны мы частично выгружаем на железо и то, что формально относиться к control, а с другой стороны мы не во всех случаях можем выгрузить весь forwarding.

anonymous
()
Ответ на: комментарий от anonymous

Ну так вы там почитайте комментарии по своей ссылке. Там вполне написано зачем нужны эти типы. Вы отличаете дата-плейн от контрол-плейн?

ventilator ★★★
()
Ответ на: комментарий от anonymous

Выше анонимус упомянул dual core celeron внутри джуна, многоядерность вполне соответствует SMP. Про много _процессоров_ я написал, конечно это не SMP. Нюансы конечно есть, но как только трафик начнет обрабатываться процессором то от производительности тут же ничего не останется. Я говорю о том что npf совсем мало относится к хардварным роутерам. А так же что существуют многопроцессорные роутеры как и написано в исходном посте.

ventilator ★★★
()
Ответ на: комментарий от ventilator

Тот анонимус был я. =) Собственно, хотелось бы и многопроцесорных и многоядерных. :lol: Короче, забейте.

anonymous
()
Ответ на: комментарий от anonymous

Много процессоров не надо, надо 256 ядер.

anonymous
()

Его не в рамках GSOC написали студенты?!

Boy_from_Jungle ★★★★
()
Ответ на: комментарий от fagot

Такое делают на Cisco CRS-1 и подобных железяках, но никак уж не на писюках.

anonymous
()
Ответ на: комментарий от fagot

Вообще говоря, T1600 называется так потому что Жунипер считает, что эта железка способна прокачать 1,6 терабита. Кроме того, эти штуки можно объединять в матрицу (типа кластер) до 16 юнитов.

anonymous
()
Ответ на: комментарий от fagot

Боюсь соврать, но кажется магистраль между Японией и САСШ порядка нескольких сотен гигабит. Из чего я дело вывод, что надо это мало где. Это что касается сырой пропускной способности. Однако производительность также расходуется на всякие вещи, например VPLS, HQOS. Нам же в конечном счете не нужен голый свитч, который будет тупо форвардить трафик. Нам нужны сервисы, которые мы будем продавать своим клиентам. Я к тому, что по большому скорость чистого форвардинга не сильно интересна.

anonymous
()

«Я ее все же ..., как матерый фряшник. Дью тему под вин7 не оценила, я снес. Но, ..., убунта (да и весь линукс, наверное) — это вещь настолько нелогичная, что просто оторопь. Какого ... апт устанавливает зависимости когда не надо, а когда надо — приходится собирать xorg по кусочкам (я краем уха еще слашал про авторемув, но судя по тому, что он мне показывает — это полярный лис)? Какого ... пакеты xorg называются xserver-xorg-чо-то-там, вместо нормальных имен? Блджад, это в каждом шаге, в каждой ... мелочи, в скорости движения и мигания курсора в консоли. Поэтому я выбираю фрю. Там если система говорит тебе, что она в тупике — то и ты с ней в тупике. Не возникает вопроса — ... ..., я все сделал как надо, а ты ... не работаешь. Когда линукс говорит, что что-то не так — ..., да все так должно быть!! Наверное, сказалось то, что фрю писали акатемики, потому что любят ее, а линукс — студенты, потому что ненавидят майкрософт (перефразируя Тео).»

anonymous
()
Ответ на: комментарий от anonymous

Насчет академиков ты загнул, конечно. Хотя Кирк PhD защитил все-таки. Говорит, что если бы не стал защищать, а пошел бы за Биллом Джоем, то сейчас имел бы остров в Карибском море. =)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.