One of the things that struck me at this year’s Future:NET was when our emcee for the day, VMware’s own Tom Gillis, mentioned that what we (network folks) care about is policy and availability. That may sound simple and even obvious, but I find it to be a powerful description of what makes a network a network.
Availability AND Policy
Availability is probably a no-brainer here. The purpose of a network is to facilitate communication through connectivity. If the network is not available (able to be used or obtained; at someone’s disposal) then by definition you can’t use it to connect to anything, which means you can’t communicate over it. Not very useful, in other words.
Availability is also, maybe because it’s so obvious, where most of us networking professionals tend to spend most of our time. We talk about resiliency, reliability, and redundancy all the time. We know that the network is the most foundational layer of technology infrastructure. We know that it must be available all the time – or else nothing else works. So we think about availability a lot.
What we may not think about nearly enough, is policy. In fact, we talk about policy so seldom that it’s probably worth examining just what is meant by this word; policy.
According to Oxford, “policy” is: “A course or principle of action adopted or proposed by an organization or individual.”
A course or principle of action, hmm. I think that means it’s how we operate. Michael Porter described “policy” as the means by which we achieve our goals (the ends). Of course, he was talking about business strategy, but I think the explanation holds up for networking as well. Converting that to modern networking lingo, “policy” is simply how we enact and enforce our intent (an outcome or business objective) in the network.
When you think about policy this way, almost all network and security configuration is an expression of policy. Whether we call it an ACL, a route, a rule, a filter, or a group; it’s simply how we want the network to behave. Which packets or frames should be forwarded where, at what throughput, etc.
In legacy networks, we configured these policies manually, box by box, on the CLI. While that may be considered easy by some highly experienced networking experts, it is certainly not simple. And worse, the inherent complexity in this approach makes it error-prone and hard to scale. Lucky for all of us, the networking industry has been undergoing rapid and major changes over the past few years.
The advent of software-defined networking (SDN) and virtualization have changed what is possible. And VMware’s NSX is at the forefront of these changes.
Network Management
Another of my favorite quotes from FutureNET:2019 was when Ken Duda stated that “network management has always been a backwater” and pointed out that networks are harder to operate than to build. This comment drew lots of vigorous head nodding from the crowd of seasoned network professionals. And we all know why they’re hard to operate. In fact, we were just talking about it, above. That’s right, those manual, box-by-box configurations!
In legacy networks, network management is indeed a backwater, as Ken said. They typically use some kind of SNMP polling to add a bit of visibility into basic network device statistics like interface up/down, CPU usage, temperature alarms, and similar. Maybe they add some pretty (or not so pretty) bandwidth graph showing your interface utilization. All of this is polled at 5-minute intervals (or less) of course, and so any alerts are purely reactive. Oh, and don’t forget to watch your syslog go scrolling by – that way you might catch something a little sooner.
Even those rudimentary tools only cover half of network management. True management is about visibility AND control. How do you configure your devices? If it’s one at a time on the CLI (or even in scripted batches), then you are the network management tool! We can do better. In fact, many folks already do – maybe even you.
Software-Defined Networking
Most definitions of SDN center around the idea of control plane and data plane separation. I won’t dispute this. Mostly because it came directly out of the Clean Slate Program at Stanford (headed by Nick McKeown (@nickmckeown1), another speaker at Future:NET 2019), which of course produced OpenFlow – still the standard bearing SDN protocol, even if not very widely deployed for reasons we don’t have the time to go into now.
That definition, however, feels a bit lacking to me. At least if you are looking at SDN pragmatically, as an operator. To me, when we talk about SDN, the reason it’s neat to separate the control plane from the data plane is all about network programmability. The goal we are seeking is the ability to abstract the underlying infrastructure from users and applications so that they can implement consistent policy across the network as simply as possible. I actually pointed this out in my first post on SDN back in 2012: “Software Defined Networking (SDN) is the current name for a continuing trend towards greater network virtualization through software abstraction.”
Hopefully now the dots are starting to connect for you. Policy is how we enact and enforce our intent on the network. Network management is how we configure policy into the network. So, the missing piece in the common definition of SDN is the management plane.
NSX Manager
Lucky for us, VMware (or really, Nicira) didn’t fall into this trap. NSX is built on an architecture that recognizes all three required planes: Data/Forwarding, Control, and Management.
In case you were wondering, yes, this is true for both NSX-v and NSX-T.
But let’s not get too far ahead of ourselves just yet. What exactly is NSX Manager? And what does it have to do with simplicity and policy?
As you can see in the diagrams above, NSX Manager sits in the management plane of every NSX deployment. That is true for NSX Data Center, NSX Cloud, and NSX for Horizon too. In fact, NSX Manager doesn’t just live in the management plane, it is the management plane for the whole NSX ecosystem. It provides a single entry point into the whole system. In other words, if you’ve ever used NSX, you’ve done it through NSX Manager.
NSX Manager is a virtual machine (the recommendation is actually a cluster of three VMs for redundancy / high availability) and it provides both the graphical user interface (GUI) and the RESTful APIs that allow configuration and orchestration of all logical networking components, network services, edge services, security services, and the distributed firewall. In fact, let me just quote the NSX-T installation guide:
“NSX Manager provides a method for monitoring and troubleshooting workloads attached to virtual networks created by NSX-T Data Center. It allows seamless orchestration of both built-in and external services. All security services, whether built-in or 3rd party, are deployed and configured by the NSX-T Data Center management plane. The management plane provides a single window for viewing services availability. It also facilitates policy-based service chaining, context sharing, and inter-service events handling. This simplifies the auditing of the security posture, streamlining application of identity based controls (for example, AD and mobility profiles). NSX Manager also provides REST API entry-points to automate consumption. This flexible architecture allows for automation of all configuration and monitoring aspects via any cloud management platform, security vendor platform, or automation framework.”
Powerful Simplicity
Having a single management interface to all devices and services in your network makes administration powerfully simple. And since all the features and functions of NSX are at your fingertips in NSX Manager, I’d also call that powerful simplicity.
To see NSX Manager in action, check out this demo by Dimitri Desmidt from Network Field Day 20:
Powerful, simple, policy. I think you get it.
But wait, there’s more!
Future:NET 2019 didn’t happen all on its own. It happens to coincide with VMworld, and this year’s VMworld brought us lots of new NSX-T features with the version 2.5 release. I’d like to quickly run through a few of the updates most relevant to policy and simplicity.
One of the biggest improvements to the power of native security policy in NSX-T was the addition of L7 App-ID support on gateway firewalls:
There were also FQDN filtering (policy) enhancements:
And finally, on the operational simplicity side of the coin, they added auto/manual drafts and rollbacks! Stay tuned for a future post digging agent-less micro-segmentation using cloud-native security controls!
