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

[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