Cisco-EEM: различия между версиями

Материал из noname.com.ua
Перейти к навигацииПерейти к поиску
Строка 1: Строка 1:
   
−
{{caution|text=Статья целиком скопирована с http://xgu.ru/wiki/Embedded_Event_Manager c целью ждальнейшей доработки и исследования
 +
{{caution|text=Статья целиком скопирована с http://xgu.ru/wiki/Embedded_Event_Manager c целью дальнейшей доработки и исследования
 
}}
  
}}
   

Версия 12:01, 23 июня 2024

Icon-caution.gif

Статья целиком скопирована с http://xgu.ru/wiki/Embedded_Event_Manager c целью дальнейшей доработки и исследования


Stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, соообщите.


EEM это функционал встроенный в Cisco IOS, который позволяет создавать сценарии для автоматизации работы устройств.

Основы EEM

Сценарий EEM можно представить так:

  • Если "событие":
    • то "выполнить действие (действия)"

То есть, причиной для выполнения сценария является событие. Событием может быть, например, изменение состояния track, запуск сценария вручную, выполнение команды и другие.

Сам сценарий может состоять из перечня команд, которые нужно выполнить, генерации syslog-сообщения и другие.

Событие, чаще всего, одно. А действий, как правило, несколько.

Синтаксис EEM

Сценарий создается в конфигурационном режиме: 

event manager applet <name>

В каждом сценарии обязательно должно быть событие: 

event manager applet TEST
 event <event name>

EEM поддерживает довольно много событий. Проверить версию EEM и посмотреть какие события поддерживаются можно с помощью команды: 

r1# sh event manager version

За событием следуют действия. У каждого действия есть свой порядковый номер. События выполняются и сортируются по номеру.

Note:

Так как в EEM используется лексикографический порядок, важно обратить внимание, что, если есть действия с нумерацией от 1 до 11, то порядок будет таким: 1,10,11,2... Чтобы действия правильно сортировались, надо либо дописывать вначале нули, либо нумеровать действия так: 1.1, 1.2, 1.3 (что к тому же позволяет группировать действия по логике выполнения).

Icon-caution.gif

Очень важный момент в работе EEM: давать команду exit в конце (или сначала end, а затем exit, если последние команды были в конфигурационном режиме).

Дело в том, что EEM использует vty для выполнения сценариев. И если не выходить явно, то можно случайно лишить себя возможности зайти на устройство.

Доступность функционала в разных версиях IOS и разных версиях EEM

Функционал EEM расширяется от версии к версии и поэтому обязательно нужно обращать внимание на то, доступен ли EEM в вашей версии IOS (CFN ) и какая именно версия EEM используется (sh event manager version).

На этой странице описывается EEM версии 4.0

Доступность функционала по обнаружению событий (event detectors) в различных версиях IOS: EEM Event Detectors Available by Cisco IOS Release

Доступность действий EEM в различных версиях IOS: EEM Actions Available by Cisco IOS Release

Определение версии EEM

Команда показывает какая версия EEM используется в данном IOS и какие события (events) доступны 

R3#sh event manager version 
Embedded Event Manager Version 4.00
Component Versions:
eem: (onep_dev2)6.0.3
eem-gold: (rel1)1.0.1
eem-call-home: (onep_dev2)1.2.0
Event Detectors:
Name                Version   Node        Type    
application         01.00     node0/0     RP      
rf                  01.00     node0/0     RP      
identity            01.00     node0/0     RP      
neighbor-discovery  01.00     node0/0     RP      
msp                 03.00     node0/0     RP      
routing             02.00     node0/0     RP      
nhrp                01.00     node0/0     RP      
track               01.00     node0/0     RP      
resource            01.00     node0/0     RP      
syslog              01.00     node0/0     RP      
cli                 01.00     node0/0     RP      
counter             01.00     node0/0     RP      
interface           01.00     node0/0     RP      
ioswdsysmon         01.00     node0/0     RP      
none                01.00     node0/0     RP      
oir                 01.00     node0/0     RP      
snmp                01.00     node0/0     RP      
snmp-object         01.00     node0/0     RP      
ipsla               01.00     node0/0     RP      
snmp-notification   01.00     node0/0     RP      
timer               01.00     node0/0     RP      
test                01.00     node0/0     RP      
config              01.00     node0/0     RP      
env                 01.00     node0/0     RP      
nf                  01.00     node0/0     RP      
rpc                 01.00     node0/0     RP

EEM Event Detectors

События, на которые может реагировать EEM:

  • Запуск вручную:
    • event none
  • Работа с событиями в CLI:
    • event cli - выполнение определенное команды
    • event syslog - появление syslog-сообщения
    • event config - изменение конфигурационного файла
  • Запуск сценария в определенное время:
    • event timer
  • Работа с счетчиками интерфейсов, с OID, с SNMP
    • interface
    • snmp
    • snmp-notification
    • snmp-object
    • oir
  • Функции IOS:
    • track
    • ipsla
    • dmvpn
    • routing
    • neighbor-discovery - CDP
    • nf - NetFlow
  • Другое
    • counter
    • env
    • identity
    • ioswdsysmon
    • resource
    • rf
    • rpc
    • tag
    • application

event none

none это специальное событие, которое позволяет запускать сценарий вручную

Например, надо внести какие-то изменения в конфигурации, которые приведут к временному разрыву связи с устройством. И, когда связь разорвется, надо будет еще выполнить несколько команд.

В таком случае, можно набрать все необходимые команды в сценарий EEM, и поставить ему event none. И запустить сценарий.

Note:

