Enable lan failover что это

Обновлено: 03.07.2024

Шпаргалки и заметки о сетевых технологиях, серверах, СХД, IT в принципе. И о разном другом) Чтоб самому не забывать, и другим помочь.

суббота, 17 сентября 2016 г.

Cisco ASA Firewall - Failover configuration / Межсетевой экран Cisco ASA - Настраиваем файловер - Часть 1: Теория. Настройка Active\Standby

Межсетевые экраны Cisco ASA поддерживают такую удобную штуку как FAILOVER, что можно перевести "отказоустойчивый [кластер]". Не следует путать с кластеризацией ASA- это немного другое.

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

Ниже расскажу подробнее про теоретическую часть файловера и приведу пример настройки (которая, кстати, весьма тривиальна).

Теория

Прежде всего следует сказать, что в файловер можно собирать только абсолютно одинаковые устройства в плане железной части. При этом должно совпадать количество оперативной памяти, количество интерфейсов Если установлены какие-либо физические модули, то они тоже должны быть одинаковыми. Что касается софта, то должны совпадать версии операционной системы (как минимум мажорное и минорное значение версии, но лучше всего, чтобы версии ОС были полностью идентичны), версии ASDM (вообще такого требования нет, но лучше, чтобы совпадали просто потому, что нет смысла держать разные версии ASDM). Софт на модулях SSM или иных тоже должен совпадать. В общем, полностью одинаковые устройства, разве что количество флеш-памяти может различаться.
Для создания файловера придется на каждом устройстве выделить линк, а лучше два, которые можно будет объединить в Redundant-интерфейс. Этот линк не будет использоваться для передачи трафика, а будет загружен исключительно файловерными данными, а именно:
- состояние соседнего устройства (активное или резервное);
- Состояние питания;

Все эти данные передаются по файловерному линку в открытом виде, если не добавить команду, позволяющую зашифровать трафик. Рекомендую по умолчанию всегда использовать шифрование на файловерном линке. Лишним не будет.
Что касается подключения линка, то можно включаться напрямую друг к другу интерфейс в интерфейс (желательно кроссовером, но у нас же повсюду теперь auto-MDI\MDIX, поэтому можно не заморачиваться). А кроме того документация говорит, что можно файловерный линк прокинуть через коммутатор, и даже не один. Такую вещь не пробовал, надо будет в будущем потестить.
Отдельного внимания заслуживает так называемый StateFull-линк. Суть в том, что можно гонять по файловерному линку не только перечень указанных выше состояний и кусков служебной информации, но и вообще все-все, чтобы полное состояние иметь на обоих межсетевых экранах. Т.е. в этом случае будут передаваться таблицы NAT-трансляций, различные прочие таблицы, в общем полное дублирование устройств.
Что еще интересного можно сказать про файловер. В принципе перечисленное выше - это основное, что нужно знать. Да! Важно учесть, что файловер накладывает некоторые ограничения на использование VPN. Но это касается только режима Active/Active. При включении этого режима не будут поддерживаться SSL\IPSec VPN, не работает динамическая маршрутизация.
Следует дополнить эту краткую теоретическую справку пометкой о том, что не все команды синхронизируются.
Ниже перечислены причины, по которым может произойти переключение файловера:
- аппаратная проблема на одной из ASA в паре. Соответственно, если режим Active\Standby, и произошло все на резервной, то ничего не произойдет. Если же на активной, то произойдет переключение на резервную;
- какой-либо программный сбой;
- слишком много интерфейсов, за которыми ведется мониторинг, стали недоступными, отвалились, в общем, возникли проблемы со связью. Кстати, как это трактовать - слишком много интерфейсов (фраза взята из мануала) - непонятно. 2 из 4 интерфейсов упало - это много или мало? Непонятно;

- на активной асашке выполнили команду no failover active, либо на резервной выполнили команду failover active. В общем, переключили файловер вручную.

Практика

Сбор Active/Standby файловера

После ввода этой группы команд каждая ASA секунд этак на 15 будет недоступна, отвалится консоль, будет казаться, что устройство зависло. Но нет, не стоит пугаться, нужно терпеливо подождать.
Фактически вся настройка уже завершена. Осталось только указать асашкам их роль в паре.
На ASA-1 я указываю команду:
!
failover lan unit primary
!
А на ASA-2 соответственно:
!
failover lan unit secondary
!
Не забываю сохранить конфигурацию. Файловер заработал, в чем я могу убедиться с помощью команды show failover state, выполненной на любой из ASA.


Попробуем доработать нашу схему. Во-первых, сделаем StateFull failover. Во-вторых, зашифруем передаваемый трафик, чтобы враги ничего не поняли, если вдруг подключатся. Набор команд, который позволит выполнить эти два условия:
!
failover link FAILOVER Redundant1 //включаем режим сохранения состояния, он же statefull
!
failover key WerYStr0ngKey // указываем ключ для шифрования данных, протекающих через наш файловерный линк

