This blog is co-authored by Ioannis Katerina and Theodoridis Dardoufa.
The text posted in this post is not in virtually any real way representative or binding because of their organization. Some information are omitted for confidentiality factors purposefully.

Ioannis is really a network and techniques engineer focusing on fault, performance, and services level overseeing for the Network also it services. He functions in the Network Section, in the IT Division of the lender of Greece, as a known person in the NOC team. He retains the CCNP Business and DevNet Associate and Expert Certifications (DEVASC, EN-AUTO). He doubles in Network devnetAutomation and is really a known person in the DevNet 500 and the DevNet Course of 2020.

Katerina is really a network engineer, functioning within the NOC team within the IT Division of Financial institution of Greece. Besides genuine networking aspects (design/execution), she’s an extremely strong knowledge on functionality and fault monitoring, and is passionate about troubleshooting weird protection and networking issues extremely. The CCNP is kept by her, CCNA and ccdp safety certifications and can be an active DevNet member.

Our last post (“Using Automation for a DataCenter Network Core Migration”), year ago was one. Year this, while we were going to the Cisco Reside Europe meeting in Barcelona, we had been asked to accomplish a follow-up blog describing what we’ve been doing since. 12 months so a lot of things had occurred since final.

“Make time and energy to save time”

You should invest amount of time in automation, to save period with it eventually. Among our biggest time starving duties was sustaining our open up source based network overall performance monitoring infrastructure. We’d to improve our monitoring toolset completely for a couple of automation capable equipment that would be prepared for the next phase inside our monitoring, when that could become achievable: Grafana, InfluxDB, Telegraf. To reduce the necessity for maintenance jobs, the complete platform would operate on Docker.

A complete large amount of first steps there, but the total outcome was rewarding and automation helpful, while at the same time providing the benefits of Infrastructure as Code. Furthermore, the info itself was designed for processing and manipulation now. In order to study about how it had been done it is possible to read these two blogs: part 1 and part 2. Also, here’s how we utilized that versatility during lockdown for creating VPN Users graph report using python code.

“If it’s built by you, they shall come.”

At that right time, we furthermore discovered Netbox. My concept and the guts piece of among our bigger tasks had been that there are particular points of access for details in a checking infrastructure, in which a new device instantly is picked up. For Cisco network products, and our very own network those drop to two specific factors:

• Cisco Prime Infrastructure
• Our NMS system

We decided we’d write code to automatically and continuously evaluate our active network stock (NMS/Cisco PI) with this intended one (Netbox). This might allow us to:

onboard devices to Netbox if they’re not there

• Automatically,
• Identify differences in today’s network status when compared to original network style and get alerts about any of it.

Back again to the starting

Adjustments and Triggers

In June 2019 during Cisco Live US the announcement made, about DevNet Certifications caused the system world to shift right into a new stage. I started studying across the locations defined by this alter as “Enterprise Automation”. That included Design Powered Telemetry and Programmability, Netconf/Restconf/Yang, Yaml/Jason/XML, Relax APIs, DevOps tools and principles, etc. Cisco DevNet provided learning labs/tracks and a substantial Sandbox Infrastucture, which made the vacation fascinating.

Cisco Live European countries Barcelona 2020 was full throttle on DevNet. Therefore many periods in parallel therefore many workshops. I enjoyed conference the DevNet and PyATS groups really. Talking about with Katerina about her impressions and ideas, I was pleased to know she has been content about how conscious we were about present developments in system automation, but additionally about our expertise and the initiatives we are producing to integrate it in management and monitoring.

From Individual Growth to Working as a Team

The DevNet experience around that true point have been concerning the journey of the average person. It’s a robust message, pushing one to a large culture change, designed to established you on that route, where you rediscover your capabilities, your relationship to simple development skills, that you can reapply to understand creative and new methods to leverage your network, your network software program and applications.

Motivation and power

Katerina, using that power that originated from her clear look at of her very own goals and skills but also sharing a standard vision, found speed. Giving an answer to all my problems for new concepts without hesitation, and defining her very own targets, she developed the next:

• A python script that could get a set of gadgets with ip, hostname, kind, series, design etc from Primary Infrastructure utilizing the REST API, in order that it could be utilized by us to populate Netbox with those devices. It can be discovered by you in github, under DeviceInfo_from_PI and contains been accepted and published within the Cisco DevNet Code Exchange.
• A different python script that could get a full set of ip addresses out of every device managed within Cisco Prime Infrastructure therefore we’d later fill them set for each device currently integrated within Netbox. It’s also on github under CollectIP, furthermore published in the Cisco DevNet Code Exchange.
• She studied Nornir utilizing the documentation, our own efforts and the wonderful videos developed by IPvZero and created a script that connects inside parallel to all or any our branch routers, searching the routing desk for a specific path, checking if the service provider router is on its major uplink or the back-up one. The provided information is received in seconds via email. The script can be acquired on github under Nornir_Check_Route

I actually asked Katerina, “what can you say if someone asked: What drives you personally to automate, help make scripts, attack another target, and keep on?” She responded:

