Cisco ASA Firewall - Сервисные работы с устройствами в Active\Standby Failover'е

   Рано или поздно созданный отказоустойчивый кластер (под кластером в данной статье понимается failover. Далее для краткости буду называть его просто кластер) приходится обслуживать. Например, требуется обновлять программное обеспечение, перезагружать устройства без потери связи или вовсе производить замену одного из члена кластера в следствие выхода его из строя.  Так же случаются человеческие или программные ошибки, в результате которых можно потерять конфиг, и, как следствие, - потерять все устройство.

   Для минимизации времени простоя из-за различного рода проблем ниже описаны сценарии восстановления работоспособности failover'a, а также последовательность действий для обновления софта на устройствах.
   Ниже представлено пошаговое руководство для решения простых сервисных задач.

Случай первый - Необходимо обновление софта

   Если необходимо обновить софт на кластере, то для этого потребуется:

   1) Проверить, какое количество последовательных обновлений может понадобиться. О чем вообще речь? Речь о том, что иногда для того, чтобы обновить софт с А на Б, может потребоваться обновиться сначала на В, а потом, возможно и на Г. В итоге путь обновлений до конечной версии будет выглядеть так: А--В--Г--Б. В противном случае можно поймать ошибку типа "No Cfg structure found...", как частично описано здесь.
   Перед началом обновления необходимо понять, сколько же шагов обновления необходимо выполнить. Для примера: в моей лабораторной используется версия софта 9.2.(2).4. Я хочу провести обновление до 9.6(1). Перед обновлением я нахожу на сайте Cisco документ Upgrade Guide для моей версии софта. Нахожу строки, подходящие для моих версий.

   В моем случае данную строку нужно читать так: Если у Вас версия софта 9.2(х), обновитесь до 9.2(2) и далее. Так как версия моего софта 9.2(2)4, значит, мне можно обновляться до 9.6(1) сразу без каких-либо промежуточных обновлений.
   2) Сделать бэкап конфига! Можно скопировать конфиг в блокнот, сохранить на рабочей станции администратора. Можно слить его по FTP, TFTP, SCP. Главное, чтобы конфиг сохранился!
   3) Для того, чтобы начать обновление, необходимо скопировать новый файл образа на диск каждой ASA в кластере. Аналогичным образом необходимо скопировать совместимые и обновленные образы ASDM. Копировать можно с FTP, TFTP или SCP, также можно скопировать с какого-либо USB-носителя.
   4) Начинать обновление необходимо с вторичного устройства. Для этого потребуется указать, какую версию ОС грузить при следующей перезагрузке, после чего перезагрузить устройство. Жесткое указание загружаемой версии требуется даже если на флешке вашего устройства имеется только один образ. Это спасет от случайной загрузки иного образа в случае его появления тем или иным способом на флеше устройства, ну и в принципе... дисциплинирует, что ли.
   Сначала на вторичной ASA прописываем путь к новому образу. Необходимо перед этим удалить старый. Для этого можно выполнить команду show run | inc boot или show bootvar. После этого удалить ссылку на старый образ и ASDM и вписать новый. Если не удалит ссылку на старый образ, то новая ссылка допишется в конец списка загрузки, и ваша новая операционная система загрузится только в случае, если первый образ будет поврежден или отсутствовать.
   В моем случае прописываю следующее:

 boot system disk0:/asa961-smp-k8.bin - загружать этот образ
 asdm image disk0:/asdm-761.bin - использовать данный образ ASDM

   Данные команды НЕ РЕПЛИЦИРУЮТСЯ. Их нужно выполнять на каждом устройстве в кластере.
   Перед перезагрузкой выполняю команду show bootvar, чтобы убедиться, что применены верные настройки:

BOOT variable = - текущее значение пустое, загружается образ, который будет найден первым на флеше
Current BOOT variable = disk0:/asa961-smp-k8.bin - означает, что при перезагрузке применится данное значение
CONFIG_FILE variable =
Current CONFIG_FILE variable =

   Обязательно выполняю команду write (в том числе на резервной ASA), т.к. без этого команда boot не применится. Перезагружаю резервную ASA и выполняю аналогичные действия на активном устройстве. После перезагрузки обоих устройств проверяю, что версии везде одинаковые.

Случай второй - Вышла из строя одна железка в паре

   Если в паре вышла одна из железок, то необходимо произвести замену. При этом новую железку лучше подготовить заранее: обновить софт до той версии, которая используется в кластере, обновить лицензию, открыв кейс в Cisco TAC. Последний пункт позволит перенести все функции, открываемые лицензиями, со старой (сгоревшей) ASA на новую. После этого в зависимости от того, вышла из строя активная или резервная ASA, выполняем следующие действия.

   A. Если сгорела вторичная, secondary ASA:

1. Включаем пришедшую на замену ASA, на которой мы уже обновили софт и мигрировали лицензии.
2. Выполняем минимальную конфигурацию для вторичной ASA (подробно описано тут). Сохранить конфигурацию, после чего выключить устройство.
3. Подключаем сначала все транспортные линки, а в самом конце - файловерные линки.
4. Включить устройство.
5. Дождаться репликации конфига, после чего зайти на резервную ASA и сохранить конфиг с помощью write.

   Б. Если сгорела первичная, primary ASA

1. Включаем пришедшую на замену ASA, на которой мы уже обновили софт и мигрировали лицензии.
2. Выполняем минимальную конфигурацию для первичной ASA (подробно описано тут). Сохранить конфигурацию, после чего выключить устройство.
3. Подключаем сначала все транспортные линки, а в самом конце - файловерные линки.
4. Включить устройство.
5. Дождаться репликации конфига, после чего зайти на основную ASA и сохранить конфиг с помощью write.
6. Для переключения работы на первичную ASA на ней выполнить команду failover active.  

Случай третий - Есть конфиг и новый failover

     

   В этом случае достаточно влить конфиг на активную ASA. Можно просто скопировать конфиг из блокнота, или же пойти сложным путем и скопировать файл с конфигом на диск ASA-primary, после чего загрузить конфигурацию с помощью copy в running-config, а после сохранить в startup-config.

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

Случай четвертый - Что-то пошло не так, и текущий конфиг на активной ASA был испорчен 

   

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