When upgrading my home lab to NSX-T 3.2.0.0 in December, I ran into an issue, where I got an error message: At that moment (3.2 was júst released) I took a look at some support articles (the benefit of being a VMware employee) and saw that I was not the only one having this issue. Shortly after encountering this, I saw that 3.2.0.0 was pulled as a method to do an upgrade (and was only available as a greenfield installation)…
One of my customers is looking to create an evironment with DR capabilities, from a networking point of view. We have looked at using Federation, but multiple reasons exist why this is currently not the best way to go forward on this. So I am looking for an alternative method to create redundancy across sites, without the need to renumber IP-addresses on virtual machines. In my home-lab I have an environment consisting of two (virtual) sites, connected to one (physical)…
In every production environment it is critical to do some good housekeeping, but the same goes for a lab environment, so I added a signed certificate and configured a (scheduled) backup for my NSX-T Managers. As you might know, I have three NSX-environments in my lab, two sites (A and B), and one Global Manager (G). For all environments the configuration is more or less identical, so I’ll only show the configuration of one of them. Backup Especially important in…
I was triggered by a question on an older post, to revisit the configuration and setup of load balancing. The setup we are working towards is: We start with creating the T1-R-1 and connecting it to the Stretched T0, that was created in an earlier activity (https://my-sddc.net/creating-stretched-networks-with-nsx-t-federation/): Not connected to an edge node cluster, to make sure we can still do multi-tier distributed routing (see https://my-sddc.net/distributed-multi-tier-routing-in-nsx-t/). We do advertise the connected segments to the T0 (and the T0 already knows…
After the initial configuration and setup of NSX-T local and global managers ánd setting up layer-3 communication (see previous blogs), we can go for the real new thing of NSX-T 3.0, stretched networking with Federation. We are aiming for the following setup: In order to set this up, we need Edge Nodes on both sites (we have those) and a configuration of Remote Tunnel Endpoints (RTEPs). We also need to create a stretched T0 and T1 and setup BGP to…
After the installation (https://my-sddc.net/nsx-t-global-manager-installation-and-initial-setup/) and initial configuration (https://my-sddc.net/nsx-t-3-0-initial-configuration/), we can start building networks. In order to get connectivity from the virtual network to the physical network, we need to setup layer-3 connectivity. In order to be able to do that, I bought a small Mikrotik device, to allow me to play around with BGP/BFD and VRF’s. What we need to do to get layer-3 connectivity is: Create transport zones for transit networks Create an uplink profile for edge nodes Setup…
This blog is to describe the initial configuration of NSX-T 3.0. After deploying the appliances and combining them into one environment (https://my-sddc.net/nsx-t-global-manager-installation-and-initial-setup/) and deploying the vSphere/vSAN environment (https://my-sddc.net/building-the-lab-vsphere-and-vsan/) it is time to combine the two and create the virtual network environment. As a reminder, our environment is going to look like this: but that’s mainly the physical side of it. The virtual side is still something I have to figure out, but for now, it’s roughly going to look like…
In my new lab environment, I will be working with two locations (Site A and Site B) and a Global NSX-T Manager to centrally manage the environment. For this, I installed a Global Manager after I deployed both Local Managers. Since I am not made of resources, all sites and the global environment will consist of one appliance, but in a production environment you would definitely need three per function. The installation of the Global Manager is almost identical to…
After the release of NSX-T 3.0, nothing stands in the way of upgrading our demo environment to NSX-T 3.0, making it ready for vSphere 7. Because I wanted to see the checks in the upgrade process of vSphere 7, where it will inform you of the interoperability of NSX-T, I started with the upgrade of the vCenter Server: and choosing Upgrade. After following the wizard a new appliance is deployed. This appliance will then be used to upgrade the current…
As you might know, I use a test/demo environment from my employer. In this environment, I can demo the VMware SDDC products for customers or colleagues. Since the start of the environment approx. four years ago, I had a demo around NSX for vSphere, but as you know, the product has been announced to go end of support in 2022 and there will be no more development on it. Also, VMware and my company (PQR) advise customers who start on…