Конечно же, желательно проверить его работу заранее на тестовом оборудовании или виртуалках. И даже после проверки стоит поставить заранее перезагрузку, на тот случай, если вы не учли какой-то момент и после отработки сценария, связь потеряется

Также событие none может пригодиться для ситуаций, когда требуется часто выполнять один и тот же перечень команд. Тогда их можно просто набрать в сценарий и запускать его по необходимости.

Примеры события none

event manager applet CONFIG
 event none
 action 0001 cli command "en"
 action 0002 cli command "conf t"
 action 0003 cli command "no router bgp 1111"
 action 0004 cli command "router bgp 3333"
 action 0005 cli command " bgp log-neighbor-changes"
...

Запустить его можно вручную: 

router# event manager run CONFIG

Multiple event

Начиная с версии EEM появилась возможность запускать политику EEM на основании нескольких произошедших событий.

event CLI

В качестве события в EEM может использоваться ввод в командной строке.

EEM позволяет указывать как работать с вводом, который перехватил. Например, можно сделать так, чтобы EEM перехватывал и не выполнял команду.


Примеры события cli

Пример политики: 

event manager applet USER_CONF_T
 event cli pattern "configure terminal" sync no skip no occurs 1
 action 1 syslog msg "User $_cli_username entered configuration mode on device $_cli_host "

Сообщение syslog выглядит так: 

*Feb 12 14:31:09.982: %HA_EM-6-LOG: USER_CONF_T: User nata entered configuration mode on device 10.3.36.3

При выполнении любой команды будет генерироваться лог сообщение с указанием пользователя, команды и устройства: 

event manager applet COMM_ACC
 event cli pattern ".*" sync no skip no occurs 1
 action 1 syslog msg "User $_cli_username entered $_cli_msg on device $_cli_host "

Пример лога: 

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#
*Feb 12 14:38:51.523: %HA_EM-6-LOG: COMM_ACC: User nata entered configure terminal  on device 10.3.36.3 
R3(config)#do sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                10.3.36.3       YES NVRAM  up                    up      
Ethernet0/1                unassigned      YES NVRAM  up                    up      
Ethernet0/1.13             172.1.13.3      YES NVRAM  up                    up      
Ethernet0/1.23             172.1.23.3      YES NVRAM  administratively down down    
Ethernet0/2                unassigned      YES NVRAM  administratively down down    
Ethernet0/2.103            172.1.103.3     YES NVRAM  administratively down down    
Ethernet0/2.203            172.1.203.3     YES NVRAM  administratively down down    
Ethernet0/3                unassigned      YES NVRAM  administratively down down    
Loopback1                  3.3.3.3         YES NVRAM  up                    up      

*Feb 12 14:39:00.095: %HA_EM-6-LOG: COMM_ACC: User nata entered do sh ip int br on device 10.3.36.3 
*Feb 12 14:39:00.095: %HA_EM-6-LOG: COMM_ACC: User nata entered show ip interface brief  on device 10.3.36.3 
R3#

Доступные переменные можно посмотреть: 

R3#sh event manager detector cli detailed | b Applet
        Applet Configuration Syntax:
        [ no ] event [tag <tag-val>] cli
                 pattern <pattern-val>
                 [enter] [questionmark] [tab]
                 sync {yes | no}
                 skip {yes | no}
                 [occurs <occurs-val>]
                 [period <sec.msec>]
                 [default <sec.msec>]
                 [mode <parser mode val>]   
                 [maxrun <sec.msec>]
                 [ratelimit <sec.msec>]

        Applet Built-in Environment Variables:
        $_event_id
        $_job_id
        $_event_type
        $_event_type_string
        $_event_pub_time
        $_event_pub_sec
        $_event_pub_msec
        $_event_severity
        $_cli_msg
        $_cli_msg_count
        $_cli_line
        $_cli_key
        $_cli_tty
        $_cli_username
        $_cli_host
        $_cli_privilege
        $_cli_error_code

event syslog

Событие syslog позволяет работать с сообщениями syslog.

Например: 

event manager applet Fa0/1_no_shut
 event syslog pattern "Line protocol on Interface FastEthernet0/0, changed state to down"
 action 1 cli command "enable"
 action 2 cli command "conf t"
 action 3 cli command "interface fa0/1"
 action 4 cli command "no sh"
 action 5 syslog msg "Interface fa0/1 no shut"
 action 6 cli command "end"
 action 7 cli command "exit"

Комментарии к примеру:

  • событие: если выскочило сообщение "Line protocol on Interface FastEthernet0/0, changed state to down"
    • event syslog pattern - позволяет указывать регулярное выражение, при совпадении с которым, будут выполняться указанные действия
    • в данном случае, просто указана подстрока ожидаемого сообщения, без использования специальных символов
  • действия: идем в интерфейс fa0/1 и включаем его. Плюс вручную генерируем сообщение syslog
    • action cli command - какие команды выполнить, когда произошло событие
    • нюанс тут только в том, что обязательно надо писать сначала "enable"
    • в остальном, просто набираем нужные команды и все (не забывая брать их в кавычки)
    • action syslog msg - сгенерировать syslog-сообщение с указанным текстом

Проверка сценария: 

R3(config-if)#int fa0/0
R3(config-if)#sh
*Feb 13 07:44:33.480: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Feb 13 07:44:34.485: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down

*Feb 13 07:44:34.968: %HA_EM-6-LOG: Fa0/1_no_shut: Interface fa0/1 no shut

*Feb 13 07:44:36.876: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
*Feb 13 07:44:37.882: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up

event interface

event manager applet INTERFACE
 event interface name FastEthernet0/0 parameter txload entry-op gt entry-val 180 entry-type value poll-interval 20
 action 1 syslog msg "Fa0/0 txload > 180"

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

