Сетевые решения — SLA

Service License Agreement (SLA) — сервис качества обслуживания. В оборудовании Cisco это скорее функция, которая обеспечивает данное качество. В данной заметке будет рассмотрен лишь один аспект SLA — настройка автоматического переключения на резервный канал связи и обратно.

Наши реалии таковы, что для доступа к данной функции на новых маршрутизаторах Cisco вы должны приобрести лицензию Data License, которая активирует SLA. На старых моделях маршрутизаторов, если я не ошибаюсь, данный функционал входит в базовый IOS.

1. Настройка SLA для автоматического переключения между двумя провайдерами

Первое, что нужно сделать, это добиться стабильного подключения к двум или нескольким провайдерам. Как это сделать описано в статье Подключение двух интернет провайдеров к маршрутизатору Cisco.

Затем нужно решить доступность какого IP адреса будем отслеживать. Это может быть как шлюз провайдера, так и любой адрес в интернете. У каждого способа есть свои преимущества и недостатки.

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

Задержка/джиттер до IP адреса в сети Интернет нестабильна. Поэтому отслеживать его доступность сложнее, но зато здесь мы будем более автономны и не будем зависеть от провайдера. Не важно, если что-то случится с его магистральным провайдером, оборвется кабель или сгорит оборудование, в тот момент как перестанет быть доступным отслеживаемый адрес, будет осуществлен автоматический переход на резервный канал связи.

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

track 111 ip sla 1 reachability

track 222 ip sla 2 reachability

ip sla 1
 icmp-echo 4.2.2.2 source-interface GigabitEthernet0/0.833
 timeout 2000
 threshold 40
 frequency 15

ip sla schedule 1 life forever start-time now

ip sla 2
 icmp-echo 22.222.222.41 source-interface GigabitEthernet0/0.832
 timeout 2000
 threshold 40
 frequency 15

ip sla schedule 2 life forever start-time now

ip route 0.0.0.0 0.0.0.0 11.111.111.65 track 111
ip route 0.0.0.0 0.0.0.0 22.222.222.41 100 track 222
ip route 4.2.2.2 255.255.255.255 11.111.111.65

В старом IOS вместо команды track 111 ip sla 1 reachability, нужно использовать track 111 rtr 1 reachability.

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

event manager applet track-111-switch
 event track 111 state any
 action 1.0 cli command "enable"
 action 2.0 cli command "clear ip nat trans forced"
event manager applet track-222-switch
 event track 222 state any
 action 1.0 cli command "enable"
 action 2.0 cli command "clear ip nat trans forced"

2. Настройка SLA с применением Route-map

Прежде чем приступать к более гибкой настройке с применением карт маршрутизации, прочтите статью Route-map / PBR.

Данная конфигурация взята из сети Интернет без предварительной редакции:

ip sla monitor 40
type echo protocol ipIcmpEcho 62.244.27.QQQ source-interface FastEthernet0/1.40
timeout 2000
frequency 3
ip sla monitor schedule 40 life forever start-time now
ip sla monitor 50
type echo protocol ipIcmpEcho 95.67.64.PPP source-interface FastEthernet0/1.50
timeout 2000
frequency 3
ip sla monitor schedule 50 life forever start-time now

track 40 rtr 40 reachability
!
track 50 rtr 50 reachability

ip route 0.0.0.0 0.0.0.0 62.244.27.QQQ track 40
ip route 0.0.0.0 0.0.0.0 95.67.64.PPP track 50

access-list 10 permit 192.168.0.0 0.0.0.255
access-list 20 permit 192.168.20.0 0.0.0.255
access-list 30 permit 192.168.30.0 0.0.0.255
!
route-map Kosmonova_user permit 20
match ip address 20
set ip next-hop verify-availability 95.67.64.PPP 1 track 50
set ip next-hop verify-availability 62.244.27.QQQ 2 track 40
!
route-map LuckyNet permit 30
match ip address 30
set ip next-hop verify-availability 62.244.27.QQQ 1 track 40
set ip next-hop verify-availability 95.67.64.PPP 2 track 50
!
route-map Kosmonova_BUH permit 10
match ip address 10
set ip next-hop verify-availability 95.67.64.PPP 1 track 50
set ip next-hop verify-availability 62.244.27.QQQ 2 track 40

interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface FastEthernet0/0.10
description BUH
encapsulation dot1Q 10
ip address 192.168.0.1 255.255.255.0
ip nat inside
ip virtual-reassembly
ip policy route-map Kosmonova_BUH
no snmp trap link-status
!
interface FastEthernet0/0.20
description USER
encapsulation dot1Q 20
ip address 192.168.20.1 255.255.255.0
ip nat inside
ip virtual-reassembly
ip policy route-map Kosmonova_user
no snmp trap link-status
!
interface FastEthernet0/0.30
description VIP
encapsulation dot1Q 30
ip address 192.168.30.1 255.255.255.0
ip nat inside
ip virtual-reassembly
ip policy route-map LuckyNet
no snmp trap link-status
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
!
interface FastEthernet0/1.40
description INET_1_LuckyNET
encapsulation dot1Q 40
ip address 62.244.27.qqq 255.255.255.252
ip nat outside
ip virtual-reassembly
no snmp trap link-status
!
interface FastEthernet0/1.50
description INET_2_Kosmonova
encapsulation dot1Q 50
ip address 95.67.64.ppp 255.255.255.252
ip nat outside
ip virtual-reassembly
no snmp trap link-status

