Jump to content
Форум по продукции MOXA

Ложка дегтя в бочке меда


Recommended Posts

Волею судеб принимал участие в реализации на энергетических объектах нескольких телекоммуникационных схем на базе коммутаторов МОХА.

При общем благоприятном впечатлении были обнаружены некоторые "засады", которые "смазали"  хорошее впечатление от оборудования.

Пишу с целью, чтобы "научили дурака" (возможно что-то "не  докурутил" в настройках), надежде, что производитель "исправится", а также, чтобы коллеги не наступали на аналогичные грабли.

 

Начнем с "модного" T.Chain:

 

1. В рекламных проспектах обещают скорость его работы (устранения отказов) ~ 20 мсек. ? Как интересно производитель измерил такую величину ?

Реально была получена худшая скорость. При отказах  в "голове"  "хвост" подключается достаточно "резво" (ПТК-клиенты не замечают этого), а вот при ее ("головы") восстановлении транзитный (из цепочки во внешний мир) трафик замирает на  значительное время (~ 1 сек.). Посему если требуется ПОДЛИННОЕ высокое быстродействие механизмов отказоустойчивости, то получается, что лучше T.Chain не применять, а надо использовать "добрый и проверенный" T.Ring+ Coupling (эта "сладкая парочка"  действительно быстро отрабатывает);

 

2.   T.Chain можно включить только на ДВУХ и более коммутаторах, т.е. ОДИН коммутатор отказоустойчивым образом по данной технологии подключить НЕЛЬЗЯ. По моему это достаточно странно;

 

3.Если развивать мысль обозначенную выше дальше, то достаточно странно, что нельзя одновременно на разных портах включить T.Chain и T.Ring (как собственно и STP/RST), т.е. нельзя например отказоустойчивым способом привязать MOXA-кольцо к внешнему НЕ МОХА-телекому;

 

Если дискуссия "задастся", то продолжение следует ....

Link to comment
  • Replies 103
  • Created
  • Last Reply

Top Posters In This Topic

Волею судеб принимал участие в реализации на энергетических объектах нескольких телекоммуникационных схем на базе коммутаторов МОХА.

При общем благоприятном впечатлении были обнаружены некоторые "засады", которые "смазали"  хорошее впечатление от оборудования.

Пишу с целью, чтобы "научили дурака" (возможно что-то "не  докурутил" в настройках), надежде, что производитель "исправится", а также, чтобы коллеги не наступали на аналогичные грабли.

 

Начнем с "модного" T.Chain:

 

1. В рекламных проспектах обещают скорость его работы (устранения отказов) ~ 20 мсек. ? Как интересно производитель измерил такую величину ?

Реально была получена худшая скорость. При отказах  в "голове"  "хвост" подключается достаточно "резво" (ПТК-клиенты не замечают этого), а вот при ее ("головы") восстановлении транзитный (из цепочки во внешний мир) трафик замирает на  значительное время (~ 1 сек.). Посему если требуется ПОДЛИННОЕ высокое быстродействие механизмов отказоустойчивости, то получается, что лучше T.Chain не применять, а надо использовать "добрый и проверенный" T.Ring+ Coupling (эта "сладкая парочка"  действительно быстро отрабатывает);

 

2.   T.Chain можно включить только на ДВУХ и более коммутаторах, т.е. ОДИН коммутатор отказоустойчивым образом по данной технологии подключить НЕЛЬЗЯ. По моему это достаточно странно;

 

3.Если развивать мысль обозначенную выше дальше, то достаточно странно, что нельзя одновременно на разных портах включить T.Chain и T.Ring (как собственно и STP/RST), т.е. нельзя например отказоустойчивым способом привязать MOXA-кольцо к внешнему НЕ МОХА-телекому;

 

Если дискуссия "задастся", то продолжение следует ....

1. 20 мс (50 на гигабитных медных линках) - это цифра не из рекламного проспекта, а реально измеренная величина внутри цепочки, состоящей не более чем из 250 коммутаторов. Если внутри цепочки данный параметр не выдерживается, давайте разберёмся почему. Теперь про "внешний мир". Естественно, что внешний мир должен знать о том, что при переходе на Tail порт - абоненты "переходят" на другое плечо. Для этого существуют специальные механизмы уведомления (Turbo Chain высылает определённые BPDU "наверх" при смене ролей). Самый часто встречающийся вариант - это включение на портах "внешнего мира", обращённых к TC, протокола RSTP с портами типа EDGE. Если этого не сделать, то да, действительно, "внешний мир" поймёт переход абонентов внутри TC только по истечении aging timer в матрице коммутации. Как то странно писать об этом на форум MOXA (или "внешний мир" - тоже на MOXA?);

