Быстрый роутинг и NAT в Linux

Интересно было бы сравнить с этим модулем:
github.com/andrsharaev/xt_NAT

Предположу, что быстрее. Объясню почему. Это код модуля для iptables, соответственно, для этого должен работать iptables, который медленнее, чем nftables из-за иной организации правил и хуков в ядре. А в случае с flow offload в передаче пакетов в установленной сессии не участвует ни iptables, ни nftables. Поэтому даже чистый роутинг с помощью flow offload получается быстрее, чем использование пустых правил iptables без conntrack.

И вопрос, в случае NFTables ALG популярных протоколов работает?

Да, любые доступные iptables-helpers можно использовать в этом случае. Пример конфига:

table raw {
        ct helper pptp-gre {
                type "pptp" protocol tcp;
        }

        chain prerouting { 
                type filter hook prerouting priority -300;
                tcp dport 1723 ct helper set "pptp-gre"
        }
}

Offload в таком случае не будет работать для соединений, у которых настроен ALG и они свалятся в обычный conntrack

Процессор в пике был до 50%, сессий около 1.6 млн. Экстраполирование чуть не срабатывает, потому что мы перешли на 40Gbps интерфейсы вместо 2х10Gbps в LAG, чем немного выиграли CPU. Нелинейный рост начинается после достаточно высокой загрузки CPU, когда в ядре набирается большое количество отложенных операций, например, удаление протухших сессий, или удаления старых данных после RCU grace period. Выглядит как резкий всплеск нагрузки на одно или нескольких ядрах. Поэтому лучше не доводить стабильную нагрузку на сервер больше 80% CPU.

Как я и писал в статье — использование DPDK-based решений накладывает дополнительные требования на эксплуатацию. Как минимум, какие инструменты использовать для диагностики сетевой части (tcpdump, просмотр fib, динамическое изменение rib)? И второе — какие инструменты использовать для мониторинга? Счетчики байт и пакетов на интерфейсах внутри DPDK показывают только текущую сетевую нагрузку, но что мониторить, чтобы понимать запас производительности? DPDK использует CPU в режиме poll — нагрузка на задействованых ядрах всегда 100% вне зависимости от того, 0 пакетов обработано за цикл или миллионы — как понять, сколько CPU осталось и когда начнутся потери пакетов?

Начать надо с обновления ядра, потому что 2.6.39, да и 3.0 — это очень старые ядра. Со времен тех ядер в сетевую подсистему внесли огромное количество изменений, избавившись от глобального spinlock'a, оптимизировав conntrack до возможности добавления до 1 млн новых сессий в секунду. Правда, параллельная обработка пакетов на платформе E56xx приводит к тому, что разные процессоры начинают "сражаться" за общую шину PCIe, но, кажется, 4Гбит/с можно обрабатывать и одним процессором.

Лимиты сессий настроены с помощью iptables connlim, но это не спасает от огромного потока новых соединений.
Пробовали отключать HT, кардинальным образом ничего не изменило (при нормальной нагрузке), решили оставить.
Сервер старенький, поэтому ОС и ядро тех времён. Стоит ли пробовать более новое ядро под rhel 6 из elrepo? Или сразу думать о современной ОС? Тогда какое ядро лучше использовать под rhel, стандартное, oracle uek или elrepo?
Интересный момент. На текущем ядре модуль igb имеет параметры (RSS, LRO и т.п.), а на новых ядрах этот модуль без параметров. Это как-то влияет на производительность?

На ufw вы зря наговариваете. Это фактически упрощённый интерфейс к iptables для непрофессионалов.

Не согласен, что это прям тупик. Несмотря на все оптимизации, сетевая часть ядра Linux — это монстр, который не может работать очень быстро из-за своей универсальности. А зависимостей между модулями столько, что не всегда получается оставить только то, что действительно необходимо. При этом на DPDK можно сделать очень производительное решение под конкретную частную задачу. Например, я не представляю, какое железо должно быть под задачу firewall ipv6 трафика с большим количеством правил (миллионы, например). При этом решение на DPDK вполне справлялось с задаче на 100Gbps line-rate, не забывая потом еще маршрутизировать этот трафик, и всё на 8 ядрах 2Ghz. Поэтому, правильнее сравнивать решения на DPDK с решениями от производителей сетевого оборудования. Например, Juniper MX204, позиционируется как бордер, P/PE маршрутизатор. Стоит сейчас больше 3 млн рублей. Сервис контракт на год на него стоит еще минимум шестизначную сумму. При этом фактически нужен для быстрого RMA, потому что time to market новых фич или багфиксов (если вообще получилось продавить тех поддержку) — минимум 6 месяцев. В качестве альтернативы — сервер на Supermicro X10, карты Mellanox ConnectX5 c такими же 100G интерфейсами. Цена выходит около 500 тыс. Если таких устройств нужно больше 4х, то ценой сервис контракта вполне можно закрыть годовую зарплату разработчика для DPDK. При этом time-to-market новых фич будет 1 спринт в agile. Решить эту же задачу в похожих объемах на чистом Linux скорее всего не выйдет, или выйдет дороже, и time-to-market будет сопоставим с Juniper

Ответы просты:

1. Графиков именно того периода нет, но они и не интересны — rx_dropped там стабильно 0.
2. Сетевая карта — для случая, отраженного в графиках Intel 82599ES, сейчас используется Mellanox ConnectX-4 Lx

да, остается. фактически создание NAT трансляции происходит в модуле nf_conntrack и абсолютно идентично тому, что происходит, если писать правила iptables. чтобы модуль ipt_NETFLOW логировал трансляции через natevents достаточно его просто загрузить

Т.е. вполне реально жить только на IPv6

Нет, конечно же. Полно ipv4-only сайтов. Понятное дело, что можно обойти с помощью nat64, но это тот ещё костыль. И мы вроде говорили об уходе от nat )))