Прошу Вашей помощи. После установки выноса в удаленном офисе на основном узле постоянно фиксируются события
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 устраняет проявление указанных инцидентов.
Хочу услышать Ваше мнение относительно причин возникновения инцидентов, способов борьбы с ними, а также корректности предположений подрядчика.
Иногда помогает перестановка INTOFA - INTOFB местами (при нюансах с платами - в плане загрузки бинарников и пр.) Второе (или наверное первое) - это вопрос синхронизации. Если вы берете синхронизацию от потока Е1 - то весь тракт от вышестоящей станции до вам должен быть синхронизирован (т.е. в SDH тоже должна быть настроена иерархия синхронизации)
Уважаемый, Vad! Прошу прощения, не совсем понял Вашу формулировку.
Т.е. подрядчик прав? Инциденты это следствие некорректной синхронизации?
Но если есть проблемы почему станция помимо этих инцидентов не подает никаких знаков? Infocs тоже показывает, что все в норме. Качество телефонной связи по данному потоку нормальное.
провайдер с громким названием "Ростелеком" еще ничего не значит, просто он поглатил всех мелких провайдеров (совсем имеющимся барахлом которое было) которые не смогли устоять на рынке
про синхру от прова подрядчик от части прав т.е. когда начинает хрома синхра надо делать делать рестарт синхронизации на dect, а самый надежный вариант это перезапуск dect-системы
согласно доке одну плату dect8 можно выделить под раздачу синхронизации для всей системы dect, побочный эффект - количество tdm-каналов урезается до 16 (если память не подводит), дект базы от этой dect8 лучше ставить в отдаленные участки где меньше потребности в dect-ах
тут само собой назревает вопрос - у вас синхронизация для dect прописана от процессора или dect8?
а чтобы навсегда избавить от хромой синхры терминируйте стык к прову через sip т.е. физически изолировать isdn-pri атс от прова, терминировать через h323 заведомо тупиковая идея тобишь опять вернетесь к тому с чего все началось
Если инциденты повторяются часто и есть возможность вечером побаловаться - выдерните поток и посмотрите что происходит. Кроме того, покажите вывод по команде infocs - будет видно что и как синхронизируется. Качество телефонной связи и синхронизация - это будет видно только на связи модемов и факсов. Для голоса как правило проблемы синхронизации (так называемые слипы) - как правило не заметны.
Vladimir Shushkov пишет: Эта пара событий с 0 и 1 повторяется примерно раз в минуту или чаще.
тут осталось выяснить методом исключения из чего события появляются, как вариант на кристалле 2 потушить ibs и отключить на 2-15 isdn если подключены и глянуть на события
но все мне кажется что все это идет с кристалла 3, синхронизация такая штучка где проблема в одном месте, а аукается совсем в другом, думаю что если кристалл 3 отправить в ребут то события уйдут
Будьте добры, если несложно, проясните пожалуйста следующие моменты:
Цитата
про синхру от прова подрядчик от части прав т.е. когда начинает хрома синхра надо делать делать рестарт синхронизации на dect, а самый надежный вариант это перезапуск dect-системы
Дурацкий вопрос - а как это сделать? В том смысле, есть какие-то команды для - рестарта синхронизации DECT - перезапуска всей DECT?
Цитата
согласно доке одну плату dect8 можно выделить под раздачу синхронизации для всей системы dect, побочный эффект - количество tdm-каналов урезается до 16 (если память не подводит), дект базы от этой dect8 лучше ставить в отдаленные участки где меньше потребности в dect-ах
Правильно ли я понимаю, что если, к примеру, в полке стоит две DECT8 платы, от одной из которых раздается синхронизация, то абоненты, которые пользуются в настоящий момент данной DECT-платой могут установить не более 16 вызовов, тогда как на абонентах другой платы, а уж тем более, другой полки, это никак не сказывается?
Цитата
тут само собой назревает вопрос - у вас синхронизация для dect прописана от процессора или dect8?
Пожалуйста, сориентируйте, где это посмотреть?
Цитата
а чтобы навсегда избавить от хромой синхры терминируйте стык к прову через sip т.е. физически изолировать isdn-pri атс от прова, терминировать через h323 заведомо тупиковая идея тобишь опять вернетесь к тому с чего все началось
Error, не совсем понял... У нас ведь классический ISDN PRI, никакого IP на стыке. А SIP и H323 же IP решения и подразумевают кардинальных изменений как договорных обязательств с провайдером, так и технических решений для этого. Или я что-то не так понял?
Цитата
отключить на 2-15 isdn если подключены и глянуть на события
В настоящий момент isdn 2-15 совсем не используется. Может ли плата с неиспользуемым потоком (никуда не подключенным) вызывать данную ситуацию?
Цитата
думаю что если кристалл 3 отправить в ребут то события уйдут
Понял. Попробую перегрузить. Еще один дурацкий вопрос: не приходилось сталкиваться с перезагрузкой отдельного кристалл. Платы - да, станцию в целом - да, а вот отдельный, зависимый кристалл - что-то не припомню такого. Команда reboot, я так понимаю, здесь не поможет. Достаточно ли перезагрузить просто платы INTIPB на этом узле?
Vladimir Shushkov пишет: Правильно ли я понимаю, что если, к примеру, в полке стоит две DECT8 платы, от одной из которых раздается синхронизация, то абоненты, которые пользуются в настоящий момент данной DECT-платой могут установить не более 16 вызовов, тогда как на абонентах другой платы, а уж тем более, другой полки, это никак не сказывается?
16 вызовов TDM т.е. dect-аналоговый телефон dect-цифрой телефон и т.д.
Цитата
Vladimir Shushkov пишет: Пожалуйста, сориентируйте, где это посмотреть?
уже стоит | 0 | 15 | DECT8 | DTM PRESENT | X |
Цитата
Vladimir Shushkov пишет: У нас ведь классический ISDN PRI, никакого IP на стыке. А SIP и H323 же IP решения и подразумевают кардинальных изменений как договорных обязательств с провайдером, так и технических решений для этого.
ставите два voip-шлюза, один шлюз в сторону провайдера, другой шлюз в сторону атс, оба шлюза смотрят друг-на- друга через sip
Цитата
Vladimir Shushkov пишет: Еще один дурацкий вопрос: не приходилось сталкиваться с перезагрузкой отдельного кристалл.
rstcpl №-кристалла № полки чтобы перезагрузить кристалл 3 делаем rstcpl 3 6 для intof так же только с указанием самого интофа
Цитата
Vladimir Shushkov пишет: - рестарта синхронизации DECT - перезапуска всей DECT?
Коллеги, испробовал все варианты с перезагрузками: -перезагрузил INTIPB плату 3-го кристалла -перезагрузил обе INTOFB платы 2-го кристалла -сделал dectrestart (правда, ожидал, что на время поотрубаются все трубки, но процесс прошел незаметно: трубки работали, лишь только в логе было сообщение о реинициализации) -сделал dectview synibs
К сожалению, инциденты продолжаются сыпаться в том же количестве. Стоит отметить, что после dectview syncibs появилось сообщение
Код
The storage of info for synchronization of IBS not active yet. It becomes active now
После syncibs ничего больше не делал. Может по-новому все поперезапускать?
Также хочу отметить еще один странный инцидент, наверное, связанный с первым. Обратил внимание, что сегодня, среди вороха событий 8KFS проскочило событие
Хотелось бы вновь поднять тему. Дело в том, что выяснились некоторые обстоятельства. Во-первых, было выяснено, что при отключении потока PRI ГТС, откуда мы принимаем синхронизацию через наше же SDH оборудование, инциденты пропадают. Т.е. качество потока E1 похоже действительно страдает.
К сожалению, пока неясно кто виновник. Поток ГТС в виде интерфейса E1 мы принимает от Ростелекома. На его площадке установлено наше оборудование Cisco ONS15305, которое отображает принимаемые E1 на кадр SDH и далее по нашим оптическим линиям передается на основной наш объект, где установлен такой же Cisco ONS15305. Из него вынимаем E1 и подаем в УАТС. Т.е. возможно страдает принимаемый от оператора поток, а возможно нестабильность вносится нашими мультиплексорами.
Обращался в тех.поддержку обслуживающую данные мультиплексоры. Приезжал технический специалист с приборами для измерения качества потоков E1 - Metrotek Berkut-E1. Выполнили часть тестов:
1. На стороне оператора воткнули в мультиплектор прибор в режиме генерации тестовой последовательности, а на стороне станции, в максимально близкой к ней точке (включая всю пассивку в виде кроссов и плинтов) сделали физический заворот. BER по нулям в течение времени измерения 15 минут. Были кодовые ошибки, которые как выяснилось позже были связаны с тем, что прибор был настроен на тестирование неструктурированного потока, тогда как на мультиплексорах порты настроены в режиме структурированных.
2. Попросили оператора сделать петлю на их стороне и произвели аналогичные замеры. Тоже все по нулям.
3. В связи с не совсем корректными замерами на этапе 1 провели повторный тест: на стороне оператора установили физическую петлю в порту E1 мультиплексора, на нашем объекте прибором сняли замеры в режиме структурированного потока. Оказалось, что в этом режиме прибор измеряет другие, наиболее, как мне кажется, интересные параметры, в том числе максимальное значение частотной девиации.
Результат последнего измерения сейчас не помню, подрядчик обещал скинуть в ближайшее время. Пока есть следующие вопросы:
1. Когда говорят о том, что INTOF критична к качеству потока ГТС, от которого синхронизируется полка, есть ли какие-то явные числовые параметры в диапазоне которых указанных проблем с выносом не должно быть? Т.е. документировано ли где-то необходимое качество сигнала синхронизации? Например, джиттер не выше такого-то значения, девиация частоты такая-то и т.д.
2. Есть желание измерить качество принимаемого от оператора потока до нашего SDH оборудования. Спросил у подрядчика - можно ли производить замеры не тестовой последовательности с установкой петли, а воткнут в прибор поаваемый от оператора рабочий поток. Он сообщил, что нет. Но есть у меня некоторые сомнения на этот счет. Ведь служебные тайм-слоты никто не отменял, и, наверное, даже в рабочем потоке, прибор должен уметь разбирать эту служебную информацию. Так ли это?
