Про виртуальные сети (часть 15). IP SLA в виртуальных сетях.

Если заглянуть на сайт cisco.com, то там можно найти документ, в котором есть следующее описание (прошу меня извинить за мой перевод, сделанный по японской технологии касавато):

IP SLA собирает информацию о производительности сети в реальном времени: время ответа, задержки, потери пакетов, измерение качества передачи голоса и пр. Пользователь имеет возможность надежно и предсказуемо производить измерения сетевой производительности продолжительное время, а также активно контролировать доступность сети. Cisco IOS IP SLA позволяет автоматизировать наблюдение за сетью, обеспечить гарантированный уровень обслуживания, активно контролировать сетевые операции и точно измерять сетевую производительность. Система активного мониторинга продолжительное время измеряет производительность сети по многочисленным маршрутам, непрерывно обеспечивая основную информацию о производительности.
Сетевой администратор может также использовать Cisco IOS IP SLA как инструмент для поиска неисправности. Он может получать статистику производительности от узла к узлу, между двумя маршрутизаторами Cisco или между маршрутизатором и сервером. Если сетевая производительности резко падает в процессе работы (перегрузка сети), сетевой администратор может точно определить узкое место и решить проблему. Cisco IOS IP SLA может также оценить уровень качества обслуживания для вновь внедряемого сервиса. Например, Cisco IOS IP SLA может определить, способна ли сеть обеспечить передачу голоса, смоделировав нагрузку и произведя измерение сетевой производительности для VoIP.

Если перевести все это, а также прочую часть документа на человеческий язык, то IP SLA предназначен для контроля доступности какого-либо узла, возможности доступа по сети к конкретному сокету, а также качества канала до узла. Кроме того есть возможность контроля доступности и производительности некоторых сервисов (DNS, FTP, HTTP, DHCP) . В результате контроля состояний и производительности сетевых сервисов формируются флаги (триггеры, датчики), которые сигнализируют, соответствуют ли контролируемые сервисы заданным параметрам качества. И уже на основе этих флагов могут быть запланированы какие-либо действия: от записи в логе до изменения конфигурации маршрутизатизатора.

В этой статье я приведу пример, как можно выбирать виртуальную сеть, основываясь на данных о доступности каждой конкретной виртуальной сети. Итак, приступим.

За основу я возьму сеть, которая использовалась для изучения маршрутизации на основе политик (Cisco PBR) вот здесь.

Phys_net

Рис. 1 Физическая топология сети

Log_net

Рис. 2 Логическая топология сети

У нас уже имеется две виртуальные подсети FTP и SSH. В этой конфигурации надежность обеспечивалась использованием EIGRP . Однако EIGRP может обеспечить надежность в случае, если отказали промежуточные узлы виртуальной сети. Но что если отказывают оконечные? В этом случае хорошо бы иметь возможность перенаправить трафик в другую виртуальную сеть.

Прежде всего нужно определить критерий, по которому мы будем определять доступность конечного узла. Здесь нужно сделать небольшое уточнение: из всех вариантов настройки IP SLA для виртуальных сетей доступен контроль только на основе протокола icmp. Так что, как в той рекламе, при всем богатстве выбора, другой альтернативы нет. Будем контролировать по icmp какой-нибудь интерфейс конечного узла.
Обычно для подобных вещей рекомендуется использовать Loopback интерфейсы, которые остаются активны до тех пор, пока работает IOS. И несмотря на то, что интерфейсы у виртуального маршрутизатора тоже виртуальные, я не буду нарушать это правило и тоже воспользуюсь Loopback.
Итак, создаем Loopback интерфейсы, назначаем их виртуальным маршрутизаторам и присваиваем IP-адреса.

Client_Side#conf t
Client_Side(config)#int lo1
Client_Side(config-if)#ip vrf forwarding FTP_Cl_Sd
Client_Side(config-if)#ip address 10.0.1.1 255.255.255.128
Client_Side(config)#int lo2
Client_Side(config-if)#ip vrf forwarding SSH_Cl_Sd
Client_Side(config-if)#ip address 10.0.2.1 255.255.255.128

Server_Side#conf t
Server_Side(config)#int lo1
Server_Side(config-if)#ip vrf forwarding FTP_Cl_Sd
Server_Side(config-if)#ip address 10.0.1.129 255.255.255.128
Server_Side(config)#int lo2
Server_Side(config-if)#ip vrf forwarding SSH_Cl_Sd
Server_Side(config-if)#ip address 10.0.2.129 255.255.255.128

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

