Parrot Опубликовано 24 июня, 2019 · Жалоба Доброго времени. Скорее всего вопрос заезжен до блеска, но судя по отсутствию 100% работающего решения до сих пор он всплывает в тех или иных аспектах. Прошу понять и помочь. RB3011, 6.43.2. 2 канала интернета. Основной pptp (pptp-Aichyna1), резервный pppoe (pppoe-byfly). Оба без статических IP. Никаких сверхестественных наворотов нет. Резервирование сделано через обычный netwatch пингованием адреса 8.8.4.4. И этот адрес в роутах прописан на основной канал pptp-Aichyna1. Шлюз по-умолчанию прописан руками с разными дистанциями для разных каналов и отключён для резерва. Если 8.8.4.4 перестаёт пинговаться, активируется маршрут резерва, у которого вес больше (distance 1). down: /ip route enable [find comment="BYFLY_ROUTE"] up: /ip route disable [find comment="BYFLY_ROUTE"] Короче, всё просто как грабли. Но пару дней назад эти грабли вдруг дали сбой. А именно - после активации резервного канала адрес 8.8.4.4 начинает пинговаться... через резервный канал! (как и все прочие маршруты, прописанные на другой интерфейс) И начинается мигалка с интервалом в 15 сек (netwatch то up, то down). Раньше такого не было. Прошу не кидать тряпками, возможно где-то что-то упустил? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxkst Опубликовано 24 июня, 2019 · Жалоба Основной канал может загнуться по двум причинам - обрыв до шлюза, или проблема после шлюза. В первом случае шлюз будет Unreachable, маршрут до 8.8.4.4 не активен. Во втором случае Reachable - и маршрут до 8.8.4.4 будет активен. Я такое резервирование никогда не делал, но по логике я бы пинг через основной канал до 8.8.4.4 прибил гвоздями. Попробуйте заблочить фаерволом пинг до гугла от роутера через резервный канал, должно сработать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Parrot Опубликовано 24 июня, 2019 · Жалоба Только что, maxkst сказал: Попробуйте заблочить фаерволом пинг до гугла от роутера через резервный канал, должно сработать Уже когда писАл этот тред, появилась именно эта мысль. Я не особо силён в настройках - если вам не сложно, подскажите, каким образом это сделать (в input?) 1 минуту назад, maxkst сказал: В первом случае шлюз будет Unreachable, маршрут до 8.8.4.4 не активен Именно в этом случае, соединение pptp лежит. Соотв. маршрут unreacheble. Микротик тогда его вообще не использует? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 24 июня, 2019 · Жалоба По правильному пинговать нужно шлюз каждого канала (а не какой-то посторонний узел в интернете), с заданием source-ip и уменьшением ttl. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxkst Опубликовано 24 июня, 2019 · Жалоба 1 минуту назад, alibek сказал: По правильному пинговать нужно шлюз каждого канала (а не какой-то посторонний узел в интернете), с заданием source-ip и уменьшением ttl А если интернет упал за шлюзом? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 24 июня, 2019 · Жалоба А если узел на пинг не отвечает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Parrot Опубликовано 24 июня, 2019 · Жалоба 1 минуту назад, alibek сказал: По правильному пинговать нужно шлюз каждого канала (а не какой-то посторонний узел в интернете), с заданием source-ip и уменьшением ttl. По-правильному вариантов масса. Мне же нужно как можно проще. У меня в 100% случаев просто отваливается pptp интерфейс. Отсюда и пляшу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxkst Опубликовано 24 июня, 2019 · Жалоба 3 минуты назад, Parrot сказал: Уже когда писАл этот тред, появилась именно эта мысль. Я не особо силён в настройках - если вам не сложно, подскажите, каким образом это сделать (в input?) Лучше output Только что, alibek сказал: А если узел на пинг не отвечает? Какой? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 24 июня, 2019 · Жалоба Проверяемый. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxkst Опубликовано 24 июня, 2019 · Жалоба Только что, alibek сказал: Проверяемый. 8.8.4.4? тогда надо бежать за противогазом, и в бункер, ибо третья мировая началась )) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Parrot Опубликовано 24 июня, 2019 · Жалоба 27 минут назад, maxkst сказал: 8.8.4.4? тогда надо бежать за противогазом, и в бункер, ибо третья мировая началась )) Ну, учитывая последние тенденции обособления рунета, не факт. Хотя я из Беларуси. Спасибо, отправил в drop всё, что пытается в output на 8.8.4.4 с резерва - пинги через резерв идти перестали. Значит и netwatch должен отрабатывать правильно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxkst Опубликовано 24 июня, 2019 · Жалоба 12 минут назад, Parrot сказал: отправил в drop всё, что пытается в output на 8.8.4.4 с резерва - пинги через резерв идти перестали Прям все-все не обязательно, достаточно только ICMP по идее Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Parrot Опубликовано 24 июня, 2019 · Жалоба 1 минуту назад, maxkst сказал: Прям все-все не обязательно, достаточно только ICMP по идее Я понимаю :). Но 8.8.4.4 у меня как DNS не используется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxkst Опубликовано 24 июня, 2019 · Жалоба 17 минут назад, Parrot сказал: Значит и netwatch должен отрабатывать правильно. Есть возможность проверить на практике? 18 минут назад, Parrot сказал: Ну, учитывая последние тенденции обособления рунета, не факт. Хотя я из Беларуси. Не думал, что все так плохо. Я из Канады Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
McSea Опубликовано 24 июня, 2019 (изменено) · Жалоба @Parrot Если для проверки ничего кроме простого пинга хоста не нужно, очень просто делается на рекурсивных маршрутах. Смотрите (ваш адрес взял для шлюза) add distance=1 dst-address=8.8.4.4/32 gateway=10.128.0.0 scope=10 add check-gateway=ping distance=1 gateway=8.8.4.4 Первый маршрут на проверочный хост, обязательно шлюзом IP адрес должен быть, не интерфейс. И scope=10. Второй маршрут основной дефолт - через первый - с проверкой пингом хоста. Третий маршрут резерв дефолт сами добавьте через второго провайдера, как он есть у вас, но с distance больше 1. Он должен быть enable, т.е. НЕ отключен. И это все, скрипты, netwatch не нужны ! Как работает - как только проверочный хост становится не доступным (проверяется пингом) ИЛИ падает интерфейс, дефолт маршрут сразу становится неактивным. И тут же становится активным резервный маршрут, который до этого был неактивным (синим) - когда проверочный хост становится доступным - доступным именно через основного провайдера - основной дефолт становится активным, а резерв опять неактивным (синим) Изменено 24 июня, 2019 пользователем McSea Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
user71 Опубликовано 25 июня, 2019 · Жалоба @McSea да но с нетвотчем с манглами оутпутами роутингами оно как то прямее. Тем более гугл очень не любит быть дефолт гейтом... может и забанить и несекурно это. P.s. сарказм. Как хоть вас угораздило додуматся до этого садомазо с нетворчем? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 25 июня, 2019 · Жалоба 1 час назад, user71 сказал: @McSea да но с нетвотчем с манглами оутпутами роутингами оно как то прямее. Тем более гугл очень не любит быть дефолт гейтом... может и забанить и несекурно это. P.s. сарказм. Как хоть вас угораздило додуматся до этого садомазо с нетворчем? Надеюсь сарказм относился к утверждению что гугл не любит быть дефолтом и про несекурность? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
user71 Опубликовано 25 июня, 2019 (изменено) · Жалоба Да. Но я неуверен. Вдруг действительно ходит. Если у вас не ходит возможно гугл неоригинальный. Это же эникаст. Изменено 25 июня, 2019 пользователем user71 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 25 июня, 2019 (изменено) · Жалоба Что ходит, о чем вы вообще? Трафик через гугл ходит если его указать гейтом? Изменено 25 июня, 2019 пользователем VolanD666 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
McSea Опубликовано 25 июня, 2019 (изменено) · Жалоба @user71 Ознакомьтесь, все уже придумано до нас -- https://wiki.mikrotik.com/wiki/Advanced_Routing_Failover_without_Scripting Через проверяемый хост трафик конечно же не ходит, он там нужен только для проверки доступности. Вместо гугла там может что угодно стоять, хоть провайдерский гейт, хоть свой же хост на другой площадке, хоть любой из 6-ти адресов Яндекс.DNS Изменено 25 июня, 2019 пользователем McSea Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 25 июня, 2019 · Жалоба Самое хорошее это 2 L2TP туннеля поднять до некого узла в ДЦ, и по ним передавать интернет. Если один провайдер перестанет работать, то и туннель отвалится, делов то. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 26 июня, 2019 (изменено) · Жалоба 8 часов назад, Saab95 сказал: Самое хорошее это 2 L2TP туннеля поднять до некого узла в ДЦ, и по ним передавать интернет. Если один провайдер перестанет работать, то и туннель отвалится, делов то. Ну обычно между провадерами пиринг, так что не сработает такая схема. Изменено 26 июня, 2019 пользователем VolanD666 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 26 июня, 2019 · Жалоба Если туннель не отвалится, то и работать продолжит, есть резерв, разве не так? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 27 июня, 2019 · Жалоба Если проверочный ДЦ у другого провайдера, то трафик между вашим провайдером и ДЦ может ходить через пиринг. Если речь о ДЦ у вашего провайдера, то это вообще бессмысленно т.к. не защищает от проблем у провайдера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 27 июня, 2019 · Жалоба В 25.06.2019 в 22:12, Saab95 сказал: 2 L2TP туннеля поднять до некого узла в ДЦ, и по ним передавать интернет. И поиметь проблемы с MTU. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...