Доброго дня всем! Сегодня появилась странная проблема - все трубки DECT начали отваливаться на непродолжительное время от базовых станций. Трубка отваливается, на экране пишет типа "нет базового блока", потом через пару секунд снова все становится нормально. Трубки отваливаются регулярно, примерно раз в минуту. Когда трубка отвалилась на нее звонки не проходят. Но при этом если по трубке начать разговор, то никаких разрывов связи, щелчков, помех или иных проблем нет. Можно говорить без проблем столько, сколько нужно. На базовых станциях BS4 никакой аномальной индикации нет. В момент, когда трубка отваливается и затем перерегистрируется, моргает зеленый светодиод как при нормальной активности. Проблема появилась сама по себе. Работ не делали, конфигурацию не меняли. Перезагрузка станции ситуацию не исправила. С чем это может быть связано и как диагностировать проблему?
В станции 2 платы SLCN, проблема проявляется при нахождении в зоне любых базовых станций, подключенных и к одной, и к другой плате...

Синхронизацию на станции смотрите.
Если включены по потоку - ищите проблему у провайдера.

Синхронизацию на станции смотрите.
Если включены по потоку - ищите проблему у провайдера.

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

Синхронизация в приоритете всегда берется с потока. Если потока нет – тогда со встроенного генератора (модуль CMS, если он у вас есть).
То, что вы указываете, очень похоже на проскальзывания у провайдера.
Посмотрите, что в логе событий станция пишет, это может как-то объяснить происходящее.

Синхронизация в приоритете всегда берется с потока. Если потока нет – тогда со встроенного генератора (модуль CMS, если он у вас есть).
То, что вы указываете, очень похоже на проскальзывания у провайдера.
Посмотрите, что в логе событий станция пишет, это может как-то объяснить происходящее.

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

Синхронизация в приоритете всегда берется с потока (который в режиме slave).
От кого в данный момент станция получает синхронизацию – смотрите на закладке Card status ->Clock ref.
Вы можете указать список разрешенных источников синхронизации на закладке: Lines/Network->ISDN parameters. Там список разрешенных и запрещенных источников синхронизации.
Синхронизировать нужно по иерархической схеме от наиболее стабильного источника.

А если в Lines/Network->ISDN parameters в разделе источников синхронизации ничего кроме портов карты DIUN2 выбрать нечего, то о чем это говорит? Что у нас нет модуля CMS и что более реально неоткуда взять синхронизацию? У нас с этой станцией чудеса какие-то творятся, хотелось бы их расколдовать. Собственно почему мы отключили потоки из-за того, что потоки стали зависать. Поработают некоторое время, потом зависают порты. Есть ощущение, что корень обоих этих проблем один. Осталось только понять, где именно он кроется

Модуль CMS это S30807-Q6928-X.
В Менеджере его не увидите, он устанавливается на процессор.
Ищите его в спецификации на вашу станцию или смотрите, есть ли плата CMS на процессоре.
Это генератор, он нужен, если DIUN2 работает мастером или для SLCN.
Еще раз замечу: если на станции один из потоков работает в slave, синхронизация будет браться с него.
Проблема с DECT у вас связана с платой DIUN2, раз потоки зависают. Смотрите логи, почему потоки зависают.
Замените плату DIUN2 или физически выньте ее из станции для проверки наличия проблемы без нее.

В Менеджере его не увидите, он устанавливается на процессор.
Маленькая ремарка, все установленные модули на процессоре можно увидеть через менеджер в меню: System Status ->System-wide -> Cards ->Designation and code no.: при выборе 6-го слота с процессором. Таким же образом можно увидеть наличие модуля RGMOD, выбирая при этом модуль SLMA.

Все дополнительные модули установленные на процессорный модуль можно посмотреть и с помощью менеджера. Заходим в закладку Sistem-wide/cards-sistem expansion hardware-кликаем лев.кл. мышки на процессорный модуль на картинке станции. и в внизу в Card data нажимаем на кнопку(справа от кода модуля) в открывшемся падающем окне видим все доп модули установленные на процессоре.

А если в Lines/Network->ISDN parameters в разделе источников синхронизации ничего кроме портов карты DIUN2 выбрать нечего, то о чем это говорит? Что у нас нет модуля CMS и что более реально неоткуда взять синхронизацию?
Если бы у вас не было модуля CMS, то на каждой базовой станции было бы не более двух одновременных разговоров - если я не ошибаюсь ;)
Как вариант можно попробовать поменять модуль CMS на заведомо исправный.
Если нет никаких "секретных" настроек, то покажите кдс - может кто нибудь увидит, что Вы не видите, иногда так бывает. :cool:
Да и проверьте правильное распределение лицензий на БС. :o

Если нет никаких "секретных" настроек, то покажите кдс - может кто нибудь увидит, что Вы не видите, иногда так бывает. :cool:
Да и проверьте правильное распределение лицензий на БС. :o

КДС во вложении. Увидел, модуль CMS установлен. К сожалению заведомо исправного модуля у нас нет, видимо эту задачу придется делегировать подрядчикам за денежку...

