27 ноября 2014 в 19:01

Mikrotik. Failover. Load Balancing из песочницы

Когда у меня встала необходимость разобраться, как сделать failover или load balancing, имея два и более каналов в мир, я нашел множество статей и инструкций, в которых описывались рабочие конфигурации. Но почти нигде не нашел разъяснения, как все работает, и описания отличий разных вариантов. Хочу исправить эту несправедливость и собрать простейшие варианты построения failover и load balancing конфигураций в одной статье.

Итак, у нас есть роутер, который соединяет нашу локальную сеть и два канала в интернет (основной ISP1 и резервный ISP2).

Давайте рассмотрим что же мы можем сделать:

Сразу предупрежу: несмотря на то, что в этой статье буду все описывать для mikrotik, не буду касаться темы скриптов

Failover


image

У нас появился резервный канал, в который можно направить трафик при отказе основного. Но как сделать, чтобы mikrotik понял, что канал упал?

Простейшее резервирование каналов


Простейший failover можно настроить, используя приоритет маршрута (distance у mikrotik/cisco, metric в linux/windows), а так же механизм проверки доступности шлюза — check-gateway.

В приведенной ниже конфигурации весь интернет трафик по умолчанию ходит через 10.100.1.254 (ISP1). Но как только адрес 10.100.1.254 станет недоступным (а маршрут через него неактивным) — трафик пойдет через 10.200.1.254 (ISP2).

конфигурация: простейший failover
# Настроим сети провайдеров:
/ip address add address=10.100.1.1/24 interface=ISP1
/ip address add address=10.200.1.1/24 interface=ISP2
# Настроим локальный интерфейс 
/ip address add address=10.1.1.1/24 interface=LAN
# скроем за NAT все что выходит из локальной сети
/ip firewall nat add src-address=10.1.1.0/24 action=masquerade chain=srcnat
###Обеспечение резервирования каналов традиционным способом###
# укажем 2 default gateway с разными приоритетами
/ip route add dst-address=0.0.0.0/0 gateway=10.100.1.254 distance=1 check-gateway=ping
/ip route add dst-address=0.0.0.0/0 gateway=10.200.1.254 distance=2 check-gateway=ping


check-gateway=ping для mikrotik обрабатывается так:
Периодически (каждые 10 секунд) шлюз проверяется отсылкой на него ICMP пакета (ping). Потерянным пакет считается, если он не вернулся в течении 10 секунд. После двух потерянных пакетов шлюз считается недоступным. После получения ответа от шлюза он становится доступным и счетчик потерянных пакетов сбрасывается.


Обеспечение failover с более глубоким анализом канала


В прошлом примере все замечательно, кроме ситуации, когда шлюз провайдера виден и пингуется, но интернета за ним нет. Нам бы это здорово помогло, если бы можно было принимать решение о жизнеспособности провайдера, пингуя не сам шлюз, а что-то за ним.

Я знаю два варианта решения этой инженерной задачи. Первый и самый распространенный — использовать скрипты, но так как в этой статье мы скрипты не трогаем, остановимся подробнее на втором. Он подразумевает не совсем корректное использование параметра scope, но поможет нам прощупать канал провайдера глубже, чем до шлюза.
Принцип прост:
Вместо традиционного указания default gateway=шлюз провайдера, мы скажем роутеру что default gateway это какой-то из всегда_доступных_узлов (например 8.8.8.8 или 8.8.4.4) и он в свою очередь доступен через шлюз провайдера.

конфигурация: failover с более глубоким анализом канала
# Настроим сети провайдеров:
/ip address add address=10.100.1.1/24 interface=ISP1
/ip address add address=10.200.1.1/24 interface=ISP2
# Настроим локальный интерфейс 
/ip address add address=10.1.1.1/24 interface=LAN
# скроем за NAT все что выходит из локальной сети
/ip firewall nat add src-address=10.1.1.0/24 action=masquerade chain=srcnat
###Обеспечение failover c более глубоким анализом канала###
#с помощью параметра scope укажем рекурсивные пути к узлам 8.8.8.8 и 8.8.4.4
/ip route add dst-address=8.8.8.8 gateway=10.100.1.254 scope=10
/ip route add dst-address=8.8.4.4 gateway=10.200.1.254 scope=10
# укажем 2 default gateway через узлы путь к которым указан рекурсивно
/ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1 check-gateway=ping
/ip route add dst-address=0.0.0.0/0 gateway=8.8.4.4 distance=2 check-gateway=ping