Когда две ASA настроены для работы в режиме Active/Active failover, нельзя включить IPsec VPN или SSL VPN. Так же не доступна динамическая маршрутизация. VPN failover доступен только для режима работы Active/Standby.

1. Stateful failover - с сохранением текущего состояния: обе ASA обмениваются информацией о состоянии сеансов по выделенному линку (Statefull Failover Link), и если какая-либо из ASA выйдет из строя, то другая подхватит существующие сеансы и продолжит работу.

2. Stateless failover - когда при отказе основной все сеансы связи сбрасываются; активируется резервная ASA, соединения для всех сеансов устанавливаются заново (использует Failover Link).

Любой Ethernet-интерфейс может использоваться в качестве failover-интерфейса, однако нельзя указывать интерфейс, на котором уже задано имя интерфейса.

Failover-интерфейс не настраивается как обычный интерфейс для передачи данных, он существует только для коммуникаций связанных с failover (он может использоваться в качестве stateful failover link).

Для того чтобы использовать возможности Stateful Failover, надо настроить stateful failover link для передачи информации о состоянии соединений.

Возможны такие варианты выбора stateful failover link:

  • Выделенный интерфейс
  • Общий интерфейс с failover link
  • Общий интерфейс с обычным интерфейсом для передачи данных. Однако, эту опцию не рекомендуется использовать. Кроме того, она поддерживается только в single context, routed mode.

Команды, которые синхронизируются на standby unit:

  • все команды конфигурационного режима, кроме команд mode, firewall и failover lan unit
  • copy running-config startup-config
  • delete
  • mkdir
  • rename
  • rmdir
  • write memory

Команды, которые не синхронизируются на standby unit:

  • Все формы команды copy, кроме copy running-config startup-config
  • Все формы команды write, кроме write memory
  • crypto ca server и соответствующие подкоманды
  • debug
  • failover lan unit
  • firewall
  • mode
  • show
  • Модули должны быть настроены отдельно на обоих ASA. При настройке failover, конфигурация модулей не передается.
  • AIP-SSM Things like signature config, virtual sensor setup, filters, and overrides should all be similar, if not exactly the same. This helps to ensure that their behavior is the same.

ASA должны быть с одинаковыми моделями модулей.

Если ASA работает в режиме routed, то надо настроить standby-адреса на интерфейсах ASA (active-адрес и standby-адрес должны быть из одной сети):

Если ASA работает в режиме transparent, то надо настроить standby-адрес для управляющего интерфейса (active-адрес и standby-адрес должны быть из одной сети):

Указать, что эта ASA выполняет роль primary unit:

Указать какой интерфейс будет использоваться для failover:

Например, интерфейс g 0/2 будет выполнять роль failover-интерфейса и будет называться failover:

Назначить active и standby IP-адреса на failover-интерфейс:

Включить интерфейс, который будет выполнять роль failover-интерфейса:

Если необходимо использовать stateful failover, то, кроме предыдущих настроек, необходимо настроить stateful failover-интерфейс.

Указать какой интерфейс будет использоваться в качестве stateful failover-интерфейса:

Если, например, в качестве stateful failover-интерфейса будет использоваться failover-интерфейс, то достаточно указать имя интерфейса:

Удалить существующую конфигурацию

Указать какой интерфейс будет использоваться для failover:

Например, интерфейс g 0/2 будет выполнять роль failover-интерфейса и будет называться failover:

Назначить active и standby IP-адреса на failover-интерфейс (команда должна в точности повторять команду введенную на primary ASA):


Небольшая шпаргалка по настройке Cisco ASA Failover в режиме Active/Standby failover с версией 9.x.

Какие варианты существуют?

Существует два типа работы Failover:

Active/Active failover — где трафик обрабатывается двумя устройствами. Данный метод не является средством увеличения производительности устройств и используется для балансировки нагрузки. При данном типе работы нельзя использовать IPsec VPN, SSL VPN и динамическую маршрутизацию.

Active/Standby failover — где трафик обрабатывается первым (активным) устройством, а второе находится в режиме ожидания и принимает нагрузку только в случае отказа первого. В данном типе работы доступно VPN failover.

Так как мы рассматриваем настройку Active/Standby failover то углубимся в данный тип работы.

В Active/Standby failover есть два режима работы :

Stateful failover — где обе ASA обмениваются информацией о состоянии сеансов по выделенному линку (Statefull Failover Link) и если какая-либо из ASA выйдет из строя, то другая подхватит существующие сеансы и продолжит работу.

Stateless failover — где при отказе основной (Active) все сеансы связи сбрасываются; активируется резервная (Standby) ASA, соединения для всех сеансов устанавливаются заново.

Перед тем как начать следует убедиться в следующем:
1. Обе ASA должны быть полностью одинаковыми во всем (модель, тип установленных модулей, количество ОЗУ и т.д.);
2. Обе ASA должны иметь одинаковый IOS;
3. Обе ASA должны иметь одинаковый загруженный образ AnyConnect (если таковой имеется или используется) и одинаковый файл профиля AnyConnect (если нет то копировать эти файлы вручную);
4. Обе ASA должны быть одинаково соединены с одними и теми же устройствами.

