lacost Опубликовано 22 марта, 2021 · Жалоба Коллеги, столкнулись с необъяснимыми потерями пакетов на макете. Т.е. мы пока не смогли найти этому какое-либо внятное объяснение. Данная схема у нас годами работала, но на новой паре серверов видим странную картину. Есть пара серверов, 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 дисциплины на одном сервере, что влечет за собой сбой в маршрутизации пакетов на другом сервере. Или я чего-то упускаю? Что это может быть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sacrament Опубликовано 22 марта, 2021 · Жалоба А между 1.3 и 2.4 гигабитный интерфейс? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lacost Опубликовано 22 марта, 2021 · Жалоба 3 часа назад, Sacrament сказал: А между 1.3 и 2.4 гигабитный интерфейс? Да, но там только исходящий из 1.3 в 2.4 и нагрузка там 5-10% от входящего. Перегруза там нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rm_ Опубликовано 22 марта, 2021 · Жалоба 7 hours ago, lacost said: между сервером 1 и 2 есть какая-то связь, которая появилась в новых дистрибутивах/ядрах, которая при повышенной нагрузке как-то уведомляет соседей о перегрузке линка? Этого же самого линка? Ну этож широко известный Flow Control. Советы разнятся от выключать везде, до включать везде. В качестве универсального можно применить "переключите на по-другому чем щас". Другого линка, каких-то линков "вообще"? Нет такого. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dr Tr0jan Опубликовано 22 марта, 2021 · Жалоба 40 minutes ago, rm_ said: Советы разнятся от выключать везде, до включать везде. Если это оно, то надо понимать, как оно работает. Иногда, это не оно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 22 марта, 2021 · Жалоба По моему мнению Flow Control фича исключительно для клиентских портов, ибо просить "заткнутся не надолго" сервер/роутер, особенно со стороны клиента не очень умно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lacost Опубликовано 23 марта, 2021 · Жалоба Про Flow Control понял. проверим. А вот здесь вообще не понял: 10 часов назад, rm_ сказал: В качестве универсального можно применить "переключите на по-другому чем щас". Другого линка, каких-то линков "вообще"? Нет такого. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rm_ Опубликовано 23 марта, 2021 · Жалоба 2 hours ago, lacost said: В качестве универсального можно применить "переключите на по-другому чем щас". Это продолжение по Flow Control, о том что с ним сделать. :) Обычно рекомендуют выключать, но здесь же на форуме помню какую-то проблему с потерями или низкой скоростью, которая решилась включением. 2 hours ago, lacost said: Другого линка, каких-то линков "вообще"? Нет такого. Речь о том, что помимо Flow Control других механизмов которыми сервер может сообщать другому о загрузке его интерфейсов - нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lacost Опубликовано 23 марта, 2021 (изменено) · Жалоба Насильно отключаем 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 с каждой стороны. Изменено 23 марта, 2021 пользователем lacost Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 23 марта, 2021 · Жалоба qlen на бондинге/вланах/etc, куда шейпер навешан, надеюсь поднят до 1000 хотя бы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lacost Опубликовано 23 марта, 2021 · Жалоба 8 минут назад, NiTr0 сказал: qlen на бондинге/вланах/etc, куда шейпер навешан, надеюсь поднят до 1000 хотя бы? Да, ровно 1000 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lacost Опубликовано 24 марта, 2021 · Жалоба Сделали апгрейд соединения 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 начинает собирать части в большой пакет и он не проходит? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 25 марта, 2021 · Жалоба Замените tc на ipt_ratelimit Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
h3ll1 Опубликовано 25 марта, 2021 (изменено) · Жалоба On 3/22/2021 at 12:38 PM, lacost said: kоллеги, столкнулись с необъяснимыми потерями пакетов Вот и понадобился админ. :) 16 hours ago, vurd said: Замените tc на ipt_ratelimit замените на nft (nftables) Изменено 25 марта, 2021 пользователем h3ll1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lacost Опубликовано 30 марта, 2021 · Жалоба В 25.03.2021 в 08:32, vurd сказал: Замените tc на ipt_ratelimit Заменили. Волшебство в действии. Вместо 2х серверов, те же задачи тащит один сервер. Поставили в боевой тест. @vurd - спасибо за наводку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 31 марта, 2021 · Жалоба В 30.03.2021 в 08:40, lacost сказал: Заменили. Волшебство в действии. Вместо 2х серверов, те же задачи тащит один сервер. Поставили в боевой тест. @vurd - спасибо за наводку. Пицот! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...