Теперь разберем, что происходит чуть подробнее:
Хитрость в том, что шлюз провайдера не знает о том, что 8.8.8.8 или 8.8.4.4 — это роутер и направит трафик по обычному пути.
Наш mikrotik считает, что по умолчанию весь интернет трафик нужно отправлять на 8.8.8.8, который напрямую не виден, но через 10.100.1.254 доступен. А если пинг на 8.8.8.8 пропадает (напомню что путь к нему у нас жестко указан через шлюз от ISP1) то mikrotik начнет слать весь интернет трафик на 8.8.4.4, а точнее на рекурсивно определенный 10.200.1.254 (ISP2).

Но у меня пару раз возникала ситуация, когда интернет через шлюз провайдера работает, а вот конкретный узел или сеть нет. В таких случаях вышеописанный метод не очень-то помогает и для обеспечения бесперебойной работы мне приходилось проверять доступность узла уже с помощью скриптов. Кстати, если кто знает решение файловера на один внешний хост без применения скриптов и протоколов динамической маршрутизации — поделитесь рецептом.

Load Balancing


Теперь давайте рассмотрим другую схему:

image

В ней второй второй канал уже не резервный, а равноценный. Почему бы не использовать оба канала одновременно, повысив таким образом пропускную способность?

Начинаем настраивать Load Balancing


Первое правило Load Balancing — следить за соединениями: на пришедшее извне соединение отвечать с того же адреса, на который оно пришло. Для исходящих соединений — отправлять пакеты только через тот адрес, с которым установилось соединение.

Второе, что тоже важно понимать — нужно разделять понятия входящего и исходящего трафика. Дело в том, что для исходящего трафика роутер может решать, по какому пути он пойдет, а входящий трафик для него как «трафик Шредингера». Пока его нет, наш mikrotik не знает, через какой интерфейс он придет, а когда пришел — менять интерфейс уже поздно.

Третье — балансировка каналов не является резервированием. Это две отдельные функции.

Кстати почему при разделе трафика мы оперируем соединениями, а не пакетами?
Почитайте, как работает TCP протокол. Если коротко — задача TCP протокола не только швырнуть пакетом в получателя, но и проконтролировать, как тот его принял. Делается это с помощью установки соединения, в рамках которого, собственно, и передаются пакеты данных — вместе со служебной информацией. Если оперировать пакетами и забыть про соединения, то возможны ситуации, когда удаленный хост, установив соединение с одним адресом, просто отбросит часть пакетов пришедшую со второго — «неправильного» адреса.


Готовимся принять «трафик Шредингера»


Итак, при любом варианте балансировки канала нам нужно сначала подготовиться к принятию входящего трафика и научить mikrotik отвечать на входящие соединения в тот же канал, из которого они пришли. С помощью маркировки соединений и последующей маркировки маршрутов для них мы, по сути, делаем несколько таблиц маршрутизации, отдельных для каждого внешнего адреса.

начальная конфигурация для load balancing с двумя внешними IP адресами
# Настроим сети провайдеров:
/ip address add address=10.100.1.1/24 interface=ISP1
/ip address add address=10.200.1.1/24 interface=ISP2
# Настроим локальный интерфейс 
/ip address add address=10.1.1.1/24 interface=LAN
# скроем за NAT все что выходит из локальной сети
/ip firewall nat add src-address=10.1.1.0/24 action=masquerade chain=srcnat
#Пометим каждое соединение пришедшее снаружи и адресованное нашему роутеру:
/ip firewall mangle add action=mark-connection chain=input in-interface=ISP1 new-connection-mark=cin_ISP1
/ip firewall mangle add action=mark-connection chain=input in-interface=ISP2 new-connection-mark=cin_ISP2
#что бы отвечать через те же интерфейсы, откуда пришли запросы, поставим соответствующую роутинг-марку на каждое соединение.
/ip firewall mangle add action=mark-routing chain=output connection-mark=cin_ISP1 new-routing-mark=rout_ISP1 passthrough=no
/ip firewall mangle add action=mark-routing chain=output connection-mark=cin_ISP2 new-routing-mark=rout_ISP2 passthrough=no
#добавим default gateway в каждую из промаркированных таблиц маршрутизации:
/ip route add distance=1 gateway=10.100.1.254 routing-mark=rout_ISP1 check-gateway=ping
/ip route add distance=1 gateway=10.200.1.254 routing-mark=rout_ISP2 check-gateway=ping


