Netgraph для пользователя

[nuclight]

Многие слышали о сетевой подсистеме Netgraph во FreeBSD, но далеко не все представляют себе, что же это такое, как оно работает, и зачем оно нужно - кроме того, что на нем работает mpd (известная очень производительная реализация PPP/PPTP/L2TP). Да еще по сети ходят многочисленные Howto типа "как считать Netflow на нетграфе", где приводят примеры

Comments

[filonov]

в мемориз в общем. А то когда лет пять его не трогаешь - оно забывается.

[kondybas]

Замечательно. Особенно в части ООП-подхода.

[kondybas]

Возник сугубо практический вопрос:
Есть ряд портов, которые слушаются на внешнем интерфейсе, и затем редиректятся вовнутрь на локальные машины, каждый порт на свою машину. На обратном пути выполняется трансляция адресов.

Что эффективнее - держать одну ноду ng_nat с набором редирект_портов, или же пачку индивидуальных нод с тупыми редирект_адресами внутри, в которые нетграфить из IPFW в зависимости от порта прибытия/хоста убытия?

Я так понимаю, что каждая нода нг_ната держит внутри динамическую таблицу пробегающих через нее соединений, в которой выполняется лукап на каждый обрабатываемый пакет. Если вместо одной общей ноды (с общей таблицей) сделать пачку отдельных нод с отдельными таблицами, то, по логике, удельное время лукапа в таблицах на пакет должно уменьшиться? И, как следствие, уменьшится нагрузка на проц?

[nuclight]

Да, именно так. Таблица libalias держится под одним локом, поэтому, если более-менее равномерно распределить нагрузку между разными нодами, только так оно сможет параллелиться на нескольких ядрах

[kondybas]

Я имел в виду немножко другое. Вместо одной большой таблицы - много сравнительно мелких. Тот же принцип, что и у разбиения кеша сквида на двухуровневое дерево. А что статический редирект адреса порождает такой же конфиг, как и редирект одного порта - это я уже понял.

В любом случае, распараллеливание обработки отдельных нод - это песня. Об этом аспекте я даже не думал.

[boorick]

Отличная работа. Спасибо.
Повешу линк.

[l2tp]

Утащила в мемориз для дальнейших медитаций

[levgem]

Хорошо расписано, хоть мне самому с этим и не приходится работать.

Вопрос такой: а как у всей этой динамической диспетчеризации запросов со скоростью обработки хотя бы на 4-5 гигабитах? Ведь статическая линковка быстрее, или тут происходит при связывании узлов статическая линковка?

[nuclight]

> со скоростью обработки хотя бы на 4-5 гигабитах?

У меня таких стендов нет.

> Ведь статическая линковка быстрее

Популярная чушь.

[levgem]

> У меня таких стендов нет.

Жалко, ведь до нескольких гигабит разницы чем раздавать тот же MPEG-TS нет.

> Популярная чушь

Это почему?

[nuclight]

> Жалко, ведь до нескольких гигабит разницы чем раздавать тот же MPEG-TS нет.

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

> Это почему?

А по какой причине вообще быть разнице? Есть бенчмарки, показывающее обратное?