As we’ve discussed SDN over the years at Packet Pushers, a recurring theme is data center network virtualization. One of the most popular options here is VMware NSX.
If you’re considering data center network virtualization, should you be looking into NSX? What is NSX good for? If you do choose to install NSX, what should you be thinking about?
On this edition of the Packet Pushers’ “Design & Build” series, we consider just that. This is not a sponsored show, but rather just a gathering of folks with some NSX background who have joined us from around the world to share their knowledge.
Our focus today is to consider when designing an NSX implementation, and then what changes for you once NSX is built and in production.
Joining the conversation are Anthony Burke (@pandom_), Senior Systems Engineer, Network and Security Business Unit, VMware; Stephen Skinner, Technical Consultant at Dimension Data; and Chris Wahl (@ChrisWahl), Technical Evangelist at Rubrik and co-host of the Datanauts podcast.
Talari creates a THINKING SD-WAN that makes the network smart and responsive, adapting in real time to changing conditions. Talari puts intelligence in every packet and at every endpoint, performing one-way measurement to identify packet loss, jitter, and the failure of any one network path—then rerouting packets to keep your data flowing. Mission-critical apps like VoIP and VDI take priority and always deliver. Visit talari.com for more details, and listen to the Packet Pushers’ conversation with John Dickey, Talari’s co-founder and CTO.
ThousandEyes gives you visibility into every network your company relies on – your corporate network, the Internet, cloud service provider network – all from one place. ThousandEyes agents are deployed across the globe and within your own network. Together, these vantage points provide the most complete understanding of network topology, dependencies and behavior. Sign up for a free account at
www.thousandeyes.com/packetpushers and choose a free ThousandEyes t-shirt.
Part 1: Deploying NSX
-NSX is cool, but WHY do you want to deploy, what is your REAL business case and do you really understand it?
-Why the first thing you should do when deploying NSX is not Deploy NSX. The first step is Planning, Planning, Planning, and much more Planning.
-Using vCenter/ESXi and being a vCenter admin are two very different things. You need to be a vCenter admin before you start with NSX.
-Conceptual, logical, and physical designs:
- Conceptual – How do the various pieces and parts intersect with one another, and how are your users going to take advantage of the stack
- Logical – Network and virtualization designs, with a focus on the various VLANs and subnets that will be consumed by the data center(s)
- Physical – Ensuring that MTU sizes are appropriate for an encapsulated packet flow, avoiding caveats around routing protocols, such as routing adjacency across a vPC link
- Security Architecture – Application topologies, flows, relationships, then using non-5tuple rules
Part 2: Security Policy Shift
-“…but if every VM now has a distributed firewall, I have 3,000 firewalls, how does it work outside of PowerPoint?”
-Service based, application-centric, security architecture that ensures how things talk to what.
-Coupling provisioning and ultimately lifecycle management with security policy in an abstracted manner.
-Using logical identifiers to determine security – such as who is logged into the VM – rather than the typical 5tuple rules.
Part 3: Big Ideas
-Silo Busting: How are customers using VMware NSX able to work successfully across their functional teams (network, security, virtualization)?
-Where do the control boundaries exist for these various silos? Who puts in changes, who approves those changes, and what does each functional group see and manipulate as part of their workflow?
-Do network engineers need to become security and/or virtualization engineers? Same goes for the other disciplines.
-Because all of the pieces and parts provided by NSX are extensible, how can we best leverage the stack to provide turnkey provisioning to the consumers of the services? Do these features go up the stack to the CMP (cloud management portal), such as OpenStack and vRealize Automation, or more granular control with vRealize Orchestrator/PowerShell (see PowerNSX)/Ruby/scripts?