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

[stesv]

И на "закуску" совсем "обнаглею":

 

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

 

Могу вложить документ, тем более, что ранее в общении Вы несколько раз изъявляли желание увидеть схемы ......

[Незнайка]

Ммм.. Экспертизу?

Я не гинеколог, но посмотреть могу (с)

Прикладывайте.

[Незнайка]

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

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

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

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

Есть подозрение, что будут "запираться" одновременно оба интерфейса, во всяком случае при использовании кабеля это именно так и происходит... То есть, видимо времена блокировки надо ставить разные для портов, обращённых к одному абоненту.

[stesv]

С небольшой задержкой (вызванной отпуском) снова позволю себе позадавать "глупые" вопросы (будет очень мало времени на настройку/испытания/эксперементы, посему по 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. По поводу одновременного запирания двух интерфейсов: Надо просто уставки сделать РАЗНЫЕ для разных интерфейсов. В этом случае один из них будет запираться первым и тем самым гасить петлю. Ежели после этого дело дойдет и до второй (большей) уставки, тогда точно в сети "ж...а" и полностью отключится от нею будет по моему даже "полезно";

 

[Незнайка]

1.а. Если это RSTP BPDU от другого коммутатора MOXA - то нет, иначе - да;

1.б. Разные switch-chip - разные возможности... Этим и объясняется;

1.в. Как уже говорил, ОС оперирует понятием fps, т.е. на интервале секунда. Switch-chip отдаёт этот счётчик;

1.г. Согласно логике работы - именно так.

2. Пробовал разные (на первом min, на втором max). При "замыкании" кабелем у меня гасли оба порта. Вероятно, будет зависеть от кол-ва broadcast в сети, я генератором его забрасывал.

 

[stesv]

1. Понятно.

 

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

 

Если Ваш эксперимент дают ДРУГОЙ результат, то вероятно логика работы отличается от описанной ранее.  

Очень бы хотелось ее совершенно ТОЧНО определить ....

[Незнайка]

Логика - как описано выше. Результат моего эксперимента ей не противоречит.

[stesv]

В очередной раз приветствую:

 

1. Не совсем понял как результат (ОДНОВРЕМЕННАЯ блокировка трафика по обоим портам с РАЗНЫМИ уставками) соответствует описанной логике; 

 

2. В реальной схеме наблюдается (по сообщениям сислог) влияние клиентских портов на топологию T.Ring (сообщается о смене топологии). Хотелось бы получить комментарии по данному явлению, подтверждающие материалы во вложении, заранее спасибо  ....

Зафиксированы следующие события--.doc

[Незнайка]

День добрый!

 

1. Потому что счётчик в fps. Как я понимаю, за секунду достигается значение, превышающее максимальную уставку и оба порта блокируются. В реальной сети это может быть по другому;

2. Я так понимаю, что фиолетовое кольцо проходит через порт 2-8 PGUSW6, состояние порта меняет свой статус, происходит Topology Change, при этом одновременно меняется статус порта 2-6 PGUSW5, хотя на схеме он указан как 028 (ошибка в схеме?).

[stesv]

Приветствую:

 

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).

 

 

[Незнайка]

Да, так стало немного понятнее, спасибо!

А Сoupler'ы где назначены - на SW5 SW6 или на SC1 SC2?

 

 

[stesv]

Приветствую,

 

1. Коплеры назначены на sw5 и sw6;

 

2. Если уж совсем быть честным, то у схемы есть следующее продолжение (оно не убралось на картинку):

 

- SC1, SC2 входят в другое кольцо, видны его коричневые линки;

- Есть еще и ТРЕТЬЕ кольцо (условно "синее", его не видно), которое также "прикоплено" к коричневому (со стороны синего);

 

3. Самое непонятное, что наблюдается  - это "перестройка топологии" (по сообщениям в сислог) при проблемах на клиентских порта;

 

4. Сеть "раздроблен" на кольца с целью попытаться локализовать возможные "неприятности" внутри одного кольца. Про проблемный ПТК писал ранее ....

[Незнайка]

То есть, SW6 - он одновременно Ring Master и Backup Coupler?

Тогда два вопроса - какая на нём прошивка и возникает ли Topology Change при подключении любого устройства в любой порт? То есть, если в произвольный порт SW6 включить ноутбук, например, произойдёт ли это событие?

Пока тут два предположения - либо это баг, либо как то связано с работой Backup Coupler, правда пока не могу понять как.

Кстати конкретно в этом случае - Topology Change на SW6 означает сброс таблицы коммутации.

 