R3#ping 6.6.6.6 size 10000 timeout 0 repeat 10000
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (8221/8221), round-trip min/avg/max = 1/1/48 ms

*Feb 13 08:04:59.240: %HA_EM-6-LOG: INTERFACE: Fa0/0 txload > 180

R3#sh int fa0/0 | i txload
     reliability 255/255, txload 255/255, rxload 255/255

event SNMP

Посмотреть идентификаторы объектов в MIB, и другую инфорацию о MIB'ах можно на сайте cisco: http://cisco.com/go/mibs

В данном сценарии проверяется загрузка процессора, среднее значение за 5 минут. За это отвечает объект cpmCPULoadAvg5min: 

event manager applet SNMP
 event snmp oid 1.3.6.1.4.1.9.9.109.1.1.1.1.25 get-type exact entry-op gt entry-val "70" poll-interval 300
 action 1 syslog msg "CPU 5min > 70 exect value = $_snmp_oid_val"

SNMP object

SNMP notification

OIR

IP SLA

EEM может реагировать на события тестов IP SLA.

Настройка сценария EEM будет выполняться на примере теста: 

ip sla 10
 icmp-echo 25.0.0.5 source-interface Ethernet0/0
 threshold 1500
 timeout 2000
 frequency 3
ip sla schedule 10 life forever start-time now

Для работы с EEM нужно несколько дополнительных команд: 

ip sla reaction-configuration 10 react timeout threshold-type consecutive 3
ip sla enable reaction-alerts
ip sla logging traps

Первая команда настраивает реакцию на событие таймаут для теста 10:

  • react timeout - реагировать на событие timeout
  • threshold-type consecutive 3 - если событие таймаут произошло 3 раза подряд, появляется событие
  • обратите внимание, что этой команды недостаточно

Для того чтобы все процессы IOS (и только IOS), которые хотят получать оповещение о настроенных событиях IP SLA, получали их, настраивается команды 'ip sla enable reaction-alerts'.

Команда 'ip sla logging traps' не обязательна. Она настраивается, если нужно чтобы при возникновении событий генерировались лог-сообщения.

При такой конфигурации, EEM сценарий может реагировать как на syslog-сообщение (так как включено ip sla logging traps), так и на внутреннее событие IP SLA.

Сценарий: 

event manager applet IPSLA10_timeout
 event ipsla operation-id 10 reaction-type timeout
 action 001 if $_ipsla_condition eq "Occurred"
 action 002  cli command "enable"
 action 003  cli command "conf t"
 action 004  cli command "int e0/1"
 action 005  cli command "shutdown"
 action 006  syslog msg "IP SLA condition Timeout occured"
 action 007  syslog msg "Interface FastEthernet0/1 shutdown"
 action 008 else
 action 009  cli command "enable"
 action 010  cli command "conf t"
 action 011  cli command "int e0/1"
 action 012  cli command "no shutdown"
 action 013  syslog msg "IP SLA condition Timeout cleared"
 action 014  syslog msg "Interface FastEthernet0/1 no shutdown"
 action 015 end
 action 016 cli command "end"
 action 017 cli command "exit"

Событие event ipsla:

  • event ipsla operation-id 10 reaction-type timeout - этой строкой EEM регистрируется как желающий получать информацию о событиях IP SLA
    • event ipsla - работаем с событием функционала IP SLA
    • operation-id 10 - конкретизируем, что работаем с тестом с номером 10
    • reaction-type timeout - отлавливаем событие timeout

В действиях используется конструкция if/else:

  • в строке if проверяется определенное условие
  • если оно выполняется, выполняются команды в этом блоке
  • если условие не выполняется, сценарий переходит в блок else (если он есть) и выполняет действия в этом блоке
  • завершается блок if/else командой end

Внутри блоков используются действия cli и syslog.

Note:

Обратите внимание на разницу:

  • 'action 015 end' это завершение блока if/else
  • а 'action 016 cli command "end"' - выход в режим enable

Еще одна конструкция, которая еще не встречалась: 

action 001 if $_ipsla_condition eq "Occurred"

В выражении if мы используем переменную $_ipsla_condition. Эта переменная относится только к IP SLA и автоматически создается самим EEM. Мы же можем работать с ее значением.

В данном случае, мы сравниваем значение переменной со строкой "Occurred":

  • если значение равно Occurred, выполняются действия в блоке if

Проверить какие переменные есть для конкретного события можно так (в данном случае, для IP SLA): 

r1#sh event manager detector ipsla detailed

Итоговая конфигурация: 

ip sla 10
 icmp-echo 25.0.0.5 source-interface Ethernet0/0
 threshold 1500
 timeout 2000
 frequency 3
ip sla schedule 10 life forever start-time now

ip sla reaction-configuration 10 react timeout threshold-type consecutive 3
ip sla enable reaction-alerts
ip sla logging traps

event manager applet IPSLA10_timeout
 event ipsla operation-id 10 reaction-type timeout
 action 001 if $_ipsla_condition eq "Occurred"
 action 002  cli command "enable"
 action 003  cli command "conf t"
 action 004  cli command "int Fa0/1"
 action 005  cli command "shutdown"
 action 006  syslog msg "IP SLA condition Timeout occured"
 action 007  syslog msg "Interface FastEthernet0/1 shutdown"
 action 008 else
 action 009  cli command "enable"
 action 010  cli command "conf t"
 action 011  cli command "int Fa0/1"
 action 012  cli command "no shutdown"
 action 013  syslog msg "IP SLA condition Timeout cleared"
 action 014  syslog msg "Interface FastEthernet0/1 no shutdown"
 action 015 end
 action 016 cli command "end"
 action 017 cli command "exit"

