Category: Virtualization

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.

One of my readers sent me a series of questions regarding a new cloud deployment where the cloud implementers want to run VXLAN and EVPN on the hypervisor hosts:

I am currently working on a leaf-and-spine VXLAN+ EVPN PoC. At the same time, the systems team in my company is working on building a Cloudstack platform and are insisting on using VXLAN on the compute node even to the point of using BGP for inter-VXLAN traffic on the nodes.

Using VXLAN (or GRE) encap/decap on the hypervisor hosts is nothing new. That’s how NSX and many OpenStack implementations work.

In 2014, we did a series of podcasts on Snabb Switch (Snabb Switch and OpenStack, Deep Dive), a software-only switch delivering 10-20 Gbps of forwarded bandwidth per x86 core. In the meantime, Snabb community slowly expanded, optimized the switching code, built a number of solutions on top of the packet forwarding core, and even forked a just-in-time Lua compiler to get better performance.

To find out the details, listen to Episode 91 of Software Gone Wild in which Luke Gorrie explained how far the Snabb project has progressed in the last four years.

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 19^th 2018 in Zurich, Switzerland.

After introducing PowerNSX Anthony Burke illustrated how easy it is to use with a Hello, World equivalent: creating a logical switch (VXLAN segment).

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 wanted to know more about containers and wondered how ipSpace.net materials could help him. Here’s a short step-by-step guide:

I published this blog post to help ipSpace.net subscribers navigate through Docker- and containers-related material. You might want to skip it if you’re not one of them.

In every SDDC workshop I tried to persuade the audience that the virtual appliances (particularly per-application instances of virtual appliances) are the way to go. I usually got the questions along the lines of “who will manage and audit all these instances?” but once someone asked “and how will we upgrade them?”

Short answer: you won’t.

VMware started talking about VMware Cloud on AWS a while ago, and my first response was “yeah, it’s just vCloud Air but they wanted to get rid of CapEx, so it’s running on someone else’s servers”

Last week Frank Denneman published a technical overview of the solution and I was mostly correct.