VCF-9 – Part 3: Networking Models

Welcome to part 3 of the VCF-9 series. Part 1 of this series dived into VCF-9 architecture and deployment models, and Part 2 showcased the deployment of a VCF instance using the new VCF installer. In this post, I will discuss the networking models available in VCF-9.

If you are not following along, I encourage you to read the earlier parts of this series from the links below:

1: VCF-9 Architecture & Deployment Models

2: VCF Installer Walk-through

In VCF 9, NSX introduces two networking object models: VPC Networking and Segment Networking.

VPC Networking: The VPC networking model offers a streamlined approach for configuring networking and security services, making it accessible even to non-networking experts. It aligns with the user experience found in public cloud platforms and integrates seamlessly within the VCF stack. Cloud users can interact with the VPC model through the NSX UI/API, vCenter UI, VCF Automation, or Supervisor cluster.Read the rest

VCF-9 – Part 2: VCF Installer Walk-through

Welcome to part 2 of the VCF-9 series. In part 1, I discussed what’s new in VCF-9 and the deployment models and cluster topologies supported by VCF. In this post, I will walk through the deployment of VCF using the new VCF installer tool. 

The cloud builder tool that was included with earlier VCF editions has been replaced by the VCF installer. The new installer offers a whole new experience for deploying VCF instances and is lightweight. VCF-9 deployment methodology is more robust, well-designed, and efficient than the previous Excel-based Cloud Builder method. The installer can deploy VCF instances via UI or through JSON files and supports both brownfield and greenfield deployments. The installer also includes an improved built-in validation.

The VCF installer is available in the OVA file format and can be downloaded from here.

Prepping the Environment

Network & VLANs

I am using a VyOS router to provide network connectivity to my nested lab and have configured the following VLANs.Read the rest

VCF-9 – Part 1: Introduction & Architecture

Introduction

VCF-9 was introduced at VMware Explore 2024, marking a pivotal advancement in how enterprises build and manage private clouds. Designed to simplify and consolidate IT environments, VCF 9 promises faster deployment, streamlined consumption, and simplified management—all while boosting security and cost-efficiency. VCF-9 is aimed at allowing organizations to manage their entire infrastructure as a single, unified system.

Some of the key features of VCF-9 are:

1: Streamlined Infrastructure: One Platform, Many CapabilitiesVCF 9 integrates compute, networking, storage, and automation into a unified framework. This helps two main audiences:

  • Infrastructure teams can automate and simplify private cloud deployment.
  • Platform engineers & developers benefit from a self-service environment for VMs, containers, and Kubernetes workloads.

2: Tailored Experiences for Cloud Admins and Engineers

  • Cloud Admins: Gain a consolidated control center to manage capacity, policies, tenants, and security—all from a single console. Diagnostic tools and topology maps accelerate issue resolution.
  • Platform Engineers: Can self-provision environments across traditional VMs and modern container stacks.
Read the rest

NSX 4.x VRF Gateways – Part 5: Inter-VRF BGP Route Leaking

Welcome to part 5 of the NSX VRF series. In part 4, I discussed Inter-VRF routing that enables communication between VRF gateways in NSX by exchanging the routes that are not BGP, e.g., connected, NAT, and static routes, etc. In this post, I will discuss how route exchange can be facilitated over BGP. 

If you are not following along, I encourage you to read the earlier parts of this series from the links below:

1: NSX VRF Gateway – Architecture & Configuration

2: VRF Config Validation & Traffic Flows

3: VRF Route Leaking

4: Inter-VRF Routing

Introduction

Inter-VRF BGP route leaking allows routes learned in one VRF to be advertised to another VRF over BGP to enable communication between the isolated VRFs. It’s achieved through configuring BGP on Tier-0 VRF gateways and utilizing route maps and community lists to control the route leaking process. 

BGP route leaking supports leaking both IPv4 & IPv6 address families.Read the rest

NSX 4.X VRF Issue “Overlapping Trunk VLAN on Logical Switch”

I came across an interesting issue while configuring VRF gateways in NSX 4.x. The configuration was erroring out with the message “Logical Switch trunk-vlan overlapping with another Logical Switch in the same underlying Edge host-switch is not allowed. Change VLAN configuration.”

After configuring the Tier-0 VRF Gateways, the parent Tier-0 went down.

Also, 2 out of 4 interfaces on the VRF gateway were stuck in the configuring state. 

The Cause

The main cause of this issue was that I created 2 trunked segments for northbound connectivity and allowed the same range of VLANs on them.

This method used to work perfectly fine in NSX 3.x. I have blogged on this topic earlier. So, I was wondering why the same steps are not working.

While troubleshooting, I came across this post by Graham Smith on Broadcom’s community channel. He has provided the resolution in his blog post here.

In NSX 3.x,Read the rest

NSX 4.x VRF Gateways – Part 4: Inter-VRF Routing

Welcome to part 4 of the NSX VRF series. In part 3, I discussed VRF route leaking that allows communication between 2 data plane isolated VRF gateways in NSX. 

