I published a blog post describing how complex the underlay supporting VMware NSX still has to be (because someone keeps pretending a network is just a thick yellow cable), and the tweet announcing it admittedly looked like a clickbait.
[Blog] Do We Need Complex Data Center Switches for VMware NSX Underlay
Martin Casado quickly replied NO (probably before reading the whole article), starting a whole barrage of overlay-focused neteng-versus-devs fun.
I’m running two workshops in Zurich in the next 10 days:
- Comparing VMware NSX and Cisco ACI (and how EVPN and VXLAN fit into the big picture) on Thursday, November 28th;
- Explaining how you could use VXLAN with EVPN to build infrastructure for active-active data centers on Tuesday, December 3rd.
I published the slide deck for the NSX versus ACI workshop a few days ago (and you can already download it if you have a paid ipSpace.net subscription) and it’s full of new goodness like ACI vPod, multi-pod ACI, multi-site ACI, ACI-on-AWS, and multi-site NSX-V and NSX-T.
A Network Artist left a lengthy comment on my Brief History of VMware NSX blog post. He raised a number of interesting topics, so I decided to write my replies as a separate blog post.
Using Geneve is an interesting choice to be made and while the approach has it’s own Pros and Cons, I would like to stick to VXLAN if I were to recommend to someone for few good reasons.
The main reason I see for NSX-T using Geneve instead of VXLAN is the need for additional header fields to carry metadata around, and to implement Network Services Header (NSH) for east-west service insertion.
A while ago I had an interesting discussion with someone running VMware NSX on top of VXLAN+EVPN fabric - a pretty common scenario considering:
- NSX’s insistence on having all VXLAN uplink from the same server in the same subnet;
- Data center switching vendors being on a lemming-like run praising EVPN+VXLAN;
- Non-FANG environments being somewhat reluctant to connect a server to a single switch.
His fabric was running well… apart from the weird times when someone started tons of new VMs.
Last year when I was creating the first version of VMware NSX Deep Dive content, NSX-V was mainstream and NSX-T was the new kid on the block. A year later NSX-V is mostly sidelined, and all the development efforts are going into NSX-T. Time to adapt the webinar to new reality… taking the usual staged approach:
- The new slide deck covering NSX-V and NSX-T is ready. It includes early information about NSX-T release 2.5; I’ll fill in the details once the documentation becomes public.
- I’ll use the slide deck in day-long workshop in Zurich on September 10th.
- The live webinar sessions (including updated NSX-T 2.5 content) will start on November 14th.
I spent a lot of time during this summer figuring out the details of NSX-T, resulting in significantly updated and expanded VMware NSX Technical Deep Dive material… but before going into those details let’s do a brief walk down the memory lane ;)
You might remember a startup called Nicira that was acquired by VMware in mid-2012… supposedly resulting in the ever-continuing spat between Cisco and VMware (and maybe even triggering the creation of Cisco ACI).
An attendee of our Building Network Automation Solutions online course decided to automate his NSX-T environment and sent me this question:
I will be working on NSX-T quite a lot these days and I was wondering how could I automate my workflow (lab + production) to produce a certain consistency in my work.
I’ve seen that VMware relies a lot on PowerShell and I’ve haven’t invested a lot in that yet … and I would like to get more skills and become more proficient using Python right now.
Always select the most convenient tool for the job, and regardless of personal preferences PowerShell seems to be the one to use in this case.
A friend of mine told me about a “VXLAN is insecure, the sky is falling” presentation from RIPE-77 which claims that you can (under certain circumstances) inject packets into VXLAN virtual networks from the Internet.
Welcome back, Captain Obvious. Anyone looking at the VXLAN packet could immediately figure out that there’s no security in VXLAN. I pointed that out several times in my blog posts and presentations, including Cloud Computing Networking (EuroNOG, September 2011) and NSX Architecture webinar (August 2013).
After four live sessions we finished the VMware NSX Technical Deep Dive webinar yesterday. Still have to edit the materials, but right now the whole thing is already over 6 hours long, and there are two more guest speaker sessions to come.
Anyways, in the previous sessions we covered all the good parts of NSX and a few of the bad ones. Everything that was left for yesterday were the ugly parts.
Here's a trick question: how often do your Visio diagrams match what's really implemented in your network?
Wouldn't it be great to be able to create or modify them on-the-fly based on what's really configured in the network? That's exactly what Anthony Burke demonstrated in the PowerNSX part of PowerShell for Networking Engineers webinar (source code).
You’ll need at least free ipSpace.net subscription to watch the video.
When VMware launched the first version of NSX for vSphere more than four years ago, the NSBU team reached out to me and asked me to create a sponsored webinar describing NSX fundamentals, its architecture, and high-level deployment guidelines.
In the meantime we discussed updating the materials, but nothing ever happened. Time to fix that, this time from a vendor-neutral perspective. We’ll start with a day-long event on April 19th 2018 in Zurich, Switzerland.
You’ll need at least free ipSpace.net subscription to watch the video.
Want to know more about VMware NSX? We’ll run an NSX-focused event and a NSX Deep Dive workshop in Zurich on April 19th 2018, an overview webinar comparing NSX, ACI and EVPN on March 1st, and a deep dive in VMware NSX architecture later in 2018.
One of the beauties of VMware NSX is that it’s fully API-based – you can automate any aspect of it by writing a script (or using any of the network automation tools) that executes a series of well-defined (and well-documented) API calls.
To make that task even easier, VMware released PowerNSX, an open-source library of PowerShell commandlets that abstract the internal details of NSX API and give you an easy-to-use interface (assuming you use PowerShell as your automation tool).
One of my readers sent me a lengthy email describing his NSX-versus-ACI views. He started with [slightly reworded]:
What I want to do is to create customer templates to speed up deployment of application environments, as it takes too long at the moment to set up a new application environment.
That’s what we all want. How you get there is the interesting part.
I keep getting questions along the lines of “should I go with VMware NSX or should I deploy Cisco ACI” every single week, and as you know it’s hard to answer anything but it depends without spending hours on the topic.