установленные модули на процессоре можно увидеть через менеджер в меню: System Status ->System-wide -> Cards ->Designation and code no.:
Я как-то не обращал внимания на выпадающий список. Что-то новое узнал, спасибо.

Физическое вынимание платы потоков из станции дает тот же результат, что при отключении обоих потоков от платы, установленной в станции - начинают отваливаться dect трубки. При хотя бы одном подключенном потоке трубки отваливаться перестают. Правда сам поток при этом работает очень не долго. Каков предварительный вердикт? Подозрение на глюк модуля CMS? От глючного модуля CMS может зависать потоки платы DIUN?

В логах система какие-то сообщения выводит?
Может проблема и с модулем CMS. Т.к. без потоков синхросигнал берется с него.
Обесточьте станцию и снимите его с процессора. Попробуйте без него запустить.

В логах система какие-то сообщения выводит?
Может проблема и с модулем CMS. Т.к. без потоков синхросигнал берется с него.
Обесточьте станцию и снимите его с процессора. Попробуйте без него запустить.

Если я запущусь без этого модуля, то какие меня ждут проблемы потенциальные? Ограничение до 2-х разговоров на базу DECT? Или вообще останется работать только одна плата SLCN? В конфиге надо что-то будет менять перед выниманием и перед установкой модуля обратно или станция сама адекватно изменение конфигурации железа отработает?

В логах ничего необычного нет.

Просто снимите модуль CMS и запустите без него.
Насчет ограничения на количество разговоров без CMS не знаю.
Я считал, что это дополнительный генератор стабильного синхросигнала.
Но Siemon пишет об этом(ограничении).

Физическое вынимание платы потоков из станции дает тот же результат, что при отключении обоих потоков от платы, установленной в станции - начинают отваливаться dect трубки. При хотя бы одном подключенном потоке трубки отваливаться перестают.
Забавный эффект... :(
Ну, что пойдём по приборам, методом исключения, с бубном в руках. :o
По кдс видно, что синхронизация берётся сначала с DIUN2 1-1, потом с DIUN2 1-2, попробуйте поменять их местами или отключить синхронизацию, например с DIUN2 1-1, но оставить синхронизацию с DIUN2 1-2. Комбинируйте с этими настройками вплоть до полного их отключения.
Не пренебрегайте советам от explorer.
Запустите без CMS модуля, особых проблем не будет, но желательно при минимально нагрузке на БС, т.е., в нерабочее время офиса.
По тайм слотам перегрузки в первом кабинете нет, даже не смотря на то, что контроллеры DECT стоят в одной половине, да и зарегистрированных DECT абонентов у Вас не много. По тайм слотам во втором кабинете есть не большая перегрузка с 11 по 16 слот.
Полностью снимите питание со станции, отключив аккумуляторы от 3-й LUNA2, главного бокса. Аккумуляторы пока не подключайте, во время проведения экспериментов. ;)
Манипуляции с процессором проводить только при ПОЛНОСТЬЮ отключённом питании. :)
Пока так, отпишитесь по итогам, самому интересно, но всё же мне кажется, что дело в CMS... :cool: Не исключаю, что CMS модуль, не работая(предположительно) у Вас в станции, прекрасно заведётся в другой станции.

Провангую, что на 3800 при снятом ЦМС кордлесс не поднимется.
99%, что нужно менять ЦМС.
Судя по всему рассматривается вариант "чтобы сделать, чтобы ничего не
делать". Могу дать совет- снимите все галочки синхронизации. Но могут появиться проблемы с факсами и связке встречная АТС- трубка DECТ.
Ну и в порядке флуда. А что, проблема поменять ЦМС под "гарантийное
письмо"?

Провангую, что на 3800 при снятом ЦМС кордлесс не поднимется.
99%, что нужно менять ЦМС.
Судя по всему рассматривается вариант "чтобы сделать, чтобы ничего не
делать".

Ну зачем же Вы так говорите? У меня задача сделать связь надежной, поэтому проблему в любом случае буду решать. Только перед тем как что-то сделать я стараюсь получить максимум информации.
Теперь по сути вопроса - CMS снял, все запустилось без нее. Есть ли ограничения - это будет видно. DECT заработал. К сожалению запустить станцию в нерабочее время я не могу, ибо офис работает круглосуточно. Сейчас буду смотреть, отвалятся ли потоки через некоторое время или будут работать. Если потоки будут работать, то признаём CMS неисправной. Если косяк останется, то потребуются еще предположения. Просто по сименсу трудно делать замену на заранее исправное. Станция все же не супер популярная, запчастей не всегда можно быстро найти. Вариант запуска без модуля в данном случае идеальный и самый быстрый. Спасибо! Если поток отвалится, отпишусь сегодня, если не отвалится - отпишусь в понедельник :)

Прошу прощения не хотел обидеть.
Звонки с трубки на встречную (или дальше транзитом) ускорят Ваши тесты.

