- 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
on 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. (heavy synth music) This is one of multiple videos
covering network automation. In the encore blueprint,
we can see in section six 15% of the exam is automation. Topics include interpret basic Python components and scripts. You need to know Python
for the encore exam. You need to be able to
interpret a Python script. So as part of the series,
I'm going to demonstrate the use of Python to
automate network devices. I would highly recommend
that you follow along, create your own scripts, connect to the Cisco DevNet sandboxes that I'm gonna be using
as part of this course or use Cisco VIRL or
CML as it's called now and automate network devices. You'll learn a lot more
by simply doing something. So don't just watch these videos. Try and create your own scripts
as we go through the course. So 6.1, Python, 6.2, construct
valid JSON encoded files. 6.3, describe high level
principles and benefits of a data modeling language such as YANG. You need to be able to describe APIs for Cisco DNA Center and vManage. 6.5, interpret REST API
response codes and results in payloads using Cisco
DNA Center and RESTCONF. You need to be able to
construct an EEM applet to automate configuration,
troubleshooting, and data collection. 6.7, compare agent versus
agentless orchestration tools, such as Chef, Puppet,
Ansible, and SaltStack. In this first automation
video, I'm gonna give you a bit of background
information with regards to network automation. We're gonna cover some of
the foundational topics. Some of this comes from my CCNA course. So you'll see that I reference
some of the blueprint in the CCNA. The reason why I'm doing
this, is I want to lay a good foundation. You need to have a good
foundation to build upon. So make sure that you learn
the basics, but very quickly in subsequent videos, I'm gonna get you creating Python scripts
using REST APIs, using JSON, and using some of the
technologies that they mention in this section. Make sure that you understand
the difference between Puppet, Ansible, Chef, and SaltStack before you go and take your exam. Make sure that you can
interpret Python scripts. Make sure that you know
how to create a JSON file. So make sure that you know how to read whether a file is correctly
formatted using JSON formatting or if it's incorrect. Does it use a single inverted comma, or double inverted commas? Does it use a semicolon or colon? You need to know the format of a JSON file as an example. Okay, I could spend a
lot of time talking about network automation in
this introductory video, but I want to lay a good
foundation in subsequent videos, we'll get into this in more detail. Let's get started talking about network automation fundamentals. (heavy synth music) 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
gonna have a controller that manages lots of devices. Now in the first sort of SDN or Software Defined
Networking Implementation, the protocol used was OpenFlow. There's a big difference between
the way OpenFlow did things and the way network
automation is done today. In the purest form of OpenFlow,
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. As a start, understand the following, where is the brain? Where is the intelligence for the network? In the purest OpenFlow
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 RIB, Routing Information Base, that's a software-based
table that's populated with routes learned through OSPF. So the brain is populating
the routing table with routes. So the RIB, or Routing Information
Base is a software-based routing table. That's then pushed down
into the 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 BPDUs are received, the brain decides once again
which ports are forwarding, which ports are gonna 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 local brain. Brain is localized to the device, but in the purest OpenFlow
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 it 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 this kind of model. OSPF uses the SPF algorithm,
shortest path first algorithm. Very complex, you have
a distributed system that then somehow converges to decide which is the best paths 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 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 kinda sucks. So what you're gonna do is
have more than one controller. And now you're 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 a link goes down,
suddenly what do the routers do? They have no brain. So the network dies, or breaks. So a lot of problems with the
pure OpenFlow 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 OpenFlow
rules to the router to override traditional networking. So the router as an example,
a switch as 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 OpenFlow 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 OpenFlow,
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 on a Southbound API, we could use NETCONF,
we could use RESTCONF. We could use multiple other
options for MPLS, BGP. Basically, there were many protocols. Now you don't have to use the
REST API of the controller to manipulate devices. Typically, the idea was 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
application uses a high-level programming language like Python. Easy REST API on the
controller, which then uses multiple protocols down to the devices, OpenFlow, NETCONF, BGPLS, whole bunch of weird
and wonderful protocols down to the devices. You as the application
developer 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 gonna
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 GNS3, or VIRL,
or even GF if you like. 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 ASICs. 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
ASICs, but the control plane or the brain, where does it reside? Today we still want to have
the brain in the device. OpenFlow, the brain was removed and put into a separate controller. We don't want to do that. Cisco devices didn't
really support OpenFlow, 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, we
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. There are actually three
planes, control plane, or forwarding plane. It's like saying router, router. How is the traffic forwarded
through the device? That always remains on the device 'cause we want high speed switching, or forwarding on the device. Brain, where does it reside? Typically it resides on the
device, but we could have put it into a controller. Where is 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 SNMP. Simple Network Management Protocol. SNMP has issues. Number one, SNMP version
one and two are insecure. Very easy to hack, bad idea
to use SNMP version one and version two. SNMP version three supports
encryption and authentication much better, but SNMP is not easy. The OIDs 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're
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 gonna support REST. So in the examples that I'm
gonna show you in this course which is very much based from
my original Python course, I'm gonna 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 CCNA level, then go and do your DevNet associate exam. I highly recommend that you
do the DevNet certification. So get your DevNet certification,
so that you can prove to employers that you're
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 OpenFlow
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 this stuff for the
real world, not for the CCNA. Learn it for the real world, and for the DevNet certification and go and get your DevNet 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. (heavy synth music)
