Необъяснимые потери пакетов. Debian

[lacost]

Коллеги, столкнулись с необъяснимыми потерями пакетов на макете. Т.е. мы пока не смогли найти этому какое-либо внятное объяснение. Данная схема у нас годами работала, но на новой паре серверов видим странную картину.

 

Есть пара серверов, Debian на ядре 4.19.0-13-amd64. В каждом по паре сетевых карт Intel X520 (с последними драйверами)

Сервера между собой соединены гиговыми портами. 10Г линки - в коммутатор.

 

Два сервера. Задача 1-го - NAT клиентов которых не надо шейпить. Задача 2-го - NAT клиентов которых надо шейпить + непосредственно шейп.

 

Исходящий из сети трафик всегда заходит на сервер 1 интерфейс 1.1 на нем принимается решение (по src_ip) нужно ли этот трафик шейпить , и если нужно, трафик идет через интерфейс 1.3 на сервер 2 в интерфейс 2.4. При выходе с интерфейса 1.3 трафик шейпится. На сервере 2 происходит NAT и трафик через интерфейс 2.6 уходит в инет.

Вариант, где трафик не надо шейпить - работает нормально. Его не рассматриваем.

Входящий из инета приходит на сервер 2 интерфейс 2.6, проходит NAT и шейпясь, через 2.5 уходит во внутреннюю сеть.

 

NAT - iptables persistent, + часть клиентов с реальниками на картах с no_track

шейпинг tc qdisc htb

 

Далее последовательность действий которая приводит к 100% исходу.

 

тестовый клиент - ноут с реальным ip на сетевой карте. 

Если не включаем шейпинг - все ходит.

Включаем шейпинг на исходящий трафик (интерфейс 1.3) на уровне 6Мбит/сек и смотрим ролик с HD-видео.

Начинаем пинговать реальный интерфейс тестового ноута большими пакетами -s 3000 с граничного маршрутизатора.

Видео - ОК, пинги в норме.

Начинаем  наливать в эту связку (сервера 1 и 2) трафик от реальных пользователей на 3-5 ГБит/сек

 

Через некоторе время, не сразу (от 30 сек до нескольких минут) начинают теряться пинги. Потери идут пачками 10-15 пакетов потерялись, потом опять проходят.

 

Убрали tc c интерфейса 1.3 - потери пропали.

 

Теперь про потери. tcpdump на сервере 2 интерфейсах 2.5 и 2.6 смотрим icmp от хоста источника пингов и хост назначения пингов. Штатно вижу реквест пакет на 2.6 и реквест пакет на 2.5 и реплай пакет на 2.6  

Как начинаются потери - я все еще вижу реквест пакеты на интерфейс 2.6 но дальше - ничего. на 2.5 я их уже не вижу.

Добавляли -j LOG во все (raw, mangle, filter, nat ) цепочки iptables. Как только начинаются потери пингов - так и в логах прекращаются новые записи. Пакет просто растворяется. Я даже не представляю куда он пропадает.

 

У меня есть единственное объяснение данному эффекту: между сервером 1 и 2 есть какая-то связь, которая появилась в новых дистрибутивах/ядрах, которая при повышенной нагрузке как-то уведомляет соседей о перегрузке линка? Для меня вообще не понятна связь между установкой tc qdisc дисциплины на одном сервере, что влечет за собой сбой в маршрутизации пакетов на другом сервере.

 

Или я чего-то упускаю?

 

Что это может быть?

[Sacrament]

А между 1.3 и 2.4 гигабитный интерфейс?

[lacost]

3 часа назад, Sacrament сказал:

А между 1.3 и 2.4 гигабитный интерфейс?

Да, но там только исходящий из 1.3 в 2.4 и нагрузка там 5-10% от входящего. Перегруза там нет. 

[rm_]

7 hours ago, lacost said:

между сервером 1 и 2 есть какая-то связь, которая появилась в новых дистрибутивах/ядрах, которая при повышенной нагрузке как-то уведомляет соседей о перегрузке линка?

Этого же самого линка? Ну этож широко известный Flow Control.

Советы разнятся от выключать везде, до включать везде. В качестве универсального можно применить "переключите на по-другому чем щас".

Другого линка, каких-то линков "вообще"? Нет такого.

