-
Cisco IOS High Availability Command Reference
-
Introduction
-
action cli through configure replace
-
control-plane through debug mpls ldp checkpoint
-
debug mpls ldp graceful-restart through event wdsysmon
-
frame-relay redundancy auto-sync lmi-sequence-numbers through issu set rollback-timer
-
match mpls-label through route-target
-
service call-home through show ip pim interface
-
show ip pim neighbor through show ppp subscriber statistics
-
show pppatm statistics through vrrp timers learn
-
Table Of Contents
debug mpls ldp graceful-restart
debug mpls traffic-eng lsd-client
event manager scheduler script
event manager scheduler suspend
event manager session cli username
debug mpls ldp graceful-restart
To display debugging information for Multiprotocol (MPLS) Label Distribution Protocol (LDP) stateful switchover (SSO) nonstop forwarding (NSF) support and Graceful Restart, use the debug mpls ldp graceful-restart command in privileged EXEC mode. To disable the display of this debugging information, use the no form of this command.
debug mpls ldp graceful-restart
no debug mpls ldp graceful-restart
Syntax Description
This command has no arguments or keywords.
Defaults
The display of debugging information is not enabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command shows events and errors related to LDP Graceful Restart.
Examples
The following example shows sample output from the debug mpls ldp graceful-restart command. The output shows that a session was lost. The status message show the events that happen during recovery of the bindings.
Router# debug mpls ldp graceful-restartLDP GR: GR session 10.110.0.10:0:: lostLDP GR: down nbr 10.110.0.10:0:: created [1 total]LDP GR: GR session 10.110.0.10:0:: bindings retainedLDP GR: down nbr 10.110.0.10:0:: added all 7 addresses [7 total]LDP GR: down nbr 10.110.0.10:0:: state change (None -> Reconnect-Wait)LDP GR: down nbr 10.110.0.10:0:: reconnect timer started [120000 msecs]LDP GR: down nbr 10.110.0.10:0:: added to bindings task queue [1 entries]LDP GR: searching for down nbr record (10.110.0.10:0, 10.2.0.10)LDP GR: search for down nbr record (10.110.0.10:0, 10.2.0.10) returned 10.110.0.10:0LDP GR: Added FT Sess TLV (Rconn 120000, Rcov 120000) to INIT msg to 10.110.0.10:0LDP GR: Tagcon querying for up to 12 bindings update tasksLDP GR: down nbr 10.110.0.10:0:: requesting bindings MARK for {10.110.0.10:0, 1}LDP GR: down nbr 10.110.0.10:0:: removed from bindings task queue [0 entries]LDP GR: Requesting 1 bindings update tasks [0 left in queue]LDP GR: 10.1.0.0/8:: updating binding from 10.110.0.10:0, inst 1:: marking stale;LDP GR: 10.2.0.0/16:: updating binding from 10.110.0.10:0, inst 1:: marking stale;LDP GR: 10.0.0.14/32:: updating binding from 10.110.0.10:0, inst 1:: marking stale;LDP GR: searching for down nbr record (10.110.0.10:0, 10.2.0.10)LDP GR: search for down nbr record (10.110.0.10:0, 10.2.0.10) returned 10.110.0.10:0LDP GR: Added FT Sess TLV (Rconn 120000, Rcov 120000) to INIT msg to 10.110.0.10:0LDP GR: searching for down nbr record (10.110.0.10:0, 10.2.0.10)LDP GR: search for down nbr record (10.110.0.10:0, 10.2.0.10) returned 10.110.0.10:0LDP GR: Added FT Sess TLV (Rconn 120000, Rcov 120000) to INIT msg to 10.110.0.10:0LDP GR: searching for down nbr record (10.110.0.10:0, 10.2.0.10)LDP GR: search for down nbr record (10.110.0.10:0, 10.2.0.10) returned 10.110.0.10:0LDP GR: Added FT Sess TLV (Rconn 120000, Rcov 120000) to INIT msg to 10.110.0.10:0LDP GR: searching for down nbr record (10.110.0.10:0, 10.2.0.10)LDP GR: search for down nbr record (10.110.0.10:0, 10.2.0.10) returned 10.110.0.10:0LDP GR: Added FT Sess TLV (Rconn 120000, Rcov 120000) to INIT msg to 10.110.0.10:0LDP GR: searching for down nbr record (10.110.0.10:0, 10.2.0.10)LDP GR: search for down nbr record (10.110.0.10:0, 10.2.0.10) returned 10.110.0.10:0LDP GR: Added FT Sess TLV (Rconn 120000, Rcov 120000) to INIT msg to 10.110.0.10:0LDP GR: Received FT Sess TLV from 10.110.0.10:0 (fl 0x1, rs 0x0, rconn 120000, rcov 120000)LDP GR: GR session 10.110.0.10:0:: allocated instance, 2LDP GR: GR session 10.110.0.10:0:: establishedLDP GR: GR session 10.110.0.10:0:: found down nbr 10.110.0.10:0LDP GR: down nbr 10.110.0.10:0:: reconnect timer stoppedLDP GR: down nbr 10.110.0.10:0:: state change (Reconnect-Wait -> Recovering)LDP GR: down nbr 10.110.0.10:0:: recovery timer started [120000 msecs]%LDP-5-GR: GR session 10.110.0.10:0 (inst. 2): starting graceful recovery%LDP-5-NBRCHG: LDP Neighbor 10.110.0.10:0 is UPLDP GR: 10.1.0.0//8:: refreshing stale binding from 10.110.0.10:0, inst 1 -> inst 2LDP GR: 10.43.0.0//16:: refreshing stale binding from 10.110.0.10:0, inst 1 -> inst 2LDP GR: down nbr 10.110.0.10:0:: recovery timer expired%LDP-5-GR: GR session 10.110.0.10:0 (inst. 2): completed graceful recoveryLDP GR: down nbr 10.110.0.10:0:: destroying record [0 left]LDP GR: down nbr 10.110.0.10:0:: state change (Recovering -> Delete-Wait)LDP GR: down nbr 10.110.0.10:0:: added to bindings task queue [1 entries]LDP GR: Tagcon querying for up to 12 bindings update tasksLDP GR: down nbr 10.110.0.10:0:: requesting bindings DEL for {10.110.0.10:0, 1}LDP GR: down nbr 10.110.0.10:0:: removed from bindings task queue [0 entries]LDP GR: Requesting 1 bindings update tasks [0 left in queue]LDP GR: GR session 10.110.0.10:0:: released instance, 1The debug output is formatted in three general ways.
•
LDP GR: GR session 10.110.0.10:0:: found down nbr 10.110.0.10:0
•
•
Table 18 describes the fields for the debug command output.
:
Related Commands
show mpls ldp graceful-restart
Displays a summary of the LDP Graceful Restart status.
debug mpls traffic-eng lsd-client
To display the Application Programming Interface (API) messages sent to the Label Switching Database (LSD) from the Traffic Engineering (TE) client, use the debug mpls traffic-eng lsd-client command in privileged EXEC mode. To disable the display of these messages, use the no form of this command.
debug mpls traffic-eng lsd-client
no debug mpls traffic-eng lsd-client
Syntax Description
This command has no arguments or keywords.
Defaults
Debugging is not enabled.
Command Modes
Privileged EXEC
Command History
Examples
The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command and enable TE globally:
00:10:23: TE-LSD-CLIENT: register with LSD OK; conn_id = 23, recov time = 60000 s00:10:23: TE-LSD-CLIENT: LSD is now upThe following messages are displayed when you issue the debug mpls traffic-eng lsd-client command and disable TE globally:
00:09:50: TE-LSD-CLIENT: unregister LSD client; result = OK; conn_id 23The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command and enable TE on specific interfaces on Cisco 7500 series routers:
00:10:23: TE-LSD-CLIENT: enabled TE LSD client on Ethernet1/0; status = OK00:10:23: TE-LSD-CLIENT: enabled TE LSD client on Serial2/0; status = OK00:10:23: TE-LSD-CLIENT: enabled TE LSD client on Serial3/0; status = OKThe following messages are displayed when you issue the debug mpls traffic-eng lsd-client command and disable TE on specific interfaces on Cisco 7500 series routers:
00:09:50: TE-LSD-CLIENT: disabled TE LSD client on Ethernet1/0; status = OK00:09:50: TE-LSD-CLIENT: disabled TE LSD client on Serial2/0; status = OK00:09:50: TE-LSD-CLIENT: disabled TE LSD client on Serial3/0; status = OKThe following messages are displayed when you issue the debug mpls traffic-eng lsd-client command and enable TE on specific interfaces on Cisco 10000 series routers:
00:10:23: TE-LSD-CLIENT: enabled TE LSD client on GigabitEthernet1/0/0; status = OK00:10:23: TE-LSD-CLIENT: enabled TE LSD client on Serial2/0/0; status = OK00:10:23: TE-LSD-CLIENT: enabled TE LSD client on Serial3/0/0; status = OKThe following messages are displayed when you issue the debug mpls traffic-eng lsd-client command and disable TE on specific interfaces on Cisco 10000 series routers:
00:09:50: TE-LSD-CLIENT: disabled TE LSD client on GigabitEthernet1/0/0; status = OK00:09:50: TE-LSD-CLIENT: disabled TE LSD client on Serial2/0/0; status = OK00:09:50: TE-LSD-CLIENT: disabled TE LSD client on Serial3/0/0; status = OKThe following messages are displayed when you issue the debug mpls traffic-eng lsd-client command, allocate labels on tunnel midpoints, and create tunnel midpoint rewrites on Cisco 7500 series routers:
00:14:04: TE-LSD-CLIENT: label alloc OK; label = 16, conn_id = 2300:14:04: TE-LSD-CLIENT: Create TE mid rewrite for 10.100.100.100 1 [5], Result: OK00:14:04: In: Serial3/0, 16 Out: Serial2/0, 3The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command, allocate labels on tunnel midpoints, and create tunnel midpoint rewrites on a Cisco 10000 series router:
00:14:04: TE-LSD-CLIENT: label alloc OK; label = 16, conn_id = 2300:14:04: TE-LSD-CLIENT: Create TE mid rewrite for 10.100.100.100 1 [5], Result: OK00:14:04: In: Serial3/0/0, 16 Out: Serial2/0/0, 3The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command, free labels on tunnel midpoints, and delete tunnel midpoints on a Cisco 7500 series router:
00:13:13: TE-LSD-CLIENT: Delete TE mid rewrite for iou-100_t1, Result: OK00:13:13: In: Serial3/0, 16 Out: Serial2/0, 100:13:13: TE-LSD-CLIENT: free label 16 result = OK; conn_id = 23The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command, free labels on tunnel midpoints, and delete tunnel midpoints on a Cisco 10000 series router:
00:13:13: TE-LSD-CLIENT: Delete TE mid rewrite for iou-100_t1, Result: OK00:13:13: In: Serial3/0/0, 16 Out: Serial2/0/0, 100:13:13: TE-LSD-CLIENT: free label 16 result = OK; conn_id = 23The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command and create tunnel headend rewrites on a Cisco 7500 series router:
00:09:10: TE-LSD-CLIENT: Create TE he rewrite for iou-100_t1, Result = OK00:09:10: tun_inst: 7 Out: Serial3/0, 16 Dest: 10.0.0.2ps_flags: 0x60003The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command and create tunnel headend rewrites on a Cisco 10000 series router:
00:09:10: TE-LSD-CLIENT: Create TE he rewrite for iou-100_t1, Result = OK00:09:10: tun_inst: 7 Out: Serial3/0/0, 16 Dest: 10.0.0.2ps_flags: 0x60003The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command and delete tunnel headend rewrites on a Cisco 7500 series router:
00:09:15: TE-LSD-CLIENT: Delete TE he rewrite for iou-100_t1, Result: OK00:09:15: tun_inst: 7 Out: Serial3/0, 16 ps_flags: 0x60003The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command and delete tunnel headend rewrites on a Cisco 10000 series router:
00:09:15: TE-LSD-CLIENT: Delete TE he rewrite for iou-100_t1, Result: OK00:09:15: tun_inst: 7 Out: Serial3/0/0, 16 ps_flags: 0x60003Related Commands
debug mpls vpn ha
To enable the display of Virtual Private Network (VPN) high availability (HA) debugging information, use the debug mpls vpn ha command in privileged EXEC mode. To disable the display of VPN HA debugging information, use the no form of this command.
debug mpls vpn ha
no debug mpls vpn ha
Syntax Description
This command has no arguments or keywords.
Defaults
VPN HA debugging is not enabled.
Command Modes
Privileged EXEC
Command History
12.2(33)SRA
This command was introduced.
12.2(31)SB
This command was integrated into Cisco IOS Release 12.2(31)SB.
Examples
The following example shows sample output from the debug mpls vpn ha command:
Router# debug mpls vpn haVPN HA debugging is on.debug ppp redundancy
To debug PPP synchronization on the networking device, use the debug ppp redundancy command in privileged EXEC mode. To disable the display of debugging output, use the no form of this command.
debug ppp redundancy [detailed | event]
no debug ppp redundancy [detailed | event]
Syntax Description
Command Modes
Privileged EXEC
Command History
Examples
The following example displays detailed debug messages related to specified PPP redundancy events:
Router# debug ppp redundancy detaileddebug pppatm redundancy
To debug PPP over ATM (PPPoA) redundancy events on a dual route processor, high availability (HA) system and display Cluster Control Manager (CCM) events and messages, use the debug pppatm redundancy command in privileged EXEC mode. To disable the display of debugging output, use the no form of this command.
debug pppatm redundancy
no debug pppatm redundancy
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The CCM provides the capability to facilitate and synchronize session bring up on the standby processor of a dual route processor HA system. Use the debug pppatm redundancy command to display CCM events and messages for PPPoA sessions on HA systems.
Note
This command is used only by Cisco engineers for internal debugging of CCM processes.
Examples
The following is sample output for the debug pppatm redundancy command from a Cisco 10000 Series router standby processor. No field descriptions are provided because command output is used for Cisco internal debugging purposes only.
Router# debug pppatm redundancy*Dec 3 02:58:40.784: PPPATM HA: [14000001]: Received the first SHDB*Dec 3 02:58:40.784: PPPATM HA: [14000001]: Base hwidb not created > yet, queuing SHDB *Dec 3 02:58:40.784: PPPATM HA: [14000001]:Requesting base vaccess creationdebug pppoe redundancy
To debug PPP over Ethernet (PPPoE) redundancy events on a dual Route Processor high availability (HA) system and display cluster control manager (CCM) events and messages, use the debug pppoe redundancy command in privileged EXEC mode. To disable the display of debugging output, use the no form of this command.
debug pppoe redundancy
no debug pppoe redundancy
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
12.2(31)SB2
This command was introduced.
12.2(33)SRC
This command was integrated into Cisco IOS Release 12.2(33)SRC.
Usage Guidelines
The CCM provides the capability to facilitate and synchronize session initiation on the standby processor of a dual route processor HA system. Use the debug pppoe redundancy command to display CCM events and messages for PPPoE sessions. This command is used only by Cisco engineers for internal debugging of CCM processes.
Examples
The following is sample output from the debug pppoe redundancy command from a Cisco 10000 series router active processor. No field descriptions are provided because command output is used for Cisco internal debugging purposes only.
Router# debug pppoe redundancyNov 22 17:21:11.327: PPPoE HA[0xBE000008] 9: Session ready to sync dataNov 22 17:21:11.351: PPPoE HA[0xBE000008] 9: code = PADR, length = 58Nov 22 17:21:11.351: PPPoE HA[0xBE000008] 9: code = SESSION ID, length = 2Nov 22 17:21:11.351: PPPoE HA[0xBE000008] 9: code = SWITCH HDL, length = 4Nov 22 17:21:11.351: PPPoE HA[0xBE000008] 9: code = SEGMENT HDL, length = 4Nov 22 17:21:11.351: PPPoE HA[0xBE000008] 9: code = PHY SWIDB DESC, length = 20Nov 22 17:21:11.351: PPPoE HA[0xBE000008] 9: code = VACCESS DESC, length = 28Nov 22 17:21:11.351: PPPoE HA[0xBE000008] 9: Sync collection for ready eventsNov 22 17:21:11.351: PPPoE HA[0xBE000008] 9: code = PADR, length = 58Nov 22 17:21:11.351: PPPoE HA[0xBE000008] 9: code = SESSION ID, length = 2Nov 22 17:21:11.351: PPPoE HA[0xBE000008] 9: code = SWITCH HDL, length = 4Nov 22 17:21:11.351: PPPoE HA[0xBE000008] 9: code = SEGMENT HDL, length = 4Nov 22 17:21:11.351: PPPoE HA[0xBE000008] 9: code = PHY SWIDB DESC, length = 20Nov 22 17:21:11.351: PPPoE HA[0xBE000008] 9: code = VACCESS DESC, length = 28The following is sample output from the debug pppoe redundancy command from a Cisco 10000 series router standby processor:
Router# debug pppoe redundancyNov 22 17:21:11.448: PPPoE HA[0x82000008]: Recreating session: retrieving dataNov 22 17:21:11.464: PPPoE HA[0x82000008] 9: Session ready to sync dataThe following is sample output from the debug pppoe redundancy command from a Cisco 7600 series router active processor.
Router# debug pppoe redundancyDec 17 15:14:37.060: PPPoE HA[0x131B01B1] 28039: Session ready to sync dataDec 17 15:14:37.076: PPPoE HA[0x131B01B1] 28039: code = PADR, length = 48Dec 17 15:14:37.076: PPPoE HA[0x131B01B1] 28039: code = SESSION ID, length = 2Dec 17 15:14:37.076: PPPoE HA[0x131B01B1] 28039: code = SWITCH HDL, length = 4Dec 17 15:14:37.076: PPPoE HA[0x131B01B1] 28039: code = SEGMENT HDL, length = 4Dec 17 15:14:37.076: PPPoE HA[0x131B01B1] 28039: code = PHY SWIDB DESC, length = 20Dec 17 15:14:37.076: PPPoE HA[0x131B01B1] 28039: code = VACCESS DESC, length = 28Dec 17 15:14:37.076: PPPoE HA[0x131B01B1] 28039: Sync collection for ready eventsDec 17 15:14:37.076: PPPoE HA[0x131B01B1] 28039: code = PADR, length = 48Dec 17 15:14:37.076: PPPoE HA[0x131B01B1] 28039: code = SESSION ID, length = 2Dec 17 15:14:37.076: PPPoE HA[0x131B01B1] 28039: code = SWITCH HDL, length = 4Dec 17 15:14:37.076: PPPoE HA[0x131B01B1] 28039: code = SEGMENT HDL, length = 4Dec 17 15:14:37.076: PPPoE HA[0x131B01B1] 28039: code = PHY SWIDB DESC, length = 20Dec 17 15:14:37.076: PPPoE HA[0x131B01B1] 28039: code = VACCESS DESC, length = 28The following is sample output from the debug pppoe redundancy command from a Cisco 7600 series router standby processor:
Router# debug pppoe redundancyDec 17 15:14:37.180: STDBY: PPPoE HA[0xE41B019B]: Recreating session: retrieving dataDec 17 15:14:37.204: STDBY: PPPoE HA[0xE41B019B] 28039: Session ready to sync datadebug qos ha
To debug quality of service (QoS) information on the networking device, use the debug qos ha command in privileged EXEC mode. To disable the display of debugging output, use the no form of this command.
debug qos ha [detail]
no debug qos ha [detail]
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use to determine that QoS in running properly on your networking device.
Examples
The following example enables QoS debugging:
Router# debug qos hadebug redundancy
To enable the display of events for troubleshooting redundant dial shelf controllers (DSCs), use the debug redundancy command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug redundancy {all | ui | clk | hub}
no debug redundancy {all | ui | clk | hub}
Syntax Description
Command Default
The command is disabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command is issued from the router shelf console.
Examples
The output from this command consists of event announcements that can be used by authorized troubleshooting personnel.
debug redundancy (RP)
To enable the display of events for troubleshooting dual Route Processors (RPs), use the debug redundancy command in privileged EXEC mode. To disable the display of debugging output, use the no form of this command.
debug redundancy {ehsa | errors | fsm | kpa | msg | progression | status | timer}
no debug redundancy {ehsa | errors | fsm | kpa | msg | progression | status | timer}
Syntax Description
Command Modes
Privileged EXEC
Command History
Examples
The following example enables debugging information for RF keepalive events:
Router# debug redundancy kpadebug snmp sync
To debug Simple Network Management Protocol (SNMP) synchronization and faults in synchronization, use the debug snmp sync command in privileged EXEC mode. To disable the display of debugging output, use the no form of this command.
debug snmp sync
no debug snmp sync
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The debug snmp sync command can be used to debug SNMP synchronization and faults in synchronization. The standby Route Processor (RP) may sometimes reset as a result of synchronization faults. If the fault occurs when SNMP activities such as SNMP sets are in progress, enter the debug snmp sync command to identify whether a synchronization fault caused the reset.
SNMP synchronizations (dynamic and bulk) are performed only if the router is configured to be in stateful switchover (SSO) mode.
Examples
The following example enables debugging of SNMP synchronization activity:
Router# debug snmp syncRelated Commands
debug snmp packets
Displays information about every SNMP packet sent or received by the networking device.
mode
Configures the redundancy mode of operation.
debug standby events
To display events related to Hot Standby Router Protocol (HSRP), use the debug standby events command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug standby events [all | api | arp | ha | internal {data | init | state | timer} | protocol | redundancy | terse | track] [detail]
no debug standby events [all | arp | ha | internal {api | data | init | state | timer} | protocol | redundancy | terse | track] [detail]
Syntax Description
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
You can filter the debug output using interface and HSRP group conditional debugging. To enable interface conditional debugging, use the debug condition interface command. To enable HSRP conditional debugging, use the debug condition standby command.
Examples
The following example shows how to enable the debugging of the active and standby Route Processors (RPs) on an active RP console. The HSRP group is configured on the active RP, and the HSRP state is active.
Router# debug standby events ha!Active RP*Apr 27 04:13:47.755: HSRP: Gi0/0/1 Grp 101 RF Encode state Listen into sync buffer*Apr 27 04:13:47.855: HSRP: CF Sync send ok*Apr 27 04:13:57.755: HSRP: Gi0/0/1 Grp 101 RF Encode state Speak into sync buffer*Apr 27 04:13:57.855: HSRP: CF Sync send ok*Apr 27 04:14:07.755: HSRP: Gi0/0/1 Grp 101 RF Encode state Standby into sync buffer*Apr 27 04:14:07.755: HSRP: Gi0/0/1 Grp 101 RF Encode state Active into sync buffer*Apr 27 04:14:07.863: HSRP: CF Sync send ok*Apr 27 04:14:07.867: HSRP: CF Sync send ok!Standby RP*Apr 27 04:11:21.011: HSRP: RF CF client 32, entity 0 got msg len 24*Apr 27 04:11:21.011: HSRP: Gi0/0/1 Grp 101 RF sync state Init -> Listen*Apr 27 04:11:31.011: HSRP: RF CF client 32, entity 0 got msg len 24*Apr 27 04:11:31.011: HSRP: Gi0/0/1 Grp 101 RF sync state Listen -> Speak*Apr 27 04:11:41.071: HSRP: RF CF client 32, entity 0 got msg len 24*Apr 27 04:11:41.071: HSRP: RF CF client 32, entity 0 got msg len 24*Apr 27 04:11:41.071: HSRP: Gi0/0/1 Grp 101 RF sync state Speak -> Standby*Apr 27 04:11:41.071: HSRP: Gi0/0/1 Grp 101 RF sync state Standby -> ActiveTable 19 describes the significant fields shown in the display.
The following sample shows HSRP debug information when HSRP is configured to send gratuitous ARP packets every four seconds:
Router# debug standby event arp detailHSRP Events debugging is on (arp)*Jun 27 14:15:51.795: HSRP: Et0/0 Grp 1 Send grat ARP 10.0.0.1 mac 0000.0c07.ac01 (use vMAC)*Jun 27 14:15:55.755: HSRP: Et0/0 Grp 1 Send grat ARP 10.0.0.1 mac 0000.0c07.ac01 (use vMAC)*Jun 27 14:15:59.407: HSRP: Et0/0 Grp 1 Send grat ARP 10.0.0.1 mac 0000.0c07.ac01 (use vMAC)
Note
Table 20 describes the significant fields shown in the display.
The following examples show the output of the debug standby event internal init command when the IP address of an interface is changed and HSRP makes an internal evaluation to see if the added address permits the currently configured standby address to remain valid.
Router# debug standby events internal initHSRP: Ethernet0/0 vIP intf primary subnet 172.24.1.0 added...HSRP: Ethernet0/0 vIP 172.24.1.254 matches intf primary subnet 172.24.1.0Router# debug standby events internal initHSRP: Ethernet0/0 vIP intf secondary subnet 172.24.1.0 added...HSRP: Ethernet0/0 vIP 172.24.1.254 matches intf secondary subnet 172.24.1.0Router# debug standby events internal initHSRP: Ethernet0/0 vIP intf secondary subnet 172.24.1.0 deleted...HSRP: Ethernet0/0 vIP 172.24.1.254 matches no intf subnetsRelated Commands
debug vrrp all
To display debugging messages for Virtual Router Redundancy Protocol (VRRP) errors, events, and state transitions, use the debug vrrp all command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug vrrp all
no debug vrrp all
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
Examples
The following is sample output for the debug vrrp all command:
Router# debug vrrp all00:15:30: %IP-4-DUPADDR: Duplicate address 10.18.0.2 on Ethernet1/0, sourced by 0000.5e00.0101May 22 18:41:54.447: VRRP: Grp 1 Advertisement Primary address 10.18.0.2different from ours 10.18.0.1May 22 18:41:57.443: VRRP: Grp 1 Advertisement Primary address 10.18.0.2different from ours 10.18.0.1May 22 18:42:00.443: VRRP: Grp 1 Advertisement Primary address 10.18.0.2different from ours 10.18.0.1May 22 18:48:41.521: VRRP: Grp 1 Event - Advert higher or equal priorityMay 22 18:48:44.521: VRRP: Grp 1 Event - Advert higher or equal priorityMay 22 18:48:47.521: VRRP: Grp 1 Event - Advert higher or equal priorityMay 22 18:53:23.390: VRRP: Grp 1 changing to V_STATE_INITMay 22 18:54:26.143: VRRP: Grp 1 changing to V_STATE_BACKUPMay 22 18:54:35.755: VRRP: Grp 1 changing to V_STATE_MASTERMay 22 18:53:23.390: VRRP: Grp 1 changing to V_STATE_INITMay 22 18:54:26.143: VRRP: Grp 1 changing to V_STATE_BACKUPMay 22 18:54:35.755: VRRP: Grp 1 changing to V_STATE_MASTERRelated Commands
debug vrrp error
To display debugging messages about Virtual Router Redundancy Protocol (VRRP) error conditions, use the debug vrrp error command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug vrrp error
no debug vrrp error
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
Examples
The following is sample output from the debug vrrp error command:
Router# debug vrrp error00:15:30: %IP-4-DUPADDR: Duplicate address 10.18.0.2 on Ethernet1/0, sourced by 0000.5e00.0101May 22 18:41:54.447: VRRP: Grp 1 Advertisement Primary address 10.18.0.2different from ours 10.18.0.1May 22 18:41:57.443: VRRP: Grp 1 Advertisement Primary address 10.18.0.2different from ours 10.18.0.1May 22 18:42:00.443: VRRP: Grp 1 Advertisement Primary address 10.18.0.2different from ours 10.18.0.1In the example, the error being observed is that the router has a virtual address of 10.18.0.1 for group 1, but it received a virtual address of 10.18.0.2 for group 1 from another router on the same LAN.
Related Commands
debug vrrp all
Displays debugging messages for VRRP errors, events, and state transitions.
debug vrrp events
To display debugging messages about Virtual Router Redundancy Protocol (VRRP) events that are occurring, use the debug vrrp events command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug vrrp events
no debug vrrp events
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
Examples
The following is sample output from the debug vrrp events command:
Router# debug vrrp eventsMay 22 18:48:41.521: VRRP: Grp 1 Event - Advert higher or equal priorityMay 22 18:48:44.521: VRRP: Grp 1 Event - Advert higher or equal priorityMay 22 18:48:47.521: VRRP: Grp 1 Event - Advert higher or equal priorityIn the example, the event being observed is that the router received an advertisement from another router for group 1 that has a higher or equal priority to itself.
Related Commands
debug vrrp all
Displays debugging messages for VRRP errors, events, and state transitions.
debug vrrp packets
To display summary information about Virtual Router Redundancy Protocol (VRRP) packets being sent or received, use the debug vrrp packets command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug vrrp packets
no debug vrrp packets
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the debug vrrp packets command. The output is on the master virtual router; the router for group 1 is sending an advertisement with a checksum of 6BE7.
Router# debug vrrp packetsVRRP Packets debugging is onMay 22 18:51:03.220: VRRP: Grp 1 sending Advertisement checksum 6BE7May 22 18:51:06.220: VRRP: Grp 1 sending Advertisement checksum 6BE7In the following example, the router with physical address 10.18.0.3 is advertising a priority of 105 for VRRP group 1:
Router# debug vrrp packetsVRRP Packets debugging is onMay 22 18:51:09.222: VRRP: Grp 1 Advertisement priority 105, ipaddr 10.18.0.3May 22 18:51:12.222: VRRP: Grp 1 Advertisement priority 105, ipaddr 10.18.0.3debug vrrp state
To display debugging messages about the state transitions occurring for Virtual Router Redundancy Protocol (VRRP) groups, use the debug vrrp state command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug vrrp state
no debug vrrp state
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
Examples
The following is sample output from the debug vrrp state command:
Router# debug vrrp stateMay 22 18:53:23.390: VRRP: Grp 1 changing to V_STATE_INITMay 22 18:54:26.143: VRRP: Grp 1 changing to V_STATE_BACKUPMay 22 18:54:35.755: VRRP: Grp 1 changing to V_STATE_MASTERRelated Commands
debug vrrp all
Displays debugging messages for VRRP errors, events, and state transitions.
destination (call home)
To configure the message destination parameters, use the destination command in profile configuration mode.
destination {address {email address | http url} | message-size-limit size | preferred-msg-format {long-text | short-text | xml} | transport-method {email | http}}
Syntax Description
Command Default
The default settings are as follows:
•
•
•
•
Command Modes
Profile configuration
Command History
12.2(33)SXH
This command was introduced.
12.2(33)SRC
This command was integrated into Cisco IOS Release 12.2(33)SRC.
event application
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run on the basis of an event raised through the EEM Event Publish application programming interface (API), use the event application command in applet configuration mode. To remove the application event criteria, use the no form of this command.
event [tag event-tag] application subsystem subsystem-id type event-type [maxrun maxruntime-number]
no [tag event-tag] event application subsystem subsystem-id type event-type [maxrun maxruntime-number]
Syntax Description
Command Default
No EEM event criteria are specified.
Command Modes
Applet configuration (config-applet)
Command History
Usage Guidelines
An EEM event is triggered when an application calls the EEM Event Publish API with an event specification that matches the subsystem ID and application event type.
Examples
The following example shows how a policy named EventPublish_A runs every 20 seconds and publishes an event to a well-known EEM event type numbered 1. A second policy named EventPublish_B is registered to run when the well-known EEM event type of 1 occurs. When policy EventPublish_B runs, it outputs a message to syslog containing data passed as an argument from EventPublish_A.
Router(config)# event manager applet EventPublish_ARouter(config-applet)# event timer watchdog time 20.0Router(config-applet)# action 1.0 syslog msg "Applet EventPublish_A"Router(config-applet)# action 2.0 publish-event sub-system 798 type 1 arg1 twentyRouter(config-applet)# exitRouter(config)# event manager applet EventPublish_BRouter(config-applet)# event application subsystem 798 type 1Router(config-applet)# action 1.0 syslog msg "Applet EventPublish_B arg1 $_application_data1"Related Commands
event manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
event cli
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run by matching a Cisco IOS command-line interface (CLI) command, use the event cli command in applet configuration mode. To remove the CLI command event criteria, use the no form of this command.
event [tag event-tag] cli pattern regular-expression {[default] [enter] [questionmark] [tab]} [sync {yes | no skip {yes | no}] [mode variable] [occurs num-occurrences] [period period-value] [maxrun maxruntime-number]
no event [tag event-tag] cli
Syntax Description
Command Default
No EEM events are triggered on the basis of a match with a Cisco IOS CLI command.
Command Modes
Applet configuration (config-applet)
Command History
Usage Guidelines
Use the event cli command to set up event criteria against which CLI commands are matched. CLI commands are compared against a specified regular expression. After a specified number of matches occurs within a specified time period, an EEM event is triggered. If multiple conditions exist, the EEM event is triggered when all the conditions are met.
When the sync keyword is used, the event detector is notified when the policy completes running. The exit status of the policy determines whether the CLI command will be executed. If the policy exit status is zero—the policy ran successfully—the CLI command is not executed; otherwise the CLI command runs.
The EEM applet can accept four keywords to add CLI parser-based events. The behavior of these keywords are as follows:
•
•
•
•
Regular Expression Match
The CLI event detector screens CLI commands for a regular expression match. When a match is found, an event is published. The match logic is performed on the fully expanded CLI command after the command is successfully parsed and before it is executed. The CLI event detector supports three publish modes:
•
•
•
Examples
The following configuration will prevent you to access the configuration mode. If the _exit_status is not set to 1, the EEM policy will disable functionality in the router. To remove this configuration, you may need to reload with unsaved configuration. It is possible to remove the event applet but all unsaved configuration will be lost and a complete reconfiguration will be necessary.
event manager applet test_cli1event cli pattern "config" sync yesaction 1.0 syslog msg "Config command is entered"end
Caution
The following example shows how to specify an EEM applet to run when the Cisco IOS write memory CLI command is run. The applet provides a notification via a syslog message that this event has occurred. The _exit_status is set to 1.
Router(config)# event manager applet cli-matchRouter(config-applet)# event cli pattern "write memory.*" sync yesRouter(config-applet)# action 1.0 syslog msg "$_cli_msg Command Executed"Router(config-applet)# set 2.0 _exit_status 1The following example shows how unintended results can be produced when using the skip keyword followed by the yes keyword. When the skip keyword is followed by the yes keyword, unintended results may be produced if the pattern match is made for configuration commands because the CLI command that matches the regular expression will not be executed. In this example, the first applet (ap1) uses the skip keyword followed by the yes keyword to specify that any CLI command that contains the show ip interface pattern is not executed. This results in the second applet (ap2) being configured without an event statement because it contains the show ip interface pattern.
Router(config)# event manager applet ap1Router(config-applet)# event cli pattern "show ip interface" sync no skip yes occurs 1 period 5Router(config-applet)# action 1 syslog msg "test 1"Router(config-applet)# exitRouter(config)# event manager applet ap2Router(config-applet)# event cli pattern "show ip interface" sync no skip no occurs 1 period 5Router(config-applet)# action 1 syslog msg "test 2"Router(config-applet)# endThe following example shows how CLI parser-based events can be generated:
Router(config)# event manager applet ap1Router(config-applet)# event cli pattern "show ip interface"The results are displayed on the screen. Note that the second line contains a message that no event is configured for the EEM applet ap2. Use command CLI pattern matching with caution when the skip and yes keywords are specified.
00:00:41: %HA_EM-6-LOG: ap1: test 100:00:41: %HA_EM-4-FMPD_NO_EVENT: No event configured for applet ap2 router#show run | beg event event manager applet ap1 event cli pattern "show ip interface" sync no skip yes occurs 1 period 5 action 1 syslog msg "test 1"event manager applet ap2action 1 syslog msg "test 2"!endRelated Commands
event manager applet
Registers an event applet with the EEM and enters applet configuration mode.
event counter
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run on the basis of a named counter crossing a threshold, use the event counter command in applet configuration mode. To remove the counter event criteria, use the no form of this command.
event [tag event-tag] counter name counter-name entry-op operator entry-val entry-value [exit-op operator] [exit-val exit-value] [maxrun maxruntime-number]
no event [tag event-tag] counter name counter-name entry-op operator entry-val entry-value [exit-op operator] [exit-val exit-value] [maxrun maxruntime-number]
Syntax Description
Command Default
No EEM events are triggered on the basis of a named counter crossing a threshold.
Command Modes
Event counter applet configuration (config-applet-event-counter)
Command History
Usage Guidelines
An EEM event is triggered when the value of a specified counter crosses a defined threshold. Depending on the operator, the threshold may be crossed when the value is greater than the threshold or when the value is less than the threshold.
Use the event counter command with the action counter command when an event occurs periodically and you want an action to be implemented after a specified number of occurrences of the event.
Exit criteria are optional. If exit criteria are not specified, event monitoring will be reenabled immediately. If exit criteria are specified, event monitoring is not reenabled until the criteria are met.
Examples
The following example shows that policy EventCounter_A is configured to run once a minute and to increment a well-known counter called critical_errors. A second policy—EventCounter_B—is registered to be triggered when the well-known counter called critical_errors exceeds a threshold of 3. When policy EventCounter_B runs, it resets the counter to 0.
Router(config)# event manager applet EventCounter_ARouter(config-applet)# event timer watchdog time 60.0Router(config-applet)# action 1.0 syslog msg "EventCounter_A"Router(config-applet)# action 2.0 counter name critical_errors value 1 op incRouter(config-applet)# exitRouter(config)# event manager applet EventCounter_BRouter(config-applet)# event counter name critical_errors entry-op gt entry-val 3 exit-op lt exit-val 3Router(config-applet)# action 1.0 syslog msg "EventCounter_B"Router(config-applet)# action 2.0 counter name critical_errors value 0 op setRelated Commands
event interface
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run on the basis of a generic interface counter crossing a threshold or reaching exit criteria, use the event interface command in applet configuration mode. To remove the interface event criteria, use the no form of this command.
event [tag event-tag] interface name interface-type interface-number parameter counter-name entry-op operator entry-val entry-value entry-type {value | increment | rate} poll-interval poll-int-value [exit-comb {or | and}] [exit-op operator exit-val exit-value] [exit-type {value | increment | rate}] [exit-time exit-time-value] [average-factor average-factor-value] [maxrun maxruntime-number]
no event [tag event-tag] interface name interface-type interface-number parameter counter-name entry-op operator entry-val entry-value entry-type {value | increment | rate} poll-interval poll-int-value [exit-comb {or | and}] [exit-op operator exit-val exit-value] [exit-type {value | increment | rate}] [exit-time exit-time-value] [average-factor average-factor-value] [maxrun maxruntime-number]
Syntax Description
Command Default
No EEM events are triggered on the basis of a generic interface counter crossing a threshold or reaching exit criteria.
Command Modes
Applet configuration (config-applet)
Command History
Usage Guidelines
An EEM event is triggered when one of the fields specified by an interface counter crosses a defined threshold.
Note
Exit criteria are optional. If you do not specify the exit criteria, event monitoring will be reenabled immediately. If you specify the exit criteria, on the basis of values or time periods, event monitoring is not reenabled until the exit criteria are met.
When you use the exit-comb keyword, the following criteria must be met:
•
•
Cisco IOS Releases 12.4(15)T, 12.2(33)SB, 12.2(33)SRA, and 12.2(33)SXH, and Prior Releases
The entry-val-is-increment keyword triggers one of the following actions:
•
•
When the optional exit-val-is-increment keyword is used, the following occurs:
•
•
Cisco IOS Release 12.4(20)T and Later Releases
The entry-type keyword triggers one of the following actions:
•
•
•
When you use the optional exit-type keyword, the following occurs:
•
•
•
Examples
The following example shows how a policy named EventInterface is triggered every time the receive_throttle counter for the FastEthernet interface 0/0 is incremented by 5. The polling interval to check the counter is specified to run once every 90 seconds.
Router(config)# event manager applet EventInterfaceRouter(config-applet)# event interface name FastEthernet0/0 parameter receive_throttle entry-op ge entry-val 5 entry-val-is-increment true poll-interval 90Router(config-applet)# action 1.0 syslog msg "Applet EventInterface"The following example shows how a policy named EventInterface_Load is triggered every time the receive_rate_bps counter for the FastEthernet interface 0/0 reaches a rate of change of 10,000 with an average factor of 10. The polling interval to check the counter is specified to run once every 120 seconds. This example is for a Cisco IOS Release 12.4(20)T or later image.
Router(config)# event manager applet EventInterface_LoadRouter(config-applet)# event interface name FastEthernet0/0 parameter receive_rate_bps entry-op ge entry-val 10000 entry-type rate poll-interval 120 average-factor 10Router(config-applet)# action 1.0 syslog msg "Applet EventInterface_Load"Related Commands
event manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
event ioswdsysmon
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run on the basis of Cisco IOS system monitor counters crossing a threshold, use the event ioswdsysmon command in applet configuration mode. To remove the event criteria, use the no form of this command.
event [tag event-tag] ioswdsysmon sub1 subevent1 [timewin timewin-value] [sub12-op {and | or} sub2 subevent2] [maxrun maxruntime-number]
no [tag event-tag] event ioswdsysmon sub1 subevent1 [timewin timewin-value] [sub12-op {and | or} sub2 subevent2] [maxrun maxruntime-number]
Subevent Syntax (for the subevent1 and subevent2 Arguments) for Cisco IOS Images
cpu-proc taskname task-name op operator val value [period period-value]
mem-proc taskname task-name op operator val value [is-percent {true | false}] [period period-value]
Subevent Syntax (for the subevent1 and subevent2 Arguments) for Cisco IOS Software Modularity Images
cpu-proc taskname task-name path pid op operator val value [period period-value]
mem-proc taskname task-name path pid op operator val value [is-percent {true | false}] [period period-value]
Syntax Description
Command Default
No EEM events are triggered on the basis of Cisco IOS system monitor counters.
Command Modes
Applet configuration (config-applet).
Command History
Usage Guidelines
An EEM event is triggered when one of the Cisco IOS system monitor counters crosses a defined threshold. Depending on the operator, the threshold may be crossed when the value exceeds the threshold or when the value is less than the threshold.
If a match is found when the op keyword is used, a subevent is triggered.
Examples
The following example shows how to configure a policy to trigger an applet when the total amount of memory used by the process named "IP RIB Update" has increased by more than 50 percent over the sample period of 60 seconds:
Router(config)# event manager applet IOSWD_Sample3Router(config-applet)# event ioswdsysmon sub1 mem-proc taskname "IP RIB Update" op gt val 50 is-percent true period 60Router(config-applet)# action 1 syslog msg "IOSWD_Sample3 Policy Triggered"Related Commands
event manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
event manager applet
To register an applet with the Embedded Event Manager (EEM) and to enter applet configuration mode, use the event manager applet command in global configuration mode. To unregister the applet, use the no form of this command.
event manager applet applet-name [authorization bypass] [class class-options] [trap]
no event manager applet applet-name [authorization bypass] [class class-options] [trap]
Syntax Description
Command Default
No EEM applets are registered.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
An EEM applet is a concise method for defining event screening criteria and the actions to be taken when that event occurs.
Only one event configuration command is allowed within an applet configuration. When applet configuration submode is exited and no event command is present, a warning is displayed stating that no event is associated with this applet. If no event is specified, this applet is not considered registered and the applet is not displayed. When no action is associated with this applet, events are still triggered but no actions are performed. Multiple action applet configuration commands are allowed within an applet configuration. Use the show event manager policy registered command to display a list of registered applets.
Before modifying an EEM applet, use the no form of this command to unregister the applet because the existing applet is not replaced until you exit applet configuration mode. While you are in applet configuration mode modifying the applet, the existing applet may be executing. When you exit applet configuration mode, the old applet is unregistered and the new version is registered.
Action configuration commands are uniquely identified using the label argument, which can be any string value. Actions are sorted in ascending alphanumeric key sequence using the label argument as the sort key and are run using this sequence.
The EEM schedules and runs policies on the basis of an event specification that is contained within the policy itself. When applet configuration mode is exited, EEM examines the event and action commands that are entered and registers the applet to be run when a specified event occurs.
The EEM policies will be assigned a class when class class-letter is specified when they are registered. EEM policies registered without a class will be assigned to the default class. Threads that have default as the class will service the default class when the thread is available for work. Threads that are assigned specific class letters will service any policy with a matching class letter when the thread is available for work.
If there is no EEM execution thread available to run the policy in the specified class and a scheduler rule for the class is configured, the policy will wait until a thread of that class is available for execution. Synchronous policies that are triggered from the same input event should be scheduled in the same execution thread. Policies will be queued in a separate queue for each class using the queue_priority as the queuing order.
When a policy is triggered and if AAA is configured it will contact the AAA server for authorization. Using the authorization bypass keyword combination, you can skip to contact the AAA server and run the policy immediately. EEM stores AAA bypassed policy names in a list. This list is checked when policies are triggered. If a match is found, AAA authorization is bypassed.
To avoid authorization for commands configured through the EEM policy, EEM will use named method lists, which AAA provides. These named method lists can be configured to have no command authorization.
The following is a sample AAA configuration.
This configuration assumes a TACACS+ server at 192.168.10.1 port 10000. If the TACACS+ server is not enabled, configuration commands are permitted on the console; however, EEM policy and applet CLI interactions will fail.
enable password labaaa new-modeltacacs-server host 128.107.164.152 port 10000tacacs-server key ciscoaaa authentication login consoleline noneaaa authorization exec consoleline noneaaa authorization commands 1 consoleline noneaaa authorization commands 15 consoleline noneline con 0exec-timeout 0 0login authentication consolelineaaa authentication login default group tacacs+ enableaaa authorization exec default group tacacs+aaa authorization commands 1 default group tacacs+aaa authorization commands 15 default group tacacs+The authorization, class and trap keywords can be used in any combination.
Examples
The following example shows an EEM applet called IPSLAping1 being registered to run when there is an exact match on the value of a specified SNMP object ID that represents a successful IP SLA ICMP echo operation (this is equivalent to a ping command). Four actions are triggered when the echo operation fails, and event monitoring is disabled until after the second failure. A message that the ICMP echo operation to a server failed is sent to syslog, an SNMP trap is generated, EEM publishes an application-specific event, and a counter called IPSLA1F is incremented by a value of one.
Router(config)# event manager applet IPSLAping1Router(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.4 get-type exact entry-op eq entry-val 1 exit-op eq exit-val 2 poll-interval 5Router(config-applet)# action 1.0 syslog priority critical msg "Server IP echo failed: OID=$_snmp_oid_val"Router(config-applet)# action 1.1 snmp-trap strdata "EEM detected server reachability failure to 10.1.88.9"Router(config-applet)# action 1.2 publish-event sub-system 88000101 type 1 arg1 10.1.88.9 arg2 IPSLAEcho arg3 failRouter(config-applet)# action 1.3 counter name _IPSLA1F value 1 op incThe following example shows how to register an applet with the name one and class A and enter applet configuration mode where the timer event detector is set to trigger an event every 10 seconds. When the event is triggered, the action syslog command writes the message "hello world" to syslog.
Router(config)# event manager applet one class ARouter(config-applet)# event timer watchdog time 10Router(config-applet)# action syslog syslog msg "hello world"Router(config-applet)# exitThe following example shows how to bypass the AAA authorization when registering an applet with the name one and class A.
Router(config)# event manager applet one class A authorization bypassRouter(config-applet)#Related Commands
event manager directory user
To specify a directory to use for storing user library files or user-defined Embedded Event Manager (EEM) policies, use the event manager directory user command in global configuration command. To disable use of a directory for storing user library files or user-defined EEM policies, use the no form of this command.
event manager directory user {library path | policy path}
no event manager directory user {library path | policy path}
Syntax Description
Command Default
No directory is specified for storing user library files or user-defined EEM policies.
Command Modes
Global configuration
Command History
Usage Guidelines
The user library directory is needed to store user library files associated with authoring EEM policies. If you have no plans to author EEM policies, you need not create a user library directory.
In Cisco IOS Release 12.3(14)T and later releases the software supports policy files created using the Tool Command Language (Tcl) scripting language. Tcl is provided in the Cisco IOS software image when the EEM is installed on the network device. Files with the .tcl extension can be EEM policies, Tcl library files, or a special Tcl library index file named "tclindex." The tclindex file contains a list of user function names and the library files that contain the user functions. The EEM searches the user library directory when Tcl starts up to process the tclindex file.
To create the user library directory before identifying it to the EEM, use the mkdir command in privileged EXEC mode. After creating the user library directory, you can use the copy command to copy .tcl library files into the user library directory.
The user policy directory is needed to store user-defined policy files. If you have no plans to author EEM policies, you need not create a user policy directory. The EEM searches the user policy directory when you enter the event manager policy policy-filename type user command.
To create the user policy directory before identifying it to the EEM, use the mkdir command in privileged EXEC mode. After creating the user policy directory, you can use the copy command to copy policy files into the user policy directory.
Examples
The following example shows how to specify disk0:/user_library as the directory to use for storing user library files:
Router(config)# event manager directory user library disk0:/user_libraryRelated Commands
copy
Copies any file from a source to a destination.
event manager policy
Registers an EEM policy with the EEM.
mkdir
Creates a new directory in a Class C flash file system.
event manager environment
To set an Embedded Event Manager (EEM) environment variable, use the event manager environment command in global configuration mode. To disable an EEM environment variable, use the no form of this command.
event manager environment variable-name string
no event manager environment variable-name
Syntax Description
variable-name
Name assigned to the EEM environment variable.
string
Series of characters, including embedded spaces, to be placed in the environment variable variable-name.
Command Default
No EEM environment variables are set.
Command Modes
Global configuration
Command History
Usage Guidelines
By convention, the names of all environment variables defined by Cisco begin with an underscore character to set them apart: for example, _show_cmd.
To support embedded white spaces in the string argument, this command interprets everything after the variable-name argument to the end of the line to be part of the string argument.
To display the name and value of all EEM environment variables after you have configured them, use the show event manager environment command.
Examples
The following example of the event manager environment command defines a set of EEM environment variables:
Router(config)# event manager environment _cron_entry 0-59/2 0-23/1 * * 0-7Router(config)# event manager environment _show_cmd show versionRelated Commands
show event manager environment
Displays the name and value of all EEM environment variables.
event manager history size
To change the size of Embedded Event Manager (EEM) history tables, use the event manager history size command in global configuration mode. To restore the default history table size, use the no form of this command.
event manager history size {events | traps} [size]
no event manager history size {events | traps}
Syntax Description
Command Default
The size of the history table is 50 entries.
Command Modes
Global configuration
Command History
Examples
The following example of the event manager history size command changes the size of the SNMP trap history table to 30 entries:
Router(config)# event manager history size traps 30Related Commands
show event manager history events
Displays the EEM events that have been triggered.
show event manager history traps
Displays the EEM SNMP traps that have been sent.
event manager policy
To register an Embedded Event Manager (EEM) policy with the EEM, use the event manager policy command in global configuration mode. To unregister the EEM policy, use the no form of this command.
event manager policy policy-filename [authorization bypass] [class class-options] [type {system | user}] [trap]
no event manager policy policy-filename [authorization bypass] [class class-options] [type {system | user}] [trap]
Syntax Description
Command Default
No EEM policies are registered.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
The EEM schedules and runs policies on the basis of an event specification that is contained within the policy itself. When the event manager policy command is invoked, the EEM examines the policy and registers it to be run when the specified event occurs.
If you enter the event manager policy command without specifying the optional type keyword, the EEM first tries to locate the specified policy file in the system policy directory. If the EEM finds the file in the system policy directory, it registers the policy as a system policy. If the EEM does not find the specified policy file in the system policy directory, it looks in the user policy directory. If the EEM locates the specified file in the user policy directory, it registers the policy file as a user policy. If the EEM finds policy files with the same name in both the system policy directory and the user policy directory, the policy file in the system policy directory takes precedence and is registered as a system policy.
The EEM policies will be assigned a class when class class-letter is specified when they are registered. EEM policies registered without a class will be assigned to the default class. Threads that have default as the class will service the default class when the thread is available for work. Threads that are assigned specific class letters will service any policy with a matching class letter when the thread is available for work.
If there is no EEM execution thread available to run the policy in the specified class and a scheduler rule for the class is configured, the policy will wait until a thread of that class is available for execution. Synchronous policies that are triggered from the same input event should be scheduled in the same execution thread. Policies will be queued in a separate queue for each class using the queue_priority as the queuing order.
When a policy is triggered and if AAA is configured it will contact the AAA server for authorization. Using the authorization bypass keyword combination, you can skip to contact the AAA server and run the policy immediately. EEM stores aaa-bypassed policy names in a list. This list is checked when policies are triggered. If a match is found, AAA authorization is bypassed.
To avoid authorization for commands configured through the EEM policy, EEM will use named method lists, which AAA provides. These named method lists can be configured to have no command authorization.
The following is a sample AAA configuration.
This configuration assumes a TACACS+ server at 192.168.10.1 port 10000. If the TACACS+ server is not enabled, configuration commands are permitted on the console; however, EEM policy and applet CLI interactions will fail.
enable password labaaa new-modeltacacs-server host 128.107.164.152 port 10000tacacs-server key ciscoaaa authentication login consoleline noneaaa authorization exec consoleline noneaaa authorization commands 1 consoleline noneaaa authorization commands 15 consoleline noneline con 0exec-timeout 0 0login authentication consolelineaaa authentication login default group tacacs+ enableaaa authorization exec default group tacacs+aaa authorization commands 1 default group tacacs+aaa authorization commands 15 default group tacacs+The authorization, class, and type keywords can be used in any combination.
Examples
The following example shows how to use the event manager policy command to register a system-defined policy named tm_cli_cmd.tcl located in the system policy directory:
Router(config)# event manager policy tm_cli_cmd.tcl type systemThe following example shows how to use the event manager policy command to register a user-defined policy named cron.tcl located in the user policy directory:
Router(config)# event manager policy cron.tcl type userThe following example shows how to use the event manager policy command to register a Tcl script named syslog.tcl with a class of default:
Router(config)# event manager policy syslog.tcl class defaultThe following example shows how to use the event manager policy command to register a Tcl script named syslog.tcl with with a class of default and bypass the AAA authorization:
Router(config)# event manager policy syslog.tcl class default authorization bypassRelated Commands
event manager run
To manually run a registered Embedded Event Manager (EEM) policy, use the event manager run command in privileged EXEC mode.
event manager run policy-filename [[parameter1] [parameter2]...[parameter15]]
Syntax Description
Command Default
No registered EEM policies are run.
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
This command also enables you to use the parameters in the event policy and to specify the arguments in the registry call.
EEM usually schedules and runs policies on the basis of an event specification that is contained within the policy itself. The event manager run command allows policies to be run manually. The event none command must first be configured to run the policy manually. The None Event Detector includes arguments when it publishes the none event. This command does not have a no form.
Examples
The following example shows how to manually run an EEM policy named policy-manual.tcl:
Router# event manager run policy-manual.tclEach parameter consists of the total number of built-ins ($_none_argc), followed by the list of built-ins ($_none_arg1, $_none_arg2, and $_none_arg3). The following examples show applets and Tool Tcl scripts.
Applet Example
event manager applet none_parameter_testevent noneaction 1 syslog msg "Number of Arguments is $_none_argc"action 2 syslog msg "Argument 1 is $_none_arg1"action 3 syslog msg "Argument 2 is $_none_arg2"action 4 syslog msg "Argument 3 is $_none_arg3"endRouter# event manager run none_parameter_test 11 22 3301:26:03: %HA_EM-6-LOG: none_parameter_test: Number of Arguments is 301:26:03: %HA_EM-6-LOG: none_parameter_test: Argument 1 is 1101:26:03: %HA_EM-6-LOG: none_parameter_test: Argument 2 is 2201:26:03: %HA_EM-6-LOG: none_parameter_test: Argument 3 is 33For policies, event_reqinfo returns the optional parameters in a string, which are then handled by the policy.
Tcl Script Example
none_paramter_test.tcl::cisco::eem::event_register_nonenamespace import ::cisco::eem::*namespace import ::cisco::lib::*# query the event infoarray set arr_einfo [event_reqinfo]if {$_cerrno != 0} {set result [format "component=%s; subsys err=%s; posix err=%s;\n%s" \$_cerr_sub_num $_cerr_sub_err $_cerr_posix_err $_cerr_str]error $result}action_syslog priority info msg "Number of Arguments is $arr_einfo(argc)"if {$_cerrno != 0} {set result [format \"component=%s; subsys err=%s; posix err=%s;\n%s" \$_cerr_sub_num $_cerr_sub_err $_cerr_posix_err $_cerr_str]error $result}action_syslog priority info msg "Argument 1 is $arr_einfo(arg1)"if {$_cerrno != 0} {set result [format \"component=%s; subsys err=%s; posix err=%s;\n%s" \$_cerr_sub_num $_cerr_sub_err $_cerr_posix_err $_cerr_str]error $result}action_syslog priority info msg "Argument 2 is $arr_einfo(arg2)"if {$_cerrno != 0} {set result [format \"component=%s; subsys err=%s; posix err=%s;\n%s" \$_cerr_sub_num $_cerr_sub_err $_cerr_posix_err $_cerr_str]error $result}action_syslog priority info msg "Argument 3 is $arr_einfo(arg3)"if {$_cerrno != 0} {set result [format \"component=%s; subsys err=%s; posix err=%s;\n%s" \$_cerr_sub_num $_cerr_sub_err $_cerr_posix_err $_cerr_str]error $result}jubjub#event manager run none_parameter_test.tcl 1 2 301:26:03: %HA_EM-6-LOG: tmpsys:/eem_policy/none_parameter_test.tcl: Number of Arguments is 301:26:03: %HA_EM-6-LOG: tmpsys:/eem_policy/none_parameter_test.tcl: Argument 1 is 101:26:03: %HA_EM-6-LOG: tmpsys:/eem_policy/none_parameter_test.tcl: Argument 2 is 201:26:03: %HA_EM-6-LOG: tmpsys:/eem_policy/none_parameter_test.tcl: Argument 3 is 3Related Commands
event manager scheduler script
To schedule Embedded Event Manager (EEM) policies and set the script scheduling options, use the event manager scheduler script command in global configuration mode. To remove the EEM script scheduling options and restore the default value, use the no form of this command.
event manager scheduler script thread class class-options number thread-number
no event manager scheduler script thread class class-options number thread-number
Syntax Description
Command Default
Only one EEM policy can be run at a time.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
Use the event manager scheduler script command if you want to run more than one EEM policy concurrently.
You should specify any one of the options class-letter, default, and range class-letter-range. You can specify all these options in the same CLI statement.
To schedule EEM policies and set the policy scheduling options, use the event manager scheduler command in global configuration mode. To remove the scheduling of the EEM policies, use the no form of this command.
Examples
The following example shows how to specify two script execution threads to run concurrently:
Router(config)# event manager scheduler script thread class default number 2event manager scheduler suspend
To immediately suspend Embedded Event Manager (EEM) policy scheduling execution, use the event manager scheduler suspend command in global configuration mode. To resume EEM policy scheduling, use the no form of this command.
event manager scheduler suspend
no event manager scheduler suspend
Syntax Description
This command has no arguments or keywords.
Command Default
Policy scheduling is active.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the event manager scheduler suspend command to suspend all policy scheduling requests and do no scheduling until you enter the no form of the command. The no form of the command resumes policy scheduling and executes any pending policies.
You might want to suspend policy execution immediately instead of unregistering policies one by one for the following reasons:
•
•
Examples
The following example of the event manager scheduler suspend command disables policy scheduling:
Router(config)# event manager scheduler suspendMay 19 14:31:22.439: fm_server[12330]: %HA_EM-6-FMS_POLICY_EXEC: fh_io_msg: Policy execution has been suspendedThe following example of the event manager scheduler suspend command enables policy scheduling:
Router(config)# no event manager scheduler suspendMay 19 14:31:40.449: fm_server[12330]: %HA_EM-6-FMS_POLICY_EXEC: fh_io_msg: Policy execution has been resumedRelated Commands
event manager session cli username
To associate a username with Embedded Event Manager (EEM) policies that use the command-line interface (CLI) library, use the event manager session cli username command in global configuration mode. To remove the username association with EEM policies that use the CLI library, use the no form of this command.
event manager session cli username username
no event manager session cli username username
Syntax Description
Command Default
No username is associated with EEM CLI sessions.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the event manager session cli username command to assign a username for EEM policy CLI sessions when TACACS+ is used for command authorization.
If you are using authentication, authorization, and accounting (AAA) security and implement authorization on a command basis, you should use the event manager session cli username command to set a username to be associated with a Tool Command Language (Tcl) session. The username is used when a Tcl policy executes a CLI command. TACACS+ verifies each CLI command using the username associated with the Tcl session that is running the policy. Commands from Tcl policies are not usually verified because the router must be in privileged EXEC mode to register the policy.
Examples
The following example of the event manager session cli username command associates the username eemuser with EEM CLI sessions initiated by EEM policies:
Router(config)# event manager session cli username eemuserRelated Commands
show event manager session cli username
Displays the username associated with CLI sessions initiated by EEM policies that use the EEM CLI library.
event none
To specify that an Embedded Event Manager (EEM) policy is to be registered with the EEM and can be run manually, use the event none command in applet configuration mode. To remove the event none command from the configuration file, use the no form of this command.
event [tag event-tag] none [maxrun maxruntime-number]
no event none
Syntax Description
Command Default
No EEM events are triggered on the basis of Cisco IOS system monitor counters.
Command Modes
Applet configuration (config-applet).
Command History
Usage Guidelines
EEM usually schedules and runs policies on the basis of an event specification that is contained within the policy itself. The event none command allows EEM to identify an EEM policy that can either be run manually or be run when an EEM applet is triggered. To run the policy, use either the action policy command in applet configuration mode or the event manager run command in global configuration mode.
Examples
The following example shows how to register a policy named manual-policy to be run manually and then how to execute the policy:
Router(config)# event manager applet manual-policyRouter(config-applet)# event noneRouter(config-applet)# exitRouter(config)# event manager run manual-policyRelated Commands
event oir
To specify that an Embedded Event Manager (EEM) applet be run on the basis of an event raised when a hardware card online insertion and removal (OIR) occurs, use the event oir command in applet configuration mode. To remove the event oir command from the configuration, use the no form of this command.
event [tag event-tag] oir [maxrun maxruntime-number]
no event [tag event-tag] oir [maxrun maxruntime-number]
Syntax Description
Command Default
No EEM applets are run on the basis of an OIR event.
Command Modes
Applet configuration (config-applet)
Command History
Examples
The following example shows how to configure an EEM applet to be run on the basis of an OIR event:
Router(config)# event manager applet oir-eventRouter(config-applet)# event oirRouter(config-applet)# exitRelated Commands
event manager applet
Registers an EEM applet with EEM and enters applet configuration mode.
event process
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run on the basis of an event raised when a Cisco IOS Software Modularity process starts, restarts, or stops, use the event process command in applet configuration mode. To remove the process event criteria, use the no form of this command.
event process {abort | start | term | user-restart | user-shutdown} path process-name
[instance instance-value] [node node-value]no event process {abort | start | term | user-restart | user-shutdown} path process-name
[instance instance-value] [node node-value]Syntax Description
Command Default
No EEM events are triggered on the basis of a Cisco IOS Software Modularity process starting, restarting, or stopping.
Command Modes
Applet configuration (config-applet)
Command History
Examples
The following example shows how to specify that an event is triggered when a Software Modularity process starts:
Router(config)# event manager applet process_termRouter(config-applet)# event process start path "cdp2.iosproc"Related Commands
event manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
event snmp
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run by sampling Simple Network Management Protocol (SNMP) object identifier values, use the event snmp command in applet configuration mode. To remove the SNMP event criteria, use the no form of this command.
event [tag event-tag] snmp oid oid-value get-type {exact | next} entry-op operator entry-val entry-value entry-type {value | increment | rate} [exit-comb {or | and}] [exit-op operator] [exit-val exit-value] [exit-type {value | increment | rate}] [exit-time exit-time-value] [exit-event {true | false}] [average-factor average-factor-value] poll-interval poll-int-value [maxrun maxruntime-number]
no event [tag event-tag] snmp oid oid-value get-type {exact | next} entry-op operator entry-val entry-value entry-type {value | increment | rate} [exit-comb {or | and}] [exit-op operator] [exit-val exit-value] [exit-type {value | increment | rate}] [exit-time exit-time-value] [exit-event {true | false}] [average-factor average-factor-value] poll-interval poll-int-value [maxrun maxruntime-number]
Syntax Description
Command Default
No EEM events are triggered on the basis of SNMP object identifier values.
Command Modes
Applet configuration (config-applet)
Command History
Usage Guidelines
An EEM event is triggered when one of the fields specified by an SNMP object ID crosses a defined threshold. If multiple conditions exist, the SNMP event will be triggered when all the conditions are met.
Exit criteria are optional. If exit criteria are not specified, event monitoring will be reenabled immediately. If exit criteria are specified—on the basis of values or time periods—event monitoring is not reenabled until the criteria are met.
When the entry-op keyword is used and there is a match, an event is triggered and event monitoring is disabled until the exit criteria are met.
When the exit-op keyword is used and there is a match, an event is triggered and event monitoring is reenabled.
The entry-type keyword triggers one of the following actions:
•
•
•
When the optional exit-type keyword is used, the following occurs:
•
•
•
The increment and rate types are supported only for the following OID types: INTEGER_TYPE, COUNTER_TYPE, and COUNTER_64_TYPE.
Examples
The following example shows how an EEM applet called memory-fail will run when there is an exact match on the value of a specified SNMP object ID that represents the amount of current process memory. A message saying that process memory is exhausted and noting the current available memory will be sent to syslog.
Router(config)# event manager applet memory-failRouter(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.48.1.1.1.6.1 get-type exact entry-op lt entry-val 5120000 poll-interval 10Router(config-applet)# action 1.0 syslog msg "Memory exhausted; current available memory is $_snmp_oid_val bytes"The following example shows an EEM applet called IPSLAping1 being registered to run when there is an exact match on the value of a specified SNMP object ID that represents a successful IP SLA ICMP echo operation (this is equivalent to a ping command). Four actions are triggered when the echo operation fails, and event monitoring is disabled until after the second failure.
A message saying that the ICMP echo operation to a server failed is sent to syslog, an SNMP trap is generated, EEM publishes an application-specific event, and a counter called IPSLA1F is incremented by a value of one.
Router(config)# event manager applet IPSLAping1Router(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.4 get-type exact entry-op eq entry-val 1 exit-op eq exit-val 2 poll-interval 5Router(config-applet)# action 1.0 syslog priority critical msg "Server IP echo failed: OID=$_snmp_oid_val"Router(config-applet)# action 1.1 snmp-trap strdata "EEM detected server reachability failure to 10.1.88.9"Router(config-applet)# action 1.2 publish-event sub-system 88000101 type 1 arg1 10.1.88.9 arg2 IPSLAEcho arg3 failRelated Commands
event manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
event syslog
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run by matching syslog messages, use the event syslog command in applet configuration mode. To remove the syslog message event criteria, use the no form of this command.
event [tag event-tag] syslog pattern regular-expression [occurs num-occurrences] [period period-value] [priority priority-level] [severity-level] [maxrun maxruntime-number]
no event [tag event-tag] syslog pattern regular-expression [occurs num-occurrences] [period period-value] [priority priority-level] [severity-level] [maxrun maxruntime-number]
Syntax Description
Command Default
No EEM events are triggered on the basis of matches with syslog messages.
Command Modes
Applet configuration (config-applet)
Command History
Usage Guidelines
Use the event syslog command to set up event criteria against which syslog messages are matched. Syslog messages are compared against a specified regular expression. After a specified number of matches occurs within a specified time period, an EEM event is triggered. If multiple conditions exist, the EEM event is triggered when all the conditions are met.
Valid levels for the priority-level argument are as follows (enter the keyword or number, if available):
•
•
•
•
•
•
•
•
•
The severity-level argument may be one or more of the following keywords:
•
•
•
•
•
•
•
•
Examples
The following example shows how to specify an EEM applet to run when syslog identifies that Ethernet interface 1/0 is down. The applet sends a message about the interface to syslog.
Router(config)# event manager applet interface-downRouter(config-applet)# event syslog pattern {.*UPDOWN.*Ethernet1/0.*} occurs 4Related Commands
event manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
event timer
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run on the basis of time-specific events, use the event timer command in applet configuration mode. To remove the time-specific event criteria, use the no form of this command.
event [tag event-tag] timer {absolute time time-value | countdown time time-value | cron cron-entry cron-entry | watchdog time time-value} [name timer-name]
no event [tag event-tag] timer {absolute time time-value | countdown time time-value | cron cron-entry cron-entry | watchdog time time-value} [name timer-name]
Syntax Description
Command Default
No EEM events are triggered on the basis of time-specific events.
Command Modes
Applet configuration
Command History
Usage Guidelines
For the cron-entry argument, the following special strings also are allowed in syntax:
•
•
•
•
Instead of the five fields of a UNIX crontab entry for the cron-entry argument, one of the following seven special strings can be entered:
•
•
•
•
•
•
•
A CRON timer may not produce the intended result if the time-of-day clock is not set to the correct time. Network Time Protocol (NTP) services can be used to facilitate keeping an accurate time-of-day clock setting. For more details on NTP configuration, see the "Performing Basic System Management" chapter of the Cisco IOS Network Management Configuration Guide, Release 12.4.
Examples
The following example shows how to specify that an event is triggered one time after 5 hours:
Router(config)# event manager applet timer-absoluteRouter(config-applet)# event timer absolute time 18000The following example shows how to specify that an event is triggered once after 6 minutes and 6 milliseconds:
Router(config)# event manager applet timer-setRouter(config-applet)# event timer countdown time 360.006 name six-minutesThe following example shows how to specify that an event is triggered at 1:01 a.m. on January 1 each year:
Router(config)# event manager applet timer-cron1Router(config-applet)# event timer cron cron-entry 1 1 1 1 * name Jan1The following example shows how to specify that an event is triggered at noon on Monday through Friday of every week:
Router(config)# event manager applet timer-cron2Router(config-applet)# event timer cron cron-entry 0 12 * * 1-5 name MonFriThe following example shows how to specify that an event is triggered at midnight on Sunday every week:
Router(config)# event manager applet timer-cron3Router(config-applet)# event timer cron cron-entry @weekly name SundayThe following example shows how to specify that an event is triggered every 5 hours:
Router(config)# event manager applet timer-watchRouter(config-applet)# event timer watchdog time 18000Related Commands
event manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
event wdsysmon
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run on the basis of Cisco IOS Software Modularity watchdog system monitor (WDSysMon) counters crossing a threshold, use the event wdsysmon command in applet configuration mode. To remove the event criteria, use the no form of this command.
event wdsysmon sub1 subevent1 [timewin timewin-value] [sub12-op {and | or | andnot}
sub2 subevent2] [node node-name]no event wdsysmon sub1 subevent1 [timewin timewin-value] [sub12-op {and | or | andnot}
sub2 subevent2] [node node-name]Subevent Syntax (for the subevent1 and subevent2 Arguments)
cpu-proc procname process-name op operator val value [period period-value]
cpu-tot op operator val value [period period-value]
deadlock procname process-name
dispatch-mgr procname process-name op operator val value [period period-value]
mem-proc procname process-name op operator val value [is-percent {true | false}] [period period-value]
mem-tot-avail op operator val value [is-percent {true | false}] [period period-value]
mem-tot-used op operator val value [is-percent {true | false}] [period period-value]
Syntax Description
Command Default
No EEM events are triggered on the basis of Cisco IOS Software Modularity WDSysMon counters.
Command Modes
Applet configuration (config-applet)
Command History
Usage Guidelines
An EEM event is triggered when one of the Cisco IOS Software Modularity WDSysMon counters crosses a defined threshold. Depending on the operator, the threshold may be crossed when the value is greater than the threshold or when the value is less than the threshold.
Examples
The following example shows how to configure a Cisco IOS Software Modularity policy to trigger an applet when the total amount of memory used by the process named "tcp.proc" has increased by more than 50 percent over the sample period of 60 seconds:
Router(config)# event manager applet WD_SampleRouter(config-applet)# event wdsysmon sub1 mem-proc procname "tcp.proc" op gt val 50 is-percent true period 60Router(config-applet)# action 1 syslog msg "WD_Sample Policy Triggered"Related Commands
event manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