Client_Side#sh ip route vrf FTP_Cl_Sd
Routing Table: FTP_Cl_Sd
Gateway of last resort is not set
C 192.168.55.0/24 is directly connected, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C 10.2.0.0/24 is directly connected, FastEthernet1/0.20
D 10.3.0.0/24 [90/30720] via 10.1.0.1, 00:11:08, FastEthernet1/0.10
C 10.1.0.0/24 is directly connected, FastEthernet1/0.10
C 10.0.1.0/25 is directly connected, Loopback1
D 10.4.0.0/24 [90/2565120] via 10.2.0.1, 00:11:08, FastEthernet1/0.20
D EX 10.0.1.128/25 [170/158720] via 10.1.0.1, 00:11:09, FastEthernet1/0.10
D EX 192.168.18.0/24 [170/33280] via 10.1.0.1, 00:11:09, FastEthernet1/0.10

Аналогично проверяем остальные маршрутизаторы:


Client_Side#sh ip route vrf SSH_Cl_Sd
Routing Table: SSH_Cl_Sd
Gateway of last resort is not set
C 192.168.55.0/24 is directly connected, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D 10.3.1.0/24 [90/2565120] via 10.1.1.1, 00:13:02, FastEthernet1/0.11
C 10.0.2.0/25 is directly connected, Loopback2
C 10.2.1.0/24 is directly connected, FastEthernet1/0.21
C 10.1.1.0/24 is directly connected, FastEthernet1/0.11
D 10.4.1.0/24 [90/30720] via 10.2.1.1, 00:13:02, FastEthernet1/0.21
D EX 10.0.2.128/25 [170/158720] via 10.2.1.1, 00:13:04, FastEthernet1/0.21
D EX 192.168.18.0/24 [170/33280] via 10.2.1.1, 00:13:04, FastEthernet1/0.21

Server_Side#sh ip route vrf FTP_Srv_Sd
Routing Table: FTP_Srv_Sd
Gateway of last resort is not set
D EX 192.168.55.0/24 [170/33280] via 10.3.0.1, 00:14:56, FastEthernet1/0.30
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D 10.2.0.0/24 [90/2565120] via 10.4.0.1, 00:14:57, FastEthernet1/0.40
C 10.3.0.0/24 is directly connected, FastEthernet1/0.30
D 10.1.0.0/24 [90/30720] via 10.3.0.1, 00:14:56, FastEthernet1/0.30
D EX 10.0.1.0/25 [170/158720] via 10.3.0.1, 00:14:56, FastEthernet1/0.30
C 10.4.0.0/24 is directly connected, FastEthernet1/0.40
C 10.0.1.128/25 is directly connected, Loopback1
C 192.168.18.0/24 is directly connected, FastEthernet0/0

Server_Side#sh ip route vrf SSH_Srv_Sd
Routing Table: SSH_Srv_Sd
Gateway of last resort is not set
D EX 192.168.55.0/24 [170/33280] via 10.4.1.1, 00:15:47, FastEthernet1/0.41
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C 10.3.1.0/24 is directly connected, FastEthernet1/0.31
D EX 10.0.2.0/25 [170/158720] via 10.4.1.1, 00:15:47, FastEthernet1/0.41
D 10.2.1.0/24 [90/30720] via 10.4.1.1, 00:15:47, FastEthernet1/0.41
D 10.1.1.0/24 [90/2565120] via 10.3.1.1, 00:15:47, FastEthernet1/0.31
C 10.4.1.0/24 is directly connected, FastEthernet1/0.41
C 10.0.2.128/25 is directly connected, Loopback2
C 192.168.18.0/24 is directly connected, FastEthernet0/0

Теперь можно приступить к конфигурированию самих мониторов. Оно состоит из двух этапов: создание самого монитора и трекера, который будет отслеживать его состояние.

Создаем монитор:

Client_Side#conf t
Client_Side(config)#ip sla monitor 1
Client_Side(config-sla-monitor)#type echo protocol ipIcmpEcho 10.0.1.129

Назначаем виртуальный маршрутизатор, на котором этот монитор будет работать:

Client_Side(config-sla-monitor-echo)#vrf FTP_Cl_Sd

И назначаем время работы монитора:

Client_Side(config-sla-monitor-echo)#ip sla monitor schedule 1 start-time now life forever

Теперь мы можем посмотреть статистику работы монитора:

Client_Side(config)#do sh ip sla monitor statistics
Round trip time (RTT) Index 1
Latest RTT: 68 ms
Latest operation start time: *00:10:56.199 UTC Fri Mar 1 2002
Latest operation return code: OK
Number of successes: 6
Number of failures: 0
Operation time to live: Forever

Все в порядке. Теперь нужно создать трекер, который будет выступать посредником между монитором и IOS.

Client_Side(config)#track 1 rtr 1 reachability

Его состояние тоже можно проверить.

Client_Side#sh track
Track 1
Response Time Reporter 1 reachability
Reachability is Up
4 changes, last change 00:17:07
Latest operation return code: OK
Latest RTT (millisecs) 47

Теперь мы можем контролировать доступность интерфейса Loopback1 на виртуальном маршрутизаторе FTP_Srv_Sd. Конфигурируем аналогичным образом мониторы и трекеры для контроля остальных Loopback интерфейсов.
Монитор и трекер для Loopback2 на SSH_Srv_Sd:

Client_Side#conf t
Client_Side(config)#ip sla monitor 2
Client_Side(config-sla-monitor)#type echo protocol ipIcmpEcho 10.0.2.129
Client_Side(config-sla-monitor-echo)#vrf SSH_Cl_Sd
Client_Side(config-sla-monitor-echo)#ip sla monitor schedule 2 start-time now life forever
Client_Side(config)#track 2 rtr 2 reachability

для Loopback1 на FTP_Cl_Sd:

Server_Side#conf t
Server_Side(config)#ip sla monitor 1
Server_Side(config-sla-monitor)#type echo protocol ipIcmpEcho 10.0.1.1
Server_Side(config-sla-monitor-echo)#vrf FTP_Srv_Sd
Server_Side(config-sla-monitor-echo)#ip sla monitor schedule 1 start-time now life forever
Server_Side(config)#track 1 rtr 1 reachability

и для Loopback2 на SSH_Cl_Sd:

Server_Side#conf t
Server_Side(config)#ip sla monitor 2
Server_Side(config-sla-monitor)#type echo protocol ipIcmpEcho 10.0.2.1
Server_Side(config-sla-monitor-echo)#vrf SSH_Srv_Sd
Server_Side(config-sla-monitor-echo)#ip sla monitor schedule 2 start-time now life forever
Server_Side(config)#track 2 rtr 2 reachability

Проверяем, что все работает:

Client_Side#sh track
Track 1
Response Time Reporter 1 reachability
Reachability is Up
4 changes, last change 00:30:08
Latest operation return code: OK
Latest RTT (millisecs) 72
Track 2
Response Time Reporter 2 reachability
Reachability is Up
2 changes, last change 00:35:28
Latest operation return code: OK
Latest RTT (millisecs) 72

Server_Side#sh track
Track 1
Response Time Reporter 1 reachability
Reachability is Up
2 changes, last change 00:35:57
Latest operation return code: OK
Latest RTT (millisecs) 55
Track 2
Response Time Reporter 2 reachability
Reachability is Up
2 changes, last change 00:35:52
Latest operation return code: OK
Latest RTT (millisecs) 27

Видим, что все нормально. Ну и теперь самая интересная часть, что же со всеми этими мониторами и трекерами делать.
В route-map для обычных маршрутизаторов (не виртуальных) есть возможность задать next-hop от состояния трекеров, например:


Client_Side(config-route-map)#set ip next-hop verify-availability 10.0.1.129 1 track 1

Но возможности выбирать виртуальный маршрутизатор подобным образом нет.
Есть еще при конфигурировании такая команда как match ip next-hop, то есть политика вроде как должна применяться в зависимости от маршрута. Возможность вставлять маршруты в таблицу маршрутизации в зависимости от состоянии трекеров есть. Однако, хотя команда и воспринимается системой, никакого влияния на применение route-map не оказывает.
Поэтому последней возможностью отработать изменение состояние трекера являются ЕЕМ апплеты. Всего нам понадобятся четыре апплета: два для отработки отказов и два для отработки восстановления виртуальных сетей. Логика работы очень проста: при отказе одной виртуальной сети прописать маршрутизацию на другую, а при восстановлении вернуть обратно.