2. Чувства у всех разные. Об этом, во всяком случае, написано в документации. Отдельно стоящий коммутатор можно подключить, используя Dual Homing, но там тоже есть ограничения из п.1;

3. Да, так и есть, причём если подумать - то этому найдётся достаточно очевидное объяснение (написать не смогу). Если есть конкретная задача - приводите топологию, будем думать, что можно сделать.

 

Продолжайте..... :)

Link to comment

С позволения отвечающего продолжу :)

 

Пока по уже "засвеченным" темам:

 

1. 20 мс ВНУТРИ цепочки конечно "радует", однако в "рекламных проспектах" одним из основных преимуществ T.Chain как раз и называется возможность "скоростного" подключения к практически ЛЮБОМУ "внешнему" телекому, посему именно в этом направлении и хотелось бы получить "чемпионские" характеристики; 

 

2. Анонсированный в моем примере внешний мир - это было кольцо T.Ring, т.е. самый что ни есть подходящий случай для демонстрации рекордных скоростей;

 

3. Понятно, что в перестроении сетевой топологии есть много "нюансов" и "тонкостей", поэтому я и спрашивал КАК измеряются заявленные скорости, чтобы оценить РЕАЛЬНЫЕ цифры, которые можно ожидать в реальных схемах;

 

4. Ответ по поводу "правильности" НЕ возможности включения T.Chain на одиночном коммутаторе воспринимаю как простое отстаивание "чести мундира", т.к. необходимость этой опции по моему ОЧЕВИДНА (а уж ее реализация по моему вообще не должна вызывать проблем). Подключение же по  Dual Homing - это ДРУГАЯ ситуация (тут моха "женится" на мохе). Кстати, не подскажите в каком документе и на какой его странице акцентировано, что   T.Chain нельзя включить на ОДНОМ коммутаторе ?

 

5.В тезисе о "очевидности" объяснения невозможности "дружбы" МОХА-протоколов с STP вероятно имеется ввиду "жадность" производителя (клиенты будут меньше покупать МОХА-железа), однако эта "жадность" приводит к большой "неприятности" - Если включены "МОХА-протоколы", то такая сеть практически НЕ защищена от петель (это как раз и есть основная "работа" STP), т.к.:

- Встроенная в коммутаторе опция защиты от петель работает только в рамках ОДНОГО коммутатора. В реальных же схемах в большинстве случаев хосты, имеющие ДВА сетевых интерфейса (через которые и возможно образование петель) подключаются к РАЗНЫМ коммутаторам;

- Теоретически можно ожидать "спасения" от межкоммутаторных  петель в опции "шторм-контроль", однако по полученным результатам (возможно было что-то "не докручено") это тоже не спасает, т.к. при этом "петлевые" порты НЕ отключаются, а коммутатор предположительно начинает "убивать" не только избыточные  "штормовые" пакеты, а ЛЮБЫЕ широковещательные (в том числе и прикладные). В общем в такой ситуации наблюдалось  неустойчивость работы и "флапанье" сети (то работает, то нет, постоянные перевыборы мастера в кольце и пр.). По уму лучше бы уж эта опция совсем отключала "петлевые" порты (что кстати и делает STP).

 

Если предложите какой либо НОРМАЛЬНЫЙ способ защиты от петель (в том числе и межкоммутатроных) при работающих МОХА-протоколах отказоустойчивости, то я с радостью откажусь от своих "домагательств" на их совместную работу с STP.

 

Если не надоел, то готов продолжить и по другим "темным" темам :) ....

Link to comment

С позволения отвечающего продолжу :)

 

Пока по уже "засвеченным" темам:

 

1. 20 мс ВНУТРИ цепочки конечно "радует", однако в "рекламных проспектах" одним из основных преимуществ T.Chain как раз и называется возможность "скоростного" подключения к практически ЛЮБОМУ "внешнему" телекому, посему именно в этом направлении и хотелось бы получить "чемпионские" характеристики; 

 

2. Анонсированный в моем примере внешний мир - это было кольцо T.Ring, т.е. самый что ни есть подходящий случай для демонстрации рекордных скоростей;

 

3. Понятно, что в перестроении сетевой топологии есть много "нюансов" и "тонкостей", поэтому я и спрашивал КАК измеряются заявленные скорости, чтобы оценить РЕАЛЬНЫЕ цифры, которые можно ожидать в реальных схемах;

 

4. Ответ по поводу "правильности" НЕ возможности включения T.Chain на одиночном коммутаторе воспринимаю как простое отстаивание "чести мундира", т.к. необходимость этой опции по моему ОЧЕВИДНА (а уж ее реализация по моему вообще не должна вызывать проблем). Подключение же по  Dual Homing - это ДРУГАЯ ситуация (тут моха "женится" на мохе). Кстати, не подскажите в каком документе и на какой его странице акцентировано, что   T.Chain нельзя включить на ОДНОМ коммутаторе ?

 

