ticket summary component milestone type owner status created modified _description _reporter 188 Требуется измеритель уровня сигнала в TDM маппере ПЛИС (sw) 1 очередь улучшение alx assigned 2016-08-04T14:38:34+05:00 2025-10-15T18:00:07+05:00 "~~Отдельная ячейка коммутационного поля TDM маппера, скомутировав в неё нужный канал мы должны увидеть уровень сигнала в этом канале.~~ На вкладке ""Данные TDM"", кроме hex и bin добавить ещё переключатель ""уровень dBm"", при переключении на этот вариант в ячейках должен отображаться уровень сигнала принятого коммутатором от платы." san 304 "Резервирование потоков: изменить алгоритм варианта ""без возврата на основной""" ПЛИС (sw) 1 очередь улучшение alx assigned 2017-11-03T13:33:39+05:00 2025-10-18T14:19:19+05:00 "Сценарий: Пользователь настроил резервирование ""без возврата на основной"". 1. ОСН-норма, РЕЗ-норма. Данные идут по потоку ОСН 2. ОСН-авария, РЕЗ-норма. Данные переключаются на поток РЕЗ 3. ОСН-норма, РЕЗ-норма. Данные по прежнему идут по потоку РЕЗ 4. ОСН-норма, РЕЗ-авария. Данные переключаются на поток ОСН 5. ОСН-норма, РЕЗ-норма. Данные переключаются на поток РЕЗ Поведение в пункте 5 кажется пользователям не логичным, и мне в том числе. Раз уж вынуждено было произведено переключение на '''основной''' поток, и он в норме, то какой смысл в возврате на резервный ? Предлагаю: в режиме ""без возврата"" производить переключение на другой поток только при аварии на текущем потоке. " san 537 "Резервирование потоков: добавить опцию ""передавать/не передавать данные в резервном потоке""" ПЛИС (sw) 1 очередь улучшение alx assigned 2021-09-08T11:59:20+05:00 2025-10-15T18:00:07+05:00 "Сейчас при переходе на резерв одной стороны, эта сторона передаёт на дальнюю сторону извещение, через биты RAI в ЦСС. Сделано это для того, чтобы в резервном потоке можно было передавать другие данные и переключение на обоих сторонах было одновременным(чтобы не получилось так что одна переключилась на резерв, а другая нет и передает ложные данные пользователю). В передаче и анализе RAI есть минус - в случае если ЦСС формируется не в нашем блоке, то в нём может присутствовать RAI, что может привести, как минимум, к ложному переключению на резерв или гипотетически к ""кольцу RAI"" Алексей(ledol) предлагает добавить еще один вариант алгоритма резервирования: Не передавать RAI и в резервном потоке всегда передавать данные из основного, тогда каждая сторона независимо от другой может переключаться на резерв." san 272 "Кнопка ""Применить"" на вкладке Ethernet->VLAN, Ethernet->RSTP" web-интерфейс (sw) 2 очередь улучшение alx new 2017-09-18T15:22:59+05:00 2023-09-11T17:58:56+05:00 "Предлагается вместо немедленной записи каждого изменения настроек в коммутатор, записывать все изменения только после нажатия кнопки ""Применить"". За время работы аппаратуры разные пользователи жалуются на неудобство ""мгновенного"" применения настроек на вкладке Ethernet->VLAN. Случайно ткнув мышкой парой пикселов правее-левее можно сломать связь с блоком. Кроме этого, ""пошаговая"" настройка немного сложнее, т.к. нужно соблюдать определённую последовательность действий, чтобы не потерять связь с блоком.(например при переносе порта CPU в другой VLAN нужно обязательно сначала создать новый vlan, а потом уже удалять старый) А недавно я сам столкнулся с неудобством такого подхода настраивая VLAN на блоках в кольце RSTP(""промежуточные"" состояния настройки сложно проанализировать, кроме того шаги вызывают кольца и перестроения дерева, и гораздо проще было бы настроить за ""одно применение"" чем пошагово. p.s. Ваня сравнивает настройку VLAN на нашей аппаратуре с игрой [https://ru.wikipedia.org/wiki/Сапёр_(игра) ""Сапёр""]." san 303 Резервирование потоков: добавить настройку таймаута детектирования аварии ПЛИС (sw) 2 очередь улучшение alx assigned 2017-11-03T13:03:19+05:00 2025-10-15T18:00:07+05:00 Сейчас при возникновении кратковременной аварии поток переключается на резервсразу. В некоторых случаях, например при грозе или э/м помехах пользователи предпочитают чтобы поток не переключался на резерв при кратковременных авариях, поэтому предлагается ввести настройку таймаута. san 314 Добавить поле комментария в настройки групповых каналов web-интерфейс (sw) 2 очередь улучшение alx new 2017-12-06T18:03:27+05:00 2017-12-06T18:06:08+05:00 "Добавить поле комментария к каждому групповому каналу, в настройки групповых каналов В старый интерфейс и новый. " san 358 Новая функция: дистанционный анализ трафика ethernet sw 2 очередь улучшение alx new 2018-10-10T16:22:10+05:00 2018-10-10T18:10:10+05:00 "Иногда при исследовании прохождения (или непрохождения) трафика по сети требуется узнать, что за пакеты ходят через наш коммутатор. Когда блок находится в физической доступности, можно подключить анализатор (компьютер) к свободному порту и миррорить туда интересующий трафик. Но если блок находится далеко и доступен только по сети, это сделать затруднительно. Отчасти задача решается направлением (миррорингом) кадров в порт CPU и наблюдением за трафиком TCPDUMP'ом, но здесь есть ряд недостатков. Во-первых, tcpdump не покажет, каким образом тегированы кадры, так как сразу после приема кадра его тэг отбрасывается. Во-вторых, трафик может быть довольно большой, и CPU в нем может ""захлебнуться"". В-третьих, возможна нежелательная ""интерференция"", например, из-за случайного пересечения адресов (скажем, CPU отвечает на запрос, посчитав, что запрос адресован ему, хотя это был запрос из независимой изолированной сети)... Насколько я помню, в коммутаторе есть такая функция - проба трафика. Суть ее в том, что из потока кадров выбираются отдельные с некоторой вероятностью (например 1 из 100) и отправляются в CPU. Предлагается задействовать ее для наблюдения за трафиком. Кадры, направленные в CPU этой функцией, могут быть опознаны по соответствующему коду (код указывается в тэге). Предлагается такие пакеты направлять в специальный VLAN (снабжать их тэгом с ID, например, 2222). Это исключит ""интерференцию"" с настоящим пользовательским трафиком (мониторинг/управление). В SW-01 для наблюдения за кадрами создать новый интерфейс с VLAN ID 2222. Наблюдать трафик можно будет как tcpdump'ом, так и самим демоном swd, который мог бы принятые кадры отображать (с минимальным анализом) в веб-интерфейсе. Прошу высказывать мнения, пожелания, критику и т.п." alx 874 Добавить диалоговое окно при коммутации контейнеров в ST-04 web-интерфейс (sw) 2 очередь улучшение alx new 2026-07-16T12:15:47+05:00 2026-07-16T12:15:47+05:00 "Предлагаю добавить диалоговое окно при коммутации нескольких контейнеров ""Создать обратное соединение?"" на плате ST-04 на вкладке ""Кроссконнекция"", как это сделано при коммутации одного контейнера. Механизм как в таблице TDM платы SW-01. То есть пользователь выделяет несколько контейнеров и перетаскивает их на другие контейнеры. Появляется диалоговое окно ""Каким источником назначить брошенный контейнер?"", после ответа пользователя ""Основным"" или ""Резервным"" возникает следующее диалоговое окно ""Создать обратное соединение?"". И при положительном ответе пользователя так же задается вопрос ""Каким источником назначить брошенный контейнер?"". После ответа пользователя ""Основным"" или ""Резервным"" происходит обратная коммутация контейнеров. На мой взгляд, это упростит процесс настройки платы." roman_zhur 66 При несконфигурированной ПЛИС выдавать аварию swd 2 очередь баг alx new 2014-07-31T16:28:14+06:00 2014-07-31T16:28:14+06:00 "При постоянной ошибке конфигурации ПЛИС (например испорчен файл прошивки) горит зеленая лампочка ""OK"", и о неисправности платы ничего не гвоорит. Надо формировать аварию при незаконфигурированной ПЛИС." alx 310 Мониторинг регенераторов SM-xx web-интерфейс (sw) 2 очередь задача alx new 2017-11-22T15:33:18+05:00 2018-10-09T10:11:50+05:00 "Пользователи часто жалуются на сложность мониторинга регенераторов подключенных к плате SM-xx. Тема эта уже давно назрела, попытался всё описать, если что-то забыл или наврал поправляйте. Что нужно от регенераторов: I. Собственно мониторинг. Периодическое обновление информации о состоянии участков линейного тракта, накопление статистики и т.д.. II. Детализация аварии на линейном тракте. Допустим тракт состоит из N участков (N-1 регенераторов) и в момент аварии пользователи хотят получить детализированное сообщение в программе мониторинга и логах, на каком участке и на какой паре произошла авария. Сложности текущего варианта: 1. Для мониторинга нужно периодически посылать команду опроса, т.е. программе мониторинга кроме чтения придётся делать ещё и запись в определённую переменную, либо посылать команду другими средствами. В любом случае это дополнительная сложность. 2. При новом опросе таблица очищается и до окончания опроса в таблице не корректные данные (не понятно регенератор пропал(не отвечает) или опрос ещё не завершен) а точного признака окончания опроса нет, есть некоторые критерии, но мы их сами ещё не можем до конца сформулировать и я думаю что перекладывать задачу определения критериев конца опроса на пользователя не правильно. 3. Проблема с отказом EOC канала на платах SM-01, суть: EOC канал может перейти в нерабочее состояние при некоторых условиях(одновременное попадание ЕОС пакетов с разных сторон в регенератор). Подробности у Влада. 4. Конфликты с совместным доступом, это следствие из п. 1-3, если два пользователя независимо друг от друга будут проводить опрос и считывать таблицу, они могут мешать друг-другу. - Очищение таблицы вызванное опросами одного мешает прочитать таблицу другому. - При повторном опросе до завершения предыдущего, возможно проявление проблемы с EOC на SM-01. Так-же это возможно при мониторинге с двух сторон Предлагается: a. Плата SW-01 сама периодически отправляет команды опроса платам SM-xx и кэширует таблицы регенераторов для мониторинга и отображения в веб-интерфейсе. b. При возникновении аварии линейного тракта производится немедленный опрос регенераторов для детализации аварии. с. Пользователь, при необходимости, может через веб-морду нажать кнопку опрос не дожидаясь автоматического обновления таблицы. Вопросы: - Критерии конца опроса (таймаут, кол-во регенераторов,...) - Опрос по разным парам. Для простоты ограничиться опросом по паре А? - Что делать с опросом с двух концов? " san 31 Сделать коммутацию обратного потока Е1 web-интерфейс (sw) 2 очередь улучшение alx new 2014-03-21T14:07:03+06:00 2014-06-16T18:13:53+06:00 Сделать коммутацию обратного потока Е1. alx 277 Окно платы SM-xx: опрос при входе web-интерфейс (sw) 2 очередь улучшение alx new 2017-09-27T17:04:47+05:00 2017-09-28T10:02:00+05:00 "Предлагается при каждом открытии окна платы SM-xx автоматически запускать ""опрос"" чтобы не вводить пользователя в заблуждение устаревшими данными в таблице. p.s. это решение временное, в идеале в таблице должно отображаться актуальное состояние регенераторов, без нажатия кнопок." san 273 Функция автоматического контроля канала sw Как-нибудь потом задача alx assigned 2017-09-18T18:46:23+05:00 2025-10-15T18:00:07+05:00 "viktam натолкнул меня на идею (см. mc-04:#12). Предположим, в сети организован некий канал, который никак не используется в ""нормальных"" ситуациях, а предусмотрен на случай проведения каких-либо ""аварийных"" работ. Канал, который не находится в работе, легко непреднамеренно ""сломать"" в процессе различных изменений конфигурации, и не заметить этого. Будет очень печально, если на момент наступления таких работ окажется, что аварийный канал не работает. Поэтому требуется регулярная проверка исправности такого канала. Возникла идея - возложить такую проверку на саму аппаратуру. Мне видится несколько возможных вариантов проверки исправности канала (в зависимости от его типа и характера): передача в канал некоего сигнала (гармонического для речевых каналов, цифрового для цифровых) и прием этого сигнала на выходе канала. Периодичность посылки должна настраиваться - раз в час, раз в сутки и т.п. Период должен быть достаточно большим чтобы не мешать нормальному использованию канала. Если приемник не ""увидел"" сигнал в течение двух интервалов (тоже, наверное, можно настраивать), формируется предупреждающее сообщение (придумать как и какое). Сигнал не должен быть очень простым, чтобы не было ложных положительных срабатываний, но и не должен быть слишком сложным, чтобы легко был реализуем средствами ПЛИС. Как вариант, последовательность тональных посылок нескольких определенных частот определенной длительности... Предлагаю обсудить детали возможной реализации и степень полезности этой функции." alx 306 Прятать лишние вкладки web-интерфейс (sw) 2 очередь улучшение alx new 2017-11-16T20:01:51+05:00 2020-04-15T12:03:38+05:00 "Предлагаю дать пользователю возможность скрыть ненужные ему вкладки из окна веб-морды. Например вкладка CDR может быть ненужной, если в блоке нет платы VE, а вкладка Сервис используется обычно только при неполадках и т.д. .. Предлагаю где-нибудь, например на вкладке Разное, разместить набор чекбоксов для выбора нужных/ненужных вкладок. Предлагаю хранить набор выбранных вкладок в ПЗУ блока." san 97 Предложение: хранить в плате sw-01 запасные конфигурации swd Как-нибудь потом задача alx new 2015-03-17T17:27:17+05:00 2017-11-17T13:29:18+05:00 "При выгрузке конфигурации, кроме носителей подключеных к ПК предусмотреть ещё выгрузку во внутреннюю память sw. Название конфигурации должен задать пользователь(например, это может быть имя файла, или как угодно) ну и соответственно при загрузке конфигурации в блок, дать возможность выбрать и из конфигураций во внутренней памяти" san