Про дробление сети на L2 с целью защиты от broadcast storm - по моему, это напрасно. В смысле не поможет. Ну тут конечно, каждый делает по своему. С моей точки зрения - тут на L3 надо сегментировать.

[stesv]

Приветствую и продолжаю:

 

1. В доказательство, что событие не случайное привожу очередной лог (который сегодня не дал выспаться);

 

2. Отвечаю на уточняющие вопросы:

 

а. Да, SW6 для своего кольца мастер, а для "внешней" стыковки он резервный коплер. ? Что-ли так НЕ рекомендуется делать ? Если да, то как делать более правильнее ?

 

б.  Прошивки во все коммутаторы залиты самые свежие, которые у Вас есть на сайте;

 

в. Сброс таблицы коммутации вероятно - это на самая большая "трагедия", беспокоит НЕПОНИМАНИЕ ситуации;

 

г. По поводу как ПРАВИЛЬНО лечить "широковещательную" болезнь:

 

- Самый правильный подход - это замена "глючного" ПТК, однако мы понимаем, что это проблематично;

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

- А еще правильно - это иметь подлинно ДУБЛИРОВАННУЮ/ДВОЙНУЮ сеть, когда одна ложится - и нас...ть, вторая параллельно и ВСЕГДА работает.

 

Зафиксированы следующие события+.txt

[stesv]

Еще вопрос:

 

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

 

? Чему верить - % или физическим значениям ? 

[stesv]

Приветствую.

 

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

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

  

[Незнайка]

День добрый!

Над предыдущими вопросами пока думаем, потому и ответа пока нет

с п. 5-7 - не согласен, всё равно ему, с какой частотой где у него какой MAC "светится", ну него на то и wire-speed, чтоб свою таблицу коммутации менять на лету.

[Незнайка]

По поводу 3% и 3Mbps. Для 1G порта это всё таки будет 30Mbps.

 

[Незнайка]

В общем пока не воспроизводится.

Дайте, пожалуйста, конфиги с SC1, SC2, SW8, SW9, SW5, SW6, и их серийные номера (в формате ABCDE1234567)

Update

Есть подозрение, что ваш ПЛК испускает в сеть что то типа RSTP BPDU при смене интерфейсов. Можно это как то узнать?

[stesv]

Приветствую.

 

1. Вчера (подвернулся останов основного оборудования) начали менять топологию в направлении большей локализации отдельных функциональных блоков (делаем три кольца T.Ring вместо двух), посему вероятно актуальными будут другие конфиги (и возможно проблемы);

 

2. Буквально сейчас начнем "химичить" с "RateLimiting", Prioroty/CoS  и пр., после чего проведем испытания на устойчивость конструкции к петлям и пр.;

 

3. Старые конфиги (новые тоже не секретные) и серийники пришлю попозже ; 

 

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

[Alexandra]

Прошивка во вложении

FWR_IKS6700A_V4.1.18_Build_17041917.rom

[Незнайка]

Попробуйте, плз, поставить на SW5 и SW6 прошивку из сообщения выше. Посмотрим, как оно будет. Подозреваю, что Topology Change уйдёт.

[stesv]

Приветствую.

 

1. Большое спасибо за прошивку. ? Это что-то новое, относительно выложенного на сайте ?

 

2. Если да (сейчас у нас используется самая новая с сайта), то перезаливаться будем позже, сейчас оборудование в работе. Или испытаем ее на другом объекте (отпишусь по результатам);

 

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

 

4. Как Вы ранее и предлагали единственное эффективное средство борьбы с широковещательным штормом для нашего "чудесного" ПТК  оказалась полная блокировка "шумящего" порта на значительное время. Хотя другой трафик может ходит совершенно нормально и при более "мягких" ограничениях;

 

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

 

Спасибо за участие в "расследовании", если был излишне эмоционален в общении - прошу прощения ....

 

 

[stesv]

Приветствую.

 

1. Большое спасибо за прошивку. ? Это что-то новое, относительно выложенного на сайте ?

 

2. Если да (сейчас у нас используется самая новая с сайта), то перезаливаться будем позже, сейчас оборудование в работе. Или испытаем ее на другом объекте (отпишусь по результатам);

 

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

 

4. Как Вы ранее и предлагали единственное эффективное средство борьбы с широковещательным штормом для нашего "чудесного" ПТК  оказалась полная блокировка "шумящего" порта на значительное время. Хотя другой трафик может ходит совершенно нормально и при более "мягких" ограничениях;

 

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

 

Спасибо за участие в "расследовании", если был излишне эмоционален в общении - прошу прощения ....

 

 

[Незнайка]

Добрый день!

 

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