5.В тезисе о "очевидности" объяснения невозможности "дружбы" МОХА-протоколов с STP вероятно имеется ввиду "жадность" производителя (клиенты будут меньше покупать МОХА-железа), однако эта "жадность" приводит к большой "неприятности" - Если включены "МОХА-протоколы", то такая сеть практически НЕ защищена от петель (это как раз и есть основная "работа" STP), т.к.:

- Встроенная в коммутаторе опция защиты от петель работает только в рамках ОДНОГО коммутатора. В реальных же схемах в большинстве случаев хосты, имеющие ДВА сетевых интерфейса (через которые и возможно образование петель) подключаются к РАЗНЫМ коммутаторам;

- Теоретически можно ожидать "спасения" от межкоммутаторных  петель в опции "шторм-контроль", однако по полученным результатам (возможно было что-то "не докручено") это тоже не спасает, т.к. при этом "петлевые" порты НЕ отключаются, а коммутатор предположительно начинает "убивать" не только избыточные  "штормовые" пакеты, а ЛЮБЫЕ широковещательные (в том числе и прикладные). В общем в такой ситуации наблюдалось  неустойчивость работы и "флапанье" сети (то работает, то нет, постоянные перевыборы мастера в кольце и пр.). По уму лучше бы уж эта опция совсем отключала "петлевые" порты (что кстати и делает STP).

 

Если предложите какой либо НОРМАЛЬНЫЙ способ защиты от петель (в том числе и межкоммутатроных) при работающих МОХА-протоколах отказоустойчивости, то я с радостью откажусь от своих "домагательств" на их совместную работу с STP.

 

Если не надоел, то готов продолжить и по другим "темным" темам :) ....

 

1. Так и есть. К сетевому оборудованию  любого производителя с поддержкой RSTP. Быстродействие внутри этого сегмента определяется его характеристиками. Это правильный вариант. Есть неправильный - без поддержки RSTP. Всё то же самое про быстродействие и характеристики (быстродействие внешней системы определяется внутри неё самой);

2. То есть TC в рассматриваемом случае подключался к TR и не выдерживалось заявленное время? Приведите схему, конфигурации, посмотрим;

3. Скорости перестроения топологий обычно измеряем утилитой LANBreak (скоростной ping);

4. Сколько операционных систем для коммутаторов было вами разработано (обкатано и продано, подтвердите утверждение практически)? :)  стр. 3-3 Communication_Redundancy_Users_Manual_v5 (на картинках роли указаны в явном виде)

5.

-хост с двумя интерфейсами не передаёт внутри себя трафик и не может образовывать петлю (он же не коммутатор), хотя, конечно, случаи бывают разные;

-петля в топологии сама по себе возникнуть не может - это какая то "надуманная" проблема;

-STP тоже не "совсем отключает" порты.

 

Самый действенный и часто встречающийся способ защиты от петель - это использование труда квалифицированного персонала и физическая защита оборудования от несанкционированного доступа :)

С STP/RSTP наши коммутаторы тоже очень хорошо работают - используйте эту возможность.

Link to comment

Крайние реплики по обсужденным темам (будут и другие):

1. "Фишка" моха - это как раз моха-протоколы. Если их НЕ использовать (или НЕ получать заявленных характеристик), тогда зачем использовать именно моха (STP-альтернатива очень даже разнообразна) ?

 

2. Если производитель не хочет прислушиваться к мнению его клиентов (по поводу T.Chain на одном девайсе) - ради бога, пусть не делает, ему же хуже;

 

3. Схема опыта была очень простая - кольцо из шести штук моха-6524, к которому цеплялась цепочка их трех моха-408. Тестирование проводилось одновременно пингом и встроенным средством подключенного к сети ПТК (не буду его рекламировать). При отключении головы ни пинг, ни ПТК не замечали перестроения, при обратном подключении иногда пропадал пинг и ПТК обнаруживал разрыв связи. При схеме "ринг+каплинг" все отрабатывало отлично при любых эмуляциях отказов;

 

4. Про петли через хост: Коллега, значит Вам повезло в жизни, раз Вы не видели ситуации, когда хост образует петлю через свои интерфейсы (фактически двух-портовую сетевую карточку, которая совершенно спокойно может быть коммутатором). Лично я буквально 3 марта был ночью выдернут из постели по данному поводу. И дело было не в " использование труда квалифицированного персонала и физическая защита оборудования от несанкционированного доступа", а в софтверных "глюках" контроллера (после перезагрузки которого петля пропала, однако его еще надо было найти). Правде если взять во внимание квалификацию "манагеров"-"закупантов", которые выбирают дешевое дер...е оборудование (имеются ввиду контроллеры/ПТК), которое не спасает даже моха-сеть, то вероятно Вы и правы.

 

