stesv

Приветствую. 1. Большое спасибо за прошивку. ? Это что-то новое, относительно выложенного на сайте ? 2. Если да (сейчас у нас используется самая новая с сайта), то перезаливаться будем позже, сейчас оборудование в работе. Или испытаем ее на другом объекте (отпишусь по результатам); 3. С помощью снифера более-менее разобрались в "чудесах" нашего ПТК и пр. моментах. На дампах видно как сбрасывается таблицы коммутации ПОСЛЕ не адекватного поведения контроллера ПТК, но вот ПОЧЕМУ это происходит (каким механизмом инициируется) так и не понял. Буду надеяться, что после перезаливки картинна изменится; 4. Как Вы ранее и предлагали единственное эффективное средство борьбы с широковещательным штормом для нашего "чудесного" ПТК оказалась полная блокировка "шумящего" порта на значительное время. Хотя другой трафик может ходит совершенно нормально и при более "мягких" ограничениях; 5.В случае повторения наших неприятностей (чего бы не хотелось), позволю себе Вас еще потревожить. В принципе могу поделится материалами наших изысканий. Спасибо за участие в "расследовании", если был излишне эмоционален в общении - прошу прощения ....

Приветствую. 1. Большое спасибо за прошивку. ? Это что-то новое, относительно выложенного на сайте ? 2. Если да (сейчас у нас используется самая новая с сайта), то перезаливаться будем позже, сейчас оборудование в работе. Или испытаем ее на другом объекте (отпишусь по результатам); 3. С помощью снифера более-менее разобрались в "чудесах" нашего ПТК и пр. моментах. На дампах видно как сбрасывается таблицы коммутации ПОСЛЕ не адекватного поведения контроллера ПТК, но вот ПОЧЕМУ это происходит (каким механизмом инициируется) так и не понял. Буду надеяться, что после перезаливки картинна изменится; 4. Как Вы ранее и предлагали единственное эффективное средство борьбы с широковещательным штормом для нашего "чудесного" ПТК оказалась полная блокировка "шумящего" порта на значительное время. Хотя другой трафик может ходит совершенно нормально и при более "мягких" ограничениях; 5.В случае повторения наших неприятностей (чего бы не хотелось), позволю себе Вас еще потревожить. В принципе могу поделится материалами наших изысканий. Спасибо за участие в "расследовании", если был излишне эмоционален в общении - прошу прощения ....

Приветствую. 1. Вчера (подвернулся останов основного оборудования) начали менять топологию в направлении большей локализации отдельных функциональных блоков (делаем три кольца T.Ring вместо двух), посему вероятно актуальными будут другие конфиги (и возможно проблемы); 2. Буквально сейчас начнем "химичить" с "RateLimiting", Prioroty/CoS и пр., после чего проведем испытания на устойчивость конструкции к петлям и пр.; 3. Старые конфиги (новые тоже не секретные) и серийники пришлю попозже ; 4. Как работает сетевая подсистема ПТК точно никто не знает - в этом вся и проблема (производитель ПТК им больше не занимается, его программисты уволились и т.д.). Причем "глюки" возникают "неожиданно", посему трудно их очно "поймать за хвост". Зарядим сегодня "сетевую прослушку" на инженерных АРМ в колцевой буфер/файлы, попробуем потом (если возникнет "неприятность") проанализировать дамп;

Приветствую. Не смотря на то, что пока ответа на предыдущие вопросы не получил, рискну выдвинуть свою версию развития обсуждаемых неприятных событий (хотелось бы получить оценку ее адекватности): В контроллерах "глючного" ПТК что-то происходит с сетевым софтом; В результате начинает флапать один из его сетевых интерфейсов; Дале, при дальнейшем развитити «неприятностей», мас-адрес флапающего интерфеса как-то просачивается и на второй интерфейс контроллера; В результате ДВА коммутатора видят один и тот же мас-адрес на разных портах; Тот коммутатор, к которому подключен флапающий интерфейс к этому относится «спокойно», т.к. в момент прилета мас-адреса на другой порт исходный находится в дауне; А вот коммутатор, к которому подключен «исправный» интерфейс, приходит в «недоумение», т.к. один и тот же мас-адрес у него с «большой частотой» светится на разных интерфейсах; Этот коммутатор решает, что «в Багдаде НЕ все спокойно» и сбрасывает свою таблицу коммутации; Именно факт сброса таблицы индицируется сислог-собщением «смена топологии» (именно так поддержка мне расшифровала указанное сообщение); После сброса таблицы коммутации коммутатор превращается в хаб, т.е. начинает размножать все пакеты на все свои порты, чем усугубляет ненормальность ситуации; Далее контроллер ПТК (если его вовремя не перезагрузить) петлюет свои сетевые интерфейсы, чем инициирует широковещательный шторм; Далее в отсутствие RSTP …..

Еще вопрос: Если попытаться включить ограничение широковещательных пакетов на портах коммутатора 6425 (они все 1G), то на веб-форме ОДНОВРЕМЕННО указаны % и физические значения. Например "85% (85Mbps)". Однако 85% от скорости 1G - это НЕ 85Mbps. ? Чему верить - % или физическим значениям ?

Приветствую и продолжаю: 1. В доказательство, что событие не случайное привожу очередной лог (который сегодня не дал выспаться); 2. Отвечаю на уточняющие вопросы: а. Да, SW6 для своего кольца мастер, а для "внешней" стыковки он резервный коплер. ? Что-ли так НЕ рекомендуется делать ? Если да, то как делать более правильнее ? б. Прошивки во все коммутаторы залиты самые свежие, которые у Вас есть на сайте; в. Сброс таблицы коммутации вероятно - это на самая большая "трагедия", беспокоит НЕПОНИМАНИЕ ситуации; г. По поводу как ПРАВИЛЬНО лечить "широковещательную" болезнь: - Самый правильный подход - это замена "глючного" ПТК, однако мы понимаем, что это проблематично; - Переход на L-3 - это правильно, только для этого необходимо "перелопатить" проект автоматизации, что также сделать сложно. Я уж не говорю о том, что некоторые "поделки" принципиально могут работать только в "плоской" сети (в свое время на другом железе и в другом проекте приходилось для этого даже поднимать L2TP). Также если будет время поделюсь обнаруженными "странностями" работы L-3 на коммутаторах моха; - А еще правильно - это иметь подлинно ДУБЛИРОВАННУЮ/ДВОЙНУЮ сеть, когда одна ложится - и нас...ть, вторая параллельно и ВСЕГДА работает. Зафиксированы следующие события+.txt

