Getting Started With NSX ALB: Part-3-NSX-T Integration

Manish Jha

In the previous post of this series, I discussed Avi controller deployment and basic configuration. It’s time to integrate NSX-T with NSX ALB. High-level steps of NSX-T integration are summarized below:

  • Create a Content Library in vCenter
  • Deploy a Tier-1 gateway for Avi Management.
  • Create Logical Segments in NSX-T for Avi SE VMs.
  • Create credentials for NSX-T and vCenter in Avi.
  • Register NSX-T with Avi Controller.
  • Create an IPAM profile. 

Let’s get started.

Create a Content Library in vCenter

Deployment of Avi Service Engine VMs is done automatically by the Avi Controller when we create a Virtual Service. For this to work, a content library must be created in the vCenter server as the controller pushes the Avi SE OVA into the content library and then deploys the SE VMs. 

Deploy Tier-1 gateway for Avi Management

You can use the existing Tier-1 gateway or deploy a new one (dedicated) for Avi management.… Read the rest

Getting Started With NSX ALB: Part-2- Avi Controller Deployment & Configuration

Manish Jha

The first post of this series talked about NSX ALB and its architecture. Also, I discussed features that make NSX ALB unique. In this post, I will discuss deployment and basic configuration, and later, I will discuss ALB integration with NSX-T.

Hardware requirements for Avi Controllers and Service Engine VMs are documented here

Prerequisites for NSX ALB Deployment:

  • vSphere is deployed and configured.
  • NSX-T Manager is deployed and is integrated with vCenter. The Tier-0 gateway is deployed and is paired with the physical network using BGP.

NSX-ALB Controller OVA can be downloaded from https://customerportal.avinetworks.com

Ova deployment is straightforward, and I am not covering the deployment wizard. Make sure to leave the Sysadmin login authentication key field blank when deploying the controller OVA. 

Once the Controller VM boots up, connect to the web interface of the controller by typing https://<Avi-Controller-ip>/

Configure the controller administrator account by setting up a password and email ID (for password reset in case of account lockout)

Configure DNS and NTP server information.… Read the rest

Getting Started With NSX ALB: Part-1- Introduction & Architecture

Manish Jha

NSX Advanced Load Balancer (formerly Avi Vantage) is a multi-cloud software-defined load balancer that provides scalable application delivery across any infrastructure. NSX ALB is 100% software-defined and provides:

  • Multi-cloud: Consistent experience across on-premises and cloud environments through central management and orchestration.
  • Intelligence: Built-in analytics drive actionable insights that make autoscaling seamless, automation intelligent, and decision making easy.
  • Automation: 100% RESTful APIs enable self-service provisioning and integration into the CI/CD pipeline for application delivery.

Note: The NSX ALB solution came through VMware’s acquisition of Avi Networks in 2019.

Some of the key features of NSX ALB are:

  • Autoscaling of Load Balancers and Applications.
  • Web Application Analytics & Performance Insights.
  • Automation for IT, self-service for developers.

To know more about these features, please visit Avi Networks website. 

NSX ALB Architecture

NSX-ALB consists of two main components:

  • Avi Controller.
  • Service Engines (SE).

Controllers are deployed by the platform administrator, and service engines are automatically deployed by the controller when we create virtual services.… Read the rest

Load Balancing VMware Cloud Director with NSX-T

Manish Jha

Recently, I tested NSX-T 3.1 integration with VCD 10.2 in my lab and blogged about it. It was a simple single-node deployment, as I was testing the integration. Later, I scaled my lab to 3 nodes and also used the NSX-T load balancer feature to test the load balancing of VCD cells.

To use the NSX-T load balancer, we can deploy VCD cells in 2 different ways:

  • Deploy VCD cells on overlay segments connected to the Tier-1 gateway and configure LB straight away (easy method).
  • Deploy VCD cells on a VLAN-backed port group and load balance them via a dedicated Tier-1 gateway.

In this post, I will demonstrate the second method. Before jumping into the lab, let me show you what is already there in my infrastructure.

In my lab, NSX-T follows the VDS + NVDS architecture. The management SDDC, where VCD cells are deployed, has a VDS named ‘Cloud-VDS,’ and I have a dedicated distributed portgroup named ‘VCD-Mgmt’ which is backed by VLAN 1800, and all my VCD cells are connected to this portgroup. … Read the rest

NSX-T integration with VMware Cloud Director 10

Manish Jha

VMware Cloud Director relies on the NSX network virtualization platform to provide on-demand creation and management of networks and networking services. NSX-V has been a building block of VCD infrastructure for quite a long time. With the release of NSX-T Datacenter, VMware clearly mentioned that NSX-T is the future of software-defined networking, and as a result customers slowly started migrating from NSX-V to NSX-T.

NSX-T 2.3 was the first version of  NSX-T which VCD (9.5) supported, but the integration was very basic and there were a lot of functionalities that were not available and it was stopping customers from using NSX-T full-fledged with VCD. NSX-T 2.5 added more functionalities in terms of VCD integration, but it was still lacking some features.