5. По поводу STP/RST - если бы устраивали их скорости сходимости (у некоторых вендоров STP отключает порты/полностью блокирует трафик - смотря как его сконфигурируешь)...

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

Link to comment

Крайние реплики по обсужденным темам (будут и другие):

1. "Фишка" моха - это как раз моха-протоколы. Если их НЕ использовать (или НЕ получать заявленных характеристик), тогда зачем использовать именно моха (STP-альтернатива очень даже разнообразна) ?

 

2. Если производитель не хочет прислушиваться к мнению его клиентов (по поводу T.Chain на одном девайсе) - ради бога, пусть не делает, ему же хуже;

 

3. Схема опыта была очень простая - кольцо из шести штук моха-6524, к которому цеплялась цепочка их трех моха-408. Тестирование проводилось одновременно пингом и встроенным средством подключенного к сети ПТК (не буду его рекламировать). При отключении головы ни пинг, ни ПТК не замечали перестроения, при обратном подключении иногда пропадал пинг и ПТК обнаруживал разрыв связи. При схеме "ринг+каплинг" все отрабатывало отлично при любых эмуляциях отказов;

 

4. Про петли через хост: Коллега, значит Вам повезло в жизни, раз Вы не видели ситуации, когда хост образует петлю через свои интерфейсы (фактически двух-портовую сетевую карточку, которая совершенно спокойно может быть коммутатором). Лично я буквально 3 марта был ночью выдернут из постели по данному поводу. И дело было не в " использование труда квалифицированного персонала и физическая защита оборудования от несанкционированного доступа", а в софтверных "глюках" контроллера (после перезагрузки которого петля пропала, однако его еще надо было найти). Правде если взять во внимание квалификацию "манагеров"-"закупантов", которые выбирают дешевое дер...е оборудование (имеются ввиду контроллеры/ПТК), которое не спасает даже моха-сеть, то вероятно Вы и правы.

 

5. По поводу STP/RST - если бы устраивали их скорости сходимости (у некоторых вендоров STP отключает порты/полностью блокирует трафик - смотря как его сконфигурируешь)...

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

 

1. Одна из, но да. Моё мнение - дело тут в подходе - кто то использует и доволен, у кого-то не получается, в силу различных причин, и да - тогда (всегда) есть альтернативы;

2. Никто не будет делать двойную работу. Есть Dual Homing. Да, есть ограничения. Но и в TC они тоже есть;

3. Такая схема должна корректно работать. Это всё, что можно сказать по такому описанию. Не исключаются и какие-то ошибки в прошивках;

4. Да, MOXA - не панацея от всех бед. И вы правы - от такого отказа спасёт только STP (если контроллер не умеет другого). Ни один "быстрый" протокол известных мне производителей не защищает от подобного рода отказов. У STP обработка подобного отказа - минимум 2 секунды;

5. См. п. 1. Не очевидные вещи есть всегда и у всех, дальше всё зависит от подхода. Кто то учится обходить и жить с этим, кто то меняет оборудование и уходит от проблем, обретая новые.. Каждый идёт своим путём :)

Link to comment

 

Крайние реплики по обсужденным темам (будут и другие):

1. "Фишка" моха - это как раз моха-протоколы. Если их НЕ использовать (или НЕ получать заявленных характеристик), тогда зачем использовать именно моха (STP-альтернатива очень даже разнообразна) ?

 

2. Если производитель не хочет прислушиваться к мнению его клиентов (по поводу T.Chain на одном девайсе) - ради бога, пусть не делает, ему же хуже;

 

3. Схема опыта была очень простая - кольцо из шести штук моха-6524, к которому цеплялась цепочка их трех моха-408. Тестирование проводилось одновременно пингом и встроенным средством подключенного к сети ПТК (не буду его рекламировать). При отключении головы ни пинг, ни ПТК не замечали перестроения, при обратном подключении иногда пропадал пинг и ПТК обнаруживал разрыв связи. При схеме "ринг+каплинг" все отрабатывало отлично при любых эмуляциях отказов;

 

4. Про петли через хост: Коллега, значит Вам повезло в жизни, раз Вы не видели ситуации, когда хост образует петлю через свои интерфейсы (фактически двух-портовую сетевую карточку, которая совершенно спокойно может быть коммутатором). Лично я буквально 3 марта был ночью выдернут из постели по данному поводу. И дело было не в " использование труда квалифицированного персонала и физическая защита оборудования от несанкционированного доступа", а в софтверных "глюках" контроллера (после перезагрузки которого петля пропала, однако его еще надо было найти). Правде если взять во внимание квалификацию "манагеров"-"закупантов", которые выбирают дешевое дер...е оборудование (имеются ввиду контроллеры/ПТК), которое не спасает даже моха-сеть, то вероятно Вы и правы.

 

