cars driving on urban highway in evening
Posted on

NSX Advanced Load Balancer (ALB) – Part 1 – Basic Virtual Service – Initial Setup, Prerequisites and Creating an NSX-T Cloud

Reading Time: 6 minutes

VMware NSX has offered load-balancing capabilities since its inception as VMware NSX for vSphere v6.0 way back in October 2013. Since then, the technology was superseded by VMware NSX-T 1.0 in May 2016 (later rebranded to VMware NSX-T Data Center (v2.2) and again to VMware NSX (v4.x)), thanks to VMware’s $1.26B acquisition of Nicira in 2012. VMware NSX-T brought us (and still does) truly hypervisor-agnostic networking, security, and native load-balancing capabilities.

In 2019, VMware acquired Avi Networks, leaders in software-defined application delivery services for the multi-cloud era. Furthermore, the VMware NSX Advanced Load Balancer (v18.2) was announced in November 2019 following this acquisition.

So, what about the NSX native load balancer? VMware will deprecate this feature in an upcoming release of VMware NSX (likely 5.x), but see below update for more information), however, no date has yet been released. However, VMware advises that customers take appropriate steps to migrate to the NSX Advanced Load Balancer (for which there is a free tier with appropriate VMware NSX licensing) as soon as possible.

Continue reading → NSX Advanced Load Balancer (ALB) – Part 1 – Basic Virtual Service – Initial Setup, Prerequisites and Creating an NSX-T Cloud

wood dirty writing abstract
Posted on

VMware NSX for vSphere to NSX-T Migration – End-to-End User Defined Topology – Config Translation Failed – Reason: Topology Plugin

Reading Time: 3 minutes

In a previous post focusing on the VMware NSX Migration Coordinator (VMware NSX for vSphere to NSX-T Migration – End-to-End User Defined Topology), I detailed the end-to-end process required to migrate VMware NSX Data Center for vSphere (NSX-V) to VMware NSX-T Data Center (now simply VMware NSX as of 4.x) and, more specifically, the ‘User Defined’ option, which allows customers to map NSX-V Edge Services Gateways (ESGs) and Distributed Logical Routers (DLRs) to NSX-T components (e.g., Tier-0 or Tier-1 Gateways). To perform this mapping, customers can either a) upload a pre-defined JSON file or b) use the NSX UI to select the appropriate Tier-0/Tier-1 Gateway via drop-down menus.

The previous post utilised VMware NSX Data Center for vSphere 6.4.13 and VMware NSX-T Data Center 3.2.1, however, labbing this in readiness for an upcoming customer engagement required VMware NSX Data Center for vSphere 6.4.14 and VMware NSX (formerly NSX-T) 4.0.1.1; herein lies the identification of a possible bug when using the UI to map ESGs/DLRs to Tier-0/Tier-1 Gateways.

Continue reading → VMware NSX for vSphere to NSX-T Migration – End-to-End User Defined Topology – Config Translation Failed – Reason: Topology Plugin

golden gate bridge san francisco california
Posted on

Extending Overlay Segments to VLAN via the VMware NSX Edge Bridge

Reading Time: 9 minutes

I’ve worked with many customers over the years who are new to VMware NSX. This generally means a full design and deployment of NSX, but to be honest, a) that’s the easy bit and b) it doesn’t give the customer much in the way of immediate value. After all, all we’ve done is deploy a software-defined networking platform and generally peered it with the physical environment.

The value begins once the Customer’s workload is actually housed on an NSX Segment. This is where we begin discussing workload migrations from physical VLANs/VDS port groups to NSX Overlay Segments. ‘Easy’ you say, ‘just migrate the virtual machines and re-IP, right’? That’s one option, however, what if the Customer has thousands of VMs? What if these VMs host mission-critical applications or applications which are prone to issues following re-IPing? Sometimes this option just isn’t feasible.

The best solution for this Customer might be to migrate workloads and retain IP addressing. We can achieve this by migrating the entire physical network into VMware NSX, however, we can also achieve this by creating a VMware NSX Edge Bridge, which effectively creates a layer-2 extension between a physical VLAN and an NSX Overlay Segment.

In this article, we will detail a number of migration scenarios before detailing the process of deploying and configuring a layer 2 extension via NSX Edge Bridge.

Continue reading → Extending Overlay Segments to VLAN via the VMware NSX Edge Bridge

photo of woman looking through camera
Posted on

VMware NSX Distributed Firewall (DFW) FQDN Filtering

Reading Time: 4 minutes

I recently had a great VMware NSX discussion with a contact on Twitter. They had reached out to me wondering if there was a way of restricting a VM’s connectivity to the internet by limiting its access to a set of wildcard addresses, e.g. *.example.com. The specific ask was to restrict access to Microsoft Windows Server Update Services, as the vast list of underlying IP addresses for *update.microsoft.com, *.download.windowsupdate.com, etc., changes regularly. In this scenario, utilising wildcards within the VMware NSX DFW rules would be hugely advantageous.

FQDN filtering within VMware NSX has been available for some time and is a quick and easy task to configure, either to allow or restrict traffic. In this article, we look at the process of implementing FQDN filtering and validate post-implementation.