“I have constantly considered myself an old-school network engineer… I’m very keen on routers/switches/protocols and so on. Thing is, that I was seeing network programmability showing everywhere up. I was needs to experience left behind. Fortunately my colleague and buddy held bombarding me with info on the subject, so to end up being frank I had been pushed by him, mentored me and obtained me involved. Since that time I have arrived at appreciate scripting and automation. Some effort is necessary by it to obtain things started, but the rate and the accuracy of the ultimate end result will probably be worth it.

What I really appreciate about automation and what motivates me personally (besides the regular “nagging and pressing” of my workmate) is determining how to utilize it to handle use cases inside our own work place. The thrill to do something new, the excitement of troubleshooting and racking your brains on what went wrong, and soon you achieve your objective! These are items that I, as a system engineer, really enjoy!!!! On the other hand, I have already been using enterprise system tools for a long time and I has been a bit reluctant to provide them up for additional frameworks and automation. What I noticed is that via making use of automation and scripts I wasn’t giving anything up. Rather, I could make even better usage of these equipment and over time this has arrived at save me time and energy to deal with another network stuff I love!”

As a team, we have been a lot more than our sum

You might say “Good! He/She is up to speed! We have been a united team!” Well, no. While that’s very good news, it doesn’t cause you to a development team.

As network engineers, we can’t split the CLI. One person gets control at the right time, and issues commands. We are able to discuss about style and configuration all we wish, make decisions jointly, but at the ultimate end, only one individual shall do the required configuration about the same device simultaneously, at any given second. Also you can find limited methods for you to get to the required result so when you perform, that is clearly a state.

Development is different. Exactly the same project, the same script even, could be cut in tiny items which can be assigned to each united group member. They can develop program code in parallel, provided that they acknowledge certain specifications and principles. That doesn’t come simple with network engineers once we are more familiar with doing things inside our own corner, therefore we have a tendency to develop automation tasks just as.

Last February, I made a decision to take the DevNet Associate examination. The test requires one to study content designed to offer you a good flavor of the various tools and methodologies you will need as a programmer, to become a useful and successful person in a development team.

Here’s a short tale to illustrate this aspect:

I wanted to turn the complete network status right into a status adjustable with PyATS watching over it having an alerting device, like Nagios for instance.

We developed the Nagios plugin with python program code that would get yourself a “golden” construction for a network gadget, store it, when run again then, would check the existing running configuration contrary to the golden. If there have been differences, it would develop a critical alert! Or even, all is OK! We’d run Genie instructions in natural python of CLI rather, and contact a python script being an argument to the PyATS docker container. The PyATS group assisted us with some instructions.

As I was getting ready to write the program code myself, my partner defeat myself to it: “hey I wrote the program code for PyATS operations, it is here, it works!”

My first response was shock. I had been glad of course, but thought “hey also, I would do that!” Also it hit me then. This is exactly what the team is approximately. It’s not really about “Hero lifestyle.” We had been co-developing in exactly the same program code, bringing everything together. It had been raw and uncut needless to say. But this is the genuine challenge. As a united team, we are a lot more than our sum. With the proper level of resources and time, we can practically create anything (or at the very least anything we are looking for) when we interact. The real problem we have to increase to as a growth team, is how exactly to benefit from our full potential.

The code and documentation for the Nagios plugin is published on github here and on the Cisco Devnet Program code Exchange here. Before that, in line with the original program code Katerina intended to get the set of devices from Primary Infrastructure, A python was made by me script that may log in Prime, get the set of products and generate PyATS testbeds per gadget location, to allow them to be utilized by you for the PyATS test scenarios. If it’s maintained by Primary, a testbed could be got by you with it. The program code is released in github here and inside the Cisco DevNet Program code Exchange here.

Epilogue – Future programs

This is a wedding anniversary post, yr after our first 1 in the cisco programmer blog one. Year it had been about person motive and inspiration final. This season it’s about group potential and growth. In case you are brand-new at this, you alone are not, the beacons lit are, the grouped community keeps growing. Study fellow champion Daniel Dib’s post about “Getting Over My Concern with Network Automation” to greatly help yourself find your personal motive and inspiration.

For those who have travelled this path and also have found the lighting already, time to go and obtain some more people who have you back, and create a united team. The experience will be rewarding for several of you.

In the next time period we intend to fulfil our programs to totally leverage Netbox’s possible through python scripts so we are able to keep an eye on device changes in the network, supply extra capabilities via custom python scripts released from Netbox UI for the collaborating teams (e.g. Helpdesk) to supply added value with features not already accessible with our group of traditional monitoring equipment. We also intend to use Cisco Primary Infrastructure as a powerful inventory for active system gadgets for both PyATS functions and Nornir duties and leverage our NMS API to obtain programmatic usage of our network alerts motor.

Finally, we plan to give Streaming Telemetry a spin as as period allows soon, because the Netconf plugin for Telegraf out is nearly! To help we grow, we intend to use tools and solutions to work efficiently together. Develop gitlab internally maybe, as a begin, and develop a common developer atmosphere predicated on docker containers, to obtain out of our WSL boxes and nearer to production. We‘ll notice you all next season

The post A Development Team is A LOT MORE THAN the sum of the Its Parts appeared very first on Cisco Blogs.