Panasonic атакует

:

image

Совсем недавно, анализируя причины перебоев в работе сетевого оборудования, я выявил очень интересную ситуацию. Расследование длилось почти месяц, и в результате была выявлена цепочка событий, которые в совокупности способны уложить корпоративную подсеть на ура.

Данная статья представляет из себя достаточно интересную головоломку, с подробным анализом того, как она была разгадана. Я думаю, данный случай будет интересен не только системным и сетевым администраторам, но и рядовым пользователям, которые могут даже не подозревать, что же может крыться за обыкновенным МФУ, неприметно стоящим в углу кабинета, в ожидании своего часа…

А для тех кто часто употребляет фразы типа «это необъяснимый глюк», или «работа данного оборудования зависит от погоды и уровня осадков в южной зимбабве» эта статья просто «must read», ибо я убежден, что любое явление можно объяснить с помощью фактов, логики и здравого смысла. И это статья яркое тому подтверждение.

И так началось все с того, что в логах некоторых коммутаторов корпоративной сети стали появляться сообщения такого содержания: «%SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port FastEthernet0/24 on VLAN000X». Знающие люди, наверное, сразу узнали сообщение в стиле Cisco IOS, а для остальных поясню: коммутатор зафиксировал петлю в сети, в связи с чем заблокировал трафик некоторого VLAN X на 24-ом порту. В данной статье под одним VLAN можно понимать одну подсеть (но только в данной статье, и исключительно для понимания описываемых событий). Так как речь идет о коммутаторе уровня доступа, а 24-ый порт связывает его с остальной сетью, то пострадавшими оказываются пользователи, подключенные к данному коммутатору и находящиеся в этой самой подсети.

Радовали лишь два обстоятельства: во-первых, порт блокировался менее чем на секунду, во-вторых, жалоб от пользователей не поступало. Пока. А значит, было время разобраться в проблеме, и не поднимая лишнего шума, устранить её.

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

Мысль о существовании реальной петли сразу была отброшена напрочь, так как не имела никаких прав на существование (опыт подсказывал). На тот момент сразу сложилось понимание того, что в сети существует некий процесс, который каким-то образом заставляет коммутатор «обнаружить петлю».

Первым делом я перерыл все логи в поисках корреляции нескольких событий во времени. И обнаружил, что каждый раз, когда происходит такое «обнаружение петли» происходит разрыв связи с одним из сетевых принтеров фирмы Canon, находящимся в этом же VLAN-е. Так как это происходило с разницей в 2-3 секунды, я пришел к выводу, что он тоже слышит в сети что-то, от чего ему становиться плохо, и он передергивает сетевой порт, а может и вовсе перегружается. Идти до него было лень, но явно ему плохело по тем же причинам.

Единственное, что могли слышать все участники одного VLAN, а значит единого широковещательного домена на 2-ом уровне, это разумеется broadcast, т.е. собственно широковещательный пакет.

Ну что же, раз скорее всего это broadcast, значит я тоже могу его услышать. Поставил отдельную тачку, подключил к нужному VLAN, и запустил на ней сниффер с анализатором протоколов, который круглые сутки писал все на диск. Абсолютно все, но только то, что мог слышать. А что он мог слышать? А слышать он мог трафик свой собственный, который интереса не представлял, и весь широковещательный трафик сети. А нам большего и не надо.

Первые результаты работы сниффера меня…ну, мягко говоря, удивили. Для данного сегмента сети, ну т.е. для всего этого VLAN-а, нормой было 500-1000 широковещательных пакетов в секунду.

Вот тут я пожалуй сделаю маленькое отступление. Некоторые сразу возмутятся, мол откуда так много трафика?! Во-первых сегмент сети достаточно большой – на вскидку 200-300 машин. Во-вторых в этот сегмент производится ридирект IPX-трафика, который очень активно использует именно широковещательные рассылки. Так что такие значения интенсивности трафика меня вовсе не удивили.

А вот это удивило:
image

В тот самый момент, когда некоторые коммутаторы сети фиксировали «петлю», широковещательный трафик в сети зашкаливал за 20’000 пакетов в секунду! Но откуда?

На этот момент уже прояснилось несколько моментов. «Петлю» фиксировали только коммутаторы серии Cisco2950, коих в сети всего два. Чаще всего это событие происходило сразу на обоих коммутаторах, но периодически проблема проявлялась лишь на одном из них, не касаясь второго. Самым интересным оказалось, что проблема каждый день проявлялась дважды точно в одно и то же время, и 1-3 раза в моменты времени абсолютно не повторяющиеся. На графике видно проявление проблемы в 10:27 утра. Вторым часом X было время 9:34 утра. Каждый день в это время ситуация повторялась. Это была первая зацепка.

