High Availability

A. The term embedded management is used describe the software subsystems within Cisco® IOS® Software that help manage, monitor, and automate actions within a router or switch running Cisco IOS Software.

A. Traditionally, network management happens from outside the network looking in. Embedded management and EEM add a new dimension. It is management from within the network and within the device itself.

A. The answer depends on what you do with it. For the most part, you can elect to use it or not. If you want, you can use EEM to automate tasks, to program actions to take based on certain events, to write custom syslog messages, or to send alerts or e-mail from a router or switch to inform operations personnel. The benefit comes from being able to automatically take action and collect data to better manage your devices and network.

A. External network management systems play a significant role in fault management, configuration management, capacity planning, provisioning, and data collection. But there are advantages to having an onboard or embedded management capability. For example, there could be instances where some problem cuts off communication to an external management system, leaving it unable to manage the device. Or it might be difficult to achieve the desired polling rate for many managed devices from a central system. In this case, distributing part of the management burden to the device itself might be a better solution.

A. Because EEM runs on the routers and switches themselves, you do not need to have an external network management system to gain some data collection and device management capabilities. You can use EEM to help the devices to help you manage the network.

A. EEM consists of three main components: event detectors, the event manager server, and the policy director. These are software components in the Cisco IOS Software. The event detectors do just that: detect when certain events occur within Cisco IOS Software and notify the event manager server. The policy director registers with the event manager server to receive events and implements policy actions. The policies are either system policies that come with Cisco IOS Software or user policies defined by you. After being registered, the policy's actions are carried out whenever the event of interest occurs.

A. For example, you might have a policy run when a particular syslog message occurs. Or a policy could run when an interface fails. Or a policy could run when CPU utilization reaches some specified threshold. There are many examples using the available event detectors.

A. There are currently 15 event detectors and more to come in future Cisco IOS Software releases.

A. User policies are defined by you, the customer. There are two types of user policies: applet policies and TCL policies. They are registered using configuration command-line interface (CLI) commands. See more about each of them in later questions.

A. Yes. The MIB that defines the trap or inform is CISCO-EMBEDDED-EVENT-MGR-MIB.my and can be retrieved from Cisco.com.

A. Yes. It is available for many Cisco Systems® products. It is in recent versions of Cisco IOS Software mainline, "T," "S," and "SX" software trains. Please see Cisco IOS Software Feature Navigator for more information.

A. Yes. EEMv1.0 was introduced in Cisco IOS Software Releases 12.0(26)S and 12.3(4)T. EEMv2.0 added some additional functions. EEMv2.1 followed and added the ability for users to program their own policies using TCL. The latest version at the time this was prepared was EEMv2.2.

A. Please see the Cisco IOS Software documentation.

A. An applet policy is a fairly simple policy defined using the Cisco configuration CLI.

A. Yes, EEMv2.1 and above allow this.

A. Yes.

A. No. You will probably want to use a TCL policy for that.

A. It is an EEM policy programmed using the TCL programming language.

A. Yes, and there has been since Cisco IOS Software Release 12.0. The current version (as of this writing, November 2005) is 8.3.4. It is used by the voice-over-IP (VoIP) subsystems in Cisco IOS Software for interactive voice response, embedded syslog manager, and the Cisco IOS Software TCL shell as well as with EEM.

A. Typically, offline on a PC, using a text editor or programming environment. You would code your policy, then download it (copy it) to the router or switch using Trivial File Transfer Protocol (TFTP) or some other protocol that works, then register it using the EEM configuration CLI commands, then test it.

A. There are some debug commands to help you find any errors in your policy. You would typically want to try your policy in a test environment before using it in a production network. It might take a few iterations to get it right. Each time you modify your code, transfer it to the router, unregister it, reregister it, and try it. Continue iterating through those steps until you are satisfied and then deploy your EEM TCL policy to your production routers.

A. Not yet. EEM is still relatively new, and the external management tools have not been updated to manage EEM policies.

A. No. The EEM subsystem, TCL interpreter, and Cisco IOS Software infrastructure have been designed to guard against your policy causing problems. Of course, if the logic of your program is wrong, you could affect the operation of the network. That is why it is prudent to test your policy in a test environment before widespread deployment.

A. No. Not without the enable password for the router. The configuration and registration of any EEM policy is done through the configuration, and you must first have authority for that. At registration the policy is read into the router's memory and implemented from there.

A. There are many excellent books about TCL programming. One widely acclaimed title is Practical Programming in Tcl and Tk by Brent B. Welch. The programming and use of EEM TCL extensions are covered in the "Writing Embedded Event Manager Policies" guide (see Cisco IOS Software documentation).

A. First, you do not have to use EEM, and all user TCL policies are completely disabled by no event manager directory user policy. The effects on performance depend on the number of policies registered and the number of event manager scheduler threads configured. The number of policies that can be registered is limited by the amount of available memory. More performance-related information will be available soon in another document.

A. Yes.

A. Not presently. This is coming in a future release.