Потоки все таки зависли. Видимо таки проблема где-то еще... Теперь остается предполагать проблему и/или в DIUN2. Только вот заменить ее пока не на что :(

Расскажите нам, DECT то больше не отваливался без CMS?
По потокам, нужно сначала определить, после какого события они “зависают”.
Эта штука очень надежная, просто так не ломается. Смотрите лог ошибок на транках в Maintenance и CDR-лог звонков не лишним тоже посмотреть, что там происходит.
Может проблема оказаться не со станцией, а с системой передачи или с встречной, которая работает мастером.

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

Расскажите нам, DECT то больше не отваливался без CMS?
По потокам, нужно сначала определить, после какого события они “зависают”.
Эта штука очень надежная, просто так не ломается. Смотрите лог ошибок на транках в Maintenance и CDR-лог звонков не лишним тоже посмотреть, что там происходит.
Может проблема оказаться не со станцией, а с системой передачи или с встречной, которая работает мастером.

С ДЕКТами проблема локализовалась - они начинали отваливаться ЛИШЬ тогда, когда все потоки от платы DIUN2 отключены (или же сама плата физически вынута из системы). После вынимания платы CMS я как-то побоялся отключать еще и потоки подумав, что системе неоткуда будет вообще брать синхронизацию. Даже при том, что потоки "зависли", но физически подключены - ДЕКТ не отваливается. Стоило потоки отключить - проблема с отваливанием ДЕКТА повторялась.
Вот логи транков:
29.09.2016 12:37:49 30-123 DIUN2 1 - 1 - 1 Timeout error in data
29.09.2016 12:37:49 21-05 DIUN2 1 - 1 - 1 Port in service
29.09.2016 12:37:49 30-123 DIUN2 1 - 2 - 1 Timeout error in data
29.09.2016 12:37:49 21-05 DIUN2 1 - 2 - 1 Port in service
29.09.2016 13:31:53 30-124 DIUN2 1 - 1 - 1 CRC error in data
30.09.2016 9:16:45 21-04 STMI2 20 - 3 - 1 Port out of service
30.09.2016 9:23:32 21-05 DIUN2 1 - 1 - 1 Port in service
30.09.2016 9:23:32 30-123 DIUN2 1 - 1 - 1 Timeout error in data
30.09.2016 9:23:32 30-123 DIUN2 1 - 2 - 1 Timeout error in data
30.09.2016 9:23:32 30-123 DIUN2 1 - 2 - 1 Timeout error in data
30.09.2016 9:24:04 30-51 DIUN2 1 - 2 - 1 UNEXP_MESSAGE
30.09.2016 9:26:15 21-05 STMI2 20 - 3 - 1 Port in service

Я здесь ничего плохого не вижу. При этом последний успешный звонок по потоку был сделан 01.10.2016 14:23:48.000. Проблема точно не в вышестоящей станции. Сейчас к потокам сименса подключена авайя IP Office 500, а раньше потоки сименса были подключены к провайдерским потокам (несколько провайдеров) - зависания были и раньше. На авайе в то время, когда потоки зависают, я вижу статус, что линия не работает. Т.е. если я правильно понимаю, то проблема ISDN L1?

Собственно станцию я перезапускал 30.09.2016 9:18, так что сообщения в логах относятся к рестарту

Здесь пока можно сделать один вывод: CMS неисправен.
Станцию целиком перегружать не нужно, можно только DIUN2.
Лог ошибок на транках нужно получить в момент зависания.
Дальше много неясного в структуре вашей сети, чтобы предположить, где источник проблемы с потоками.

Это сообщение говорит, что есть ошибки в системе передачи:
29.09.2016 13:31:53 30-124 DIUN2 1 - 1 - 1 CRC error in data

Может DIUN2 здесь и не при чем.
Переведите каналы в режим без проверки CRC4, понаблюдайте, останется проблема с потоками или нет.

Здесь пока можно сделать один вывод: CMS неисправен.
Станцию целиком перегружать не нужно, можно только DIUN2.
Лог ошибок на транках нужно получить в момент зависания.
Переведите каналы в режим без проверки CRC4, понаблюдайте, останется проблема с потоками или нет.

Не уверен теперь на счет CMS. Без него зависание потока не прекратились. Так что он может быть в равной степени исправен или нет.

Лог ошибок на станции в момент зависания - это крайне проблематично. Момент зависания не предсказуем. Я благодаря автоматическому переключению маршрутов обычно спустя несколько часов узнаю о том, что потоки зависли. На Авайе у меня кстати настоена отправка трапов по снмп когда что-то с транками происходит. Дык мониторинг даже частенько вообще молчит. Но поток при этом перестает работать. Он тихо вырубается...
Без CRC сейчас включу потоки. Правда сомневаюсь, что это что-то изменит.
Следующий шаг буду делать - замена платы потоков на исправную, сейчас как раз договариваюсь...

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

В момент зависания платы потоков в логе такая ошибка:
04.10.16 15:20:04 30-124 DIUN2 1 - 1 - 1 CRC error in data

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

Видимо, CRC4 у вас не выключен на станциях. Поэтому и пишет в лог.
Нужно менять с обоих сторон: на HiPath сменить протокол и на Avaya.
Или разбираться, почему в системе передачи ошибки.
Последнее будет правильнее.