Добрый день. Возникла такая проблема. У нас имеется шлюз DFL-800 h/w: 2.26.00.06-12649, на WAN1 подключен Провайдер1(резервный) наWAN2 подключен Провайдер2 (основной). Есть локальная сеть 192.168.200.0/24 (LAN) где сидят все пк и сервера и несколько ip-телефонов и сеть в DMZ зоне 10.11.11.0/24 для ip-телефонов, АТСка на основе Asterisk находится в облаке. WAN2 через него в инет идут и LAN и DMZ.
Когда случается авария у Провайдера2 (основной) мы переключаемся на WAN1 резервный и тут возникает проблема подавляющее большинство ip-телефонов независимо где они находятся в LAN или DMZ продолжают пытаться подключиться к АТСке через неработающий WAN2 в отличии от компьютеров которые почти сразу начинают нормально работать через резервный WAN1. Как мы переключаем на резерв: в таблице маршрутизации main понижаем метрику у WAN1 например с 70 до 60 а у WAN2 повышаем с 60 до 70. Пробовал перезагружать IP-телефон но он все равно идет через неработающий WAN2 т.е. у DFL-800 висит старая таблица маршрутизации и ее как-то нужно сбросить. Помогает только перезапуск DFL’ьки. Может есть какая-то команда в CLI чтобы сбросить эту «висящюю» таблицу маршрутизации? Или еще какой-то способ чтобы устройства не использовали старый маршрут?

На DFL для WAN Failover используется метод включения/отключения основного маршрута. Это делается несложно, автоматически и, вроде, ни у кого не вызывает проблем.

Я не очень понимаю, зачем вы это делаете вручную.

http://dlink.ru/ru/faq/383/1974.html

http://dlink.ru/ru/faq/331/1720.html

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

Мониторинг предпочтительнее делать только через ICMP.

И прошивку, конечно, надо обновить до последней 2.27.08.03 FW.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

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

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