Now some good news.
Before we get into the network automation section you don't have to learn python for the CCMA exam that's
covered in the Cisco definite certification.
I took the CCMA and definite associate exam on the same day.
I've spoken previously about this early in the course but I'm going to replay parts of that video in
this section just to remind you of my thoughts.
When I took the exam the CCMA examined testing on topics such as REST API Jason formatting that's covered
in the automation and program ability section of the blueprint.
So as an example make sure that you know how to interpret Jason encoded data.
Make sure that you know how to describe the characteristics of rest based APIs so as an example when
I want to get data from a survey using a REST API that's a get if I want to delete some data it's a
delete MAKE SURE THAT YOU KNOW THE REST API verbs but you don't have to write Python code using REST
API.
You don't have to learn answerable for the exam.
Now in this section I'm going to show you python scripts.
I'm going to show you animal scripts.
You don't however have to learn that for the CCMA exam.
You need to learn that for the definite exam and the developer certifications.
Now is it recommended that you learn Python.
Definitely.
If you're interested in getting ahead in your career learn Python learn animal.
I've been seeing these things for many many years.
Years ago I was explaining the separation of the control plane and data plane.
You can see this video on YouTube as an example made many years ago.
This stuff has now become mainstream.
It's important that you learn Python and sensible for the real world and to get ahead in your career.
But for the CCMA exam you don't have to learn python scripts.
You don't have to learn animal scripts.
Now if I hear that this has changed that now they testing your coding ability.
I'll update this video.
But at the moment because I haven't heard any new updates you can assume that you don't have to learn
python and sensible code for the exam.
You need to understand the principles.
So as an example here they talk about explaining how automation impacts network management.
Let me tell you the world is changing with network automation in the same way that we had autonomous
access points in the past and they are now managed using a controller.
The idea here is we're going to have a controller that manages lots of devices.
Now in the first sort of SDM or software defined networking implementation the protocol used was open
flow.
There's a big difference between the way open flow did things and the way network automation is done
today in the purest form of open flow.
The switches or devices in your network become dumb.
The controller which would simply be a linux ubuntu server as an example controls the devices in the
network.
They lose their brain.
So in the CCMA they talk about separation of control plane and data plane and northbound and southbound
APIs as a start understand the following.
Where is the brain.
Where is the intelligence for the network in the purest open flow implementation.
The brain was removed from the networking device and put into the controller.
If we had 100 routers or 100 switches in a traditional network we have 100 brains every router every
switch controls itself.
It has its own data plane or forwarding plane that's how it switches traffic from wanting to face to
another.
It has its own control plane.
In other words its own brain.
When a rider using a SPF receives an update it updates its routing table.
So the rub routing information base that's a software based table that's populated with rats learnt
through SPF so the brain is populating the routing table with ruts.
So the rub or writing information base is a software based writing table that's then pushed down into
hardware or into the forwarding plane or data plane.
In other words into the Ferb or forwarding information base.
In other words into hardware.
So we have the control plane which is the brain of the device or SPF is populating the writing information
base.
The brain determines where traffic is routed.
Same kind of idea with spanning tree spanning tree BP the user received.
The brain decides once again which ports affording which ports are going to be blocked.
So the thing to remember is the device has a local intelligence.
The brain is on the device.
If we had 100 routers they would each have their own brain brain is localized to the device.
But in the purest open flow example the devices became dumb and we put the brain into the controller
so that the controller centralized controller was the brain for 100 devices.
That's nice in a way because the controller is a central device that you can manipulate and then update
the forwarding of 100 devices.
It also gives the centralized device more visibility of the network so you can see the entire network
instead of the writer just seeing its own local writing table and not having visibility of the entire
network.
There were advantages with with this kind of model Oh SPF uses the SPF algorithm shortest path first
algorithm.
Very complex.
We have a distributed system that then somehow converges to decide which is the best path in the network.
Much easier to put the intelligence in a centralized controller but it didn't work because as an attacker
which device am I going to attack.
I'm going to attack that centralized device if I can take out the controller.
I not only just take out one router I take out 100 writers I basically can destroy your network by just
killing the controller.
There were other problems because Okay so ever centralized device.
But what about redundancy if this thing dies your whole network dies.
So that kind of sucks.
So what you're gonna do is have more than one controller and now you back to the distributed database
scenario or synchronization issue.
How do I synchronize multiple databases in multiple physical controllers to have a single logical controller.
So there were a lot of other issues with this model became a nightmare.
What happens if the rowdies lose connectivity to the centralized controller.
Think about it.
The Rada has its own localized brain in a traditional networking environment.
If it loses connectivity to another writer that's not a problem because he has his own local brain.
That road has its own local brain.
But if you put the brain in the controller and then the road is loose connectivity to the controller
because a link goes down suddenly what are the riders do.
They have no brain so the network dies or breaks.
So a lot of problems with the pure open flow environment.
They then came up with this hybrid approach where we had some intelligence on the devices some intelligence
on the controller where the controller could override what a rudder was doing so we could write open
flow rules to the rider to override traditional networking.
So the ride as an example switch as an example would do traditional riding or traditional switching
but then we could create extra rules here where I could manipulate the flow of traffic from a centralized
controller.
Now one of the cool things with the open flow model and the whole idea of a controller is these devices
talk to the controller using what's called a southbound API so the controller is sitting over here talks
down to the devices using southbound API.
Notice how I've got my hand up here northbound API is southbound API.
Just think south down North up.
So an application developer could write an application talk to the controller using a northbound API.
Typically these would be Rest Api wise.
That's very common today and then a protocol would be used on the southbound API so the controller would
talk down to the riders and switches using some kind of protocol which could be open flow.
That was the original idea.
Could be s an MP.
Don't forget a simple network management protocol been used for years from management stations to networking
devices so S&P could be using the southbound API.
We could use net conf we could use rest conf we could use multiple other options for NPR less BGP.
Basically there were many protocols for CCN HS just have an understanding that we could use rest conf
we could use rest api is actually we could use CLIA we could use as an MP.
Now you don't have to use the rest api of the controller to manipulate devices.
Typically the idea was you you were an application developer used a python script that wrote rules to
the controller which then sent it down to the devices.
The advantage of that was this concept of abstraction.
Complex to write rules to devices.
That was what they said.
Much easier to write stuff to a rest api on the controller so you would write rules to the controller
using the rest api so application uses a high level programming language like Python.
Easy Rest Api in the controller which then uses multiple protocols down to the devices open flow.
Net conf BGP unless less whole bunch of weird and wonderful protocols down to the devices you as the
application develop are being abstracted from the networking devices.
That's the idea but you could do away with a controller and just configure the network devices directly
using a Python script or animal script.
That's what I'm going to show you in the course because that's a lot easier actually to get started
with.
It's a lot easier to say okay let's write a simple python script that updates something on the broader
or pulls information out of the router or switch.
You can mimic this with physical equipment in a lab or in genus 3 or viral or even if you if you like.
So I'm gonna show you some examples of that but just remember you don't have to learn python for the
exam.
You don't have to learn python or sensible programming for the exam but for the real world I'd suggest
that you do learn both of those.
So here they talk about separation of control plane a data plane.
Just note where is the brain local device.
In the old days control plane forwarding plane or data plane was in the device.
So think of the data plane as the forwarding through the ASX.
I've got a router.
Traffic arrives on one interface it gets switched to another interface so data gets sent through the
device.
It's switched on the data plane or forwarding plane that still resides in the device.
Typically it's done using A6 but the control plane or the brain where does it reside.
Today we still want to have the brain in the device open flow the brain was removed and put into a separate
controller.
We don't want to do that.
Cisco devices didn't really support open flow.
They still don't.
The idea is the brain remains on the device but we can use a centralized controller to configure the
devices.
So rather than making the device done we still allow them to do their forwarding still allow them to
have their local brain but we can configure the devices either directly or through a controller which
makes it easier to manage many devices.
So that's one of the central ideas of a controller based network.
Now what I haven't mentioned she has the management play actually three planes control plane or forwarding
plane.
It's like saying write a router.
How is the traffic forwarded through the device.
That always remains on the device because we want high speed switching or forwarding on the device brain
where does it reside typically resides on the device.
But we could have put it into a controller.
Where's the management.
So what's the management plan.
We typically manage a Cisco device using a console or remotely would be telnet bad idea and SSA.
So how do we manage the device now us as humans would use one of those interfaces to configure the device
but to manage the device using a application we in the old days would use SMP simple network management
protocol is an MP has issues.
No one is an MP Virgin wanted to are insecure very easy to hack.
Bad idea to use S&P version 1 and version 2.
It's an MP version 3 supports encryption and authentication much better but it's an MP is not easy.
The OED and the way to extract information from a device is difficult so the rage today which has actually
been going on for a few years is to use a API application programming interface again.
Rest is one of the most popular API is used all over the place.
So when we transition from being a pure network engineer to doing more programming.
The guys from the programming world are used to rest api.
They used all over the place once again in applications.
So when they want to configure network devices it makes sense that that device has a rest api but just
be aware that a lot of old devices will not have a rest api.
You need to use a modern Cisco network device to get a rest api.
So just because rest is cool doesn't mean that all devices are going to support rest.
So in the examples that I'm going to show you in this course which is very much based from my original
Python course I'm going to show you how to configure the devices using telnet and SSA.
Because that's an easy way to get started.
Start with the basics at CCN a level then go and do your definite associate exam.
I highly recommend that you do the definite certification so get your definite certification so that
you can prove to employers that you are not just a network engineer but you also understand programming.
Now as I've said I've been talking about programming for a long time.
I spoke about open flow more than five years ago.
So the idea is this stuff has been bubbling up in the industry but now Cisco have formalized it.
So my recommendation is learn Python and sensible learn the stuff for the real world not for the CCMA
loner for the real world and for the definite certification and go and get your definite certification
as soon as you can so that you can prove to employers that you're not just a network engineer but you
also understand programming.
I'm afraid that being a traditional network engineer with no understanding of programming is over you
will need to learn programming if you wanted to have a good job in future I'm really glad that Cisco
have done this but they've only put 10 percent of the exam being automation and programming so automation
program ability 10 percent of the exam not very big and they use words like explain and compare.
They don't use words like configure or troubleshoot so this is a very high level.
This is typical Cisco way of doing it very high level but then perhaps in the next release of the CCMA
it will become more detailed and you'll be asked more information.