3. Настройка SLA на межсетевом экране Cisco ASA

По этой теме я как раз нашел статью в сети Интернет. Автора статьи зовут Неупокоев Александр и впервые она была опубликована на его сайте admindoc.ru.

Условия:

Есть два канала в интернет.

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

Конфигурационный файл имеет вид:

!
interface GigabitEthernet0/0
nameif inside
security-level 100
ip address 10.0.0.1 255.255.255.0
!
interface GigabitEthernet0/1
nameif outside
security-level 0
ip address xx.xx.XX.XX2 255.255.255.252
!
interface GigabitEthernet0/2
shutdown
nameif outside_adsl
security-level 0
ip address yy.yy.yy.yy.2 255.255.255.252

Будем считать, что на одном интерфейсе, смотрящего в сторону провайдера у нас всё настроено, интернет работает, NAT поднят. Для обеспечения переключения в случае когда по оптическому линку вдруг перестают ходить пакеты нужно настроить механизм SLA.

Как это работает? Очень просто, мы указываем чтоб по основному интерфейсу до определённого хоста (обычно шлюз провайдерский, либо шлюз аплинкера прова) каждый некоторый интервал производились отправки icmp echo request. Если ответ echo reply приходит, то всё хорошо, если всё плохо, то переключаемся на дополнительный канал, в нашем случае ADSL.

Как это настраивается в Cisco ASA 55xx.

ciscoasa# conf t
ciscoasa(config)# sla monitor 1
ciscoasa(config-sla-monitor)#type echo protocol ipIcmpEcho xx.xx.xx.xx1 interface outside
ciscoasa(config-sla-monitor-echo)#num-packets 3
ciscoasa(config-sla-monitor-echo)#frequency 10

Первой командой мы указали, что номер SLA конфигурации 1-ый, и тем самым зашли в режим конфигурации SLA. Дальше мы определяем тип мониторинга, указываем протокол и IP адрес узла, который будем проверять на «живучесть», и соответсвенно интерфейс, через который всё это будет делаться.

Следующей командой мы указываем сколько пакетов в сторону хоста будет направлено, frequency указывает на то, как часто мы будем посылать echo request хосту, в нашем случае каждые 10 секунд.

Так же можно указать порог ответа (echo reply), до которого будет считаться что всё впорядке, если свыше переходить соответсвенно на запасной канал. Делается это с помощью treshold в режиме config-sla-monitor-echo. Так же можно выставить время timeout для conn, h323, sip и так далее.

Для нас данных настроек достаточно, доп.информацию всегда можно почерпнуть на cisco.com, ссылки приведу ниже.

ciscoasa(config)#sla monitor schedule 1 life forever start-time now

Здесь мы указываем когда запускать данный мониторинг и его время жизни. В данном случае мониторинг запущен всегда, т.е. всегда проверяется «живучесть нашего хоста».

Далее нам необходимо прописать трэк, который будет привязан к нашему основному каналу:

ciscoasa(config)# track 1 rtr 1 reachability

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

route outside 0.0.0.0 0.0.0.0 xx.xx.xx.xx1 1 track 1
route outside_adsl 0.0.0.0 0.0.0.0 yy.yy.yy.yy1 254

Настройка SLA закончена.

Теперь можно проверить, что у нас сейчас в таблице маршрутизации:

ciscoasa# sh route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 83.69.71.205 to network 0.0.0.0

C xx.xx.xx.xx 255.255.255.252 is directly connected, outside
C yy.yy.yy.0 255.255.255.0 is directly connected, outside_adsl
C 127.0.0.0 255.255.0.0 is directly connected, cplane
C 10.10.10.0 255.255.255.0 is directly connected, management
C 10.0.0.0 255.255.255.0 is directly connected, inside
S* 0.0.0.0 0.0.0.0 [1/0] via xx.xx.xx.xx1, outside
ciscoasa#

Видим, что интернет работает через основного провайдера, т.е. через интерфейс outside, о чем говорит нам последняя строка sh route.

После отключения интерфейса outside (просто выдергиваем сетевой шнур), через несколько секунд заглянем в тот же sh route:

ciscoasa# sh route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 83.69.71.205 to network 0.0.0.0

C xx.xx.xx.xx 255.255.255.252 is directly connected, outside
C yy.yy.yy.0 255.255.255.0 is directly connected, outside_adsl
C 127.0.0.0 255.255.0.0 is directly connected, cplane
C 10.10.10.0 255.255.255.0 is directly connected, management
C 10.0.0.0 255.255.255.0 is directly connected, inside
S* 0.0.0.0 0.0.0.0 [1/0] via yy.yy.yy.yy1, outside_adsl
ciscoasa#

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

Для того, чтоб посмотреть как ходят пакетики и проверяют живучесть, можно использовать debug:

ciscoasa# debug sla monitor trace

И соответсвенно для просмотра ошибок:

ciscoasa# debug sla monitor error

Понравилась статья? Поделиться с друзьями:
TelecomBook
Яндекс.Метрика