Приветствую, 1. Коплеры назначены на sw5 и sw6; 2. Если уж совсем быть честным, то у схемы есть следующее продолжение (оно не убралось на картинку): - SC1, SC2 входят в другое кольцо, видны его коричневые линки; - Есть еще и ТРЕТЬЕ кольцо (условно "синее", его не видно), которое также "прикоплено" к коричневому (со стороны синего); 3. Самое непонятное, что наблюдается - это "перестройка топологии" (по сообщениям в сислог) при проблемах на клиентских порта; 4. Сеть "раздроблен" на кольца с целью попытаться локализовать возможные "неприятности" внутри одного кольца. Про проблемный ПТК писал ранее ....

Приветствую: 2. а. Да, имеется фиолетовое кольцо, состоящее их 4х коммутаторов, которое каплингом (зеленые линки) прицеплено к другому кольцу (на картинке обрезано, т.к. большой файл не вкладывается); б. Мастером в фиолетовым кольце назначен SW6 (6728), как обозначено на схеме, секондари порт указан пунктиром; в. Кольцевые-фиолетовые порты на SW6 - это 28 (4-4) и 18 (3-2), каплинг порт - это 27 (4-3); г. К портам 14(2-6), 16 (2-8) и другим (на картинке не показано) подключены КЛИЕНТЫ ("проблемный" ПТК), которые периодически отваливается и переподключается (а также возможно что-то еще делают - к примеру петлюют через себя интерфейсы), о чем в логах и пишутся сообщения (смотри про порт 2-6); д. НЕПРИЯТНОСТЬ же - это сообщения о перестройке топологии. Т.е. вызывает озабоченность/непонимание влияние клиентских портов на магистральную "потенцию" коммутаторов (работу T.Ring); е. Разночтение в нумерации обусловлено тем, что моха при конфигурации обозначает порты в одном стиле (например 4-4), а через snmp отдает их нумерацию по другому (например 28).

В очередной раз приветствую: 1. Не совсем понял как результат (ОДНОВРЕМЕННАЯ блокировка трафика по обоим портам с РАЗНЫМИ уставками) соответствует описанной логике; 2. В реальной схеме наблюдается (по сообщениям сислог) влияние клиентских портов на топологию T.Ring (сообщается о смене топологии). Хотелось бы получить комментарии по данному явлению, подтверждающие материалы во вложении, заранее спасибо .... Зафиксированы следующие события--.doc

1. Понятно. 2. Если при меж коммутаторном замыкании портов гаснут ОБА порта (тем более ОДНОВРЕМЕННО), и при этом на них прописаны РАЗНЫЕ уставки, то это по моему не соответствует логике работы, которая была Вами озвучена выше. Т.е. исходя из описанной логики, при сработывании первой уставки "топологически" прекращается "бег по кругу" широковещательных пакетов, значит шторм должен затихнуть и до второй уставки дело НЕ должно доходить. Если Ваш эксперимент дают ДРУГОЙ результат, то вероятно логика работы отличается от описанной ранее. Очень бы хотелось ее совершенно ТОЧНО определить ....

С небольшой задержкой (вызванной отпуском) снова позволю себе позадавать "глупые" вопросы (будет очень мало времени на настройку/испытания/эксперементы, посему по 100 раз все переспрашиваю): 1. Скачал самый новый мануал (июль 2017 г.) на Мохи в котором обнаружилось: а. Для коммутаторов "Type 3" (именно такие меня интересуют - 6728) НЕЛЬЗЯ выбрать политику "Rate Limiting", т.е. вероятно существует она ОДНА единственная. Соответственно вопрос ? Ограничивается ли этой единственной политикой "мультикаст" трафик (например работа протокола RSTP, действие политики для данного типа коммутаторов в мануале не расшифровывается)? При этом для коммутаторов "Type 4" (у меня такой 6524) снова показана возможность выбора политики. б. Оказывается для коммутаторов "Type 1" (510) ограничения трафика политикой "Rate Limiting" можно задать ОТДЕЛЬНО для каждой очереди (картинка на стр.72). ? Это так ? Если да, то почему производитель от этого отказался на "толстых" моделях коммутаторов ? в. ? Все значения "Rate Limiting" измеряются/вычисляются коммутатором на интервале 1 секунда или каком либо другом интервале усреднения ? Т.к. вероятно "мгновенные" (в момент прохождения пакета) значения скоростей всегда равны физической скорости на интерфейсе; г. ? Ограничения скорости/отбрасывание пакетов совершенно точно НЕ влияют на "служебную информацию протоколов T.Ring/T/Chain ? Т.е. "Rate Limiting" совершенно точно НЕ перестраивает их топологию ? 2. По поводу одновременного запирания двух интерфейсов: Надо просто уставки сделать РАЗНЫЕ для разных интерфейсов. В этом случае один из них будет запираться первым и тем самым гасить петлю. Ежели после этого дело дойдет и до второй (большей) уставки, тогда точно в сети "ж...а" и полностью отключится от нею будет по моему даже "полезно";

И на "закуску" совсем "обнаглею": ? А не могли бы Вы провести "экспертизу" мероприятий, которые мы в итоге (и по результатам нашего общения) наработали в части исправления средствами мохи "кривизны" нашего ПТК ? Могу вложить документ, тем более, что ранее в общении Вы несколько раз изъявляли желание увидеть схемы ......