Таким образом mikrotik будет проводить каждый пакет помеченного соединения по соответствующей таблице маршрутизации и внешние адреса (10.100.1.1, 10.200.1.1) будут доступны извне без путаницы в каналах и маршрутах.

Делим исходящий трафик


Для распределения исходящего трафика по интерфейсам, нам всего-то нужно повесить соответствующую марку маршрута на соединение. Сложность в том, что нужно решить на какое соединение вешать метку ISP1, а на какое ISP2.

Существует несколько вариантов разделения соединений по группам:

1) Делим исходящий трафик, прикручивая марку намертво


Правила, балансирующие трафик мы можем прописать жестко:
Например мы хотим настроить важные для нас протоколы HTTP(80 port), HTTPS (443 port), POP (110 port), SMTP (25 port) через ISP1, а весь остальной трафик пустить через второго провайдера:

конфигурация с балансировкой канала по жестко прописанным правилам
# Настроим сети провайдеров:
/ip address add address=10.100.1.1/24 interface=ISP1
/ip address add address=10.200.1.1/24 interface=ISP2
# Настроим локальный интерфейс 
/ip add address=10.1.1.1/24 interface=LAN
# скроем за NAT все что выходит из локальной сети
/ip firewall nat add src-address=10.1.1.0/24 action=masquerade chain=srcnat
#Пометим каждое соединение пришедшее снаружи и адресованное нашему роутеру:
/ip firewall mangle add action=mark-connection chain=input in-interface=ISP1 new-connection-mark=cin_ISP1
/ip firewall mangle add action=mark-connection chain=input in-interface=ISP2 new-connection-mark=cin_ISP2
#что бы отвечать через те же интерфейсы, откуда пришли запросы, поставим соответствующую роутинг-марку на каждое соединение.
/ip firewall mangle add action=mark-routing chain=output connection-mark=cin_ISP1 new-routing-mark=rout_ISP1 passthrough=no
/ip firewall mangle add action=mark-routing chain=output connection-mark=cin_ISP2 new-routing-mark=rout_ISP2 passthrough=no
#добавим default gateway в каждую из промаркированных таблиц маршрутизации:
/ip route add distance=1 gateway=10.100.1.254 routing-mark=rout_ISP1 check-gateway=ping
/ip route add distance=1 gateway=10.200.1.254 routing-mark=rout_ISP2 check-gateway=ping
#failover через второго провайдера для каждого из шлюзов
/ip route add distance=2 gateway=10.200.1.254 routing-mark=rout_ISP1 
/ip route add distance=2 gateway=10.100.1.254 routing-mark=rout_ISP2 
# отправим трафик идущий к портам 80,443,110,25 на ISP1
/ip firewall mangle add chain=prerouting action=mark-routing new-routing-mark="lan_out_ISP1" passthrough=no dst-port=80,443,110,25 protocol=tcp 
#а весь остальной трафик на ISP2:
/ip firewall add chain=prerouting action=mark-routing new-routing-mark="lan_out_ISP2" passthrough=no
#добавим default gateway в каждую из промаркированных для LAN трафика таблиц маршрутизации:
/ip route add distance=1 gateway=10.100.1.254 routing-mark=lan_out_ISP1 check-gateway=ping
/ip route add distance=1 gateway=10.200.1.254 routing-mark=lan_out_ISP2 check-gateway=ping
#failover через второго провайдера для каждого из шлюзов
/ip route add distance=2 gateway=10.200.1.254 routing-mark=lan_out_ISP1 
/ip route add distance=2 gateway=10.100.1.254 routing-mark=lan_out_ISP2 



2) Делим исходящий трафик, выбирая каждое Н-ое соединение


Можем делить соединения по-порядку. Первые налево, вторые — направо. Все просто.

