Welcome to EveDumps This is a free, Complete course for the CCNP 350-401 ENCOR Exam Training. 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 article on EveDumps 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. This is one of multiple articles 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 read these articles Try and create your own scripts as we go through the course So. 61 Python 62 construct valid JSON encoded files, 63 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 65 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.

67, Compare agent versus agentless orchestration tools such as Chef, Puppet Ansible and SaltStack. In this first automation, Article, 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 articles. I'm gonna get you creating Python scripts using REST APIs using JSON and using some of the technologies that t 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. I could spend a lot of time talking about network automation in this introductory article, But I want to lay a good foundation in subsequent articles 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 t 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, T 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, T 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 , 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? T have no brain, So the network dies or breaks So a lot of problems with the pure OpenFlow environment. T 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.

Cisco CCNP 350-801 Dumps

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 t 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: " 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, T 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, T 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 from the programming world are used to REST APIs t're used all over the place once again in applications. So when t 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.

The process of becoming a networker isn’t considered for the faint-hearted. It requires lots of hard work and nice and trustworthy Cisco CCNP 350-801 Dumps, like that offered at the EveDumps, to clear this grueling exam.


Leave a comment