3. Такая идея первой пришла в голову и рассматривается как один из вариантов, однако: -Было бы очень хорошо, если бы моха ФИЗИЧЕСКИ отключала интерфейсы. При этом хост определял бы Down порта, констатировал отказ сети и переключался бы на резерв (вплоть до перехода на другой контроллер); - При логическом же отключении порта, хост считает, что у него с сетью все нормально и он продолжает работать как работал через тот-же интерфейс, т.е. пулять пакеты в отключенный порт и физически через себя "замыкать" петлю (временно разорванную); - Т.е. предложенным способом теоретически можно временно притушить шторм (и это уже не плохо), а вот "полечить" контроллер/хост не получается

Снова буду "доставать" своей непонятливость (она вынужденная, т.к. провести испытания предварительных настроек нет возможности, а время на возможную трансформацию продуктива будет очень мало): 1. а. ? Т.е., чтобы работали политики и значения ограничения скорости, заданные в "Rate Limiting", надо отключить "шторм-контрол" ? Иначе вероятно "высокие" пороги "шторма" никогда не будут достигнуты, т.к. порог в 10% "шторм-контроля" будет первым достигаться, соответственно дальнейший трафик будет блочится и до больших порогов дело не дойдет. б.То, что у мохи очереди "разгружаются" по выходу, а трафик блочится на входе - это понятно. Вопрос как раз в том, чтобы блочился трафик более "интеллигентно", а не "оптом" (например дифференцировано по VLANaм, как можно сделать у той же циски). Иначе до очередей пакеты просто НЕ добираются . в. Услышал, что пакеты ТR и ТС блочится не должны, т.к. они мультикаст (кстати, в политиках "Rate Limiting" по моему можно задать блокировку мультикаста), а как быть в отношении пакетов "Coupling" (вероятно и такие есть) ? Они тоже гарантированно не блочатся "ограничителями скорости"? 2. Я описал то, что видел своими глазами, а сообщения же о смене топологии записаны в лог-файлах. Глубоко копать ЧТО и ПОЧЕМУ происходило времени не было - надо было максимально быстро оживлять систему (что и произошло при разрыве предположительно кольцевой топологии). Повторить эксперимент на работающем оборудовании тоже нет желания, вот сейчас "постфактум" и пытаюсь понять ИСТИННЫЕ причины наблюдаемого и выработать мероприятия по снижению вероятности повторения "неприятностей"; 3. По поводу "какие претензии": - Как писал ранее в общем моха понравилась, только вот оказалось, что она нормально работает с НОРМАЛЬНЫМИ хостами (там горя не знаю с мохой); - Если же "посчастливилось" заиметь "кривые" хосты (например склонные к образованию петель через свои интерфейсы), да еще с "плоской" и НЕ дублированной сетью то возможностей мохи для "исправления ситуации" не хватает; - Получается, что надо или переходить полностью на RSTP (при этом НЕ устраивает скорость отработки отказов - за время сходимости RSTP оборудование успевает остановится) или "шаманить" с CoS и "Rate Limiting" (? может еще какие есть возможности ?), чтобы снизить риски "неприятностей" (и криков начальников); - Возможно, что имеются завышенные ожидания в наличии у мохи некоторых "фич", однако они порождены опытом работы с другим железом; - Понимаю, что ПРАВИЛЬНОЕ решение - это изначально купить нормальный и не "глючный" (а значит и дорогой) ПТК, только у покупателя системы видно были другие мысли на этот счет и теперь приходится жить с тем, что имеется в наличии .....

Еще несколько "идиотских" вопросов: 1. Как я понял из вышесказанного, "шторм контрол" и "Rate Limiting" по крупному делают примерно одно и тоже - ограничивают широковещательный трафик. Соответственно вопрос: ? Если включены ОБЕ опции, то кто из них "главнее", т.е. чьи параметры будут применены в итоге на портах коммутатора ? 2. Неприятная ситуация с предположительно "перевыборами" при шторме наблюдалась при использовании TR2 и проявлялась она в: - "мигание" (достаточно "частое") индикации "мастер" на коммутаторе, который директивно был им назначен; - мастер сыпет в сислог сообщения "смена топологии"; - "прмаргивание" (достаточно "редкое") индикации "мастер" на коммутаторе, на котором предположительно образовалась петля; - "прикладной" обмен практически "умер"; - "управляющий" трафик (реализован в отдельной от прикладного обмена Vl1) ну ОЧЕНЬ затруднен (чтобы опустить "петлевой" порт и тем самым "топологически" погасить шторм пришлось долго "пробиваться" на коммутатор); Есть подозрение (возможно неверное), что при шторме неприятности обусловлены не напрямую большим широковещательным трафиком, а тем, что он не "обрабытывется" системой очередей (т.е. "возбуд" любого даже НЕ важного трафика, "прибивает" полезные широковещательные пакеты во ВСЕХ других очередях/VLAN) и перегрузкой CPU коммутатора. Отсюда очень любопытно посмотреть методику испытаний тех самых колец из 250 коммутаторов, загруженных на 100%; 3. Также бы хотелось получить информацию о якобы известной поддержке "ситуацию, когда broadcast-шторм "положит" TR" ? Или позиция производителя - это утаивание "неприятной" информации (как например немаршрутизируемость управляющей VLAN) ? Заранее спасибо и извиняюсь, за возможное "занудство" ....

