Ремонт портал 128 бит

Резервирование каналов на Mikrotik , Настройка Mikrotik

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

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

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

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