конфигурация с балансировкой канала по Н-ному соединению:
# Настроим сети провайдеров:
/ip address add address=10.100.1.1/24 interface=ISP1
/ip address add address=10.200.1.1/24 interface=ISP2
# Настроим локальный интерфейс 
/ip address add address=10.1.1.1/24 interface=LAN
# скроем за NAT все что выходит из локальной сети
/ip firewall nat add src-address=10.1.1.0/24 action=masquerade chain=srcnat
#Пометим каждое соединение пришедшее снаружи и адресованное нашему роутеру:
/ip firewall mangle add action=mark-connection chain=input in-interface=ISP1 new-connection-mark=cin_ISP1
/ip firewall mangle add action=mark-connection chain=input in-interface=ISP2 new-connection-mark=cin_ISP2
#что бы отвечать через те же интерфейсы, откуда пришли запросы, поставим соответствующую роутинг-марку на каждое соединение.
/ip firewall mangle add action=mark-routing chain=output connection-mark=cin_ISP1 new-routing-mark=rout_ISP1 passthrough=no
/ip firewall mangle add action=mark-routing chain=output connection-mark=cin_ISP2 new-routing-mark=rout_ISP2 passthrough=no
#добавим default gateway в каждую из промаркированных для внешних адресов таблиц маршрутизации:
/ip route add distance=1 gateway=10.100.1.254 routing-mark=rout_ISP1 check-gateway=ping
/ip route add distance=1 gateway=10.200.1.254 routing-mark=rout_ISP2 check-gateway=ping
#из каждых двух соединений первое пометим на отсылку через ISP1
/ip firewall mangle add src-address=10.1.1.0/24 action=mark-routing chain=prerouting new-routing-mark=lan_out_ISP1 nth=2,1
#а второе на отсылку через ISP2
/ip firewall mangle add src-address=10.1.1.0/24 action=mark-routing chain=prerouting new-routing-mark=lan_out_ISP2 nth=2,2
#добавим default gateway в каждую из промаркированных для LAN трафика таблиц маршрутизации:
/ip route add distance=1 gateway=10.100.1.254 routing-mark=lan_out_ISP1 check-gateway=ping
/ip route add distance=1 gateway=10.200.1.254 routing-mark=lan_out_ISP2 check-gateway=ping
#failover через второго провайдера для каждого из шлюзов
/ip route add distance=2 gateway=10.200.1.254 routing-mark=lan_out_ISP1 
/ip route add distance=2 gateway=10.100.1.254 routing-mark=lan_out_ISP2 



3) Делим исходящий трафик, используя PCC (per connection classifier)


PCC подходит к дележу трафика чуть сложнее. Он разделяет трафик по группам, основываясь на данных TCP заголовка (src-address, dst-address, src-port, dst-port).

конфигурация с балансировкой канала по PPC:
# Настроим сети провайдеров:
/ip address add address=10.100.1.1/24 interface=ISP1
/ip address add address=10.200.1.1/24 interface=ISP2
# Настроим локальный интерфейс 
/ip address add address=10.1.1.1/24 interface=LAN
# скроем за NAT все что выходит из локальной сети
/ip firewall nat add src-address=10.1.1.0/24 action=masquerade chain=srcnat
#Пометим каждое соединение пришедшее снаружи и адресованное нашему роутеру:
/ip firewall mangle add action=mark-connection chain=input in-interface=ISP1 new-connection-mark=cin_ISP1
/ip firewall mangle add action=mark-connection chain=input in-interface=ISP2 new-connection-mark=cin_ISP2
#что бы отвечать через те же интерфейсы, откуда пришли запросы, поставим соответствующую роутинг-марку на каждое соединение.
/ip firewall mangle add action=mark-routing chain=output connection-mark=cin_ISP1 new-routing-mark=rout_ISP1 passthrough=no
/ip firewall mangle add action=mark-routing chain=output connection-mark=cin_ISP2 new-routing-mark=rout_ISP2 passthrough=no
#добавим default gateway в каждую из промаркированных таблиц маршрутизации:
/ip route add distance=1 gateway=10.100.1.254 routing-mark=rout_ISP1 check-gateway=ping
/ip route add distance=1 gateway=10.200.1.254 routing-mark=rout_ISP2 check-gateway=ping
#failover через второго провайдера для каждого из шлюзов
/ip route add distance=2 gateway=10.200.1.254 routing-mark=rout_ISP1 
/ip route add distance=2 gateway=10.100.1.254 routing-mark=rout_ISP2 
#используя PPC разделим трафик на две группы по исх. адресу и порту
/ip firewall mangle add src-address=10.1.1.0/24 action=mark-routing chain=prerouting new-routing-mark=lan_out_ISP1 per-connection-classifier=src-address-and-port:2/0
/ip firewall mangle add src-address=10.1.1.0/24 action=mark-routing chain=prerouting new-routing-mark=lan_out_ISP2 per-connection-classifier=src-address-and-port:2/1
#добавим default gateway в каждую из промаркированных для LAN трафика таблиц маршрутизации:
/ip route add distance=1 gateway=10.100.1.254 routing-mark=lan_out_ISP1 check-gateway=ping
/ip route add distance=1 gateway=10.200.1.254 routing-mark=lan_out_ISP2 check-gateway=ping
#failover через второго провайдера для каждого из шлюзов
/ip route add distance=2 gateway=10.200.1.254 routing-mark=lan_out_ISP1 
/ip route add distance=2 gateway=10.100.1.254 routing-mark=lan_out_ISP2 



