Network Programmability

So recently I have been giving thought about my future in IT and I've been finding myself becoming more interested in network engineering. Something that has steered me in that direction has been the topic of network programmability. I noticed this is an up and coming trend and I find the idea to automate your network setups very interesting. The most popular programming tool used for this being Python. I like that Python doesn't seem like an overly complicated program language, I've always wanted to try my hand at programming and I can apply into my networking career.

Is anyone here familiar or already working in the field with network programmability that can share their thoughts on this or give advice on how to best approach this skill set?

Find more posts tagged with

Comments

stlsmoore

Haven't experienced much with network programmability yet outside of basic expect scripts, etc. Someone can chime in I'm sure but it's still bleeding edge. With that said Python is never a bad thing to learn, I use it to help me with small tasks here and there.

I'm currently getting more involved with "Cloud" as there's still quite a bit of network design and implementation needed. Albeit more simplified and stripped down than any CLI you'll come across. Cloud providers such as AWS and Azure is a bit more vetted now with businesses. I'm starting to see a lot of businesses move or at least create test infrastructure environments with cloud vendors. Almost every Network Engineer job app I see mentions experience with a cloud vendor in some form.

hurricane1091

Bleeding edge is right. However, we're seeing more scripts being created to do tasks. Or really, we're seeing more people take advantage of this and Cisco is actively encouraging folks to do these kinds of things. Example: we use ANSIBLE to deploy mass config changes. We use it to set up new routers too out in the field and just plug in different values for the variables. It works well but has short comings.

Now, they are pushing equipment that is DNA center compatible these days. I am going to be ordering Catalyst 9300 access switches but there's no way we will be automating them with something like Cisco DNA. I've only had a brief introduction to the stuff, but I was told that the appliance itself has a list price of over $70k, plus additional licensing is needed per port on the switches if you want to use DNA on them. It's just cost prohibitive at this point, and the rest of our network is "legacy" equipment. If we were bigger, maybe we would make the investment. 500 million dollar company isn't terribly small though and we're still not doing it. I know of others who want to have a next-gen datacenter, but can't get there due to cost. Plus, we really do not know exactly what will be possible as well. I think everyone gets there eventually, but it's slow going in my books.

networker050184

Python, bash, Napalm, Ansible, Salt. Those seem to be the most popular currently used in network automation. I'd personally concentrate more on being decent with scripting and learning Ansible/Salt first. These will be much more valuable in the short term than starting down a path of being a Python programmer. Those skills will develop with time.

MitM

hurricane1091 wrote: »

I am going to be ordering Catalyst 9300 access switches but there's no way we will be automating them with something like Cisco DNA. I've only had a brief introduction to the stuff, but I was told that the appliance itself has a list price of over $70k, plus additional licensing is needed per port on the switches if you want to use DNA on them. It's just cost prohibitive at this point, and the rest of our network is "legacy" equipment. If we were bigger, maybe we would make the investment. 500 million dollar company isn't terribly small though and we're still not doing it. I know of others who want to have a next-gen datacenter, but can't get there due to cost. Plus, we really do not know exactly what will be possible as well. I think everyone gets there eventually, but it's slow going in my books.

I'm also getting some 9300's most likely, but don't think we'll be going with DNA for now. We're also a 500 mil company, but as you said, probably too much of an investment right now.

For the OP, python is good to learn. I haven't looked at it yet. You can probably check out some affordable courses on Udemy. As networker mentioned, Ansible is also valuable to learn

Hondabuff

MitM wrote: »

I'm also getting some 9300's most likely, but don't think we'll be going with DNA for now. We're also a 500 mil company, but as you said, probably too much of an investment right now.

For the OP, python is good to learn. I haven't looked at it yet. You can probably check out some affordable courses on Udemy. As networker mentioned, Ansible is also valuable to learn

We are a $4B a year company and laughed at the price. Cheaper to hire another CCNP Level Engineer.

stlsmoore

Hondabuff wrote: »

We are a $4B a year company and laughed at the price. Cheaper to hire another CCNP Level Engineer.

Is it me or does it feel as if network vendors are stuck in a rut? They're attempting to push the industry forward with SDN, programmability, but it's so cost prohibitive not many businesses are biting. Honestly I haven't heard the SDN buzz word nearly as much this year compared to a few years ago.

ccie14023

Yes, I actually have been working on this for a couple years now.

Python is certainly a good starting point. You don't need to become an expert developer to take advantage of Python's capabilities. Even basic scripting is a great way to start taking advantage of automation. I always recommend Sweigart's Automate the Boring Stuff, which is not a network-specific book but is a great intro to Python which also has a lot of useful chapters on things like reading data from spreadsheets.

You'll want to learn about YANG data models and the protocols that consume them, like NETCONF/RESTCONF. NETCONF/YANG is available in IOS XE 16.5 and higher. The basic idea is that pushing/reading CLI is not too easily with a script, since programming languages like to work with structured data. I recommend Cisco DevNet (developer.cisco.com), and if you have access to the Cisco Live content library I can recommend a few sessions (including my own

).

Ansible, as some others mentioned in the thread, is a good starting point as well and will be more widely deployed than Python scripting, in my opinion. Most of the Ansible automation has been CLI templating, but they are building out their networking capabilities and will be consuming the NETCONF/YANG stuff soon. Same with Puppet, which is less popular in the networking industry, but is doing a lot of work in this area as well.

