Это, похоже, не DFL

Взял Zyxel P2602H (ADSL+4ports HUB + FXS SIP x2).
Настроил его в аварийный режим (есть там такая фишка - BackupGateway через которую VoIP может перекидываться по другому маршруту, когда DSL канал недоступен)
Т.е. перестроил его как двухпортовый SIP шлюз.

Настроил ему LAN c тем же IP, что и один из SPA-8000 и воткнул в DMZ вместо Linksys.
(чтобы не переписывать правила и заодно выявить в них косяки, если таковые есть)

И этот гад, при всем при этом работая через ж...у умудрялся легко перерегистрироваться при failover на резервный маршрут и так же нормально перерегистрироваля при возврате на основной маршрут.
И во всех случаях звонки проходили нормально с двухсторонней слышимостью.

SPA и не только 8000 перерегистрируются лишь в том случае, если после переключения маршрута секунд на 10-15 выдернуть оба RJ45 из обоих WAN, а потом снова воткнуть.

Выводы:
1. Косяк в настройке шлюзов (причем какой то хитрый и непрозрачный, о котором я понятия не имею).
2. Косяк SIPNET.
3. Косяк прошивки. (причем всех SPA, еще пробовал свой домашний SPA-2102, ведет себя абсолютно так же как и 8000)

По первому и второму пункту буду тиранить SIPNET.
Если не поможет, придется пинать Сиську по теме корявых прошивок, ибо нефиг было Sipura, оно же Linksys, приобретать для расширения ассортимента LowEnd!

И я, дурак, повелся на рекомендации специалистов того ISP, канал которого мы недавно подключили. (Типа, они городской телефон по своей сети раздают исключительно через SPA и все работает просто замечательно...)
Надо было не экономить казенные деньги, а брать шлюзы AudioCodes, как сначала и планировал.

Если ни чего не поможет, то придется срочно форсировать подъем своей локальной Звездочки и туда регить все SPA без failover.
А Астер пусть уже разбирается со всеми внешними VoIP линиями через failover.

ЗЫ: На SPA перестроил SIP сигнализацию с UDP на TCP - вроде бы начал перерегистрироваться, но как то коряво и очень неспеша...
Непонятно, почему ZyXEL нормально перерегистрируется по UDP...
...однозначно буду пинать support sipnet.

Ну, могу сказать что у меня дома тоже 2102, работает через DFL-800 до сипнет вообще без NAT-правил с поддержкой SIP и других порт-маппингов. Исходящие звонки отлично, слышимость отличная, входящих соответственно нет (и не надо). Редко бывают моменты не регистрации девайса, но почему так и не выяснил (некогда).

Вам в вашем случае наличия корпоративной IP АТС я бы посоветовал шлюзы через allow пустить до Asterisk, а тот пуская уже решает по внешним линиям. Конечно, если такое возможно организационно.

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc

Ну дык мне то надо.
Астер будет дай бог к весне, если будет вообще. По этому я и хотел, как временное решение все завязать через кучу дочерних account-ов sipnet.

Но возвращаемся к нашим, точнее моим, баранам.

После переругиваний с новым провом и разборок с sipnet, не приведших к положительным результатам, были произведены дополнительные исследования по теме. Что характерно, в них даже VoIP GW не участвовали. Похоже, проблема локализована, но решить я ее не смогу самостоятельно, без соответствующих изменений в firmware DFL.

Описание лабораторной работы:

1. DFL 800.
2. К LAN подключен комп с XP. Оттуда наблюдаем происходящее, пингуем, трассируем.
3. WAN1 ADSL, WAN2 - еще один ADSL.
4. на DFL настроена простейшая конфигурация failover в таблице main.
Все остальное, связанное с балансировкой и альтернативной маршрутизацией отключено.
5. Для чистоты эксперимента маршруты мониторим на DFL исключительно по ICMP. Мониторим, пусть, скажем, чисто 8.8.8.8
6. Для эмуляции ситуации failover ни в коем случае не выдергиваем RJ45 разъемы из WAN DFL-ки. (Иначе это будем менее заметно)
Дергаем исключительно телефонные шнурки из ADSL.

(Вариантов для подобного стенда море. Важно лишь то чтобы исследуемый в I-Net или его эмуляторе хост был доступен и по основному и по резервному маршрутам, так же мониторинг основного и резервного маршрутов на DFL и эмуляция ситуации failover должны исключить все связанное с выдергивание RJ45 из WAN и отключение активного сетевого оборудования подключенного непосредственно к WAN DFL.
Зачем это нужно, станет понятно в конце описания.)

Теперь, собственно, лабораторка:
C компа, который в LAN пингуем какой ни-ть хост в I-Net.
Пусть будет, например, ntp.chg.ru

Стандартные для винды 4 пакета проходят.
Трассируем маршрут. Убеждаемся что все правильно. Это основной маршрут.
Создаем ситуацию failover путем выдергивания телефонного кабеля из ADSL на основном маршруте.
Ждем, пока отработает мониторинг по ICMP на DFL-ке.
Повторяем пинг и трассировку. Все в норме. Резервный маршрут.

