VMware’s Network Virtualization Platform, NSX, is an immensely powerful technology that can transform a datacenter’s infrastructure and streamline network service delivery across the enterprise. NSX’s scope, scale, and capability will easily impress techies, CCIE’s, and IT stakeholders alike. NSX changes the topology of a traditional hardware-bound network by eliminating the dependency on all that “intelligence” baked into proprietary hardware. Instead, the logic and associated services are delivered through a software control plane. Separating the control and data planes effectively reduces the physical network to a glorified IP packet forwarder.
With that said, it is also important to understand that NSX is not a re-write of your network and the fundamental concepts it is built upon. The abstraction of the logic from the physical underpinnings is a modern approach to designing, building, and servicing network architectures, but the fundamentals — the protocols, tools, concepts, etc. — are still at play. And for that reason, i’m often baffled when I enter into a debate with a “traditional” network engineer about the ins-and-outs of physical vs. virtual networking technologies like NSX. What I quickly realize is they are not defending the concepts or technology, they are defending their skill set. It’s a fear or reluctance of straying from what they know best. Does this sound familiar? Remember the all-out fights that had to occur before server virtualization became mainstream? Back then there were always a few individuals pushing to try something new. It was these sys admins that knew there was a better way to provision and manage servers — whether one at a time or at massive scale. It was about learning knew technologies, expanding their skill set and scope, but still applying all the fundamentals. It was a new way of doing things — and everyone on that bandwagon excelled and continues to do so. There were those who waited for the top-down mandate and had to play catch-up, and the others who took the bull by the horns and became the go-to talent. It’s no surprise that server virtualization became the de-facto for x86 compute…nor should it be a surprise when network virtualization follows suite.
This is history repeating itself.
I was a network engineer in my previous life and helped design, implement and support several incredibly complex networks across the enterprise and our DoD customer (never a dull moment there!). As you’d expect, Cisco was a prominent vendor and so I worked towards achieving CCNA and then CCNP certifications (among other certs, but fell short of a CCIE) to fine-tune my skills. I have to admit I once had a death grip on Cisco because I felt I knew them best. To this day, those certifications stand out as some of the best IT training I have ever received. They helped with the fundamentals, advanced concepts, and of course the Cisco proprietary tech. But ultimately I was able to take that skill set and apply it to many other vendor’s technologies, topologies, and concepts, even in environments where Cisco owned a minimal footprint. The foundation was critical, the rest is what you make of it. I know the difference between an industry standard and a proprietary technology. Each vendor will provide the fundamentals and layer their own magic sauce on top of it, but at the end of the day it’s all networking. My point is CCIE’s are not bound to Cisco. In fact, they have an incredible opportunity to quickly embrace new technologies and lead the next-generation of network transformation much like server virtualization did for compute. And they also don’t have to abandon all that Cisco gear at their fingertips.
|VMware’s Network Virtualization Platform
I’ve been dipping my feet more and more into NSX as of late and recently completed an internal “NSX Ninjas” bootcamp to hone in my skills. It was no surprise that anyone with a networking background in this class was able to hit the ground running. I was able to pick up where I left off many years ago. Physical network architectures are now logical — defined by software and delivered through a set of modern UI’s independent of the underlying hardware. Logical switching, routing, isolation zones? No problem. IP, OSPF, BGP, IPSEC, VXLAN…all well-known protocols with the same expected results whether in hardware or defined by software. L2, L3, L4-L7, 2-tier, 3-tier, whatever. Deploy a distributed firewall strategy or instantly expand a network or service to the rest of the datacenter…done in just a few clicks. You can stick to the basics or explore the bleeding edge in a single UI. Bottom line is understanding the fundamentals gave me a significant head start and so I was able to quickly focus on NSX’s unique concepts and capabilities that make it a leading networking technology. And one more thing — NSX will deliver all this independently of underlying hardware, as you’d expect a software-defined solution to do. Repeat after me: an app-centric, software-defined network shall not have a hardware dependency! True software-defined networks are managed by and dependent on software only. Everything else is a marketing ploy. But I digress…
In this series I will dive into the ins and outs of NSX in the form of Facts and FAQ’s. I will cover each major component and sub-component, adopted standard, deployment methodology, and implementation strategy. I will provide answers for the most common questions and concerns using my own experiences as well as all the tools and resources available to me. I will also use the series of posts to aggregate available information, set expectations, and ultimately fine-tune my own skill set.
NSX is the future of networking and I want to be ALL OVER IT. This is my start.
Next Up: NSX Uncovered – Part 2, Overview (coming very soon!)