Еще несколько уточнений: 0. Ранее, сейчас и позже (до особого уточнения) речь идет о L-2 QoS (с ним бы хоть разобраться) , т.е. в категориях мануала речь идет о битах CoS; 1. Исходя из ответа 1 получается, что "при любом раскладе" моха САМА может отмаркироваить биты только как CoS=1. Сунул свой любопытный нос в мануал по командной строке, нашел там описание "интерфейсной" команды "cos default-cos", которая как я понял (из описания) именно и настраивает ПРОИЗВОЛЬНУЮ маркировку CoS пакетов, поступивших на акцесные порты. ? Я неправильно понял мануал и все таки CoS всегда = 1 для акцесных портов ? 2. Исходя из ответа "2" как бы получается, что например широковещательный шторм НЕ может нарушить работу Т.ринг. Мне показалось, что на практике это не так и при широковещательном шторме происходят постоянные перевыборы мастера в кольце (по крайней мере по внешней индикации). ? Мне описанное именно ПОКАЗАЛОСЬ и Вы гарантируете (а еще лучше сами проверили) АБСОЛЮТНУЮ приоритетность управляющих пакетов над всеми остальными ? 3. ? Т.е. CoS=2 присваивается ВСЕМ "управляющим" пакетам (snmp, telnet и пр. на управляющих интерфейсах)? 4. ? Т.е получается, что для широковещательных пакетов при ограничении скорости система очередей фактически НЕ работает ? Т.е. отбрасывается первый же пакет, который превысил "уставку" ВНЕ зависимости от того, к какой очереди он принадлежит (например ГЛАВНОЙ/"пустой", при этом во "второстепенных" очередях широковещательные пакеты совершенно спокойно "ждут своего часа" на выход ?)? 5. ? Вероятно следует понимать "превысили порог - начинаем отбрасывать ВСЕ пакеты, соответствующие политике и ждем СЛЕДУЮЩУЮ секунду, в течении которой трафик снова начинает подсчитываться и при превышении порога начинает снова отбрасываться" ?. Т.е. как бы получается "дыхание" с частотой 1 сек. Update Про СОБСМТВЕННЫЙ трафик понятно, хотя CoS=2 для него лично мне представляется "странным" (возможно вследствие нарушения "чувства прекрасного" по причине плотной работы с ДРУГИМ оборудованием). Быть бы ТВЕРДО уверенным в обозначенном - вот в чем "заковыка" (любой приоритет можно в принципе наложить с помощью настройки "карты" приоритетов).... Хотелось бы разобраться с маркировкой ЧУЖОГО акцесного трафика - смотри выше п.1

Продолжу: 1. Исходя из ответа "2а" получается, что биты QoS НЕ ПЕРЕмаркировываются НИКОГДА (т.е. установленные "кем-то" QoS НИКОГДА не изменяются). Однако был еще вопрос КАК Моха сама МАРКИРУЕТ изначально "QoS-пустые" пакеты ? Т.е. приходит пакет на АКЦЕСНЫЙ порт, а уходит через ТРАНКОВЫЙ в НЕнативном VLAN. ? Какой у него будет QoS (написано, что по умолчанию он будет "0", кстати это НЕ очередь "нормал" - это так ?) и можно ли это изменить ? Если да, то как ?; 2 Из ответа 2б можно предположить, что пакеты управления сетью (в том числе возможно и пакеты, обеспечивающие работоспособность протоколов T.Ring, T.Chain, Coupling и пр) ВСЕГДА попадают в очередь "нормал". ? Это так ? Т.е. чтобы эти пакеты гарантированно НЕ "забивались" (и например НЕ "ломались" указанные выше протоколы ) весь остальной (прикладной) трафик должен быть помещен в ДРУГУЮ ("меньшую" в режиме "стрикт") очередь? Или пакеты перечисленных выше протоколов всегда идут "вперед паровоза" (не заметил этого у себя) ? 3. Возьмем к примеру протокол OSPF, как ранее было отвечено его пакеты исходно попадут в очередь "нормал", однако если управляющая VLAN на "исходящем" порту будет в НЕнативная, то по умолчанию этому пакету присвоится QoS = "0", а значит на входящем порту соседа этот пакет окажется в очереди "Low". ? Это так ? 4.Про отбрасывание пакетов (ответ 3): ? Как отбрасывание пакетов соотносится с ОЧЕРЯДИМИ ? Т.е. порог установлен "оптом" для ВСЕХ очередей или индивидуально для каждой ? При превышении порога каков порядок выбора очередей для отбрасывания пакетов ? Или очереди для отбрасываемых пакетов отбираются "случайно" ? 5. Также интересно на каком интервале времени коммутатор вычисляет загрузку, т.е. в течении какого времени надо намерить например более 10% широковещательного трафика, чтобы потом начать его блокировать.