Проверка выполнение сценария.

Когда IP SLA тест не получил ответ (должно не прийти 3 ответа): 

%RTT-3-IPSLATHRESHOLD: IP SLAs(10): Threshold Occurred for timeout

%HA_EM-6-LOG: IPSLA10_timeout: IP SLA condition Timeout occured
%HA_EM-6-LOG: IPSLA10_timeout: Interface FastEthernet0/1 shutdown

%SYS-5-CONFIG_I: Configured from console by  on vty0 (EEM:IPSLA10_timeout)

%LINK-5-CHANGED: Interface Ethernet0/1, changed state to administratively down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to down

После восстановления IP SLA теста: 

%RTT-3-IPSLATHRESHOLD: IP SLAs(10): Threshold Cleared for timeout
%HA_EM-6-LOG: IPSLA10_timeout: IP SLA condition Timeout cleared
%HA_EM-6-LOG: IPSLA10_timeout: Interface FastEthernet0/1 no shutdown

%SYS-5-CONFIG_I: Configured from console by  on vty0 (EEM:IPSLA10_timeout)

%LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up

event track

Track это функция оборудования Cisco, которая позволяет отслеживать состояние выбранного объекта и влиять на состояние других функций.

Например, track используется в связке с IP SLA для резервирования провайдеров.

В этой схеме:

  • IP SLA используется для проверки доступности ресурса (а лучше ресурсов) в Интернет
  • Track следит за IP SLA
    • если ресурс пингуется, то track в состоянии UP
    • если ресурс не пингуется, то track в состоянии DOWN
  • В свою очередь, track влияет на маршрут, к которому он привязан:
    • Track UP - маршрут есть
    • Track Down - маршрута нет

Зачем же тут нужен EEM, если и так все работает?

EEM в такой схеме нужен для того чтобы, при переключении провайдеров (смене статуса track), очищалась таблица трансляций (NAT). Иначе сессии подвисают.

Сценарий EEM, в таком случае, может выглядеть так: 

event manager applet ISP_1 
 event track 100 state any
 action 001 cli command "enable"
 action 002 cli command "clear ip nat trans *"
 action 003 syslog msg "ISP 1 status changed"
 action 004 cli command "end"
 action 005 cli command "exit"

Событие 'event track 100 state any реагирует на смену состояние track.

Конфигурация IP SLA и Track тут не описывается. Если вы хотите посмотреть полную конфигурацию для такой схемы, она описана тут: http://xgu.ru/wiki/2_ISP_%D0%B1%D0%B5%D0%B7_BGP

Однако, как правило, удобнее разделить события UP и DOWN. В таком случае у нас получатся два сценария: 

event manager applet ISP_1_UP 
 event track 100 state up
 action 001 cli command "enable"
 action 002 cli command "clear ip nat trans *"
 action 003 syslog msg "ISP 1 is UP"
 action 004 cli command "end"
 action 005 cli command "exit"

event manager applet ISP_1_DOWN 
 event track 100 state down
 action 001 cli command "enable"
 action 002 cli command "clear ip nat trans *"
 action 003 syslog msg "ISP 1 is DOWN"
 action 004 cli command "end"
 action 005 cli command "exit"

Stub track

Stub track, как правило, используется в action. А именно, в действиях его состояние меняется с помощью EEM.

Преимущество Track в том, что он может влияет на другие объекты в конфигурации.

Note:

Обратите внимание, что по сути, можно было бы и без stub track менять конфигурацию, так как EEM может передавать любые команды.

Stub track немного лучше тем, что объект, к которому привязан track, остается в конфигурации. А не исчезает полностью, как в случае, когда мы просто EEM его удаляем и опять создаем.

Создается stub track таким образом: 

track 10 stub-object
 default-state down

При создании Stub track, как и в обычном track, мы указываем номер. И обязательно надо не забыть параметр stub-object. Именно он делает track 'тупиковым'.

Еще одна особенность stub track - состояние по умолчанию. В нашем track мы указали, что по умолчанию он в состоянии down.

Теперь track можно привязать к объекту. В данном случае, к статическому маршруту: 

ip route 0.0.0.0 0.0.0.0 190.16.3.1 track 10

Обратите внимание, что состояние по умолчанию, для данного трека, DOWN. Поэтому маршрута не будет в таблице маршрутизации.

Создаем сценарии. Используем timer cron, чтобы создать статические маршруты, которые появляются и исчезают по расписанию.

Первый сценарий поднимает track. И, соответственно, появляется маршрут: 

event manager applet ADD_ROUTE
 event timer cron cron-entry "0 6 * * 1-5"
 action 001 track set 10 state up
 action 002 syslog msg "6 AM! Route 0.0.0.0/0 190.16.3.1 added"
 action 003 cli command "exit"

Второй сценарий переводит track в состояние DOWN. И, соответственно, исчезает маршрут: 

event manager applet DEL_ROUTE
 event timer cron cron-entry "0 19 * * 1-5"
 action 001 track set 10 state down
 action 002 syslog msg "7 PM! Route 0.0.0.0/0 190.16.3.1 deleted"
 action 003 cli command "exit"

Проверить состояние track: 

r1#sh track
Track 10
  Stub-object
  State is Up
    14 changes, last change 00:00:02, by EEM
  Tracked by:
    STATIC-IP-ROUTING 0

И маршруты, к которым привязан track: 

r1#sh ip route track-table
 ip route 0.0.0.0 0.0.0.0 190.16.3.1 track 10 state is [up]

Пример использования stub track

Будет два сценария.

Один сценарий будет реагировать на высокую загрузку интерфейса: 