[dr Tr0jan]

40 minutes ago, rm_ said:

Советы разнятся от выключать везде, до включать везде.

Если это оно, то надо понимать, как оно работает. Иногда, это не оно.

[Ivan_83]

По моему мнению Flow Control фича исключительно для клиентских портов, ибо просить "заткнутся не надолго" сервер/роутер, особенно со стороны клиента не очень умно.

[lacost]

 

Про Flow Control понял. проверим.

 

 А вот здесь вообще не понял:

10 часов назад, rm_ сказал:

В качестве универсального можно применить "переключите на по-другому чем щас".

Другого линка, каких-то линков "вообще"? Нет такого.

 

[rm_]

2 hours ago, lacost said:

В качестве универсального можно применить "переключите на по-другому чем щас".

Это продолжение по Flow Control, о том что с ним сделать. :)

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

 

2 hours ago, lacost said:

Другого линка, каких-то линков "вообще"? Нет такого.

Речь о том, что помимо Flow Control других механизмов которыми сервер может сообщать другому о загрузке его интерфейсов - нет.

[lacost]

Насильно отключаем Flow Control на всех интерфейсах

ethtool -A eno1 autoneg off rx off tx off

 

Начинаем наливать трафик

 

Через некоторое время - опять потери.

 

смотрю по всем интерфейсам статистику по отправке 

#ethtool -S eno1 | grep flow
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 0
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0

В tcpdump не вижу никакого служебного трафика, везде пустота. 

tcpdump -nni any ether proto 0x8808
tcpdump -nni any not ip and not arp

 

 

снимаем шейпер с исходящего (Сервер 1) - потери прекращаются.

 

ПС. Небольшое дополнение к схеме. Сейчас работаем с линком 1.3 - 2.4 в Bond'е 2х1Ge с каждой стороны.

 

Edited March 23, 2021 by lacost

[NiTr0]

qlen на бондинге/вланах/etc, куда шейпер навешан, надеюсь поднят до 1000 хотя бы?

[lacost]

8 минут назад, NiTr0 сказал:

qlen на бондинге/вланах/etc, куда шейпер навешан, надеюсь поднят до 1000 хотя бы?

Да, ровно 1000

[lacost]

Сделали апгрейд соединения 1 .3 - 2.4 на 10GE

 

Вообще ничего не изменилось. Все так же. Включаем tc на Сервер 1 - начинаются потери на Сервер 2

 

До этого проверяли направление из интернета в локалку - после включения tc на "Сервер 1" - "Сервер 2" перестает форвардить эти ICMP.

 

Решили изменить направление теста. Тестируем из локалки в инет. Пакет пролетает через Сервер1, приходит на Сервер2 и там пропадает. 

 

Трафика между Сервер1 и Сервер2 кроме IPv4 и ARP в tcpdump не видно.

 

При этом, параллельно с запущенным пингованием длинными (3000) пакетами iperf работает и показывает заявленную (6 Мбит/сек) скорость. Т.е. эффект заметен только на фрагментированных пакетах. Пинг 1472 еще проходит, выше - нет.

 

Может быть при включении tc на Сервер1 начинают как-то маркироваться пакеты, и Сервер2 принимает решение прекратить маршрутизацию?

Или может быть Сервер 2 начинает собирать части в большой пакет и он не проходит?   

[vurd]

Замените tc на ipt_ratelimit

[h3ll1]

On 3/22/2021 at 12:38 PM, lacost said:

kоллеги, столкнулись с необъяснимыми потерями пакетов

Вот и понадобился админ. :)

16 hours ago, vurd said:

Замените tc на ipt_ratelimit

замените на nft (nftables)

Edited March 25, 2021 by h3ll1

[lacost]

В 25.03.2021 в 08:32, vurd сказал:

Замените tc на ipt_ratelimit

Заменили. Волшебство в действии.

Вместо 2х серверов, те же задачи тащит один сервер.

Поставили в боевой тест.

 

@vurd - спасибо за наводку. 

 

[vurd]

В 30.03.2021 в 08:40, lacost сказал:

Заменили. Волшебство в действии.

Вместо 2х серверов, те же задачи тащит один сервер.

Поставили в боевой тест.

 

@vurd - спасибо за наводку. 

 

Пицот!