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

Mikrotik. Failover. Load Balancing

Сетевые технологии

Из песочницы

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

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

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

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

Failover

У нас появился резервный канал, в который можно направить трафик при отказе основного. Но как сделать, чтобы 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

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

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

Начинаем настраивать 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

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

Удачи в настройках безотказных систем маршрутизации.

Метки:

Комментарии 40

Black_Sun 27.11.14 в 19:23
+1
Отличная статья, спасибо.
Добро пожаловать на Хабр.
avorsa 27.11.14 в 20:37
0
Огромное спасибо! Как раз взял домой 951-ый микротик для организации резервирования 2-ух проводных ISP и балансировки нагрузки!
Melkij 27.11.14 в 20:55
0
ECMP штука простая, вот только таблица роутинга обнуляется каждые 10 минут. Как следствие — соединение может пойти через другого провайдера, что из-за использования nat'а приведёт к обрыву соединения.
PPC надёжнее.
- erazel 27.11.14 в 20:59
  0
  ППК это что? Пер Пакет Класифаер? :-)
  - Melkij 27.11.14 в 21:03
    
    0
    Разделитель Различных Соединений! PCC, конечно, опечатка.
erazel 27.11.14 в 20:58
–2
Ну вроде бы по делу написано, но уж больно как то на уровне начальных уроков. Обычно такие проблемы возникают у совсем новичков. Хотя как часть книги «настраиваем микротик за 24 часа» очень даже круто. Так сказать сухо и по делу без лишней информации.
Ovsiannikov 27.11.14 в 22:11
+2
Урра! наконец-то вышла хорошая статья на эту тему. Добавить даже сразу особо нечего.
- Ovsiannikov 27.11.14 в 22:19
  0
  придумал, что добавить: накидайте больше тегов и фраз в конце текста, наподобие: «баласерофка тырнета» или «атказаусточивасть на некротике». Чтобы легче потом в поиске находилось кому понадобится.
  это шутка, пишите грамотно
- vdemchuk 28.11.14 в 12:04
  0
  Спасибо.
  А добавить есть что.
  Например если оба провайдера не используют статику или Point-to-Point соединения, а дают нам динамическую адресацию по DHCP, причем меняя и адреса default gateway.
  тогда невозможно напрямую прописать маркировки трафика.
  
  Вариант решения у меня есть, оттестирую что он работает и выложу небольшой апдейт.
  - avorsa 28.11.14 в 13:46
    
    0
    о! у меня второй ISP пчелайн с их забористым L2TP…
    Жду с нетерпением!
    - vdemchuk 28.11.14 в 14:10
      
      0
      
      а у пчелайна в чем забористость L2TP?
      вроде L2TP — Point-to-Point и сам туннель можно в качестве роута указывать.
      или там Dual Access (то что в старых прошивках Длинка называют Russian PPTP/L2TP)?
      в смысле сначала DHCP с роутом на 0.0.0.0/0 а не только свои сети, и поверх уже L2TP туннель.
    - vdemchuk 16.12.14 в 18:10
      
      0
      
      кстати пока добавлю куда копать, если провайдер раздает DHCP — 1) при настройке DHCP client в микротик можно задать distance.
      2) в подразделе routing (динамическая маршрутизация) у микротика есть filter. С его помощью можно на все маршруты приходящие по DHCP автоматом метить.
  - freemanlutsk 24.09.15 в 10:07
    
    0
    Получилось? :)
  - faeton 22.12.16 в 22:07
    
    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 }