Client_Side(config)#event manager applet FTP_DOWN
Client_Side(config-applet)# event syslog pattern "TRACKING-5-STATE: 1 rtr 1 reachability Up->Down"
Client_Side(config-applet)#action 001 cli command "enable"
Client_Side(config-applet)#action 002 cli command "configure terminal"
Client_Side(config-applet)#action 003 cli command "route-map Cl_Sd_Map permit 10"
Client_Side(config-applet)#action 004 cli command "set vrf SSH_Cl_Sd"
Client_Side(config-applet)#action 005 cli command "end"
Client_Side(config-applet)#action 006 cli command "exit"
Client_Side(config-applet)#action 007 cli command "exit"

Client_Side(config-applet)#event manager applet FTP_UP
Client_Side(config-applet)#event syslog pattern "TRACKING-5-STATE: 1 rtr 1 reachability Down->Up"
Client_Side(config-applet)#action 001 cli command "enable"
Client_Side(config-applet)#action 002 cli command "configure terminal"
Client_Side(config-applet)#action 003 cli command "route-map Cl_Sd_Map permit 10"
Client_Side(config-applet)#action 004 cli command "set vrf FTP_Cl_Sd"
Client_Side(config-applet)#action 005 cli command "end"
Client_Side(config-applet)#action 006 cli command "exit"
Client_Side(config-applet)#action 007 cli command "exit"

Client_Side(config-applet)#event manager applet SSH_DOWN
Client_Side(config-applet)#event syslog pattern "TRACKING-5-STATE: 2 rtr 2 reachability Up->Down"
Client_Side(config-applet)#action 001 cli command "enable"
Client_Side(config-applet)#action 002 cli command "configure terminal"
Client_Side(config-applet)#action 003 cli command "route-map Cl_Sd_Map permit 11"
Client_Side(config-applet)#action 004 cli command "set vrf FTP_Cl_Sd"
Client_Side(config-applet)#action 005 cli command "end"
Client_Side(config-applet)#action 006 cli command "exit"
Client_Side(config-applet)#action 007 cli command "exit"

Client_Side(config-applet)#event manager applet SSH_UP
Client_Side(config-applet)#event syslog pattern "TRACKING-5-STATE: 2 rtr 2 reachability Down->Up"
Client_Side(config-applet)#action 001 cli command "enable"
Client_Side(config-applet)#action 002 cli command "configure terminal"
Client_Side(config-applet)#action 003 cli command "route-map Cl_Sd_Map permit 11"
Client_Side(config-applet)#action 004 cli command "set vrf SSH_Cl_Sd"
Client_Side(config-applet)#action 005 cli command "end"
Client_Side(config-applet)#action 006 cli command "exit"
Client_Side(config-applet)#action 007 cli command "exit"

И аналогичным образом на маршрутизаторе Server_Side:

Server_Side(config)#event manager applet FTP_DOWN
Server_Side(config-applet)#event syslog pattern "TRACKING-5-STATE: 1 rtr 1 reachability Up->Down"
Server_Side(config-applet)#action 001 cli command "enable"
Server_Side(config-applet)#action 002 cli command "configure terminal"
Server_Side(config-applet)#action 003 cli command "route-map Srv_Sd_Map permit 10"
Server_Side(config-applet)#action 004 cli command "set vrf SSH_Srv_Sd"
Server_Side(config-applet)#action 005 cli command "end"
Server_Side(config-applet)#action 006 cli command "exit"
Server_Side(config-applet)#action 007 cli command "exit"

Server_Side(config-applet)#event manager applet FTP_UP
Server_Side(config-applet)#event syslog pattern "TRACKING-5-STATE: 1 rtr 1 reachability Down->Up"
Server_Side(config-applet)#action 001 cli command "enable"
Server_Side(config-applet)#action 002 cli command "configure terminal"
Server_Side(config-applet)#action 003 cli command "route-map Srv_Sd_Map permit 10"
Server_Side(config-applet)#action 004 cli command "set vrf FTP_Srv_Sd"
Server_Side(config-applet)#action 005 cli command "end"
Server_Side(config-applet)#action 006 cli command "exit"
Server_Side(config-applet)#action 007 cli command "exit"

Server_Side(config-applet)#event manager applet SSH_DOWN
Server_Side(config-applet)#event syslog pattern "TRACKING-5-STATE: 2 rtr 2 reachability Up->Down"
Server_Side(config-applet)#action 001 cli command "enable"
Server_Side(config-applet)#action 002 cli command "configure terminal"
Server_Side(config-applet)#action 003 cli command "route-map Srv_Sd_Map permit 11"
Server_Side(config-applet)#action 004 cli command "set vrf FTP_Srv_Sd"
Server_Side(config-applet)#action 005 cli command "end"
Server_Side(config-applet)#action 006 cli command "exit"
Server_Side(config-applet)#action 007 cli command "exit"

