Представьте задачу — есть офис, подключенный к 2м различным интернет-провайдерам посредством маршрутизатора от Cisco и вам необходимо обеспечить резервирование сервиса.
Вариантов решения может быть несколько (2 статических маршрута по умолчанию, динамическая маршрутизация, etc.), но всегда есть ограничения для их использования. Например, 2 статических маршрута по умолчанию будут выполнять поставленную задачу только в случае падения line protocol на интерфейсе в сторону провайдера.
Сразу хочу оговориться — данное решение не позиционируется как некая панацея или единственное верное для задачи. Это лишь один из взглядов на проблему, дополнительно дающий начальное представление о механизмах Cisco IOS — IP Service Level Agreements и Embedded Event Manager.
IP Service Level Agreements
Механизм IP SLA выполняет простую функцию — замер критичных для различных приложений (в том числе мультимедиа) параметров IP-сети: задержки, джиттера, доступности ресурсов и т.д. Архитектура проста и прозрачна — для замеров параметров между 2мя устройствами в сети (в нашем случае — маршрутизаторы Cisco) одно из устройств генерирует запросы на замеры (sla monitor), а второе отвечает на них (sla responder).
Embedded Event Manager
EEM — механизм, позволяющий реагировать на различные события (events) происходящие с устройством. Примеры событий — появление определнного сообщения в logging buffer, введенная в CLI команда, SNMP trap, событие сгенерированное подсистемой IP SLA и многое другое. Обработать эти события можно 2мя способами — applet (пишется прямо в IOS CLI) или script (пишется на TCL и загружается в маршрутизатор). Таким образом, EEM является очень гибким механизмом для расширения функциональности маршрутизатора — условно говоря, количество вариантов применения ограничивается только вашей фантазией и навыками программирования.
Как эти 2 механизма помогут в нашем случае? Очень просто — IP SLA будет с помощью icmp (в этом случае настраивать sla responder не требуется) проверять доступность какого-либо интернет-ресурса и при его недоступности генерировать событие, которое мы обработаем с помощью EEM. В приведенном примере я просто поменяю маршрут по умолчанию на другого провайдера, но можно вносить и более комплексные изменения в конфигурацию — менять ACL, правила NAT и прочее.
Необходимое замечание — чтобы обрабатывать события от IP SLA необходим EEM v3.0 (начиная с версии IOS 12.4(22)T).
Тестовая топология:
CPE — маршрутизатор установленный в офисе, на котором и будут выполняться все описанные конфигурации. ISP1 и ISP2 — маршрутизаторы провайдеров. Для пущей простоты на них настроен NAT.
Конфигурация SLA:
В данном кусочке конфига мы создаем sla monitor под номером 1, который будет посылать icmp запросы на 10.0.0.1 каждые 30 секунд (frequency 30), начиная с текущего момента (start-time now) и постоянно (life forever). Следующие 2 строки задают реакцию по результатам sla monitor, в данном случае — генерация события по таймауту (react timeout threshold-type immediate action-type triggerOnly).
Конфигурация EEM:
Тут все прозрачно — задаем директорию где сохранены предварительно загруженные (например с tftp) TCL-скрипты и устанавливаем ipsla.tcl как пользовательский обработчик событий.
Проверить установленные скрипты для обработки событий можно командой show event manager policy registered:
TCL-скрипт, выполняющий всю логику:
Построчно разбирать смысла особого нет, поэтому отмечу только принципиальные моменты. Строка 1 — задает тип обрабатываемого события, в нашем случае как раз IP SLA с номером 1 (operation_id 1). Строки 4-5 дают возможность использовать встроенные в роутер расширения TCL (например action_syslog для логирования). В 11-14 мы проверяем параметр event condition, это необходимо, так как IP SLA event генерируется 2 раза — когда событие свершилось (Occured) и когда очистилось (Cleared). В нашем случае маршрутизацию необходимо менять только когда событие произошло и 10.0.0.1 стал недоступен. Остальные строчки скрипта, как мне кажется, в дополнительных разъяснениях не нуждаются — все ясно из комментариев. Так же, для использования в реальных условиях, в скрипт необходимо добавить обработку ошибок (как наприме в строках 20-23), здесь я это опустил для удобства восприятия.
Надеюсь этот маленький пример дает начальное представление об IP SLA и EEM, а так же о потенциале использования этих механизмов.
UPD: перенес в сообщество Cisco
Вариантов решения может быть несколько (2 статических маршрута по умолчанию, динамическая маршрутизация, etc.), но всегда есть ограничения для их использования. Например, 2 статических маршрута по умолчанию будут выполнять поставленную задачу только в случае падения line protocol на интерфейсе в сторону провайдера.
Сразу хочу оговориться — данное решение не позиционируется как некая панацея или единственное верное для задачи. Это лишь один из взглядов на проблему, дополнительно дающий начальное представление о механизмах Cisco IOS — IP Service Level Agreements и Embedded Event Manager.
IP Service Level Agreements
Механизм IP SLA выполняет простую функцию — замер критичных для различных приложений (в том числе мультимедиа) параметров IP-сети: задержки, джиттера, доступности ресурсов и т.д. Архитектура проста и прозрачна — для замеров параметров между 2мя устройствами в сети (в нашем случае — маршрутизаторы Cisco) одно из устройств генерирует запросы на замеры (sla monitor), а второе отвечает на них (sla responder).
Embedded Event Manager
EEM — механизм, позволяющий реагировать на различные события (events) происходящие с устройством. Примеры событий — появление определнного сообщения в logging buffer, введенная в CLI команда, SNMP trap, событие сгенерированное подсистемой IP SLA и многое другое. Обработать эти события можно 2мя способами — applet (пишется прямо в IOS CLI) или script (пишется на TCL и загружается в маршрутизатор). Таким образом, EEM является очень гибким механизмом для расширения функциональности маршрутизатора — условно говоря, количество вариантов применения ограничивается только вашей фантазией и навыками программирования.
Как эти 2 механизма помогут в нашем случае? Очень просто — IP SLA будет с помощью icmp (в этом случае настраивать sla responder не требуется) проверять доступность какого-либо интернет-ресурса и при его недоступности генерировать событие, которое мы обработаем с помощью EEM. В приведенном примере я просто поменяю маршрут по умолчанию на другого провайдера, но можно вносить и более комплексные изменения в конфигурацию — менять ACL, правила NAT и прочее.
Необходимое замечание — чтобы обрабатывать события от IP SLA необходим EEM v3.0 (начиная с версии IOS 12.4(22)T).
Тестовая топология:

