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