With the release of NSX-T 3.0, the game has changed and NSX-T is more tightly coupled with VCD and thus customers can leverage almost all functionalities of NSX-T with VCD. … Read the rest

NSX-T Federation-Part 4: Configure Stretched Networking

Manish Jha

Welcome to the fourth part of the NSX Federation series. In the last post, I talked about configuring local and global NSX-T managers to enable federation. In this post, I will show how we can leverage it to configure stretched networking across sites. 

If you have missed the earlier posts of this series, you can read them using the links below:

1: NSX-T Federation-Introduction & Architecture

2: NSX-T Federation-Lab Setup

3: Configure Federation

NSX-T Federation Topology

Before diving into the lab, I want to do a quick recap of the lab topology that I am building.

The following components in my lab are already built out:

1: Cross Link Router: This router is responsible for facilitating communication between Site-A & Site-B SDDC/NSX.

  • Site-A ToR01/02 are forming BGP neighborship with the Cross Link Router and advertising necessary subnets to enable inter-site communication.
  • Site-B ToR01/02 are also BGP peering with the Cross Link Router and advertising subnets. 
… Read the rest

NSX-T Federation-Part 3: Configure Federation

Manish Jha

Welcome to the third post of the NSX Federation series. In part 1 of this series, I discussed the architecture of the NSX-T federation, and part 2 was focused on my lab walkthrough.

In this post, I will show how to configure federation in NSX-T.

If you have missed the earlier posts of this series, you can read them using the below links:

1: NSX-T Federation-Introduction & Architecture

2: NSX-T Federation-Lab Setup

Let’s get started.

Federation Prerequisites

Before attempting to deploy and configure federation, you have to ensure that the following prerequisites are in place:

  • There must be a latency of 150 ms or less between sites.
  • Global Manager supports only Policy Mode. The federation does not support Manager Mode.
  • The Global Manager and all Local Managers must have NSX-T 3.0 installed.
  • NSX T Edge Clusters at each site are configured with RTEP IPs.
  • Intra-location tunnel endpoints (TEP) and inter-location tunnel endpoints (RTEP) must use separate VLANs.
… Read the rest

NSX-T Federation-Part 2: Lab Setup

Manish Jha

In the first part of the NSX-T federation series, I discussed about architecture and components of the federation and also discussed some use cases. In this post, I will explain my lab topology before diving into the NSX-T Federation configuration.

I am trying to setup a federation between 2 sites in my lab and on both sites, I have already deployed the following:

  • vSphere 7 (ESXi & vCenter).
  • vSAN for shared storage.
  • NSX-T 3.0 Manager.
  • NSX-T 3.0 Edges.

I have 4 ESXi hosts on each site, and each ESXi has 4 physical NICs. All 4 NICs are connected to a trunked port on ToR.

The networking architecture in my lab is a mix of VDS and N-VDS. 

2 NICs from each host are participating in routing regular datacenter traffic (Mgmt, vSAN & vMotion). 

The other 2 NICs are connected to N-VDS and carry overlay traffic. 

For edge networking, I am using multi-tep, single NVD-S architecture.… Read the rest

NSX-T Federation-Part 1: Introduction & Architecture

Manish Jha

NSX-T federation is one of the new features introduced in NSX-T 3.0, and it allows you to manage multiple NSX-T Data Center environments with a single pane of glass. Federation allows you to stretch NSX-T deployments over multiple sites and/or towards the public cloud while keeping a single pane of management. Federation can be compared with the Cross-vCenter feature of NSX-V, where universal objects span more than one site.

NSX-T Federation Components/Architecture/Topology

With the NSX-T Federation, the concept of a Global Manager (GM) is introduced, which enables a single pane of glass for all connected NSX-T managers. A global manager is an NSX-T manager deployed with the role “Global.” Objects created from the Global Manager console are called global objects and pushed to the connected local NSX-T Managers.

The diagram below shows the high-level architecture of the NSX-T Federation

You can create networking constructs (T0/T1 gateways, segments, etc.) from Global Manager that can be stretched across one or more locations.… Read the rest

HCX Service Mesh Operations via API

Manish Jha

Before deploying Service Mesh, we need to create Compute & Network Profiles in both source & destination HCX environment. The order of Service Mesh deployment is as follows:

  1. Create Network Profiles in source & destination HCX.
  2. Create Compute Profiles in source & destination HCX.
  3. Trigger Service Mesh deployment from on-prem (source) site.

In this post I will demonstrate HCX Service Mesh operations via API.

Some of the most common operation associated with service mesh can be:

  1. Create profiles (Network & Compute) and deploy service mesh.
  2. Update Network & Compute profiles to include/remove additional features.
  3. Delete Network & Compute profiles.
  4. Update Service Mesh to include/remove additional services.
  5. Delete Service Mesh. 

Let’s jump into lab and look at these operations in action.

Network Profile API

1: List Network Profiles: This API call list all the networks profiles that you have created to be used in service mesh. 

 

Note: Here objectId is the id of the various networks participating in network profiles

2: List Specific Network profile: This API call lists a specific network profile.… Read the rest