event manager applet TXload_high
 event interface name FastEthernet0/1 parameter txload entry-op gt entry-val 200 entry-type value poll-interval 10
 action 001 track set 10 state up
 action 002 cli command "exit"

В этом сценариии у нас новое событие event interface:

    • name FastEthernet0/1 - нас интересует статистика интерфейса Fa0/1
    • parameter txload - сценарий будет считывать параметр TX-загрузка
    • entry-op gt entry-val 200 entry-type value - мы считываем мараметр txload и проверяем его значение, если оно больше 200, будут выполняться действия (у Cisco txload и rxload может принимать значение от 0 до 255)
    • poll-interval 10 - статистика проверяется каждые 10 секунд

Второй сценарий реагирует на понижение загрузки (если стала менее чем 100 из 255): 

event manager applet TXload_low
 event interface name FastEthernet0/1 parameter txload entry-op lt entry-val 100 entry-type value poll-interval 10
 action 001 track set 10 state down
 action 002 cli command "exit"

Соответственно, когда нагрузка на интерфейсе Fa0/1 повышается, поднимается маршрут.

Логика тут такая:

  • есть основной маршрут
  • он ведет через интерфейс Fa0/1
  • когда загрузка на этом интерфейсе сильно повышается, мы подниамем второй маршрут (к которому привязан трек)
  • и трафик балансируется между двумя маршрутами
  • тут важный момент, что когда подключится второй маршрут, трафик на основном интерфейсе в любом случае упадет. Поэтому надо осторожно поиграться со значениями параметров в этих двух скриптах.

Routing

NetFlow

event neighbor discovery

Событие neighbor-discovery позволяет реагировать на события протокола CDP.

При возникновении события CDP, EEM считывает информацию в переменные. Доступные переменные можно проверить так: 

r1#sh event manager detector neighbor-discovery detailed 
No.  Name                Version   Node        Type    
1    neighbor-discovery  01.00     node0/0     RP      

        Tcl Configuration Syntax: 
        ::cisco::eem::event_register_neighbor_discovery 
                 [tag <tag-val>] 
                 interface <interface-pattern> 
                 [cdp {add | update | delete | all}] 
                 [link-event {down|goingdown|init|testing|up|reset|admindown|deleted|all}] 
                 [line-event {up|down|all}] 
                 [queue_priority {normal | low | high | last}] 
                 [maxrun <sec.msec>]
                 [ratelimit <sec.msec>]
                 [nice {0 | 1}]
...
        Applet Built-in Environment Variables: 
        $_event_id
        $_job_id
        $_event_type
        $_event_type_string
        $_event_pub_time
        $_event_pub_sec
        $_event_pub_msec
        $_event_severity
        COMMON VARIABLES: 
        $_nd_notification 
        $_nd_intf_linkstatus 
        $_nd_intf_linestatus 
        $_nd_local_intf_name 
        $_nd_short_local_intf_name 
        $_nd_port_id 
        CDP EVENT VARIABLES: 
        $_nd_protocol 
        $_nd_proto_notif 
        $_nd_proto_new_entry 
        $_nd_cdp_entry_name 
        $_nd_cdp_hold_time 
        $_nd_cdp_mgmt_domain 
        $_nd_cdp_platform 
        $_nd_cdp_version 
        $_nd_cdp_capabilities_string 
        $_nd_cdp_capabilities_bits 
        $_nd_cdp_capabilities_bits_[0-31]

Пример сценария, который на основе информации из сообщений CDP, прописывает описание интерфейсов: 

event manager applet update-int-desc
 event neighbor-discovery interface regexp .*Ethernet.* cdp add 
 action 1.0 cli command "enable"
 action 2.0 cli command "config t"
 action 3.0 cli command "interface $_nd_local_intf_name"
 action 4.0 cli command "description To $_nd_cdp_entry_name $_nd_port_id"
 action 5.0 syslog msg "Description for $_nd_local_intf_name changed to $_nd_cdp_entry_name $_nd_port_id"
 action 6.0 cli command "end"
 action 7.0 cli command "exit"

В этом сценарии используются несколько переменных:

  • $_nd_local_intf_name - локальный интерфейс оборудования (на котором мы находимся). Нам он нужен чтобы перейти в соответствующий интерфейс для настройки
  • $_nd_cdp_entry_name - имя устройства (hostname + domain)
  • $_nd_port_id - интерфейс удаленного устройства

Источник сценария [1].

До выполнения сценария, описаний интерфейсов нет: 

r1#show int desc 
Interface                      Status         Protocol Description
Fa0/0                          up             up       
Fa0/1                          up             up       
Fa0/2                          up             up

Так как сценарий реагирует на добавление устройств по CDP, надо инициировать это событие.

В лабораторных условиях можно просто выключить и включить порты.

Но в реальной жизни лучше воспользоваться командой clear cdp table: 

r1#clear cdp table

После этого сценарий выполняется для двух интерфейсов: 

%HA_EM-6-LOG: update-int-desc: Description for FastEthernet0/0 changed to r5.xgu.ru FastEthernet0/0
%SYS-5-CONFIG_I: Configured from console by  on vty0 (EEM:update-int-desc)

%HA_EM-6-LOG: update-int-desc: Description for FastEthernet0/1 changed to sw1.xgu.ru FastEthernet0/1
%SYS-5-CONFIG_I: Configured from console by  on vty0 (EEM:update-int-desc)

На интерфейсах появилось описание: 

r1#show int desc 
Interface                      Status         Protocol Description
Fa0/0                          up             up       To r5.xgu.ru FastEthernet0/0
Fa0/1                          up             up       To sw1.xgu.ru FastEthernet0/1
Fa0/2                          up             up