5. По поводу STP/RST - если бы устраивали их скорости сходимости (у некоторых вендоров STP отключает порты/полностью блокирует трафик - смотря как его сконфигурируешь)...

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

 

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-адрес (вот через него и возможно управление. хоть он совершенно ДРУГОЙ, относительно объявленного в конфиге адреса управления);

 

Конечно же описанное выше "не смертельно", однако ПОЧЕМУ об этом ничего не написано в документации ?

Сколько времени было ПОТЕРЯНО, пока разобрались  с описанными выше "особенностями" :(...

 

? Или я ошибаюсь ?

 

Есть продолжение у перечисленных "странностей"...

Link to comment

 

 

Крайние реплики по обсужденным темам (будут и другие):

1. "Фишка" моха - это как раз моха-протоколы. Если их НЕ использовать (или НЕ получать заявленных характеристик), тогда зачем использовать именно моха (STP-альтернатива очень даже разнообразна) ?

 

2. Если производитель не хочет прислушиваться к мнению его клиентов (по поводу T.Chain на одном девайсе) - ради бога, пусть не делает, ему же хуже;

 

3. Схема опыта была очень простая - кольцо из шести штук моха-6524, к которому цеплялась цепочка их трех моха-408. Тестирование проводилось одновременно пингом и встроенным средством подключенного к сети ПТК (не буду его рекламировать). При отключении головы ни пинг, ни ПТК не замечали перестроения, при обратном подключении иногда пропадал пинг и ПТК обнаруживал разрыв связи. При схеме "ринг+каплинг" все отрабатывало отлично при любых эмуляциях отказов;

 

4. Про петли через хост: Коллега, значит Вам повезло в жизни, раз Вы не видели ситуации, когда хост образует петлю через свои интерфейсы (фактически двух-портовую сетевую карточку, которая совершенно спокойно может быть коммутатором). Лично я буквально 3 марта был ночью выдернут из постели по данному поводу. И дело было не в " использование труда квалифицированного персонала и физическая защита оборудования от несанкционированного доступа", а в софтверных "глюках" контроллера (после перезагрузки которого петля пропала, однако его еще надо было найти). Правде если взять во внимание квалификацию "манагеров"-"закупантов", которые выбирают дешевое дер...е оборудование (имеются ввиду контроллеры/ПТК), которое не спасает даже моха-сеть, то вероятно Вы и правы.

 

5. По поводу STP/RST - если бы устраивали их скорости сходимости (у некоторых вендоров STP отключает порты/полностью блокирует трафик - смотря как его сконфигурируешь)...

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

 

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-адрес (вот через него и возможно управление. хоть он совершенно ДРУГОЙ, относительно объявленного в конфиге адреса управления);

 

Конечно же описанное выше "не смертельно", однако ПОЧЕМУ об этом ничего не написано в документации ?

Сколько времени было ПОТЕРЯНО, пока разобрались  с описанными выше "особенностями" :(...

 

? Или я ошибаюсь ?

 

Есть продолжение у перечисленных "странностей"...

 

 

Б. Про Dual Homing - верно. "Сверху" должен быть TR или TC;

В. Вот для этого (у MOXA) и сделан TC, который позволяет организовать взаимодействие с "верхней" сетью на стороннем оборудовании, главное чтоб оно умело RSTP;

 

1,2,3. Да, с management VLAN - ситуация действительно странная. Это просто надо принять как есть, объяснить невозможно :) Подозреваю, что данное недоразумение досталось нам в наследство от L2 коммутаторов, то есть это как бы виртуальный интерфейс, который как бы сам по себе и не участвует в дальнейшей деятельности коммутатора (не попадает в таблицу маршрутизации, так же как и MAC коммутатора не висит ни на одном из портов). Вполне вероятно, что в документации это явным образом не указывается, но что бы это понять - достаточно посмотреть в таблицу маршрутизации (мне не кажется, что это займёт много времени). Обходится это (как и было отмечено) очень просто - взаимодействием через любой другой интерфейс. То есть как бы да - странность есть, но называть это существенным недостатком (поливать нас дёгтем из-за того, что не проверили таблицу маршрутизации) - ну как то даже не знаю.. Вам виднее :)

Link to comment

После небольшой паузы позволю себе продолжить:

 

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 МОХА-коммутатор ПЕРЕСТАЕТ "чувствовать" непосредственное подключение к "чужой" сети и начинает маршрутизировать туда   пакеты через соседа (по статическому маршруту);

 

