Scope mikrotik что это
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Резервирование каналов в Mikrotik при помощи рекурсивной маршрутизации
Значение интернета в повседневной жизни и деятельности предприятий всех форм и размеров с каждым днем только растет, особенно сейчас, когда весь мир переходит на дистанционные методы работы в связи с пандемией короновируса. Но этот вопрос актуален также и для торговых предприятий, платежные карты используются практически каждым вторым покупателем и отсутствие интернета мгновенно скажется на выручке предприятия. В данной статье мы рассмотрим, каким образом можно организовать резервный канал и обеспечить быстрое переключение на него и обратно штатными средствами RouterOS.
Как показывает читательский отклик, маршрутизация для многих администраторов является достаточно сложной темой. Тем не менее если вы внимательно выполните все инструкции данной статьи, то всё будет работать. Однако слепое выполнение инструкций не добавляет понимания происходящих процессов и, если что-то пойдет не так вы окажетесь в весьма затруднительном положении, поэтому перед тем, как перейти к практике мы выполним небольшой теоретический ликбез.
Теория
Действительно, маршрутизация достаточно сложная тема, поэтому мы сознательно упростили многие моменты для того, чтобы обеспечить понимание процессов начинающими в объеме необходимом для решения поставленной задачи.
Что такое маршрутизация? Это процесс определения пути следования данных в сетях связи. Его можно сравнить с прокладкой маршрута с использованием навигатора, вы задаете начальную и конечную точку и получаете несколько вариантов проезда с указанием всех промежуточных точек. В некоторых точках маршрут может разделяться на несколько вариантов, из которых вы можете выбрать наиболее оптимальный, исходя из оценки текущей дорожной обстановки.
Для каждого узла маршрута, а наш роутер является одним из них, решение о маршрутизации принимается на основании таблицы маршрутизации. Рассмотрим ее простейший вариант, за основу мы взяли стандартный вывод в терминале Mikrotik и добавили дополнительные данные, сейчас они могут быть непонятны, но ниже мы будем к ним обращаться.
Прежде всего разберемся как заполняется таблица маршрутизации. Это может происходить несколькими способами:
К одной цели могут вести несколько маршрутов, приоритетом их выбора является значение административной дистанции, чем ниже это значение, тем выше приоритет у маршрута. Если вернуться к нашей аналогии с навигатором, то он может проложить нам несколько маршрутов, но приоритет получит самый короткий. Но если на этом маршруте возникнут серьезные затруднения, скажем, пробка или авария, то мы можем выбрать более длинный маршрут. Также и здесь, если маршрут с наименьшей административной дистанцией недоступен, то выбирается маршрут с более высокой дистанцией.
Теперь разберемся как все это работает. Допустим мы хотим обратиться к узлу 8.8.8.8, роутер берет таблицу маршрутизации и осуществляет в ней поиск наилучшего маршрута к запрашиваемому узлу. В нашем случае искать особо нечего и это будет «нулевой» маршрут со шлюзом 192.168.3.1. Но маршрутизаторы крупных сетевых узлов могут содержать тысячи и десятки тысяч маршрутов и поэтому поиск может оказаться совсем не простым и дешевым действием.
Коротко напомним о том, что такое «нулевой» маршрут или шлюз по умолчанию, он используется в том случае, если в таблице для узла назначения не было найдено ни одного подходящего маршрута. Проще говоря, если роутер не знает куда отправить данные, он отправляет их шлюзу по умолчанию. Особой записи для узла 8.8.8.8 в нашей таблице нет, поэтому будет использоваться «нулевой» маршрут.
В нашем случае основной задачей маршрутизатора будет определить интерфейс выхода, т.е. куда именно физически нужно направить данные, чтобы они добрались до требуемого места назначения. Поэтому роутер снова начинает поиск в таблице маршрутизации чтобы определить каким образом следует добраться до искомого адреса шлюза 192.168.3.1, согласно таблице, будет найден маршрут к сети 192.168.3.0/24 через интерфейс ether5. Так как интерфейс выхода определен, то поиск прекращается и роутер формирует необходимый тип данных для передачи на канальном уровне.
Здесь тоже следует дать краткие пояснения, если интерфейс выхода является сетью Ethernet, то роутер выполнит ARP-запрос для адреса шлюза и сформирует Ethernet-кадр, а если это туннельный интерфейс точка-точка (VPN, PPPoE), то выполнит инкапсуляцию IP-пакета и отправит его на другую сторону туннеля.
И здесь мы приходим к следующим соображениям: таблица маршрутизации может быть большая и поиск по ней может быть затратным, в тоже время шлюз будет располагаться в одной из непосредственно присоединенных сетей, возможно следует ограничить поиск только по ним?
По умолчанию данные опции имеют следующее значение:
Таким образом область поиска существенно снижается и маршрут к шлюзу ищется только среди непосредственно присоединенных сетей. Теперь самое время перейти к рекурсивной маршрутизации.
Mikrotik имеет возможность проверять доступность шлюза, используя для этого пинг, если шлюз оказывается недоступным, то маршрут становится неактивным. Это хорошо, но позволяет выявлять только проблемы в сети провайдера, и если шлюз остается доступным, то маршрут будет продолжать оставаться активным, несмотря на остуствие доступа в интернет. Но что, если указать в качестве шлюза удаленный высокодоступный узел?
Давайте рассмотрим следующую таблицу маршрутизации:
В качестве шлюза по умолчанию мы указали адрес одного из DNS-серверов Cloudflare, обратите внимание, что такой адрес не должен использоваться в вашей сети, потому что после отказа связанного с ним провайдера он окажется недоступен. Теперь мы можем проверять наличие интернета за пределами сети провайдера и своевременно переключать маршруты в случае его недоступности.
Теперь разберемся как это работает. Когда мы хотим связаться с каким-либо узлом в сети интернет маршрутизатор выполнит поиск по таблице маршрутизации и, если не указано иных маршрутов, выберет «нулевой» в котором указан шлюзом 1.1.1.1, так как найден адрес, то поиск будет продолжен, чтобы определить интерфейс выхода. Так как указанный нами шлюз не находится ни в одной из непосредственно присоединенных сетей, то сделать это не удастся и такой маршрут работать не будет.
Практика
Будем считать что на вашем роутере уже настроен доступ к двум провайдерам и мы не будем останавливаться на этапе базовой настройки, если вы испытываете затруднения с этим, то обратитесь к нашей статье: Базовая настройка роутера MikroTik.
Перед тем, как переходить к дальнейшим настройкам нам нужно выяснить и запомнить адреса шлюзов провайдеров, для этого можно заглянуть на закладку Nexthops, для коммутируемых подключений (VPN, PPPoE) следует проверить свойства соответствующего соединения.
Внимание! Дальнейшие действия следует производить имея физический доступ к устройству!
После этого доступ в интернет по обоим каналам пропадет. Имейте это ввиду при планировании работ.
Эти же действия через терминал:
Затем добавим два рекурсивных «нулевых» маршрута. Для первого провайдера:
Для второго провайдера:
То же самое быстро в терминале:
Теперь таблица маршрутизации будет выглядеть следующим образом:
Наши маршруты добавились как рекурсивные и активным является маршрут через основного провайдера. Теперь имитируем аварию у первого провайдера, буквально через 10-20 секунд таблица маршрутизации изменится и рабочим станет маршрут через резервный канал:
После того, как первый провайдер устранит неисправность снова произойдет изменение маршрутов и рабочим снова станет основной канал.
Как видим на практике все оказалось достаточно просто, но мы уверены, что слепое повторение инструкций без понимания сути производимых действий никого и никогда ни к чему хорошему не приводило, поэтому настоятельно советуем не пренебрегать теоретической частью материала.
Рекурсивная маршрутизация и PPPoE
При использовании PPPoE подключения вы рано или поздно столкнетесь с проблемой изменения адреса шлюза провайдера, это может произойти даже при наличии выделенного IP адреса. После чего маршрут к высокодоступному узлу перестает работать, что приводит к полной неработоспособности этого провайдера. Диагностика такой неисправности может оказаться весьма затруднительной если вы не сталкивались с данной проблемой ранее и недостаточно четко представляете себе принципы работы рекурсивных маршрутов.
Чтобы этого избежать используем одну небольшую хитрость. Вспомним, о чем мы говорили в теоретической части. При использовании PPPoE соединения адрес шлюза провайдера роутеру как таковой не нужен. Он используется только для определения интерфейса выхода. Для работы протокола PPP, который лежит в основе PPPoE, IP-адреса не требуются. Это дает возможность самостоятельно присвоить произвольный адрес для удаленного конца туннеля и использовать его в качестве шлюза.
В терминале это можно сделать так:
После чего назначим этот профиль вашему PPPoE соединению:
И после его перезапуска убедимся, что удаленный адрес соединения теперь соответствует назначенному нами:
Теперь можно использовать данный адрес как шлюз для этого провайдера, не беспокоясь о возможных изменениях.
Рекурсивная маршрутизация и DHCP
Описанная выше проблема актуальна и для провайдеров, выдающих настройки по DHCР, в том случае если у клиента нет выделенного IP-адреса, текущий адрес может быть назначен из нескольких диапазонов, а следовательно, будет изменен и адрес шлюза. В отличие от PPPoE здесь мы не сможем задать произвольный адрес, поэтому нам на выручку придут скрипты.
Прежде всего добавим к маршруту для высокодоступного узла через шлюз провайдера уникальный комментарий, например, ISP1.
Теперь при каждом новом получении адреса по DHCP скрипт будет находить наш маршрут и изменять в нем значение шлюза на реально полученный адрес. Попробуем смоделировать данную ситуацию и выдадим нашему роутеру адрес первого провайдера из другого диапазона. Как видим, все автоматически изменилось согласно вновь полученных настроек:
Таким образом мы снова успешно решили задачу поддержания маршрутной информации в актуальном состоянии несмотря на ее возможные изменения со стороны провайдера.
Дополнительные материалы:
Mikrotik
The Dude
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Scope 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 RouterOS
Маршрутизация — процесс поиска оптимального пути для передачи пакетов в сетях TCP/IP. Любой устройство подключенное к сети IPv4 содержит процесс и таблицы маршрутизации.
Данная статья не является HOWTO, она описывает на примерах статическую маршрутизацию в RouterOS, я намеренно опускал остальные настройки (например srcnat для доступа в сеть интернет), поэтому для понимания материала требуется определенный уровень знания по сетям и RouterOS.
Коммутация и маршрутизация
Маршрутизация — процесс передачи пакетов между Layer2 сегментами. Если устройство хочет отправить пакет, получатель которого находится за пределами Ethernet сегмента, оно смотрит в свою таблицу маршрутизации и передает пакет шлюзу, который знает куда отправить пакет дальше (а может и не знает, изначальный отправитель пакета про это не осведомлен).
Проще всего рассматривать маршрутизатор, как устройство подключенное к двум или более Layer2 сегментам и способное передавать пакеты между ними определяя оптимальный маршрут по таблице маршрутизации.
Если вам все понятно или вы и так это знали, то читайте дальше. Остальным настоятельно рекомендую ознакомиться с маленькой, но очень емкой статьей.
Маршрутизация в RouterOS и PacketFlow
Практически весь функционал относящийся к статической маршрутизации находится в пакете system. Пакет routing добавляет поддержку алгоритмов динамической маршрутизации (RIP, OSPF, BGP, MME), Routing Filters и BFD.
На PacketFlow можно выделить три места, где принимаются решения о маршрутизации IP пакетов: 
RIB, FIB, Routing Cache
Routing Information Base
База в которой собираются маршруты от протоколов динамической маршрутизации, маршруты от ppp и dhcp, статические и подключенные (connected) маршруты. Данная база содержит все маршруты, за исключением отфильтрованных администратором.
Условно, можно считать что [IP]->[Route] отображает RIB.
Forwarding Information Base 
База в которой собираются наилучшие маршруты из RIB. Все маршруты в FIB являются активными и используются для пересылки пакетов. Если маршрут становится неактивным (отключен администратором (системой), или интерфейс через который должен отправляться пакет не активен) маршрут удаляется из FIB.
Для принятия решения о маршрутизации в таблице FIB используются следующие данные о IP пакете:
Попадая в FIB пакет проходит следующие стадии:
Условно, можно считать что [IP]->[Route Active=yes] отображает FIB.
Routing Cache
Механизм кэширования маршрутов. Маршрутизатор запоминает куда были отправлены пакеты и если встречаются похожие (предположительно из одного соединения) пускает их по тому-же маршруту, без проверки в FIB. Кэш маршрутов периодически очищается.
Данный механизм был удален из ядра linux 3.6, но в RouterOS до сих пор используется kernel 3.3.5, возможно Routing cahce — одна из причин.
Диалог добавления маршрута
[IP]->[Route]->[+] 
Флаги маршрутов 
Что указывать в gateway: ip-адрес или интерфейс?
Система позволяет указывать и то, и другое, при этом не ругается и не дает подсказок, если вы что-то сделали неправильно.
IP адрес
Адрес шлюза должен быть доступен по Layer2. Для Ethernet это означает, что роутер должен иметь на одном из активных интерфейсов ip адрес из той же подсети, для ppp — что адрес gateway указан на одном из активных интерфейсов в качестве адреса подсети.
Если условие доступности по Layer2 не выполняется — маршрут считается неактивным и не попадает в FIB.
Интерфейс
Все сложнее и поведение маршрутизатора зависит от типа интерфейса:
Старайтесь указывать ip адрес в качестве gateway всегда когда это возможно. Исключение — connected маршруты (создаются автоматически) и PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*) интерфейсы.
OpenVPN не содержит PPP заголовка, но можно использовать имя OpenVPN интерфейса для создания маршрута.
More Specific Route
Основное правило маршрутизации. Маршрут описывающий более маленькую подсеть (с наибольшей маской подсети) имеет больший приоритет при принятии решения о маршрутизации пакета. Положение записей в таблице маршрутизации не имеет отношения к выбору — основное правило More Specific.
Все маршруты из указанной схемы активны (находятся в FIB), т.к. указывают на различные подсети и не конфликтуют между собой.
Если один из шлюзов станет недоступным, связанный маршрут будет считаться неактивным (удален из FIB) и для пакетов будет производиться поиск из оставшихся маршрутов.
Маршруту с подсетью 0.0.0.0/0 иногда придают особое значение и называют «Маршрут по умолчанию» (Default Route) или «Шлюз последней надежды» (gateway of last resort). На самом деле в нем нет ничего магического и он просто включает все возможные адреса IPv4, но данные названия хорошо описывают его задачу — он указывает на шлюз, куда пересылать пакеты для которых нет других, более точных, маршрутов.
Максимально возможная маска подсети для IPv4 — /32, такой маршрут указывает на конкретный хост и может использоваться в таблице маршрутизации.
Понимание More Specific Route является фундаментальным для любых устройств работающих с TCP/IP.
Distance
Дистанции (или Метрики) необходимы для административной фильтрации маршрутов до одной подсети доступной через несколько шлюзов. Маршрут с меньшей метрикой считается приоритетным и попадет в FIB. Если маршрут с меньшей метрикой перестанет быть активным, то в FIB он будет заменен на маршрут с большей метрикой. 
Если присутствует несколько маршрутов до одной подсети с одинаковой метрикой, маршрутизатор добавить в таблицу FIB только один из них, руководствуясь своей внутренней логикой.
Метрика может принимать значение от 0 до 255: 
Check gateway
Check gateway — расширение MikroTik RoutesOS для проверки доступности шлюза по icmp или arp. Раз в 10 секунд (изменить нельзя) на шлюз отправляется запрос, если дважды не приходит ответ маршрут считается недоступным и удаляется из FIB. Если check gateway отключил маршрут проверки продолжается и маршрут снова станет активным после одной успешной проверки. 
Check gateway отключает запись, в которой он настроен и все остальные записи (во всех таблицах маршрутизации и ecmp маршрутах) с указанным шлюзом.
В целом check gateway работает нормально, если не возникает проблем с потерей пакетов до шлюза. Check gateway не знает, что происходит со связью за пределами проверяемого шлюза, для этого необходимы дополнительные инструменты: скрипты, рекурсивная маршрутизация, протоколы динамической маршрутизации.
Большинство VPN и туннельных протоколов содержат встроенные средства для проверки активности соединения, включать для них check gateway — это дополнительная (но очень маленькая) нагрузка на сеть и производительность устройства.
ECMP маршруты
Equal-Cost Multi-Path — отправка пакетов до получателя используя одновременно несколько шлюзом с перебором по алгоритму Round Robin.
ECMP маршрут создается администратором, путем указания нескольких gateway для одной подсети (либо автоматический, при наличии двух равноценных маршрутов OSPF). 
ECMP используется для балансировки нагрузки между двумя каналами, в теории, если в ecmp маршруте два канала, то для каждого пакета исходящий канал должен отличаться. Но механизм Routing cache отправляет пакеты из соединения по маршруту, которым пошел первый пакет, в итоге получаем подобие балансировки на базе соединений (per-connection loading balancing).
Если отключить Routing Cache, то пакеты в ECMP маршруте будут делиться правильно, но возникает проблема с NAT. Правило NAT обрабатывает только первый пакет из соединения (остальные обрабатываются автоматически) и получается ситуация, что с различных интерфейсов уходят пакеты с одним адресом источника. 
В ECMP маршрутах не работает check gateway (баг RouterOS). Но можно обойти это ограничение, если создать дополнительные маршруты для проверки, которые будут отключать записи в ECMP.
Фильтрация средствами Routing
Опция Type определяет, что сделать с пакетом:
Фильтрацию обычно используют, когда нужно обезопасить отправку пакетов не по тому пути, конечно можно фильтровать подобное через firewall.
Пара примеров
Для закрепления базовых вещей о маршрутизации.
Типичный домашний роутер 
Типичный домашний роутер с PPPoE 
Типичный домашний роутер с двумя провайдерами и резервированием 
Трафик до 0.0.0.0/0 идет через 10.10.10.1, пока данный шлюз доступен, иначе переключается на 10.20.20.1
Такую схему можно считать резервированием канала, но она не лишена недостатков. Если произойдет обрыв за пределами шлюза провайдера (например внутри операторской сети), ваш роутер об этом не узнает и продолжит считать маршрут активным.
Типичный домашний роутер с двумя провайдерами, резервированием и ECMP 
Маршруты для проверки синего цвета (цвет неактивных маршрутов), но это не мешает работе check gateway. В текущей версии (6.44) RoS автоматический приоритет отдается ECMP маршруту, но лучше добавить проверочные маршруты в другие таблицы маршрутизации (опция routing-mark )
На Speedtest и прочих подобных сайтах прироста скорости не будет (ECMP делит трафик по соединениям, а не по пакетам), но p2p приложения должны загружать быстрее.
Фильтрация через Routing 
Вариант фильтрации при которой туннельный трафик не уйдет на маршрутизатор провайдера при отключении ipip интерфейса. Подобные схемы требуются редко, т.к. можно реализовать блокировку через firewall.
Routing Loop
Петля маршрутизации — ситуация когда пакет бегает между маршрутизаторами до истечения ttl. Обычно является следствием ошибки конфигурации, в больших сетях лечится внедрением протоколов динамической маршрутизации, в маленьких — внимательностью.
Выглядит это примерно так: 
Пример (наипростейший) как получить подобный результат: 
Пример с Routing loop не имеет практического применения, но он показывает что маршрутизаторы понятия не имеют о таблице маршрутизации своих соседей.
Policy Base Routing и дополнительные таблицы маршрутизации
При выборе маршрута, роутер использует только одно поле из заголовка пакета (Dst. Address) — это базовая маршрутизация. Маршрутизация на базе других условий, например адреса источника, типа трафика (ToS), балансировка без ECMP, относится к Policy Base Routing (PBR) и использует дополнительные таблицы маршрутизации.
More Specific Route является основным правилом выбора маршрута, в пределах таблицы маршрутизации.
По умолчанию все правила маршрутизации добавляются в таблицу main. Администратор может создать произвольное количество дополнительных таблиц маршрутизации и направлять пакеты в них. Правила в разных таблицах не конфликтуют между собой. Если пакет не нашел подходящего правила в указанной таблице, он уйдет в таблицу main.
Пример с распределением через Firewall: 
Проблемы терминологии
В RouterOS есть определенные проблемы с терминологией.
При работе с правилами в [IP]->[Routes] указывается таблица маршрутизации, хотя и написано что метка: 
В [IP]->[Routes]->[Rule] все правильно, в условии метки в действии таблицы: 
Как отправить пакет в определенную таблицу маршрутизации
RouterOS дает несколько инструментов:
Правила [IP]->[Route]->[Rules]
Правила обрабатываются последовательно, если пакет совпал с условиями правила он не проходит дальше.
Routing Rules позволяют расширить возможности маршрутизации, опираясь не только на адрес получателя, но и адрес источника и интерфейс на который был получен пакет.
Правила состоят из условий и действия:
В FIB трафик до локальных процессов обрабатывается в обход правил [IP]->[Route]->[Rules] : 
Маркировка [IP]->[Firewall]->[Mangle]
Маршрутные метки позволяют устанавливать шлюз для пакета используя практически любые условия Firewall: 
Практически, потому что не все из них имеет смысл, а некоторые могут работать нестабильно.
Маркировать пакет можно двумя способами:
В статье про firewall я писал, что второй вариант предпочтительнее т.к. снижает нагрузку на cpu, в случае с маркировкой маршрутов — это не совсем так. Указанные способы маркировки не всегда являются равноценными и обычно используются для решения различных задач.
Примеры использования
Переходим к примерам использования Policy Base Routing, на них гораздо проще показать зачем все это нужно.
MultiWAN и ответный исходящий (Output) трафик
Распространенная проблема, при MultiWAN конфигурации: Mikrotik доступен из сети интернет только по «активному» провайдеру. 
Роутеру не важно на какой ip пришел запрос, при генерации ответа он будет искать маршрут в таблице маршрутизации, где активен маршрут через isp1. Дальше такой пакет скорее всего будет отфильтрован по пути до получателя.
Еще один интересный момент. Если на интерфейсе ether1 настроен «простой» source nat: /ip fi nat add out-interface=ether1 action=masquerade пакет уйдет в сеть с src. address=10.10.10.100, что еще больше усугубит ситуацию.
Исправить проблему можно нескольким способами, но для любого из них потребуются дополнительные таблицы маршрутизации: 
Использование [IP]->[Route]->[Rules]
Указываем таблицу маршрутизации которая будет использована для пакетов с указанными Source IP. 
Данный способ не требует рабочий Connection Tracker, в отличии от использования таблицы Mangle.
Использование [IP]->[Firewall]->[Mangle]
Соединение начинается со входящего пакета, поэтому маркируем его ( action=mark-connection ), для исходящих пакетов от маркированного соединения устанавливаем маршрутную метку ( action=mark-routing ). 
Если на одном интерфейсе настроено несколько ip, можно добавить в условие dst-address для уточнения.
MultiWAN и ответный dst-nat трафик
Пример посложнее, что делать если за роутером находится сервер (например web) в частной подсети и необходимо обеспечить доступ к нему по любому из провайдеров.
Суть проблемы будет та же, решение похоже на вариант с Firewall Mangle, только будут использоваться другие цепочки: 
На схеме не отображен NAT, но думаю и так все понятно.
MultiWAN и исходящие соединения
Можно использовать возможности PBR для создания нескольких vpn (в примере SSTP) соединений с разных интерфейсов роутера.
Дополнительные таблицы маршрутизации:
Простые правила NAT, иначе пакет уйдет с интерфейса с неправильным Src. Address:
Интересно, что на роутере вы увидите следующую таблицу соединений: 
На VPN сервере (на тестовом стенде он у меня один) можно увидеть что все соединения происходят с правильных адресов: 
Постой способ
Есть способ проще, можно просто указать определенный шлюз для каждого из адресов:
Распределение соединений пользователей по каналам связи
Простые, повседневные задачи. Опять же понадобятся дополнительные таблицы маршрутизации:
Используя [IP]->[Route]->[Rules] 
Используя маркировки в [IP]->[Firewall]->[Mangle]
Простой пример со списками ip адресов. В принципе можно использовать практически любые условия. Единственное предостережение layer7, даже в паре с метками соединений, может показаться что всё работает правильно, но часть трафика всеравно уйдет не туда. 
«Запереть» пользователей в одной таблице маршрутизации можно через [IP]->[Route]->[Rules] :
Либо через [IP]->[Firewall]->[Filter] :
В примере с использованием [IP]->[Route]->[Rules] подобных исключений нет, но трафик до локальных процессов доходит. Дело в том, что попадая в FIB пакет промаркированный в [PREROUTING|Mangle] имеет маршрутную метку и уходит в таблицу маршрутизации отличную от main, где нет локального интерфейса. В случае с Routing Rules, сначала проверяется предназначен ли пакет локальному процессу и только на этапе User PBR он уходит в заданную таблицу маршрутизации.
Используя [IP]->[Firewall]->[Mangle action=route]
Данное действие работает только в [Prerouting|Mangle] и позволяет направлять трафик на указанный шлюз без использования дополнительных таблиц маршрутизации, указывая адрес шлюза напрямую:
Динамическая балансировка на основе PPC
Per Connection Classificator — является более гибким аналогом ECMP. В отличии от ECMP делит трафик по соединениям более строго (ECMP ничего про соединения не знает, но в паре с Routing Cache получается нечто похожее).
PCC берет указанные поля из ip заголовка, преобразует их в 32-битное значение и делит на знаменатель. Остаток от деления сравнивается с указанным остатком и если они совпадают, то применяется указанное действие. Подробнее. Звучит дико, но работает. 
Пример с тремя адресами:
Пример динамического распределения трафика по src.address между тремя каналами: 
Переключение каналов связи
Check ping — хороший инструмент, но он проверяет связь только с ближайшим IP пиром, сети провайдеров обычно состоят из большого числа маршрутизаторов и обрыв связи может произойти за пределами ближайшего пира, а дальше идут магистральные операторы связи у которых тоже могут случаться проблемы, в общем check ping не всегда показывает актуальную информацию о доступе в глобальную сеть.
Если у провайдеров и крупных корпораций есть протокол динамической маршрутизации BGP, то домашним и офисным пользователем приходится самостоятельно придумывать как проверять доступ в интернет через определенный канал связи.
Обычно используются скрипты, которые через определенный канал связи проверяют доступность ip адреса в сети интернет, при этом выбирается что то надежное, например google dns: 8.8.8.8. 8.8.4.4. Но в сообществе Mikrotik для этого приспособили более интересный инструмент.
Пара слов про рекурсивную маршрутизацию
Рекурсивная маршрутизация необходима при построении Multihop BGP пиринга и в статью про основы статической маршрутизации попала только за счет ушлых пользователей MikroTik, которые придумали как использовать рекурсивный маршруты в паре с check gateway для переключение каналов связи без дополнительных скриптов.
Пришло время в общих чертах разобраться с опциями scope/target scope и каким образом маршрут привязывается к интерфейсу: 
При наличии рекурсивного маршрута происходит все тоже самое, но в два этапа: 
Пример использования рекурсивной маршрутизации для переключения маршрутов 
Конфигурация: 
Можно проверить, что пакеты будут отправляться на 10.10.10.1: 
Check gateway ничего не знает про рекурсивную маршрутизацию и просто отправляет ping’и на адрес 8.8.8.8, который (исходя из таблицы main) доступен через шлюз 10.10.10.1.
Если происходит потеря связи между 10.10.10.1 и 8.8.8.8, то происходит отключение маршрута, но пакеты (включая проверочные ping) до 8.8.8.8 продолжают идти через 10.10.10.1: 
Если происходит потеря линка на ether1, то получается неприятная ситуация, когда пакеты до 8.8.8.8 пойдут через второго провайдера: 
Это проблема, если вы используете NetWatch для запуска скриптов при недоступности 8.8.8.8. При обрыве линка NetWatch просто отработает по резервному каналу связи и будет считать что все нормально. Решается добавлением дополнительного фильтрующего маршрута:
На хабре есть статья, где ситуация с NetWatch рассмотрена более детально.
И да, при использовании подобного резервирования адрес 8.8.8.8 будет жестко привязан к одному из провайдеров, соответственно выбирать его в качестве источника dns не самая хорошая идея.
Пара слов про Virtual Routing and Forwarding (VRF)
Технология VRF предназначена для создания нескольких виртуальных маршрутизаторов внутри одного физического, данная технология широко применяется у операторов связи (обычно в связке с MPLS) для предоставления услуги L3VPN клиентам с пересекающимися адресами подсетей: 
Но VRF в Mikrotik организован на базе таблиц маршрутизации и имеет ряд недостатков, например локальные ip адреса роутера доступны из всех VRF, подробнее можно почитать по ссылке.
Пример конфигурации vrf: 
С устройства подключенного к ether2 видим, что проходит ping до адреса роутера из другого vrf (и это проблема), при этом ping в интернет не уходит: 
Для доступа в интернет необходимо прописать дополнительный маршрут обращающийся к таблице main (в терминологии vrf это называется route leaking): 
И настроить маркировку для ответного трафика в [PREROUTING|Mangle] : 
Подсети с одинаковой адресацией
Организация доступа до подсетей с одинаковой адресацией на одном роутере используя VRF и netmap: 
Правила маршрутизации для возвратного трафика:
Добавление маршрутов полученных по dhcp в заданную таблицу маршрутизации
VRF может быть интересен, если необходимо автоматически добавить динамический маршрут (например от dhcp client) в определенную таблицу маршрутизации.
Добавление интерфейса в vrf:
Правила для отправки трафика (исходящего и транзитного) через таблицу over-isp1:
Дополнительный, фейковый маршрут для работы исходящей маршрутизции:
Этот маршрут необходим только чтобы локальные исходящие пакеты могли пройти через Routing decision (2) до [OUTPUT|Mangle] и получить маршрутную метку, если на маршрутизаторе есть другие активные маршруты до 0.0.0.0/0 в таблице main оно не требуется. 
Фильтрация маршрутов (входящий и исходящих) — это инструмент который обычно используется вместе с протоколами динамической маршрутизации (поэтому доступен только после установки пакета routing), но во входящих фильтрах есть две интересные цепочки:
Это очень точечный инструмент и если можете сделать что-то без Routing Filters (но не скриптами), то не используйте Routing Filters, не путайте себя и тех кто будет конфигурировать роутер после вас. В контексте динамической маршрутизации Routing Filters будут использоваться значительно чаще и продуктивнее.
Установка Routing Mark для динамических маршрутов
Пример с домашнего маршрутизатора. У меня настроено два VPN соединения и трафик в них должен заворачиваться в соответствием с таблицами маршрутизации. При этом я хочу что-бы маршруты создавались автоматически при активации интерфейса:
Не знаю почему, наверное баг, но если создать vrf для ppp интерфейса, то маршрут до 0.0.0.0/0 всеравно попадет в таблицу main. Иначе всё было бы еще проще.
Отключение Connected маршрутов
Иногда требуется и такое:
Инструменты отладки
RouterOS предоставляет ряд средств для отладки маршрутизации: