Записки 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
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Manual:IP/Route
Applies to RouterOS: v3, v4, v5+
Contents
Overview
Router keeps routing information in several separate spaces:
Routing Information Base
RIB (Routing Information Base) contains complete routing information, including static routes and policy routing rules configured by the user, routing information learned from routing protocols, information about connected networks. RIB is used to filter routing information, calculate best route for each destination prefix, build and update Forwarding Information Base and to distribute routes between different routing protocols.
By default forwarding decision is based only on the value of destination address. Each route has dst-address property, that specifies all destination addresses this route can be used for. If there are several routes that apply to a particular IP address, the most specific one (with largest netmask) is used. This operation (finding the most specific route that matches given address) is called routing table lookup.
If routing table contains several routes with the same dst-address, only one of them can be used to forward packets. This route is installed into FIB and marked as active.
When forwarding decision uses additional information, such as a source address of the packet, it is called policy routing. Policy routing is implemented as a list of policy routing rules, that select different routing table based on destination address, source address, source interface, and routing mark (can be changed by firewall mangle rules) of the packet.
All routes by default are kept in the main routing table. Routes can be assigned to specific routing table by setting their routing-mark property to the name of another routing table. Routing tables are referenced by their name, and are created automatically when they are referenced in the configuration.
Each routing table can have only one active route for each value of dst-address IP prefix.
There are different groups of routes, based on their origin and properties.
Default route
Route with dst-address 0.0.0.0/0 applies to every destination address. Such route is called the default route. If routing table contains an active default route, then routing table lookup in this table will never fail.
Connected routes
Connected routes are created automatically for each IP network that has at least one enabled interface attached to it (as specifie in the /ip address configuration). RIB tracks status of connected routes, but does not modify them. For each connected route there is one ip address item such that:
Multipath (ECMP) routes
Because results of the forwarding decision are cached, packets with the same source address, destination address, source interface, routing mark and ToS are sent to the same gateway. This means that ECMP route does not perform pure per-connection balancing, but it can be used to load balance connections if at least one of previously mentioned parameters is different than previous connection. See interface bonding if you need to achieve per-packet load balancing.
To implement some setups, such as load balancing, it might be necessary to use more than one path to given destination. However, it is not possible to have more than one active route to destination in a single routing table.
ECMP (Equal cost multi-path) routes have multiple gateway nexthop values. All reachable nexthops are copied to FIB and used in forwarding packets.
OSPF protocol can create ECMP routes. Such routes can also be created manually.
Routes with interface as a gateway
Value of gateway can be specified as an interface name instead of the nexthop IP address. Such route has following special properties:
Route selection
Each routing table can have one active route for each destination prefix. This route is installed into FIB. Active route is selected from all candidate routes with the same dst-address and routing-mark, that meet the criteria for becoming an active route. There can be multiple such routes from different routing protocols and from static configuration. Candidate route with the lowest distance becomes an active route. If there is more than one candidate route with the same distance, selection of active route is arbitrary (except for BGP routes).
BGP has the most complicated selection process (described in separate article). Notice that this protocol-internal selection is done only after BGP routes are installed in the main routing table; this means there can be one candidate route from each BGP peer. Also note that BGP routes from different BGP instances are compared by their distance, just like other routes.
Criteria for selecting candidate routes
To participate in route selection process, route has to meet following criteria:
Nexthop lookup
Nexthop lookup is a part of the route selection process.
Routes that are installed in the FIB need to have interface associated with each gateway address. Gateway address (nexthop) has to be directly reachable via this interface. Interface that should be used to send out packets to each gateway address is found by doing nexthop lookup.
Some routes (e.g. iBGP) may have gateway address that is several hops away from this router. To install such routes in the FIB, it is necessary to find the address of the directly reachable gateway (an immediate nexthop), that should be used to reach the gateway address of this route. Immediate nextop addresses are also found by doing nexthop lookup.
Nexthop lookup is done only in the main routing table, even for routes with different value of routing-mark. It is necessary to restrict set of routes that can be used to look up immediate nexthops. Nexthop values of RIP or OSPF routes, for example, are supposed to be directly reachable and should be looked up only using connected routes. This is achieved using scope and target-scope properties.
Recursive nexthop lookup example
Interface and immediate nexthop are selected based on the result of nexthop lookup:
Forwarding Information Base
FIB (Forwarding Information Base) contains copy of information that is necessary for packet forwarding:
By default (when no routing-mark values are used) all active routes are in the main table, and there is only one hidden implicit rule («catch all» rule) that uses the main table for all destination lookups.
Routing table lookup
FIB uses following information from packet to determine it’s destination:
Possible routing decisions are:
Results of routing decision are remembered in the routing cache. This is done to improve forwarding performance. When another packet with the same source address, destination address, source interface, routing mark and ToS is routed, cached results are used. This also allows to implement load balancing using ECMP routes, because values used to lookup entry in the routing cache are the same for all packets that belong to the same connection and go in the same direction.
If there is no routing cache entry for this packet, it is created by running routing decision:
Result of routing decision can be:
Rules that do not match current packet are ignored. If rule has action drop or unreachable, then it is returned as a result of the routing decision process. If action is lookup then destination address of the packet is looked up in routing table that is specified in the rule. If lookup fails (there is no route that matches destination address of packet), then FIB proceeds to the next rule. Otherwise:
Result of this routing decision is stored in new routing cache entry.
Properties
Route flags
| Property(Flag) | Description |
|---|---|
| disabled (X) | Configuration item is disabled. It does not have any effect on other routes and is not used by forwarding or routing protocols in any way. |
| active (A) | Route is used for packet forwarding. See route selection. |
| dynamic (D) | Configuration item created by software, not by management interface. It is not exported, and cannot be directly modified. |
| connect (C) | connected route. |
| static (S) | static route. |
| rip (r) | RIP route. |
| bgp (b) | BGP route. |
| ospf (o) | OSPF route. |
| mme (m) | MME route. |
| blackhole (B) | Silently discard packet forwarded by this route. |
| unreachable (U) | Discard packet forwarded by this route. Notify sender with ICMP host unreachable (type 3 code 1) message. |
| prohibit (P) | Discard packet forwarded by this route. Notify sender with ICMP communication administratively prohibited (type 3 code 13) message. |
General properties
Other Read-only properties
| Property | Description |
|---|---|
| gateway-status (array) | Array of gateways, gateway states and which interface is used for forwarding. Syntax «IP state interface», for example «10.5.101.1 reachable bypass-bridge». State can be unreachable, reachable or recursive. See nexthop lookup for details. |
| ospf-metric (integer) | Used OSPF metric for particular route |
| ospf-type (string) |
BGP Route Properties
These properties contain information that is used by BGP routing protocol. However, values of these properties can be set for any type of route, including static and connected. It can be done either manually (for static routes) or using route filters.
Применение OSPF в MikroTik RouterOS (часть 3)
Ближайшие
тренинги Mikrotik
Места
проведения
г. Санкт-Петербург, Крестовский остров, Северная дорога, дом 12.
г. Санкт-Петербург, ст. м. «Приморская»,
ул. Одоевского, д. 24 к. 1, 2 этаж
Механизмы преобразования маршрутной информации, полученной в служебных сообщениях OSPF, в записи таблицы маршрутизации для перенаправления пакетов.
Введение
В предыдущих частях серии статей были рассмотрены теоретические основы протокола OSPF, типы областей и типы LSA, распространяемых протоколом.
В третьей части будут описаны механизмы преобразования маршрутной информации, полученной в служебных сообщениях OSPF, в записи таблицы маршрутизации для перенаправления пакетов.
Заполнение таблицы маршрутизации
После синхронизации LSDB в рамках каждой области, устройства запускают процесс вычисления дерева кратчайших путей (SPF), результатом которого должен стать расчёт маршрутов к каждой из известных сетей с определённой метрикой.
На следующем этапе вычисленные маршруты должны экспортироваться в таблицу маршрутизации FIB, однако на данной стадии учитывается ряд других факторов, таких как наличие других источников маршрутной информации, тип маршрута и метрика.
Параметр distance
Как упоминалось выше, у маршрутизатора может быть несколько источников маршрутной информации и, в случае если маршрут в одну и ту же сеть принят от разных источников, то помещение того или иного маршрута в FIB будет регулироваться параметров distance.
Рассмотрим пример, в котором демонстрируется использование нескольких источников маршрутов:
Маршрутизаторы R1 и R2 подключены двумя каналами связи, на которых выделена адресация 172.16.100.0/24 и 172.16.50.0/24. Помимо этого, eth4-интерфейс маршрутизатора R2 ассоциирован с сетью 10.0.0.0/8. Интерфейсы eth2 на обоих маршрутизаторах помещены в backbone area, причём R2 инжектирует в магистральную область маршрут к 10.0.0.0/8, как внешний.
Вам помогла эта статья?
Приглашаем пройти обучение в нашем тренинг-центре и научиться настраивать оборудование MikroTik на профессиональном уровне! Узнайте расписание ближайших курсов и бронируйте место!
Конфигурация устройств:
Метрика OSPF
Проанализируем таблицу маршрутизации R1:
Обратим внимание, что пакет в сеть 10.0.0.0/8 будет отправлен в сторону устройства с ip-адресом 172.16.100.2, т.е. на R2, c интерфейса eth2.
Добавим статический маршрут к сети 10.0.0.0/8 через шлюз 172.16.50.2, выполнив на R1 команду /ip route add dst-address=10.0.0.0/8 gateway=172.16.50.2, и проанализируем изменения в таблице маршрутизации:
По результатам вывода, после внесённых в конфигурацию изменений, все пакеты в сеть 10.0.0.0/8 будут отправлены с eth1-интерфейса. Это объясняется тем, что в базе данных маршрутов (RIB) R1 присутствует два маршрута к сети 10.0.0.0/8 от двух источников: один получен через OSPF (distance = 110), а другой из статических записей (distance = 1). Сравнив параметры distance этих маршрутов, R1 помещает в таблицу маршрутизации оба, однако активным (флаг A) делает только статический маршрут, т.к. его distance меньше.
Аналогичную ситуацию можно наблюдать для маршрута в сеть 172.16.50.0/24: один маршрут в эту сеть является непосредственно подключенным (distance = 0), а второй маршрут сообщает R2, т. к. eth1-интерфейс R2 ассоциирован с этой сетью (distance – 110).
Конфигурация устройств:
Основной метрикой, используемой в OSPF для выбора лучшего маршрута, является стоимость: в таблицу маршрутизации будет добавлен маршрут с меньшим значением стоимости.
Значение стоимости указывается в качестве параметра каждого интерфейса, ассоциированного с OSPF и может принимать значения от 1 до 65535. Стоимость пути в сеть равна сумме стоимостей исходящих интерфейсов на пути распространения LSA с этой маршрутной информацией. Значение стоимости маршрута равная 16777215 считается недостижим для OSPF и данный маршрут не будет добавлен в таблицу маршрутизации.
В RFC 2328 отсутствует описание методики расчёта стоимости интерфейсов, поэтому при построении сетей с применением оборудования нескольких вендоров необходимо учитывать разницу в алгоритмах расчёта метрики OSPF. В RouterOS по умолчанию для всех интерфейсов используется стоимость 10, однако её можно задать вручную. Используя гибкую настройку стоимостей возможно реализовать схемы с асимметричной маршрутизацией и балансировкой трафика.
Рассмотрим схему с асимметричной маршрутизацией, рисунок 32. Пусть маршрутизаторы R1 и R2 соединены двумя каналами связи, на которые выделены сети 172.16.50.0/24 и 172.16.100.0/24. Кроме того, за каждым из маршрутизаторов есть сеть: 10.0.1.0/24 за R1 и 10.0.2.0/24 за R2. Все интерфейсы маршрутизаторов ассоциированы с backbone area.