Пример сценария EEM (advanced)

В сценарии выше есть несколько минусов:

  • в имени хоста остался домен, что, скорее всего, лишняя информация
  • имя порта хотелось бы сократить, например, до Fa0/1

Сценарий ниже использует более сложную логику и, не только исправляет перечисленные минусы, то и дополняет функционал:

  • проверяет существующее описание интерфейса и, если новое и старое описание одинаковые, описание не меняется
  • сообщение syslog оповещает о том изменилось описание или нет

Сценарий: 

event manager applet UPD-int-desc authorization bypass
 description "Auto-update port-description based on CDP neighbor info"
 event neighbor-discovery interface regexp .*Ethernet.* cdp add
 action 0.0  comment "Event line regexp: Deside which interface to auto-update description on"
 action 1.0  comment "Verify CDP neighbor to be Switch or Router"
 action 1.1  regexp "(Switch|Router|AIR)" "$_nd_cdp_capabilities_string"
 action 1.2  if $_regexp_result eq "1"
 action 2.0  comment "Trim domain name"
 action 2.1  regexp "^([^\.]+)" "$_nd_cdp_entry_name" match host
 action 3.0  comment "Convert long interface name to short"
 action 3.1  string first "Ethernet" "$_nd_port_id"
 action 3.2  if $_string_result eq "7"
 action 3.21 string replace "$_nd_port_id" 0 14 "Gi"
 action 3.3  elseif $_string_result eq 10
 action 3.31 string replace "$_nd_port_id" 0 17 "Te"
 action 3.4  elseif $_string_result eq 4
 action 3.41 string replace "$_nd_port_id" 0 11 "Fa"
 action 3.5  elseif $_string_result eq 0
 action 3.51 string replace "$_nd_port_id" 0 7 "Eth"
 action 3.6  end
 action 3.7  set int "$_string_result"
 action 4.0  comment "Check old description if any, and do no change if same host:int"
 action 4.1  cli command "enable"
 action 4.11 cli command "config t"
 action 4.2  cli command "do show interface $_nd_local_intf_name | incl Description:"
 action 4.21 set olddesc "<none>"
 action 4.22 set olddesc_sub1 "<none>"
 action 4.23 regexp "Description: ([a-zA-Z0-9:/\-]*)([a-zA-Z0-9:/\-\ ]*)" "$_cli_result" olddesc olddesc_sub1 
 action 4.24 if $olddesc_sub1 eq "$host:$int"
 action 4.25 syslog msg "EEM script did NOT change description on $_nd_local_intf_name, since remote host and interface is unchanged"
 action 4.26 exit 10
 action 4.27 end
 action 4.3  cli command "interface $_nd_local_intf_name"
 action 4.4  cli command "description $host:$int"
 action 4.5  cli command "do write"
 action 4.6  syslog msg "EEM script updated description on $_nd_local_intf_name from $olddesc to Description: $host:$int and saved config"
 action 5.0  end
 action 6.0  exit 1

Источник сценария (в статье сценарий немного изменен) [2].

Проверим работу сценария.

Сначала смотрим какие соседи обнаружились у маршрутизатора по протоколу CDP: 

r1#sh cdp n
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone, 
                  D - Remote, C - CVTA, M - Two-port Mac Relay 

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
r5               Fa 0/0            179              R    2811       Fa 0/0
sw1.xgu.ru       Fa 0/1            178             R S   3550       Fa 0/1

Проверяем подписи интерфейсов: 

r1#sh int desc
Interface                      Status         Protocol Description
Et0/0                          up             up       
Et0/1                          up             up       
Et0/2                          up             up

Теперь даем clear cdp table и наблюдаем за выполнением сценария: 

r1#clear cdp table 
r1#
%HA_EM-6-LOG: UPD-int-desc: EEM script updated description on FastEthernet0/1 from <none> to Description: sw1:Fa0/1 and saved config
r1#
%HA_EM-6-LOG: UPD-int-desc: EEM script updated description on FastEthernet0/0 from <none> to Description: r5:Fa0/0 and saved config

Проверяем описание: 

r1#sh int desc
Interface                      Status         Protocol Description
Fa0/0                          up             up       r5:Fa0/0
Fa0/1                          up             up       sw1:Fa0/1
Fa0/2                          up             up

Обратите внимание, что, хотя r5 был без имени домена, а sw1 с именем домена, в описании интерфейсов, в обоих случаях осталось только имя.

Теперь посмотрим как реагирует сценарий на изменения.

Добавим имя домена на маршрутизатор r5 и посмотрим как реагирует сценарий: 

%HA_EM-6-LOG: UPD-int-desc: EEM script did NOT change description on FastEthernet0/0, since remote host and interface is unchanged

В данном случае, описание не меняется, так как, хотя и добавилось имя домена, в описании мы его удаляем, поэтому оно не поменялось.

event timer

У события timer есть несколько разновидностей:

  • absolute
  • countdown
  • watchdog
  • cron

event timer countdown

С помощью события timer countdown можно сделать сценарий, который будет запускаться через определенное время, каждый раз после перезагрузки.

Например, если в сценарии прописано событие вида: 

event timer countdown time 20

То сценарий запустится через 20 секунд.

Сценарий запускается после перезагрузки, потому что конфигурация каждый раз применяется при старте. И отсчет начинается заново.

Note:

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

Если это критично (в указанном примере, это не важно), можно решить вопрос добавив сценарий в стартовую конфигурацию (скопировать стартовый конфиг, добавить туда сценарий, а затем скопировать назад).

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

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

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

