The Napkin Dialogues: Nexus Programmability, Part I

I know that I take a different approach to learning new things than most people. At least, I know my approach is different than the way people present them. The good news is that when I get something, I really get it. However, when looking at the juggernaut that is “Software-Defined X,” or even “programmability,” I know that I’m still a long, long way away from feeling like I have a handle on it.

When I wrote the previous blog post on some of the key “Open” terms were in programmability, I was overjoyed to find out that there were a few people who also had difficulty getting a grip on this too.

In other words, I’m not alone!

There is still a bewildering amount of information that I still need to learn, however, and it seems to me that if I resonated with a few people about these high-level topics, there are probably a few more who are curious about what lies beneath as well. Fortunately I work for a company (and with a lot of people) who have been willing to help me.Because he did such a fantastic job breaking the different tiers of “Open” for me, I asked Jim* to break out the napkins once more and run down some of the more esoteric programmability elements.

[* Jim is still not a real person]

At first, though, he wasn’t sure where to start. “That’s a tall order,” he said. “You’re asking me to teach you programming?”

“No, no,” I reassured him. “In fact, I don’t want you to teach me programming. There’s no way that I can simply become an expert programmer just by taking a week-long course in Python or Ruby or C or Java, etc. But that’s the part that makes me nervous.”

“Why?”

“Because I feel so hopelessly out of my league,” I said. “I understand storage, and I understand storage networks. I have the basics of Ethernet networking – about a CCNA’s worth – but I’m no CCIE. I have no idea how I’m going to suddenly learn how to be an expert programmer as well.”

“Ah, I see,” Jim said, his voice turning sympathetic. “The good news is that you don’t have to become a programmer, per se.”

“No?” I wasn’t sure if I believed him.

He shook his head. “No,” he said. “Programmability – in this case – simply refers to the ability to make a switch do something. It has to do with the way you can interact with the switch itself. “

“But I keep hearing about Java, Python, Ruby, C, etc.,” I argued. “Those sound like programming languages to me.”

He nodded, acknowledging my mild sarcasm. “Yes, they are, but it’s all about how you use them,” he countered.

I must not have looked convinced, because he took out his pen and pulled a napkin over from the dispenser. Given that we seem to have these conversations over beer, a napkin was always handy. And, since I owed him “big time” for all the help he’d given me to understand this stuff, I felt it was the least I could do to buy him as many as it took to get me to understand. How he hadn’t died from alcohol poisoning by this point I have no idea.

“Okay, let’s say you’ve got a Nexus switch,” he said.

“Oh no,” I groaned.

He stopped. “What?” he asked.

“If you’re going to start by drawing abstraction layers and whatnot, with a bunch of rectangles stacked on top of each other, I don’t think I’m going to get it,” I said.

“I mean, I know they have a purpose and are useful to a point,” I complained, “but I’ve seen so many of them back-to-back that they really have lost all meaning to me.”

“Okay,” he said, thoughtfully. “I can see that. Let’s try something radically different.”

He started drawing on the napkin.

Okay. This was different. He had my attention.

CLI/Python/NetConf

“Let’s say you have a port on a Nexus switch, and you want to do something to that port,” he explained as he drew. “It doesn’t matter what you want to do with it, so let’s keep it very, very simple. The port is controlled by the operating system, right?”

“Right,” I said. “NX-OS.”

“Correct,” he said. “Now, in this case, what we really need to do is talk to NX-OS. So how do we go about talking to NX-OS traditionally?”

“Through the command-line interface,” I suggested.

He tapped his nose to indicate that I was spot on. “Yes. The CLI,” he said as he went back to drawing.

 

“When we use the CLI to do this, we enter into the configuration part of the interface and tell it to do whatever we want. In this case, we want to activate the port.” He started writing some text off to the side.

“Now before you say anything,” he cautioned, “I know this is an extremely simple example, but the point is only to show that this is how we communicate with NX-OS for it to do something. Even simple tasks count as ‘something.’”

“Got it,” I said. I knew there was more that you had to do to an interface or the switch in order for it to do anything useful, but that wasn’t the point here. We were focusing solely on how to communicate with the switch, rather than what to communicate.