Ostan 28.11.14 в 18:31
0
В первой части статьи ставился вопрос: как обнаружить отсутствие соединения с Интернетом? Автор предлагал пинговать DNS Googl`а — IP 8.8.8.8. Замечу, что есть встроенное средство — /System/Watchdog, которое может перезагрузить роутер и отправить оповещение на e-mail. Для целей резервирования канала это не подходит, а для подключений через одного провайдера по одной линии — помогает в случае проблем с соединением.
partizannn 16.12.14 в 17:47
0
Подскажите, а как «домешать» в вашу схему еще одну локальную подсеть?
То есть я имею на микротике 2 локальные сети вида: 10.0.2.1, 10.0.33.1
- vdemchuk 16.12.14 в 18:05
  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
  
  а потом разобраться с метками — в некоторых используются адреса локальной сети.
  - partizannn 17.12.14 в 10:49
    
    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 на свое
ruskella 03.01.15 в 15:39
0
Хотелось бы почитать про разграничение каналов и сетей, то есть:
В микроик подключается 1 провод или оптика, с пулом на несколько адресов, теперь надо 1IP пустить в одну сеть, 2IP пустить в другую сеть и так далее… И было бы интересно про сквозное подключение почитать, когда 2IP не микроиком обслуживается, а пропускается дальше (как свитч).

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

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

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

В общем, либо пингу на такие точки верить с оглядкой (обобщать несколько замеров, брать не только гугловские ДНС, но и Яндексовские — всяко поближе будет).
HunterXXI 04.06.15 в 21:23
0
О! Крутая статья. Так получилось, что наткнулся на не только сейчас. Спасибо мил человек за труды. Как вспомню как мне эта тема с маркировками в микро тике сложно давалась аж вздрагиваю. Был бы тогда под рукой такой мануал все прошло бы легче.
Ziptar 30.11.15 в 16:03
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)
- kpcp 12.05.16 в 20:45
  0
  т.е. по этой схеме совсем нельзя сделать доступ до самого роутера извне?
  очень печально, но всеже спасибо за очень подробный разбор полетов, действительно доходит аж до головы.
  - Ziptar 12.05.16 в 22:09
    
    0
    С небольшими корректировками возможно. Но через одного ISP, прописав в основную таблицу маршрутизации дефолт гейт через этого ISP с бОльшей метрикой, чем прочие маршруты, дабы использовался последним.
    Кроме того, если немного скорректировать балансировку с ECMP — вместо роутинг марка mixed использовать «дефолтный» main — должно работать полностью.
sergeyklenov 26.01.16 в 10:47
+1
Интересно получается с манглами: если нет дефолтного маршрута то схема не работает.
то есть для работающей схемы нужен дефолтный маршрут + два маршрута с метками.
P.S. Это я про доступность роутера из-вне по разным интерфейсам.
sudoroot 08.03.16 в 08:12
0
А ведь и правда не работает балансировка исходящего траффика от самого микротика.
Господа, может кто нибудь нашел способ? Поделитесь!
Мне надо распределить по нескольким каналам несколько туннелей. Попробовал и EMCP, и PCC, счетчики растут но траффик бежит упорно через один интерфейс. Хотя если рассматривать таблицу прохождения пакетов iptables, то mangle output должен был поменять ему маршрут, далее route recheck.
- sudoroot 08.03.16 в 09:04
  0
  Похоже я сам тупой, проблема судя по всему в алгоритме хеширования, я использую в качестве туннелей l2tp, а они и порт источник и порт назначения используют 1701, поэтому для алгоритма все одно..
Alex013 26.11.16 в 17:57
0
Спасибо!
Настроил failover с двумя провайдерами. А как быть с их DNS? Как сделать, что бы для каждого провайдера использовался «его» DNS?
И ещё, если не сложно: следующим этапом планирую прикручивать OpenVPN-туннель. Внешний IP даёт только основной провайдера, его доступность >95%. Потеря туннеля при работе через резерв не беспокоит. Но не возникнет ли проблем с доступом в подсеть за туннелем, из-за предложенных «хитростей» в роутах?
- Helldar 28.11.16 в 03:17
  0
  А как насчет использования DNS того же Гугла?
  8.8.8.8 да 8.8.4.4
  - Alex013 28.11.16 в 10:04
    
    +1
    А как на счёт того, что не все провайдеры с этим соглашаются ;)?
    - Helldar 28.11.16 в 10:07
      
      0
      
      Резонно)
- AntiHelper 28.11.16 в 11:44
  0
  Попробуйте на самом роутере поднять роль DNS-сервера, а в качестве источников для него укажите все DNS-серверы обоих провайдеров. Это костыль, но работать будет. Для внутренних абонентов укажите DNS-сервер, который на роутере.
  Второй вариант — статические маршруты.
  - Alex013 28.11.16 в 15:03
    
    0
    До костыля с единым списком «всех DNS» я дотумкал самостоятельно, и как раз, понимая, что «это костыль» — хотел найти другое решение. Про «статические маршруты» — пока не осознал… Имеете ввиду прописать отдельно для LAN-WAN1 и LAN-WAN2?
    Кстати, а не честнее ли будет сделать failover на скриптах? Не нашёл сравнения преимуществ/недостатков этих двух решений.
    - AntiHelper 28.11.16 в 15:21
      
      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
      
      Файловер на скриптах — это попытка использования только одного провайдера в один момент времени. В случае полноценного использования двух каналов одновременно(а в случае падения одного из каналов использовать резервный) требуется подобное решение, которое описано в статье.
      Мне правда описанное в статье нравиться немного по другому делать, но этот способ тоже вполне жизнеспособен.
      - Alex013 28.11.16 в 15:31
        
        0
        
        Мысль со статикой уловил — спасибо.
        Моя задача — как раз организация резервного канала, т.к. нет никакого смысла складывать «100мбит» основного и «2мбит» резервного. Кроме того, мне нравится идея оповещения (e-mail, SMS или ещё как) о падении «основного» — так у меня раньше жил mwan3 под OpenWRT. Я правильно понимаю, что «оповещение» один фиг скриптами будет?
        
        AntiHelper 28.11.16 в 16:47
        
        0
        
        Оповещение — самая простая задача, которую можно организовать в любом случае.
        
        Лично у меня оповещения работают через нетвоч, который дёргает скрипты.
        
        Alex013 28.11.16 в 16:53
        
        0
        
        AntiHelper:
        у меня оповещения работают через нетвоч, который дёргает скрипты
        
        Так и я про то, что без скриптов оповещения не сделать. Может тогда имеет смысл всё на скриптах?
        
        AntiHelper 28.11.16 в 17:38
        
        0
        
        Решайте тем способом, который у Вас лучше всего получается.
Turilion 14.04.17 в 16:08
0
Маркировать СОЕДИНЕНИЯ в цепочке INPUT совершенно бесполезно.
/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
происходит это потому что цепочка input идёт уже после маршрутизации, а значит первый прилетевший пакет уже прошел маршрутизацию и открыл соединение без марки, и всё что происходит дальше в этом соединении так же не будет маркироваться.
Можете проверить сами, открыть Connection list и поссмотреть какая марка навешиваеться на соединения.
Правильно будет вот так:
/ip firewall mangle add action=mark-connection chain=prerouting in-interface=ISP1 new-connection-mark=cin_ISP1
passthrough=no