As for DNA Center, which someone else mentioned in the thread... I work on that as well and it's not really a programmability tool. It is more of a controller/management system. Catalyst 9300/9500 is not strictly required for DNA Center or SD-Access, but I do recommend those platforms for programmability as they have the most features as well as an x86 processor. Previous switches had MIPS. The x86 is nice if you want to do application hosting on the box. DNAC is indeed expensive at this point, and not the kind of thing you'd throw in the home lab.

It's a brave new world but you might as well get into it!

Spiegel

Thanks for the responses guys. That was good information. I'll definitely take them into consideration when approaching this area in the near future.

thomas_

Network programmability sounds really interesting to me as well. Unfortunately, I'll probably have to change jobs in order to be able to do more with it as I'm kind of limited in what I can do right now due to work environment constraints. Although they probably won't fit your definition of network programmability, two things that haven't been mentioned yet are IOS shell and Guestshell(16.6 CSR) release. I've only used IOS shell, but read about Guestshell here: https://www.reddit.com/r/networking/comments/6lm34k/cisco_is_coming_out_of_its_shell/

I haven't done anything mind blowing with IOS shell, but it does give you the ability to write some "for" and "while" loops along with some "if" statements and conditional testing. My favorite thing to use it for is it's grep utility, so I don't have to be limited to the include/exclude/begin pipe options.

For example, if you wanted to know how many interfaces were currently showing connected on a switch without counting line by line you could do something like:

show interface status | grep -c connected

and it would give the number of lines that had the word "connected" in it. I believe you can also do multiple greps such as:

show interface status | grep connected | grep 675

so the above would show you all of the interfaces that had a status of connected AND a vlan of 675(or description if you happened to have an interface description that had 675" in it. Using the regular CLI "include" word after the pipe you would be limited to a logical OR by doing:

show interface status | include connected|675

This is useful for somethings, but not useful if you are trying to see what matches both criteria instead of just one criteria.

The "for" loops get a little more interesting. Let's say that you wanted to look at the running configuration of certain ports that matched a certain criteria such as in a certain vlan, had a certain interface description, etc. You could either do a show run interface gix/x for each interface that you wanted to look at or page through the entire running config. You could start at the beginning of the interface configurations using the "begin" keyword after a pipe, but if you were on a switch with a couple hundred interfaces that will still take you awhile. With a "for" loop you could do something like:

for x in `show interface status | grep 675 | cut -d" " -f1`; do
show run interface $x;
done

For this example, lets say the ports you were interested in looking at were all in vlan 675. Let's also say you know there's probably more than 50, but less than 75 ports, so it would take a lot of "show run interface gx/x" commands to look at the running configs for all of the interfaces in vlan 675. You would also probably have to do a "show interface status | include 675" and copy the output to a notepad, so you knew what interfaces to look at.

With the example above, it would find all the the lines of output that had "675" in it, it would then cut the first field using a space as a delimiter. In the "show interface status" output this would the shorthand interface number such as "Gi1/1", "Gi1/2", etc. It would then proceed to do a show run interface using each of those interfaces that were in vlan 675(or had an interface description that containted "675".) This would save you some time.

There's also the possibility of making some configuration changes. Let's use the same example as above and go even further. Let's say you wanted to change the vlan of the interfaces in vlan 675 to vlan 775. You could do something like:

for x in `show interface status | grep 675 | cut -d" " -f1`; do
config t
interface $x
switchport access vlan $x
end;
done

Now, obviously the above isn't ideal as you would be going in and out of configuration mode, but I think that should work(I haven't tested that exact code). There's probably some tweaks that could be made where you only went into configuration mode once and then executed those commands on all of the matching interfaces, but I think you get the point.

I've also used IOS shell to compile information that was found in different commands to only output the information I wanted to see. Off the top of my head it was something like:

for x in `show interface status | grep <something-matching-part of interface description>; do
DESC=`show interface $x | cut -d" " -f3`
MAC=`show mac address-table interface $x | grep <something I don't remember> | cut <some other stuff I don't remember>`
CDP=`show cdp neighbors $x | grep <something I don't remember> | cut <something I don't remember>
echo "*************************"
echo $DESC
echo $MAC
echo $CDP
echo "*************************";
done

The concept of the above pseudoscript would be to take the matching interfaces from the "for" line and then use those interfaces in the other commands. As the other commands run they would be stored in variables and at the end the variables would be printed to screen. Doing something like this allowed me to gather all the information I typically would look at for a bunch of different ports without having to type in 3 or 4 different commands to look at each port. I got something similar to the above working.

Obviously, all of the other things that were mentioned by others is probably a much better way to accomplish network programmability, but the IOS shell and Guestshell have some useful features if you are stuck in the dark ages of manually logging into switches. Also, there are better tools that will do the same thing I've described and get much of the same information via SNMP polling, but like I said if you are stuck at a medieval employer when it comes to networking stuff, it can be useful and save some time. There's also something called EEM or embedded event manager that is also pretty interesting. I almost forgot to mention macros as well. I really need to start looking for another job, so I can mess around with more interesting stuff.