- [Narrator] In this video we're going to take a look
at configuring the Embedded Event Manager.
The Cisco blueprint for this exam calls for knowledge
of using CLI applets with EEM configuration.
So that's what we're going to focus on here
rather than using scripting.
I have a very simple network here.
I have just a couple of routers interconnected
over the 10.1.1.0/24 network.
In my case, I don't actually need that connection.
You can test this out with a single router,
everything that I'm going to show you.
And one really common way that we might use this
is through automatically re-enabling any interfaces
that have been administratively shut down.
So let's say we have a critical public facing interface
or one that's connected out to a WAN connection.
This is a safeguard that we could put in place to make sure
the interface doesn't get accidentally shut down,
which would maybe sever connectivity
to a server or sever WAN access.
And the way that we're going to do this,
is we're going to create an EEM policy
that looks for syslog messages
related to the interface being shut down.
The Event Detector is going to look
for those specific syslog messages
and they're going to trigger an event action
that will re-enable the interface.
So in order to do that,
let's first go under Global Configuration Mode.
And let's go under Interface gig 0/1,
and the first thing I'm actually
going to do is I'm going to shut down that interface.
We're going to be able to see the actual syslog message
that is generated when the interface is shut down.
And we actually see that here.
What I'm going to do is I'm going to copy the contents
of this message so that I get the format exactly correct.
So I'm going to copy that.
I'm going to copy just the last part of the message,
not the entire message,
just the syslog message output.
I'm going to copy that and I'll hang onto that
for later reference.
After I've done that,
I'll go ahead and re-enable the port with a NO-SHUT command.
And now we can start the configuration
by saying Event Manager.
And if we look at Contextual Help,
since we're configuring this locally on the device
rather than using external scripting,
we can use the Applet keyword in our instance.
And then you can see that we need to give that a name.
I'm going to name that something just very intuitive.
I'll name it AUTO NO SHUT.
And if we hit Enter,
you'll now see we're under Applet Configuration mode.
And now, the next thing we need to do,
is we need to define an Event Detector.
So if we say Events and we look at Contextual Help,
you can see those many, many options that we have here.
In our case,
since we're going to be using Syslog Message Detection,
I'll use the Syslog keyword to detect the syslog event.
So I'll say syslog.
And, again, many, many events that we can do here,
many things we can use.
We can detect specific syslog warning levels if we want,
we can detect specific facility codes.
In my case, I'm going to use the Pattern keyword
and that's going to search for a specific string.
It's going to look through our syslog message queue and,
if a match is found to this string of text that we define,
then it's going to trigger an action
that we'll define later.
This string pattern needs to start with a quotation mark,
so I'll put in a quotation mark,
then I'm going to paste in the syslog message
that I copied earlier and then I want
to end that with another quotation mark
and I can hit Enter to accept that.
Now that we have an Event Detector configured,
we can configure what action we want taken
in the event that there is a trigger.
So we can say Action,
and we need to give that a name as you can see here.
Now it's a pretty standard convention
to name those actions in a numerical sense.
So in this case, I'm going to make that action 1.0.
If I have additional actions,
I'll make those 1.1 and 1.2 and so on.
I'll number those sequentially.
And if I configured other actions for this same detector,
I might change those to 2.0, 2.1, 2.2 and so on.
That's just my own preference,
so obviously you can use whatever convention
you find most intuitive.
If we look at our Contextual Help options again,
lots of things we can do
in the case that this is triggered.
In our example, I want to re-enable this interface,
so near the top we see the option for CLI.
That's going to allow me to execute a CLI command.
And that's exactly what I want to do.
I'm going to be able to run specific commands
once this is triggered.
So I'm going to say action 1.0, CLI command,
and then I can put the actual command that I want ran.
And that, again, needs to be in quotation marks.
So, the first thing I want to do
is I want to make sure it goes under enable mode.
So I'll make the first one Enable,
then I can say action 1.0, CLI command.
The next thing I want to do is go under
Configure Terminal mode.
Actually, I almost made the wrong number there.
I'll make that 1.1.
Then I want to define another action,
action 1.2, CLI command.
The next command that I want ran is
I want to go under interface configuration mode.
In my case, for gig 0/1.
And finally, action 1.3 CLI command.
I want to do a NO SHUT
and that's going to re-enable the interface.
So let's test this out now.
Exit here and we'll go under our interface gig 0/1
and I'm going to run the SHUT command
to shut down that interface.
And we're going to see a message pop in stating
that the interface was set to administratively down.
And we see that here.
The interface was changed to administratively down
and almost immediately,
the state changed to back up.
We see a second message saying that the state
of interface gig 0/1 was changed to up.
If we go and do a quick show IP interface brief,
you can see that in fact this gig 0/1 interface 10.1.1.1,
that is in fact in the up up state.
So this EEM configuration worked
exactly as we expected it to.
Let's try one more example of this in use.
And what I'm going to do here is I want to limit
the output of a show run for our users.
So let's go back under Global Configuration mode
and let's say Event Manager Applet.
And again, we need to give that an intuitive name.
I'll call it NO-SHOW-RUN.
And, under here, we'll say event CLI pattern.
And that's going to allow us to match a pattern
based on the input in the CLI.
So, whatever we define in our string here,
it's going to detect if that was entered into the CLI
and that's going to trigger.
So let's say we use again quotation marks
and I'm going to use the 'Show Run' command.
So if a user puts in
anything matching this pattern in the CLI,
that could be Sh Run,
they could put Show Running - config,
they could put Show Run
they could put the full command,
any possible variation of that,
that's going to trigger.
And that's going to allow us to control what happens.
So let's do that.
And if we look at Contextual Help,
the option of interest that I want to point out
is the skip keyword.
This is going to determine whether or not
this command is skipped
or whether it is allowed when it's detected.
In my case, since I don't want to allow that,
I'm going to say Skip and we'll have to say Yes or No.
I'm going to say Yes to skip that CLI command execution.
The next option we want,
if we look at our help output,
is the Sync keyword.
Again followed by Yes or No.
This is going to run the policy either synchronously
or asynchronously with the CLI.
So if we choose Yes, that's going to be synchronous,
if we choose No, it's going to be asynchronous.
Since we're using this to limit the CLI outputs,
we want the policy to run
before the CLI command executes
rather than waiting for the CLI command
and taking a chance of that actually presenting an output.
That's not what we want.
So we'll say Sync No and we'll hit Enter.
Now that we've defined that,
we need to define an action to be taken.
In my case, I'm going to choose to present users
with a message letting them know
that this command is restricted
and suggesting that they contact an administrator.
That's something that may be configured
for lower level users,
maybe a tier one help desk support, for example.
So let's say action 1.0
and from Contextual Help
we see those many options.
And down near the bottom
we're going to see the Syslog option.
This is going to allow us to log a syslog message.
So let's do that.
Syslog message and we can follow that
with the actual message string that we want output.
So, again, that needs to be in quotation marks,
so I'll say, "Command not allowed,
please contact an administrator."
We'll end that with another quotation mark with Enter,
and let's test this out.
Let's go back and let's try to do a Show Run command.
And notice there's no output for the Show Run command.
The only output we get is our syslog message
stating that the command has been disallowed
and that's exactly what we want to see in this case.
Now these are just a couple of examples,
but, again, there are many, many numerous options
here for using the Embedded Event Manager for automation.
We can even use this in conjunction with IP SLA tracking,
which we looked at in our advanced IP SLA video,
where we looked at how we could track
those WAN changeovers if we have multiple ISPs.
This is a way that we can help automate
and track failover alerting.
We can even configure EEM to email administrators
in cases where that would be applicable.
Remember that the actions
and the event detectors available to you,
those are going to depend upon your specific IOS version.