Втыкаем телефонный кабель в ADSL. Ждем возвращения на основной маршрут.
Опять пингуем и трассируем. Возврат на основной маршрут произведен.

Меняем условия эксперимента.
На сей раз откроем для пингования три окошка.
В первом, контрольном, будем повторять то, что уже делалось ранее.
Во втором запустим ping X.X.X.X -t до эмуляции ситуации failover.
В третьем ping -t после failover
По исчезновении ситуации failover просто посмотрим что получилось.

Не буду дальше заниматься описательной частью, но вывод такой:
При переключении маршрута открытые соединения по дохлому маршруту DFL самостоятельно не сбрасывает.

Вот почему у меня шлюзы нормально перерегистрировались, когда я выдергивал RJ45 из WAN. По любому, после выдергивания кабеля DFL-ке приходилось сбрасывать открытые соединения на дохлом маршруте.

А при условии что на шлюзах был активирован NAT Keepalive, чтобы не было проблем с входящими звонками, это еще усугубляло ситуацию.

Даже если в DMZ DFL-ки поставить полноценный Астер проблема с внешней перерегистрацией при переключении маршрутов на DFL все равно останется и с вероятностью ~100% проявится уже на Астере.

Проблема локализована. Как решать не знаю.

Попробуйте командой connections -close из консоли прибить подключение - перерегистрируется шлюз?

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc

Я, конечно, попробую, но уже в понедельник вечером...

ЗЫ: Проблема, похоже, существенно глубже, чем перерегистрация голосовых шлюзов - любая сетевая задача, работающая во время переключения маршрута продолжает висеть на дохлом маршруте до ее прерывания вручную и, опять же, вручную запуска заново.
Возможно, DFL задачи на дохлых маршрутах и сбрасывает самостоятельно, но дождаться этого радостного момента у меня ни разу не хватило терпения. Ждал минут по 15...

Задачи, работающие с ICMP и UDP точно подвисают на старом дохлом маршруте, а TCP, вроде бы, в зависимости от алгоритмов запущенной задачи, использующей сеть, может перескакивать на другой маршрут самостоятельно.
До тестирования всяких туннельных протоколов типа GRE руки еще не дошли.

Проведена лабораторная работа по рекомендованной методике

1. В коммандной строке на хосте с адресом 192.168.4.201 (хост подключен к интерфейсу LAN) было запущено:
> ping ya.ru -t
Пошли нормальные icmp ответы.

2. Сэмулирована ситуация failover на основном канале.

3. Маршрут перещелкнулся на резервный.

4. ping ya.ru -t не переключилась и подвисла на старом маршруте.
Пошли icmp ответы Превышен интервал ожидания

5. Был выполнен ручной сброс соединений для этого хоста по SSH.
(PuTTY подключался из I-Net к WAN2 (WAN резервного канала) с совершенно третьего компа.
Т.е. в офисе сидел человек на хосте 192.168.4.201 с телефонной трубой в руках и выполнял пингование и трассировку, а я из дома, тоже с телефонной трубой в руках по SSH сбрасывал подвисшие соединения. Команды connections -close -all и connections -close -xxxiface=xxx были использованы в начале до детальной локализации проблемы. Оказалось, что вполне хватает сброса конкретного подвисшего хоста команды connections -close -srcip=X.X.X.X)

Скриншот PuTTY при выполнении сброса соединений для этого хоста:

DFL-800:/> connections -close -srcip=192.168.4.201
State Proto Source Destination Tmout
-------- ------- --------------------------- --------------------------- ------
ZOMBIE UDP lan:192.168.4.201:59770 w2_Inko:83.234.208.10:53
ZOMBIE ICMP lan:192.168.4.201:1024 w1_CenterTelecom:77.88.21.3:1024
ZOMBIE UDP lan:192.168.4.201:63714 w2_Inko:83.234.208.10:53
ZOMBIE UDP lan:192.168.4.201:53672 w2_Inko:83.234.208.10:53
ZOMBIE UDP lan:192.168.4.201:49269 w1_CenterTelecom:192.168.5.1:53
ZOMBIE UDP lan:192.168.4.201:59770 w1_CenterTelecom:192.168.5.1:53
ZOMBIE UDP lan:192.168.4.201:55387 w2_Inko:83.234.208.10:53
ZOMBIE UDP lan:192.168.4.201:49390 w1_CenterTelecom:192.168.5.1:53
ZOMBIE UDP lan:192.168.4.201:53672 w1_CenterTelecom:192.168.5.1:53
ZOMBIE UDP lan:192.168.4.201:49390 w2_Inko:83.234.208.10:53
ZOMBIE UDP lan:192.168.4.201:49269 w2_Inko:83.234.208.10:53
ZOMBIE UDP lan:192.168.4.201:63714 w1_CenterTelecom:192.168.5.1:53
ZOMBIE UDP lan:192.168.4.201:55387 w1_CenterTelecom:192.168.5.1:53
DFL-800:/>

