SDDC.Lab v3
Last week we released version 3 of the SDDC.Lab project. For those of you who aren’t familiar with the project, it’s a set of Ansible scripts (Playbooks) that perform automated deployments of nested VMware SDDCs. An hour after you issue the deploy command, a fully-fledged vSphere-NSX-T environment is at your disposal. Pretty cool. The diagram
Quick Tip – Ansible Module “nsxt_rest”
There are Ansible modules for configuring most of the NSX-T platform components, but for certain configuration tasks it might be quicker (or even necessary) to GET/POST/PUT/PATCH/DELETE to the NSX-T REST API directly. Now, in those situations you could use curl or Postman or any of the other REST API clients out there, but if you
Log Insight – Integration With Jenkins
During some research I did for a customer on how to trigger an action based on an error event in the SDDC, I built myself a lab and ended up with a concept that seems interesting enough to write some lines about on the blog. High-Level The diagram below illustrates the “solution” at a high-level:
Around the NSX-T Table(s)
The NSX-T Central Control Plane (CCP) is building and maintaining a central repository for some tables that make NSX-T the unique network virtualization solution it is. More specifically I’m talking about: The Global MAC address table The Global ARP table In today’s article I’ll have a closer look at these two tables. MAC Address Table
HCX Your Way To NSX-T Overlay
Happy New Year! 🙂 In the last two posts we had a look at two different methods for extending VLANs to NSX-T overlay. In the first post we configured a bridge which works well in scenarios where we the source VLAN and destination NSX-T Edge can achieve layer 2 adjacency. In the second post we
VPN Your Way To NSX-T Overlay
In the previous article we had a look at how VLAN-connected workloads were migrated to NSX-T overlay by setting up a bridge between VLANs and NSX-T overlay segments. This works well in scenarios where layer 2 adjacency between source and destination environment can be achieved. In other words, we can stretch the source VLAN(s) to
Bridge Your Way To NSX-T Overlay
Organizations implementing NSX-T overlay have several options when it comes to migrating existing VLAN-connected workloads to NSX-T overlay segments. Common methods include re-IP’ing or re-deploying workloads to a new IP space allocated to NSX-T logical networking. It gives the workload somewhat of a fresh start. Besides, a re-IP process can be a very useful exercise
SDDC.Lab v2
Back in April I published a post about my GitHub repository containing Ansible scripts that perform automated deployment of nested vSphere/NSX-T lab environments. A lot has happened during the last 5 months and now that we’re close to making version 2 the default branch, I thought it would be a good time to give you
Automate Ubuntu Server 20.04 Installation with Ansible
And now something completely different. Recently, while working on a project, I had to come up with a way to automate Ubuntu Server 20.04 VM installations on vSphere. Utilizing Ubuntu’s new autoinstall method together with some Ansible code I managed to get something up and running. Decent enough to share it with you. Overview The
Configuring NSX-T 3.0 Stretched Networking
NSX-T 3.0 comes with brand new features for logical networking in multisite environments. With NSX-T Federation the platform effectively receives a location-aware management, control, and data plane and this gives us, the implementers and architects, some very interesting new options when designing and installing NSX-T 3.0 in a multisite scenario. Although Federation affects all major