Server_Side(config-applet)#event manager applet SSH_UP
Server_Side(config-applet)#event syslog pattern "TRACKING-5-STATE: 2 rtr 2 reachability Down->Up"
Server_Side(config-applet)#action 001 cli command "enable"
Server_Side(config-applet)#action 002 cli command "configure terminal"
Server_Side(config-applet)#action 003 cli command "route-map Srv_Sd_Map permit 11"
Server_Side(config-applet)#action 004 cli command "set vrf SSH_Srv_Sd"
Server_Side(config-applet)#action 005 cli command "end"
Server_Side(config-applet)#action 006 cli command "exit"
Server_Side(config-applet)#action 007 cli command "exit"

Ну и осталось только проверить работу. Для этого включим отладку апплетов:

Client_Side#debug event manager action cli

Сымитируем отказ сети FTP отключение интерфейса Loopback1 на маршрутизаторе Server_Side:


Server_Side#conf t
Server_Side(config)#int lo1
Server_Side(config-if)#sh

И проверяем реакцию на маршрутизаторе Client_Side:

Client_Side#
*Mar 1 00:08:59.687: %TRACKING-5-STATE: 1 rtr 1 reachability Up->Down
*Mar 1 00:08:59.719: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : CTL : cli_open called.
*Mar 1 00:08:59.723: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : IN :
*Mar 1 00:08:59.739: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : OUT :
*Mar 1 00:08:59.739: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : OUT : Client_Side>
*Mar 1 00:08:59.739: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : OUT : Client_Side>
*Mar 1 00:08:59.739: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : OUT : Client_Side>
*Mar 1 00:08:59.739: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : IN : >enable
*Mar 1 00:08:59.755: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : OUT :
*Mar 1 00:08:59.759: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : OUT : Client_Side#
*Mar 1 00:08:59.759: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : IN : #configure terminal
*Mar 1 00:08:59.783: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : OUT :
*Mar 1 00:08:59.787: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : OUT : Enter configuration commands, one per line. End with CNTL/Z.
*Mar 1 00:08:59.787: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : OUT : Client_Side(config)#
*Mar 1 00:08:59.795: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : IN : #route-map Cl_Sd_Map permit 10
*Mar 1 00:08:59.811: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : OUT :
*Mar 1 00:08:59.811: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : OUT : Client_Side(config-route-map)#
*Mar 1 00:08:59.811: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : IN : #set vrf SSH_Cl_Sd
*Mar 1 00:08:59.831: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : OUT :
*Mar 1 00:08:59.835: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : OUT : Client_Side(config-route-map)#
*Mar 1 00:08:59.839: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : IN : #end
*Mar 1 00:08:59.855: %SYS-5-CONFIG_I: Configured from console by on vty0 (EEM:FTP_DOWN)
Client_Side#
Client_Side#sh route-map
route-map Cl_Sd_Map, permit, sequence 10
Match clauses:
ip address (access-lists): FTP_Cl_Sd_List
Set clauses:
vrf SSH_Cl_Sd
Policy routing matches: 0 packets, 0 bytes
route-map Cl_Sd_Map, permit, sequence 11
Match clauses:
ip address (access-lists): SSH_Cl_Sd_List
Set clauses:
vrf SSH_Cl_Sd
Policy routing matches: 0 packets, 0 bytes

Как мы видим, после того как произошел отказ сети FTP, все пакеты, предназначенные для нее, теперь будут направлять в сеть SSH. Так как мы только сымитировали отказ сети выключением интерфейса, в обратную сторону пакеты конечно же пойдут по сети FTP. В случае настоящего отказа сети FTP аналогичный апплет отработает и на Server_Side.

Ну и для полного комплекта проверим восстановление сети.

Server_Side(config-if)#no sh