Зарекался не продолжать, однако вынужден это сделать 1. Сначала отвечу на заданные ранее вопросы: а. Информация о "конкурентах" - ОДНОВРЕМЕННУЮ поддержку разных протоколов "отказоустойчивости" на разных портах коммутаторов поддерживают: - Коммутаторы Хиршман (ГиперРинг + RSTP); - "Промышленные" коммутаторы Циско (MRP + RSTP). б. По поводу НЕ предоставления схем - не совсем пониманию чем может помочь картинка из нарисованном на ней кольце из коммутаторов, тем более что обсуждаются КОНЦЕПТУАЛЬНЫЕ вопросы, ответы на которые могут быть наложены на ЛЮБУЮ конкретную топологию; в. По поводу "УТЕШЕНИЯ" - поверьте, для этого есть более интересные способы, чем "бодаться" с неприветливой техподдержкой. 2. Новые вопросы, теперь по QoS (при его активации): а. В мануле написано, что коммутаторы маркируют у НЕмаркированных входных пакетов биты CoS (которые на L-2) "ПО УМОЛЧАНИЮ (обычно это 0)", соответственно хотелось бы ТОЧНО знать как конфигурируется маркировка по своему усмотрению; б. Хотелось бы знать как маркируются "внутренние" пакеты коммутатора, которые не привязаны к конкретному порту источнику - например пакеты из управляющей VLAN (1). Также интересно можно ли маркировку привязать именно к VLAN (конкуренты это делают), а не к физическому порту коммутатора; в. В мануле написано, что коммутаторы МОГУТ (т.е. это НЕ обязательно) ПЕРЕмаркировывать биты CoS, соответственно хотелось бы ТОЧНО знать КАК конфигурируется эта "свобода выбора" (когда надо перемаркировывать, а когда не надо; как эту свободу реализовать для входного пакета на порту, и как для выходного); 2. Новые вопросы, теперь по ограничению скорости трафика (Rate Limiting): а. В мануле написано, что при определенных настройках (Тип1/Port Disable) и объеме трафика порт может "ВЫКЛЮЧЕН". ? Что значит "ВЫКЛЮЧЕН" ? Он физически переводится в Down (т.е. "сосед" определит, что порт выключен) или просто по нему НЕ передается трафик, а физичеки порт в Up ? б. Аналогичный вопрос для (Тип2/Disable Port ); в.Аналогичный вопрос для (Тип3/Disable Port ); 3. И "на закуску" объясните пожалуйста КАК работает опция "Шторм-контрол". Лично у себя эфекта от ее включения я особого не заметил... Заранее спасибо .... Зарекался не продолжать, однако вынужден это сделать 1. Сначала отвечу на заданные ранее вопросы: а. Информация о "конкурентах" - ОДНОВРЕМЕННУЮ поддержку разных протоколов "отказоустойчивости" на разных портах коммутаторов поддерживают: - Коммутаторы Хиршман (ГиперРинг + RSTP); - "Промышленные" коммутаторы Циско (MRP + RSTP). б. По поводу НЕ предоставления схем - не совсем пониманию чем может помочь картинка из нарисованном на ней кольце из коммутаторов, тем более что обсуждаются КОНЦЕПТУАЛЬНЫЕ вопросы, ответы на которые могут быть наложены на ЛЮБУЮ конкретную топологию; в. По поводу "УТЕШЕНИЯ" - поверьте, для этого есть более интересные способы, чем "бодаться" с неприветливой техподдержкой. 2. Новые вопросы, теперь по QoS (при его активации): а. В мануле написано, что коммутаторы маркируют у НЕмаркированных входных пакетов биты CoS (которые на L-2) "ПО УМОЛЧАНИЮ (обычно это 0)", соответственно хотелось бы ТОЧНО знать как конфигурируется маркировка по своему усмотрению; б. Хотелось бы знать как маркируются "внутренние" пакеты коммутатора, которые не привязаны к конкретному порту источнику - например пакеты из управляющей VLAN (1). Также интересно можно ли маркировку привязать именно к VLAN (конкуренты это делают), а не к физическому порту коммутатора; в. В мануле написано, что коммутаторы МОГУТ (т.е. это НЕ обязательно) ПЕРЕмаркировывать биты CoS, соответственно хотелось бы ТОЧНО знать КАК конфигурируется эта "свобода выбора" (когда надо перемаркировывать, а когда не надо; как эту свободу реализовать для входного пакета на порту, и как для выходного); 2. Новые вопросы, теперь по ограничению скорости трафика (Rate Limiting): а. В мануле написано, что при определенных настройках (Тип1/Port Disable) и объеме трафика порт может "ВЫКЛЮЧЕН". ? Что значит "ВЫКЛЮЧЕН" ? Он физически переводится в Down (т.е. "сосед" определит, что порт выключен) или просто по нему НЕ передается трафик, а физичеки порт в Up ? б. Аналогичный вопрос для (Тип2/Disable Port ); в.Аналогичный вопрос для (Тип3/Disable Port ); 3. И "на закуску" объясните пожалуйста КАК работает опция "Шторм-контрол". Лично у себя эфекта от ее включения я особого не заметил... Заранее спасибо .... Зарекался не продолжать, однако вынужден это сделать 1. Сначала отвечу на заданные ранее вопросы: а. Информация о "конкурентах" - ОДНОВРЕМЕННУЮ поддержку разных протоколов "отказоустойчивости" на разных портах коммутаторов поддерживают: - Коммутаторы Хиршман (ГиперРинг + RSTP); - "Промышленные" коммутаторы Циско (MRP + RSTP). б. По поводу НЕ предоставления схем - не совсем пониманию чем может помочь картинка из нарисованном на ней кольце из коммутаторов, тем более что обсуждаются КОНЦЕПТУАЛЬНЫЕ вопросы, ответы на которые могут быть наложены на ЛЮБУЮ конкретную топологию; в. По поводу "УТЕШЕНИЯ" - поверьте, для этого есть более интересные способы, чем "бодаться" с неприветливой техподдержкой. 2. Новые вопросы, теперь по QoS (при его активации): а. В мануле написано, что коммутаторы маркируют у НЕмаркированных входных пакетов биты CoS (которые на L-2) "ПО УМОЛЧАНИЮ (обычно это 0)", соответственно хотелось бы ТОЧНО знать как конфигурируется маркировка по своему усмотрению; б. Хотелось бы знать как маркируются "внутренние" пакеты коммутатора, которые не привязаны к конкретному порту источнику - например пакеты из управляющей VLAN (1). Также интересно можно ли маркировку привязать именно к VLAN (конкуренты это делают), а не к физическому порту коммутатора; в. В мануле написано, что коммутаторы МОГУТ (т.е. это НЕ обязательно) ПЕРЕмаркировывать биты CoS, соответственно хотелось бы ТОЧНО знать КАК конфигурируется эта "свобода выбора" (когда надо перемаркировывать, а когда не надо; как эту свободу реализовать для входного пакета на порту, и как для выходного); 2. Новые вопросы, теперь по ограничению скорости трафика (Rate Limiting): а. В мануле написано, что при определенных настройках (Тип1/Port Disable) и объеме трафика порт может "ВЫКЛЮЧЕН". ? Что значит "ВЫКЛЮЧЕН" ? Он физически переводится в Down (т.е. "сосед" определит, что порт выключен) или просто по нему НЕ передается трафик, а физичеки порт в Up ? б. Аналогичный вопрос для (Тип2/Disable Port ); в.Аналогичный вопрос для (Тип3/Disable Port ); 3. И "на закуску" объясните пожалуйста КАК работает опция "Шторм-контрол". Лично у себя эфекта от ее включения я особого не заметил... Заранее спасибо .... Мануал Моха на русском.pdf

