Мы небольшой региональный интернет-провайдер. Недавно случился у нас инцидент.

Первый звоночек прозвенел, когда было зафиксировано резкое уменьшение нагрузки на внешнем интернет‑канале, сопровождавшееся записями в логах KERNEL PERF interrupt took too long, lowering на одном из серверов, обеспечивающих доступ в сеть Интернет. Расследование показало, что нагрузка вернулась к норме в течение 15 минут, и никаких последствий не было выявлено.

Последствия проявились через несколько часов, когда нагрузка упала уже значительно с одновременным увеличением пинга до всех узлов с внешней зоны Интернета. Оперативно принятые меры позволили устранить проблему, но не дали понимания полной картины происходящего. На всякий случай были остановлены некритичные ресурсоёмкие сервисы, чтобы снизить нагрузку.

Как вскоре выяснилось, это не помогло, и проблема опять проявилась в ещё больших объёмах. По результатам углубленного анализа исходных данных удалось выяснить несколько векторов возникновения проблемы, суть которых — неоптимальные настройки полисера. Что, однако вызывало некоторые сомнения - эта же конфигурация работала месяцами и не вызывала никаких проблем. Подозрения пали на динамическую часть конфигурации, содержащую десятки тысяч элементов. Разработали несколько вариантов оптимизации, но был принят самый радикальный - вообще отключить ACL и полисинг. Что и было тут же сделано, благо запаса пропускной способности вполне хватало, и все напряглись в тревожном ожидании. Счастья не случилось - канал опять просел, пинги рванули вверх выше Эвереста, посыпалась масса звонков от пользователей.

Тут сделаем лирическое отступление — абонент, прорвавшийся к нам через соц.сети, поведал что он в очереди 67-й (!), при том что у нас всего 20 входящих каналов! С этим надо будет разобраться позже.

При обновлении конфигурации полисера обратили внимание, что сброс таблиц nftables на какое-то время решает проблему, и казалось бы — успех уже близок. Понятно, что это какая-то программная проблема, осталось найти что именно. Стали анализировать все доступные логи, и обнаружили всплеск трафика на одном из DNS серверов. Включили реалтайм мониторинг, и несказанно удивились - десяток абонентов генерировал в сотни раз больше DNS запросов, чем все остальные абоненты, вместе взятые. Попахивало DDoS-атакой ботнета.

Попавшие под подозрение были немедленно отключены, на DNS сервере сброшен кеш (а то мало ли — может уже отравлен), полисер перезапущен. Загрузка канала пошла вверх, пинги на 8.8.8.8 стабилизировались на обычных 18.5 мс - вот оно счатье!  Но недолго. Так как крайним на подозрении был DNS сервер, запилили в него ACL, ограничивающий сильно активных пользователей, флудящих запросами. Правда, пришлось ограничивать сильно.

И ведь помогло. Но теперь жаловались абоненты, попавшие под ограничение. С этим уже можно было работать. Дальнейший анализ не выявил каких-либо аномалий или признаков DDoS или действий ботнета. Нет, они конечно были, какой-то процент наших абонентов разводит у себя вирусы и состоит в ботнетах, не подозревая того, но всё в обычных ежедневных пределах. Проблему вызывало явно что-то другое.

Интернет внутри страны все это время работал без перебоев, платежи проходили, интернет-банкинг всех банков был доступен, местные новости и погода открывались без проблем.

Обратили внимание, что ограничение DNS снижает потребление канала в Интернет до значений менее 70% от потолка, и тогда проблема не проявляется. Забрезжил свет в конце тоннеля.

Вспомнили, что все началось с KERNEL PERF interrupt took too long в логах на одном из серверов. В нём стояли две сетевые карты Intel x710-DA4, что обеспечивало 80 Гбит/с пропускной способности. На одном из портов одной из карт значение размера кольцевого буфера отличалось от соседних, и явно было не то, что настроено изначально. Поправить размер кольцевого буфера не проблема, занимает 1 секунду, и при 4-кратном резервировании (помним, Intel x710-DA4 имеет 4 порта) не приводит к разрыву соединения. Но в данном конкретном случае простейшая операция намертво завесила сервер! Бросок в серверную, кнопка reset — сервер ожил. Пинги на 8.8.8.8 в пределах нормы, загрузка канала медленно растет, уже превысила 75% - кол-центр молчит, жалоб нет. После 80% следить перестали - и так вcё было понятно.

Послесловие.

После очень удачной линейки на чипе X520 очень уважаемая компания Intel выпустила новую модель — X710. Там всё было лучше — PCIE v3 вместо v2 на х520-х, больше аппаратных очередей, меньше энергопотребление.

Но по итогу вышла крайне ненадежная вещь, и никакими обновлениями драйверов в Intel за столько лет ничего сделать так и не смогли. Просто похоронили x710, выпустив на замену линейку E810.