Делим исходящий трафик, используя ECMP (equal cost multipath routing)


На мой взгляд самый простой и вкусный вариант разделения траффика:

конфигурация с балансировкой канала по ECMP
# Настроим сети провайдеров:
/ip address add address=10.100.1.1/24 interface=ISP1
/ip address add address=10.200.1.1/24 interface=ISP2
# Настроим локальный интерфейс 
/ip address add address=10.1.1.1/24 interface=LAN
# скроем за NAT все что выходит из локальной сети
/ip firewall nat add src-address=10.1.1.0/24 action=masquerade chain=srcnat
#Пометим каждое соединение пришедшее снаружи и адресованное нашему роутеру:
/ip firewall mangle add action=mark-connection chain=input in-interface=ISP1 new-connection-mark=cin_ISP1
/ip firewall mangle add action=mark-connection chain=input in-interface=ISP2 new-connection-mark=cin_ISP2
#что бы отвечать через те же интерфейсы, откуда пришли запросы, поставим соответствующую роутинг-марку на каждое соединение.
/ip firewall mangle add action=mark-routing chain=output connection-mark=cin_ISP1 new-routing-mark=rout_ISP1 passthrough=no
/ip firewall mangle add action=mark-routing chain=output connection-mark=cin_ISP2 new-routing-mark=rout_ISP2 passthrough=no
#добавим default gateway в каждую из промаркированных таблиц маршрутизации:
/ip route add distance=1 gateway=10.100.1.254 routing-mark=rout_ISP1 check-gateway=ping
/ip route add distance=1 gateway=10.200.1.254 routing-mark=rout_ISP2 check-gateway=ping
#промаркируем весь траффик из локальной сети
/ip firewall mangle add src-address=10.1.1.0/24 action=mark-routing chain=prerouting new-routing-mark=mixed
#используем ECMP для балансировки траффика из локальной сети
/ip route add dst-address=0.0.0.0/0 gateway=10.100.1.254,10.200.1.254 routing-mark=mixed


Mikrotik сам поделит трафик по шлюзам, используя round-robin алгоритм.

Кстати, в версии 6.Х RouterOS mikrotik поломал check-gateway в ECMP, так что использовать конструкцию
/ip route add gateway=10.100.1.254,10.200.1.254 check-gateway=ping можно и логично, но абсолютно бесполезно.
Для пометки неживых маршрутов в ECMP нужно создать дополнительные маршруты, которые используют каждый из gateway по-отдельности. С включенным check-gateway разумеется. Помечая маршрут неактивным, mikrotik делает это для всех.

И последнее немаловажное замечание про скорость каналов


Возьмем 2 неравнозначных канала, например, 100 мбит и 50 мбит. Сбалансируем их через Nth, PCC или ECMP. Какую суммарную пропускную способность получим?

На самом деле — где-то около 100 мбит (самый слабый канал Х раз).
Происходит это потому, что mikrotik понятия не имеет о пропускной способности каналов, он ее не измеряет. Он просто делит трафик на относительно равные группы.

Побороть этот нюанс можно правильно проектируя группы исходящего трафика, с учетом пропускной способности каналов.

Например
в ECMP это можно сделать указав более скоростной шлюз несколько раз, тем самым повышая частоту его использования.
/ip route add dst-address=0.0.0.0/0 gateway=10.100.1.254,10.100.1.254,10.200.1.254


В PCC тоже можно сделать неравные группы:

