Q: Автоматическое восстановление IP-Networking после сбоев в IP-канале, /Не работает после обрыва и восстановления связи по IP Опции

[Alexander Y. Leo...]

Извините, что повторно. Хотел поднять прежнюю тему, но не нашел (удалили?).

Есть две мини-АТС:
1) ipLDK-100 OFFICE - GS90P-3.7Ce JUL/07
2) ipLDK-300 OFFICE - GS30P-3.7Ce JUL/07
Установлены на удалении друг от друга. Подключены к локальным сетям (ЛВС), соединенных маршрутизаторами через радиосеть (канал >=2 Мбит). Радиосеть провайдера с "серыми" IP-адресами, тем не менее, дополнительно между маршрутизаторами налажена VPN (тоннель).

На мини-АТС включен IP-Networking (лицензия есть, активирована), общий номерной план, transit-out, transit-in (побежденный благодаря Harris'у), в общем "полный андульсиён". VoIP организовано платами VOIBE GS30H-2.1Cb , VOIB mode: H.323, кодек: G.723.1. Качество передаваемого голоса оценивается пользователями на "5".

Иногда (редко, не чаще 2 раз в день) в радиоканале возникают задержки (на канальном уровне), которые приводят либо к тайм-аутам в связи по IP (внутри VPN), либо к кратковременному отключению VPN. Кратковременный = не больше 5 минут, зачастую 10-20 секунд.

Сетевые сервисы типа терминальной сессии, электронной почты, сетевой печати реагируют на такие "пропадания" нормально: потормозят, конечно, чуток, но продолжают свою работу когда канал стабилизируется.
А мини-АТС не восстанавливает связь: после восстановления связи в канале необходимо перезапускать мини-АТС (если не помогла, то обе).
Иначе при звонке на местный номер (или при попытке использовать transit-out) сначала долгая тишина в трубке, потом короткие гудки.
В таком состоянии мини-АТС может находится несколько часов (пока не перезапустишь) -- сама связь не восстанавливает.

Это баг или фича (имеющейся прошивки)? Или кривые ручонки "настройщика"? (т.е. меня)

В прошлой теме гуру предлагали мне сделать трейс или протокол работы мини-АТС в такой ситуации.
Я уже и на это согласен, если эти действия помогут определить причину сбоя.

Конечно, если это "фича" такая, то остается смириться и придумывать что-нить типа автоматического перезапуска мини-АТС, в случае поступления сигнала от диагностической утилиты (которая следит за состоянием канала и оповещает администратора в случае проблем).

[grey73]

1) ipLDK-100 OFFICE - GS90P-3.7Ce JUL/07
2) ipLDK-300 OFFICE - GS30P-3.7Ce JUL/07
которые приводят либо к тайм-аутам в связи по IP (внутри VPN), либо к кратковременному отключению VPN. Кратковременный = не больше 5 минут, зачастую 10-20 секунд.

У меня три ldk-300, без нетвокинга. Платы не помню -- 2004 год еще. Прошивка 2.2Fi -- на днях буду апгрейдить.

До тех пор, пока в отдельный VLAN в сетке не вынес сетевухи (в каждом здании), VOIB регулярно подвисали твоим же макаром. Их какой-то траффик основной сетки "убивает", я думаю.

Cейчас для них по каналу отдельный VLAN в каждом здании, который заворачивается в свой собственный VPN (организовано по физическому каналу 2 параллельных VPN -- один для АТС с задранным QoS, и второй для данных), в котором чисто сами материнки, VOIB платы и доступ с моего компа через роутер -- на порулить.
Да собственно и АТС в разных IP-сетях, между ними по 2 роутера (пограничный в каждом здании) -- всё нормально уже несколько лет :-)
Канал падает редко, но иногда бывает. Всё восстанавливается.

До третьей АТС организован VPN через интернет вообще. Тоже всё нормально себя ведёт. Правда, качество чуть хуже при большой загрузке -- там несколько провайдеров по пути, и с QoS не всё просто.
Обрывы чаще. Но самовосстанавливается без проблем.

Моё imho -- нужно физически отделить АТСный траффик от остального. Должно помочь.

И еще -- при отсутствии связи дефолтгейтвей должен жестко говорить вызывающей АТС, что порт либо хост недоступен, а не тормозить, посылая пакеты кругами по роутерам и прочему, пока пакет по TTL не помрёт. Тут снифферы очень даже помочь могут.

Кстати, у меня перезапускать при подвисании приходилось только платы VOIB ресетом на оных.

[vldmr]

И еще -- при отсутствии связи дефолтгейтвей должен жестко говорить вызывающей АТС, что порт либо хост недоступен, а не тормозить, посылая пакеты кругами по роутерам и прочему, пока пакет по TTL не помрёт. Тут снифферы очень даже помочь могут.

- важный момент

При проведении изысканий вяснено что иногда подвисания происходят при звонке в "никуда" - т е на недоступный IP

[grey73]

- важный момент

При проведении изысканий вяснено что иногда подвисания происходят при звонке в "никуда" - т е на недоступный IP

Не совсем так.
Если при звонке возвращается сразу ICMP Host/Port Unreachable, то АТС просто пищит ошибкой, и не виснет.
А вот если пакет от АТС уходит, и через несколько десятков секунд возвращается ICMP TTL таймаут, то подвисание VoIB платы очень вероятно.
У меня было именно так.

[Alexander Y. Leo...]

Если при звонке возвращается сразу ICMP Host/Port Unreachable, то АТС просто пищит ошибкой, и не виснет.
А вот если пакет от АТС уходит, и через несколько десятков секунд возвращается ICMP TTL таймаут, то подвисание VoIB платы очень вероятно.

Да, у нас при отключении канала тайм-ауты идут, а не сразу "узел недоступен".
----
Вот и "направление копания" обозначилось. Спасибо вам, vldmr и grey73!