Зарекался не продолжать, однако вынужден это сделать 1. Сначала отвечу на заданные ранее вопросы: а. Информация о "конкурентах" - ОДНОВРЕМЕННУЮ поддержку разных протоколов "отказоустойчивости" на разных портах коммутаторов поддерживают: - Коммутаторы Хиршман (ГиперРинг + RSTP); - "Промышленные" коммутаторы Циско (MRP + RSTP). б. По поводу НЕ предоставления схем - не совсем пониманию чем может помочь картинка из нарисованном на ней кольце из коммутаторов, тем более что обсуждаются КОНЦЕПТУАЛЬНЫЕ вопросы, ответы на которые могут быть наложены на ЛЮБУЮ конкретную топологию; в. По поводу "УТЕШЕНИЯ" - поверьте, для этого есть более интересные способы, чем "бодаться" с неприветливой техподдержкой. 2. Новые вопросы, теперь по QoS (при его активации): а. В мануле написано, что коммутаторы маркируют у НЕмаркированных входных пакетов биты CoS (которые на L-2) "ПО УМОЛЧАНИЮ (обычно это 0)", соответственно хотелось бы ТОЧНО знать как конфигурируется маркировка по своему усмотрению; б. Хотелось бы знать как маркируются "внутренние" пакеты коммутатора, которые не привязаны к конкретному порту источнику - например пакеты из управляющей VLAN (1). Также интересно можно ли маркировку привязать именно к VLAN (конкуренты это делают), а не к физическому порту коммутатора; в. В мануле написано, что коммутаторы МОГУТ (т.е. это НЕ обязательно) ПЕРЕмаркировывать биты CoS, соответственно хотелось бы ТОЧНО знать КАК конфигурируется эта "свобода выбора" (когда надо перемаркировывать, а когда не надо; как эту свободу реализовать для входного пакета на порту, и как для выходного); 2. Новые вопросы, теперь по ограничению скорости трафика (Rate Limiting): а. В мануле написано, что при определенных настройках (Тип1/Port Disable) и объеме трафика порт может "ВЫКЛЮЧЕН". ? Что значит "ВЫКЛЮЧЕН" ? Он физически переводится в Down (т.е. "сосед" определит, что порт выключен) или просто по нему НЕ передается трафик, а физичеки порт в Up ? б. Аналогичный вопрос для (Тип2/Disable Port ); в.Аналогичный вопрос для (Тип3/Disable Port ); 3. И "на закуску" объясните пожалуйста КАК работает опция "Шторм-контрол". Лично у себя эфекта от ее включения я особого не заметил... Заранее спасибо ....

Да, получается "разговор глухого со слепым", "я про Фому - мне про Ерему" Тон ответа и аргументы типа "Приведите в пример других производителей, где есть аналогичные механизмы (подтвердите своё утверждение);" или нравоучения о том, что надо ВСЕГДА глядеть в таблицу маршрутизации просто удивляют (видимо во всем видится злой умысел). Коллега, я не собираюсь "обливать грязью" МОХА-железо (хотя мог бы), я просто ИСКРЕННЕ считал (теперь уже нет), что производитель ЗАИНТЕРЕСОВАН в том, чтобы УЛУЧШИТЬ свое железо. Сейчас же не вижу смысла продолжать и выхожу из обсуждения, тем более что я все свои проблемы РЕШИЛ еще ДО общения в форуме. Извините, если своим "занудством" доставил кому-то неприятные минуты ....

После небольшой паузы позволю себе продолжить: 1. Про "Б": В том то и дело, что очень часто надо "подружить" УЖЕ развернутую инфраструктуру TR с ВНЕШНЕЙ "чужой" системой. Надо ЧЕСТНО признать, что в настоящее время у МОХА механизмов для этого НЕТ . 2. Про "В": Читай выше (нужен стык УЖЕ работающего TR c внешней системой) + TC НЕ работает на ОДНОМ коммутаторе (это обсуждено в самом верху); 3. Теперь про маршрутизацию управляющей влан: - Искать маршрут в таблице маршрутизации для ПОДКЛЮЧЕННОЙ сети - по моему это достаточно "странно", в частности исходя из опыта работы с "кошачими" коммутаторами. Телекомщику, работающему в основном с железом ДРУГИХ производителей трудно догадаться, что имеет место быть упомянутая "фича/баг", особенно в условиях "цейтнота". Повторюсь - я НЕ против данной "фичи/бага", меня просто УДИВЛЯЕТ отсутствие упоминания о ней в документации (а также на страницах данного форума); 4. Была обнаружена и ДРУГАЯ странность в работе маршрутизации (опять же - скольких нервов это стоило): - Как было отмечено выше, в условиях ОТСУТСВИЯ L-2 механизмов "дружбы" УЖЕ развернутой инфраструктуры TR c "чужим" внешним миром была сделана ставка на механизмы L-3 (маршрутизация + VRRP); - На каждом из двух L-3 коммутаторах МОХА была создана ОТДЕЛЬНАЯ VLAN (иначе образуется петля через "чужую" сеть, защиты от которой нет - читай обсуждение выше), с точкой (IP-адресом) терминирования "чужой" сети. В данные VLAN был выведен на каждом соответствующем коммутаторе ОДИН единственный порт в режиме Acces; - Обозначенные выше точки терминирования на разных L-3 МОХА-коммутаторах оказывались в одном L-2 сегменте (через "чужую" сеть) и между ними поднимался протокол VRRP; - Во внешней сети в качестве маршрута в МОХА-сеть указывался виртуальный IP-адрес поднятого протокола VRRP; - Чтобы схема работала при "диагональном" выборе шлюзов (с "разных сторон"), необходимо сделать между L-3 коммутаторами дополнительный L-3 интерконнект и через него прописать маршруты в "чужую" сеть (навстречу друг-другу), при этом "чужая" сеть также оказывается НЕПОСРЕДСТВЕННО подключенной к каждому L-3 МОХА-коммутатору; - Далее все ДОЛЖНО работать очень "просто" - пока L3 МОХА-коммутатор "чувствует" (соответствующий линк в UP ) НЕПОСРЕДСТВЕННО подключению "чужую" сеть, он туда пакеты маршрутизирует напрямую. Если линк в "чужую" сеть падает, L-3 МОХА-коммутатор ПЕРЕСТАЕТ "чувствовать" непосредственное подключение к "чужой" сети и начинает маршрутизировать туда пакеты через соседа (по статическому маршруту); - Описанная выше схема была обкатана на "кошачьих" коммутаторах, где она нормально работает, однако на МОХА-коммутаторах она НЕ ВЗЛЕТЕЛА, т.к. при пропадании линка МОХА не перестает "чувствовать" непосредственное подключение к "чужой" сети и НЕ начинает маршрутизиовать пакеты ЧЕРЕЗ СОСЕДА . Таким образом НЕ получается в полной мере реализовать отказоустойчивость, что достаточно "грустно". ? Может быть было что-то НЕ "докуручено" или имеются ИНЫЕ механизмы решения проблемы ?