- Описанная выше схема была обкатана на "кошачьих" коммутаторах, где она нормально работает, однако на МОХА-коммутаторах она НЕ ВЗЛЕТЕЛА, т.к. при пропадании линка МОХА не перестает "чувствовать" непосредственное подключение к "чужой" сети и НЕ начинает маршрутизиовать пакеты ЧЕРЕЗ СОСЕДА :(.

 

Таким образом НЕ получается в полной мере реализовать отказоустойчивость, что достаточно "грустно".

 

? Может быть было что-то НЕ "докуручено"  или имеются ИНЫЕ механизмы решения проблемы ? 

Link to comment

После небольшой паузы позволю себе продолжить:

 

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. Всё как раз всё наоборот - у MOXA есть Turbo Chain, который дружит с RSTP. Любым. Как бы вам не хотелось думать об обратном. Приведите в пример других производителей, где есть аналогичные механизмы (подтвердите своё утверждение);

2. Да, TC не работает на одном коммутаторе, на одном работает Dual Homing, которые не обладает функционалом TC, но, тем не менее, он есть;

3. Странности у каждого разные. Для меня "странно" искать проблему в маршрутизации, не глядя в таблицу маршрутизации (кстати, а сколько времени было потеряно?), считая присоединённые маршруты как бы "недостойными" внимания. И да, мы стараемся исправляться, вот, теперь об этом у нас есть упоминание на форуме, спасибо! :) ;

4. Вот как раз тот случай, когда один раз проще нарисовать, чем много написать. Нарисуйте схемку, пожалуйста, подумаю.

Link to comment

