Cisco-EEM: различия между версиями
Sirmax (обсуждение | вклад) |
Sirmax (обсуждение | вклад) |
||
| (не показана 1 промежуточная версия этого же участника) | |||
| Строка 1: | Строка 1: | ||
[[Категория:Неоконченные страницы]] |
[[Категория:Неоконченные страницы]] |
||
[[Категория:Cisco]] |
[[Категория:Cisco]] |
||
| + | [[Категория:Cisco Embedded Event Manager]] |
||
| + | [[Категория:EEM]] |
||
| + | =Cisco Embedded Event Manager= |
||
{{caution|text=Статья целиком скопирована с http://xgu.ru/wiki/Embedded_Event_Manager c целью дальнейшей доработки и исследования |
{{caution|text=Статья целиком скопирована с http://xgu.ru/wiki/Embedded_Event_Manager c целью дальнейшей доработки и исследования |
||
}} |
}} |
||
Текущая версия на 16:33, 24 июля 2024
Cisco Embedded Event Manager
|
|
Статья целиком скопирована с http://xgu.ru/wiki/Embedded_Event_Manager c целью дальнейшей доработки и исследования |
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
За событием следуют действия. У каждого действия есть свой порядковый номер. События выполняются и сортируются по номеру.
Так как в EEM используется лексикографический порядок, важно обратить внимание, что, если есть действия с нумерацией от 1 до 11, то порядок будет таким: 1,10,11,2... Чтобы действия правильно сортировались, надо либо дописывать вначале нули, либо нумеровать действия так: 1.1, 1.2, 1.3 (что к тому же позволяет группировать действия по логике выполнения).
|
|
Очень важный момент в работе 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. И запустить сценарий.
Конечно же, желательно проверить его работу заранее на тестовом оборудовании или виртуалках. И даже после проверки стоит поставить заранее перезагрузку, на тот случай, если вы не учли какой-то момент и после отработки сценария, связь потеряется
Также событие 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.
Обратите внимание на разницу:
- '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 в том, что он может влияет на другие объекты в конфигурации.
Обратите внимание, что по сути, можно было бы и без 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 секунд.
Сценарий запускается после перезагрузки, потому что конфигурация каждый раз применяется при старте. И отсчет начинается заново.
Нюанс этого события в том, что сценарий запустится через 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
- 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
|
|
Скрипт желательно проверить заранее на тестовом устройстве. Даже после проверки лучше прежде чем выполнять скрипт подстраховаться перезагрузкой. Например, установить перезагрузку через 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" ...
Дополнительная информация
- EEM tutorial
- How-to get notifications for IP SLA monitor using EEM
- Tclsh on Cisco IOS tutorial (NIL wiki)
- EEM examples
- EEM Demystified, part 1 (INE)
- Примеры использования
- Cisco IOS Embedded Event Manager (EEM)
- как определить версию EEM
- Configuration Guide
- Документация по Tcl
- Cisco EEM Best Practices
- EEM Built-in "Action" Variables
- Automatically Set Port Descriptions
{{Навигационная таблица |имя = 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
