Скрытый баг (фича ?) коммутатора ZyXEL ES-2108-G



Администрируя сеть Tier-3 провайдера, сталкиваешься с очень интересными особенностями некоторых вендоров.
Об одной из таких особенностей и пойдет речь в этой статье.


Предыстория


Изначально была следующая топология сети:



За ненадобностью было решено демонтировать Switch 1. Не дождавшись отчета монтажников, я, сидящий за PC 1, решил проверить доступность коммутатора. Как и следовало ожидать — он не пинговался. Не помню из каких соображений, решил сделать до него трейс.

Как ни странно — трассировка достигла конечного узла, но ответ пришел от IP-адреса, настроенного на ZyXEL'е.

Спустя некоторое количество времени ситуация нормализовалась, трейс не уходил дальше Router 1, но увиденное
не давало мне покоя.

Поиск причин


После очередного рабочего решил собрать аналогичную топологию в офисе и докопаться до истины.
Приложив минимальные усилия, собрал тестовую сеть:



Проверил доступность каждого из узлов — все пингуется. Далее запустил Wireshark на Test PC, отключил (физически)
Test Switch. Как и раньше — пинг до Test Switch не проходил, но traceroute на 10.230.160.20 упорно показывал конечным узлом 10.230.160.9.

Я получил то чего хотел — дамп трафика.

Как видно — пакеты уходят от Test PC в сторону Test Switch:


Дальше получаем ICMP-пакеты от Zyxel Type-3, Code-3:


После очистки FDB на Zyxel'е, я увидел долгожданный ARP:


Почему traceroute выводил конечным узлом Zyxel — мы разобрались, осталось понять причину странного поведения Zyxel'я.

Заключение


За ответом, мучающим меня, я направился в службу поддержки компании Zyxel. Беседа длилась неделю, я отправлял специалистам дампы, файлы конфигурации, они, в свою очередь, предлагали актуальные версии микропрограммы, которые, к сожалению, не исправляли данный баг.

В итоге переписки специалисты из Zyxel подтвердили наличии неисправности, но т.к. это не влияет на работоспособность сети в целом, да и сама модель снята с производства, изменений в прошивку внесено не будет.

Данный ответ меня вполне устроил, аналогичные коммутаторы из сети убрал, ТТ закрыл.

P.S. Не судите строго, буду рад ответить на все интересующие вас вопросы.

Спасибо за внимание!
Поделиться публикацией

