action 1.0 cli command [cmd]
Defines an Embedded Event Manager (EEM) applet action that executes a specified Cisco IOS CLI command when the applet is triggered.
Definition: action 1.0 cli command [cmd] is a Cisco IOS applet config command. Defines an Embedded Event Manager (EEM) applet action that executes a specified Cisco IOS CLI command when the applet is triggered.
Overview
The 'action 1.0 cli command' is a directive used within Cisco IOS Embedded Event Manager (EEM) applets to execute a specified CLI command when the applet triggers. EEM is a powerful, event-driven automation framework that allows network engineers to monitor system events and respond with pre-defined actions, such as executing CLI commands, sending SNMP traps, or generating syslog messages. This command is essential for automating repetitive tasks, enforcing compliance, and enabling rapid response to network incidents without manual intervention.
In the context of network automation, EEM applets act as 'if-then' scripts: when a specific event occurs (e.g., a syslog message, a timer expiry, or a routing change), the applet runs a series of actions. The 'action 1.0 cli command' is the most common action, allowing the applet to execute any IOS CLI command, from 'show' commands for data collection to 'configure terminal' commands for configuration changes. This capability is invaluable for tasks such as automatically saving the running configuration after a change, logging interface status changes, or even adjusting routing parameters in response to network events.
When to use this command versus alternatives: For simple, event-triggered automation, EEM is often more straightforward than scripting with Python or using REST APIs, as it is built into IOS and requires no external servers. However, for complex workflows or multi-device orchestration, tools like Ansible or Cisco NSO are more appropriate. EEM is best suited for single-device, event-driven tasks that need to run in real-time with minimal overhead.
Important IOS behavior: The CLI command executed by EEM runs with the privilege level of the user who triggered the applet (or the default privilege level if triggered by a system event). For commands that require higher privilege (e.g., 'configure terminal'), the applet must be configured to run with the necessary privilege, often by setting the 'event manager applet' command with 'authorization bypass' or ensuring the applet runs under a user with privilege 15. Output from the command is buffered and can be captured using the 'action 1.0 cli command' with the 'append' or 'output' options, but by default, output is discarded unless explicitly stored. The command does not modify the running configuration unless the executed CLI command itself does (e.g., 'configure terminal' commands). It is important to note that EEM applets can be triggered by many events, including syslog patterns, SNMP traps, interface state changes, and even periodic timers, making this action versatile for proactive network management.
action 1.0 cli command [cmd]When to Use This Command
- Automatically save the running configuration to startup configuration when a critical interface goes down.
- Send a custom syslog message and execute a show command to capture interface status when a routing protocol neighbor is lost.
- Automatically clear counters on an interface after a maintenance window to reset statistics.
- Execute a ping to a remote server and log the result when a specific event occurs.
Parameters
| Parameter | Syntax | Description |
|---|---|---|
| action-number | <1-99> | Specifies the sequence number of the action within the applet. Actions are executed in ascending order. Common mistake: using duplicate numbers or skipping numbers, which can cause confusion; it is best to use sequential numbers starting from 1. |
| cli command | STRING | The exact IOS CLI command to execute, enclosed in quotes if it contains spaces. The command can be any valid IOS command, including 'show', 'configure terminal', 'copy', etc. Common mistake: forgetting to include the full command path (e.g., 'configure terminal' must be followed by the configuration commands in separate actions). |
Command Examples
Save configuration on interface down
action 1.0 cli command "write memory"This action executes the 'write memory' command to save the running configuration to startup configuration. No output is displayed as the command runs silently.
Send syslog and show interface status
action 2.0 cli command "show interfaces GigabitEthernet0/1"GigabitEthernet0/1 is up, line protocol is up
Hardware is CN Gigabit Ethernet, address is aabb.cc00.0201 (bia aabb.cc00.0201)
Internet address is 192.168.1.1/24
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1000Mbps, link type is auto, media type is RJ45
output flow-control is unsupported, input flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1000 bits/sec, 2 packets/sec
5 minute output rate 500 bits/sec, 1 packets/sec
12345 packets input, 1234567 bytes
Received 123 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
23456 packets output, 2345678 bytes
0 underruns, 0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped outThis action runs 'show interfaces GigabitEthernet0/1' to display the status and statistics of the interface. The output shows interface status (up/down), IP address, MTU, bandwidth, delay, reliability, load, duplex, speed, and detailed packet counters. Key fields to monitor: 'line protocol is up' indicates Layer 2 connectivity; 'input errors' and 'output errors' should be zero; 'CRC' errors indicate physical layer issues.
Understanding the Output
The 'action cli command' itself does not produce output directly; instead, it executes the specified CLI command. The output shown is the result of that command. In EEM applet configuration, the action is defined but the output is not displayed until the applet triggers.
When troubleshooting, you would check the syslog or the output of the command if it is redirected (e.g., using 'append' or 'redirect' options). For example, if the action runs 'show interfaces', the output can be sent to a syslog server or stored in a file. In the output, look for interface status (up/down), error counters (input errors, CRC, output errors), and load metrics.
Good values: interface up/up, zero errors, low utilization. Bad values: interface down, high CRC errors, excessive drops.
Configuration Scenarios
Automatically Save Running Configuration on Syslog Error
A network engineer wants to ensure that whenever a critical syslog message (e.g., 'UPDOWN' or 'LINEPROTO') is generated, the running configuration is automatically saved to startup configuration to prevent loss of changes.
Topology
Single router: R1Steps
- 1.Step 1: Enter global configuration mode: R1# configure terminal
- 2.Step 2: Create an EEM applet named AUTO-SAVE: R1(config)# event manager applet AUTO-SAVE
- 3.Step 3: Define the trigger event: R1(config-applet)# event syslog pattern 'UPDOWN'
- 4.Step 4: Add action to save configuration: R1(config-applet)# action 1.0 cli command 'write memory'
- 5.Step 5: Exit applet configuration: R1(config-applet)# end
- 6.Step 6: Verify the applet: R1# show event manager policy registered
! event manager applet AUTO-SAVE event syslog pattern "UPDOWN" action 1.0 cli command "write memory" !
Verify: Use 'show event manager policy registered' to confirm the applet is active. To test, trigger an interface up/down event and check the syslog for 'copy running-config startup-config' message. Expected output includes 'AUTO-SAVE' in the policy list.
Watch out: The 'write memory' command requires privilege level 15. If the applet is triggered by a user with lower privilege, the command may fail. Use 'authorization bypass' under the applet or ensure the triggering user has sufficient rights.
Log Interface Status Changes to a File
An engineer needs to log every time an interface goes up or down, capturing the interface name and timestamp, to a file on flash for later analysis.
Topology
Single router: R1 with multiple interfacesSteps
- 1.Step 1: Enter global configuration mode: R1# configure terminal
- 2.Step 2: Create an EEM applet named LOG-INT: R1(config)# event manager applet LOG-INT
- 3.Step 3: Define the trigger event for interface line protocol changes: R1(config-applet)# event syslog pattern 'LINEPROTO-5-UPDOWN'
- 4.Step 4: Add action to capture the interface name and timestamp: R1(config-applet)# action 1.0 cli command 'show interface | include line protocol'
- 5.Step 5: Add action to append output to a file: R1(config-applet)# action 2.0 cli command 'append flash:int-status.log $_cli_result'
- 6.Step 6: Exit and verify: R1(config-applet)# end
! event manager applet LOG-INT event syslog pattern "LINEPROTO-5-UPDOWN" action 1.0 cli command "show interface | include line protocol" action 2.0 cli command "append flash:int-status.log $_cli_result" !
Verify: Check the file contents: R1# more flash:int-status.log. Expected output shows lines like 'GigabitEthernet0/0 is up, line protocol is up' with timestamps from syslog.
Watch out: The 'append' command expects the file to exist; if not, it will fail. Pre-create the file using 'touch flash:int-status.log' or use 'action 2.0 cli command "write flash:int-status.log $_cli_result"' to overwrite, but appending is safer for logs.
Troubleshooting with This Command
When troubleshooting EEM applets that use the 'action 1.0 cli command', the first step is to verify that the applet is registered and enabled. Use 'show event manager policy registered' to list all applets; if the applet is missing, check for syntax errors in the configuration. Next, examine the event trigger: use 'show event manager event-types' to see which events are supported, and ensure the event pattern (e.g., syslog regex) matches exactly.
For syslog-triggered applets, enable 'debug event manager action cli' to see the CLI command being executed and its output. Healthy output shows the command being sent and the result; if you see 'command failed' or 'privilege error', the issue is likely permissions. The '$_cli_result' variable stores the output of the last CLI command; use 'action 1.0 cli command' with 'append' to write this to a file for later review.
Common symptoms include: applet triggers but no action occurs – check if the action number is correct and the command syntax is valid. If the command is a 'configure terminal' sequence, ensure each configuration command is a separate action (e.g., action 1.0 cli command 'configure terminal', action 2.0 cli command 'interface GigabitEthernet0/0', action 3.0 cli command 'shutdown'). Another frequent issue is that the applet runs but the output is not captured; use 'action 1.0 cli command' with the 'output' option to store the result in a variable.
Correlate with 'show logging' to see if the triggering event occurred. For timer-based applets, verify the timer is running with 'show event manager timer'. If the applet is supposed to run on a specific routing event (e.g., OSPF neighbor change), use 'show ip ospf neighbor' to confirm the event actually happened.
Finally, check the EEM policy directory: 'show event manager policy active' shows currently running policies. If the applet is not listed, it may have been removed due to a configuration reload or syntax error. In summary, systematic verification of registration, event trigger, action execution, and permissions will resolve most issues.
CCNA Exam Tips
CCNA exam tip: EEM applets are configured in global configuration mode, not interface mode. Remember the 'event manager applet' command starts the applet definition.
CCNA exam tip: The 'action' command must be numbered (e.g., action 1.0) and the CLI command must be enclosed in double quotes.
CCNA exam tip: EEM applets can be triggered by events like syslog patterns, interface state changes, or timers. Know the 'event syslog' and 'event interface' triggers.
CCNA exam tip: The 'cli command' action can include 'append' or 'redirect' to save output to a file, which is useful for logging.
Common Mistakes
Mistake 1: Forgetting to enclose the CLI command in double quotes, causing a syntax error.
Mistake 2: Using an invalid action number (e.g., action 0.0) — action numbers must start at 1.0.
Mistake 3: Not specifying the full command path (e.g., using 'write memory' instead of 'write memory' is fine, but some commands require 'do' prefix in certain modes).
action 1.0 cli command [cmd] vs event manager applet
Both commands are essential for Cisco Embedded Event Manager (EEM) configurations but operate at different levels. 'event manager applet' creates the applet container and defines the triggering event, while 'action 1.0 cli command' is a subcommand that specifies a CLI command to execute when the applet triggers. They are often confused because both are required for a functional EEM policy.
| Aspect | action 1.0 cli command [cmd] | event manager applet |
|---|---|---|
| Scope | Defines an action within an applet | Creates the entire applet container |
| Configuration mode | Applet config mode (after 'event manager applet') | Global configuration mode |
| Function | Executes a specified CLI command as a response | Defines the event trigger that activates the applet |
| Dependency | Requires an existing applet created by 'event manager applet' | Must be configured before any actions are defined |
| Typical use | Running a show command or reconfiguring an interface on event | Setting up an EEM policy for syslog or interface state changes |
Use action 1.0 cli command [cmd] when you need to execute a specific CLI command as part of an existing EEM applet, such as logging or resetting an interface.
Use event manager applet when you want to create a new automation instance that responds to a specific system event, like a syslog message or timer expiration.
Platform Notes
In IOS-XE (e.g., Catalyst 9000 switches), the 'action 1.0 cli command' syntax is identical to classic IOS. However, IOS-XE uses a Linux-based kernel, and some commands may have slightly different output formatting. For NX-OS (e.g., Nexus switches), the equivalent is 'event manager applet' with 'action 1.0 cli command' but note that NX-OS uses a different CLI structure; for example, 'write memory' is 'copy running-config startup-config'.
Also, NX-OS supports 'event manager applet' with 'event syslog' but the pattern matching is case-sensitive. On ASA firewalls, EEM is not supported; instead, use 'event manager' in ASA 9.x with limited actions, but the 'cli command' action is not available. For IOS-XR (e.g., ASR 9000), EEM is not supported; automation is done via 'event manager' in a different paradigm (e.g., 'event manager policy' using TCL scripts).
In terms of version differences: IOS 12.x and 15.x have the same EEM syntax, but 16.x (IOS-XE) introduced 'event manager applet' with additional options like 'event cli' for command-based triggers. Always verify the exact syntax with 'show event manager applet all' to see the configured applets. For high-availability platforms, EEM applets run on the active supervisor; if a switchover occurs, applets are re-registered on the new active.
When using 'action 1.0 cli command' with 'configure terminal', be aware that the configuration change is applied immediately and is not automatically saved; consider adding a 'write memory' action afterward.
Related Commands
Practice for the CCNA 200-301
Test your knowledge with practice questions covering all CCNA 200-301 exam domains.
Practice CCNA 200-301 Questions