Что реплицируется и что нет?

Так же следует учесть что после настройки не все команды или файлы реплицируются межу Active и Stanby ASA.

Не реплицируются такие файлы как:

Файлы образ и профиль AnyConnect;

Образ Cisco Secure Desktop (CSD);

Не реплицируются следующие команды:

Команда Copy (исключение copy running-config startup-config );

Команда Write (исключение write memory );

Команда Debug и все ее составляющие;

Команда Failover lan unit и все ее составляющие;

Команда Firewall и все ее составляющие;

Команда Terminal pager и pager .

По поводу лицензий на устрйоство.

Начиная с версии 8.3(1) достаточно лицензии только для Active устройства.

Настройка устройств.

Обе ASA никак не подключены друг к другу.

Настройка ASA-01

Первым делом необходимо выбрать интерфейс для Statefull Failover Link по которому ASA будут обмениваться состояниями.

На обоих ASA интерфейс должны быть одним и тем же.

Настройка Statefull Failover Link.

interface GigabitEthernet0/1
description STATE-REPLICATION Failover Interface
no nameif
no security-level
no ip address
no shutdown

Включаем режим failover на ASA-01

failover
failover lan unit primary
failover lan interface STATE-REPLICATION GigabitEthernet0/1
failover polltime unit 1 holdtime 3
failover link STATE-REPLICATION GigabitEthernet0/1
failover interface ip STATE-REPLICATION 172.16.0.1 255.255.255.252 standby 172.16.0.2
wri

Настройка ASA-02

Настройка Statefull Failover Link.

interface GigabitEthernet0/1
description STATE-REPLICATION Failover Interface
no nameif
no security-level
no ip address
no shutdown

Включаем режим failover на ASA-02

failover
failover lan unit secondary
failover lan interface STATE-REPLICATION GigabitEthernet0/1
failover polltime unit 1 holdtime 3
failover link STATE-REPLICATION GigabitEthernet0/1
failover interface ip STATE-REPLICATION 172.16.0.1 255.255.255.252 standby 172.16.0.2
wri

После этого выключаем ASA-02, соединяем между собой интерфейсы GigabitEthernet0/1 обеих ASA и включаем ASA-02.

После загрузки ASA-02 появится следующее:

Detected an Active mate
Beginning configuration replication from mate.

Если существуют какие-то недочеты и ошибки то они будут выведены в консоль.

Проверку работоспособности Failover проверяем командой sh failover на ASA-01 и получаем вывод:

Failover On
Failover unit Primary
Failover LAN Interface: STATE-REPLICATION GigabitEthernet0/1 (up)
Unit Poll frequency 1 seconds, holdtime 3 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Version: Ours 9.1(7)12, Mate 9.1(7)12
Last Failover at: 08:52:25 MSK/MSD Jul 21 2018
This host: Primary - Active
Active time: 2709783 (sec)
slot 0: ASA5550 hw/sw rev (2.0/9.1(7)12) status (Up Sys)
slot 1: ASA-SSM-4GE-INC hw/sw rev (1.0/1.0(0)10) status (Up)
Other host: Secondary - Standby Ready
Active time: 0 (sec)
slot 0: ASA5550 hw/sw rev (2.0/9.1(7)12) status (Up Sys)
slot 1: ASA-SSM-4GE-INC hw/sw rev (1.0/1.0(0)10) status (Up)

Где Other host: Secondary - Standby Ready говорит о том, что failover работает нормально.

Если хотим доступность ASA Standby в сети.

Если вам необходима доступность Standby ASA в сети то выполните на Active ASA, на нужном вам интерфейсе следующее:

int НОМЕР ИНТЕРФЕЙСА
ip address IP-АДРЕС МАСКА standby IP-АДРЕС

Что делать если у вас подключен провайдре к одной из ASA?

Если к одной из ASA подключен провайдер и вы не знаете как подключить его к второй ASA то поставьте в разрез обычный коммутатор или соберите виртуальный коммутатор на управляемом коммутаторе, умеющим использовать VLAN - просто выделите 3 порта в VLAN не использующийся в конфигурациях оборудования и подключите в них обе ASA и вашего провайдера.

Команды Show, которые помогут.

Show conn count
Show failover
Show failover exec
Show failover exec mate
Show failover group
Show monitor-interface
Show running-config failover

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

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

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

Failover

image

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

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

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

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

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

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

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

конфигурация: failover с более глубоким анализом канала

Теперь разберем, что происходит чуть подробнее:
Хитрость в том, что шлюз провайдера не знает о том, что 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 адресами

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

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

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

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

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

конфигурация с балансировкой канала по жестко прописанным правилам

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

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

конфигурация с балансировкой канала по Н-ному соединению:

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

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

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

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

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

Читайте также: