Имеется станция OXE с дублированными CPU, двумя платами INTIPA. В настоящее время все подсоединено к одному коммутатору уровня доступа. Для построения ABCF over IP, подключения одного IP-выноса и подключения IP-телефонов используется только одна из плат (доступы созданы только для одной INTIP платы). Вторая, видимо (до конца не уверен), не используется, хотя IP адрес на ней прописан.
Есть желание разнести процессоры и платы по разным коммутаторам уровня распределения-ядра, повысив в целом отказоустойчивость платформы.
Включен взаимодействие процессоров по Ethernet вместо C1. Планирую отключить embedded ethernet и переключить физически процессоры на разные коммутаторы. Ознакомился с разделом IP Redundancy документации Alcatel. Не пойму, какие должны быть предварительные настройки второй IP платы, чтобы она могла на себя брать функционирование, в случае отключения первой платы? Должен ли я помимо IP адресов еще что-то настраивать? Например, для IP транк-группы создавать и указывать доступы для второй платы?
Большое спасибо!
Не собираются тарификационные данные, Не собираются тарификационные данные с использованием MOXA
После временного отключения от станции OXE MOXA и последующего подключения в первоначальное состояние (спустя несколько дней) перестала сниматься тарификация со станции. Используется следующая структура
OXE (ttyS2) -> CBRMA (Port C) -> (COM Port 1) MOXA (Ethernet) -> LAN-IP -> Server (Barsum Enterprise)
В параметрах Accounting сказано собирать RealTime tickets через V24. В параметрах V24 (System -> V24 port) следующие данные
На MOXA выставлены аналогичные параметры. Проверял выдачу CDR-тикетов подключением с помощью нуль-модемного кабеля напрямую к порту C CBRMA ноутбука - записи выдаются. Для подключения станции к MOXA использую кабель прямого типа. В мониторинге MOXA показывает неизменяющееся нулевое значение входящих данных. С выхода MOXA по IP тоже естественно ничего нет. В IP-сети MOXA настроена как TCP-сервер, а сервер тарификации как TCP-клиент.
Подскажите пожалуйста, в чем может таиться причина проблемы.
Одна из станций в удаленном филиале подключена к ГТС через NDDI2. При звонке на один из номеров слышу в ответ три очень коротких гудка затем паузу (т.е. 1я секунда - три гудка, 2я секунда пауза). При этом телефон абонента не звонит. Сопряжение транк-группы для данной линии с аппаратом абонента реализовано через группы искания hunt-groups, т.е. в параметрах транк-группы сказано звонить на номер HG, в составе которой состоит один абонент. Первоначально думал, что просто зависла плата. Пробовал ее перезагружать - бесполезно. На место еще пока не выезжал, саму линию до ГТС не тестировал, но возможно придется.
Подскажите пожалуйста, есть ли какие-то данные относительно указанного типа КПВ. Может ли (и если может, то что именно) некорректная настройка станции являться причиной данного КПВ?
Иногда, при возникновении каких-нибудь "глюков" с аппаратами используем простую процедуру пересоздания абонента. Проблема в том, что некоторые абоненты, типа секретарей, имеют очень большой перечень настроенных клавиш.
Можно ли как-то сохранить эту конфигурацию и применить ее затем на вновь созданного абонента? Можно ли это сделать средствами mgr? Можно ли это сделать средствами OmniVista 4760? И самое главное как (в двух словах)?
Большое спасибо!
Изменение временных зон, Перевод стрелок на зимнее время
Подскажите, кто что будет делать в этом плане? Может есть какие патчи? Дело в том, что у нас несколько станций и релизы рознятся от 8-й до 11 версий.
Планируем по-старинке изменить зону Etc-4 на Etc-3 (живем по московскому времени). Подрядчик-же не рекомендовал настройки типа Etc, сославшись на возможные "косяки", сказал, что желательно ставить зону Moscow. Но, я так понимаю, в наших условиях с этой настройкой будет полная чехорда: какие-то станции будут автоматически переводить время на летнее-зимнее два раза в год, какие-то останутся на летнем и т.д.
Нужно добавить, что станции берут временные метки по NTP.
Какие у Вас планы на ближайшие выходные в этой связи?
Спасибо!
Инциденты 3660 в большом количестве, Постоянно с периодичностью чаще одного раза в минуту регистрируются события
Прошу Вашей помощи. После установки выноса в удаленном офисе на основном узле постоянно фиксируются события
0:3660 = status of 8KFS (0 is OK, 1 is KO): 0, value: 3029 0:3660 = status of 8KFS (0 is OK, 1 is KO): 1, value: 3028
Эта пара событий с 0 и 1 повторяется примерно раз в минуту или чаще. К основному узлу уже был подключен один вынос по IP через связку INTIPA - INTIPB. Пару месяцев назад подключили еще один вынос по оптике, но в этот раз через связку INTOFA-INTOFB. На всех площадках имеется DECT (может быть связано с ним), но на основной площадке используем RBS c платами DECT8 , а на удаленных IBS и соответственно eUA32.
Стоит также отметить, что второй вынос подключен сразу двумя линками INTOF, т.е. в основном узле установлены две платы INTOFA, которые разными оптическими трассами подключены соответственно в две платы INTOFB выноса.
В описании инцидента рекомендуется перезагрузка платы INTOF. Перезагружал поочередно обе. При перезагрузке первой инциденты продолжаются фиксироваться со ссылкой на вторую плату. При перезагрузке второй - все наоборот.
Подрядчик, который ставил вынос, уверяет, что в данном случае линки просто резервируют друг друга, т.е. по факту используется только один линк, а второй просто простаивает, ожидая, когда умрет первый. Также подрядчик отметил, что какой-либо петли в этой топологии (по аналогии с Ethernet) возникнуть не может.
На вопрос относительно инцидентов, подрядчик объяснил проблему плохим качеством потока E1 с ГТС. Дело в том, что основная полка подключена к ГТС по E1 через наше же оборудование SDH. Согласно слов подрядчика, некачественный поток E1 не позволяет кристаллу нужным образом синхронизироваться. Также, с его слов, отключение синхронизации узла с E1 устраняет проявление указанных инцидентов.
Хочу услышать Ваше мнение относительно причин возникновения инцидентов, способов борьбы с ними, а также корректности предположений подрядчика.
Большое спасибо!
S0 bus exists, При смене типа аппарата или удалении
Одному из пользователей вместо цифрового аппарата решили установить IP Touch. Сделали все не путем удаления-создания, а с помощью изменения типа с цифрового на IP (IP аппарат изъяли у другого пользователя, которому наоборот поставили цифровик, так же путем изменения типа). Подключили телефон и обнаружили, что аппарат постоянно уходит в перезагрузку после последнего 5-го этапа. При этом на станции телефон "пророс" в том плане, что у него появились MAC и IP адреса в TSC/IP свойствах.
На станции при этом регистрируется инцидент 3:0377=ip phone init incident Not an ip set
Решили пересоздать абонента, удалив его для начала. Однако удалить абонента не удается - появляется ошибка Object -1: Attribute 0: S0 bus exists. Изменить тип аппарата назад на цифровик также не получается - та же самая ошибка.
Прошу помочь в разрешении тупиковой ситуации: 1. Почему аппарат может постоянно уходить в перезагрузку с регистрацией указанного инцидента? 2. Как все-таки удалить абонента в условиях возникновения указанной ошибки?
Большое спасибо!
Не регистрируются пропущенные вызовы, На цифровом телефоне не отображаются пропущенные звонки
Помогите пожалуйста.Некоторые пользователи жалуются на то, что на их телефонах не регистрируются пропущенные звонки. Вот, в частности, сегодня поступила заявка по данной проблеме. У абонента цифровой аппарат. Обратил внимание, что по downstat t -> 4 отображается два аппарата, в том числе принадлежащий данному юзеру
Код
Your choice ? 4
*** IPTOUCH-A(4019) TDM : soft : 3.81.00
*** IPTOUCH-B(4029) IPTOUCH-C(4039) TDM : soft : 3.81.00 - data : 3.81.00
*** Download time optimization: FOR EACH SET
** 32 IPTOUCH TDM phones are declared on this node !!
** 1 IPTOUCH TDM phones are not updated with the right binary !!
** 0 IPTOUCH TDM phones can be reseted for update !!
| IPTOUCH TDM out of order
+----------+-------+-------------+-----------------+--------+--------------+-------------------+------------+
| QMCDU | Neqt | Cry/Cpl/Trm | Name | Type | Dw Policy | Custo | Local |
+----------+-------+-------------+-----------------+--------+--------------+-------------------+------------+
| 3204 | 00588 | 0/ 9/ 1 | Ivanova T.V. | IPTOUC | DELAYED | | chi2.01.01 |
| 3117 | 00598 | 0/ 9/11 | Petrov | IPTOUC | DELAYED | N/R | N/R |
+----------+-------+-------------+-----------------+--------+--------------+-------------------+------------+
Total IPTOUCH TDM Phones out of order 2
IPTOUCH TDM phone downloaded informations :
-------------------------------------
1 Display up to date IPTOUCH TDM phones
2 Display IPTOUCH TDM phones not yet updated
3 Display download in progress
4 Display out of order IPTOUCH TDM phones
5 Display all IPTOUCH TDM phones
0 Quit
Может ли это быть причиной проблемы? Что за статус у аппарата DELAYED (отложенный, кто или что его отложило)? Как можно устранить данную проблему? Пробовал перезагрузить плату eUA32, к которой подключен аппарат - не помогло.
Просветите пожалуйста на тему сертификации инженеров ACFE/ACSE. Какие предварительные требования к сертифицируемому? Необходимо ли предварительное обучение? Сколько нужно сдать экзаменов, какие, сколько стоят? Где можно сдавать экзамены (PearsonVUE, Prometric)? Что из себя представляет экзамен: тест или лабораторная? Сколько времени и какое кол-во вопросов? Каков проходной балл?
Большое спасибо!
О влиянии hunt группы на доступ к внешним сетям, При указании HG не удается позвонить на межгород
Есть абонент с определенным Public network COS, согласно которому в соответствии с правилами дискриминатора и зон ARS, данному пользователю разрешены звонки на межгород.
Как только прописываю абоненту hunt-группу при наборе первых цифр междугороднего вызовы идет отбой с сообщением "Функция отклонена"
Может ли как-то влиять (и если может, то как) задание hunt-группы на правила дискриминатора?
Спасибо!
Инциденты DECT, Инциденты после изменения PARI PLI
Для того чтобы работал Distant Mobility пришлось на одной из станций поменять PARI/PLI значения, для приведения в соответствие с другими станциями. После изменения естественно поотваливались все трубки. Зарегистрировал их заново. Возможно небольшое число трубок осталось неперерегистрированными (работники в отпусках). Плату DECT и станцию не перезапускал, т.к. вроде и так все нормально работало. Сегодня обратил внимание на множество инцидентов с источником DECT:
Код
08/05/14 06:21:12 000004M|000/02/-/---|=4:3841=DECT8 WINDI software anomaly {2 b 0 3f 18 1e 0 0 0}
08/05/14 06:22:16 000004M|000/02/0/004|=5:1381=DECT (CTM) Radio Fixed Part put in service: cspver 24 bsver 83
08/05/14 06:22:47 000004M|000/02/0/004|=3:1378=DECT (CTM) loss of base station: cspver 24 cause 1 param 255 bsver 255
08/05/14 06:22:52 000004M|000/02/-/---|=4:3841=DECT8 WINDI software anomaly {2 b 0 53 3d 1e 0 0 0}
08/05/14 06:23:52 000004M|000/02/-/---|=4:3841=DECT8 WINDI software anomaly {2 b 0 91 56 1e 0 0 0}
08/05/14 06:26:09 000004M|000/02/0/004|=5:1381=DECT (CTM) Radio Fixed Part put in service: cspver 24 bsver 83
Подскажите пожалуйста, с чем связаны данные события, насколько они критичны и как от них избавиться.
Тема настроек COS для меня пока что достаточно мутна. Помогите пожалуйста разобраться в следующей ситуации.
Есть сеть из станций OXE, расставленных по региону и соединенных ABC гибридными линками. Согласно текущим настройкам если абоненту некоторой станции назначен Public Network COS = 2, то он может звонить только абонентам внутри сети, Public COS = 3 разрешены звонки на ГТС, Public COS = 4 разрешены междугородние вызовы. Один из узлов, который внедряли последним выбивается из общей схемы и портит картину: если некоему абоненту этого узла присвоить Public COS = 4, то он может успешно дозваниваться до абонентов этого же узла, но НЕ МОЖЕТ звонить абонентам других узлов (на аппарате высвечивается Busy). Стоит сменить COS на 2, вызов не внутренних абонентов других узлов проходит, но естественно не доступен город.
В какой части Public Network COS может влиять на вызовы между внутренними абонентами, пусть и расположенными на разных узлах, соединенных по IP.
Спасибо!
Помогите разобраться с темой Аудит, Не понял некоторые моменты
Небольшая предыстория: есть два узла (номера 3 и 7). ПО на них разное, на 3-м версия релиза 11, на 7-м - версия 10. Насколько я понял из обсуждаемых на форуме вопросов, проблем в части синхронизации основных настроек возникнуть не должно. На 3-м узле наиболее полная информация о сети (наибольшее число пользователей, большая масса префиксов, в т.ч. с других узлов сети). Узел 7 обслуживает небольшую область. Он внедрялся последним. Подрядчики (по их словам), во время установки столкнулись с какими-то сложностями из-за включенного броадкаста (то ли где-то, на другом узле, отвалился доступ в город, то ли еще что - внятно они объяснить не смогли). В результате броадкаст они выключили. Аудит тоже не проводили, а для того чтобы можно было звонить например на узел 3, создали Routing номера, типа "номера начинающиеся с 11, 12, 13, 14 звони на узел 3, он разберется". После этого (уже во время эксплуатации станций нами) на обоих узлах добавлялись/удалялись абоненты, изменялись другие параметры. В общем, в результате конфигурации на станциях полностью не соответствуют друг другу. И всё бы ничего, но однажды я со своей трубкой DECT прибыл в область 7-го узла и выяснил, что моя трубка не работает несмотря на правильные настройки в части PARI/PLI. Насколько я понял, это связано с тем, что нет моего Network номера на станции 7, смотрящего на узел 3 (домашний узел для моего телефона). В общем, с учетом этого, да и вообще с целью как-то упорядочить картину, было решено провести аудит.
С темой Аудит документации ознакомился. В голове много неясностей. Для начала решил опробовать режим симуляции. Аудит запустил на 7-м узле и первое что вызвало у меня сомнения - вопрос насчет Reference node.
1. Станция предлагает Reference building in the local node или Reference downloading over the network. Поясните пожалуйста что здесь имеется в виду. Насколько я понял, что если я хочу, чтобы информация с 3-го узла заполнила локальную базу, то "опорный" (reference) узел должен быть 3-й. Так? Т.е. в этом вопросе я выбираю вариант 3?
2. Далее доходим до стадии выбора объектов. Часть объектов обозначены *, часть данного обозначения не имеет. Правильно ли я понял, что синхронизации будут подвергнуты именно те, что со звездой? Почему-то не удается изменить данный перечень. Например, объект 1 Numbering Plan по умолчанию без звезды. Я хочу ее добавить. Указываю в диалоге 1, но звезда не появляется. Аналогично, если хочу где-то снять *. Можно ли править выбор объектов по умолчанию и как это сделать?
3. Непонятна и следующая стадия: Global Network или Only one node. Выбрал Only one node, понимая, что хочу данные брать только с удаленного узла 3, а не со всех оставшихся узлов сети.
4. При следующем выборе узла пробовал указывать 7 (помня, что ранее выбрал 3), но получал нулевой результат. После выбора в данном пункте 3 получил кое-какие данные, которые опять не вызвали вопросы. Вот, например, кусок
Правильно ли я понимаю, что на локальном узле (7), после поступления информации с узла 3 будут выполнены: автоматическое создание префикса 2401,1290,..., обновлены 25, 31, 32 и т.д., автоматически удален 1193, а префикс 26 в связи с конфликтом нужно будет править вручную?
Спасибо большое!
Инциденты после установки патча, Инциденты 2686, 1603, 1607
После обновления ПО на станции OXE (11-релиз) с 25 патча до 33 на станции стали появляться новые инциденты: 11/04/14 09:41:43 000003S|---/--/-/---|=0:1603=IO1 driver error, wrong telephone msg received, line 1533, position (0,28,131) 11/04/14 09:41:43 000003S|---/--/-/---|=3:1607=01.15.3b.00.0f.0f.00.1c.08.83.54.01.5a.db.ce 11/04/14 09:41:43 000003S|---/--/-/---|=0:1603=IO1 driver error, wrong telephone msg received, line 6329, position (0,28,131) 11/04/14 09:41:43 000003S|---/--/-/---|=3:1607=01.15.3b.00.0f.0f.00.1c.08.83.54.01.5a.db.ce По Incinfo не сильно что-то понял. Смущает также параметр 1603-го инцидента (0,28,131). Судя по описанию число 28 должно соответствовать номеру платы (cpl), но у нас 28-слотовый кабинет, и платы нумеруются с 0 до 27-го.
Кроме того до обновления патча периодически проскакивал инцидент 11/04/14 15:28:02 000003S|---/--/-/---|=2:2686=MAO err on stand-by CPU: err 4100 Ope ope 111 Obj TSC_IP Inst : 3 17783
Надеялся, что после установки обновления (выполнял с выравниванием баз путем клонирования database MAO без Linux) инциденты 2686 более не будут проявляться, но ошибся, установка патча и выравнивание не помогли.
Подскажите пожалуйста, что это за инциденты такие и как с ними бороться.
Спасибо!
Проблема NTP синхронизации, NTP: Synchronization lost
Проблема в следующем. На ряде станций (на большинстве) наблюдаю постоянно такой инцидент
Код
08/04/14 17:59:09 000002M|---/--/-/---|=4:3077=NTP: Synchronization lost
08/04/14 18:14:17 000002M|---/--/-/---|=4:3077=NTP: Synchronization lost
08/04/14 18:29:24 000002M|---/--/-/---|=4:3077=NTP: Synchronization lost
08/04/14 18:44:36 000002M|---/--/-/---|=4:3077=NTP: Synchronization lost
08/04/14 18:59:45 000002M|---/--/-/---|=4:3077=NTP: Synchronization lost
08/04/14 19:15:06 000002M|---/--/-/---|=4:3077=NTP: Synchronization lost
Понятно, что что-то не то с синхронизацией по NTP. Но что? В swinst сказано брать время по NTP.
Код
The date is Apr 8, 2014 and the time is 21:10:22 (09:10:22 PM)
The timezone is Etc/GMT-4
NTP is running
Configured as client of server(s):
> 10.69.128.34
NTP-сервер 10.69.128.34 работает. С него успешно берут метки другие сетевые устройства. Никаких ограничивающих списков доступа нет. На станции запускал tcpdump udp port 123 - пакеты уходят как со станции на сервер, так и обратно, примерно раз в 10-15 минут. Правда запрос идет версии NTPv4, а ответ возвращается NTPv3.
Вывод ntpq
Код
(2)fl_06> ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.69.128.34 10.64.34.10 3 u 201 512 377 0.437 72.890 83.353