На графике верхняя черная линия – это весь трафик отловленный сниффером. А синяя – это все ARP запросы. Как известно ARP-запрос рассылается широковещательным пакетом, и присутствие этого трафика вполне укладывается в рамки моего понимания. Но именно из ARP-запросов и состоит весь гребень этой самой волны в 20’000 пакетов! Стоит еще отметить маленький всплеск зеленой линии. Это SNMP-трафик(в двух словах — протокол управления сетью). А также красный всплеск – это unicast-flood. Но к ним мы вернемся позже.

Анализ логов сниффера затянулся не на один день. Я также обнаружил, что в момент проявления проблемы сеть наполняло unicast-flood-ом, т.е. говоря несколько более простым языком большое количество коммутаторов типа Cisco3560(это не свитч за 500 рублей, это управляемое сетевое оборудование корпоративного уровня с соответствующей стоимостью) на какой-то промежуток времени начинали работать как тупой хаб. Это совсем ставило в тупик. Ситуация развивалась как в сказке – чем дальше тем страшнее. И мне предстояло столкнуться с неким монстром, который мог вытворять такое!

И вот среди шквала ARP-запросов и флуда unicast-трафика мне удалось выделить четыре пакета. Четыре пакета, которые всегда появлялись в момент проявления проблемы, и что самое главное первый из них всегда появлялся ДО появления этой волны.

Что же это были за пакеты такие? Четыре абсолютно одинаковых широковещательных пакета, от одного источника. Точнее в 9:34 от одного, а в 10:27 от другого, и еще иногда от третьего в произвольные моменты времени. И так, вот что представлял из себя этот пакет:

image

Вообще-то говоря ничего криминального. Всего лишь некое МФУ фирмы Panasonic во всеуслышание объявила о себе, послав широковещательный пакет с TTL=1 в пределах своей подсети на UDP-port 3892(pcc-image-port). Ну и что тут такого ужасного?

На первый взгляд действительно ничего. Но вот тут интерес посмотреть на это чудо техники японских разработчиков пересилил лень. Имея MAC-адрес, я быстро определил месторасположение этого девайса и направился к нему. Ничего высокотехнологичного я не увидел, ну МФУ как, МФУ. Но тут возникла мысль. Порты коммутаторов, к которым подключены данные МФУ всегда передергивались(link up/down), перед тем как они формировали такой пакет. Было два варианта. Либо он перезагружается, и формирует его, либо он по каким-то причинам перезагружает работу своего сетевого интерфейса. В любом случае перезагрузка этого МФУ могла бы смоделировать эту ситуацию.

Это был headshot! Перезагружая МФУ, я моделировал эту ситуацию снова и снова. Сомнений не оставалось – вот оно – ЗЛО!

Но обнаружение проблемы это пол дела, гораздо сложнее, но и интереснее, понять, почему так происходит, а особенно, почему это происходит каждый раз в одно и то же время? Какая первая мысль? Конечно же перезагрузка МФУ-шек по расписанию! Я выяснил, что всего в данном сегменте сети присутствует три таких МФУ, и установлены они были как раз месяц-два назад. Получив доступ к вэб-интерфейсу этих железок я перерыл их вдоль и поперек, но ни о каких перезагрузках по расписанию не было и речи. И тут…и вот тут я обратил внимания, что системное время на этих МФУ не соответствовало реальному. А отличалось оно на…9 часов 34 минуты на одном и на 10 часов и 27 минут на другом! Т.е. они перезагружались ровно в полночь, ровно в 00:00, но по своим внутренним часам.

Связисты подтвердили, что есть у Панасовских АТС-ок такая особенность – ребутиться в полночь. Видимо МФУ получил АТС-ное наследство, ибо его прямым предком явно являлись факсимильные аппараты. Что касалось третьего МФУ, то судя по всему его часто перезагружали руками, выдергивая из розетки, что и вызывало возникновения проблемы в произвольные моменты времени.

Таким образом был однозначно определен виновник – МФУ Panasonic. И стало ясно, почему эти события происходят в фиксированные моменты времени, ровно как стало ясно, почему бывают проблемы и в случайные моменты времени. Но нужно было еще понять, почему возникало такое количество ARP-трафика в сети, почему плохеет коммутаторам, и откуда вылазит флуд.

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

И так. Полная Хронология событий происходящих в сети в момент включения любого из подозреваемых МФУ (по ходу дела считайте количество широковещательных пакетов при каждом событии):

1. При включении формируется пакет, дамп которого был приведен выше, и рассылается по всей сети. Пакет рассылается 4 раза, но благо все те устройства, что этот пакет получают, реагируют лишь на первый такой пакет, игнорируя остальные. В противном случае волна широковещательного трафика была бы в 4 раза больше! А теперь отметим, что это собственно 4 широковещательных пакета.

