Alright folks, we are now going to begin our automation preparation for the ENCQOR certification
exam.
Let's go out to the exam objectives so we can have a better understanding of what we
are going to cover here.
So 15% of your exam is from these particular videos that we are going to present to you.
So you have Python here, JSON here, YANG, DNA Center, APIs, REST APIs, EM, as well as
Chef, Puppet, Ansible, and SaltStack.
So 15% of your exam is approximately, how many questions would that be approximately?
Let's open up our calculator and figure that out right now.
So that's going to be approximately 87 multiple choice questions plus maybe 3, 4, or 5 simulations.
So from just the multiple choice questions alone, 87 times, we are going to put times
15% here.
So about 13 questions, divide that by 7.
So maybe like 2 questions per topic, so 1, 2, 3, maybe 4 questions per topic down here,
but that's excessive.
4 would be excessive.
So your goal here is to ensure that you have the information and knowledge that is necessary
to address those very specific types of questions on the exam.
So like I've said before, I build my courses based on what?
The exam objectives, but also my exam experience.
So this ENCOR automation preparation is going to be focused on what we need to know specifically
for each of these particular topics.
So EEM, REST APIs, DNA Center, JSON, Python, and so on and so forth to help you get ready
for the certification exam.
All right.
So with that said, let's dive into our discussion on EEM, Embedded Event Manager.
So what is Embedded Event Manager, folks?
Embedded Event Manager is a tool, a tool that is built into our Cisco iOS operating system
that gives us the ability to automate event detection and event recovery or event responses.
So what we create is we create these things called EEM policies, and these EEM policies
could either be an EEM applet or an EEM script.
So the applets are defined using the CLI, and the scripts would be defined using the
TCL tool command language.
So before the ENCOR certification exam, you're going to be tested on EEM applets.
I'm going to repeat that, EEM applets.
So we are not at all working with the TCL scripting in Cisco iOS.
We're going to be dealing with the EEM applets instead.
So the first thing I want to do is just give you a nice example of using EEM just for fun.
It's a fun, silly little example, but it's going to show you how you could have some
automation based on certain scenarios, certain situations that have happened.
So an event is what?
An event is a change of state on our device.
So an interface going up, an interface going down, this happening, that happening, and
so on and so forth.
So based on those things happening, whatever it happens to be, we can define an event that
then triggers an action based on that particular event happening.
So I have pre-configured here one in Notepad that I'm just going to walk through with you.
So it is going to be, do this right here.
So this first one here.
So configure terminal, and then I type an event manager applet to create my applet,
and then I give it a name.
So in this case, I'm giving it the name gigabit 0 slash 1 admin down.
It's just a name, just for fun.
And then here, we're specifically monitoring a syslog pattern.
So if a syslog pattern or a syslog message is generated by our device, specifically one
that says gigabit ethernet 0 slash 1, change state to administratively down, then we have
these following actions that are going to happen.
So what I had to do is I actually had to find out what is that syslog pattern that is going
to be generated when my interface goes administratively down.
So I went ahead and did that manually.
I just brought down the interface, and that was the syslog message body or part of the
syslog message body, and that is what I'm going to use now for my automation.
So if this message is ever created at all or a message is created that has this information
in it, then I want to perform the following action.
So action number one is to generate an actual syslog message.
So create a syslog message that says interface gigabit 0 slash 1 has been administratively
shut down, re-enabling.
So this is a syslog message that I am creating myself now to have generated based on this
event occurring.
Then I want the following commands to be executed.
I want enable, configure terminal, interface gig 0 1, no shut, and then end, meaning that
we are automating these commands so that way that we can bring the interface back up.
That's what's happening in this particular case.
So what we're going to do is I'm just going to copy this right now.
So copy it, and I'm going to bring it over to my device.
So R2 is an example.
We'll type in configure terminal.
I think we already had that copied though, and I'm going to go ahead and put it in here.
Yep.
All right.
And I'll just go ahead and right click.
I want all of that.
All right.
So there we go.
So all those commands have been put in there now.
So if we go to interface, for example, gigabitethernet 0 slash 1, and we type in shutdown, what's
going to happen?
Well, the interface is going to go down, and a syslog message is going to be generated.
And that syslog message that is generated is going to match this one right here.
And what was that one?
Let me show you again.
It's this one right here.
It's going to match this.
And then all of this is going to happen, all of these actions.
Ready?
Let's do it.
So I'm going to shut down the interface, and so there is the syslog message that was generated
from shutting down the interface.
So gigabitethernet 0 slash 1, change state to administrative.
So I have to match that.
That is case sensitive.
That had to be matched perfectly, perfectly, which it is, because I copied and pasted it
right from the iOS when I created that script.
And then you'll see here that this syslog message was generated by EEM.
Interface gig 0 1 has been administratively shut down, dot, dot, dot, re-enabling.
And where is that from?
It's from this.
Action number 1, create your own syslog message that states this.
It did it for me.
And then perform all these actions.
So these actions occurred.
You're not going to see the actions actually occurring, but you'll see what happened.
Our interface went back to up, up.
Why did our interface get re-enabled?
Because those actions were executed behind the scenes.
So enable, configure terminal, interface gig 0 1, no shut end.
And here's the deal.
You need to.
You need to create your actions based on the fact that you are starting in user exec mode.
That's right.
That's exactly what happens here with EEM.
So if you forget enable, you forget configure terminal, you forget the navigation in your
script, it's not going to work.
Keep that in mind.
So it's possible, right, on an exam you could be tested on, oh, why isn't this working?
What is missing?
Think of the process.
How would I enable an interface?
How would I do this?
How would I do that?
You have to specify all those actions in the right order for it to work.
Now you might be saying, well, what about authentication?
What about user name?
That's okay.
Because that is not necessary when you're using EEM.
Because it's being executed behind the scenes by the system, all these actions.
It's automatically privileged level 15.
So you type in enable, it's automatically authenticated.
It's already there.
Why?
Because we created this.
We needed to have the permissions to create this in the first place.
So the system is now just essentially piggybacking on the fact that, hey, you were authenticated
to create this in the first place, and you could do all of this in the first place, so
we're just going to execute it now.
So you don't have to worry about user names and passwords or anything like that.
All right, so there is just an example of having a dynamic EEM applet.
Something has occurred, an interface went down, and then we dynamically re-enabled it.
All right, so let's have some fun with this one now.
We're going to continue on.
In this case, it says, event syslog pattern, so event manager applet, gig01 admin up.
So the other one was called admin down.
This one's called admin up.
If we see the syslog pattern gig01 change state to up, then create a syslog message
that says, interface gig01 has been restored.
And then look at this action.
We could email, so send a message to the mail server at 10.0.3.8 with the subject line,
or not the subject line, with the recipient as itteam at stormwindlive.com from eemapplets
at stormwindlive.com.
So I would have to have a mailbox for eemapplets at stormwindlive.com, and then the subject
line is gig01 up, down, up, body is gig01 was re-enabled because someone administratively
shut it down.
Find out who and take action, so that would be the email.
So let's go ahead and just copy and paste that.
And I don't have a mail server set up right now, so the mail aspect of it is not going
to work, but you're still going to have the opportunity to see, in the end, the fact that
we're trying to contact the mail server.
All right, so there's the other event manager applet.
So now we've got two event manager applets on our device.
So let's go to interface gig01 and let's watch them get executed.
So the first one's going to get executed because the interface is going down, but then when
the interface gets re-enabled, this is what's going to show up.
And we saw that earlier, right?
Earlier it said gig01 changed state to up.
Gig01 has, oh, sorry, gig01 changed state to up.
So by the fact that the interface was re-enabled, then that is automatically going to trigger
this one here.
So both are going to get triggered.
Watch.
Here we go.
So shut down.
So the interface is shut down.
It has now triggered.
There's the syslog message.
We are re-enabling.
And then once it goes up, there's the other syslog message.
Interface gig01 has been restored.
All right, so now that it's been restored, the interface is back up and running.
But there's the email.
Now we're trying to contact the email server.
So I'm getting these error messages all because the email server doesn't exist.
But if the email server existed, we would have been able to successfully send that email
to the mail server who could then give it to the IT team.
So that way there they could take action, do whatever needs to be done, right?
So that's just an example so far of EEM in action, folks, right?
So we've created an applet, and we have defined an event.
And then based on that event happening, we want these certain actions to take place.
So when you create your EEM policy, you're going to name it like we did.
The very first line was EEM or Event Manager Applet, I should say, and then gave it a name.
Then select the event.
You can only have one event per applet, OK, one event per applet.
But you can have as many actions as you need in order to do whatever automation you need
to have done.
So for every single EEM applet, it's one event followed by many actions.
Now when it comes to our EEM applet, what type of event detectors do we have?
Well, it could be an application event, a CLI event.
It could be counter events.
It could be IPSLA events, NetFlow events.
It could be none.
Meaning you just manually trigger the applet whenever you need to.
It could be based on SNMP.
It could be based on syslog, as you've seen in my example so far.
It can even be based on like a watchdog, a system monitor event, or a timer event, and so on and so forth.
And then what are the actions you can take?
Well, you've already seen actions like CLI actions, but you could also have email actions as we saw as well.
You can manually have actions occur.
You could generate an SNMP trap.
You can even just print text to the terminal window if you want to.
So for the certification exam, make sure you are well aware of what you see on this page, right?
You name it.
Then you have one event and then multiple actions in order to accomplish your objective.
Very, very, very important.
All right, so the example we just saw, those examples are really good examples that I did live for you.
I also have them in the slide deck if you ever want to go back and review them in the slide deck as well.
So for example, in this case, the event manager applet had been down.
It's all listed right here for you to see if you want to review what we just did.
But let me give you some other examples as well.
So for example, manual example.
First of all, how do you manually create an EAM, or not manually create one, but create an EAM applet that is not dynamic?
It's manual in nature, meaning it does not get triggered unless you just simply manually start it, right?
Your event type, take a peek at this, your event type is none.
That's it.
Event none means manual.
That's right.
So I type in event manager applet, give it a name, and then you type in event none, and event none means I will manually trigger it.
And how do you manually trigger it?
You manually trigger it from privilege exec mode, and you type in the command event manager run, and then the name of the policy, and that's how you would run it.
So event none means it's a manual policy, and then you use the event manager run command in order to execute it.
And so in this particular case, you'll see that it has run successfully.
So let's read through our policy here.
So event none, action one.
So when I manually trigger this policy, action one says create a syslog message.
My example manual policy has been triggered.
So down here, interface gig01 is now disabled because someone ran the manual policy.
Oh, my example manual policy has been triggered.
There it is right there.
Excellent.
So when I trigger it, it's generate a syslog message, then the CLI command enable, configure terminal, interface gig01, shut down, shut down, and then end.
And then in this example here, we're even showing you how you could copy the running config to a text file in Flash.
So there is another CLI command, the copy command being executed dynamically, just an example as part of this.
And then action eight says puts interface gig01, puts.
What in the world is a put?
Put means display the message to the console.
That's it.
So there it is.
Notice it's not a syslog message, OK?
So puts shows a message, but it's not a syslog message, so it's not treated as a syslog message.
It's just a message.
That's it.
Keep that in mind.
So you use the word syslog.
If you want to generate a syslog message, as you can see, with dates and timestamps and facilities and mnemonics and severity levels.
But if you just want to put a message, you used puts.
Puts means put a message.
That's the best way to think about it.
Don't forget that.
So as you can see, interface gig01 is now disabled because someone ran the manual policy.
Interface gig01 is now disabled because someone ran it.
That is put.
Notice it's not a syslog message.
So there's an example there.
Right.
Another example is just monitoring, like using something like SNMP.
So in this case here, we have our event manager applet.
I just called it Encore for my example, event SNMP, and then the object identifier for SNMP.
So this is just a made-up object identifier, right?
So don't even look it up.
It's just made up.
And in my case here, so I made it up here for this case.
But in the real world, what do you want to do?
You're going to want to make sure that you have the right object ID for exactly what you're trying to get from SNMP.
And then in this case, it says get type.
Get type is what?
Exact, meaning I want this exact OID.
Nothing more, nothing less.
This exact OID and the information associated with it.
And then the entry operator.
So this is the operator.
Greater than or equal to, greater than or equal to what particular value?
80.
So greater than or equal to 80.
That's what that means.
Entry op, entry value go together.
So entry op is greater than or equal to.
It could be less than or equal to.
It could be equal to.
But in my case, it says greater than or equal to 80.
80 what?
80%, right?
Over some particular polling interval.
The polling interval is 300, so five minutes.
So in this case, this is just an example of our using or monitoring our CPU.
That's what my example is in this particular case.
So the five minute CPU threshold has been breached.
My threshold is 80%.
So greater than or equal to 80% over a five minute period.
So if that SNMP variable is over 80% for a five minute period,
then this gets triggered.
Let me repeat that.
If that OID, that SNMP variable, is over 80% for a five minute period,
then the event gets triggered.
So when the event gets triggered now, we
get a syslog message that says, the five minute CPU threshold has been breached.
It is now above 80%.
It is time to panic, LOL.
And then action 2.0 is a command that generates the show processes CPU command.
So to let us know, hey, show processes CPU.
And notice I have it sorted.
And then append flash colon five minute CPU file.
So what I'm showing you here as an example with the CLI command
is that I can go ahead and I could execute the command show
processes CPU as an action.
And then what we can do is by using the pipe and append,
so pipe and append, we can actually modify a file in flash
all at the exact same time.
So show process CPU sorted.
And then take that information and add it
to that file called five minute CPU file in flash.
There's an example of how we could execute different things.
Next, I've got an alarm example.
So in this case here, this is just about alerting us,
alerting us that something has happened.
So it's a very simple one.
It says event manager applet on core alert.
The event is going to be a CLI event.
So if somebody types something in, we want to know.
So in this case, event CLI pattern conf t,
so configure terminal.
Any variation of configure terminal, that works.
And then our action here you can see
is an SNMP trap formatted as a string, string data.
And it says alarm because someone entered
global configuration mode.
And then our action in this case is our priority critical
message, possible configuration changes happening.
So I have a syslog message and an SNMP trap in this example.
And the syslog message, we actually
set the priority to critical.
And the message, the priority critical severity level,
critical, they use the word priority here,
but it's talking about the severity level of syslog.
And then the message is possible configuration changes happening.
So I'm just showing you examples here in case
you need to know some of these.
IPSLA and tracking objects, we said as well.
So here I have an example of IPSLA.
ICMP echo 8.8.8.8 frequency every five seconds.
And then we have our IPSLA schedule one start time now,
life forever.
And then we have a tracking object keeping track
of that SLA instance.
So track 15 says keep track of the reachability of IPSLA 1.
So in the end, if IPSLA 1 is successful,
the tracking object is up.
If IPSLA 1 is unsuccessful, then the tracking object goes down.
So in this case, since it's a ping, if the ping is successful,
the tracking object is up.
If the ping fails, the tracking object is down.
Now, my event manager applet, we're
going to call it track IPSLA, it is event, event track 15
state down.
So we're only tracking the tracking object 15 if it's down.
If it's up, we don't care.
If it's down, we care.
So you have the option, for example, with event track
to do the state up, the state down, or the state both.
So if it goes up, if you have up, then if it goes up,
it triggers.
If it's down, it's triggered.
If you pick down.
If it's both, then whether it's up or down,
it's going to trigger it in that motion.
So in this case, only if it goes to down
do I want this event to get triggered.
So event track 15 state down.
So if we're up, everything's good.
If we go down, then I want this to trigger.
And the trigger is what?
Or the action, I should say, is what?
Syslog message.
So again, just generating a syslog message.
The IPSLA probe is broken.
And I'm showing you here the priority of 1.
So it's wrapped around the line.
But syslog, syslog message, priority 1.
We have that all part of it.
So now, in this case here, I'm just
showing you down the road, connectivity to 888 fails.
So now that connectivity has failed,
that means the probe goes down.
The probe, or the IPSLA instate, goes down.
Ping fails.
Tracking object goes down.
This gets triggered.
And you can see it just got triggered.
Tracking state 15, IPSLA one reach
really went from up to down.
Boom.
There is your EAM applet.
What is the action?
Generate a syslog message.
The IPSLA probe is broken.
Simple example, just to show you again
how you can combine a lot of these different things
together to get automation results that you need.
Same thing with OSPF debugging example here I have.
So in this case, I'm doing an OSPF debug.
So I called my applet Encore OSPF debug.
Event syslog pattern is what?
OSPF-5-adjacency process one, neighbor, da, da, da, da,
on gig zero one from full to down.
So I explicitly looked up that particular pattern,
that syslog message, by triggering the neighborship
to fail on my device and seeing what shows up.
And as a result of that, I know what it is.
And I can put it as my pattern for syslog.
And so if that ever shows up as a syslog message,
then what do I want to do?
Enable.
Then I want to do logging buffered seven.
I want to debug IPOSPF event.
I want to debug IPOSPF adjacency.
I want to debug IPOSPF hellos.
And then all those debug messages
are going to be generated behind the scenes
and saved where?
To my RAM, to my buffer logging in this particular case.
So that way there, I can now go into the RAM
and I can take a peek at what?
I can take a peek at the debug messages that are showing up.
So we might also want to generate another syslog
message that notifies me or sends some sort of trap
and just lets me know, or an email that lets me know,
hey, we just had an OSPF failure.
You might want to log into R2 and check out
the debug information that's showing up there.
So we can even make it more exciting than it already is.
All right, so those are a bunch of different examples for EEM.
So for the exam one, you got to know what EEM is.
Make sure you know that your applet is going to be named.
You're going to have one event.
And then based on that one event,
you are going to then have a multitude
of different types of actions.
Make sure you know for the exam, syslog, SNMP,
what else, the puts example I gave you,
the email example I gave you, the IPSLA and tracking object
example I gave you.
So there's a reason why I gave you these examples.
So that way there, you have the opportunity
to familiarize yourself with what
is happening in relation to these different types of EEM
applets.
Why?
The most important thing for you to do
is be able to read them.
Read them from top to bottom and understand what is it doing?
What is it doing?
And if you can do that, you're one step closer to success
in the real world and on the certification exam
when it comes to EEM.
Knowing what puts is versus your message versus your email.
If I showed it to you, it's a good thing to remember it
and why it exists.
So that way there, if it shows up,
you're ready to go on the exam.
All right, other than that, folks,
there's so much more in relation to EEM
It could possibly be a five-day course in itself, EEM,
if you really wanted to cover everything.
But we're not going into that much detail.
You have what you need to be successful with EEM
on the certification exam.