reachable mikrotik что это
Рекурсивная маршрутизация в MikroTik
Принцип работы рекурсивной маршрутизации в MikroTik и что такое scope и target-scope
Рекурсивная маршрутизация
Данная реализация поведения маршрутизации появилась из-за того, что в протоколе BGP при распространении маршрутов полученных через eBGP в iBGP next-hop по умолчанию, не меняется. Но не будем о BGP, а будем о простом.
Давайте начнём с простого, ниже я привёл таблицу маршрутизации простого маршрутизатора без каких либо излишек.
Смотря на таблицу маршрутизации выше, ответьте на вопрос. Какой шлюз будет выбран для отправки пакета на адрес 8.8.8.8?
Я более чем уверен, что вы абсолютно правильно определили шлюз как 10.11.100.254 в маршруте 0.0.0.0/0 по номером ноль.
А теперь попробуйте ответить на следующий вопрос. Какой интерфейс будет выбран для отправки пакета на адрес 8.8.8.8? Почувствуйте разницу, в первом вопросе я спрашивал про шлюз, а в данном вопросе про интерфейс.
И вы скорее всего все ответите, что ether1 и будете правы, но вопрос почему именно так.
Задача маршрутизатора, определить не шлюз, а интерфейс выхода, так как маршрутизатору надо будет понять как передать до шлюза пакет, если тип ethernet, то необходимо будет выяснить с помощью arp mac адрес шлюза, если это какой-то тип инкапсуляции, то пакет надо обернуть в данный тип инкапсуляции и отправить, на адрес пира.
Я не могу, вам показать fullview таблицу маршрутизации, так как она бы банально заняла огромное место на данной странице.
И так представьте у себя в голове таблицу маршрутизации в 700000 маршрутов. Представили?!
Я намеренно проигнорирую такие вещи как Кеш таблицы маршрутизации. (Представим, что его нет.)
Перед маршрутизатором стоит задача, отправить пакет на адрес 8.8.8.8
В данном процесс поиска, есть одно тонкое место, при повторном поиске маршрута, уже до адреса шлюза 5.5.5.1 маршрутизатор проходит опять всю таблицу маршрутизации. Вам не кажется, что это немного излишне? Строго говоря адрес шлюза должен быть в непосредственно присоединенной сети к маршрутизатору! Так может следующий поиск осуществлять только среди connected маршрутов? да это было бы идеально. Но так как я уже написал выше, в протоколе BGP при передачи маршрута из eBGP в iBGP адрес шлюза не меняется, то шлюз уже не может быть connected. И что же делать?
Scope
В linux, а так как RouterOS основан на Linux, то также и в RouterOS введено такое понятие как scope маршрута и target-scope
У любого маршрута есть, свой scope и target-scope.
Теперь давайте смотря на таблицу маршрутизации выше, попробуем ответить на вопрос. Какой интерфейс будет выбран для отправки пакета на адрес 8.8.8.8?
Значения Scope
Значение вы можете править руками, как для scope так и для target-scope. В случае с динамической маршрутизацией вы можете scope или target-scope указать с помощью фильтров маршрутизации, но вам необходимо знать, что есть предустановленные значения.
Все типы маршрутов, кроме на iBGP, основаны на состоянии интерфейса, ну возможно eBGP немного сбоку стоит, так как по умолчанию он требует прямой связности с пиром, хотя это обходится с помощью multihop. А iBGP у него target-scope = 30, так как адрес шлюза не меняется, и нужен ещё один какой-то протокол, который бы сообщил как достичь сети nexthop-a. Например статический маршрут или зачастую ospf.
Но мы можем использовать во благо, данное поведение, чтобы узнавать наличие интернета за провайдером, без использования скриптов. Понятно, что только пинг и без дополнительный параметров малоэффективен, но это лучше чем нечего.
И так давайте переделаем дефолтный маршрут, и адрес шлюза укажем не наш шлюза, а например 8.8.8.8
Создадим маршрут до 8.8.8.8 через шлюз нашего провайдера.
Создали, маршрут но маршрут по умолчанию, до сих пор не активен. Так как маршрутизатор всё также не смогу найти, маршрут до 8.8.8.8, так как target-scope дефолтного маршрута равен 10, и именно среди таких scope будет производится поиск до адреса 8.8.8.8. Нам необхоидимо установить scope маршрута 8.8.8.8, так чтобы он попадал под поиск, а это значит установить scope либо 10 или меньше. Сделаем.
И наблюдаем, то что поднялся рекурсивный маршрут. gateway-status=8.8.8.8 recursive via 10.11.100.254
Теперь давайте ещё раз ответим на вопрос, только изменим адрес назначения. Какой интерфейс будет выбран для отправки пакета на адрес 4.4.4.4?
А теперь мы можем сделать следующее, мы можем указать, использовать check-gateway и тем самым проверять доступность 8.8.8,8, и если будут недоступны, маршрут умрёт, и станет активным какой-нибудь другой маршрут с худшей дистанцией, например через LTE интерфейс.
Вы можете сделать рекурсивно, друг за другом, но это не имеет значение не в каких целях.
Одними 8.8.8.8 сыт не будешь
Да конечно, если упадёт 8.8.8.8, то мало не поздоровиться, будете переделывать. Можно поступить следующим образом.
Например взять три хоста высокой доступности 1.1.1.1, 8.8.8.8 и 77.88.8.8, можете любые свои, главное чтобы они действительно максимально всегда были доступны.
Создать три маршрута, через нашего провайдера. Таким образом
Далее создать три дефолтных рекурсивных маршрута, разной дистанцией.
В итоге, у вас будет такая картина в Winbox.
Если от 77.88.8.8 перестанет приходить ответы icmp, но при этом 8.8.8.8 будет приходить, то маршрут через шлюз 77.88.8.8 выпадет из процесса маршрутизации и его место займет следующий дефолтный маршрут по дистанции.
Часто слышу вопрос, а как сделать так, чтобы можно сделать через PPPoE рекурсивный маршрут? Тут всё дело в понимании, как таковой адрес шлюза не используется, кроме как в ethernet сетях, так как в ethernet нам нужен его mac адрес, в любых типах инкапсуляции в том числе и PPPoE адрес шлюза не используется, в виду того, что маршрутизатору просто надо запихнуть пакет в другой протокол и отправить на другую сторону.
Естественно мы можем этим воспользоваться.
Создайте отдельный PPP Profile и укажите абсолютно любой IP адрес в поле remote-address, главное чтобы этот адрес не пересекался с вашими внутренними сетями. Далее укажите этот профиль в настройках вашего PPPoE клиента, и вы можете использовать указанный адрес в поле remote-address, как адрес шлюза, для настройки рекурсивной маршрутизации.
PC360
Ремонт/настройка ПК и окружающих его устройств.
MikroTik – настройка двух каналов доступа в Интернет.
В описании представлена настройка двух Интернет-каналов в режиме резервирования. При пропадании связи с одним из каналов, трафик автоматически переходит на второй канал. Работа основана на мониторинге основного канала через пинг и разной метрике шлюзов.
Недостаток метода в том, что мониторинг выполняется от роутера MikroTik до следующего роутера (провайдера). Если Интернет пропадет на участке ВОЛС (см. схему ниже), то наш MikroTik не обнаружит этого и не переключится на резервный канал.
Освоить MikroTik Вы можете с помощью онлайн-куса «Настройка оборудования MikroTik». Курс содержит все темы, которые изучаются на официальном курсе MTCNA. Автор курса – официальный тренер MikroTik. Подходит и тем, кто уже давно работает с микротиками, и тем, кто еще их не держал в руках. В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.
В схеме участвует роутер MikroTik RB750Gr3 с прошивкой 6.47.4.
В первый и второй порты подключены патч-корды внешних сетей. В пятый порт патч-корд от коммутатора локальной сети.
Подключаемся к MikroTik через WinBox из локальной сети. (как это сделать)
Reset Configuration.
Сбрасываем конфигурацию без сохранения настроек по умолчанию.
Рекурсивная маршрутизация в MikroTik через шлюзы назначемые DHCP
Наиболее часто задаваемый мне вопрос по использованию рекурсивной маршрутизации звучит так: «Что делать, если основной провайдер назначает нам ip-адрес через dhcp, при этом часто изменяется шлюз по-умолчанию?».
Warning! материалы и схемы в данной статье упрощены до примитивизма с целью дать общее понятие о методе решения проблемы. Без углубления в частности.
Для чего нужна рекурсивная маршрутизация? Для мониторинга наличия интернета за шлюзом провайдера. Ведь нередко случается, что маршрутизатор провайдера прекрасно отвечает на эхо-запросы, но [ап]линк в глобальную сеть у провайдера о какой-то причине пропал.
Рекурсивная маршрутизация позволяет оценить наличие доступа в Интернет через выбранного провайдера и принять решение о маршрутизации трафика.
Однако, дело в том, что использование рекурсивной маршрутизации предполагает наличие прибитого гвоздями прямое явное указание IP-адреса шлюза среди параметров создаваемого маршрута. Указание в качестве шлюза имени broadcast-интерфейса является неправильным и во многих случаях просто не работает, т.к. требует наличия proxy-arp со стороны провайдера. А еще, вместо провайдера proxy-arp может включить ваш сосед про провайдерскому свитчу и попытаться перехватить таким образом ваш трафик, устроив классический MITM!
Магия рекурсивной маршрутизации прячется за параметрами «scope» и «target-scope». Чтобы маршрут работал как рекурсивный, его «target-scope» должен быть больше или равен значению «scope» у статического маршрута на который он ссылается рекурсивно, а указанный в маршруте шлюз лежал вне прямой досягаемости через один из интерфейсов.
Рассмотрим простейшую схему Active/Backup. Наш маршрутизатор выполнятет NAT и подключен к двум провайдерам посредством интерфейсов Ether1-isp1 и Ether2-isp2. Основной провайдер (ISP-1) раздаёт своим клиентам IP-адреса посредством протокола DHCP и никак иначе. Второй провайдер предоставляет нам статический IP-адрес, но значительно меньшую скорость.
Переключение на запасного (ISP-2) должно происходить тогда, когда доступ в Интернет через основного провайдера становится невозможным.
Изюминкой от провайдера для подобной схемы является периодическая произвольная смена не только IP-адреса клиента, но и default-gateway.
До версии 6.39 мне приходилось видеть весьма изощренные костыли в различных комбинациях sheduler, netwatch и тому подобных механизмов.
Начиная с версии 6.39 разработчики RouterOS пошли навстречу таким пользователям и создали возможность вызывать специальный скрипт при срабатывании dhcp-клиента на устройстве.
Собственно решение состоит из двух частей:
Создадим резервный маршрут через «ISP-2» со значением «distance» больше, чем у будущего основного. В данном примере я использовал «distance=2»:
Далее, для того, чтобы получать от провайдера «ISP-1» маршрут по-умолчанию, но прямо его не использовать, существует специальное значение «distance=255». Маршрут с таким значением distance попадет в системную таблицу маршрутизации, но никогда не станет активным.
Такой маршрут нужен нам только для чтения присланных провайдером параметров и внедрением их в настройки рекурсивных маршрутов посредством скрипта.
Первая строка должна (и будет!) указывать на настоящий шлюз в сети провайдера лишь после того, как провайдер выдаст параметры по dhcp и они будут обработаны посредством dhcp-client script:
Теперь, при получении от провайдера «ISP-1» IP-адреса для использования в качестве шлюза по-умолчанию, он будет внесен в маршрутную пару вместо «127.0.0.1».
Вторая строка, где указан маршрут до 0.0.0.0/0, собственно и осуществляет всю магию. Указанный там в качестве шлюза узел 8.8.4.4 будет проверяться на отклик опцией «check-gateway=ping» именно через сеть ISP-1. В случае если узел 8.8.4.4 не ответит дважды на эхо-запросы в течение 20 секунд, маршрутизатор будет считать связь с Интернетом через этот маршрут (ISP-1) недоступной. Новые соединения в этом случае будут направлены через запасного провайдера ISP-2.
Если всё сделано правильно, то в окне winbox /ip->routes около маршрута до 8.8.4.4 будет видно слова «resursive via. ». Это значит маршрут построился именно как рекурсивный.
В завершении, исключительно для примера — скрин окна винбокса:
Reachable mikrotik что это
Приступая к выполнению задачи я рассчитывал на легкую прогулку в тени дубового парка, созерцая природу и предаваясь размышлениям… Однако позже стало понятно, что это будет тернистый и сложный поход сквозь горные реки с подводными камнями, обледеневшими скалами и глубокими пещерами. Через медитации, борьбу со стихиями и собственной тупостью преодоление себя я, все таки, достиг желанной нирваны.
В этой статье я не только предоставлю готовый набор правил, но и постараюсь максимально доступно объяснить почему и как именно они работают.
Конкретно в моем случае, нужно было настроить роутер так, чтобы web-сервер в локальной сети за ним был доступен по IP любого из 3-х провайдеров.
Часть 1.
Для начала пробежимся по всем настройкам, дабы самые нетерпеливые могли скопипастить не читая.
Версия RouterOS:
Интерфейсы:
Не помню начиная с какой версии RouterOS появилась эта фишка. Она позволяет группировать интерфейсы, что весьма удобно (например, в правилах /ip firewall). У меня создана группа из 3-х WAN-интерфейсов.
IP-адреса (адреса, по понятным причинам, «левые»):
Роутинг:
Для организации Failover’а я настроил рекурсивную маршрутизацию, подробнее расскажу в 2-ой части.
Firewall (для данной публикации я сознательно привожу правила, разрешающие все. Не делайте так!):
dst и src nat:
mangle
Часть 2.
Рассмотрим все подробнее.
Роутинг:
/ip route
В первых трех строчках мы указываем default gateway каждого из 3-х наших провайдеров. Маршруты имеют одинаковый вес (distance), но работают в разных таблицах маршрутизации.
Другими словами, эти маршруты работают для пакетов промаркированных соответствующим тегом (routing-mark). Теги пакетам мы будем навешивать в /ip firewall mangle (о чем я подобно расскажу ниже).
Следующие 3 строки — указание маршрутов по умолчанию в основной таблице маршрутизации.
Здесь стоит обратить внимание на:
MikroTik. Nexthop_lookup
Английский статьи http://wiki.mikrotik.com/wiki/Manual:IP/Route, на мой взгляд, слегка упорот. Это не Cisco CCNA Exploration, который читается на одном дыхании, но я постараюсь перевести ее отрывок максимально понятно. Если где-то увидите такую же упоротость, поправьте меня, пожалуйста.
Во-первых, определимся с некоторыми терминами.
Nexthop — следующий прыжок, если дословно. Следующий шлюз/роутер/маршрутизатор на пути следования пакета из точки А(от моего роутера, например) в точку Б (допустим до гуглового DNS 8.8.8.8), т.е. следующий транзитный участок, на котором будет обрабатываться пакет. В переводе будет использоваться словосочетание “следующий хоп” (простите за англицизм).
Immediate nexthop — следующий шлюз/роутер/маршрутизатор на пути следования пакета из точки А в точку Б, доступный непосредственно. Для моего домашнего MikroTik, с маршрутом по-умолчанию:
89.189.163.1 — это и есть immediate nexthop, т.к. доступен он через ether1-gateway. В переводе будет использоваться словосочетание “непосредственно доступный следующий хоп”.
Connected route — связанный маршрут. Маршрут, шлюз которого доступен непосредственно.
Gateway — сетевой шлюз/роутер/маршрутизатор. Я буду пользоваться всеми тремя вариантами перевода.
scope — Используется в механизме поиска следующего хопа, т.е. решения какой же хоп станет следующим. Нужный маршрут может быть выбран только среди маршрутов, значения scope которых меньше либо равно значению target-scope. Значения по-умолчанию зависят от протокола:
target-scope — Используется в механизме поиска следующего хопа, т.е. решения какой же хоп станет следующим. Это максимальное значение параметра scope для маршрута, посредством которого может быть найден следующий хоп. Для iBGP значение установленно в 30 по-умолчанию.
Табличка значений обоих параметров.
Поиск следующего хопа. Поиск следующего хопа является частью процесса выбора маршрута.
Маршрутам, находящимся в FIB, нужен интерфейс, соответствующий каждому из адресов шлюзов. Адрес следующего хопа-шлюза должен быть непосредственно доступен через этот интерфейс. Интерфейс, который следует использовать для посылки исходящего пакета каждому из шлюзов, находится с помощью поиска следующего хопа.
Некоторые маршруты (например, iBGP), в качестве адреса шлюза, могут иметь адрес принадлежащий маршрутизатору, находящемуся через несколько прыжков-шлюзов от нашего MikroTik. Для установки таких маршрутов в FIB необходимо найти адрес шлюза, доступного непосредственно (an immediate nexthop), т.е. напрямую от нас, который и будет использоваться для достижения адреса шлюза в этом маршруте. Непосредственный адрес следующего хопа также может быть найден при помощи механизма поиска следующего хопа.
Поиск следующего хопа выполняется только в основной таблице маршрутизации main, даже для маршрутов, имеющих отличное значение параметра routing-mark. Это необходимо для ограничения установки маршрутов, которые могут быть использованы для поиска непосредственно доступных хопов (immediate nexthops). В маршрутах для протоколов RIP или OSPF предполагается, что следующий маршрутизатор доступен непосредственно и должен быть найдены используя только связанные маршруты(connected routes).
Маршруты с именем интерфейса в качестве шлюза не используются в поиске следующего хопа. Если есть маршрут с именем интерфейса, а также маршрут с активным IP-адресом, то маршрут с интерфейсом игнорируется.
Маршруты, имеющие значение параметра scope больше максимально допустимого не используются в поиске следующего хопа. В каждом маршруте указывается максимально допустимое значение параметра scope, для его следующего хопа, в параметре target-scope. Значение по-умолчанию для этого параметра позволяет выполнить поиск следующего хопа только через связанные маршруты (connected routes), за исключением iBGP-маршрутов, которые имеют большее значение по-умолчанию и могут выполнить поиск следующего хопа также через IGP и статические маршруты.
Интерфейс и адрес следующего непосредственно доступного маршрутизатора выбираются основываясь на результатах поиска следующего хопа:
А теперь, как говорят в КВН, зачем же я показал этот номер. Обратите внимание, мы устанавливаем scope=10 для статических маршрутов в последних трех строках, тем самым «заставляем» MikroTik принимать во внимание эти маршруты при поиске следующего хопа.
Он и принимает, и таким образом маршруты по-умолчанию через:
Cтановятся recursive, т.е. непосредственно доступными хопами будут шлюзы провайдеров и трафик мы пошлем через них, но check-gateway=ping будет проверять доступность адресов ЗА провайдерскими сетями.
Надеюсь мой перевод и объяснение будут вам полезны.
Пока самые охочие до знаний читают под спойлером, расскажу немого короче и проще. Когда мы указываем scope=10 в последних трех строках, мы даем понять MikroTik’у, что:
ему доступны не напрямую, а рекурсивно через данные статические маршруты. По одному IP на брата-провайдера.
/ip firewall mangle
Для пояснения правил этого раздела пригласим несколько помощников.
1. MANGLE — данная таблица предназначена для операций по классификации и маркировке пакетов и соединений, а также модификации заголовков пакетов (поля TTL и TOS) (викиучебник).
Таблица mangle содержит следующие цепочки:
2. CONNECTION TRACKING — специальная подсистема, отслеживающая состояния соединений и позволяющая использовать эту информацию при принятии решений о судьбе отдельных пакетов.
3. Packet flow MikroTik’а
Я разбил правила на группы, для облегчения их понимания. В первой группе 6 правил, которые отвечают за трафик в/из самого роутера, и во второй группе 6, для транзитного трафика.
Начем с первых двух. В первом мы сообщаем роутеру, что все входящие chain=input соединения на интерфейс ISP1 нужно маркировать action=mark-connection new-connection-mark=ISP1-conn, а так же указаваем passthrough=yes, чтобы пакет, после прохождения этого правила, не покинул таблицу и продолжил следование по правилам.
Все описанное выше справедливо и для ISP2 и для ISP3. Таким образом мы добились того, что роутер ответит именно с того интерфейса, на который к нему прийдет запрос.
Переходим к завершающим шести правилам. Уже понятно, они также разбиты на подгруппы по 2, для каждого из наших ISP. Первое из них поручает роутеру следить за цепочкой FORWARD и если происходит соединение через интерфейс ISP1, то оно маркируется action=mark-connection новым тегом new-connection-mark=ISP1-conn-f (обратите внимание! отличным от тега трафика самого маршрутизатора, в данном случае мы маркируем транзитный трафик). passthrough=no, т.к. мы не хотим, чтобы пакет, после попадания в это правило, обрабатывался в таблице как-то еще.
Второе навешивает нужную метку роутинга new-routing-mark=ISP1-route в цепочке PREROUTING, т.е. ДО принятия решения о маршрутизации, и отслеживает трафик пришедший к нам из локальной сети in-interface=bridge.
Здесь нас выручает механизм CONNECTION TRACKING, позволяющий поймать промаркированные правилом выше соединения из локальной сети(от WEB-сервера) и навесить им необходимый тег роутинга.
Это позволяет транзитному трафику(здесь к/от web-сервера) идти именно тем путем, которым он и пришел, т.е. пришел через ISP1 — уходи через него же.
Mikrotik, 3 провайдера, переключение и разделение трафика
И наконец наша таблица маршрутизации
Здесь необходимы пояснения, для каждого провайдера мы создали дефолтный маршрут с маркировкой маршрута.
Первый маршрут мне необходим для того чтобы настраивать сам MikroTik.
Собственно на этом всё. Наш MikroTik готов для дальнейшей тонкой настройке.
На следующем этапе мы настроем отзывчивость MikroTik со всех провайдеров.
Для начала настроем маскарад для все трёх интерфейсов.
Теперь наверное самое интересное Mangle
Наша задача сделать так чтобы на MikroTik можно было достучаться через всех трёх провайдеров.
Для этого мы должны отловить входящие соединения и замаркировать соединения, следующим правилом необходимо для маркированного соединения сделать обратку в того провайдера с которого соединения пришло.
Картинка для закрепления. И понимания.
Отлично теперь мы можем заходить на MikroTik через любого провайдера.
Настало время каждого офиса займёмся трафиком с четвёртого порта. Но прежде предусмотрительно подготовим один маленький но тонкий нюанс, так как мы будет использовать prerouting то трафик перед «Попаданием» в таблицу маршрутизации, необходимо отфильтровать.
Необходимо создать адрес листы с сетями которые не должны маркироватся.
Я обычно называю его LocalNet и в этот раз поступим также.
И так мы создали листы локальных сетей, теперь приступим к маршрутизации трафика.
Перед тем как пакет покинет маршрутизатор: если адрес отправителя состоит в сети 192.168.101.0/24 и адрес назначения не числится в листах, то маркируем маршрут именем office 1
Совсем просто, это весь трафик который принадлежит офису 1 и не идёт до наших других локальных подсетей.
Далее нам необходимо создать три маршрута для трафика office 1
Немного разъяснения check-gateway это процедура автоматической проверки доступности шлюза, так как у меня это соединение L2 то в моём случае arp лучше чем ping, если у вас L3 (pptp etc) то ставите ping.
Также необходимо обратить внимание distance как раз по ней маршрутизатор определяет при одинаковом адресе назначения какой приоритет маршрутов.
Ну а теперь финальная часть нашего «марлезонского балета».
Так как cheсk-gateway проверяет доступность только шлюза, нас это категорически не устраивает.
Наша задача определить живой ли канал в интернет через каждого провайдера и в зависимости от живности включать и отключать маршруты.
В данном случае у нас две сети
office1 ISP1->ISP2->ISP3
office2 ISP2->ISP1-ISP3
Как видно что конченым результатом у нас в любом случае будет ISP3, естественно канал ISP3 нам нет необходимости проверять.
И так прежде нам необходимо настроить дату и время на MikroTik. Я надеюсь вы сделаете это без моей помощи.
Отступление: в интернете много различных скриптов, но большинство из них выполняют скрипт в заданный промежуток времени которые меняет значения дистанции в маршрутах. Нас такой вариант не устраивает так как в MikroTik стоит NAND память и у неё есть свой предел записи. Мы будем его экономить. Кончено же можно было отредактировать скрипт и делать проверку, но это не наш метод. )
Будем использовать функционал MikroTik. NetWatch
Создадим два правила.
Netwacth работает как тригер.
Если состояние изменилось то выполняется скрипт указанный в текущем значении тригера.
В нашем случае если пинг до 8.8.8.8 не пройдёт то, смениться статус на down и исполниться скрипт ISP1-DOWN, как только значение станет up, то исполниться скрипт ISP1-UP
Напишем скрипты для наших событий.
ISP1-UP
В моё случае я ищу так, кто то определяет по комментариям к маршрутам.
Но я пока встречал только один раз где реально использовалась дистанция больше 10.
ISP1-DOWN
Для того чтобы весь наш netwatch полноценно работал нам необходимо добавить два маршрута, который будут отправлять трафик на 8.8.8.8 через ISP1, а трафик до 8.8.4.4 через ISP2