2. ПО, установленное на клиентских машинах(PCCMFLPD.EXE, которое как раз и слушает этот самый 3892-ой порт), получает этот пакет. Для примера укажем, что у нас 60 таких клиентов, по 20 на каждое МФУ (да, большие такие кабинеты).

3. И тут происходит неожиданное. Это ПО общается с МФУ по протоколу SNMP. И все клиенты получившие такой пакет рассылают широковещательный SNMP-запрос get-next-request. Отметим, что это еще 60 широковещательных пакетов.

4. Каждое устройство, работающее по SNMP, получив такой пакет, хочет на него ответить. И значит, ему нужно знать MAC-адрес того, кто этот запрос отправил. А теперь давайте представим себе, что у нас в сети 100 устройств, включая эти 3 МФУ, которые работают по протоколу SNMP. Откуда так много? Ну в основном это принт-сервера HP, которые используются для печати. И что же мы получаем? каждое из 100 устройств хочет ответить каждому из 60 клиентов. Таким образом каждое такое устройство отсылает 60 ARP-запросов. А для себя отметим 6000 широковещательных запросов в сети. ARP-запросов, кстати говоря. Ага, уже пахнет жареным, но это только начало =).

5. А теперь давайте вспомним про два наших коммутатора, с которых все началось. Да-да, те самые Cisco2950. Дело в том, что когда они огребают такое количество широковещательного трафика, они воспринимают это как broadcast-storm. Это явление обычно сопровождает петли в сети, когда один пакет бесконечно ходит по кругу. А ведь эти коммутаторы и объясняют блокировку своих портов именно так: «Loop guard blocking port», т.е. «блокировка порта для защиты от петли»(криво звучит, зато понятно я думаю). Ну заблочился порт, ну и шут с ним казалось бы. Ан нет! При разблокировке порта коммутатор отсылает своему root-у в данном инстансе STP-дерева сообщение типа TCN(Topology Change Notifier), т.е. извещение об изменение топологии. А как реагирует на такое сообщение Root-овый коммутатор данного STP-дерева? Разумеется отсылает всем-всем-всем TC(Topology Change). Все коммутаторы, получившие TC как известно сбрасывают age-time таблиц MAC-адресов. Во первых именно так мы получаем unicast-flood в сети, во вторых на коммутаторах, выполняющих маршрутизацию в другие сети, возникает наведенная проблема. Они не могут маршрутизировать пакеты адресату, MAC-адрес которого не известен, и что же они делают? ARP-запрос! Т.е. все интерфейсы, на которых поднята маршрутизация для данного VLAN опрашивают все узлы данной сети по своей ARP-таблице, уточняя тем самым корректность хранящейся в них информации. Ну а мы для себя отмечаем ещё много ARP—запросов. Ну вот вам и ARP-шквал!

На самом деле 5-тый пункт нашей хронологии не точен и скуп на факты. Там есть очень много тонких моментов, и вообще говоря все не совсем так, хотя очень близко. Но это сделано умышлено, дабы смысл сих трок был ясен максимально возможному количеству читателей, а объем не зашкаливал за несколько страниц. К тому же даже краткое описание принципов STP и причин возникновения unicast-flood’а потянет еще на две три статьи.

P.S. А вообще причем тут Panasonic? Настроили бы время на МФУ правильно, и не было бы проблемы. Ночью-то все машины пользователей выключены, и нет в сети никого, кто бы услышал тот самый первый пакет. Так что никаких претензий к Panasonic нет, и быть не может. Отчасти сами виноваты. А чисто технически, перезагружать оборудование ровно в полночь это вообще-то идея хорошая, жаль только что отключить или изменить настройки нельзя.

P.S.2 Причем тут Cisco? Да и к Cisco претензий нет. 2950-ые железки слабые, честно борются с широковещательным штормом, блокируя порт. 3560-ые не менее честно реагируют на TC, вызывая флуд (я повторюсь, там ещё много тонкостей на эту тему).

P.S.3 Причем тут пользователи? А вообще не причем! Как оказалось, на тех самых 2950-ых коммутаторах нет ни одного пользователя в данном сегменте сети. Просто эти коммутаторы единственные, кто реагирует на эту проблему. Стоит заметить, что порт они блокируют не полностью, а только по данному VLAN-у, а все же остальные VLAN-ы работают без перебоев. Т.е. и проблемы-то реально не было. Но какой потенциал! А вот если бы там были пользователи… они бы точно сказали, что работа сети зависит от погоды и уровня осадков в южной зимбабве. Как видите объяснить можно все, кроме того, чего объяснять не хочется.

P.S.4 Вот такая вот маленькая победа на полях невидимого фронта…вот только сложно теперь без содрогания смотреть на те МФУ Panasonic...ideas for life, блин! =)