Comments 6
А почему не использовали net watch, как здесь?
Действительно? почему не использовать Netwatch?
У меня, например используется алгоритм такой: определяем маршруты до пингуемых мест, пингуем 1-ip через isp_1, второй через isp_2
при потери пакетов до адресата 1-ip, выполняем скрипт (одна строка) "/ip route enable [find dst-address=0.0.0.0/0 and gateway=ххх.ххх.ххх.ххх and distance >= 3;" — т.е. меняем весомость роута первого провайдера и отправляем траффик через резервного провайдера, при появлении пингов возвращаем. тоже самое и со вторым провайдером. за пару лет проблем не наблюдалось, работает отлично без нареканий.
все гениально просто!
У меня, например используется алгоритм такой: определяем маршруты до пингуемых мест, пингуем 1-ip через isp_1, второй через isp_2
при потери пакетов до адресата 1-ip, выполняем скрипт (одна строка) "/ip route enable [find dst-address=0.0.0.0/0 and gateway=ххх.ххх.ххх.ххх and distance >= 3;" — т.е. меняем весомость роута первого провайдера и отправляем траффик через резервного провайдера, при появлении пингов возвращаем. тоже самое и со вторым провайдером. за пару лет проблем не наблюдалось, работает отлично без нареканий.
все гениально просто!
Там много моментов, почему не подходит. Главный — что роуты на статике всегда активны, а если указывать в качестве шлюза интерфейс (что придется делать для PPP), то он не будет активным, когда канал упадет, и приехали. Во-вторых, пинговать один хост — не лучшая идея, с любым хостом может что-то случиться… И в-третьих, очень не хочется держать постоянно активным 3G соединение.
Немного поразмыслив, понял, что неактивные роуты — не проблема, и в принципе через netwatch можно все сделать и для PPP соединений, если игнорировать два других моих аргумента. Но возникает вопрос, делаете ли Вы при включении/отключении роутов ресет текущим соединениям?
Можете поделиться как решается проблема неактивных маршрутов? Кажется роуты на статике тоже могут переставать работать. Например, упало соединение на физическом интерфейсе (кабель порвался). Тогда маршрут для проверки основного канала станет неактивным и Netwatch успешно сделает ping, так и не поняв, что канал упал. Если же резервный канал поднимается только после регистрации падения основного, то Netwatch выполнит переход на резервный канал, а затем снова успешно сделает ping и выполнит скрипт для возврата на мертвый основной канал. Так и будет по кругу…
А вот в собственном скрипте мы можем явно указать интерфейс в команде ping, избежав проблем.
А вот в собственном скрипте мы можем явно указать интерфейс в команде ping, избежав проблем.
Я поначалу тоже так думал. Возможно я неправ, но если посмотреть, как сделано по ссылке в первом комментарии, то в той конфигурации проверочный пинг на 8.8.8.8 пойдет либо через шлюз первого провайдера, либо не пойдет вообще, т.к. маршрута через другие шлюзы на 0.0.0.0 без routing mark нет. Скорее всего роутер скажет dest unreachable для пингов. Когда канал заработает, маршрут до 8.8.8.8 поднимется и пинги пойдут. А весь forward трафик идет по маршрутам с метками, на которых и висит логика.
Интерфейс в команде ping указывать некорректно, в описании к скрипту об этом написано, еще вот ссылочка. Хотя у меня тоже вроде работает, но делать так не стал.
Интерфейс в команде ping указывать некорректно, в описании к скрипту об этом написано, еще вот ссылочка. Хотя у меня тоже вроде работает, но делать так не стал.
Sign up to leave a comment.
Mikrotik: скрипт переключения на резервный канал интернета