Client_Side#
*Mar 1 00:16:07.907: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : OUT :
*Mar 1 00:16:07.911: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : OUT : Client_Side#
*Mar 1 00:16:07.911: %HA_EM-3-FMPD_ERROR: Error executing applet FTP_DOWN statement 005
Client_Side#
*Mar 1 00:16:07.919: %HA_EM-6-LOG: FTP_DOWN : DEBUG(cli_lib) : : CTL : cli_close called.
Client_Side#
*Mar 1 00:17:09.787: %TRACKING-5-STATE: 1 rtr 1 reachability Down->Up
*Mar 1 00:17:09.831: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : CTL : cli_open called.
*Mar 1 00:17:09.831: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : IN :
*Mar 1 00:17:09.843: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT :
*Mar 1 00:17:09.843: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT : Client_Side>
*Mar 1 00:17:09.843: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT : Client_Side>
*Mar 1 00:17:09.843: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT : Client_Side>
*Mar 1 00:17:09.843: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : IN : >enable
*Mar 1 00:17:09.859: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT :
Client_Side#
*Mar 1 00:17:09.863: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT : Client_Side#
*Mar 1 00:17:09.867: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : IN : #configure terminal
*Mar 1 00:17:09.887: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT :
*Mar 1 00:17:09.887: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT : Enter configuration commands, one per line. End with CNTL/Z.
*Mar 1 00:17:09.887: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT : Client_Side(config)#
*Mar 1 00:17:09.891: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : IN : #route-map Cl_Sd_Map permit 10
*Mar 1 00:17:09.911: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT :
*Mar 1 00:17:09.911: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT : Client_Side(config-route-map)#
*Mar 1 00:17:09.911: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : IN : #set vrf FTP_Cl_Sd
*Mar 1 00:17:09.923: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT :
*Mar 1 00:17:09.923: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT : Client_Side(config-route-map)#
*Mar 1 00:17:09.923: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : IN : #end
*Mar 1 00:17:09.923: %SYS-5-CONFIG_I: Configured from console by on vty0 (EEM:FTP_UP)
*Mar 1 00:17:09.935: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT :
*Mar 1 00:17:09.935: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT : Client_Side#
*Mar 1 00:17:09.935: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : IN : #exit
*Mar 1 00:17:09.951: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT :
*Mar 1 00:17:09.955: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT : Client_Side>
*Mar 1 00:17:09.955: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : IN : >exit
*Mar 1 00:17:09.971: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT :
*Mar 1 00:17:09.975: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : OUT : Client_Side>
*Mar 1 00:17:09.975: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : IN : >exit
*Mar 1 00:17:09.975: %HA_EM-6-LOG: FTP_UP : DEBUG(cli_lib) : : CTL : cli_close called.
Client_Side#
Client_Side#sh route-map
route-map Cl_Sd_Map, permit, sequence 10
Match clauses:
ip address (access-lists): FTP_Cl_Sd_List
Set clauses:
vrf FTP_Cl_Sd
Policy routing matches: 0 packets, 0 bytes
route-map Cl_Sd_Map, permit, sequence 11
Match clauses:
ip address (access-lists): SSH_Cl_Sd_List
Set clauses:
vrf SSH_Cl_Sd
Policy routing matches: 0 packets, 0 bytes

И мы видим, что все вернулось на свои места.

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

Client_Side(config)#track 3 list boolean or
Client_Side(config-track)#object 1
Client_Side(config-track)#object 2

Первой строкой мы создали трекер который отслеживает список трекеров и определяет свое состояние как результат операции «ИЛИ». Второй и третьей строкой мы добавляем в этот список трекеры 1 и 2. Таким образом, трекер 3 будет принимать значение Down, когда и трекер 1, и трекер 2 принимают значение Down. А реакцией на значение Down трекера 3 может быть, например, запуск апплета, который отправляет сообщение на электронную почту (хотя по-хорошему отправка сообщения должна происходить при переходе в состояние Down и первых двух трекеров):

Client_Side(config)#event manager environment _email_to post@mail.ru
Client_Side(config)#event manager environment _email_server mail.ru
Client_Side(config)#event manager environment _email_from test@test.net
Client_Side(config)#event manager applet ALL_DOWN
Client_Side(config -applet)#event syslog pattern "TRACKING-5-STATE: 3 list boolean or Up->Down"
Client_Side(config -applet)#action 001 mail server "$_email_server" to "$_email_to" from "$_email_from" subject "$_event_pub_time: All networks is down"

Не забываем, что и доменные имена надо разрешать:

Client_Side(config)#ip domain-lookup
Client_Side(config)#ip name-server 8.8.8.8

Вот как-то так. Сразу честно признаюсь, что отправку почты до конца протестировать не удалось. Mail.ru smtp соединения сразу сбрасывает.

Аверьянов Кирилл
network-lab.ru


Комментарии:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Hide me
Получать регулярно свежие материалы, лабораторные и вебинары
Email Имя
Show me