Obviously, anyone who had ever worked with a Cisco switch would know this; there is nothing new here. Even so, it was a great place to level-set, even for me.

“For some people using the CLI can be somewhat limiting, though,” he said. “For example, while the CLI provides you with direct access to the operating system, it doesn’t really allow you for even the most basic programming functions.”

“For example?” I asked. This was the kind of thing that I wanted to hear.

“Well,” he said. “Say you wanted to check for a condition first and then you want to activate or deactivate the port.”

“Okay,” I said, “But I think I’m going to need something a bit more real to work with.”

“Fair enough, here’s an example anyone can do at home,” he said, sounding just like a children’s TV show presenter.

“Let’s say that you want to check the traffic on an interface to look for CRC errors and, if there are, you want to shut down the port. This is what it might look like.”

“In this case, this is a very simple four-step process that lists the configuration for the Ethernet1/2 interface, singles out the CRC errors and shows it to us. Then we go into the interface itself and shut it down.”

“I think I see what you’re getting at,” I said. While this may be fine for checking on one or two ports, if you have to do an entire switch – which can have up to hundreds of ports, this can get pretty onerous.”

Jim nodded. “Yes, and that’s just for one switch! Imagine if you have hundreds of switches.”

I frowned, thinking that one through. “Sure, but would anyone really want to send a script out to hundreds of switches like that?”

Jim grinned broadly. “Well, that’s a completely different question. I suggest we leave that one aside for the moment.”

I nodded. That sounded like a can of worms I wasn’t ready to open just yet.

“For now, though,” Jim continued, “let’s suppose that you want to do this for a single switch that has a couple-dozen ports. This is a four-step process that requires you to type in all that stuff each time you want to do this. Sure, you can abbreviate most of these commands – which I’m going to do from now on because it’s a lot to write out – but it’s still an awful lot of typing.”

“Sure,” I said, “but not all of your ports are going to require you to type in all that information, if there are no CRC errors.”

He pointed his pen at me. “Exactly,” he said emphatically. “You only want to do this if there are CRC errors. The CLI cannot make that determination for you, you have to either do it yourself – “

“Or use something that can do it for you,” I finished for him.

“Correct,” he confirmed. “For example, there is the Python interpreter.”

“… which of course can be called remotely using a script that uses SSH to connect to the device,” he said, continuing to talk as he wrote on the napkin.

“I had heard that Python was pretty popular now,” I said. “I confess, I tried to learn it a long time ago but realized my future wasn’t in programming.” Little did I know.

“Python itself is pretty easy to learn as well,” Jim continued, “plus it has some advantages over other scripting languages such as Perl or TCL in that it’s easy to read, it’s object-oriented, and it’s very, very clean. Not only that, but there is an enormous community that help support Python as well. There are oodles of tutorials out there for everyone from the absolute beginner to the most experienced programmer.”

He took out another napkin and started writing down some addresses for me to look at on my own:

https://www.coursera.org/course/interactivepython —> (9 week course)
http://www.learnpython.org/ —> no download needed, start coding in python on the website
http://docs.python.org/2/tutorial/ —> Official Python tutorial (really good source of python documentation)
http://www.trypython.org/ —> python interpreter online

“What’s the big deal?” I asked, genuinely confused. “So I can write a script that connects to the switch and runs the CLI. So what?”

He shook his head. “You can do that, sure,” he said, “but any Python script can be run on the box itself.”

This was news to me. “Huh?” I asked. “You can run Python on the switch itself?”

He grinned. “Yup. I can’t believe you didn’t know that.”

Neither could I. “What kind of commands can you run?”

“All of them.”

I cocked my head. “Say again?”

“All of them,” he repeated. “Well, pretty much all of them. I can only think of one command off the top of my head, and perhaps there are a few others, but generally speaking yes, you have the full breadth of NX-OS commands at your disposal. Any CLI command can be executed from the Python Interpreter mode. Not only that, but you can parse the outputs and perform conditional actions. You can call a different python script from within a script, too. When you do this the script is stored on bootflash on the switch. There is a pretty good webpage about the Python API on the N7k, as well as for the 5k, for example.”