P.S. Не висло бы оно в таких слачаях...

Сообщение отредактировал Alexander Y. Leonov - 7.2.2008, 14:39

[grey73]

Да, у нас при отключении канала тайм-ауты идут, а не сразу "узел недоступен".

Ну так на роутере нужно роутинг при отсутствии канала прописать в Unreachable ЯВНЫМ образом.
У меня добавочная строчка с анричиблом прописана с заведомо большой метрикой. Если интерфейс падает, то это правило и начинает работать:

192.168.152.0/22 via 192.168.2.226 dev tun2
unreachable 192.168.152.0/22 scope host metric 255

то есть в моем случае если tun2 упадет, то пакеты в 192.168.152.0/22 будут возвращаться с анричиблом, а не уходить на дефолтгейтвей роутера, и там теряться

[Alexander Y. Leo...]

Ну так на роутере нужно роутинг при отсутствии канала прописать в Unreachable ЯВНЫМ образом./.../

У нас роутер -- это сервер, который работает под управлением Win2003 cо службой RRAS (он и VPN-туннели делает). При кратковременном обрыве связи VPN-туннель не рвется сразу, просто тайм-ауты возвращает. Если перерыв в связи (в базовом канале) кратковременный, то после восстановления связи туннель продолжает свою работу (без переподключения заново). Конечно, когда тоннель "совсем отключается", то получаем unreachable.
RRAS так тонко не регулируется (второй вариант: у меня не хватает знаний ), и менять эту систему на "аппаратный" роутер (или *nux-based ОС) ради обхода ситуации, при которой VoIP-подсистема УАТС "завешивается", пока никто не будет. Это тупик. Пока перегружаю вручную (если УАТС близко, то перезагружаю reset'ом VOIBE, если далеко, то удаленно всю УАТС).

[All is not what ...]

удаленно VOIBE ребутится через Update

[Alexander Y. Leo...]

удаленно VOIBE ребутится через Update

В смысле, заливать прошивку для того, чтобы перезапустить только плату VOIBE?
Я ни разу еще не заменял firmware на плате VOIBE (предстоит это сделать) и не знаю сколько это по времени занимает.
Но вообще да.. прикольно. Тем более, что другого способа и нет.

[vldmr]

да нет не так надо просто войти в настойки viob через pcadmin и ничего не меняя нажать update

[Alexey A. Astash...]

Извините, что повторно. Хотел поднять прежнюю тему, но не нашел (удалили?).

Это к сожалению до сегодняшнего дня остается "фичей" АТС, сами ждем недождемся когда же наконецто выйдет новая прошивка в которой эта "фича" будет исправлена. вот кстати с RSG таких проблем нет, потеряля коннект? невопрос, на тебе реконнект, ничего не висит, прекрасно все
А вот тут остается только ждать
Виснет исключительно во время разговора. Если сеть пропала вне активности то ничего страшного не произойдет естесственно, но вот по непонятно каким причинам у нас в офисе всегда канал идет на Retrain именно во время разговора примерно в одно и тоже время суток, причем приходится перезапускать сразу 3 АТС (точнее делать Update платам VOIBE.)

[Alexander Y. Leo...]

Это к сожалению до сегодняшнего дня остается "фичей" АТС, сами ждем недождемся когда же наконецто выйдет новая прошивка в которой эта "фича" будет исправлена. /.../

К сожалению, мне доступен только краткий перечень новых "фич" прошивки 3.8 (типа анонса краткого). Не могу удостовериться в том, что разработчики собираются новой версией исправить эту особенность.
Существует ли уже "общедоступный" перечень исправлений версии 3.8?
(Или Вы имеете в виду новую прошивку VOIBE, а не ПО самой мини-АТС? )

P.S. Я сейчас перезапускаю 2 АТСки. В ближайшей перспективе еще 3 штуки будут подключены к IP-Net...

[nikol]

К сожалению, мне доступен только краткий перечень новых "фич" прошивки 3.8 (типа анонса краткого). Не могу удостовериться в том, что разработчики собираются новой версией исправить эту особенность.
Существует ли уже "общедоступный" перечень исправлений версии 3.8?
(Или Вы имеете в виду новую прошивку VOIBE, а не ПО самой мини-АТС? )

P.S. Я сейчас перезапускаю 2 АТСки. В ближайшей перспективе еще 3 штуки будут подключены к IP-Net...

Честно говоря, я так и не понял, что Вы хотите от версии 3.8? Начнем с того, что этой версии вообще не существует! Есть, конечно, бета, но там в контексте Вашего обсуждения ничего нового нет. А что будет в официальной и когда, так этого пока никто не знает (ну кроме самой LG).

[Alexey A. Astash...]

К сожалению, мне доступен только краткий перечень новых "фич" прошивки 3.8 (типа анонса краткого). Не могу удостовериться в том, что разработчики собираются новой версией исправить эту особенность.
Существует ли уже "общедоступный" перечень исправлений версии 3.8?
(Или Вы имеете в виду новую прошивку VOIBE, а не ПО самой мини-АТС? )

P.S. Я сейчас перезапускаю 2 АТСки. В ближайшей перспективе еще 3 штуки будут подключены к IP-Net...

у меня 3 я уже за......лся вовсю полная Ж.....!!!

Честно говоря, я так и не понял, что Вы хотите от версии 3.8? Начнем с того, что этой версии вообще не существует! Есть, конечно, бета, но там в контексте Вашего обсуждения ничего нового нет. А что будет в официальной и когда, так этого пока никто не знает (ну кроме самой LG).

Что нового будет в 3.8 приблизительно понятно, думаю даже много чего интересного добавится, ждем с нетерпением новую версию прошивки. Насколько я вкурсе отчет об данной ошибке (о которой сейчас идет тема) AXEL (дай бог ему здоровья, чтобы мы делали без него) еще в ноябре по моей просьбе отправил производителям в корею.
Сейчас Март, ну думаю уже какнибудь задумался производитель об исправлении этой ошибки, раз о выпуске первой беты было известно еще в Сентябре 2007.

[nikol]

уСейчас Март, ну думаю уже какнибудь задумался производитель об исправлении этой ошибки, раз о выпуске первой беты было известно еще в Сентябре 2007.

Не факт!

[Alexey A. Astash...]

Не факт!

значит это будет очередное разочарование...

[Alexander Y. Leo...]

Честно говоря, я так и не понял, что Вы хотите от версии 3.8?

Я хочу, чтобы ipLDK не падала в "обморок" после кратковременных неполадок в IP-сетях.
Offtopic
Еще чего ожидаю очень: возможность указать перевод внешнего вызова на Net-номер прямо в PGM144.

Сообщение отредактировал Alexander Y. Leonov - 7.3.2008, 15:13

[Alexander Y. Leo...]

Еще немножко оффтопика.
Скачал бесплатный telnet-клиент, который умеет выполнять скрипты (который можно "заавтоматизировать"): Tera Term (http://hp.vector.co.jp/authors/VA002416/teraterm.html)
На его скриптовом языке написал скрипт:

Код

;вписать сетевой адрес мини-АТС:
connect '192.168.100.1'
;вписать путь к лог-файлу -- на всякий случай проверять как все прошло...
logopen 'C:\ipldk.log' 1 1

getdate Currentdate
gettime Currenttime
; добавить в лог-файл информацию о текущей дате и времени
logwrite '================'#13#10
logwrite Currentdate
logwrite #13#10
logwrite Currenttime
logwrite #13#10'================'#13#10

; login
wait   'Press enter.'
sendln #13
wait   'ENTER PASSWORD:'
; вписать инженерный пароль обслуживания системы (для доступа к функциям maint)
sendln 'тут_пароль'
; auto login into maintenance mode complete.

wait   'maint>'
sendln 'reboot'
wait 'Password:'
; вписать административный пароль на доступ к настройкам мини-АТС
sendln 'тут_адм_пароль'
wait 'Retype password:'
sendln 'тут_тот_же_адм_пароль'

logwrite #13#10
logclose
disconnect
closett

И можно такой скриптик либо по расписанию запускать, либо по событию (например, от программы мониторинга канала поступило сообщение об обрыве).

Но к сожалению таким образом перезапускается же вся мини-АТС...

[All is not what ...]

делайте тоже самое через ком порт VOIB`а

[AXEL]

кстати решил проверить платы VOIBE, и оказалось что на старой версии таких эффектов не наблюдалось.
Правда там другие глюки были , в частности с сипом.
кто хочет может попробывать у себя версию платы VOIBE 2.0. меняеться через WEB интерфейс.
правда проверял не долго может ещё что вылезет.

Прикрепленные файлы

 Gs30H20Ca.zip ( 1,28 мегабайт ) Кол-во скачиваний: 20

 

[Alexander Y. Leo...]

кстати решил проверить платы VOIBE, и оказалось что на старой версии таких эффектов не наблюдалось.
Правда там другие глюки были , в частности с сипом.
кто хочет может попробывать у себя версию платы VOIBE 2.0. меняеться через WEB интерфейс.
правда проверял не долго может ещё что вылезет.

Глюки с SIP'ом меня не пугают. Пугает то, что "может ещё вылезет" Есть ли примерный список надежных исправленний (разницы) от версии 2.0 к версии 2.1?
Чтобы это что-то не стало новым компромисом (типа, "да, вот это перестало работать, зато ж каналы не виснут!" ).
Сегодня постраюсь попробовать... Спасибо за прошивку (у меня сейчас везде на VOIBE'ах Version: GS30H-2.1Cb )

[AXEL]

вот примерно что изменилось.
в файле.

Прикрепленные файлы

 VOIBE_software_changes.zip ( 10,54 килобайт ) Кол-во скачиваний: 16

 

[Alexander Y. Leo...]

Возврат к старой прошивке (2.0Ca), похоже, устранил проблему с зависаниями VOIBE с новейшей прошивкой (2.1Cb) во время time-out'ов в канале связи!
Натурный эксперимент показал, что при одинаковых условиях 2.1Cb виснет, а 2.0Ca -- нет.

вот примерно что изменилось.

Спасибо! Похоже, нет ничего (для меня) критичного.

[harris]

Возврат к старой прошивке (2.0Ca), похоже, устранил проблему с зависаниями VOIBE с новейшей прошивкой (2.1Cb) во время time-out'ов в канале связи!
Натурный эксперимент показал, что при одинаковых условиях 2.1Cb виснет, а 2.0Ca -- нет.

Спасибо! Похоже, нет ничего (для меня) критичного.

Ну вот, теперь есть все основания попинать корейцев, чтобы устранили проблему версий 2.1
Придется писать кляузу....

[All is not what ...]

Натурный эксперимент показал, что при одинаковых условиях 2.1Cb виснет, а 2.0Ca -- нет.

а на 2.1 делали h323 only?

[AXEL]

делали

[nikol]

делали

Вот ответьте мне, господа! Ну почему у меня все работает??? И уж поверьте не одна стация... Вот до сих пор никто не СОИЗВОЛИЛ прислать полный снифер с "неработающей станции!!!" Почему??? Да, действительно, согласен, возможно может станция зависнуть при возврате пакетов при условии VPN или других подобных делах (каналах), но ведь это редкость!! (да то же не факт!)!!! Вот лично у меня, пока, не получилось её повесить! Если у кого-то получилось, то пришлите - рассмотрим... Я последнюю версию не оправдоваю, там действительно не совсем все в порядке, с самопроизвольной перезагрузкой платы действительно есть проблемы (блин, причины отследить так и не удалось), но, только вот лишнего говорить и писать не нужно... И чего, интерестно, LG, в этом случае, будет исправлять, если даже клиентам не всё до конца понятно??? Вот к примеру, 2.0! Посадите секретаршу следить, или посмотрите в логах EzAttendanta, все-равно перезагрузка платы идет! И чем она в этом случае лучше? Тем, что не виснет при наличии VPN??? (Я так завесить и не смог, убил, блин, свои выходные...) Спорный вопрос!!!!
Ладно, извените меня. Просто вероятно, я уже устал...

[Alexander Y. Leo...]

а на 2.1 делали h323 only?

Да, только H.323.

Вот до сих пор никто не СОИЗВОЛИЛ прислать полный снифер с "неработающей станции!!!" Почему???

Что такое "полный снифер"?

Сообщение отредактировал Alexander Y. Leonov - 17.3.2008, 16:42

[Alexey A. Astash...]

Вот ответьте мне, господа! Ну почему у меня все работает??? И уж поверьте не одна стация... Вот до сих пор никто не СОИЗВОЛИЛ прислать полный снифер с "неработающей станции!!!" Почему??? Да, действительно, согласен, возможно может станция зависнуть при возврате пакетов при условии VPN или других подобных делах (каналах), но ведь это редкость!! (да то же не факт!)!!! Вот лично у меня, пока, не получилось её повесить! Если у кого-то получилось, то пришлите - рассмотрим... Я последнюю версию не оправдоваю, там действительно не совсем все в порядке, с самопроизвольной перезагрузкой платы действительно есть проблемы (блин, причины отследить так и не удалось), но, только вот лишнего говорить и писать не нужно... И чего, интерестно, LG, в этом случае, будет исправлять, если даже клиентам не всё до конца понятно??? Вот к примеру, 2.0! Посадите секретаршу следить, или посмотрите в логах EzAttendanta, все-равно перезагрузка платы идет! И чем она в этом случае лучше? Тем, что не виснет при наличии VPN??? (Я так завесить и не смог, убил, блин, свои выходные...) Спорный вопрос!!!!
Ладно, извените меня. Просто вероятно, я уже устал...

Необходимым условием зависания является отваливание канала во время разговорва между двумя станциями, в состоянии покоя этого не происходит.
На счет прямого подключения без VPN или потока маршрутизаторов никогда не пробовал может оно и не повиснет.
Одно могу сказать точно, жостаточно многим абонентам для связи нескольких удаленных офисов компании провайдер предлагают VPN на стороне собственно провайдера, поскольку
A) По этому каналу провайдер при условии соглашения легко предоставляет возможность пропускания тагированных приоритетом пакетов (QoS) между офисами.
Б) Далеко не все проавайдервы могут предоставить подключение типа Static а не PPPoE (к вопросу создания VPN своими средствами)
В) Это просто удобно

И вообще не вижу смысла делать подный сниффер

[Alexey A. Astash...]

Я хочу, чтобы ipLDK не падала в "обморок" после кратковременных неполадок в IP-сетях.

Это тема как показал факт что не в 3.8 поошивки станции походу а в прошивке платы, а может это связано с отработкой DUAL Protocol (SIP+H.323)

Offtopic
Еще чего ожидаю очень: возможность указать перевод внешнего вызова на Net-номер прямо в PGM144.

Вот скажи мне нафик тебе это нужно? Это можно было до выхода 3.8 сделать легко с помощю групп я понимаю еслибы на равне с внутренними абонентами можно было одновременно ставить и NetDSS (который кстати только 1 можно ставить), вот это тема, скорее всего эту тему никто и реализовывать не будет, хотя это реально нужно. поскольку в этом случае придется писать целый алгоритм обработки который должен работать как часы. если у тебя сняли в одном офисе(станции) трубку в другую станцию мгновенно должен прийти что заняли линию, а если не придет быстро такой сигнал? Отсюда при двух одновременно поднятых трубках на двух станциях скорее всего произойдет сбой... Можно проще поступить одного принудительно отключать при получении коллизии, а если станция отключит не того абонента? Но к вопросу подвисания линий если пройдет задержка в сети, то получится что оба абонента уже используют одну и туже линию, и скорее всего оба абонента отключатся от нее после получения сигнала коллизии (восстановления IP сети) но можно и проще сделать, сатвить при снятии трубки опрос коллизии, скажем в 0.5 сек, т.е. в течении которых связь устанавливаться не будет. (но это вопрос чисто к производителю)
Единственное, что можно реализовать это отправку входящего звонка нескольким абонентам другой станции при использовании все техже групп. Отправляешь звонок на, скажем группу кооторй у тебя нет в этой станции, но есть на другой а на другой станции у тебя уже расписано куда должен идти звонок т.е. разбиться, т.е. в этом случае у тебя уже конечная станция будет отрабатывать возможные коллизии между абонентами.

[Alexander Y. Leo...]

Вот скажи мне нафик тебе это нужно? Это можно было до выхода 3.8 сделать легко с помощю групп /.../

Все очень просто.
Дано: две УАТС в двух офиса разных городах. К первой УАТС подключены аналоговые внешние линии от ГАТС первого города, ко второй -- линии от ГАТС второго города.
Требуется: в ночное время перекидывать внешний вызов с определенных внешних линий первой УАТС на определенные внутренние линии (ночным дежурным) второй УАТС. (Днем, так уж и быть, телефонист в первом офисе переводит если нужно на абонентов второго офиса).

Сейчас (прошивка 3.7) это делается так: http://forum.ipldk.ru/index.php?s=&sho...ost&p=10782 (+ перевод net transfer mode из режима REROUTE в режим JOIN)
---
По теме: да действительно "виснет" не УАТС, а платы VOIBE. Прямо сейчас (после отката на предыдущие версии прошивки VOIBE) они не "виснут", сотрудники довольны, руководство спокойно, я гребу премии лопатой (в смысле: не наказали как обычно).

[Alexey A. Astash...]

Все очень просто.
Дано: две УАТС в двух офиса разных городах. К первой УАТС подключены аналоговые внешние линии от ГАТС первого города, ко второй -- линии от ГАТС второго города.
Требуется: в ночное время перекидывать внешний вызов с определенных внешних линий первой УАТС на определенные внутренние линии (ночным дежурным) второй УАТС. (Днем, так уж и быть, телефонист в первом офисе переводит если нужно на абонентов второго офиса).

Сейчас (прошивка 3.7) это делается так: http://forum.ipldk.ru/index.php?s=&sho...ost&p=10782 (+ перевод net transfer mode из режима REROUTE в режим JOIN)

Незнаю как это с PRI работает, с Analog CO все просто: входящий вызов отправляешь вечером скажем на группу *620 в которой стоиттип групп Net VM Grp там может стоять как группа соседней станции так и один абонент, никаких проблем на 3.7Df я не испытывал.
Потом посмотри? прошивка 3.8Ah уже вышла и лежит на сайте (правда глюная она)
Ничего абсолютно нового производитель не сделал в этой области в новой прошивке, все как был так и сталось, скопировали настройку эту в PGM 144 и усёёё.

---
По теме: да действительно "виснет" не УАТС, а платы VOIBE. Прямо сейчас (после отката на предыдущие версии прошивки VOIBE) они не "виснут", сотрудники довольны, руководство спокойно, я гребу премии лопатой (в смысле: не наказали как обычно).

А вот меня досих пор наказывают, так как мы используем как H.323 так и SIP (SIPNET.RU ибо спрашивается нафик плпта за $2100+$350 IPN) одновременно, соответсвенно 2.0 мне прошивка никак не катит.

[harris]

... прошивка 3.8Ah уже вышла и лежит на сайте (правда глюная она)

Что именно "глючное"???

[nikol]

Потом посмотри? прошивка 3.8Ah уже вышла и лежит на сайте (правда глюная она)

Блин, действительно, а в чем глючность? У меня достаточно давно установлена, только вот "глючность" я вероятно не заметил...

[nikol]

Необходимым условием зависания является отваливание канала во время разговорва между двумя станциями, в состоянии покоя этого не происходит.
На счет прямого подключения без VPN или потока маршрутизаторов никогда не пробовал может оно и не повиснет.
Одно могу сказать точно, жостаточно многим абонентам для связи нескольких удаленных офисов компании провайдер предлагают VPN на стороне собственно провайдера, поскольку
A) По этому каналу провайдер при условии соглашения легко предоставляет возможность пропускания тагированных приоритетом пакетов (QoS) между офисами.
Б) Далеко не все проавайдервы могут предоставить подключение типа Static а не PPPoE (к вопросу создания VPN своими средствами)
В) Это просто удобно

И вообще не вижу смысла делать подный сниффер

Как именно моделировали зависания во время разговора? Физически рубили канал, или как? Блин, хороший у Вас провайдер (это я насчет QoS). Не провайдер, а мечта! Нам бы такого...
По поводу снифера, так у меня просто нет слов... Станция всё-таки не утюг...

[grey73]

Незнаю как это с PRI работает, с Analog CO все просто: входящий вызов отправляешь вечером скажем на группу *620 в которой стоиттип групп Net VM Grp там может стоять как группа соседней станции так и один абонент, никаких проблем на 3.7Df я не испытывал.

С PRI то всё работает "из коробки" еще и на 2.2Fi у меня.

А вот вышеуказанное для CO'шек -- точно проверено, и на 3.7Df работает?
Или имелось в виду 3.6Df ?
6 или 7 ?? :-)

У меня на 3.6Df такое не получилось.
Верней, эффект такой:
Звонок второй станцией принимается, но поднимаешь трубку -- тишина. В это время звонящий продолжает слышать посылки вызова. Кладешь трубку на вызываемом -- он снова начинает звонить. Ну и т.д.

У Вас точно всё отвечается и звук есть в обе стороны?

[igoman]

С PRI то всё работает "из коробки" еще и на 2.2Fi у меня.

А вот вышеуказанное для CO'шек -- точно проверено, и на 3.7Df работает?
Или имелось в виду 3.6Df ?
6 или 7 ?? :-)

У меня на 3.6Df такое не получилось.
Верней, эффект такой:
Звонок второй станцией принимается, но поднимаешь трубку -- тишина. В это время звонящий продолжает слышать посылки вызова. Кладешь трубку на вызываемом -- он снова начинает звонить. Ну и т.д.

У Вас точно всё отвечается и звук есть в обе стороны?

У себя проверил на 3.6Са точно не работает также, как и описал grey73.

[grey73]

У себя проверил на 3.6Са точно не работает также, как и описал grey73.

Как сказал harris (по телефону :-) , "Net VM Grp" сделано типа для других целей -- внешняя голосовая почта или что-то типа того, точно не уверен.
Но ведь принцип то ТОТ ЖЕ САМЫЙ!
И звонок как-бы проходит!
Пусть доделают, что ли
Ау, Игорь! Напиши корейцам!
Или в 3.8 оно уже как-то реализовано, и более по-нормальному?

Просто жду вот MPBN на апгрейд -- заработает или нет? и какой механизм?

[harris]

Как сказал harris (по телефону :-) , "Net VM Grp" сделано типа для других целей -- внешняя голосовая почта или что-то типа того, точно не уверен.
Но ведь принцип то ТОТ ЖЕ САМЫЙ!
И звонок как-бы проходит!
Пусть доделают, что ли
Ау, Игорь! Напиши корейцам!
Или в 3.8 оно уже как-то реализовано, и более по-нормальному?

Просто жду вот MPBN на апгрейд -- заработает или нет? и какой механизм?

Да, принцип тот же самый. Но кто именно это заказывал (страна-заказчик), для каких целей, какие были доп. требования - неизвестно. Посему неизвестны и детали, как это реализовано.
ИМХО, возможно проблема в лицензиях (Net Enable) + Join/Reroute...

В версии 3.8 сделано уже по нашему запросу: в ПГМ 144 добавлена возможность назначить вызов на Net Number (номер, прописанный в ПГМ324. А уж за этим номером может стоять как конкретный абонент другой станции, так и Hunt-группа). При этом вызов должен быть назначен только на Net Number и более никуда.
При этом станция не замыкает шлейф СО линии, пока нет ответа от сетевого абонента.

[Alexey A. Astash...]

Что именно "глючное"???

Перестал работать Mobile Extention через SIP:
сейчас работает так на релизе 3.8:
Станция B --> H.323 --> Ext.Станция А <--> SIP sipnet.ru <--> Mobile Extention
это очень важная фукция, как правда потом выяснилось что ее не заявили официально в 3.8.

Должно быть так:
Станция B <--> H.323 <--> Ext.Станция А <--> SIP sipnet.ru <--> Mobile Extention

На одной версии точно работало (не совсеми провайдерами SIP) например с Zebra Telecom эта функция отрабатывала наура, даже говорить было отлично (может из-за кодека g.711 хотя я непомню использовали мы его на тот момент уже или еще нет т.е. был g.729).
А вот с sipnet.ru связь устанавливалась нормально в таком режиме
Станция B <--> H.323 <--> Ext.Станция А <--> SIP sipnet.ru <--> Mobile Extention
Но абоненты друг друга уже не слышали, гдето несовместимость с кодеком выходила (G.729 использовали)

Я еще неуспел проверить работу Firewall Usage ON/OFF (болел, но на неделе постараюсь)
На счет других глюков пока не буду ничего говорить, пока не буду полностью уверен, но похоже что пока все нормально.

[Alexey A. Astash...]

Как именно моделировали зависания во время разговора? Физически рубили канал, или как? Блин, хороший у Вас провайдер (это я насчет QoS). Не провайдер, а мечта! Нам бы такого...
По поводу снифера, так у меня просто нет слов... Станция всё-таки не утюг...

Моделяция шла обрывом линии DSL на бридже, соответсвенно бридж стоит за основным шлюзом который прописан в станции. Отсюда получается что станция в сети, основной шлюз тоже в сети с бриджом, станция видит основной шлюз, станция посылает пакеты, но пакеты не могут просто дойти до конечной станции поскольку из-за физического обрыва линии дальше пакеты не идут пока бридж не выйдет на связь.
Да просто ломает снифать линию, она находится в другом VLAN в котором не выделялось отдельных портов для сниферов, можно конечно и основным шлюзом снифать, да разбираться неохота, в целом и так пока поянтно что проблема в прошивке VOIBE

[grey73]

Моделяция шла обрывом линии DSL на бридже, соответсвенно бридж стоит за основным шлюзом который прописан в станции. Отсюда получается что станция в сети, основной шлюз тоже в сети с бриджом, станция видит основной шлюз, станция посылает пакеты, но пакеты не могут просто дойти до конечной станции поскольку из-за физического обрыва линии дальше пакеты не идут пока бридж не выйдет на связь.

Я уже писал, и вроде даже в этой ветке, правда, не про VOIBE, а про VOIB.

Делаете VPN на роутер поближе к другой станции, и проблема решается.
В смысле DSL падает, VPN почти мгновенно тоже падает.
Соответственно, станция начинает получать не таймауты, а Unreacheble.
Помогает от зависов VOIB на 100%.
Как сделал VPN, так проблема больше не повторялась.

[Alexey A. Astash...]

Я уже писал, и вроде даже в этой ветке, правда, не про VOIBE, а про VOIB.

Делаете VPN на роутер поближе к другой станции, и проблема решается.
В смысле DSL падает, VPN почти мгновенно тоже падает.
Соответственно, станция начинает получать не таймауты, а Unreacheble.
Помогает от зависов VOIB на 100%.
Как сделал VPN, так проблема больше не повторялась.

Ломает делать VPN поверх VPN

[grey73]

При этом станция не замыкает шлейф СО линии, пока нет ответа от сетевого абонента.

Замечательно! Молодцы!
Но по телефону было сказано, что там "не всё гладко" -- что, всё-таки есть проблемы?

И еще интересует проброс в обратную сторону -- я делал с помощью добавления в пгм324 кода выхода на PSTN.
Но при этом любой на любом телефоне независимо от COS может набрать этот самый код выхода, и получить доступ к СО. Как бы это заблокировать? И оставить только выход с внешней станции через этот код доступа?

Или в 3.8 по-другому сделано?
Или вообще в принципе есть ещё механизм, а я про него не знаю?

[grey73]

Ломает делать VPN поверх VPN

Фсяко!

Лучше параллельно второй сделать, чтоб АТС с основной сеткой вообще не пересекались. В VLAN их, и персональный VPN им. И этому VPN'у выставить QoS правильно -- еще и качество связи вырастет.

[Alexey A. Astash...]

Фсяко!

Лучше параллельно второй сделать, чтоб АТС с основной сеткой вообще не пересекались. В VLAN их, и персональный VPN им. И этому VPN'у выставить QoS правильно -- еще и качество связи вырастет.

Ну АТС и так в одельной VLAN+QoS (писал выше), а вот VPN предоставляет провайдет (3го уронвня) поверх этого VPN не вижу смысла вешать еще один VPN специально для АТС.

[Alexander Y. Leo...]

Возврат к старой прошивке (2.0Ca), похоже, устранил проблему с зависаниями VOIBE с новейшей прошивкой (2.1Cb) во время time-out'ов в канале связи!
Натурный эксперимент показал, что при одинаковых условиях 2.1Cb виснет, а 2.0Ca -- нет.

Здравствуйте! Есть ли уже прошивка для VOIBE новее чем 2.1Cb?
А я бы её проверил на предмет работы на обрывающемся канале...

[AXEL]

пока нет

[Alexander Y. Leo...]

...А то ж у версии 2.0Са своих "глюков" хватает.

Например, беспричинное выключение сетевого интерфейса и/или пропадание VOIBE из списка плат УАТС -- если смотреть через telnet командой bs, то в списке плат её не видно; помогает с переменным успехом или перезапуск платы, или перезапуск УАТС, или выключение питание УАТС. Пока наблюдаю это на двух УАТС, установленных в разных местах (городах), подключенных к разным типам сетевого оборудования.

[AXEL]

сегодня на сайте выложим новую версию платы VOIBE
Проверили немного, подвисания вроде нет.
2.1Dc
а пока держите на форуме.

Прикрепленные файлы

 Gs30H21Dc.zip ( 1,06 мегабайт ) Кол-во скачиваний: 14

 

[Alexey A. Astash...]

сегодня на сайте выложим новую версию платы VOIBE
Проверили немного, подвисания вроде нет.
2.1Dc
а пока держите на форуме.

УРААА!!! РАБОТАЕ ОТЛИЧНО РЕВЛЬНО ИСПРАВИЛАСЬ ПРОБЛЕМА!!!
YEEESSS!!!!
Всем качать и ставить

[Pritex]

На VOIM IPLDK-20 тот же глюк с подвисаниями . Прошивка GS66H-B.1Ce .
Есть ли новая микропрограмма , а то достало уже, начальство мозг проело , внедрение в другие офисы приостановилось до решения данного вопроса.

[Alexey A. Astash...]

На VOIM IPLDK-20 тот же глюк с подвисаниями . Прошивка GS66H-B.1Ce .
Есть ли новая микропрограмма , а то достало уже, начальство мозг проело , внедрение в другие офисы приостановилось до решения данного вопроса.

Станции ipLDK-300 3.8Bf

Народ начал жаловаться что стала связь рваться, во время разговора по IP (любой тип), после наступления какого определенного момента времени связь теперь рвется через каждые 10 секунд разговора...
во время разговора наступает тишина затем идет сигнал Err в трубку, меня пока нет в офисе незнаю что происходит.
Канал связи при этом стабилно работает, единственное что может меняться это автоматически пакеты по MPLS могут менять по середине маршрутизатры на более быстрые в настоящий момент времени. но на конечную свзяь это никогда не влияло, может и сейчас какбы проблема не в этом.
Думаю нужно открыть закрепленную тему:
Статистика работы VOIBE после перепрошивки на 2.1Dc. без этой статистики думаю производителю сложно будет что либо объяснить.
ЗЫ. Последнее что было проверено это MobileExtention на SIP с приходом звонка по H.323 после этого мнуты через 3 позвонили и сказали что связь с тем офисом на котором пробовался мной Mob.Ext. односторонняя вместо голоса какието трески-хрипы или вообще тишина потом отбой. с другой стороны слышно нормально.
Может это конечно с Mob.Ext. не связано.

[Alexander Y. Leo...]

Прошил на всех станция (версия основного ПО станций: 3.7, SIP не используется).
Полет нормальный.

Список изменений этой версии уже доступен?

[K13A]

тоже имею проблему с пропаданием ip-связи...
2 раза где-то за неделю было...

С одной стороны ipLDK-300, с ней все ok, перезапускать не приходится, воткнута в маршрутизатор d-link dir-100 с выставленным максимальным приоритетом, ибо канал общий с инетораздающим компом, с другой стороны ipLDK-60, воткнута в 4х портовый adsl модем dlink вместе с опять же инетораздающим компом, приоритеты на модеме не выставляются.

Симптомы сбоя: если пытаться звонить со стороны 300й станции - долгая тишина, потом отбой, со стороны 60й - сразу пишет "линия занята", хотя все каналы voib свободны, лечится мгновенно перезагрузкой ipLDK-60...


Что делать? :-)

[K13A]

PS:

версия voib на ipLDK-60 - 2.1Dp
ipLDK-300 - 4.3Ae

[harris]

PS:

версия voib на ipLDK-60 - 2.1Dp
ipLDK-300 - 4.3Ae

ОК. А все-таки, если при сбое в связи попробовать перезапустить не 60-ку, а только плату VOIB на 300-ке ??? Попробуйте...

[K13A]

ok, буду ждать сбоя :-)

[K13A]

теперь в работе две 60ки, сбои участились, лечатся перезагрузкой плат voib 60к, перезагрузка платы на 300ке не помогает...

[K13A]

нет идей ни у кого?

[Alexey A. Astash...]

нет идей ни у кого?

попробуйте восстановить стабильность канала связи и просмотреть частоту Retrain VPN..
А также простестировать канал на потери используя нечто программы mtr.
Все сбои между АТС происходят в первую очередь из-за прошивки с ошибками которые точно не отслеживают потерю связи и не отпускают канал, и вобще вешают поаты VoIP.
И потом уже такие подвисоны напрямую зависят от качества и стабильности каналов.

[K13A]

прошил 300ку до 3.8, вроде бы пока полет нормальный, будем ждать ...

[Alexander Y. Leo...]

Ещё раз прошу прощение за поднятие старой темы.

Обнаружил необъяснимый (для меня) глюк в работе мини-АТС.
Конфигурация:

Код

SLOT  BRD-TYPE   FW-Ver.  BRD-ISSUE  SERVICE
---- ----------  -------  ---------  -------

   0  MPBN         [b]3.7Ce[/b]
   1  DSIB                             INS
   2  SLIB12                           INS
   3  CLCOB8                           INS
   4  VOIB         [b]2.1Dс[/b]       21       INS
   5  ....
   6  ....
   7  ....
   8  ....
   9  ....
  10  ....
  11  ....
  12  ....

Это один кабинет ipLDK-100.

К блоку питания подключёны внешние батареи.
Блок батарей собран по схеме из 4-х батарей 12В 17мАч (в сборе дают напряжение 24В).

Когда отключается э/энергия мини-АТС продолжает работать от батарей. А вот плата VOIBE падает в свой привычный "обморок" -- не откликается на сетевые запросы (в том числе и на ICMP) и, конечно, VoIP-взаимодействие тоже отсутствует. "Молчание" VOIBE "лечится" перезагрузкой всей мини-АТС из telnet-сессии. Интересно, что просто выключение/включение питания не помогает гарантированно (может с раза 3 или 4-го). Также не помогает и перезапуск мини-АТС из pcAdmin'а (c системного телефона не пробовал).

Нагрузка на блок питания:

Код

POWER USAGE PER RACK
----------------------------------------------------------
PSU/RACK      +5V         -5V         +30V       REMARK
----------------------------------------------------------
PSU           4.00 A      0.50 A      3.00 A     120 W
----------------------------------------------------------
RACK #1       3.10 A      0.25 A
RACK #2       0.00 A      0.00 A
----------------------------------------------------------

POWER USAGE PER SLOT
----------------------------------------------------------
SLOT    BOARD       +5V            -5V           +30V
----------------------------------------------------------
RACK #1
  ..     MPB        868.00 mA      85.00 mA      10.00 mA
  ..     RGU          0.00 mA       0.00 mA     120.00 mA
  ..     PFTU         0.00 mA       0.00 mA      55.00 mA
  01     DSIB       100.00 mA      45.00 mA     221.70 mA
  02     SLIB2E     225.00 mA      36.00 mA     460.00 mA
  03     CLCOB8     405.00 mA      80.00 mA       0.00 mA
  04     VOIBE     1200.00 mA       0.00 mA       0.00 mA
         Option     300.00 mA       0.00 mA       0.00 mA
TOTAL             3098.00 mA     246.00 mA     866.70 mA
----------------------------------------------------------
RACK #2
TOTAL                0.00 mA       0.00 mA       0.00 mA
----------------------------------------------------------

Посоветуйте, пожалуйста, что ещё проверить или заменить в этой системе?

Покамест "тупо" подключим мини-АТС к ближайшему ИБП, к которому подключены серверы и сетевое оборудование (коммутатор, маршрутизатор), через которое мини-АТС связано с ЛВС и удалёнными сетями.

[Alexander Y. Leo...]

Плату VOIBE на ремонт или замену?
Или БП?

Есть ли у кого в практике такие или подобные случаи?

[vldmr]

при питании от батарей, когда VOIB не живет, из монитора команду дайте BC что бы понять теряет или нет проц плату

[Alexander Y. Leo...]

при питании от батарей, когда VOIB не живет, из монитора команду дайте BC что бы понять теряет или нет проц плату

Специально съездили к этой мини-АТС "поближе", проверили испытания (это в удаленном подразделении).

Выяснилось следующее:
- Батареи мини-АТС были выключены -- кабель от внешних к станции (в БП) подключен , тумблер (который включает батареи) -- выключен. (Диверсанты не пойманы, к сожалению). Т.е. я прошлый раз неправильно описал ситуацию. Просто на той точке есть бензогенератор и тамошние сотрудники его довольно быстро включают. А от него запитана и э/розетка, в которую включена мини-АТС. Поэтому я и думал, что когда нет "городской" э/энергии, то АТС продолжает работать на своих аккумуляторах.
- Тумблер включили, подключили другие внешние батареи (привезли с собой новые и предварительно заряженые).

Провели небольшое испытание:
- При включенных батареях и при отключении внешнего э/питания мини-АТС продолжает работать об батарей, плата VOIBE не теряется.
- Если выключить батареи (тумблером или отсоединить кабель), а затем выключить и включить внешнее э/питание, то конечно же мини-АТС выключается , затем запускается, но примерно в 2 из 3 случаев плата VOIBE не стартует (выпадает из конфигурации -- в telnet по команде bc её не видно). Остальное в мини-АТС работает штатно. "Вернуться на место" плате VOIBE помогает или повторное выключение/включение питания (но зачастую по несколько раз нужно выключить/включить) либо перезапуск командой reboot из telnet-сессии (гарантированно помогает, по крайней мере всегда приводило к тому, что плата VOIBE после перезагрузки в конфигурации появлялась) -- я об этом уже писал в одном из прошлых сообщений.

Уезжая, подключили и включили внешние батареи, да ещё от ближайшего ИБП всю конструкцию запитали. В общем, такими вот внешними средствами вероятность возникновения проблемы была понижена.

Сообщение отредактировал Alexander Y. Leonov - 8.4.2009, 12:32

[vldmr]

Довольно странно. Многократно Включали / Выключали / Включали - такого не замечено

[stasmar]

Недавно стал посетителем этого форума. Инетересно было узнать. Про объединение LDK по радиоканалу. И про зависание миниАТС. У нас в городе поток Е1 дорогой, а необходимость объединения АТС была жизненно необходима. Расстояние между LDK300 - 4.7 км. Радиорелейку - долго разрешение ждать. Воспользовался атмосферной оптикой по Ethernet 100 мегабит. Заодно и сетки двух участков - объеденены. Так вот по 8-ми каналам 100 номеров одной АТС со 100 номерами другой, бывает дней по пять не отваливается. Если зависает - то только одну плату перезагружаю, вторая почему-то не разу не подвисала. Далее жду апгрейта оборудования атмосферной оптики - более надежного. Пару идей по модернизации я сам им подкидывал, после которых сетка нашей фирмы зависать из-за этого оборудования перестала. Сетка вообще работает как зверь. Только когда туман - обрывается.