event manager applet IntfDown
  description Shutdown LAN int G0/0/2 and bridge-domain 301 on router start
  event syslog pattern "SYS-5-RESTART"
  action 001 cli command "enable"
  action 002 cli command "config t"
  action 003 cli command "interface g0/0/2"
  action 004 cli command "shutdown"
  action 005 cli command "bridge-domain 301"
  action 006 cli command "shutdown"
  action 007 syslog msg "LAN interface g0/0/2 and BD 301 is temporary shutdown"
  action 008 cli command "end"
  action 009 cli command "exit"

event manager applet IntfUp
  description Enable LAN int G0/0/2 and bridge-domain 301 after 80 sec
  event timer countdown time 80
  action 001 cli command "enable"
  action 002 cli command "config t"
  action 003 cli command "interface g0/0/2"
  action 004 cli command "no shutdown"
  action 005 cli command "bridge-domain 301"
  action 006 cli command "no shutdown"
  action 007 syslog msg "LAN interface g0/0/2 and BD 301 is UP"
  action 008 cli command "end"
  action 009 cli command "exit"

event timer watchdog

Событие timer watchdog позволяет выполнять действия с определенной периодичностью.

Например, этот скрипт будет очищать счетчики интерфейсов каждый час: 

 event manager applet CLEAR
  description Clear interface counters every hour
  event timer watchdog time 3600
  action 001 cli command "enable"
  action 002 cli command "clear counters" pattern "confirm"
  action 003 cli command "y"
  action 004 syslog msg "All counters cleared"
  action 005 cli command "exit"

event timer cron

Событие timer cron позволяет запускать сценарий в определенное время.

В событии timer cron можно указывать такие 5 значений:

  • минуты (0-59)
  • часы (0-23)
  • день месяца (1-31)
  • месяц (1-12)
  • день недели (0-6)

Например, этот сценарий будет запускаться каждый рабочий день в 6 утра: 

event manager applet CRON
 event timer cron cron-entry "0 6 * * 1-5"
 action 001 cli command "enable"
 action 002 syslog msg "6 AM! Time to get up"
 action 003 cli command "exit"

Test

Watchdog System Monitor

EEM Actions

В EEM есть такие действия:

  • cli
  • file
  • info
  • mail
  • policy
  • reload
  • snmp-trap
  • syslog
  • track

Встроенные переменные

При написании сценариев EEM, можно использовать встроенные переменные для различных событий.

Посмотреть какие встроенные переменные существуют для события можно с помощью команды: 

sh event manager detector <event detector> detailed

R3#sh event manager detector interface detailed  | b Applet
        Applet Configuration Syntax: 
        [ no ] event [tag <tag-val>] interface 
                 name <interface-name>
                 parameter <counter-name>
                 poll-interval <sec.msec>
                 entry-val <entry-val>
                 entry-op {gt | ge | eq | ne | lt | le}
                 entry-type {value | increment | rate}
                 [exit-comb {or | and}]
                 [exit-val <exit-val>
                  exit-op {gt | ge | eq | ne | lt | le}
                  exit-type {value | increment | rate}]
                 [exit-time <sec.msec>]
                 [exit-event {false | true}]
                 [average-factor <average-factor-val>]
                 [maxrun <sec.msec>]
                 [ratelimit <sec.msec>]

        Applet Built-in Environment Variables: 
        $_event_id
        $_job_id
        $_event_type
        $_event_type_string
        $_event_pub_time
        $_event_pub_sec
        $_event_pub_msec
        $_event_severity
        $_interface_name 
        $_interface_parameter 
        $_interface_is_increment 
        $_interface_value 
        $_interface_delta_value 
        $_interface_exit_event

Примеры использования

Изменение конфигурации удаленного устройства

Часто бывает так, что настройка выполняется на удаленном устройстве. И иногда нет возможности перенастроить устройство не потеряв доступ к нему. Один из вариантов решения проблемы, это использование EEM.

Например, в этом случае, надо перенастроить BGP и выполнить такие команды: 

no router bgp 1111

router bgp 3333
 bgp log-neighbor-changes
 neighbor 70.10.5.105 remote-as 3333
 neighbor 70.10.5.105 description MyISP-SUPERISP
 neighbor 70.10.5.105 transport path-mtu-discovery
 neighbor 70.10.5.105 update-source Port-channel1.74
 neighbor 70.10.5.165 remote-as 3333
 neighbor 70.10.5.165 description MyISP-BESTISP
 neighbor 70.10.5.165 transport path-mtu-discovery
 neighbor 70.10.5.165 update-source Port-channel1.64
 address-family ipv4
  network 53.151.88.0 mask 255.255.248.0
  network 53.151.88.0 mask 255.255.252.0
  network 53.151.92.0 mask 255.255.252.0
  network 53.152.224.0 mask 255.255.224.0
  network 53.152.224.0 mask 255.255.248.0
  network 53.152.224.0 mask 255.255.252.0
  network 53.152.228.0 mask 255.255.252.0
  network 53.152.232.0 mask 255.255.248.0
  network 53.152.232.0 mask 255.255.252.0
  network 53.152.236.0 mask 255.255.252.0
  network 53.152.240.0 mask 255.255.248.0
  network 53.152.240.0 mask 255.255.252.0
  network 53.152.244.0 mask 255.255.252.0
  network 53.152.244.0 mask 255.255.254.0
  network 53.152.246.0 mask 255.255.254.0
  network 53.152.248.0 mask 255.255.248.0
  network 53.152.248.0 mask 255.255.252.0
  network 53.152.252.0 mask 255.255.252.0
  neighbor 70.10.5.105 activate
  neighbor 70.10.5.105 send-community
  neighbor 70.10.5.105 soft-reconfiguration inbound
  neighbor 70.10.5.105 prefix-list SUPERISP-OUT out
  neighbor 70.10.5.105 route-map COMMUNITYMAP out
  neighbor 70.10.5.165 activate
  neighbor 70.10.5.165 send-community
  neighbor 70.10.5.165 soft-reconfiguration inbound
  neighbor 70.10.5.165 prefix-list MyISP-BESTISP-OUT out
  neighbor 70.10.5.165 route-map COMMUNITYMAP out
  maximum-paths 4
 exit-address-family
