Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
Zyxel у Tier 3 провайдера? моветон, кмк
После подобных инцидентов стал недолюбливать коммутаторы уровня доступа от Zyxel.
моветон — это когда сеть не работает. А оборудование может быть любым, лишь бы SLA соответствовало. Например, любимый многими каталист 2950 значительно хуже по фичасету того же dlink des-3526.
ну вот вам же и объясняют, что их недолюбливают и убирают :) просто среди тех, кто уже наступал на эти грабли, давать в сеть провайдера с таким SLA оборудование ненадежных вендоров — моветон, вне зависимости от фичасета. Никому не нужны фичи, если надежность не на уровне.
А когда сеть не работает — это уже не моветон, это просто глупость в Tier 3, за которую можно заплатить работой и репутацией :)
А когда сеть не работает — это уже не моветон, это просто глупость в Tier 3, за которую можно заплатить работой и репутацией :)
Увы, очень неприятно слышать от любого вендора такую отмазку, что, раз девайс не производится, то патчей делать никто не будет. Ладно циска и иже с ней, которые модельный ряд не меняют годами (я про акксес-левел), а некрупные, но очень себя любящие фирмы вроде длинка или зухеля — ой, они модели клепают, а с софтовой поддержкой бывает очень комично (для них) и грустно (для покупателя). Мало что иногда не найти даже спеца, как какую-то фичу запустить правильно, так еще и ответы вроде описанного в статье, увы, не редки.
а в чем прикол? Зюксель отвечает на ARP, что за IP адрес 160.20 отвечает он, хотя на деле это не так. я правильно понял?
предлагали актуальные версии микропрограммы
А вот с этого места пожалуйста поподробней, насколько я помню и на сайте производителя нет прошивок свежее начала 2012 года, вы уверены что они актуальные? Сейчас к сожалению точно не вспомню, но находил неисправленные ошибки, благо было на что поменять, поэтому особенно не парился, но если есть свежые версии где возможно их исправили хотелось бы на них глянуть.
Что-то из вашего описания картина проблемы никак не склеивается.
Как-то непонятно каким образом пакеты с 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?
Как-то непонятно каким образом пакеты с 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?
Я буду очень рад, если Вы поможете мне разобраться с проблемой до конца.
Для полноты картины — прикладываю дамп.
Насчет этого думал, но в саппорте Zyxel'я информацию не предоставили.
По вопросам:
1) Да, проблема проявлялась только при использовании traceroute, использующей UDP. С ICMP проблем не наблюдалось.
2) Дамп трасераута выше, ICMP-пингов там нет (увы, что осталось).
3) К сожалению больше нет в наличии подобных коммутаторов, так что эти данные предоставить не смогу. Разумеется все проверял, в FDB Zyxel не было ничего подозрительного, после исключения из сети Test Switch, запись о нем удалилась. Что касательно ARP-кеша, там также были записи о Test PC, L2-Switch и Test Switch, после отключения Test Switch, запись осталась. Но проблема решалась именно чисткой MAC-таблицы Zyxel.
Для полноты картины — прикладываю дамп.
Или баг в ПО как раз и связан с тем, что 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.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Скрытый баг (фича ?) коммутатора ZyXEL ES-2108-G