Беда с UDP портами в Debian 7.4

раз/два в сутки закрываются все UDP порты.

В какое время? В одно и тоже? Бекапы настроил по крону?

в разное. Один раз может и в 8 вечера, может и в 10, а может и утром. А вот порты разом кроются.

Бекапы есть и без крона.

Я к тому, что может нагрузка на проц возрастает и пакеты просто не доходят? UDP без подтверждения всё-таки.

пакеты дружно для всех не доходят. А с процем всё норм, пробовал даже оффать почти всё, кроме нужного сервера. Да и по htop'у проц не занят: http://er-mta.net/screenshots/cloud/Screenshot_at_2014_04_12__23_29_54.png

Однако теряется коннект по UDP и это факт.

что именно происходит — существующие соединения отваливаются или просто серверные приложения перестают отвечать на новые запросы? как долго это обычно длиться — минуты, часы? что при этом в логах самих сервисов — они видят входящие коннекты или до них даже не доходит (что более вероятно)? можешь ли ты взять tcpdump в такой момент?

а, и еще — какая версия ядра и какой дистрибутив?

UDP это как письмо по почте. Что бы его подтвердить Нужно в ответ отправить такое же письмо. Причём всё это происходит в масштабе времени маши, а не человека. Т.е. никакими htop'ами ты это не поймаешь. Лучше логи покажи сервера (который обрабатывает) ну и dmesg посмотри.

Существующие соединения отваливаются и серверные приложения перестают коннектить UDP порты. Длится это от 2 до 10 минут. В логах пусто (да и приложения-то не умеют сообщать о бедах), разве что при тесте портов в консольке приложения говорится, что UDP закрыты (см http://er-mta.net/screenshots/cloud/Screenshot_at_2014_04_12__22_35_13.png ). tcpdump сообщает, что пакеты доходят, но физически ни один сервер не может общаться ни с одним клиентом.

dmesg спамит сообщениями вида:

[5214116.441546] IPv6 addrconf: prefix with wrong length 48 [5214116.442156] IPv6 addrconf: prefix with wrong length 48 [5214316.948204] IPv6 addrconf: prefix with wrong length 48 [5214317.028876] IPv6 addrconf: prefix with wrong length 48 [5214345.577194] IPv6 addrconf: prefix with wrong length 48 [5214345.579772] IPv6 addrconf: prefix with wrong length 48 [5214369.771693] IPv6 addrconf: prefix with wrong length 48 [5214369.773671] IPv6 addrconf: prefix with wrong length 48 [5214570.276905] IPv6 addrconf: prefix with wrong length 48 [5214570.280193] IPv6 addrconf: prefix with wrong length 48 [5214770.786798] IPv6 addrconf: prefix with wrong length 48 [5214770.798854] IPv6 addrconf: prefix with wrong length 48 [5214815.716146] IPv6 addrconf: prefix with wrong length 48 [5214815.719686] IPv6 addrconf: prefix with wrong length 48 [5214872.413879] IPv6 addrconf: prefix with wrong length 48 [5214872.416840] IPv6 addrconf: prefix with wrong length 48

IPv6 addrconf

Гугл:

If you're seeing errors like:

IPv6 addrconf: prefix with wrong length 48
In your dmesg / syslog on Ubuntu, add the following params to your sysctl

# Don't listen for RA's or autoconf
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.eth0.accept_ra=0
net.ipv6.conf.eth0.autoconf=0
net.ipv6.conf.lo.accept_ra=0
net.ipv6.conf.lo.autoconf=0

Это-то понятно, но разве это может повлиять на работу UDP в ipv4?

Это-то понятно, но разве это может повлиять на работу UDP в ipv4?

Раз понятно, то выясни причину такого поведения.

Кстати, запись в лог это атомарная операция уровня ядра. Так что множество подобных сообщений могут приводить к потере пакетов upd, которые, как я уже несколько раз тебе сообщал, не имеют гарантии доставки.

Ещё можешь у разработчиков поинтересоваться, что они делают, если ответного письма не получают.

в такой момент а) протестируй доступность удп-портов с локалхоста и б) посмотри что в нетстате и в каком состоянии сокеты. посмотри нет ли например интеррап-шторма, посмотри что пакеты не застревают в connection queue сокетов потому что процессы внезапно на чем-то заблокировались, например на IO которое почему-то затупило.

наконец, попробуй наобум свежее ядро — я видел такой баг на редхатах 2.6 ветки, непомню уже чем это было вызвано, помню что чем-то из бекпортов и они его в апстриме в 3-ей линейке ядер уже фиксили.

Пока что лишь оффнул поддержку ipv6, ибо хламился dmesg. Мб в этом и был косяк. А ядро там далеко не 2.6: стоит 3.2.0.4 amd64, деба 7.4 же.

ИМХО, ситуация не очевидная, может у вас просто игровой сервер глючит. Я бы для начала активировал на сервере xinetd echo-dgram , и с помощью nc постоянно (допустим раз в 10 секунд) поверял, работает ли этот udp. И если и там будет ситуация аналогичная, такая что tcpdump на сервере видит только входящие udp-пакеты (порт 7), а ответных исходящих пакетов нет, то, наверное, что-то с ядром.

Игровой сервер может и глючил бы, да не 11 штук сразу и на одно время.

Чудеса разные бывают. Может все эти сервера используют одинаковую библиотеку.

И то, что вы наблюдаете tcpdump'ом udp пакеты без ответов на них игровым сервером, не говорит, что он их действительно не получает. Ведь вы не знаете протокола, не знаете какое должно быть содержимое пакета. Может у хостера маршрутизатор что-то не то делает с содержимым udp-пакетов.

Но, в общем то я ни на чём не настаиваю.