CPE — маршрутизатор установленный в офисе, на котором и будут выполняться все описанные конфигурации. ISP1 и ISP2 — маршрутизаторы провайдеров. Для пущей простоты на них настроен NAT.
Конфигурация SLA:
ip sla 1 icmp-echo 10.0.0.1 frequency 30 ip sla schedule 1 life forever start-time now ip sla reaction-configuration 1 react timeout threshold-type immediate action-type triggerOnly ip sla enable reaction-alerts
В данном кусочке конфига мы создаем sla monitor под номером 1, который будет посылать icmp запросы на 10.0.0.1 каждые 30 секунд (frequency 30), начиная с текущего момента (start-time now) и постоянно (life forever). Следующие 2 строки задают реакцию по результатам sla monitor, в данном случае — генерация события по таймауту (react timeout threshold-type immediate action-type triggerOnly).
Конфигурация EEM:
event manager directory user policy "disk0:/" event manager policy ipsla.tcl type user
Тут все прозрачно — задаем директорию где сохранены предварительно загруженные (например с tftp) TCL-скрипты и устанавливаем ipsla.tcl как пользовательский обработчик событий.
Проверить установленные скрипты для обработки событий можно командой show event manager policy registered:
No. Class Type Event Type Trap Time Registered Name 1 script user ipsla Off Mon Oct 12 22:04:00 2009 ipsla.tcl operation-id {1} nice 0 queue-priority normal maxrun 20.000 scheduler rp_primary
TCL-скрипт, выполняющий всю логику:
- ::cisco::eem::event_register_ipsla operation_id 1
- # import EEM symbols
- namespace import ::cisco::eem::
- namespace import ::cisco::lib::
- # getting EEM environment data
- array set evtData [event_reqinfo]
- set evt_cond $evtData(condition)
- if { $evt_cond == "Cleared" } {
- action_syslog msg "IPSLA condition cleared"
- exit 0 0
- }
- # log message
- action_syslog msg "IPSLA condition occured, changing default route to another ISP"
- # ope Cisco CLI
- if { [catch {cli_open} result] } {
- puts stderr "CLI OPEN failed ($result)"
- exit 0 0
- }
- array set cfd $result
- # get default route and put gateway ip address to $ip_nexthop
- catch {cli_exec $cfd(fd) "sh ip route 0.0.0.0 0.0.0.0 | inc \\\*"} result
- regexp {[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+} $result ip_nexthop
- # delete current default route
- cli_exec $cfd(fd) "enable"
- cli_exec $cfd(fd) "configure terminal"
- cli_exec $cfd(fd) "no ip route 0.0.0.0 0.0.0.0"
- # set default route via another ISP
- switch $ip_nexthop {
- 192.168.0.6 { cli_exec $cfd(fd) "ip route 0.0.0.0 0.0.0.0 192.168.0.2" }
- 192.168.0.2 { cli_exec $cfd(fd) "ip route 0.0.0.0 0.0.0.0 192.168.0.6" }
- }
- cli_exec $cfd(fd) "end"
- catch {cli_close $cfd(fd) $cfd(tty_id)}
- exit 0 0
Построчно разбирать смысла особого нет, поэтому отмечу только принципиальные моменты. Строка 1 — задает тип обрабатываемого события, в нашем случае как раз IP SLA с номером 1 (operation_id 1). Строки 4-5 дают возможность использовать встроенные в роутер расширения TCL (например action_syslog для логирования). В 11-14 мы проверяем параметр event condition, это необходимо, так как IP SLA event генерируется 2 раза — когда событие свершилось (Occured) и когда очистилось (Cleared). В нашем случае маршрутизацию необходимо менять только когда событие произошло и 10.0.0.1 стал недоступен. Остальные строчки скрипта, как мне кажется, в дополнительных разъяснениях не нуждаются — все ясно из комментариев. Так же, для использования в реальных условиях, в скрипт необходимо добавить обработку ошибок (как наприме в строках 20-23), здесь я это опустил для удобства восприятия.
Надеюсь этот маленький пример дает начальное представление об IP SLA и EEM, а так же о потенциале использования этих механизмов.
UPD: перенес в сообщество Cisco