“If you take this example,” he said, tapping the napkin with the CRC CLI commands, and you wanted to run the Python code on the Nexus 7000, for instance, this is what you would get.”

“Here, though, the script runs through all of the interfaces on the switch,” he explained, “not just the Ethernet1/2 interface.”

“Nice. What else can you do?” I asked.

“The on-box Python can be used to do things like Power-On Auto Provisioning, or POAP,” he said. “It can also be used to tie into EEM.”

“What’s EEM?” I asked.

“Sorry,” he apologized. “There are a lot of acronyms here to play with. EEM stands for Embedded Event Manager, which is an internal scripting capability in NX-OS. It can do things like monitor events and then take action, such as when a module changes status, or the temperature of a switch reaches a certain threshold. Stuff like that.

“Ultimately, there is a lot you can do with Python, both on- and off-box. If you take a look around the web, you’ll find some Cisco- and community-contributed scripts at places like GitHub,” he said.

NetConf

“But that’s not the only way to communicate with the CLI,” he continued. “You can, of course, connect to the switch using a script, or even use something like NetConf, which can call the CLI directly but does not reside on the switch itself.”

 

“Go on,” I prompted. He knew what I was going to ask anyway.

“NetConf,” he said, smiling, “is another way of managing a device. It’s remote management, which gives some pretty nice advantages over more traditional ways, such as the CLI and SNMP.”

“How so?”

“Well, SNMP – comparatively speaking – is a bit limited and more complicated when compared to newer methods, and not quite as powerful either,” he replied.

“NetConf, on the other hand,” he continued, “is a way that we can use virtually any of the CLI outputs as well as filter them. Additionally, sometimes – rare as it may be – the CLI commands can actually change between OS upgrades, and making sure that your scripts will work if they only replicate the CLI can be a pain. NetConf helps address the ever-changing structure and syntax of commands.

“As far as SNMP is concerned, NetConf has a big advantage, because not only is it agentless, but it eliminates the need for screen scraping using complex scripts just because SNMP doesn’t define all the possible output fields.”

“So, from the switch’s perspective,” I concluded, “this minimizes the load on CPU and memory because we’re connecting to the switch via SSH sessions.

“Exactly,” he agreed. “In addition, SNMP was designed for performance and monitoring applications, not configuration, and generally speaking there is a lack of useful standard security mechanisms, though version 3 has improved upon this quite a bit.

“For our conversation here, though,” he said, “SNMP has the key drawback that there is a lack of a defined discovery process that makes it hard to find the right modules to hook into. With NetConf, you have the ability to display the CLI output in NetConf/XML format, which makes parsing by script much easier.”

“You can do that?” I asked.

Jim pulled out his laptop. “Sure. Let me show you.”

He called up a terminal window and typed in some familiar commands. “Let’s just take a look at the Ethernet interface,” he said.

“And now we can run the same command, but have the output give us XML,” he said, adding in a quick few characters to the command.

“Ah, I see,” I said. It was easy to see how that format would be much easier for a script to parse into something usable.

“It’s important to remember,” he said, “that NetConf was designed from the ground up to interface with the network device manager. It has the ability to make a distinction between multiple configuration data sets, such as the running configuration, startup configuration, and a potential candidate configuration, and it has a more robust commit mechanism that allows you to check to make sure that dependencies are satisfied before committing a change.”

“Let me see if I understand this,” I said. “I can check to see if there are going to be any unintended consequences before blindly submitting the command?”

“Precisely, although,” he said, smiling. “it’s also important to remember that it’s garbage-in, garbage-out. If you write stupid code, you’re going to get stupid behavior. Later on, though, we’ll talk about how we can get even more streamlined output from JSON.”

I grinned, but inside I realized that I was very good at doing stupid things. Better leave that to the professionals. Or something.

Taking a Break

At this point we both needed a bit of a breather, but I knew we had just gotten started. When we came back to continue our conversation, we spent more time talking about Puppet, Chef, and what in the world this “onePK” thing is all about. After that, we started talking more about XML, JSON, NXAPI and a few other things to help paint a much broader picture.