/ip firewall mangle add src-address=10.1.1.0/24 action=mark-routing chain=prerouting new-routing-mark=lan_out_ISP1 per-connection-classifier=src-address-and-port:3/0
/ip firewall mangle add src-address=10.1.1.0/24 action=mark-routing chain=prerouting new-routing-mark=lan_out_ISP1 per-connection-classifier=src-address-and-port:3/1
/ip firewall mangle add src-address=10.1.1.0/24 action=mark-routing chain=prerouting new-routing-mark=lan_out_ISP2 per-connection-classifier=src-address-and-port:3/2



Спасибо за внимание.

Удачи в настройках безотказных систем маршрутизации.
Виктор @vdemchuk
карма
16,0
рейтинг 0,0
Самое читаемое Администрирование

Комментарии (39)

  • +1
    Отличная статья, спасибо.
    Добро пожаловать на Хабр.
  • 0
    Огромное спасибо! Как раз взял домой 951-ый микротик для организации резервирования 2-ух проводных ISP и балансировки нагрузки!
  • 0
    ECMP штука простая, вот только таблица роутинга обнуляется каждые 10 минут. Как следствие — соединение может пойти через другого провайдера, что из-за использования nat'а приведёт к обрыву соединения.
    PPC надёжнее.
    • 0
      ППК это что? Пер Пакет Класифаер? :-)
      • 0
        Разделитель Различных Соединений! PCC, конечно, опечатка.
  • –2
    Ну вроде бы по делу написано, но уж больно как то на уровне начальных уроков. Обычно такие проблемы возникают у совсем новичков. Хотя как часть книги «настраиваем микротик за 24 часа» очень даже круто. Так сказать сухо и по делу без лишней информации.
  • +2
    Урра! наконец-то вышла хорошая статья на эту тему. Добавить даже сразу особо нечего.
    • 0
      придумал, что добавить: накидайте больше тегов и фраз в конце текста, наподобие: «баласерофка тырнета» или «атказаусточивасть на некротике». Чтобы легче потом в поиске находилось кому понадобится.
      это шутка, пишите грамотно
    • 0
      Спасибо.
      А добавить есть что.
      Например если оба провайдера не используют статику или Point-to-Point соединения, а дают нам динамическую адресацию по DHCP, причем меняя и адреса default gateway.
      тогда невозможно напрямую прописать маркировки трафика.

      Вариант решения у меня есть, оттестирую что он работает и выложу небольшой апдейт.
      • 0
        о! у меня второй ISP пчелайн с их забористым L2TP…
        Жду с нетерпением!
        • 0
          а у пчелайна в чем забористость L2TP?
          вроде L2TP — Point-to-Point и сам туннель можно в качестве роута указывать.
          или там Dual Access (то что в старых прошивках Длинка называют Russian PPTP/L2TP)?
          в смысле сначала DHCP с роутом на 0.0.0.0/0 а не только свои сети, и поверх уже L2TP туннель.
        • 0
          кстати пока добавлю куда копать, если провайдер раздает DHCP — 1) при настройке DHCP client в микротик можно задать distance.
          2) в подразделе routing (динамическая маршрутизация) у микротика есть filter. С его помощью можно на все маршруты приходящие по DHCP автоматом метить.
      • 0
        Получилось? :)
      • 0
        Получилось придумать оптимальный вариант для DHCP-выдаваемых адресов у обоих ISP?
        Пока единственное, что нашлось — скриптом обновлять каждый раз.

        Примерно таким.
        :global newgw [/ip dhcp-client get [find interface="ether1-gateway" ] gateway ]
        :global activegw [/ip route get [/ip route find comment="Ether1-Wan"] gateway ]
        :if ($newgw != $activegw) do={
        /ip route set [find comment="Ether1-Wan"] gateway=$newgw
        /ip route set [find comment="Ether1-Wan routing gateway"] gateway=$newgw
        }
        :global newgw [/ip dhcp-client get [find interface="ether2-gateway" ] gateway ]
        :global activegw [/ip route get [/ip route find comment="Ether2-Wan"] gateway ]
        :if ($newgw != $activegw) do={
        /ip route set [find comment="Ether2-Wan"] gateway=$newgw
        /ip route set [find comment="Ether2-Wan routing gateway"] gateway=$newgw
        }
  • 0
    В первой части статьи ставился вопрос: как обнаружить отсутствие соединения с Интернетом? Автор предлагал пинговать DNS Googl`а — IP 8.8.8.8. Замечу, что есть встроенное средство — /System/Watchdog, которое может перезагрузить роутер и отправить оповещение на e-mail. Для целей резервирования канала это не подходит, а для подключений через одного провайдера по одной линии — помогает в случае проблем с соединением.
  • 0
    Подскажите, а как «домешать» в вашу схему еще одну локальную подсеть?
    То есть я имею на микротике 2 локальные сети вида: 10.0.2.1, 10.0.33.1
    • 0
      Для начала добавить их в маскарадинг (нат)
      /ip firewall nat add src-address=10.0.2.0/24 action=masquerade chain=srcnat
      /ip firewall nat add src-address=10.0.33.0/24 action=masquerade chain=srcnat

      а потом разобраться с метками — в некоторых используются адреса локальной сети.
      • 0
        Ну еси я правильно понял, то еще надо для моих адресов локальной сети продублироать это правило:
        /ip firewall mangle add src-address=10.1.1.0/24 action=mark-routing chain=prerouting new-routing-mark=mixed — при этом заменить 10.1.1.0 на свое
  • 0
    Хотелось бы почитать про разграничение каналов и сетей, то есть:
    В микроик подключается 1 провод или оптика, с пулом на несколько адресов, теперь надо 1IP пустить в одну сеть, 2IP пустить в другую сеть и так далее… И было бы интересно про сквозное подключение почитать, когда 2IP не микроиком обслуживается, а пропускается дальше (как свитч).

    Выше описанная ситуация была, когда провайдер дал оптику и надо было настроить выше описанным методом.

    P.S.
    Провайдер давал просто адреса, не vlan
    • 0
      Так в этой ситуации микротик уже не выступает роутером. Объединить порты в bridge и настроить IP провайдера на хостах.
      Тут уже не будет балансировки и файловера на уровне IP. Если ее строить — то на канальном.
  • 0
    > это какой-то из всегда_доступных_узлов (например 8.8.8.8 или 8.8.4.4)

    На всякий случай уточню, что эти сервера всегда работают, но _не_всегда_ доступны. Так что пинг на них может и пропасть, просто потому, что они — anycast.

    В общем, либо пингу на такие точки верить с оглядкой (обобщать несколько замеров, брать не только гугловские ДНС, но и Яндексовские — всяко поближе будет).
  • 0
    О! Крутая статья. Так получилось, что наткнулся на не только сейчас. Спасибо мил человек за труды. Как вспомню как мне эта тема с маркировками в микро тике сложно давалась аж вздрагиваю. Был бы тогда под рукой такой мануал все прошло бы легче.
  • 0
    Данная схема не работает, если нужна связь между узлами в локальной подсети или подсетях.
    Причина проста: всем узлам задаётся таблица маршрутизации, в которой указан только 0.0.0.0/0 поэтому любые узлы мы ищем в интернетах, и, как ни странно, не находим.
    А вот если нам нужна маршрутизация внутри локальной сети — мы должны в каждое правило рядом с src-adress=172.16.0.0/22 добавить dst-adress=!172.16.0.0/22 (ip взяты «к примеру»), тогда при поиске узлов с локальным адресом mangle правило применено не будет, и будет назначена дефолтная main-таблица. (HINT! не забываем, что мы можем использовать не -adress а -adress-list — так имеем возможность гибкой настройки)
    Кроме того, сам микротик для исходящих от него самого пакетов и соединений полностью игнорирует routing-mark'и в input и output цепочках, указанные в mangle таблице, и всегда использует таблицу маршрутизации main, отсюда вытекает то, что:
    1) показанный здесь фильтр входящих на микротик соединений и отсылки их на тот же ISP не работает — микротик принимает соединение на интерфейс ISP, и пытается отослать его туда же, но сталкивается с тем, что no route to host
    2) сам микротик не может ничего получить из интернетов, т.к. мы лешаем его дефолт гейта
    Поправить это у меня пока не получилось (вернее получилось, задав дефолт гейт одного из ISP с метрикой 100, другого с метрикой 90 — но это костыль — так мы не имеем возможности отсылать входящие соединения туда, откуда они пришли, а только на интерфейс с меньшим значением метрики в таблице main)
    • 0
      т.е. по этой схеме совсем нельзя сделать доступ до самого роутера извне?
      очень печально, но всеже спасибо за очень подробный разбор полетов, действительно доходит аж до головы.
      • 0
        С небольшими корректировками возможно. Но через одного ISP, прописав в основную таблицу маршрутизации дефолт гейт через этого ISP с бОльшей метрикой, чем прочие маршруты, дабы использовался последним.
        Кроме того, если немного скорректировать балансировку с ECMP — вместо роутинг марка mixed использовать «дефолтный» main — должно работать полностью.
  • +1
    Интересно получается с манглами: если нет дефолтного маршрута то схема не работает.
    то есть для работающей схемы нужен дефолтный маршрут + два маршрута с метками.
    P.S. Это я про доступность роутера из-вне по разным интерфейсам.
  • 0
    А ведь и правда не работает балансировка исходящего траффика от самого микротика.
    Господа, может кто нибудь нашел способ? Поделитесь!
    Мне надо распределить по нескольким каналам несколько туннелей. Попробовал и EMCP, и PCC, счетчики растут но траффик бежит упорно через один интерфейс. Хотя если рассматривать таблицу прохождения пакетов iptables, то mangle output должен был поменять ему маршрут, далее route recheck.
    • 0
      Похоже я сам тупой, проблема судя по всему в алгоритме хеширования, я использую в качестве туннелей l2tp, а они и порт источник и порт назначения используют 1701, поэтому для алгоритма все одно..
  • 0
    Спасибо!
    Настроил failover с двумя провайдерами. А как быть с их DNS? Как сделать, что бы для каждого провайдера использовался «его» DNS?
    И ещё, если не сложно: следующим этапом планирую прикручивать OpenVPN-туннель. Внешний IP даёт только основной провайдера, его доступность >95%. Потеря туннеля при работе через резерв не беспокоит. Но не возникнет ли проблем с доступом в подсеть за туннелем, из-за предложенных «хитростей» в роутах?
    • 0
      А как насчет использования DNS того же Гугла?
      8.8.8.8 да 8.8.4.4
      • +1
        А как на счёт того, что не все провайдеры с этим соглашаются ;)?
        • 0
          Резонно)
    • 0
      Попробуйте на самом роутере поднять роль DNS-сервера, а в качестве источников для него укажите все DNS-серверы обоих провайдеров. Это костыль, но работать будет. Для внутренних абонентов укажите DNS-сервер, который на роутере.
      Второй вариант — статические маршруты.
      • 0
        До костыля с единым списком «всех DNS» я дотумкал самостоятельно, и как раз, понимая, что «это костыль» — хотел найти другое решение. Про «статические маршруты» — пока не осознал… Имеете ввиду прописать отдельно для LAN-WAN1 и LAN-WAN2?
        Кстати, а не честнее ли будет сделать failover на скриптах? Не нашёл сравнения преимуществ/недостатков этих двух решений.
        • 0
          статические маршруты — вы прописываете, что маршрут к конкретному IP должен идти только через шлюз первого провайдера, а к другому IP через другого провайдера.
          В коде это выглядит примерно так(по памяти):
          /ip route add dst-address=8.8.8.8 gateway=2.2.2.2
          /ip route add dst-address=8.8.4.4 gateway=1.1.1.1

          Файловер на скриптах — это попытка использования только одного провайдера в один момент времени. В случае полноценного использования двух каналов одновременно(а в случае падения одного из каналов использовать резервный) требуется подобное решение, которое описано в статье.
          Мне правда описанное в статье нравиться немного по другому делать, но этот способ тоже вполне жизнеспособен.
          • 0
            Мысль со статикой уловил — спасибо.
            Моя задача — как раз организация резервного канала, т.к. нет никакого смысла складывать «100мбит» основного и «2мбит» резервного. Кроме того, мне нравится идея оповещения (e-mail, SMS или ещё как) о падении «основного» — так у меня раньше жил mwan3 под OpenWRT. Я правильно понимаю, что «оповещение» один фиг скриптами будет?
            • 0
              Оповещение — самая простая задача, которую можно организовать в любом случае.

              Лично у меня оповещения работают через нетвоч, который дёргает скрипты.
              • 0
                AntiHelper:
                у меня оповещения работают через нетвоч, который дёргает скрипты

                Так и я про то, что без скриптов оповещения не сделать. Может тогда имеет смысл всё на скриптах?
                • 0
                  Решайте тем способом, который у Вас лучше всего получается.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.