1. Одна из, но да. Моё мнение - дело тут в подходе - кто то использует и доволен, у кого-то не получается, в силу различных причин, и да - тогда (всегда) есть альтернативы; 2. Никто не будет делать двойную работу. Есть Dual Homing. Да, есть ограничения. Но и в TC они тоже есть; 3. Такая схема должна корректно работать. Это всё, что можно сказать по такому описанию. Не исключаются и какие-то ошибки в прошивках; 4. Да, MOXA - не панацея от всех бед. И вы правы - от такого отказа спасёт только STP (если контроллер не умеет другого). Ни один "быстрый" протокол известных мне производителей не защищает от подобного рода отказов. У STP обработка подобного отказа - минимум 2 секунды; 5. См. п. 1. Не очевидные вещи есть всегда и у всех, дальше всё зависит от подхода. Кто то учится обходить и жить с этим, кто то меняет оборудование и уходит от проблем, обретая новые.. Каждый идёт своим путём Позволю себе продолжить: А. Сначала про "смену оборудования": В том то и дело, что железо МОХА в целом понравилось (иначе не стал бы тратить свое и чужое время), только "обидно", что на мой взгляд "мелочи" оставляют неприятное (хоть и небольшое) "послевкусие" Б.Про "Dual Homing": Эта "фича" по моему работает только при "интеграции" МОХА-структур между собой, а не при интеграции МОХА-сети с "чужим" миром. ? Или я ошибаюсь ? В.Теперь следующие реальные "заморочки", объясняющие ПОЧЕМУ я выше "домогаюсь" на предмет STP: - Есть реальный крупный объект, где развернуто НЕСКОЛЬКО систем АСУ ТП, между которыми необходимо надежное и эффективное информационное взаимодействие; - Каждая система АСУ ТП реализована на СВОЕЙ телекоммуникационной платформе "известных" производителей (одна из них МОХА), с включенными СВОИМИ протоколами (на МОХА - T.Ring) отказоустойчивости; - Как было обсуждено выше, в этом случае становятся НЕДОСТУПНЫ "общепринятые" протоколы (например STP), с помощью которых разные системы можно было легко и ОТКАЗОУСТОЙЧИВО "поженить"; - ? Что делать ? Вот тут мы плавно переходим к уровню L-3 (маршрутизации), благо в МОХА-сети нашлась парочка L-3 коммутаторов (плюсом к засвеченным выше 6524 и 408), однако: 1. Как оказалось, МОХА НЕ маршрутизирует "управляющую" сеть (где живет объявленный в конфиге IP адрес управления коммутатором). Если это "фича", а не "баг", то почему об этом НИГДЕ не написано ? Эта проблема очень серьезная, т.к. обычно "квалифицированные" наладчики ВСЕ (управление + прикладной уровень) "сваливают" в один L-2 сегмент, который вследствие описанного выше становится НЕ доступным для внешнего мира ЧЕРЕЗ собственную маршрутизацию (становится необходимо делать внешнюю); 2.Ситуация усугубляется, если ПТК должен получать данные с самого коммутатора (по SNMP), в этом случае ПРИНЦИПИАЛЬНО достаточно сложно разнести прикладные сегменты и сегменты управления; 3. Зато в свете описанного выше становится удивительным то, что оказывается коммутатором можно управлять по ДРУГОМУ IP-адресу (относительно объявленного в конфиге), если "галкой" в конфиге разрешено управление из сети, которая терминирована (присутствует) на данном коммутаторе через IP-адрес (вот через него и возможно управление. хоть он совершенно ДРУГОЙ, относительно объявленного в конфиге адреса управления); Конечно же описанное выше "не смертельно", однако ПОЧЕМУ об этом ничего не написано в документации ? Сколько времени было ПОТЕРЯНО, пока разобрались с описанными выше "особенностями" ... ? Или я ошибаюсь ? Есть продолжение у перечисленных "странностей"...

