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

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

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

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

[AXEL]

делали

[nikol]

делали

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

[Alexey A. Astash...]

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

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

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

[nikol]

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

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

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

[Alexey A. Astash...]

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

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