In this post, I will discuss Inter-VRF routing.

If you are not following along, I encourage you to read the earlier parts of this series from the links below:

1: NSX VRF Gateway – Architecture & Configuration

2: VRF Config Validation & Traffic Flows

3: VRF Route Leaking

Inter-VRF routing was first introduced in NSX 4.1.0, and it allows exchanging routes between VRFs. The route exchange happens between VRFs over an internally plumbed Inter-VRF transit link. 

You can configure Inter-VRF routing between:

  • Parent Tier-0 gateway and Tier-0 VRF gateway.
  • From Tier-0 VRF gateway to parent Tier-0 gateway.
  • From one Tier-0 VRF gateway to another Tier-0 VRF gateway.

To exchange routes between the gateways, you can use one of the following methods:

  • Inter-VRF Route Advertisement – Advertise routes that are not BGP, such as static, connected, NAT, etc, that are available as inter-vrf static routes on the connected gateway.
Read the rest

NSX 4.x VRF Gateways – Part 3: VRF Route Leaking

Welcome to part-2 of the NSX VRF series. Part 1 of this series discussed VRF architecture, and part 2 demonstrated data plane isolation between the VRF instances.

In this post, I will demonstrate how to establish communication between 2 VRFs using VRF Route Leaking.

If you are not following along, I encourage you to read the earlier parts of this series from the links below:

1: NSX VRF Gateway – Architecture & Configuration

2: VRF Config Validation & Traffic Flows

By default, the data plane traffic between VRF instances is isolated in NSX. You can exchange traffic between 2 VRFs by configuring VRF Route Leaking. In this technique, static routes are configured on the VRF gateways to steer traffic towards other VRF gateways.

There are 2 supported topologies for VRF route leaking:

  • Local VRF-to-VRF route leaking
  • Northbound VRF leaking

Note: A multi-tier routing architecture is required for traffic to be exchanged in a VRF leaking topology, as static routes pointing to Tier-1 distributed router (DR) uplinks are necessary.Read the rest

NSX 4.x VRF Gateways – Part 2: VRF Config Validation & Traffic Flows

Welcome to part-2 of the NSX VRF series. Part 1 of this series discussed VRF architecture and its use cases and the advantages that VRF offers over traditional routing isolation techniques. In this post, I will demonstrate VRF configuration validation to ensure things are working as expected. 

The following configuration was done in vSphere before VRF validation:

  • VRF-Red VM is deployed and connected to segment “red-ls01” and has IP 192.168.40.2
  • VRF-Blue VM is deployed and connected to segment “blue-ls01” and has IP 192.168.50.2

Connectivity Test

The blue VRF VM can:

  • Ping its default gateway.
  • Uplink interface used for BGP peering.
  • An IP from the physical network.

However, the Blue VRF VM can’t ping the Red VRF gateway or any of its VMs.

The same tests were performed on the Red VFR VM and validated that it can’t reach the Blue VRF gateway or its VM.

You can run similar tests using the NSX Traceflow tool.Read the rest

NSX 4.x VRF Gateways – Part 1: VRF Architecture & Configuration

Introduction

VMware NSX has been providing multi-tenancy capabilities to an SDDC since its inception. There are various ways to achieve it, depending on the use cases. In the simplest architecture, multi-tenancy is achieved by creating and connecting various Tier-1 gateways to a Tier-0 gateway, where each Tier-1 gateway belongs to a dedicated tenant with a non-overlapping network. Having several Tier-0 gateways, each owned by a different tenant, is another way of achieving multi-tenancy.

Multi-tenancy without NSX VRF

The concept of VRF is not new with NSX. It has been since v3.x of NSX. The VRF functionality has changed and gained new features with the latest iterations of NSX.

Virtual Routing and Forwarding (VRF) allows NSX admins to virtualize the routing table on a Tier-0 gateway and provide tenant separation from a routing perspective. With VRF, you can configure per-tenant data plane isolation up to the physical network without creating a Tier-0 gateway per tenant.Read the rest

How to Upgrade NSX ALB in a GSLB Setup

The Global Server Load Balancing (GSLB) function of NSX ALB (Avi) enables load balancing for globally distributed applications/workloads (usually, different data centers and public clouds). GSLB offers efficient traffic distribution across widely scattered application servers. This enables an organization to run several sites in either Active-Active (load balancing and disaster recovery) or Active-Standby (DR) mode.

In a GSLB setup, the corporate DNS server delegates one or more subdomains to Avi GSLB, which then owns these domains and provides responses to DNS queries from clients. DNS based load balancing is implemented by creating a DNS Virtual Service in Avi. In a GSLB setup, one site is designated as the GSLB leader, and the rest of the sites are GSLB followers. 

If you are new to GSLB, I encourage you to read about the same from the links below:

1: Avi GSLB in VMware Cloud on AWS

2: Avi GSLB for Containerized Workloads

Upgrading Avi controllers is pretty straightforward and is well documented in the product documentation.Read the rest