ip bgp-community new-format

Если нет никаких способов выполнить эти настройки не потеряв связь, то можно использовать скрипт EEM: 

event manager applet CONFIG
 event none
 action 0001 cli command "en"
 action 0002 cli command "conf t"
 action 0003 cli command "no router bgp 1111"
 action 0004 cli command "router bgp 3333"
 action 0005 cli command " bgp log-neighbor-changes"
 action 0006 cli command " neighbor 70.10.5.105 remote-as 3333"
 action 0007 cli command " neighbor 70.10.5.105 description MyISP-SUPERISP"
 action 0008 cli command " neighbor 70.10.5.105 transport path-mtu-discovery"
 action 0009 cli command " neighbor 70.10.5.105 update-source Port-channel1.74"
 ...

Запустить его можно вручную: 

router# event manager run CONFIG

Icon-caution.gif

Скрипт желательно проверить заранее на тестовом устройстве. Даже после проверки лучше прежде чем выполнять скрипт подстраховаться перезагрузкой.

Например, установить перезагрузку через 10 минут: reload in 10. Если скрипт не отработает, то маршрутизатор перезагрузится и вернется прежняя конфигурация.

Вспомогательный скрипт python для генерирования действий в скрипте EEM

Когда команд надо выполнить много, то не очень удобно набирать все их в скрипте, дописывая каждый раз впереди action 000x cli command.

Тем более, что часто перечень команд сочиняется не на лету, а используется после предварительных тестов.

То есть, есть перечень команд, которые надо выполнить скриптом EEM. И не хочется копировать их руками.

Этот небольшой скрипт Python, на основании переданного ему как параметра, имени файла где хранятся строки конфигурации для скрипта EEM, генерирует строки вида action 000x cli command: 

import sys

config = sys.argv[1]

with open(config, 'r') as file:
    for (i, command) in enumerate(file, 1):
        print 'action %04d cli command "%s"' % (i, command.rstrip())

Файл с командами: 

Nata$ cat test_conf 
en
conf t
no router bgp 1111
router bgp 3333
 bgp log-neighbor-changes
 neighbor 70.10.5.105 remote-as 3333
 neighbor 70.10.5.105 description MyISP-SUPERISP
 neighbor 70.10.5.105 transport path-mtu-discovery
 neighbor 70.10.5.105 update-source Port-channel1.74
 ...

Пример использования: 

Nata$ python eem.py test_conf
action 0001 cli command "en"
action 0002 cli command "conf t"
action 0003 cli command "no router bgp 1111"
action 0004 cli command "router bgp 3333"
action 0005 cli command " bgp log-neighbor-changes"
action 0006 cli command " neighbor 70.10.5.105 remote-as 3333"
action 0007 cli command " neighbor 70.10.5.105 description MyISP-SUPERISP"
action 0008 cli command " neighbor 70.10.5.105 transport path-mtu-discovery"
action 0009 cli command " neighbor 70.10.5.105 update-source Port-channel1.74"
...

Дополнительная информация

{{Навигационная таблица |имя = Cisco |state = collapsed |заголовок = Cisco Systems, Inc. |стиль_основного_заголовка = background:#dcf0ff;padding-top:3pt;padding-bottom:3pt;font-size:120%; |стиль_заголовков = background:#dcf0ff;padding-top:2pt;padding-bottom:2pt;font-size:105%; |стиль_нечетных = |стиль_четных = background:#f0f0f0;

|заголовок1 = Устройства |список1 = Cisco 871Шаблон:* Cisco RouterШаблон:* Cisco SwitchШаблон:* Сisco Сatalyst Шаблон:* Cisco IPSШаблон:* Cisco ASAШаблон:* PIXШаблон:* Dynamips

|заголовок2 = Безопасность
(коммутаторы и
маршрутизаторы) |список2 = Cisco SecurityШаблон:* Port securityШаблон:* DHCP snoopingШаблон:* Dynamic ARP ProtectionШаблон:* IP Source GuardШаблон:* Аутентификация при доступе к сетиШаблон:* 802.1X в CiscoШаблон:* Zone-Based Policy FirewallШаблон:* Cisco NATШаблон:* NAT в Cisco Шаблон:* Cisco SSH

|заголовок3 = Cisco ASA |список3 = Cisco ASA/NATШаблон:* Cisco ASA/TroubleshootingШаблон:* Cisco ASA/IPSШаблон:* Cisco ASA failoverШаблон:* Cisco ASA/Transparent firewallШаблон:* Cisco ASA/Site-to-Site_VPNШаблон:* Cisco ASA/Easy_VPNШаблон:* Cisco ASA/WebVPNШаблон:* Объединение OSPF-сетей туннелем между двумя системами ASA (без GRE)Шаблон:* Центр сертификатов на Cisco ASA

|заголовок4 = VPN |список4 = IPsec в CiscoШаблон:* Cisco IOS Site-to-Site VPN Шаблон:* DMVPN Шаблон:* Cisco Easy VPNШаблон:* Cisco Web VPNШаблон:* Cisco ipsec preshared

Источник — https://noname.com.ua/mediawiki/index.php?title=Cisco-EEM&oldid=13542