Things I Learned About Nexus Power-On Auto Provisioning (POAP)

I’ve spent the last few days working with Cisco Nexus switches and trying to get them to auto-provision using DHCP and I wanted to document some of the things I learned in the process.

POAP uses DHCP and delivers an IP address along with the name of a tftp server and a filepath to an install-script file the switch. If the switch is in a sufficiently unconfigured state, it will automatically being the POAP process when it boots up. I say sufficiently unconfigured because it is possible to be overconfigured and underconfigured. You’re overconfigured if there is a startup-config. You’re underconfigured if your box boots to the Loader> prompt as the first box I touched did. (You can fix this by booting up and running “install all” for any image)

The POAP install-script can be downloaded in the same area of the Cisco.com site where you download the kickstart image. This is counter-intuitive placement on Cisco’s part but Arista is also guilty of placing things like config guides in their code download area. It’s not a bad way to go but I would prefer that they indicate it more clearly.

You will have to tailor the POAP script to suit your environment.

I had to update it to reflect the code images I wanted to use and I also added an entropy value to the destination filenames for the kickstart and system images because the script doesn’t copy the files if they already exist. And the sample POAP install-scripts seem to all be hard-configured to save the files as n3k.k and n3k.s. The result for me was that I ended up with a version of code other than what I wanted on my switches.

The sample POAP scripts also don’t seem to include downloading image files from a remote server so that is something you will have to adjust as well. I’m still learning about what kind of documentation is available for the python API so I can’t make strong recommendations about how to fix that just yet.

More later.

Shared Thoughts on the Path to Network Programmability

I wanted to share a really well written blog post that is based on a presentation about the evolution of Network Programmability. One of the things I tend to like about a strong presentation is that it covers enough history and current context to make the content relevant to its audience. The writer of this article does that amazingly well. I’m glad to share it since I agree with much of what he said and it dovetails with my thinking on the subject.

Here are some of the points summarized: - We need a new model. We need to put into place a methodology that allows us to interact with the network in the same way that we design it. - Purchasing products or building solutions that do the [high level abstractions], without a mastery of [fundamental technologies],.. will inevitably result in failure. - At scale, repetitive tasks are the not-so-silent killer…. These repetitive tasks tend to occupy a lot of time, mostly for those whose time is really valuable… These tasks are prime candidates for automation. - Some kind of centralization will win out. - No, you do NOT need to become a programmer, but you can if you truly want to. - “The truth is that we don’t need all network engineers to learn code. We need network engineers to solve networking problems. We also need a smaller subset of these folks to tackle the problems in existing tool sets and getting the networking discipline to understand how to improve processes for the better.”