Крайние реплики по обсужденным темам (будут и другие): 1. "Фишка" моха - это как раз моха-протоколы. Если их НЕ использовать (или НЕ получать заявленных характеристик), тогда зачем использовать именно моха (STP-альтернатива очень даже разнообразна) ? 2. Если производитель не хочет прислушиваться к мнению его клиентов (по поводу T.Chain на одном девайсе) - ради бога, пусть не делает, ему же хуже; 3. Схема опыта была очень простая - кольцо из шести штук моха-6524, к которому цеплялась цепочка их трех моха-408. Тестирование проводилось одновременно пингом и встроенным средством подключенного к сети ПТК (не буду его рекламировать). При отключении головы ни пинг, ни ПТК не замечали перестроения, при обратном подключении иногда пропадал пинг и ПТК обнаруживал разрыв связи. При схеме "ринг+каплинг" все отрабатывало отлично при любых эмуляциях отказов; 4. Про петли через хост: Коллега, значит Вам повезло в жизни, раз Вы не видели ситуации, когда хост образует петлю через свои интерфейсы (фактически двух-портовую сетевую карточку, которая совершенно спокойно может быть коммутатором). Лично я буквально 3 марта был ночью выдернут из постели по данному поводу. И дело было не в " использование труда квалифицированного персонала и физическая защита оборудования от несанкционированного доступа", а в софтверных "глюках" контроллера (после перезагрузки которого петля пропала, однако его еще надо было найти). Правде если взять во внимание квалификацию "манагеров"-"закупантов", которые выбирают дешевое дер...е оборудование (имеются ввиду контроллеры/ПТК), которое не спасает даже моха-сеть, то вероятно Вы и правы. 5. По поводу STP/RST - если бы устраивали их скорости сходимости (у некоторых вендоров STP отключает порты/полностью блокирует трафик - смотря как его сконфигурируешь)... Однако повторюсь - не хочет производитель прислушиваться к мнению клиентов, ради бога, значит клиенты уйдут к другому производителю ...

С позволения отвечающего продолжу Пока по уже "засвеченным" темам: 1. 20 мс ВНУТРИ цепочки конечно "радует", однако в "рекламных проспектах" одним из основных преимуществ T.Chain как раз и называется возможность "скоростного" подключения к практически ЛЮБОМУ "внешнему" телекому, посему именно в этом направлении и хотелось бы получить "чемпионские" характеристики; 2. Анонсированный в моем примере внешний мир - это было кольцо T.Ring, т.е. самый что ни есть подходящий случай для демонстрации рекордных скоростей; 3. Понятно, что в перестроении сетевой топологии есть много "нюансов" и "тонкостей", поэтому я и спрашивал КАК измеряются заявленные скорости, чтобы оценить РЕАЛЬНЫЕ цифры, которые можно ожидать в реальных схемах; 4. Ответ по поводу "правильности" НЕ возможности включения T.Chain на одиночном коммутаторе воспринимаю как простое отстаивание "чести мундира", т.к. необходимость этой опции по моему ОЧЕВИДНА (а уж ее реализация по моему вообще не должна вызывать проблем). Подключение же по Dual Homing - это ДРУГАЯ ситуация (тут моха "женится" на мохе). Кстати, не подскажите в каком документе и на какой его странице акцентировано, что T.Chain нельзя включить на ОДНОМ коммутаторе ? 5.В тезисе о "очевидности" объяснения невозможности "дружбы" МОХА-протоколов с STP вероятно имеется ввиду "жадность" производителя (клиенты будут меньше покупать МОХА-железа), однако эта "жадность" приводит к большой "неприятности" - Если включены "МОХА-протоколы", то такая сеть практически НЕ защищена от петель (это как раз и есть основная "работа" STP), т.к.: - Встроенная в коммутаторе опция защиты от петель работает только в рамках ОДНОГО коммутатора. В реальных же схемах в большинстве случаев хосты, имеющие ДВА сетевых интерфейса (через которые и возможно образование петель) подключаются к РАЗНЫМ коммутаторам; - Теоретически можно ожидать "спасения" от межкоммутаторных петель в опции "шторм-контроль", однако по полученным результатам (возможно было что-то "не докручено") это тоже не спасает, т.к. при этом "петлевые" порты НЕ отключаются, а коммутатор предположительно начинает "убивать" не только избыточные "штормовые" пакеты, а ЛЮБЫЕ широковещательные (в том числе и прикладные). В общем в такой ситуации наблюдалось неустойчивость работы и "флапанье" сети (то работает, то нет, постоянные перевыборы мастера в кольце и пр.). По уму лучше бы уж эта опция совсем отключала "петлевые" порты (что кстати и делает STP). Если предложите какой либо НОРМАЛЬНЫЙ способ защиты от петель (в том числе и межкоммутатроных) при работающих МОХА-протоколах отказоустойчивости, то я с радостью откажусь от своих "домагательств" на их совместную работу с STP. Если не надоел, то готов продолжить и по другим "темным" темам ....

Волею судеб принимал участие в реализации на энергетических объектах нескольких телекоммуникационных схем на базе коммутаторов МОХА. При общем благоприятном впечатлении были обнаружены некоторые "засады", которые "смазали" хорошее впечатление от оборудования. Пишу с целью, чтобы "научили дурака" (возможно что-то "не докурутил" в настройках), надежде, что производитель "исправится", а также, чтобы коллеги не наступали на аналогичные грабли. Начнем с "модного" T.Chain: 1. В рекламных проспектах обещают скорость его работы (устранения отказов) ~ 20 мсек. ? Как интересно производитель измерил такую величину ? Реально была получена худшая скорость. При отказах в "голове" "хвост" подключается достаточно "резво" (ПТК-клиенты не замечают этого), а вот при ее ("головы") восстановлении транзитный (из цепочки во внешний мир) трафик замирает на значительное время (~ 1 сек.). Посему если требуется ПОДЛИННОЕ высокое быстродействие механизмов отказоустойчивости, то получается, что лучше T.Chain не применять, а надо использовать "добрый и проверенный" T.Ring+ Coupling (эта "сладкая парочка" действительно быстро отрабатывает); 2. T.Chain можно включить только на ДВУХ и более коммутаторах, т.е. ОДИН коммутатор отказоустойчивым образом по данной технологии подключить НЕЛЬЗЯ. По моему это достаточно странно; 3.Если развивать мысль обозначенную выше дальше, то достаточно странно, что нельзя одновременно на разных портах включить T.Chain и T.Ring (как собственно и STP/RST), т.е. нельзя например отказоустойчивым способом привязать MOXA-кольцо к внешнему НЕ МОХА-телекому; Если дискуссия "задастся", то продолжение следует ....