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) сначала долгая тишина в трубке, потом короткие гудки.
В таком состоянии мини-АТС может находится несколько часов (пока не перезапустишь) -- сама связь не восстанавливает.

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

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

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

[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