Да, получается "разговор глухого со слепым",  "я про Фому - мне про Ерему" :( 

 

Тон ответа и аргументы  типа "Приведите в пример других производителей, где есть аналогичные механизмы (подтвердите своё утверждение);" или нравоучения о том, что надо ВСЕГДА глядеть в таблицу маршрутизации  просто удивляют (видимо во всем видится злой умысел).

 

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

 

Сейчас же не вижу смысла продолжать и выхожу из обсуждения, тем более что я все свои проблемы РЕШИЛ еще ДО общения в форуме. 

 

Извините, если своим "занудством" доставил кому-то неприятные минуты ....

Link to comment

Да, получается "разговор глухого со слепым",  "я про Фому - мне про Ерему" :(

 

Тон ответа и аргументы  типа "Приведите в пример других производителей, где есть аналогичные механизмы (подтвердите своё утверждение);" или нравоучения о том, что надо ВСЕГДА глядеть в таблицу маршрутизации  просто удивляют (видимо во всем видится злой умысел).

 

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

 

Сейчас же не вижу смысла продолжать и выхожу из обсуждения, тем более что я все свои проблемы РЕШИЛ еще ДО общения в форуме. 

 

Извините, если своим "занудством" доставил кому-то неприятные минуты ....

 

Схемы нет. Желания разобраться в проблеме из поста #9 нет. Есть блюдце с эмоциями. :mellow:

Это ресурс технической направленности. Не думаю, что вы найдёте здесь утешение....

Link to comment
  • 3 months later...

Зарекался не продолжать, однако вынужден это сделать :(

 

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. И "на закуску" объясните пожалуйста КАК работает опция "Шторм-контрол". Лично у себя эфекта от ее включения я особого не заметил...

 

 

Заранее спасибо ....

Link to comment

Зарекался не продолжать, однако вынужден это сделать :(

 

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

Link to comment

:)

 

Не буду весь этот "поток", который тут аж в 3х экземплярах отправили, цитировать или комментировать. Я на вопросы отвечу, так, чтоб потом может кому другому тоже пригодилось:

 

2а. По фразе "немар" не нашёл этого. Вообще коммутаторы MOXA не изменяют содержимое QoS или ToS. Т.е. на выходе вы получите то же значение QoS, что и на входе;

2б. В плане QoS - никак. То есть им присваивается normal и изменить этого никак нельзя. K VLAN тоже нельзя;

2.в. Возможно неточность перевода (не искал). Не перемаркировывают. См. 2.а.;

Следующий пункт 2 (три раза отправили, а пунктов пожалели :blink: )

2.a. Физически в Down не переходит, программная блокировка;

2.б. -//-;

2.в. -//-;

3. Начинает отбрасывать broadcast (L2) выше определённого порога. Порог (в fps) у моделей разные, но в среднем можно ориентироваться на 10% от пропускной способности порта в одну сторону.

 

Пожалуйста B)

Link to comment

Продолжу:

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% широковещательного трафика, чтобы потом начать его блокировать.

 

Link to comment

0. Есть QoS, ToS (старое), DSCP (новое). Соответственно, 802.1p, RFC1349, RFC 2474. Впредь, плз уточняйте, про какой QoS (L2 или L3) мы говорим. А то может как с таблицей маршрутизации получиться :wacko:. Справочно - сначала обрабатываются DSCP (ToS), потом QoS;

1. При следовании Access -> Trunc QoS будет проставлен как 1 (про normal - был не прав, это будет background). Изменить никак нельзя.

2. Нет. BPDU TR, TC всегда будут иметь высший приоритет;

3. Ему будет присвоено QoS как 2 (не могу сказать почему это так) и DSCP как 6 (потому как это routing protocol). Далее см. п.0;

4. Кадры отбрасываются при превышении порога, до проверки признаков качества дело не доходит;

5. Счётчик там в fps. Соответственно, интервал обновления - секунда. Превысили порог - начали отбрасывать - ждём следующего значения.

 

Update

QoS всего собственного трафика, испускаемого коммутатором, который должен иметь 802.1Q, будет равен 2.

 

Link to comment

Еще несколько уточнений:

 

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

Link to comment

1. Да. qos default-cos определяет очередь, в которую будут попадать пакеты без СoS. Маркировка CoS, при этом, все равно будет равна 1 (если она будет производиться). При этом, эта команда будет корректно работать либо на чистом L2 трафике, либо при отключённой проверке ToS;

2. Должно быть именно так. Не спорю, я могу представить ситуацию, когда broadcast-шторм "положит" TR. Но это очень специфичная ситуация, и, для начала, хотелось бы точно знать, что у вас это именно так, и знать вашу топологию. А мы про TR1 или TR2? В TR2 пропадание BPDU не должно приводить к перевыборам (даже если они пропадают). Проверяли (не я, конечно), на 250 коммутаторах при 100% загрузке портов;

3. Да;

4. Да, разумеется;

5. Да, если смотреть график broadcast в этом случае - там будет "пила".

 

 

 

Link to comment

Еще несколько "идиотских" вопросов:

 

1. Как я понял из вышесказанного, "шторм контрол" и "Rate Limiting" по крупному делают примерно одно и тоже - ограничивают широковещательный трафик. Соответственно вопрос: ? Если включены ОБЕ опции, то кто из них "главнее", т.е. чьи параметры будут применены в итоге на портах коммутатора ? 

 

2. Неприятная ситуация с предположительно  "перевыборами"  при шторме  наблюдалась при использовании TR2 и проявлялась она в:

 - "мигание" (достаточно "частое") индикации "мастер" на коммутаторе, который директивно был им назначен;

 -  мастер сыпет в сислог сообщения  "смена топологии";

 - "прмаргивание" (достаточно "редкое") индикации "мастер" на коммутаторе, на котором предположительно образовалась петля;

 - "прикладной" обмен  практически "умер";

 - "управляющий" трафик (реализован в отдельной от прикладного обмена Vl1) ну ОЧЕНЬ затруднен (чтобы опустить "петлевой" порт и тем самым "топологически" погасить шторм пришлось долго "пробиваться" на коммутатор);

 

Есть подозрение (возможно неверное), что при шторме неприятности обусловлены не напрямую большим широковещательным трафиком, а тем, что он не "обрабытывется" системой очередей (т.е. "возбуд" любого даже НЕ важного трафика, "прибивает" полезные широковещательные пакеты во ВСЕХ  других очередях/VLAN) и перегрузкой CPU коммутатора. Отсюда  очень любопытно посмотреть методику испытаний тех самых колец из 250 коммутаторов, загруженных на 100%;

 

3.  Также бы хотелось получить информацию о якобы известной поддержке  "ситуацию, когда broadcast-шторм "положит" TR" ? Или позиция производителя - это утаивание "неприятной" информации (как например немаршрутизируемость управляющей VLAN) ? 

 

Заранее спасибо и извиняюсь, за  возможное "занудство" ....

Link to comment

1. Тут я точно ответить не могу, но в моём понимании, Broadcast Storm Protection работает раньше, чем Rate Limiting (в более ранних "восходящих" политиках). Точно могу сказать, что блоки за них отвечают разные. Для точного ответа тут надо читать мануал на ASIC, а он мало того, что огромный, так ещё и "секретный" (т.к. платный). Кстати, (применительно к QoS) - обсуждаемые механизмы работают в восходящих правилах, а очереди - в исходящих.

2. Мммм.. Возможно всё, конечно. Но:

- BPDU TR (TC) - это не broadcast, a multicast, соответственно, фильтр их "рубить" не должен;

- пропадание BPDU (как уже говорил) в TR2 не приводит к перевыборам/изменению топологии;

- про обработку очередей чуть чуть написал в п.1;

- методики у меня нет/скорее всего вообще нет, так как протокол проприетарный :( . Думаю, что при тестировании использовали трафик-генератор и flooded unicast. Broadcast'том естественно никто не тестирует, т.к. broadcast storm, как известно, кроме забивания полосы пропускания имеет и другую беду (какую? B)  Назовёте?).

3. Я тут так отвечу - всегда и везде говорится, что использование TR спасает от единичного отказа (обрыв линии/выход из стоя коммутатора). Именно от единичного. Broadcast shorm, как ни крути - это отказ топологии в целом, причём, в большинстве случаев, вызванный либо неправильными действиями, либо неверной конфигурацией. Какие тут претензии?

Link to comment

Снова буду "доставать" своей непонятливость (она вынужденная, т.к. провести испытания предварительных настроек нет возможности, а время на возможную трансформацию продуктива будет очень мало):

 

1.

а. ? Т.е., чтобы работали политики и значения ограничения скорости, заданные  в "Rate Limiting", надо отключить "шторм-контрол" ? Иначе вероятно "высокие" пороги "шторма" никогда не будут достигнуты, т.к. порог в 10% "шторм-контроля" будет первым достигаться, соответственно дальнейший трафик будет блочится и до больших порогов дело не дойдет.

 

б.То, что у мохи очереди "разгружаются" по выходу, а трафик блочится на входе - это понятно. Вопрос как раз в том, чтобы блочился трафик более "интеллигентно", а не "оптом" (например дифференцировано по VLANaм, как можно сделать у той же циски). Иначе до очередей пакеты просто НЕ добираются :(.

 

в. Услышал, что пакеты ТR и ТС блочится не должны, т.к. они мультикаст (кстати, в политиках "Rate Limiting" по моему можно задать блокировку мультикаста), а как быть в отношении

пакетов "Coupling" (вероятно и такие есть) ? Они тоже гарантированно не блочатся "ограничителями скорости"?

 

2.  Я описал то, что видел своими глазами, а сообщения же о смене топологии записаны в лог-файлах. Глубоко копать ЧТО и ПОЧЕМУ происходило времени не было - надо было максимально быстро оживлять систему (что и произошло при разрыве предположительно кольцевой топологии). Повторить эксперимент на работающем оборудовании тоже нет желания,  вот сейчас "постфактум" и пытаюсь понять ИСТИННЫЕ причины  наблюдаемого и выработать мероприятия по снижению вероятности повторения "неприятностей";

 

3. По поводу "какие претензии":

- Как писал ранее в общем моха понравилась, только вот оказалось, что  она нормально работает с НОРМАЛЬНЫМИ хостами (там горя не знаю с мохой);

- Если же  "посчастливилось" заиметь   "кривые" хосты (например склонные к образованию петель через свои интерфейсы), да еще с "плоской" и НЕ дублированной сетью то возможностей мохи для "исправления ситуации" не хватает;

- Получается, что  надо или переходить полностью на RSTP (при этом НЕ устраивает скорость отработки отказов -  за время сходимости RSTP оборудование успевает остановится) или "шаманить" с CoS и "Rate Limiting" (? может еще какие есть возможности ?), чтобы снизить риски "неприятностей" (и криков начальников);

- Возможно,  что имеются завышенные ожидания в наличии у   мохи некоторых "фич", однако  они порождены опытом работы с другим железом;

- Понимаю, что ПРАВИЛЬНОЕ решение - это изначально купить нормальный и не "глючный" (а значит и дорогой) ПТК, только у покупателя системы видно были другие мысли на этот счет и теперь приходится жить с тем, что имеется в наличии .....

 

Link to comment

1.a. Полагаю, что так;

1.б. Вообще, большинство ASIC это умеет. Но у нас (MoxaOS) этого нет :(. Вот перейдём на какой нить VxWorks (как у того-же Hirschmann) - и сразу научимся  :);

1.в. Аналогично. Можно и там и там ограничение на multicast включить. Но они в него всё равно попадать не должны (т.к. будут "покрашены" чуть раньше);

2. :unsure:

3. На мой взгляд, для борьбы с broadcast storm - это использовать Rate Limiting в режиме Port Disable, и блокировать порт на какое-то существенное время (10 минут? час?). И сделать так на всех портах, обращенных к абонентам (кроме магистральных, где TR, например). То есть заштормило - заблокировали - спокойно разбираемся.

Link to comment

3. Такая идея первой пришла в голову и рассматривается как один из вариантов, однако:

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

- При логическом же отключении порта, хост считает, что у него с сетью все нормально и он продолжает работать как работал через тот-же интерфейс, т.е. пулять пакеты в отключенный порт и физически через себя "замыкать" петлю (временно разорванную);

- Т.е. предложенным способом теоретически можно  временно притушить шторм (и это уже не плохо), а вот "полечить" контроллер/хост не получается :(

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...