Linux NAT и потери при настройке nftables с flow offload

[Tormato 0]

Приветствую,

 

Ребята такое дело есть nat сервер на базе линукса и все вроде бы правильно с таким вот конфигом:

flush ruleset

table ip filter {
        chain input {
                type filter hook input priority 0; policy accept;
                ct state established accept
                iif "vlan4" counter drop
                iif "vlan5" counter drop
        }

        #flowtable fastnat {
        #        hook ingress priority 0
        #        devices = { vlan4, vlan5 }
        #}

        #chain forward {
        #        type filter hook forward priority 0; policy accept;
        #        ip protocol { tcp , udp } flow offload @fastnat;
        #}
}


table ip nat {
        chain post {
                type nat hook postrouting priority 100; policy accept;
                ip saddr 10.0.0.0/8 oif "vlan5" snat to 105.46.1.1-105.46.1.125 persistent
        }

        chain pre {
                type nat hook prerouting priority -100; policy accept;
        }
}

Плюс подкручены стандартные опции для самого нат сервера через sysctl.

 

Обратите внимание на закомменченную порцию с flow offload, с ней при 12G нат трафика неаблюдаются довольно сушественные потери на входе интерфейса:

 

Если закомментить часть отвечающую за flow offload, то нагрузка на процессот немного вырастает но потери исчезают аж пока трафика не станет 19G при загрузке CPU 85%. Да и то при такой нагрузке потери менее значительные:

 

Функция flow offload хороша и позволяет сэкономить на нагрузке CPU, но почему оно так сильно влияет на потери трафика или нужно настроить что либо еще?

 

[prolan.pw 0]

Добрый день.

Прошу прощения за небольшой некропостинг - но проблему удалось победить? Столкнулся с такой же проблемой

[karyon 48]

при великому трафіку такі проблеми бачили на картах intel 710, напевне через відносно малий буфер, в нас проблема вирішилася після заміни мережевої карти.

Крім цього ще існують проблеми з timeout встановлених зєднаннь, тобто після попадання в контракт і маркування зєдання як offload збивається timeout сесії на дефолтний, в якомусь з останніх ядер він ставився в коді в 86400. Тобто після будь-яких сканувань (вірусами чи абонентами) дуже швидко росте таблиця conntrack. Коротше кажучи, трохи сирувата реалізація offload

[Avad0n 22]

2 часа назад, karyon сказал:

при великому трафіку такі проблеми бачили на картах intel 710, напевне через відносно малий буфер, в нас проблема вирішилася після заміни мережевої карти.

40G? На что поменяли если не секрет?

[prolan.pw 0]

На тестовом стенде удалось воспроизвести, локализовать и победить проблему.

На сервере с NAT в разных интерфейсах поднят BGP с разными маршрутизаторами (маршрутизаторы в свою очередь подключены к разным магистральным провайдерам, т.ч. трафик может прийти как с одного интерфейса так и с другого).

На самом сервере с NAT маршрут по умолчанию смотрит только в первый интерфейс.

 

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

Выключение второго интерфейса тут же решает проблему.