Ever since I entered this field, I’ve been interested in this concept of “network programmability”. Forgetting for a second what we’ve been talking about in the past few years since the advent of the “SDN tsunami”, even the ability to automate simple infrastructure tasks at a small scale has grabbed my attention.
It’s important to note something here; the CLI is a wonderful tool. So many vendors take the wrong approach and say the CLI is going away in lieu of pretty GUIs and APIs, as if someone can’t write a really good CLI to consume a really good API.
The networking industry has long speculated that coding skillsets are something that will likely become key in the future. I’m sure this will vary from job to job, but I can tell you that - at least for me - it’s already happened.
I’m not even just talking about knowing syntax like Python, Java, Ruby, etc. I’ve maintained these skillsets sufficiently throughout my network-specific studies that recalling these skills isn’t that hard (admittedly I’m a youngin so it hasn’t been that long).
When using overlays, its important to remember (in most cases) that an entire Ethernet frame is being encapsulated in something else (usually Ethernet + IP + UDP + Overlay Header). This means that the Maximum Transmission Unit for the underlay must be adjusted.
There are a number of posts out there about correct MTU settings for VXLAN. Unfortunately, many of them are either wrong, or unclear as to the math behind these calculations.
I’ve had network configuration tools and protocols on my mind for the last few weeks. Everyone’s got some hot new API or configuration protocol - and on the outside looking in, it’s easy to assume that they’re all just different flavors of the same general concept - network configuration. So are they basically competing standards (VHS vs Betamax, anyone?)? Or is there a method to this madness?
Just to name a few, OVSDB and Netconf are actually established JSON-RPC and XML-RPC (respectively) based standardized formats for accomplishing network configuration on the wire, rather than chase down each vendor’s individual XML/JSON API.
A robust built-in API is not something you traditionally see in a Cisco router or switch. My first experience with anything like this on Cisco was with Unified Computing System. Though it’s a high-level API that interacts only with the UCSM application managing the entire stack, it’s still a robust way to configure policy and resources within UCS.
ACI is recieving the same treatment, and though it’s true that there will be a slew of programmability options built into the APIC controller that is the cornerstone of the ACI fabric that we’ll be hopefully seeing later this year, there are also some very cool options on each individual switch in NXOS or Standalone mode as well.
I was fortunate enough to be given access to a pair of Nexus 9Ks in our lab, and I want to give a brief overview of the initial configuration process, and a brief introduction to some of the features initially presented to us on the switch platform.
Here are a few summarized thoughts:
Calling it a switch is actually kind of funny to me. All ports are routed and shutdown by default, and though you can obviously “no shut” them, and you can convert to a switchport, the switch is clearly built for all-L3 operations.
I was inspired by many little things over the past few days to begin writing a post about this whole “writing code” thing that network engineers the world over have been asking about.
I’ve said before I know that most network engineers already write some kind of code - even if it’s as simple as a snippet of VBA in an Excel spreadsheet to automatically convert a spreadsheet of configuration options into an actual running configuration.
I was fortunate enough to spend this morning (and will be here for quite a while) in Silicon Valley at the first ever OpenDaylight Summit. The initial keynotes were good, but for me the event started last night when I had the opportunity to sit with some of my own industry role models and just talk nerdy, nerdy networking.
Considering how very young this project is (10 months), there are a surprisingly large number of people here - over 550 attendees.
It’s been really interesting to see the industry in an all-out zerg rush to adopt Python as a skill-set. What is it about this seemingly arbitrary selection in the vast array of programming languages available out there? What is so special about Python that it comes up in nearly every conversation about SDN?
This post has been in drafts for some time, and I was motivated to finish it up by this Packet Pushers episode, where Jeremy Schulman and others discuss Python and its impact to networking.
I’m pleased to be invited back for the 7th installment of Networking Field Day in San Jose, CA from February 19th - 21st. This event is part of a series of independent IT community-powered events that give the vendors an opportunity to talk about the products and ideas they’ve been working on, and receive honest and direct feedback from the delegates.
The results of this dynamic vary quite greatly - sometimes a vendor doesn’t quite bring their A-game and we let them know.
I will be at the OpenDaylight Summit in Santa Clara on February 4th and 5th.
To me, OpenDaylight represents a platform on which we can test SDN ideas today, right here, and right now. In my day job I may never be called upon to help deploy OpenDaylight (here’s hoping!) but nonetheless, it’s projects like this where the best and the brightest come together to share ideas and help to form the technology that the industry will be using for the next few decades.
This will be a short follow-up to my last post about the idea of Flow Control in storage protocols. As a review, the three main options in common use today are:
IP Storage - uses TCP windowing to provide feedback to client on how much data to send
Native Fibre Channel - uses buffer credits (typically on a hop-by-hop basis when using N_port to F_port) FCoE - uses Priority Flow Control to define a class of service on which to send Ethernet PAUSE frames to manage congestion The last item is really the only one that warrants any kind of configuration, as the first two are more or less baked into the protocol stacks.
Sadly, this will be another post regarding issues I’ve had with UCSM firmware release 2.2(1b). During the upgrade process, I experienced a lot of issues with data plane connectivity - after I activated (and subsequently rebooted) a Fabric Interconnect, and it came up with the new NXOS version, a slew of blades would have persistent errors regarding virtual interfaces (VIFs) that wouldn’t come back online.
Here is the error report for a single blade where I was seeing these errors:
When upgrading UCS firmware, it’s important to periodically check the state of the HA clustering service running between the two Fabric Interconnects. The infrastructure portions of UCS are generally redundant due to these two FIs but only if the clustering service has converged - so it’s important to use the “show cluster state” command to verify this is the case. During a firmware upgrade to 2.2(1b), I checked this:
6296FAB-A# connect local-mgmt 6296FAB-A(local-mgmt)# show cluster state Cluster Id: 8048cd6e-5d54-11e3-b36c-002a6a499d04 Unable to communicate with UCSM controller The error message - “unable to communicate with UCSM controller” worried me, and it was given when I ran the “show cluster state” command as well as the “cluster lead” command - the latter of which is necessary to switch an FI’s role in the cluster from subordinate to primary.
One of the (sadly numerous) issues I’ve run into while upgrading to Cisco UCSM version 2.2(1b) is this little error message indicating that a service failed to start:
This gives us an error code of F0867 and it’s letting us know that the UCSM process httpd_cimc.sh failed on one of our Fabric Interconnects.
For those that don’t know, you can get a list of processes within UCSM by connecting to local management and running “show pmon state”.
When making the leap to adopting FCoE as a storage medium, there are a few things to consider in order to be successful. Many of these concepts are foreign to the storage administrator who has been operating a native Fibre Channel SAN for the better part of the last decade or more - this is because while Fibre Channel networks are costly, they are purpose-built. There is no concept of a loop in Fibre Channel - with Ethernet we deal with these all the time.
Over the past few months I’ve heard a lot about vendor lock-in, specifically with respect to new SDN/Network Virtualization products that have come out last year. It appears that no matter what product you look at, there’s some major factor that will cause you to be severely locked in to that vendor until the end of time. Unless, of course, you’re a proponent of that vendor, in which case, that vendor is NOT locking you in, but that other guy totally is.
I’ve been hearing a lot about libvirt, so I figured I’d check it out, and see if I could play around with it in my own home lab.
According to the wiki, libvirt is a ”collection of software that provides a convenient way to manage virtual machines and other virtualization functionality, such as storage and network interface management.” Okay that’s pretty cool - basically if I have a multi-hypervisor environment, I can build my operational policies around libvirt, so that no matter what hypervisor a workload is being instantiated on, the process is the same.
Wow - this one snuck up on me. Seriously, when I think of how 2013 went, I’m amazed at how much happened this year but also how fast it flew by.
As per the tradition I started last year, I thought it prudent to write a post summarizing how terribly I was able to forecast 2013 in terms of personal goals, and make another feeble attempt at planning out 2014.
Matt Oswalt