[mac-addres 0090.e800.0081]

После проведенных исследований я склонен полагать что это баг прошивки 3.4, т.к. анализ трафика посредством Wireshark показал что это LLDP.

Те два ринга, за которыми этого адреса не видно, "смотрят" на root через 508-е коммутаторы с ver.3.1 (LLPD на них включен).

Отключив LLDP на 518-х, 3750 успешно про 0090e8000081 забыл.

Такие пироги.

[mac-addres 0090.e800.0081]

Вчера обнаружил в сети весьма странную вещь, которая теперь не дает мне покоя.

Имеется 7 рингов версии 1, построенных на 518-х и 508-х коммутаторах с 3.4 и 3.1 прошивками соответственно. Все ринги сходятся на пару Cisco 3750 (stackwise).

Вчера получил в syslog сообщение типа типа:

"... Host 0090e8000081 in vlan1 is flapping between port Gi2/0/6 and port Gi1/0/8..."

Вроде бы ничего удивительного, но такого адреса в сети нет, и ни один из Moxa не имеет его в Mac-address-table.

Далее, если повторять "sh mac address-table | incl 0081" на 3750, то циска постоянно видит его за разными интерфейсами, но почему то только в пяти рингах из семи.

Сам адрес судя по первому октету принадлежит Moxa.

Кто-нибудь в курсе что это за зверь?

[TurboRing резервирование. Несколько вопросов]

Добрый день, господа специалисты! Буду безмерно благодарен если Вы проясните ряд вопросов....

Intro. Есть некая индустриальная сеть. Частично RSTP(запланирован переход в кольца), частично TurboRing-и на 518A. Два ринга "изолированных", два с Ring Coupling (схема во вложении.). Все сходятся в Cisco 3750. Все станции, находящиеся в одном шкафу, подключены к паре коммутаторов находящихся там же, на станциях настроен NIC Teaming.

Т.к. оборудование крутится в режиме 24х7, нормально протестировать сеть возможным не предоставлялось до недавнего времени, когда случился небольшой вынужденный простой. Появились вопросы....

1. Резервирование.

Подключались лэптопами к коммутаторам R1_3 и R1_6. Проверяли пингом связь с "синими" станциями, поочередно разрывая первый и второй каналы на каждой из них. Все ОК. Резервирование работает.

Разрывали гигабитные интерфейсы - нихт проблем. Пинги не теряются.

Еще раньше (когда железо крутилось), обратили внимание, что статус 14-го порта на R1_2, настроенного как "Redundant Port Status 1st Port", не "Forwarding", а "Learning" (состояние int.14 на R1_1 "Blocked") - решили перезагрузить. Сначала ч/з web-интерфейс - статус порта "Learning" не изменился, затем отключением питания - тот же "Learning". Т.к. время позволяло, взяли со склада новую Moxa, залили конфиг R1_2 и заменили, состояние 14-го порта не изменилось. Но зато обнаружилась весьма неприятная вещь, в то время, когда R1_2 была выключена (перетыкали шнурки из старой R1_2 в новую R1_2) - "синие" станции потеряли связь с "красными". После включения связь восстановилась. Сняли питание с R1_1 - "синие" не видят "красных". Т.е. получается, что весь наш производственный процесс зависит от надежности Moxa, и случись что с любой из них - мы теряем управление им. Как так?

Про "Learning" тоже интересно узнать, раньше я его не встречал. Да, если перевести мастера с R1_6 на R1_5, то "Learning" соответственно перебирается на 14-й порт R1_1.

2. Ring Coupling

Сняв питание с R2_3 наблюдали потерю связи с "зелеными" станциями со стороны "синих". Т.е. получается, что если выходит из строя коммутатор с включенным Coupler-ом, то мы теряем все внешние связи с рингом R1. Для себя и так и не осознал преимущества этой технологии в данном конкретном случае. Почему не подключили R1_1 и R1_2 сразу на 3750, а использовали Coupling? Потому что дешевле? Я конечно выясню это у наших финских друзей, но сейчас они все поголовно в отпуске. Возможно я что-то не догоняю более глобального... Но, за последний год, не было ни одного случая чтобы останавливалось оборудование в обоих рингах сразу, в том время как несколько раз имели место плановые остановы в R1 и R2, и если бы кольца были "изолированы", то можно было бы исследовать более предметно тот или иной сегмент, а в данном случае вносить какие-либо изменения в конфигурации, в то время как часть оборудования работает, я, признаться, побаиваюсь.

 

Все 518A с прошивкой v2.3.2. У нее еще забавный глюк, если исследовать сеть посредством Fluke Network Analyzer, то все 518-е отдают маску сети вида 0.240.255.255, вызывая тем самым разрыв шаблона у Fluke.) Мы используем в одном из RSTP сегментов также пару 518-х, я на них накатывал firmware v.3 и Fluke принял правильную 255.225.240.0. Но ч/з пару месяцев прикатил очередной финишгай и откатил их обратно на 2.3.2, аргументировав тем, что v.3 не тестировалась их корпарацией.

Такие пироги.