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, блин! =)

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 98

      +62
      Добротно так написали, хоть и не отношусь к админам, но читал взахлеб, прям блокбастер.
        0
        Довольно таки старая проблема.
        Впервые я её обнаружил, когда на рынок вышли лазерные Canon.
        Их программное обеспечение «желало лучшего» из-за чего по странному обстоятельству страдала сеть. Но это было лет 10 назад. Видно сразу что Panasonic наступил на те же грабли.
          +12
          Респект за такое расследование.
          Почти как Конан-Дойла можно читать. :)
            +14
            Ага, впору создавать новый жанр: «админский детектив» :-)
            g0ff: спасибо за интересную статью.
              0
              Аналогичные мысли возникли во время прочтения статьи. По ощущениям, как про вирусы человек здесь писал. Увлекательно. Спасибо.
              +5
              Очень увлекательное расследование, такая целеустремленность в поиске причин неполадок, очень хорошее качаство для сетевого администратора.

              Панасоники конечно молодцы :), видимо перезагрузкой решали какие-то свои внутренние проблемы, но проблема врядли бы возникла при более правильном дизайне сети, 200-300 хостов в одной подсети — это перебор, ведь при таком большом широковещательном домене проблемы с производительностью сети практически неизбежны.
                +3
                полностью с вами согласен, по поводу размеров подсети
                и проблема эта известная.
                еще хуже то, что этот широковещательный домен размазан по 30+ коммутаторам и двум зданиям!
                но увы, есть причины(от админов независящие), по которым ситуация остается неизменной и решение этих проблем отложено на неопределенный срок.
                а проблем с производительностью на практике нет.
                • UFO just landed and posted this here
                    +1
                    Для чего это сделано понятно, я и сам не раз сталкивался с подобным даже на более серьезных устройствах, например, во Львове есть несколько АТС (не мини, а настоящих — узлы горосдской телефонной сети), которые тоже перезапускаются каждую ночь и процес этот у них занимает до десяти минут.

                    Но это их не оправдывает, а наоборот говорит о качестве системного ПО :)

                    А про провайдеров и сессии: мы значит крутую билинговую систему сделали, у клиентов наших клиентов иногда бывают сесии длительностью в пару месяцев :)
                      +2
                      И «не было ни единого разрыва!» ;)
                      0
                      Можете обьяснить такой момент в работе одного провайдера?

                      Макс длинна сессии — 12ч. Примерно 15 декабря ВНЕЗАПНО сессия прекратила прерываться… на 3 недели. Так же в течении этих трёх недель не начислялась ежемесячная абонентская плата, назначенная на 20 число месяца. Никаких новостей на оф. сайте не было.
                        +2
                        Можно строить разные гипотезы, опираясь на существующий опыт, например, в нашей практике есть случаи когда разрыв сессии необходим для изменения атрибутов соединения, или бывали случаи когда на праздники связанные со сменой года нужно было отменить выполнение процедур связанных с отключением по состоянию счета.

                        Но 15 декабря, это рановато для начала сервисных процедур, а три недели это как-раз после праздников, больше всего похоже на то, что 15-го что-то сломалось, а заметили аж когда от праздиков отошли :)
                    +3
                    snmp — Stability Not My Problem. Ну или как-то так, да.
                      0
                      не Stability, а Security
                      +7
                      ещё несколько сюжетов да харизматичных персонажей и получится хороший сериал «Сетевой Хаус» ;-)
                        0
                        Администратор Хаус. Не админ, а Администратор.
                          +8
                          House S.A.
                          Season 0x0, Episode 0x0 ;)
                      • UFO just landed and posted this here
                          +5
                          Читается как детектив :-)
                          Люблю я такие расследования, жаль личное участие в них бывает очень утомительным :-)
                            +15
                            Читал статью сразу после просмотра серии «доктора Хауса». Похоже — невероятно :) Завязка, интрига, потенциально смертельно опасный баг, неверное предположение циски о петле, сложные анализы и торжество рациональной аналитики в финале.

                            Выводы:
                            1) Все устройства врут.
                            2) Все устройства ошибаются.

                            А всего-то надо было принимать витамины и вести здоровй образ жизни — при установке МФУ'шек пробить в них правильное системное время. :)
                            • UFO just landed and posted this here
                                +7
                                много слышал про «доктора Хауса».
                                ни разу не смотрел.
                                видимо стоит все же глянуть.
                                  0
                                  Кто это?
                                    +2
                                    Один гавнюк и наркоман :))
                                    Но мыслями стреляет прицельно.
                                    +6
                                    А в роли волчанки — Windows?
                                  • UFO just landed and posted this here
                                      +2
                                      А чисто теоретически, возможно ли такое ПО, которое как раз будет рассылать такие пакеты, которые исходили от МФУ при перезагрузке? Ведь это серьезная брешь в системе безопасности, т.к. вирус знающий такую уязвимость сможет положить всю корпоративную сеть.
                                        +1
                                        стоит учесть стечение обстоятельств.
                                        1) это ПО должно быть на множестве клиентов в данной подсети(допустим распространить вирусом)
                                        2) в данной подсети должно быть множество устройств, работающих с SNMP в комьюнити public
                                        3) TC(Topology Change) — вызываны слабым железом. с одной стороны в сети может и не быть таких железок. с другой стороны вся сеть может быть построена только на них, и тогда…
                                        4) есть один интересный момент, в дампе четко видно TTL=1, что не позволяет пакету покидать данную подсеть… а если IP.TTL = '255', то большому кораблю большое плавание! Но тут уже все зависит от настроек маршрутизации…

                                        наверное определяющим является второй пункт.
                                          0
                                          Вы описали ситуацию с логической точки зрения. С другой стороны, имхо, вполне можно эксплуатировать подобные схемы, даже без устройств. Тот же ARP флуд. Ну или действительно намеренно пытаться инициировать (а то и подделывать) TC.

                                          P.S: По поводу пункта 4 сомнительно. Даже если бы TTL не был 1 то пропускать бродкасты наружу это уже сомнительно имхо. Вы знаете ситуации когда они пропускаются? Или это из за VLANов?
                                            0
                                            Да конешно, для аткаи на корпоративную сеть лучше использовать специальное ПО, позволяющее сформировать любой пакет, а не таскать с собой МФУ внушительных размеров. =)

                                            Я рассмотрел ситуацию чисто гипотетически, указав, что все зависит от настроек маршрутизации, но в принципе такое возможно.

                                            VLAN в данном контексте стоит рассматривать лишь как единый широковещательный домен второго уровня, ну или проще говоря одну физическую сеть. Правда виртуальную. Они тут не при чем, т.к. маршрутизация — это уже третий уровень, а VLAN-ы исключительно второй.
                                          0
                                          Оно не только позможно, но и существует, даже вполне благонадежные диагностические утилиты позволяют сгенерировать пакет с нужными характеристиками или flood (много-много таких пакетов). Бороться с этим можно устанавливая специальные фильтры против таких атак, кроме того можна использовать чисто административные методы.
                                            0
                                            arp-ами можно столько всего наделать в корпоративной сетке… ужос
                                            0
                                            Рукоплещу анализу.
                                              0
                                              Угу-угу, было бы еще веселее, если бы в конторе стояло штук 10 таких МФУ-шек, которые синхронизировали время по NTP, но часовой пояс стоял некорректный (например, +11). Тогда DDoS был бы покруче =)
                                                +2
                                                Тогда бы невилировалась мораль статьи, о том что нужно искать обьяснение таким «мистическим» явлениям, а не спихивать на — «неисповедимы пути электронов в вычислительной машине». Описаный вами расклад привел бы к тому что на поиски его причины бросили бывсе силы, получился бы «экшн» но без морали, да и ругани в сторону Панасоника было бы.
                                                –8
                                                а не набор ли ошибок в администрировании тут
                                                огромная подсеть на тупых свичах(или не настроенный вилан)
                                                открытые порты на пользовательских машинах
                                                не настроенные циски
                                                  +2
                                                  >>огромная подсеть на тупых свичах
                                                  Cisco 2950 и 3560 — не самые тупые свичи.

                                                  >>или не настроенный вилан
                                                  Почитайте еще раз статью

                                                  >>открытые порты на пользовательских машинах
                                                  И чо?

                                                  >>не настроенные циски
                                                  Что конкретно нужно добавить в конфиг?
                                                    +1
                                                    ошибка одна — системное время на МФУ, а настройка МФУ не имеет отношения к сетевому администрированию.

                                                    назвать cisco2950 — тупым свичом… у меня язык не поворачивается. да, не корпоративный уровень, но никак не тупая.(vlan тут не при чом)

                                                    открытые порты — а зачем закрывать порты в сети, которая находиться за множеством фаерволов? и опять таки это не имеет отношение к сетевому администрированию

                                                    не настроено что?!
                                                      +1
                                                      Вопрос о том что относится к сетевому администрированию, а что нет, довольно сложный. МФУ в данном случае, всетаки, сетевой узел. Другое дело, что конфигурирование МФУ не вашего уровня задача, за такое разгильдяйство можно надавать щелбанов технику который устройство устанавливал :)
                                                      0
                                                      Тупые свичи? Открытые порты? О чем вы?
                                                      Или вы сторонник закрывать все и вся и блокировать одноклассников? ;)
                                                      Проблемы уровня системного (сетевого) администрирования тут нет.
                                                        0
                                                        А открытые портыэто очеь страшно… сродни открытым дверям? :-)
                                                        +1
                                                        А не было бы решением проблемы завести МФУ-шки через программный принт-сервер, а не выполнять печать напрямую?
                                                        Т.е. стоит Windows Server 2003, к котрому «локально» подключен по IP-порту, а сам этот принтер расшарен пользователям.
                                                        Имхо, так намного функциональнее, биллинг ко всему этому можно прикрутить, авторизация само собой, приоритезация, ну и так далее.
                                                          +3
                                                          Учитывая мой скромный опыт общения со службой принт-сервера на базе Win2003, мне не ясно, как это может решить проблему?
                                                          Ну только если выводить МФУ в другую подсеть в другом vlan-е…
                                                          А это можно сделать и без принт-сервера, т.к. клиентское ПО можно настроить по IP.

                                                          Мы рассматривали множество вариантов решения. И выводить МФУ в отдельный vlan, и в отдельную подсеть с маршрутизацией, и вырезать порты на на клиентах…
                                                          Но как это не странно самым оптимальным решением является все же именно настройка корректного времени.

                                                          Был поставлен эксперимент. В 18-00 все сотрудники уходят, выключая свои машины. Перезагрузка МФУ в 19-00 не дает никакого эффекта! Просто некому ответить на эти пакеты, а если кто и задержался на работе, то что там какие-то 200-300 пакетов?
                                                          Вот так! Все гениальное просто.
                                                            0
                                                            Логично, не за чем городить огород :)
                                                            0
                                                            Вполне возможно, а для усиления эффекта, вынести принтеры в отдельную VLAN.
                                                            Но это все в случае просто принтера, а речь идет о МФУ, его и как сканер захотят пользовать, а тут может оказаться не все так просто (решаемо, но мороки больше).
                                                              +1
                                                              А эти МФУ только как сканер и используют.
                                                              Не зря же в сети под сотню принт-серверов HP-шных. =)
                                                              А мороки никакой — тот же софт, тот же IP прописать.
                                                              Либо на клиентах, либо в DNS.
                                                              А клиенты настроить на DNS имя.
                                                                0
                                                                а что за hpшные принт-серверы? А то один тут Kyocerа c стандартным принт-сервером совсем замучил…
                                                            0
                                                            Аффтару за раследование зачет! =)
                                                            Решить проблему можно вынесением МФУ в отдельный VLAN с единственным гейтом во вне (пользовательскую сеть). В таком случае ввиду TTL=1 такого шторма не получится никак, т.к. дальше выделенного VLAN-а пакеты не уйдут.
                                                              +2
                                                              Вот они, админские будни :)
                                                                +4
                                                                А по вечерам автор курит трубку и играет на скрипке.

                                                                0
                                                                отличное чтиво.
                                                                и отличная работа проделана.
                                                                тоже люблю выяснять детали разных казусов.
                                                                  +1
                                                                  Вопрос к автору

                                                                  Где такому учат или где вы учились?
                                                                    +2
                                                                    если не считать высшего образования и опыта работы, то главный источник знаний в данном вопросе — cisco.com
                                                                    +1
                                                                    Немного смущает терминология «коммутатор зафиксировал петлю в сети», a la Cosmopolitan. Начнем с того, что петли никакой нет и фиксировать ее никто не мог. В реальность технология Loop Guard придумана для того, чтобы в ситуации если коммутатор перестал получать BPDU на non-designated порт, вместо того, чтобы переводить его в состояние Forwarding, блокирует его на случай однонаправленой потери линка, предотвращая таким образом образование кольца на L2.

                                                                    Так что утверждение «когда они огребают такое количество широковещательного трафика, они воспринимают это как broadcast-storm» не соответствует действительности в Вашем случае — такая функциональность возможна, но если бы она сработала, сообщение об ошибке было бы другое.

                                                                    Мне в этой истории непонятны два вопроса:
                                                                    1. Куда делось BPDU, отсутствие которого спровоцировало Loop Guard ошибку? 6000 мелких пакетов настолько забили транк?
                                                                    2. Насколько я понимаю, аксесс-коммутаторы соединены одним транком с центральным устройством. Зачем при таком сценарии включать на единственном рут-порте Loop Guard, который по умолчанию выключен на всех портах (во всяком случае на всех железках, которые я видел)? Или все-таки были избыточные соединения?
                                                                      0
                                                                      2. portfast по-умолчанию как раз-то выключен. Те именно по-умолчанию будет дедектися петля.
                                                                        0
                                                                        Я ничего не писал про PortFast, речь шла про Loop Guard.

                                                                        PortFast, опять-таки не «детектит петли», а безусловно переводит порт в Forwarding, миную Listening и Learning, всё.
                                                                          0
                                                                          Я наверное не понимаю фразу «Зачем при таком сценарии включать на единственном рут-порте Loop Guard..». Я так понимаю он всегда ON по дефолту на транк порту? Нет?
                                                                            0
                                                                            По ссылке, которую я дал можно прочитать: «By default, loop guard is disabled.» Далее я повторил это по-русски.
                                                                              0
                                                                              Все вижу, не заметил с первого раза.
                                                                        +1
                                                                        Долго думал, что вам ответить.
                                                                        Во-первых, позволю себе заметить, что в статье после 5-го пункта есть абзац содержащий такие фразы:
                                                                        "… не точен и скуп на факты."
                                                                        "… вообще говоря все не совсем так, хотя очень близко."
                                                                        «краткое описание принципов STP и причин возникновения unicast-flood’а потянет еще на две три статьи.»

                                                                        Во-вторых, во общем, я с вами согласен, но есть некоторые особенности, которые я не осветил, а вы не учли.
                                                                        Я предлагаю написать небольшую отдельную статью в блоге Cisco, с описанием особенностей работы коммутаторов серии cisco2950. Там я подробно изложу свою точку зрения, с соответствующими аргументами. И если у вас останутся вопросы, то мы сможем обсудить их в комментариях к той статье, так как это уже вопросы более специфические.
                                                                          0
                                                                          Ждём с нетерпением. Тема «Cisco» теперь очень заинтересовала!
                                                                      • UFO just landed and posted this here
                                                                          +4
                                                                          если вопрос к автору, то отвечаю:
                                                                          с такой увлекательной работой и большими возможностями профессионального роста(не карьерного, а именно профессионального) — это не важно!
                                                                          а вообще не много =\
                                                                            0
                                                                            респект за первую часть ответа! :))
                                                                          +2
                                                                          мдя. и после этого юзвери смеют говорить, что админы сидять и «ничерта не делают».
                                                                          вот они, бойцы невидимого фронта.
                                                                            0
                                                                            Перечитал статью 4 раза. С удовольствием :)
                                                                              0
                                                                              Проблемы бы не было, если бы циска и панасоник не экономили на программистах. Тупое введение паузы произвольного периода (0… пара секунд) между:
                                                                              1. Наступлением 00:00 и перезагрузкой
                                                                              2. Получением пакета на порт 3892 и отправкой ответа
                                                                              3. Получением TC-пакета и началом инициализации таблицы MAC-адресов (которую тоже хорошо бы чуть-чуть растянуть во времени)
                                                                              позволило бы избавиться от кучи головняка.
                                                                                0
                                                                                1. момент времени, когда происходит перезагрузка не влияет на дальнейшее развитие событий, хоть это 00:00:00, хоть 00:00:02.
                                                                                2. Да, при таком стечении обстоятельств предложенное вами решение растянет волну во времени, и снимет все наведенные проблемы. Но во первых такое решение это заплатка, а не решение проблемы на корню. Во-вторых, разве могли такое предположить разработчики ПО для МФУ класса SOHO(SmallOfficeHomeOffice)? Я думаю им простительно.
                                                                                3. Чем меньше интервал времени между реальным изменением топологии сети, и сбросом MAC-таблиц, тем меньше вероятность дропа(потери) пакетов. Одно лечим, другое калечим. К тому же этот интервал можно вручную настроить в IOS(операционная система, применяемая на оборудовании cisco) разным на разных устройствах. Но все же в идеале нужно стремиться к минимальному значению, и одинаковому поведению(стандартизация) всех узлов сети. Иначе, когда, как вы предлагаете такие временные интервалы будут определяться случайным образом, диагностировать проблемы в сети станет в разы сложнее!
                                                                                  –1
                                                                                  > 2. Да, при таком стечении обстоятельств предложенное вами решение растянет волну во времени, и снимет все наведенные проблемы. Но во первых такое решение это заплатка, а не решение проблемы на корню. Во-вторых, разве могли такое предположить разработчики ПО для МФУ класса SOHO(SmallOfficeHomeOffice)? Я думаю им простительно.

                                                                                  Они тупые индусы, если не могли такое предположить. Они сами спланировали ситуацию, в которой
                                                                                  а) широковещательный пакет влечет за собой ответы от всех присутствующих клиентов в данном сегменте сети (1 пакет запрос, 10-100-1000 ответов на него мгновенно — это нормально? У любого вменяемого человека в голове сразу же загорелась бы неонка лампочка, что такое делать нельзя.)

                                                                                  > 3.

                                                                                  Х.З. Понятно, что хочется за минимальное время всё сделать, но такой вариант решения — далеко не оптимальный. Зачем рассылать сразу всем клиентам ARP-запросы? Можно рассылать их по мере появления пакетов для них (т.е. для неизвестных пока MAC-адресов).
                                                                                  0
                                                                                  ПО на компах, некий PCCMFLPD.EXE. Не очень понимаю зачем оно вообще нужно. Без него не печатает? Или это для сканера?
                                                                                  Я бы сказал соответствующим людям что бы снесли это вредоносное ПО.
                                                                                  +1
                                                                                  вот если бы не написали бы в начале статьи про panasonic и мфу в углу комнаты, было бы вобще супер :)
                                                                                    0
                                                                                    С удовольствием принимаю вашу критику!
                                                                                    Было два варианта:
                                                                                    1. Не писать сразу про МФУ в углу комнаты, и тогда читатель подсознательно искал бы в статье ответ на вопрос КТО? Кто же виноват в этом?
                                                                                    2. Начав статью с недвусмысленного намека на виновника, я переключил интерес читателя на поиски ответа на вопрос ПОЧЕМУ? А именно это и было главной идей статьи. Не найти виновника, а понять почему так происходит.
                                                                                    А за дельную критику в литературном(а не техническом) ракурсе — спасибо.
                                                                                      0
                                                                                      пожалуйста :)
                                                                                    0
                                                                                    читал на одном дыхании :]
                                                                                      0
                                                                                      Эркюль Пуаро network edition! Настоящий детектив! Очень интересно.
                                                                                        0
                                                                                        Следствие ведут знатоки (с).
                                                                                        Автору множественный респект, давно с таким интересом не читал.
                                                                                          0
                                                                                          Вах, очень увлекательно, спасибо.
                                                                                            0
                                                                                            Рекомендую приложить сслыку на пост в свое резюме
                                                                                            • UFO just landed and posted this here
                                                                                                0
                                                                                                NetWare — зона ответственности серверистов, а я все же сетевик. Как следствие дать подробного и развернутого ответа не могу.
                                                                                                Но на сколько я понимаю NetWare — это лишь пережиток прошлого, и сейчас его роль сведена лишь до каталогов директорий(организация доступа к ресурсам) и файл-серверов. Но повторюсь, я могу ошибаться.
                                                                                                0
                                                                                                А что за родное ПО Panasonic? для чего оно используется?
                                                                                                Имеется ввиду драйвер принтера или что-то другое?
                                                                                                  0
                                                                                                  Драйвер принтера + дополнительное ПО.
                                                                                                  Оно необходимо для реализации функции сетевого сканера в первую очередь. Заметьте МФУ имеет сетевой порт Ethernet, т.е. это полноценный сетевой сканер. А также для мониторинга принтеров. Это ПО кстати обнаруживает все принт-сервера в сети, и очень хорошо подходит для их мониторинга(оно цепляет все наши HP-шники, а это около сотни!). В главном окне выводиться весь список принтеров и их текущее состояние — например «Готов», или «кончился картридж», «нет бумаги» и т.д. Вообще-то очень удобно. Само ПО проблем не вызывает, и нареканий к нему нет… ну пока оно не услышит зов МФУ =)
                                                                                                    0
                                                                                                    Мда, коварное ПО)
                                                                                                    но я скорее всего оставил бы его только там, где оно действительно нужно. А просто печатать и тем более снимать копии можно и без дополнительного ПО.
                                                                                                    По моему опыту — сканером в МФУ пользуются чрезвычайно редко. А так как к МФУ для сканирования все равно далеко ходить нужно, то людям проще дойти до полноценного сканера.
                                                                                                      0
                                                                                                      > сканером в МФУ пользуются чрезвычайно редко
                                                                                                      В это сложно поверить, но я видел своими собственными глазами!
                                                                                                      Скорость сканирования у это МФУ чисто визуально близка к странице в секунду.
                                                                                                      В него заряжают стопку договоров, и он их сканит с бешенной скоростью.
                                                                                                      Дык вот, что бы перезагрузить МФУ, мы каждый раз были вынуждены дожидаться окончания процесса сканирования. Сложилось впечатление, что МФУ-шка сканирует документы 8 часов в день, каждый день. Это по странице в секунду!
                                                                                                      0
                                                                                                      Так причина проблемы-то всё же в этом самом ПО, а не в МФУ? МФУ ведь только провоцируют проблему, как я понял, это мог бы сделать кто угодна. А Вы говорите, что нареканий к ПО нет, как же так? :)
                                                                                                        0
                                                                                                        Нет нареканий к ПО в штатном режиме работы.
                                                                                                        Данная ситуация это все же больше стечение обстоятельств, нежели кривизна ПО, имхо.
                                                                                                    –1
                                                                                                    Мне как ленивый админ с 9 стажем, который не любит читать худ. литературу, но вот твоя статья зацепила, читал, как детектив… давай еще.
                                                                                                      0
                                                                                                      ну и писать не умею
                                                                                                      –1
                                                                                                      Бренд Panasonic напоминает китайцев, которые «для облегчения общения с русскими» называют себя Васями и Петями. В оригинале же Matsushita — имя само за себя говорит.
                                                                                                        0
                                                                                                        вообще-то, японцы это произносят как Мацусита, так что не надо грязи
                                                                                                        0
                                                                                                        хотя и не понимаю ничего в устройстве сетей, но, как уже было сказано выше, написано действительно очень увлекательно и интересно =)
                                                                                                          0
                                                                                                          Спасибо за статью! пришлась очень кстати, т.к. от клиента пришло письмо с проблемой с такими же симптомами )
                                                                                                            0
                                                                                                            Хочу статью со всеми тонкостями ) получилось как в хорошем практическом руководстве по TCP/IP!
                                                                                                              0
                                                                                                              В планах:
                                                                                                              — Статья о некоторых особенностях коммутаторов серии cisco2950
                                                                                                              — Статья о причинах unicast-flood'а в локальной сети

                                                                                                              Но я не собираюсь торопиться, всему свое время.
                                                                                                              +1
                                                                                                              Вот такие посты я приветствую на хабре, а не «у гугла в гмыле появилась новая фенечка»
                                                                                                                0
                                                                                                                Интересно и познавательно, спасибо! Тоже случаются иногда подобные эпические драмы =)
                                                                                                                  0
                                                                                                                  неплохо, ога. :) автор молодец, что докопался до причины, а не забил.

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

                                                                                                                  а была действительно сладкая возможность помусолить за каталисты на хабре (да неужели дожили на хабре говорить за каталисты?! О_о)

                                                                                                                  и да, МФУ хорошее устройство не назовут :) никогда не понимал в чем прелесть купить гавнецо три в одном вместо покупки трех _нормальных_ устройств, а в случае с принтером, вообще отдельный принтсервер…
                                                                                                                    0
                                                                                                                    А никто и не говорил, что эти каталисты роутят.
                                                                                                                    Нет ну роутят конечно, и даже каталисты, ну дык ведь шеститонники(cisco catalyst 650x), а никак не 29х0 и 35х0.
                                                                                                                    В данной статье маршрутизация во вне не имеет никакого значения, так как все события разворачиваются исключительно в пределах одного широковещательного домена.
                                                                                                                    А на счет хабра и каталистов — там вон про микроконтроллеры топики пошли, так что как знать, как знать…

                                                                                                                  Only users with full accounts can post comments. Log in, please.