6. После выполнения этого сброса через PuTTY сразу пошли ответы icmp в окне из котрого выполнялась команда ping -t с хоста 192.168.4.201.

7. Сэмулирована ситуация восстановления на основном канале.

8. Маршрут перещелкнулся на основной.

9. Снова подвисание ping -t, теперь уже при возврате на основной маршрут.

10. Снова скриншот PuTTY при выполнении сброса соединений для этого хоста:

DFL-800:/> connections -close -srcip=192.168.4.201
State Proto Source Destination Tmout
-------- ------- --------------------------- --------------------------- ------
ZOMBIE ICMP lan:192.168.4.201:1024 w2_Inko:77.88.21.3:1024
ZOMBIE UDP lan:192.168.4.201:56954 w1_CenterTelecom:192.168.5.1:53
ZOMBIE UDP lan:192.168.4.201:56954 w2_Inko:83.234.208.10:53
ZOMBIE UDP lan:192.168.4.201:56116 w1_CenterTelecom:192.168.5.1:53
DFL-800:/>

11. Снова пошли нормальные ответы icmp уже с основного маршрута.

12. Если не выполнять сброса соединеий вручную через SSH, то нормальные ответы icmp (См. п. 4 .) возобновляются при возврате на основной маршрут. (Т.е. пропускаются п. 5,6 и 9,10).
Однако, в реальных "боевых" условиях время выхода из ситуации failover ни когда не известно. Значит ли это, что не переключившиеся соединения будут висеть в таком состоянии сколь угодно долго, до отмены ситуации failover?

13. Если после переключения маршрута запустить новое сетевое приложение, то оно начнет работать уже по новому маршруту, и в то же время сетевые подключения которые еще были открыты на старом маршруте так и останутся зомбиками.
Так же замечено следующее: Пока есть зомбики на дохлом маршруте к тому же хосту с этого же компа обратиться нельзя уже по новому маршруту, хотя к любым другим хостам можно.
================================================================
!!! При ручном сбросе соединений через SSH подключение командой типа:
connections -close -srcip=X.X.X.X
Хост X.X.X.X нормально начинает работать на новом маршруте.
(Это относится и к перерегистрации VoIP шлюзов по новому маршруту.)

На udp:53 внимание заострять не имеет смысла.
Точно такая же реакция наблюдается и при пинговании по IP без задействования DNS.

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


Вот такие результаты получились.


И что теперь делать дальше?

Попробуйте поставить последнюю прошивку на DFL 2.27 с ней исправлены некоторые проблемы с VoIP.
http://ftp.dlink.ru/pub/FireWall/

_________________
Форум не подразумевает под собой быстрый ответ, хотите быстрый и квалифицированный ответ - звоните в техподдержку компании D-Link 8-800-700-5465

Эти косяки как раз на v.2.27!!!
И проблемы не только с VoIP но и с перемаршрутизацией любого UDP трафа и вообще, похоже, любого типа трафа с негарантированной доставкой!!!

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

IMHO, вместо того, чтобы заниматься всякой ерундой, типа русификации интерфейса, программерам из D-Link нужно сначала вылизать функционльность оси, которая на DFL-ках!!!

Вот еще один скрин SSH. По адресу 192.168.6.65 в DMZ висит Linksys SPA-8000.
После ручного сбороса соединений шлюз сразу же нормально регистрировался на новом маршруте.


А вот этот скрин исключительно для Вас, уважаемый Vitaliy Korkunov (Сотрудник D-LINK):

Пока я вижу единственный выход:
1. Огрести по полной программе от Генерального директора, за то что с моей подачи купили оборудование, которое не делает того, что должно делать.
2. После прихода в себя выкинуть DFL, взять отдельный комп с 3-мя сетевухами, взять бубен, взять Linux или FreeBSD и нашаманить какое ни-ть работоспособное решение.

Так?
(Правда после этого плакал мой зарубежный отпуск, т.к. за свой счет придется компенсировать купленные 2 DFL-800 и 1 DFL-210...)

Драматизировать я бы не стал.
Как минимум, вы всегда можете написать простейший скрипт, который будет контролировать состояние канала и выполнять команду.

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc

Убедитесь, что у вас в в System Advanced settings, включен UDP Bidirectional keep-alive.

Что у вас с маршрутизацией? У вас я та понял 2 провайдера.

_________________
Сообщения в PM игнорируются, задавайте вопросы на форуме.

Таже самая проблема, не маршрутизируются на резервный канал UDP пакеты VoIP.
Что делать?

хы...я тут немного разобрался с теорией работы SIP протокола и железок которые его поднимают
Вообщем получается если сменить канал то железка VoIP телефонии не знает об этом и пытается восстановить связь. Сервера её не понимают и в итоге чтоб поднять SIP необходимо полностью перерегистрировать железку на SIP сервере.