Now some good news before we get into the network automation section.
You don't have to learn Python for the CCNA exam that's covered in the Cisco dev net certification.
I took the CCNA and Dev Net 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 CCNA exam will test you on topics such as Rest API, JSON formatting that's covered in the automation
and programmability section of the blueprint.
So as an example, make sure that you know how to interpret JSON 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 server 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 APIs.
You don't have to learn Ansible for the exam.
Now in this section, I'm going to show you Python scripts.
I'm going to show you Ansible scripts.
You don't, however, have to learn that for the CCNA exam.
You need to learn that for the dev net 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 Ansible.
I've been saying 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 and YouTube as an example made many years ago.
This stuff has now become mainstream.
It's important that you learn Python and Ansible for the real world and to get ahead in your career.
But for the CCNA exam, you don't have to learn Python scripts.
You don't have to learn Ansible 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 Ansible 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 an 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 Q&A they talk about separation of control, plane and data, plane and northbound and southbound
APIs.
As they start, understand the following Where is the brain?
Where is the intelligence for the network and 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 one interface to another.
It has its own control plane, in other words, its own brain.
When a router using OSPF receives an update, it updates its routing table.
So the RGB routing information base, that's a software based table that's populated with routes learnt
through OSPF.
So the brain is populating the routing table with routes.
So the RGB or routing information base is a software based routing table that's then pushed down into
hardware or into the forwarding plane or data plane, in other words, into the FIB or forwarding information
base, in other words into hardware.
So we have the control plane, which is the brain of the device.
OSPF is populating the routing information base.
The brain determines where traffic is routed.
Same kind of idea with spanning tree spanning tree beeped, user received.
The brain decides once again which ports are forwarding, 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 or they would each have their own local.
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 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 router just seeing its own local routing table and not having visibility of the entire
network.
There were advantages with with this kind of model.
OSPF uses the SP algorithm, shortest path, first algorithm, very complex to 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 and not only just take out one router or take out 100 routers, so
I basically can destroy your network by just killing the controller.
There were other problems because okay, so we have a centralized device, but what about redundancy?
If this thing dies, your whole network dies.
So that kind of sucks.
So what you're going to do is have more than one controller and now you back to this 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 routers lose connectivity to the centralized controller?
Think about it.
The router has its own localized brain in a traditional networking environment.
If it loses connectivity to another router, that's not a problem because he has his own local brain.
That router has its own local brain.
But if you put the brain in the controller and then the routers lose connectivity to the controller
because the link goes down suddenly, what are the routers 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 router was doing so we could write open
flow rules to the router to override traditional networking.
So the router is an example of switches.
An example would do traditional routing 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 APIs.
Southbound APIs.
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 APIs.
That's very common today.
And then a protocol would be used on the southbound API.
So the controller would talk down to the routers and switches using some kind of protocol which could
be open flow.
That was the original idea.
Could be SNMP.
Don't forget simple network management protocol being used for years from management stations to networking
devices.
So SNMP could be used in a southbound API.
We could use net conf, we could use rest conf, we could use multiple other options for MPLS BGP.
Basically, there were there are many protocols for I just have an understanding that we could use rest
conf we could use rest APIs actually we could use CLI, we could use SNMP.
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, you 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 the application uses a high level programming language like Python Easy Rest API and the controller,
which then uses multiple protocols down to the devices.
Open flow net conf bgp ls a whole bunch of weird and wonderful protocols down to the devices.
You as the application developer are being abstracted from the networking devices.
That's the idea.
But you could do away with the.
Controller and just configure the network devices directly using a Python script or Ansible 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 router
or pulls information out of the router or switch.
You can mimic this with physical equipment in a lab or in S3 or viral, or even if you if you like.
So I'm going to 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 Ansible 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 and 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 A-6.
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 A-6, 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 devices dumb, 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 here is the management plane.
They actually three planes control plane or forwarding plane.
It's like saying router router.
How's 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 plane?
We typically manage a Cisco device.
Using a console or remotely would be telnet bad idea and ssh.
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 S&P Simple Network Management Protocol is SNMP has issues.
Number one, it's an IP version one or two, insecure, very easy to hack, bad idea to use S&P version
one.
And version two is SNMP.
Version three supports encryption and authentication much better, but S&P is not easy.
The IDs 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.
APIs 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 APIs.
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 SSH because that's
an easy way to get started.
Start with the basics.
At any 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 Ansible, learn the stuff for the real world, not for the
CCNA, learn it for the real world and for the dev net certification, and go and get your dev net 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 want to have a good job in future.
I'm really glad that Cisco have done this, but they've only put 10% of the exam being automation and
programming.
So automation, programmability, 10% 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 CCNA, it will become more detailed and you'll be asked
more information.