Комментарии 17

    0
    Zyxel у Tier 3 провайдера? моветон, кмк
      0
      После подобных инцидентов стал недолюбливать коммутаторы уровня доступа от Zyxel.
        0
        моветон — это когда сеть не работает. А оборудование может быть любым, лишь бы SLA соответствовало. Например, любимый многими каталист 2950 значительно хуже по фичасету того же dlink des-3526.
          0
          ну вот вам же и объясняют, что их недолюбливают и убирают :) просто среди тех, кто уже наступал на эти грабли, давать в сеть провайдера с таким SLA оборудование ненадежных вендоров — моветон, вне зависимости от фичасета. Никому не нужны фичи, если надежность не на уровне.

          А когда сеть не работает — это уже не моветон, это просто глупость в Tier 3, за которую можно заплатить работой и репутацией :)
            0
            tier-1 и tier-3 сети с дата-центрами и их уровнями по tier путать не надо =)
              0
              ок, репутацией и работой не заплатите :) но временем сотрудников и лояльностью клиентов — запросто.
        0
        Увы, очень неприятно слышать от любого вендора такую отмазку, что, раз девайс не производится, то патчей делать никто не будет. Ладно циска и иже с ней, которые модельный ряд не меняют годами (я про акксес-левел), а некрупные, но очень себя любящие фирмы вроде длинка или зухеля — ой, они модели клепают, а с софтовой поддержкой бывает очень комично (для них) и грустно (для покупателя). Мало что иногда не найти даже спеца, как какую-то фичу запустить правильно, так еще и ответы вроде описанного в статье, увы, не редки.
          0
          у циски тоже — EoL объявлен? все, даже кейс в ТАСе не открыть, не то что объявление о том, что прошивки не будет…

          аксесс-левел в циске менялся за последние 10 лет очень сильно — 2950, 2960, 2960G, 2960-E, 2960-X
          3560, 3560v2, 3560G, 3560-E, 3560-X, 3650…

          +1
          а в чем прикол? Зюксель отвечает на ARP, что за IP адрес 160.20 отвечает он, хотя на деле это не так. я правильно понял?
            0
            Отвечает он на UDP-пакеты от traceroute с dst ip — 10.230.160.20, а они к нему никак не относятся.
              0
              ясно. спасибо.
            0
            предлагали актуальные версии микропрограммы

            А вот с этого места пожалуйста поподробней, насколько я помню и на сайте производителя нет прошивок свежее начала 2012 года, вы уверены что они актуальные? Сейчас к сожалению точно не вспомню, но находил неисправленные ошибки, благо было на что поменять, поэтому особенно не парился, но если есть свежые версии где возможно их исправили хотелось бы на них глянуть.
              0
              Возможно не так выразился, вендор не вносил каких-либо изменений, просто указал на последнюю прошивки, которая была выпущена как раз в 12 году.
              0
              Что-то из вашего описания картина проблемы никак не склеивается.

              Как-то непонятно каким образом пакеты с MAC DST test switch попадают на CPU zyxel.
              1. Ясно, что после того как вы отключили test switch, промежуточный считч удалил из своей таблицы коммутации MAC адрес test switch.
              2. Так как на хосте ARP запись еще сохранилась, то хост продолжает посылать пакеты обычные и будет это делать до тех пока запись ARM не заэкспайрится.
              3. L2 switch не знает за каким портом теперь MAC DST test switch и пересылает его как unknown unicast (в вашей схеме на порт zyxel).
              4. Zyxel получив пакет с MAC DST test switch также обрабатывает его как unknown unicast, но пересылать то его не куда. Пакет не предназначен самому коммутатору MAC DST != MAC CPU, т.е. на CPU пакет не отправится, других портов в UP нет, т.е. пакет должен дропнуться. Или баг в ПО как раз и связан с тем, что unknown unicast на порт CPU попадают и CPU их обрабатывает?

              Немного вопросов:
              1. Судя по дампу пользуете UDP пинг линуксовый. С обычным ICMP пингом такая ситуация проявляется?
              2. Можете показать дамп пакетов пинга и трасераута?
              3. Можете показать FDB до и после очистки? А заодно еще и ARP кэш на хосте и zyxel?
                0
                Я буду очень рад, если Вы поможете мне разобраться с проблемой до конца.
                Для полноты картины — прикладываю дамп.

                Или баг в ПО как раз и связан с тем, что unknown unicast на порт CPU попадают и CPU их обрабатывает?

                Насчет этого думал, но в саппорте Zyxel'я информацию не предоставили.

                По вопросам:
                1) Да, проблема проявлялась только при использовании traceroute, использующей UDP. С ICMP проблем не наблюдалось.
                2) Дамп трасераута выше, ICMP-пингов там нет (увы, что осталось).
                3) К сожалению больше нет в наличии подобных коммутаторов, так что эти данные предоставить не смогу. Разумеется все проверял, в FDB Zyxel не было ничего подозрительного, после исключения из сети Test Switch, запись о нем удалилась. Что касательно ARP-кеша, там также были записи о Test PC, L2-Switch и Test Switch, после отключения Test Switch, запись осталась. Но проблема решалась именно чисткой MAC-таблицы Zyxel.
                  0
                  Дамп ситуации не прояснил.
                  Жаль, что этого свича нет больше. Так бы с ним парочку экспериментов провести. Интересно разобраться, подумаю где бы его раздобыть.
                    0
                    Буду очень благодарен, если поделитесь результатами своих экспериментов.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое