Cisco asa два провайдера

Read this article in English

Любой администратор когда-то обязательно сталкивался с выходом из строя канала связи, обеспечивающего офису доступ в Интернет или к другим ресурсам. Обычно в этот момент и возникает мысль о каком-то резерве (никак не раньше :-)). А вот при наличии двух провайдеров уже есть возможность настроить отказоустойчивое подключение.

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

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

В нашем распоряжении есть Cisco ASA 5505, обеспечивающая подключение офиса к сети Интернет через провайдера 1 (Ethernet 0/1). Подробное описание настройки можно найти в статье «Cisco ASA. Основы. Доступ в Интернет»
К устройству дополнительно подключен провайдер 2 в интерфейс Ethernet 0/2. (см. схему).

Задача: настроить отказоустойчивое подключение к Интернет (dual wan).

Шаг 1. Проверка маршрутов

Проверяем текущие маршруты на устройстве. Для удобства командой sh run | inc route выводим строки текущей конфигурации, содержащие слово «route»
FW-DELTACONFIG-1# sh run | inc route
route outside 0.0.0.0 0.0.0.0 1.1.1.1 1
Если переводить с языка устройства на «человеческий», то получится следующее:
«Перенаправлять все пакеты, о которых я не знаю, в сторону интерфейса outside через шлюз 1.1.1.1»
Cisco ASA «знает» только о тех сетях, которые подключены к ней напрямую (connected) или для которых имеются подобные строки маршрутов.

Шаг 2. Настройка интерфейсов для резервного провайдера

На межсетевом экране уже настроен интерфейс outside (Ethernet 0/1 Vlan 2), к которому подключен Основной провайдер. В текущей конфигурации (просмотреть командой sh run) будут присутствовать подобные строки:
FW-DELTACONFIG-1# sh run
/. вырезано. /
interface Vlan2
nameif outside
security-level 0
ip address 1.1.1.2 255.255.255.252
/. вырезано. /
interface Ethernet0/1
switchport access vlan 2
/. вырезано. /
Добавим настройки для Резервного канала, который подключен к Ethernet 0/2 Vlan 3
FW-DELTACONFIG-1 (config)#
interface Vlan 3
nameif outside_backup
security-level 0
ip address 2.2.2.2 255.255.255.252

interface Ethernet0/2
switchport access vlan 3
no shut
Если все подключено и настроено корректно, то должен быть доступен шлюз Резервного провайдера.
FW-DELTACONFIG-1 # ping 2.2.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.1, timeout is 2 seconds:
.
Success rate is 100 percent (5/5) , round-trip min/avg/max = 10/18/20 ms

Шаг 3. Настройка отслеживания доступности провайдера

Для того, чтобы межсетевой экран Cisco ASA следил за доступностью Основного канала настраиваем функцию ip sla monitor. С ней каждый заданный интервал времени будет посылаться ping (icmp запрос) на адрес провайдера 1. Ответный ping (icmp ответ) будет означать доступность канала.
FW-DELTACONFIG-1 (config)#
sla monitor 1
type echo protocol ipIcmpEcho 1.1.1.1 interface outside
timeout 3000
threshold 10000
frequency 5
sla monitor schedule 1 life forever start-time now

track 1 rtr 1 reachability

Для справки:
timeout 3000 – время, которое Cisco ASA будет ждать ответа на icmp запрос. 3000 => 3 секунды.
frequency 5 – как часто посылать запросы. Раз в 5 секунд.
threshold 10000 – время задержки операции 10 секунд, в течение которого не происходит никаких действий.

Шаг 4. Шлюз по умолчанию для Резервного провайдера.

Для Резервного провайдера по аналогии с Основным также требуется указать шлюз по умолчанию (default gateway), куда Cisco ASA будет отправлять все пакеты, но с одним отличием – этот маршрут не должен учитываться, когда доступен Основной провайдер. Для этого следует изменить административное расстояние маршрута – сделать его больше, тем самым понизив приоритет.
По умолчанию значение административного расстояния для статического маршрута – 1. Зададим для Резервного канала значение, близкое к максимальному – 250
FW-DELTACONFIG-1 (config)#
route outside_backup 0.0.0.0 0.0.0.0 2.2.2.1 250
После добавления в конфигурации должно быть 2 маршрута по умолчанию
FW-DELTACONFIG-1# sh run | inc route
route outside 0.0.0.0 0.0.0.0 1.1.1.1 1
route outside_backup 0.0.0.0 0.0.0.0 2.2.2.1 250

Шаг 5. Активация переключения

Финальный шаг – привязать основной маршрут к функции слежения за доступностью канала (ip sla).
Добавляем новую строку для шлюза по умолчанию с пометкой track 1 и удаляем старую
FW-DELTACONFIG-1 (config)#
route outside 0.0.0.0 0.0.0.0 1.1.1.1 1 track 1
no route outside 0.0.0.0 0.0.0.0 1.1.1.1 1
После этого в итоговой конфигурации останутся две строчки для шлюзов по умолчанию
FW-DELTACONFIG-1# sh run | inc route
route outside 0.0.0.0 0.0.0.0 1.1.1.1 1 track 1
route outside_backup 0.0.0.0 0.0.0.0 2.2.2.1 250

Важно!
Если существуют строки маршрутов для каких-то сетей, кроме шлюза по умолчанию, то следует учесть их при настройке.

Важно!
Кроме маршрутов необходимо скорректировать списки доступа (access-lists) и правила трансляций (NAT) для интерфейса Резервного провайдера. Добавьте идентичные правила и привяжите их к интерфейсу outside_backup.

Проверка работы механизма отслеживания

Для проверки работы отслеживания ip sla используется команда show sla monitor operational-state
FW-DELTACONFIG-1# show sla monitor operational-state
Entry number: 1
Modification time: 12:02:29.993 MSK Mon Aug 17 2015
Number of Octets Used by this Entry: 1480
Number of operations attempted: 39
Number of operations skipped: 0
Current seconds left in Life: Forever
Operational state of entry: Active
Last time this entry was reset: Never
Connection loss occurred: FALSE
Timeout occurred: FALSE
Over thresholds occurred: FALSE
Latest RTT (milliseconds): 10
Latest operation start time: 12:05:39.997 MSK Mon Aug 17 2015
Latest operation return code: OK
RTT Values:
RTTAvg: 10 RTTMin: 10 RTTMax: 10
NumOfRTT: 1 RTTSum: 10 RTTSum2: 100
Здесь собрана вся информация о статистике срабатывания и настройках функции. Информация будет полезна в случае необходимости диагностики.

Важно!

Не забудьте сохранить конфигурацию командой write или copy run start. Иначе после перезагрузки все изменения будут потеряны.
FW-DELTACONFIG-1# write
Building configuration.
[OK]

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

Итак, дано:
1. Cisco 2821;
2. Модуль HWIC-2FE;
3. Шнурок от одного прова (SPI1) ip: xxx.xxx.xxx.xx2 (шлюз: xxx.xxx.xxx.xx1);
4. Шнурок от второго прова (SPI2) ip: yyy.yyy.yyy.yy2 (шлюз: yyy.yyy.yyy.yy1);
5. Сеть предприятия, ip: 10.0.0.0 255.255.255.0.
Сразу хочу предупредить, что для дальнейших действий понадобиться IOS не ниже версии 12.4(15)T, по двум причинам: первая – это невозможность работать с IP Service Level Agreement, а вторая – это невозможность работать с HWIC-2FE, он просто не определяется циской. Я как раз под это и попал, пришлось извращаться, т.к., как оказалось, обновление IOS — процесс простой только с первого взгляда )) В общем собрав все, какие только можно, подводные камни, я всё же перешёл на нужную версию операционки. Потом, если соберусь, посвящу этому отдельную заметку )
Суть резервирования сводится к прописыванию двух маршрутов с разными метриками, и если нет необходимости в NATе, то всё вроде бы просто, но… мы не ищем лёгких путей ))) Шучу конечно же )) Просто в нашем случае NAT как раз-таки и нужен. Итак, чтобы иметь возможность задать две настройки для NAT, нужно использовать роут-мапы.

ip nat inside source route-map ISP1 interface GigabitEthernet0/1 overload
ip nat inside source route-map ISP2 interface FastEthernet0/2/0 overload

route-map ISP2 permit 10
match ip address 10
match interface FastEthernet0/2/0
!
route-map ISP1 permit 10
match ip address 10
match interface GigabitEthernet0/1

Так же следует настроить возможность отключения маршрута при его неисправности. Проверять валидность маршрута будем при помощи посылки icmp-пакетов на заведомо исправный узел, к примеру, yandex (87.250.251.3) и google (8.8.8.8). Алгоритм прост – через sla настраиваем мониторинг вышеуказанных узлов, создаём два маршрута через 2х разных провайдеров, настраиваем один как track 1, второй, соответственно как track 2, привязываем один трек к одному, sla, а второй ко второму.

ip route 0.0.0.0 0.0.0.0 xxx.xxx.xxx.xx2 3 name 1ISP track 1
ip route 0.0.0.0 0.0.0.0 yyy.yyy.yyy.yy2 100 name 2ISP track 2

ip sla 123
icmp-echo 87.250.251.3 source-interface GigabitEthernet0/1
frequency 10
ip sla schedule 123 life forever start-time now
ip sla 456
icmp-echo 8.8.8.8 source-interface FastEthernet0/2/0
frequency 10
ip sla schedule 456 life forever start-time now

track 1 ip sla 123
!
track 2 ip sla 456

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

ip route 8.8.8.8 255.255.255.255 yyy.yyy.yyy.yy1 name Google
ip route 87.250.251.3 255.255.255.255 xxx.xxx.xxx.xx1 name Yandex

Тут вроде всё. Теперь вернёмся снова к NATу. Чтобы, при падении маршрута, в таблице трансляции не подвисали трансляции, нужно их сбрасывать. Настроить это лучше всего по событию трекинга.

event manager applet natclear
event track 1 state any
action 0.9 cli command "enable"
action 1.0 cli command "clear ip nat translation *"
action 2.0 cli command "clear ip nat translation forced"

Всё работает на реальном железе, маршруты переключаются. Пока всех всё устраивает. Как следующий шаг развития в этом направлении буду смотреть в сторону BGP, но это уже не много другая история.
З.Ы.: Полный листинг конфига ниже.

Конфигурация

Пояснения по командам

Оба маршрута должны быть с одинаковой подсетью и маской. И должны резервный машрут должен быть с большей метрикой.

Эта команда включает проверку доступности адреса 192.0.2.254. Проверка заключается в отсылке 3 icmp запросов с timeout 5000, размером 100 байт (что дает размер пакета в 136 байт). Проверка раз в 60 секунд.

Проверка работы

Проверить настройки можно командами:

1. show running-config sla monitor — Покажет настройки sla в конфигурации

2. show sla monitor configuration — Отображает текущие настройки конфигурации

3. show sla monitor operational-state — Покажет текущее состояние SLA операций

Оцените статью
Много толка
Добавить комментарий