Vad пишет: с точки зрения броадкаста и аудита - с других узлов по идее берется только информация о ЛОКАЛЬНЫХ ресурсах. Т.е. с центрального узла не будет браться информация об абонентах и транковых группах с других узлов
Да, Вадим, спасибо, так и есть. После General Check со всей сети подгрузились все транк-группы.
Дальше интересно. Включаю в сеть новый нод. Он просто End Node, смотрит статическим линком в другой узел, который дальше смотрит в остальную сеть динамическим линком. Проблема такая: делаю Hybrid Link (IP), тип Static. В супрутаже вижу только тот routing node, в который включаюсь. Туннельные IP адреса остальных узлов, которые лежат дальше этого роутинг нода, не пингуются. Удаляю статический линк, делаю динамический - вижу все узлы. Удаляю динамический линк, снова делаю статический - вижу все узлы, пинги на туннельные адреса идут. Перегружаю end node. По-прежнему вижу все узлы. Это нормально?
Поправка. Концы звезды в моем случае соединены каждый с двумя соседними. Так что получается "велосипедные колесо". Как правильно в этом случае делать типы линков периферии с центром и с соседями?
Коллеги! Не буду ради глупых вопросов плодить темы. Что-то я, видимо, слишком много перечитал доки и затупил. Сеть ABC-F по теории имеет три вида узлов: End node (тут все понятно, оконечный нод, только static) Routing Node (имеет по крайней мере один dynamic линк) Backbone node (толоко динамические линки)
Вопрос: сеть типа "звезда" - один центр и много лучей с одним нодом на конце. Центр - это backbone или routing нод? Получается, при такой топологии в сети нет динамической маршрутизации, только статическая, и оконечный нод про другие оконечные ничего не знает.
Вопрос этот не из праздного интереса - в существующую звезду (в которой все линки, а их порядка 30, сделаны dynamic, что, оказывается, нехорошо), включил еще один оконечный нод, и сделал его по правилам, через статический линк. Так вот, в супрутаже он видит только центральный нод, что, в принципе, согласуется с теорией, но вот при проведении "входящего" аудита на новом ноде с центрального нода, скажем, по транк-группам, инсертятся только транк-группы центрального узла, а группы всех прочих узлов - нет, хотя на центральном узле они все видны.
Разрешите, я немного внесу ясность. Есть центральная ОХЕ. В нее включены ОХО, где-то по H323, где-то по SIP. ОХО звонят друг другу с 8-значным А-номером (4 знака ID + внутренний номер). Задача - чтобы на звонимую ОХО приходил 4-значный А-номер, то есть транзитной ОХЕ откусывать ID и слать только Ext. Что, требуется все TG переделывать в private? А для SIP это тоже будет работать?
Третья чвсть марлезонского балета. Беру swk от "честных" OPS с другого объекта. Залились нормально (ну, то есть с руганью на software package, но залились). А тот, первый swk не совсем честный. Я его дернул из zip файла, сгенеренного Актисом. Может, в этом дело? Вообще, swk файл в актисовском архиве и swk, который приходит из Алкателя, идентичны?
Если вдруг пропало "у некоторых", а у остальных нет, то первое, что лезет в голову, что ходите вы наружу через разные каналы, и тот канал, по которому ходили "некоторые", отвалился. Остальные звонят по-прежнему, так как их канал жив. Но это лишь предположения. Дайте хоть что-нибудь - поток/аналоговые транки/IP в город? Какую цифру жмете для выхода в город и чему она в префикс-плане соответствует?
Ну, а из общего - смотрим статусы всех транк групп, ищем те, что не в сервисе. Сравниваем Public Network Category у звонящего и незвонящего абонента.
Добрый день. Есть Appliance Server, поднятый мной на VMWare. Нормально залился релиз 11.0. Беру swk файл от 11 релиза. Переименовываю его в software.mao и кладу в usr3/mao. Рестарт. (В процессе загрузки ругается на Software package error). spadmin пункт 2 показывает, что счетчики стали ненулевые (IP и SIP абоненты, SIP GW и т.д.). Но ничего создавать не дает - ни IP, ни SIP абонентов. Software protection error со ссылкой на локи, которые у меня, напомню, ненулевые. Ничего, кроме виртуальных аналоговых.
Вторая часть марлезонского балета. Разворачиваю на этой машине реальную базу (правда, от кристалла R7.0). После трансляции базы получаю кучу SIP абонентов, которых могу удалять, но! не создавать (опять Software protection error).
Что, без хорошего CPUID даже 30 дней не поработает?
как вариант (теория, с USB-KEY не имел дело) для центра узлов лицензировать AS-Virtualization VMWare, в комплекте будут USB-KEY, а фактически поставить сервак максимально к приближенному к бренду с двумя дуплами под процы (максимальная приближенность выражается в совместимом RAID-контролере и NIC-Intel)
Интересно. Я про такое даже не читал... В любом случае, "поздняк мететься, полы покрашены". Оборудование уже куплено.
Vlad 46 пишет: Выводить много аварий на alarm set смысла нет, как правило выводятся критические, а их не так уж много и CP справится. Лучший вариант пользоваться 4760 или 8770 с отсылкой по почте
Про вариант с ОВ знаю, но клиент привык по старинке. Скорее всего, будем использовать оба варианта.