[grifin.ru]

Есть два "интернета" от разных провайдеров на микротике, за микротиком 3 SIP устройства за НАТом. Все три коннектятся к внешнему астериску.

Первый интернет "падает" Скрипты благополучно удаляют дефолтный маршрут на упавший интернет и основным становится маршрут на резервный канал. SIP устройства благополочно переавторизовываются и работают через резерв.

А вот дальше - интересно:

Восстанавливается основной интернет. Маршрут на него включается, все пакеты с момента включения как-бы должны идти через новый канал но SIP регистрация при этом падает и не восстанавливается пока руками не удалить из таблицы fierwall -> connectoins  соединения смотрящие на SIP сервер.

Это так и должно быть ? если да, то как настроить чтоб небыло таких проблем ?

SIP ALG включен, прошивка - последняя.

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

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

В принципе если объясните мне почему так происходит - думаю до решения я и сам додумаюсь.

Заранее спасибо.

[myth]

conntrack

[grifin.ru]

conntrack

Это понятно, что conntrack, почему он не разваливается по таймауту после того как маршрутизация поменялась ?

И что в таких случаях полагается делать ?

[grifin.ru]

Можно, конечно, тупо в переключающий скрипт прописать удаление всех коннекшеннов с этим Reply Dst. Address

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

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

Подскажите куда смотреть

[grifin.ru]

И, у меня такое ощущение, ято такое залипание только у SIP соединений имеет место быть. А значит это как-то связано с SIP ALG ?

[grifin.ru]

Пока ищу красивое решение, прописал в скрипт:

/ip firewall connection remove [find reply-dst-address~"XXX.XXX.XXX."]

Работает. Но основного вопроса это не отменяет ;)

[myth]

Таймауты по-умолчанию очень большие.

[nkusnetsov]

grifin.ru, соединение однажды установленное будет считаться живым, пока не прилетит явный "fin" или не истечет таймаут бездействия.

Для udp-based SIP важен как раз таймаут. Поскольку в соединении пролетают пакеты qualify, registration renew - в соответствии с sip registration interval, оно постоянно обновляет счётчик-таймер таймаута и соединение поддерживается "живым". Это нормальное поведение.

Так, что Ваш путь - только принудительно сбрасывать состояния соединений при восстановлении основного провайдера.

Изменено 14 марта, 2017 пользователем nkusnetsov

[Saab95]

Сделайте переключение не дефолтными маршрутами, а с помощью маркировки роутов. Тогда все будет отрабатывать без проблем.

[grifin.ru]

Сделайте переключение не дефолтными маршрутами, а с помощью маркировки роутов. Тогда все будет отрабатывать без проблем.

А какая разница ?

На самом деле так и сделано. Прописано два дефолта в разных таблицах и в манагле маргируются роуты. Но там я еще много проблем словил:

Во-первых если регистрация через один "интернет" сделана, а RTP пытался установиться через другой - нихрена не работало. Не стал с этим разбираться, сдела на базе адрес-листов, чтоб один и тот-же IP ходил через один и тот-же интернет.

Потом долго бился с глюками, пока не догадался отключить fasttrack.

При включенном fasttrack маршрутизация первого пакета в соединении шла правильно а потом (когда в  forward'е fasttrack включался, больше пакеты правилами FW не маркировались и все летело через MAIN таблицу. Много времени потерял, пока это понял.

Может, кстати, и первя проблема была из-за fasttrack ?

[Saab95]

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

[grifin.ru]

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

Зачем, я просто рублю коннекшены которые построены через отключаемое соединение.

[Saab95]

Зачем, я просто рублю коннекшены которые построены через отключаемое соединение.

 

Представьте что работает интернет 1 и вдруг пропала связь. У клиентов сети соединения установлены с адреса интернета 1, и на всех сайтах они авторизованы с этого адреса. Тут связь поменялась на провайдера 2, в зависимости от настроек сайтов, доступ по авторизованным сессиям может не пропасть, а может и пропасть. Тут снова заработал интернет 1 и все соединения пошли по нему, на сайтах опять путаница - запросы стали снова приходить с другого адреса.

 

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

[grifin.ru]

в зависимости от настроек сайтов, доступ по авторизованным сессиям может не пропасть, а может и пропасть

Вы предлагаете оборвать принудительно все сессии. Зачем ? Те, которые пропадут - пропадут сами. Зачем рва те, которые смогут продолжить работать ?

Тем более когда я рву НАТ коннекшены то новые установятся скорее всего, уже с другим номером исходящего порта.

[Saab95]

Если вы вынесете НАТ на 2 сторонних микротика, а управлять кто куда идет будете с третьего, то никаких проблем не будет.