Помогите пожалуйста советом. От тех.поддержки получил рекомендацию исправить ошибки БД станции воспользовавшись утилитой fichges с ключами recover dico и recover all. Тех.поддержка предупредила, что процедура опасная, возможно тотальное разрушение БД. В этой связи решили не рисковать и работы проводить в выходной день.
После выполнения команд постоянно сыпались сообщения типа
Позвонил в тех.поддержку. Они сообщили, что это нормально. Якобы несмотря на ошибку таблица пересоздается заново. Но у меня есть сомнения на этот счет.
Будьте добры, проконсультируйте по вопросу использования данной утилиты. Что конкретно она делает (действительно пересоздает БД, или только переиндексирует существующие таблицы БД)? Насколько она опасна и были ли прецеденты крушения БД? Действительно ли нормально появление сообщений об ошибке открытия файлов?
Большое спасибо!
Проблемы с подсистемой DECT при bascul, Нестабильная работа
При переключении работы с одного процессора на другой наблюдаем странности. Пару недель назад отключились некоторые трубки DECT - пришлось их перерегистрировать. Возможно, это связано с некогерентностью баз. Вчера тестировал станцию, предварительно проведя клонирование.
Во-первых, обратил внимание, что даже после клонирования, процессоры видят DECT базы IBS на выносе (подключен через INTOF) по-разному: основной процессор видит их нормально, как 6-канальные устройства, резерв при этом видит их как 3 канальные базы. После bascul оба процессора стали видеть их как 3 канальные базы. Одновременная перезагрузка обоих процессоров вернула все в исходное состояния: основной видит 6-канальные устройства, резерв - 3х канальные.
Странно, но после перезагрузки выноса путем rstcpl INTOF-платы выноса оба процессора стали видеть базы нормально.
Во-вторых, даже когда удалось добиться того, чтобы оба CPU видели базы как 6-канальные устройства, после выполнения bascul выявился следующий "косяк": при попытке дозвониться на трубку DECT, которая находится в спящем состоянии со своей трубки получаю в ответ на своей трубке сообщение Feature rejected. На стационарном аппарате короткий гудок, как будто трубку вовсе отключена. Но стоит эту трубку пробудить, т.е. либо физически к ней подойти и нажать любую кнопку, либо позвонив на тандемный стационарный аппарат (при его наличии), после чего входящие вызовы на нее начинаю проходить. Ситуация казалась крайне неприятной, т.к. проверку проводил в выходной день, когда большинства сотрудников не было на рабочих местах. Ожидал, что в понедельник начнет шухер.... Позже выяснил, что минут через 15 на спящие трубки могу-таки дозвониться. Это нормальная история?
P.S. Хочу еще добавить, что при переключении CPU в логах фиксируются инциденты типа
Код
06/06/15 11:23:54 000003S|000/15/-/---|=3:2040=Std By CPU. Bad term type = DECT_BS instead of POS_NUM Msg 7 n_term 0
Подскажите пожалуйста. На станции периодически появляются инциденты
Код
27/06/15 12:15:18 000003M|---/--/-/---|=0:1603=IO1 driver error, wrong telephone msg received, line 1451, position (0,13,254)
27/06/15 12:15:18 000003M|---/--/-/---|=3:1607=01.0d.0d.00.00.00.00.0d.04.fe.f9.00.15.ff.ff
Является ли увеличение частоты данных инцидентов признаком того, что базы на двухпроцессорной системе разъехались и необходимо выполнять клонирование?
Спрашиваю потому, что недавно переводили работу bascul-ом на резервный процессор, не обратив внимание на наличие данных инцидентов, после чего приличное кол-во трубок DECT отвалились (просто белый экран на трубках). После отключения трубок пришлось их регистрировать заново. Причем что интересно, команда dectrm для них не отрабатывала, ссылаясь на то что аппарат не является cordless.
Спасибо!
Не удается изменить приоритет синхронизации, На плате INTOF не меняется приоритет
Коллеги, правильно ли я понимаю, что ничего такого "криминального" в текущей конфигурации нет? Т.е. какого-то параметра настройки, который был не задан надлежащим образом подрядчиками и о котором я не знаю, вроде как нет?
Цитата
vad пишет: Но все равно - проверьте - хорошо ли подсоединены патч-корды и т.п.
Понял, спасибо. Всё проверю. Возможно имеет смысл также сделать замеры трассы рефлектометром - тоже займусь. Платы тоже попробую поменять.
Цитата
error пишет: 1. Плата pri в слоте 0-0 совместно с intof вещь коварная
К сожалению, тут уже сложно что-то изменить. Привязка к существующей схеме, отсутствие SIP-E1 конверторов, наличие проектной документации, которую у нас любят проверять различные аудиторы - все это связывает руки.
Цитата
error пишет: 2. синхра для дект откуда берется с проца или dect8
Если нетрудно, сообщите пожалуйста, где это посмотреть? CPLSTAT?
Цитата
error пишет: 3. Стоит руками времени перезапустить синхру дект (а еще лучше сам дект) и посмотреть на через сколько времени опять инцинденты поползут
Попробую сделать.
Цитата
error пишет: 4. Я сторонник физического изолирования pri если есть дект. Изолирование pri по схеме pri-sip-pri, так по крайне мере можно избавится от кривизны часов прова
Вот насчет часов прова хотелось бы сделать несколько уточнений. На самом деле поток E1 на порт 0-0 платы NPRAE к нам приходит не напрямую от провайдера, а через наше же оборудование SDH. Т.е. на площадке оператора стоит наша железка Cisco ONS 15305, в которую в том числе включен поток E1 ГТС. Далее с этой железки к нам через SDH кольцо приходит поток STM1, из которого уже в нашем здании вытаскиваются различные E1, в том числе поток ГТС. Источником синхронизации всей системы задан именно поток ГТС, который приходит в ONS на площадке оператора. Другие потоки, вынимаемые у нас и подключаемые к сети передачи данных, по сути, также синхронизированы от данного потока ГТС. Сеть передачи данных работает штатно. Каких-либо проскальзываний не наблюдается. Я думаю, что если бы была некачественная синхра от провайдера, наверное, на СПД это сказалось бы в первую очередь?
И еще насчет качества синхры... Правильно ли я понимаю, что у провайдера нет какой-то особенной настройки типа "отдавать синхру" или "не отдавать", т.е. он передает обычный TDM поток. В этом случае, насколько корректным является обращение к провайдеру с просьбой проверить, улучшить качество передаваемого потока? Можно ли вообще как-то определить качественность определенного потока: выполнить какие-то замеры и т.д., чтобы не ориентироваться по косвенным признакам типа сигнала SYNC на плате станции?
Спасибо!
Не удается изменить приоритет синхронизации, На плате INTOF не меняется приоритет
Почему-то в нем вообще нет информации о выносе, подключенном по INTOF. К основной полке подключен также вынос по INTIP - о нем, как видно из вывода команды, информация присутствует.
Выкладываю также вывод config all:
Код
(3)xa000000> config all
Thu Apr 16 13:04:20 AST 2015
Crystal 0 :
+-------------------------------------------------------------------+
| Cr | cpl| cpl type | hw type | cpl state | coupler ID |
|----|----|------------|-----------|--------------|-----------------|
| 0 | 0 | NPRAE|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 1 | eZ32|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 2 | NPRAE|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 3 | eZ32_2|---------- |ONLY OPS FILE | BAD PCMS CODE |
| 0 | 4 | GPA2|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 6 | CPU7_STEP2|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 7 | IO2N|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 8 | INTOF2A|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 9 | eUA32|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 10 | eZ32|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 11 | NPRAE|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 12 | eZ32|---------- | REG NOT INIT | BAD PCMS CODE |
| 0 | 15 | DECT8|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 17 | INTIPA| INT-IP | IN SERVICE | BAD PCMS CODE |
| 0 | 19 | NPRAE|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 20 | CPU7_STEP2|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 21 | IO2N|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 22 | BRA2|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 24 | INTIPA| INT-IP | IN SERVICE | BAD PCMS CODE |
| 0 | 26 | RMA|---------- |ONLY MAO FILE | BAD PCMS CODE |
| 0 | 27 | INTOF2A|---------- | IN SERVICE | BAD PCMS CODE |
+-------------------------------------------------------------------+
--- Inter Crystal Topology ---
+-------------------------------------------------------------------------+
| CR | CPL Type Role Free/Tot Role Type CPL | CR |
|-------------------------------------------------------------------------|
|000 | 08 -INTOF2A (INT_A ) === 78/78 === ( MAIN) INTOF2B - 20 |002 |
|-------------------------------------------------------------------------|
|000 | 27 -INTOF2A (INT_A ) === 77/78 === (STANDBY) INTOF2B - 06 |002 |
|-------------------------------------------------------------------------|
> Reference rack not set
Crystal 1 :
+-------------------------------------------------------------------+
| Cr | cpl| cpl type | hw type | cpl state | coupler ID |
|----|----|------------|-----------|--------------|-----------------|
| 1 | 0 | UA_FICTIF| | IN SERVICE | NO PCMS CODE |
+-------------------------------------------------------------------+
Crystal 2 :
+-------------------------------------------------------------------+
| Cr | cpl| cpl type | hw type | cpl state | coupler ID |
|----|----|------------|-----------|--------------|-----------------|
| 2 | 1 | eZ32_2|---------- | IN SERVICE | BAD PCMS CODE |
| 2 | 6 | INTOF2B|---------- | IN SERVICE | BAD PCMS CODE |
| 2 | 10 | eZ32_2|---------- | IN SERVICE | BAD PCMS CODE |
| 2 | 12 | eZ32_2|---------- | IN SERVICE | BAD PCMS CODE |
| 2 | 15 | NPRAE|---------- | IN SERVICE | BAD PCMS CODE |
| 2 | 17 | eUA32|---------- | IN SERVICE | BAD PCMS CODE |
| 2 | 20 | INTOF2B|---------- | IN SERVICE | BAD PCMS CODE |
| 2 | 22 | NDDI2|---------- | IN SERVICE | BAD PCMS CODE |
| 2 | 24 | eUA32|---------- | IN SERVICE | BAD PCMS CODE |
| 2 | 26 | BRA2|---------- | IN SERVICE | BAD PCMS CODE |
+-------------------------------------------------------------------+
--- Inter Crystal Topology ---
+-------------------------------------------------------------------------+
| CR | CPL Type Role Free/Tot Role Type CPL | CR |
|-------------------------------------------------------------------------|
|002 | 06 -INTOF2B (STANDBY) === 77/78 === ( INT_A) INTOF2A - 27 |000 |
|-------------------------------------------------------------------------|
|002 | 20 -INTOF2B (MAIN ) --- 78/78 --- ( INT_A) INTOF2A - 08 |000 |
|-------------------------------------------------------------------------|
Crystal 3 :
+-------------------------------------------------------------------+
| Cr | cpl| cpl type | hw type | cpl state | coupler ID |
|----|----|------------|-----------|--------------|-----------------|
| 3 | 0 | eZ32_2|---------- | IN SERVICE | BAD PCMS CODE |
| 3 | 2 | eUA32|---------- | IN SERVICE | BAD PCMS CODE |
| 3 | 4 | NDDI2|---------- | IN SERVICE | BAD PCMS CODE |
| 3 | 6 | INTIP3B| INT-IP3 | IN SERVICE | BAD PCMS CODE |
+-------------------------------------------------------------------+
--- Inter Crystal Topology ---
+-------------------------------------------------------------------------+
| CR | CPL Type Role Free/Tot Role Type CPL | CR |
|-------------------------------------------------------------------------|
|003 | 06 -INTIP3B (MAIN ) --- 7/7 --- ( INT_A) INTIP3A - 01 |019 |
|-------------------------------------------------------------------------|
Crystal 19 :
+-------------------------------------------------------------------+
| Cr | cpl| cpl type | hw type | cpl state | coupler ID |
|----|----|------------|-----------|--------------|-----------------|
| 19 | 0 | FICTIF| | REG NOT INIT | NO PCMS CODE |
| 19 | 1 | INTIP3A| | IN SERVICE | NO PCMS CODE |
| 19 | 2 | INTIP3A| | OUT OF SERV | NO PCMS CODE |
+-------------------------------------------------------------------+
--- Inter Crystal Topology ---
+-------------------------------------------------------------------------+
| CR | CPL Type Role Free/Tot Role Type CPL | CR |
|-------------------------------------------------------------------------|
|019 | 01 -INTIP3A (INT_A ) === 7/7 === ( MAIN) INTIP3B - 06 |003 |
|-------------------------------------------------------------------------|
(3)xa000000>
Настройки всех INTOF плат одинаковые и имеют следующий вид
Код
--Review/Modify: Board------------------------------------------------¬
¦ X ¦
¦ Node Number (reserved) : 3 X ¦
¦ Shelf Address : 0 X ¦
¦ Board Address : 8 X ¦
¦ X ¦
¦ Interface Type + INTOF2A ¦
¦ Virtual board + NO ¦
¦ Usage State + Unknown ¦
¦ Operational State + Enabled ¦
¦ Main/Standby State + Main (Master) ¦
¦ Number Of Sets Connected : 0 X ¦
¦ Remote Shelf Address : 2 X ¦
¦ Remote Board Address : 20 ¦
¦ Synchronization Priority : 255 ¦
¦ Country + Default ¦
¦ Incidents Teleservice + YES ¦
¦ X ¦
L----------------------------------------------------------------------
Бросается в глаза странный статус Usage State = Unknown.
Вынос подключен по оптике. В настоящий момент используется одна и та же трасса для обоих подключений, однако в ближайшем будущем для отказоустойчивости планируем переключить одно из соединений на другую трасса. Длина трасс около 2,5 км. Новая планируемая трасса около 3,5 км.
Спасибо!
Цитата
vad пишет: - внутри пары - можно поменять местами А и В платы (бывают нюансы)
Уважаемый vad, можно поподробнее, что вы имели в виду - поменять местами платы внутри основной полки (выноса), оставив платоместа теми же самыми? Или поменять платы между выносом и основной полкой?
Спасибо!
Не удается изменить приоритет синхронизации, На плате INTOF не меняется приоритет
Имеется станция OXE (R11) с выносом, подключенным через двойное INTOF подключение (по две платы на основной полке и выносе, одно из подключений MAIN, другое - STANDBY). На станции постоянно с периодичностью 2-5 минут возникает инцидент, о котором я уже как-то здесь писал, но ответа получить не удалось:
15/04/15 16:41:08 000003M|000/08/-/---|=0:3660=status of 8KFS (0 is OK, 1 is KO): 1 , value : 30 31 15/04/15 16:41:08 000003M|000/08/-/---|=0:3660=status of 8KFS (0 is OK, 1 is KO): 0 , value : 30 30
Обратил внимание, что когда общаешься с абонентом выноса, иногда проскакивают щелчки, кратковременно пропадает голос. Также понаблюдал визуально за платами INTOF. Действительно, в момент возникновения инциденота, примерно на одну секунду, загорается красным индикатор SYNC.
Стал более детально исследовать конфигурацию, и обнаружил, что в параметрах плат INTOF на выносе синхронизация выставлена в 255 (т.е. работать автономно). Вынос нас устанавливал подрядчик. Обратился к нему. Тот подтвердил, что эта настройка может быть причиной некорректной синхронизации и рекомендовал задать значения типа 10 на основной плате и 20 на резервной.
Подскажите пож-та, действительно ли данная настройка является причиной возникновения инцидентов?
Попробовал изменить приоритеты и ... не получилось - появилось сообщение об ошибке:
С чем может быть связан данный запрет и как его преодолеть?
Думал, что возможно, это связано с тем, что плата находится в состоянии INSERVICE. Хотел перевести ее в OUTSERVICE, но понял, что не знаю как это сделать. Пробовал варианты ouserv с различными ключами (например, outserv p 2 6 0 all - не отключает плату). Может ли состояние INSERVICE являться причиной запрета модификации? Ради проверки попробовал изменить приоритет на доступе работающей платы NPRAE - все изменяется без проблем.
Неужели проблема решается только пересозданием выноса? Если так, то что же делать с кучей абонентов, которые работают на этом выносе - ведь они насколько я понимаю, все удалятся? Восстановление из бэкапа тут не поможет.
Иногда возникает необходимость перерегистрации телефонных аппаратов DECT (используем модели 400 и 8232) на удаленной станции. При этом звонить пользователям и разъяснять как надо чистить EEPROM, а потом доходить до состояния running как-то нехорошо. Но и ехать на удаленную площадку ради одной двух трубок тоже невесело. Можно ли зная IPEI привязать трубку к станции без "перепрошивки" трубки? Может есть возможность как-то задать IPEI непосредственно в dectinston? Неужели администратор лишен возможности выполнения этой операции удаленно?
Спасибо!
Создание NDDI транка с подключением абонента напрямую, Аналог Cisco PLAR
Есть две станции OXE, соединенные по IP в единое ABC звено. На одну из станций приходит СО-линия, подключенная напрямую в обход станции к абоненту. В связи с организационными изменениями абонент переехал в зону действия второй станции. Ростелеком не может выполнить переключение старого номера СО-линии на площадку второго здания.
В этой связи есть мысль подключить СО-линию к имеющейся NDDI плате, создать соответствующий BCA транк, а на второй станции создать абонента. Вопрос: можно ли настроить станции таким образом, чтобы абоненту не приходилось набирать префикс занятия новой ТГ? Например, зная, что данный абонент особенный, и что он не может занимать другие ТГ, каким-то образом связать ТГ и абонента, так что при поднятии трубки для звонка в город станция автоматически коммутировала его на заданную ТГ?
Спасибо!
ABCF Logical Link over IP с несколькими платами INTIP
А по лицензиям сориентируйте пожалуйста. Если я правильно помню, то добавление одной из плат это что-то около 30 доступов? Указанные мной параметры H323 Virtual - 92, IP trunk - 92 это имеет отношение к задаче или это какие-то другие лицензионные ограничения? Если да, то я в IP транк могу включить 3 INTIP платы?
Коллеги, хочу вернуться к теме с трубками 8232. Иногда возникает ситуация, когда в сервисное меню по описанной выше методике не попасть. Например, если на станции дать dectrm, когда аппарат был выключен или находился вне зоны действия станции, то после этого экран аппарата показывает пустоту и никак на реагирует на какие-либо нажатия клавиш. Выключение-включения, вытаскивание аккумулятора не помогает. Обращал внимание, что после того как такую "зависшую" оставить на какой-то долгий промежуток времени (сутки), то потом она вроде бы как очищается. В старых трубках все просто - почистил eeprom и регистрируй себе заново. А что делать в описанноий ситуации?
Спасибо!
ABCF Logical Link over IP с несколькими платами INTIP
На станциях узла ABC сети создано по одной IP-транкгруппе. В состав транкгруппы включены доступы только одной из плат INTIP. Можно ли включить в транкгруппу плюсом доступы второй платы? Что будет со связью при отключении первой платы (насколько я представляю, текущие соединения разорвутся, но новые должны создаваться без проблем)?
Насколько мне известно, здесь могут быть проблемы связанные с лицензиями. На текущий момент spadmin показывает наличие H323 Virtual ... 92, и IP trunk тоже 92 - возможно данные параметры к данной задаче отношения не имеют.
В нашей организации эксплуатируется 7 станций OXE, объединенных посредством IP каналов в единое звено ABC. Так уж случилось, что на некоторых станциях значения PARI/PLI одинаковые. При этом роуминг корректно работает. Есть подозрение, что где-то этот недочет может всплыть, но где? Не отработает audit? Не смогу регистрировать трубки удаленно? Ведь если все работает в одинаковым значением PARI, то вообще теряется смысл правил назначения PARI - можно просто на вех станциях установить одно и то же значение и все будет работать.
Спасибо!
Низкая скорость модемного подключения, Для внутренних аналоговых абонентов скорость подключения - 9200 бс
error пишет: вообще-то "звонить с ГТС" и "звонить через ГТС" это не одно и тоже, догадайтесь с двух раз
Прошу прощения, может действительно туплю. Но я же писал:
Цитата
Vladimir Shushkov пишет: Да, эксперимент проводил на одном ноутбуке. В одном случае включал просто в городскую сеть - всё ок. Во втором - на внутренний номер станции. Причем в этом случае при звонке по короткому номеру (к примеру, 1000) и при выходе на городскую линию через префикс с возвратом на тот же модемный пул (9 721000 - 9 - выход на город, 721000 транслируется в 1000) один и тот же негативный результат.
Насколько я понимаю (если не так, то прошу поправить), то "включал просто в городскую сеть - всё ок" - это звонить с ГТС, а "и при выходе на городскую линию через префикс с возвратом на тот же модемный пул" - это звонить через ГТС. Так? Если так, то как я и писал выше, данный эксперимент был проделан неоднократно.
Цитата
error пишет: я так думаю что у вас did из гтс в сторону cisco сделан ссылкой на TG
Сделано так: 721000 транслируется DDI транслятором в префикс 1000, значение которого есть speed dial. В параметрах speed dial прописан номер вызова C4001000; в префиксах C400 соответствует префиксу занятия TG смотрящей на Cisco.
Цитата
error пишет: направление 721000 у вас через что сделано?
Направление через ARS. В ARS роуте действительно были указаны только voice и fax. Добавил третьим значением unrestriced digital. Снял опять трассировку в сторону Cisco после звонка через ГТС (т.е. после набора 9 721000). Bearer Capability изменился на нужный 9090a3, однако скорость соединения по прежнему 9600.
Цитата
error пишет: TG в циску как смотрит network mode
Циска берет синхронизацию со станции.
Цитата
error пишет: infocs что показывает
Сейчас на руках точных данных нет. Но пару дней назад, когда проблема уже имела место, infocs показывал состояния synchonized. Синхронизация берется с того самого городского потока. Кстати, сказать, на синхронизацию у меня есть серьезные подозрения, т.к. есть другие проблемы (инциденты связанные с выносом INTOF, которые якобы намекают на плохую синхру; по этому поводу я уже задавал здесь вопрос, но пока так и не нашел ответа).
Еще хочу уточнить следующий момент. На самом деле, для отказоустойчивости у нас развернуто две Cisco. Имеется две территориально разнесенные станции, которые соединены между собой по ABCF через IP. Номер 721000 приходит на проблемную станцию (1), о которой сейчас ведем речь, а номер 722000 - на другую (2). Так вот, когда я, являясь абонентом станции 1 звоню через ГТС на эту же станцию - все плохо. А когда звоню на 9-722000 - соединению устанавливается на скорости 46 кбс.
Цитата
Андрей пишет:
Почитал про bearer capability, более менее понятно, спасибо. Сразу же решил проверить настройки ARS, о которых писал выше. Понятно, на основании чего данный параметр может выставляться когда я звоню через ГТС. Но откуда он берется когда я звоню по короткому номеру???