Continue reading → VMware NSX Distributed Firewall (DFW) FQDN Filtering

flock of birds flying
Posted on

VMware NSX for vSphere to NSX-T Migration – End-to-End User Defined Topology

Reading Time: 12 minutes

Article Updated: 20th July 2023

In my previous post, I covered the end-to-end migration of VMware NSX for vSphere to NSX-T Data Center (VMware NSX from v4.0.0.1) via the Fixed Topology Option, however, in real life I don’t see this option utilised very often due to the limited number of supported topologies.

How then can we achieve the same in-place, end-to-end migration of unsupported topologies? This is where the User Defined Topology option comes into play, and it offers much greater flexibility by enabling customers to define/map their own logical routing topologies. This, of course, will require a design and, like the message I tried to impart in my previous post, this must be planned ahead of your proposed change/maintenance/migration window.

Continue reading → VMware NSX for vSphere to NSX-T Migration – End-to-End User Defined Topology

flock of white birds against a black background
Posted on

VMware NSX for vSphere to NSX-T Migration – End-to-End Fixed Topology

Reading Time: 9 minutes

In a previous post, we discussed the value of pre-migration validation checks, identifying whether a customer environment is aligned to the supported fixed topologies and the process of creating and viewing the JSON output following the successful import of NSX for vSphere configuration.

In this post, we continue on the same theme and will use the NSX-T (VMware NSX from v4.0.0.1) Migration Coordinator to migrate an NSX for vSphere environment, end-to-end, to NSX-T via the Fixed Topology option.

Continue reading → VMware NSX for vSphere to NSX-T Migration – End-to-End Fixed Topology

magnifying glass on top of document
Posted on

VMware NSX-T Migration Coordinator Report Export for Fixed Topology Migration

Reading Time: 4 minutes

With VMware NSX for vSphere (NSX-V) having gone end of general support on January 16th 2022, there are numerous customers now busily working on migrating to VMware NSX-T Data Center (VMware NSX as of v4.0.0.1).

In future posts, I will detail the end-to-end migration process for both Fixed and User Defined Topologies utilising the NSX-T Migration Coordinator, however, before we jump in, let us look at a rather handy report which is often helpful in validating customer readiness and environmental health for those looking to migrate via the Fixed Topology option.

Continue reading → VMware NSX-T Migration Coordinator Report Export for Fixed Topology Migration

Posted on

VMware NSX Micro-Segmentation Only Deployment

Reading Time: 7 minutes

When we talk about VMware NSX (formerly VMware NSX-T Data Center), most of us think about abstracting management of the network away from the physical fabric thanks to NSX’s magic sauce and overlay networking capability via Geneve encapsulation. However, overlay networking isn’t always the primary use case, with a high volume of customers opting for micro-segmentation only.

Some customers, for example, are happy to allow the network’s management and physical gateways to remain within the physical fabric. Perhaps their organisation already has an alternative software-defined networking product, or they simply don’t make that many changes within their network. So, how can customers use micro-segmentation via the NSX Distributed Firewall (DFW)? Simply put, by utilising currently existing vSphere environments and VDSs in conjunction with the NSX DFW.

Continue reading → VMware NSX Micro-Segmentation Only Deployment

Posted on

VMware NSX-T Data Center One-Arm Load Balancer for VLAN-Backed Workloads

Reading Time: 4 minutes

Scenario – Let us say I have a Customer who has a load balancing requirement, however, they do not utilise Overlay networking and, as a result, no Tier-0 or Tier-1 Gateways exist to form a software-defined routing architecture. As such, an Inline load balancer topology will not be possible. However, VLAN-backed NSX-T Segments are in place, as the customer currently utilises distributed firewalling.

This article looks at how we can deploy a Tier-1 Gateway for one-arm load balancing to backend virtual machines housed on VLAN-backed NSX-T Segments. Should we wish, we could expand the server pool by adding physical devices as well.

Continue reading → VMware NSX-T Data Center One-Arm Load Balancer for VLAN-Backed Workloads

Posted on

Securing Physical Workloads via the VMware NSX-T Gateway Firewall and Service Interface

Reading Time: 5 minutes

Where the NSX-T Distributed Firewall (DFW) provides stateful protection to workloads at the vNIC level from within for micro-segmentation of east-west traffic, the Gateway Firewall (GFW) provides centralised stateful protection of north-south traffic for perimeter firewalling. Depending on the use case, the GFW might secure traffic between physical and virtual servers, physical to physical servers, and within multi-tenant environments, DMZ’s or could be utilised for, for example, PCI compliance.

The GFW can be implemented per Gateway and is supported on both Tier-0 and Tier-1 Gateways. The GFW is also independent of the NSX-T DFW as it holds its own configuration and enforcement policies. Excitingly, we can also leverage the GFW to secure physical workloads housed on VLAN-backed networks via the Service Interface. This is particularly useful where customers are unable to utilise the VMware NSX-T Kernel Agent (think proprietary appliances/servers).

In this article, we take a look at the process of securing physical server workloads housed on VLAN-backed networks.

Continue reading → Securing Physical Workloads via the VMware NSX-T Gateway Firewall and Service Interface