Доброго дня, %username%!
Хочу поведать поучительную историю, которая случилась сегодня у меня на работе. Работаю я в одной очень известной компании предоставляющей, в числе прочих, услуги доступа ко всемирной паутине. И суть моей работы заключается в поддержании нормальной работы сети передачи данных. Сеть эта построена по классической структуре Ядро, Агрегация, Доступ. Коммутаторы доступа приблизительно на половину производства D-Link, вторая (большая) половина от Huawei. Управление всем сетевым железом вынесено в отдельный вилан, через него же оно всё и мониторится.
И вот сегодня поутру стало твориться нечто неладное. Система управления и мониторинга железа стала выкидывать «портянки» событий «коммутатор *** офлайн»-«коммутатор *** онлайн». Причём сообщения эти приходили по сегментам сети, в которых установлены были коммутаторы производства Huawei. Беглый просмотр состояния шторм-контроля и загруженности интерфейсов на агрегации ничего не дал, ничего не сказали и логи. День обещал быть весёлым…
Звонок от службы мониторинга сети не добавил радости — завели инцидент по выпадению домовых узлов. При этом массовых жалоб от клиентов об ограничениях в получении услуги не поступало. Удалось даже найти клиента в проблемном сегменте, который отвечал на ICMP обнадёживающими 0,8-ю милисекундами. Попытки зайти на какой-либо коммутатор по телнету были сродни пытке: коннект либо отваливался по тайм-ауту, либо приходилось минутами ждать реакции на ввод логина/пароля и на команды. Отчаявшись посмотреть лог «полуживого» коммутатора я, для очистки совести, помучившись изрядно, перезагрузил его. Секунд 10 после старта коммутатор был жив, бодренько отвечая на ICMP запросы, но тут же «пинги» на глазах стали принимать совершенно неприличные значения в 800-1000 мс, а потом и вовсе пропали.
Тут до меня стало доходить, что процессоры, отнюдь не высокопроизводительные у коммутаторов, явно чем-то загружены и, по всей видимости, на все 100%. Запустив tcpdump на vlan-интерфейсе сервера мониторинга я нашел причину высокой загрузки CPU на коммутаторах. Аномально большое количество ARP трафика в вилане управления — несколько тысяч пакетов в секунду. Причина найдена, но вот как отыскать её источник? Было решено заблокировать вилан управления на всех портах агрегации и потом по очереди разблокировать его обратно пока не будет найден проблемный сегмент.
Я успел проделать эту операцию всего на двух узлах агрегации, как вдруг внезапно вся эта свистопляска прекратилась. Но очень подозрительным мне показалось то, что минутою раньше мой коллега, сидящий за соседним столом, вынул сетевой патчкорд из порта коммутатора который служил для доступа к оборудованию и его настройки. Я попросил коллегу снова подключить свой ноутбук в сеть — спустя 10 секунд «пинги» на коммутаторы опять взлетели до безобразных значений. Источник был найден, но этот ноутбук не один месяц использовался для обновления ПО и настройки сетевого оборудования, что же могло с ним такое случиться?
Для начала решили, хотя и наличествовал установленный антивирус, просканировать на наличие зловредов утилитами от доктора и лаборатории. Ничего существенного найдено не было. Попробовали загрузиться в Linux — сетевая молчала, никакого флуда. Обратно загрузили Windows — стойкий эффект, сразу же вилан наполнялся ARP флудом. Но буквально вчера с ноутбуком всё было в порядке! И тут я зачем-то полез в настройки сетевой карты… Коллега мой не часто занимается настройкой железа и обновлением ПО на нём, поэтому запомнить значения маски и шлюза для сети управления он не мог. И он допустил досадную ошибку в конфигурации сетевой карты — вместо 255.255.224.0 для маски подсети он указал 255.255.254.0!
Но что ещё более меня поразило, так это то, что несмотря на явно неправильную конфигурацию (шлюз в ней оказался за пределами сетевого сегмента из-за неверно указанной маски), операционка безропотно проглотила этот бред! Превратив ноутбук в генератор ARP трафика. Вот что было в настройках протокола ipv4:
IP адрес 10.220.198.111
Маска 255.255.254.0
Адрес шлюза 10.220.192.1
При такой маске подсеть ограничена IP адресами 10.220.198.1 — 10.220.199.254 и шлюз 10.220.192.1 лежит вне этого диапазона. Операционная система не должна разрешать присваивать адрес шлюза из другой сети. Это явный баг!
Был бы признателен если бы кто-то взял на себя труд объяснить механизм возникновения ARP флуда в данной ситуации, от себя же хочу пожелать всем специалистам сетевикам внимательности и ещё раз внимательности. Как говорится — семь раз отмерь, один раз отрежь.
Автор: Yoda33
