vCloud Air Data Protection:Part-1:Introduction

Everybody knows how important is to backup your critical workloads in your infrastructure. The need to protect workloads is the same whether it’s onsite or in the cloud.vCloud Air Data Protection services ensures business continuity for the workloads which are running in your vCloud Air environment.

So what is vCloud Air Data Protection exactly?  

VMware vCloud® Air Data Protection offers secure, policy-based backup and recovery in the cloud for virtual machines hosted exclusively on vCloud Air. It is an agent-less, self-service, policy-driven backup and recovery service with works on the principle of image-level backups.

As compared to traditional file-based backup and recovery solutions, vCloud Air Data Protection uses image-level backups to ensure all operating system, file system and application data encapsulated within a virtual machine are captured as a snapshot image before being committed to backup media.

The self-service backup features give customers a confidence to run their critical workloads in vCloud Air without worrying about data loss.

The below diagram illustrates high level overview of how DPS works in vCloud Air


Graphic Thanks to

Benefits of vCloud Air Data Protection?

Following are the benefits which an end user will get with DPS is vCloud Air:

  • Backup policy affinity controls per Virtual DataCenter (VDC) or per vApp
  • Daily (24-hour) Recovery Point Objective (RPO) guarantee
  • Virtual machine (image-level) Restore Granularity Objective (RGO)
  • Custom backup window scheduling
  • Configurable data retention
  • On-demand backups
  • Intelligent consumption tracking and activity reports

How vCloud Air DPS Works?

Data Protection uses snapshots to take the image level backup of Virtual Machines. When a backup is initiated, a snapshot of that VM is taken.  Post completion of the snapshot, it is then stored on the Data Protection storage (which is different than the storage which customers get when they purchase compute bits from vCloud Air) for the duration of the retention period defined in the policy.

The first backup is always a full backup and post that DPS leverages Change Block Tracking (CBT) and only backups the delta changes.Once the retention period is expired, the very first backup of the VM is deleted.

Below image summarizes the high level workflow of DPS


Graphic Thanks to

Data Protection Policies

Using the Data Protection Service, you can set data protection policies for your virtual data centers and vApps to meet your protection needs. You can apply data protection policies in the following ways:

1: To a virtual data center (Enabled mode): When you enable data protection for a virtual data center, all the virtual machines added to that virtual data center are protected automatically.

2: To a vApp directly (Self Service mode): When you switch to Self Service mode, the Data Protection Service does not back up all virtual machines in that data center automatically. You have the option to choose which virtual machines to back up and to apply individual policies to those virtual machines.

Note: To enable data protection for a virtual data center, you must be logged into vCloud Air as a virtual infrastructure administrator. If you are logged in as an end user, you can set backup policies only for the vApps you own.

Why Should Customer choose vCloud Air Data Protection Service?

DPS is different from the traditional backup and recovery techniques. Below are the 2 main features which makes DPS so popular:

1: Non-intrusive Protection for any Operating System and Application

By leveraging the Storage APIs at the vSphere layer in vCloud Air, DPS is able to use a combination of inline I/O quiescing and snapshot techniques at the virtualization layer to capture a crash-consistent image replica of any vApp and its virtual machine members.

These point-in-time replicas are made possible in Data Protection without having to install custom software agents, which often result in resource contention and potential performance degradation during an active backup window.

2: Multilayer Restore Workflows for Advanced Recovery

Data Protection helps streamline data recovery operations by offering dual self-service restore modes that can each address variable use cases:

  • In-place restore : Recovering from a backup replaces the protected virtual machine
  • Out-of-place restore: Recovered VM from backup is deployed as a separate VM.

Whether recovering a single virtual machine that has been accidentally deleted or an entire vApp with multiple virtual machine members assigned, each restore mode ensures that data is safely recovered with minimal disruption to ongoing operations.

Storage Considerations for DPS:

  • Backups on standard storage are limited by 200 IOPs per virtual machine disk (VMDK) and a 23 hour timeout. This allows ~300GB backups per VMDK for a backup if there is very minimal load on the disks. This should be considered when planning backups for vApps and individual virtual machines.
  • Recommended sizes for backups when using SSD accelerated storage are no greater than 2TB per VMDK with a total vApp size under 10 terabytes.
  • If the virtual machines are on standard storage, VMWare recommends that the VMDKs be no larger than 300 gigabytes each with a total vApp size under 2 terabytes.

For full list of DPS Best Practices please see VMware KB-2119537

How to Buy DPS?

A subscription to Data Protection can be purchased through MyVMware®. After the subscription is activated, a customer can begin using Data Protection through the vCloud Air console.

Thats it for this post. In next post of this series we will look into how to schedule a backup on a vApp/VM using DPS and how to restore it from backup.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)


Posted in vCloud Air | Leave a comment

Troubleshooting Edge Gateway High Availability

Yesterday I was working on Edge Services Gateway in my Lab and deployed the edge gateway in HA mode. Soon after the deployment when I checked the HA status from vCenter, it reported status as Down


To counter any UI bug which might be reporting HA status as down (as this was a brand new deployment), I decided to check the HA status by logging onto edge vm’s directly.

On checking for the HA status on the VM, below message was displayed

Highavalibity healthcheck server is stopped



I did a search on google for this message and didn’t get much results. Then I checked the Admin guide for NSX and came to know the fact that you should have at least one vNIC configured as High availability traffic flows on one of the internal interface.

By design the edge High Availability Service will only kick in once the first Internal vNIC has been added and configured. If you have enabled HA after doing the initial interface configurations you won’t have this issue as during the HA setup you are asked which vNIC to choose. If you enable HA without a vNIC configured the service won’t kick in until that vNIC is in play.

On checking my HA configuration I found that I have not configured any internal interface on my edge gateway.


I went ahead and finally configured vNIC1 interface


As soon as the internal interface was configured, High availability was established on the edge gateway.


On doing a check on edge VM’s, confirmed that one of em is active and other is standby



I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in NSX | Leave a comment

Learning NSX-Part-9-Edge Services Gateway

In last 2 post of the series we discussed about Distributed Logical Router. Moving forward in NSX learning series, we will look into what is Edge Service Gateway and will discuss on when to use edge gateway. We will look into deploying ESG and configuring it and then finally some touch down points on monitoring Edge gateways.

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

1: Introduction to VMware NSX

2: Installing and Configuring NSX Manager

3: Deploying NSX Controllers

4: Preparing Esxi Hosts and Cluster

5: Configure VXLAN on the ESXi Hosts

6: Logical Switching

7: Distributed Logical Router Tidbits

8: Installing Distributed Logical Router

In VMware NSX for vSphere there are two different types of NSX routers which can be deployed in virtual network infrastructure.

  1. The NSX Edge Services Router (ESR)
  2. The NSX Distributed Logical Router (DLR)

Both the ESR and DLR can run dynamic routing protocols, or not. Both of them support Static/default routes as well.

Although we can use Logical route to route between 2 or more logical networks, and physical networks, the recommended way is to use an Edge Services router. The ESR has a number of features such as Firewall, DHCP Services, NAT, load balancing and VPN services.

Difference between ESR and DLR?

ESR can be think of a router contained within a VM. Both the control plane and data plane resides in the VM, but ESR is more than just a router. It provides supports for L4-L7 services like FW, LB, NAT, VPN. ESR can establish routing protocol sessions with other routers and all of the traffic flows through this VM.

In DLR the data plane is distributed in kernel modules at each vSphere host, while the control plane exists in a VM (LRC).  The control plane VM in turn relies on the NSX controller cluster to push routing updates to the kernel modules.

When to use ESR?

In last post of the series we discussed that with evolution of virtualization/cloud computing, the amount of East-West traffic in datacenter have grown significantly. We also discussed about the hair-pinning of traffic and how DLR can be used to reduce the East-West traffic and get rid of hair-pinning issue.

As compared to DLR, ESR is unique in its own way. It’s more than a just router.  Using ESR we can leverage features such as firewall, load balancer, and VPN etc and because of this, it works well as the device handling the North-South traffic at the perimeter of your virtual network.

Since ESR is deployed as a VM, we can have virtually unlimited ESR’s running in parallel, each establishing the secure perimeter for their own.

Lets jump into the lab now and see the installation/configuration of ESG.

The edge gateway is deployed in the same way as a distributed router instance. To deploy an ESG, navigate to Networking & Security > NSX Edge. 

1: Click on the  (plus) button to open the deployment wizard.


2: Select Edge Services Gateway and enter the name of your Edge gateway . You can also configure a hostname.

If you want edge gateway to be highly available, check mark the “Enable High Availability” option. Hit Next to continue.


3: Provide the password for the admin user (atleast 12 characters long)

If you want to manage Edge Gateway over ssh then enable ssh access. Enabling auto rule generation, which will create necessary rules automatically when edge services such as VPN and load balancing are enabled:


4: Click Next and select the Appliance Size. There are a number of options for the appliance size. I have chosen ‘Compact’ in my lab environment. Click on (plus)  to select the Cluster/Resource Pool/Datastore/ Host etc where the edge will be deployed.

More on what should be an ideal choice for edge size, please read this article




5:  Click on (plus)  to Configure edge gateway’s interfaces.


6: Select the uplink interface and select the port-group to which this uplink will connect to. Assign an IP Address and subnet mask for the interface.

Note that it could be either a Public IP (in case of Uplink connected to a public network) either a private (in case of a Firewall inter-vlan or internal network)

Hit OK once you have entered all the information.


Click on next to continue the deploy wizard.

7:  For Default gateway settings, select the vNIC where your gateway will be connected to and enter the Gateway IP. Hit Next to continue.


8: On the next screen you can, optionally, select to configure the Firewall default policy:


9: On Ready to Complete page review your settings and hit finish to complete ESG deployment wizard.


10: In vCenter Recent task pane you can see edge vm deployment has been kicked off.


11: Under NSX Edges you can see your newly created edge gateway listed there.


12: Under VM and Templates view in vCenter, you can verify that 2 edge VM’s have been deployed (as we deployed edge in HA mode). You can select the edge VM to verify that VM is now up and running. Additionally you can check how much RAM/CPU has been assigned to the edge VM.


16: Double click on the edge gateway from Network & Security > NSX Edges view to open up the edge gateway configuration options.

Click on Manage > Settings > Configuration to add additional configuration items like defining a syslog server where edge gateway can forward the logs, DNS Settings on edge gateway etc.

Also verify the HA status of edge VM from this page.


17: By navigating to Monitor > Statistics tab, you can grab the Interface throughput stats and concurrent connection data for your edge gateway.


18: Finally if you click Actions button, it will bring a drop down menu which provides additional options available on edge gateway like Force Sync (it reboots the edge gateway backing VM’s), Edge re-deployment etc (this deletes the existing edge VM’s from vCenter a new VM is deployed).

You can also change the edge gateway admin user credentials by selecting Change CLI Credentials, also you change logging level etc from the dropdown menu.


I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in NSX | Leave a comment

Learning NSX-Part-8-Installing Distributed Logical Router

In last post of this series we discussed about distributed logical router and went through some important terms and terminologies. In this post we will jump into lab and will deploy logical distributed router.

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

1: Introduction to VMware NSX

2: Installing and Configuring NSX Manager

3: Deploying NSX Controllers

4: Preparing Esxi Hosts and Cluster

5: Configure VXLAN on the ESXi Hosts

6: Logical Switching

7: Distributed Logical Router Tidbits

Before jumping into deploying distributed router, I want to stress on the fact that your logical switches be ready. What i mean here since you wanna test routing between 2 or more different subnets, you should have logical switches ready in place and should have some live VM’s attached to it.

In my lab I have 3 logical switches created for this purpose.


Lets jump into lab now.

1: To Deploy Logical Router login to vSphere Web Client and navigate to Networking & Security -> NSX Edges .Click on ‘+’ to add NSX Logical router.


2: On the New NSX Edge page, select Logical Router option and provide a name,hostname and sweet little description description. If you want your edges highly available, select the checkbox that says “Enable High Availability”. Hit Next to continue.


3: Supply the admin password and set the log level to emergency (if you dont want disk space of your edge appliance getting filled quickly)

I like doing things over ssh, so I have enabled SSH on my edge appliance which will be deployed. Hit next.


Note: If password for your edge appliance is contains less than 12 characters, then you are going to get below warning.


4: On configure deployment page, select the virtual datacenter where LDR will be deployed.

Click on green ‘+’ button which says NSX edge appliances. This will deploy DLR Control VM.


5: Specify the Cluster, Datastore, Host and Folder to deploy the DLR Control VM and hit ok.


6: On the Configure interfaces page, click the select button.


It will open a new window from where you can select the management network for the edge interface.

A note about Management Interface Configuration

Management Interface is not a LIF, it’s local to the Control VM and does not require an IP address assigned and even if you configure one you wouldn’t be able to reach it via a routing protocol because there’s Reverse Path Forwarding (RPF) enabled.


It should look like as shown below. Click on “Configure interface of this NSX Edge” to define your LIF’s.


7: On the Add Interface dialog box, Enter the name of Interface, Select Type, Click Select Link for Connected To: and choose the desired Logical Switch and OK.


Select the logical switch to which your LIF will connect to.


After selecting the logical switch with which this LIF will connect to, we have to define IP address and subnet mask for the LIF.


Using the ‘+’ symbol repeat the wizard until you have created all the LIFs required in your environment.


8: Next and optional, configure a default gateway for the DLR. This typically would be the EGW ip address.


9: On ready to complete page, review your settings and hit finish to start deploying the DLR.


10: Post deployment of DLR, if you navigate to VM and templates view, you will see 2 VM’s deployed (as I chose HA option during deployment). One of these VM will be in active mode and other in standby mode.


Also if you click on NSX edges under Networking and Security, you will se ethe newly created edge listed there.


Double click on the edge and navigate to Manage > Configuration tab, and you can verify from here as well that 2 control VM’s are deployed and one of em is currently active.

You will also find options like changing the edge size from compact to Large or Quad Large, option to define syslog server where edge will route all the logs and option to change HA configuration.


11: On VM and Templates select Logical Router and select Summary tab. Here you will see all the IP’s assigned on your edge VM.


DLR deployment verification steps:

1:  Check DLR instance

From NSX Controller run

show control-cluster logical-routers instance all

This commands shows all the dLR instances and the corresponding hosts (VTEPs) that have joined. This command is very useful when something like routes are not propagated from the Control VM to the hosts.


2: Check Routing Table on ESXi host.

From ESXi, find the DLR name with the command

net-vdr -l -I


3: Check the routing table installed on the host coming from that dLR

net-vdr -l --route default+edge-1


4: On NSX Controller run following commands to see info about MAC Table/ARP table

show control-cluster logical-switches vni 5000 show control-cluster logical-switches mac-table 5001 show control-cluster logical-switches arp-table 5001


Note: In my lab ARP table/Mac Table returns as empty because I dont have any running VM’s connected to my logical switch yet.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in NSX | Leave a comment

Learning NSX-Part-7-Distributed Logical Router Tidbits

In last post of this series we discussed about Logical Switching and understood when do we use logical switching. Also we deployed our first logical switch and moved a VM over to the newly created switch.

In this post we will discuss about Distributed Logical Router and look at the terms and terminology associated with it. We will not be diving into lab in this post as I intend to this in next post of this series

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

1: Introduction to VMware NSX

2: Installing and Configuring NSX Manager

3: Deploying NSX Controllers

4: Preparing Esxi Hosts and Cluster

5: Configure VXLAN on the ESXi Hosts

6: Logical Switching


Physical Routers are the building block of any network infrastructure. They are essential for building a working network topology. As we know Routers comes into picture when we need communication between 2 different subnets. The problem with physical networking was that the topology becomes more and more complex as infrastructure is scaled out and the network devices had to process a lot of East-West and North-South traffic.

SDN  has simplified the networking and helped in breaking the silos of traditional physical networking. As we need routers in physical environments, we need to have similar capabilities in virtual networking world also.

With VMware NSX-v Routing between IP subnets can be performed in a logical space without traffic going out to the physical router. This routing is performed in the hypervisor kernel with a minimal CPU and memory overhead. This functionality provides an optimal data-path for routing traffic within the virtual infrastructure.

What is a DLR?

The Distributed Logical Router, or DLR, does what it says, it routes: it’s a router.

Like traditional routers, we can configure and use routing protocols such OSPF, IS-IS & BGP. DLR also provides a very cool feature known as “Layer 2 bridging”, which allows NSX VXLAN Logical Switch port group to talk to the regular VLAN out there on physical switch.

Distributed routing provides an optimized and scalable way of handling East – West traffic within a data center. If you are not familiar with what is East – West traffic, then it is the traffic which originates when virtual machines within a datacenter talk to each other. As virtualization has grown over time, virtual machines had replaced the physical servers and thus the amount of East–West traffic in the datacenter is growing.

In a vSphere environment virtual machines that are connected to different subnets (portgroups) want to communicate with each other, the communication between these VM’s has to go via physical adapter connected to the Esxi host to the physical switch and then it traverse to physical router which in turn does the routing and routes packets accordingly. The packets then follow the reverse path and reaches to destination VM. This non optimal flow of packet is referred to as “hair-pinning”

Distributed Router in VMware NSX prevents “hair pinning” by providing hypervisor level routing. Each hypervisor has a routing kernel module that performs routing between the logical interfaces (LIFs). We will discuss about LIF’s shortly.

Components of DLR

A DLR consists of following components:

  • Data plane : Data plane is kernel module installed on each vSphere host. DLR get installed on vSphere hosts along with VXLAN and DFW modules when we prep it ( we have done this activity in previous post of this series.
  • Control Plane : Control plane is made up of virtual machines running as what we call as Logical Router Controller or LRC. Every time Distributed Router is deployed, a “Control VM” is deployed alongside.
  • LRC VM’s are the supervisor Module. They are responsible for doing the routing updates, pairing or neighbor relationship with Edge service gateways or other physical routers and then it passes that information to NSX controllers and down to the vSphere hosts. Controller VM’s are not in data plane and data continues to flow even if controller vm’s are down, but you will not get routing updates or changes. When no control VM is available, packets are routed with last known configuration.
  • Management Plane : The management plane for Distributed Logical Routers is, like every other NSX component, part of the vSphere Web Client. You’ll find everything you need to configure and manage your Distributed Router Instances under the NSX Edges tab.

Logical Interfaces (LIF’s)

The distributed logical router possess and manage the logical interfaces (LIF’s). The LIF concept is similar to VLAN interfaces on a physical router. A DLR can have a maximum of 1,000 LIF’s. We discussed above that the routing kernel module present on each vSphere host performs routing between the LIFs.

When the LIF is connected to a VLAN, the LIF has a pMAC and when the LIF is connected to a VXLAN, the LIF has a vMAC.


Where does DLR fit in to NSX infrastructure?

The recommended use case for Distributed Logical Routers is East-West traffic. We already discussed above what is a East-West traffic. DLR helps in reducing East-West traffic as each vSphere host is capable of doing L3 routing and thus virtual machine communication traffic do not need to go out to physical router to get routed.

For handling North-South traffic (traffic that leaves your virtual infrastructure or datacenter),VMware recommendation is to use Edge Service Gateways. The main benefit of using Distributed Routers is to take advantage of the optimized data path that network takes when routed by a DLR. Using DLR’s you can avoid “hairpinning” problems and thus can achieve a low packet transit time and saves network bandwidth.

Below diagram taken from a cisco UCS environments explains how NSX reduces East-west or North-South traffic.


For a deep-dive on different use cases for DLR or other NSX architecture related knowledge, have a look on this awesome document from VMware: Architecting-a-VMware-NSX-Solution

The below diagram gives a high level overview of how DLR fits into your infrastructure.


DLR Interfaces type

In DLR we have three types of interfaces. These are called Uplink, LIFs and Management.

Uplink: This connects the DLR Control VM to the upstream router. In some documents you will see that uplink is also referred to as “transit”, and this interface is the transit interface between the logical space to the physical space. The DLR supports both OSPF and BGP on its Uplink Interface, but cannot run both at the same time. We can only enable OSPF on a single Uplink Interface.

LIFs: LIFs exist on the ESXi host at the kernel level; LIFs are the Layer 3 interface that act as the default gateway for all VM’s connected to logical switches.

Management: DLR management interface can be used for different purposes. The first one is to manage the DLR control VM remote access like SSH. Another use case is for High Availability. The last one is to send out syslog information to a syslog server.

The management interface is part of the routing table of the control VM; there is no separate routing table. When we configure an IP address for the management interface only devices on the same subnet as the Management subnet will be able to reach the DLR Control VM management IP, and the remote device will not be able to contact this IP.

The below image is diagrammatic explanation of above.


 DLR Interfaces Type

I will wrap my post here else it will be a super large boring post, but believe me world of DLR has not finished yet. A lot of things about DLR is yet to cover, but instead of writing up everything here, I would recommend reading below articles from fine gentlemens.

1: How Distributed Routing or DLR works by Joseph Griffiths

2: A deep dive into NSX Distributed Routing by Roie Ben Haim

3: Distributed virtual and physical routing in VMware NSX for vSphere by Brad Hedlund

In next post of this series we will deploy a DLR and see how to configure it. Stay Tuned!!!

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)

Posted in NSX, Vmware | 2 Comments

Delete Stale Org Networks and Edge Gateway from vCloud Director

Today while working in production, I came across an issue where the edge VM’s backing the edge gateway were not present in vCenter (no idea how they got deleted). Due to this I was not able to delete the Org network from vCD. Any attempt to delete the Org network was failing with error

[ f3fcd1fd-cf1c-4a57-a920-504204dceba7 ] Cannot delete organization VDC network DMZ (0dff6592-df7c-4e02-a106-5f0ed722d601)
Cannot update edge gateway "urn:uuid:f41b9f5a-0389-4781-ae0d-4b9cd19e9756"

java.util.concurrent.ExecutionException: com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (202): The requested object : edge-xyz could not be found. Object identifiers are case sensitive.

- Cannot update edge gateway "urn:uuid:f41b9f5a-0389-4781-ae0d-4b9cd19e9756"
java.util.concurrent.ExecutionException: com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (202): The requested object : edge-xyz could not be found. Object identifiers are case sensitive.

- java.util.concurrent.ExecutionException: com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (202): The requested object : edge-xyz could not be found. Object identifiers are case sensitive.

- com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (202): The requested object : edge-xyz could not be found. Object identifiers are case sensitive.

- VSM response error (202): The requested object : edge-xyz could not be found. Object identifiers are case sensitive.

This is what I was seeing in vCloud Director


On further investigation I found that the virtual wires associated with the problematic network were present in vCenter but on selecting the virtual machine tab for the virtualwire (distributed portgroup), I was not seeing any VM connected. Typically an edge VM should appear in the list.

That is when I found that edge VM’s were gone from vCenter.

Tried to re-deploy edge gateway and it also failed. Got same error about edge VM’s not being present

[ 8580da07-1ce4-440f-b126-0e5c8cca6e3e ] Cannot redeploy edge gateway XYZ (urn:uuid:f41b9f5a-0389-4781-ae0d-4b9cd19e9756)
com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (202): The requested object : edge-xyz could not be found. Object identifiers are case sensitive.

- com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (202): The requested object : edge-xyz could not be found. Object identifiers are case sensitive.

- VSM response error (202): The requested object : edge-xyz could not be found. Object identifiers are case sensitive.

In this situation there is nothing much you can do. You need to hack your VCD DB and remove the stale entries from the database which would cause those entries to disappear from vCD UI.

First of all delete all virtual wires corresponding  to the stale Org network from vCenter.

Secondly you need to analyze the database to look into the tables where info about those Org networks is stored. Typically you have to  use following queries:

1: Find Org vDC ID where your stale networks exists

select id ,vdc_id ,name FROM vdc_logical_resource where lr_type= ‘NETWORK’ AND name = ‘Org_nw_name’;

Output (Assuming your org network name is ABC)

id       vdc_id   name

2: List all Org Networks in your Org VDC (In case you have more than one stale network)

Select id, name from vdc_logical_resource where vdc_id = 0xBBBBB AND lr_type = ‘NETWORK’;

In this example I am assuming that you have 3 stale Org network namely ABC,DEF and XYZ

id        name

Note: In case you have several org networks associated with your edge gateway but there is only one problematic (stale) org network, then you can modify the above query as shown below.

Select id, name from vdc_logical_resource where vdc_id = 0xBBBBB  lr_type = ‘NETWORK’ AND name = ‘Org_nw_name’;

This query will specifically return record of the stale network and thus will prevent accidental deletion of any healthy org network

3: Find Logical network id and gateway id

select display_name, id, gateway_id, logical_network_id from gateway_interface where display_name = ‘ABC’;

display_name       id       gateway_id   logical_network_id
ABC             0xF41B9F      0x8EEB1C       0x9FCD1Y

4: Query for link_lnet_id

select id,link_lnet_id FROM logical_network WHERE name = ‘ABC’

id                                  link_lnet_id
0x8EEB1C757916483893A633FF3E459ECE  NULL

Once you have all the information in place, use following delete queries to remove the records of the stale networks from vCD UI

delete FROM vdc_logical_resource WHERE id = 0xAAAAAAA;

delete FROM gateway_assigned_ip WHERE gateway_interface_id = 0xF41B9F;

delete FROM gateway_interface WHERE logical_network_id = 0x9FCD1Y;

delete FROM logical_network WHERE name = ‘ABC’;

Once you have deleted all stale networks and intend to delete edge gateway as well, you can do so by firing the below query

delete FROM gateway WHERE id = Edge_gw_id;


delete FROM gateway WHERE id = 0xF41B9F5A03894781AE0D4B9CD19E9756;

Posted in vCloud Director | Leave a comment

Learning NSX-Part-6-Logical Switching and Transport Zones

In last post of this series we briefly looked what is VXLAN (In actual it’s an ocean of knowledge in itself) and also we configured VXLAN on our cluster/hosts.

In this post we will be talking about Logical switching and we will see how to create that and will cover prerequisites part as well.

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

1: Introduction to VMware NSX

2: Installing and Configuring NSX Manager

3: Deploying NSX Controllers

4: Preparing Esxi Hosts and Cluster

5: Configure VXLAN on the ESXi Hosts

Let’s start with introduction to Logical Switching.

What is Logical Switching?

Functionality of a Logical switch is very similar to that of a physical switch i.e they allow isolation of applications and tenants for security purpose. A logical switch when deployed, creates a broadcast domain to allow isolation of the VM’s running in infrastructure.

Logical switches provides you with capability of creating VLAN’s (similar to in physical world) and these VLAN’s not only provides isolation but can also span across large compute clusters.

The logical switch is mapped to a VXLAN that encapsulates the traffic going over physical network.

Logical switches can be created as either local or as universal (which can span  across vCenter’s in a cross-vCenter NSX deployment architecture). Universal logical switch can aid you with capability of extending your VXLAN across two different sites.

Why logical switching?

To answer this question I am not gonna include a long paragraph with complex networking terms. Instead I will ask a simple question that inn a physical networking world why VLAN?

A cloud service provider or any organization can have multiple tenants running in their data center. In a public cloud environment a tenant can simply be referred as a customer while in an organization tenant can be the different departments of that organization.

Now these tenants are running their business critical applications deployed inside the VM’s running on top of virtualization stack and are sharing same piece of infrastructure (compute, storage and network).

Now the question arises how to stop each tenant from sneaking into other tenant’s VM or applications. These tenants require isolation from each other for various reason including security, fault isolation, and avoiding overlapping IP addressing issues.

So to solve the above problem we use logical switching.

Prerequisites for creating a Logical Switch

Before you go and start creating logical switches in your environment, you have to make sure you meet following requirements:

  • vSphere distributed switches must be configured. You cannot deploy logical switches on standard switches.
  • NSX controllers must be deployed.
  • Your compute host clusters must be prepared and ready to go.
  • VXLAN must be configured.
  • A Transport Zone and a segment ID pool must be configured.

In our last post covered all the above requirements. So let’s jump into lab and start creating logical switches.

To start creating Logical Switch, Login to your vCenter server Web Client and navigate to Home | Networking & Security | Logical Switches

Click on the green “+” button to start creating a new Logical Switch


2. Provide a name and nice little description for your logical switch. Select the transport zone to which this logical switch will be mapped.

Also select the replication mode for the logical switch.


By default, the logical switch inherits the control plane replication mode set in the Transport Zone. You can change this by selecting one of the available modes.

IP discovery is enabled by default and allows Address Resolution Protocol (ARP) suppression between VMs connected to the same logical switch. There should not be any reason to disable this (optional).

Enable MAC learning setting if your virtual machines are having multiple MAC addresses or using virtual NICs that are trunking VLANs. This setting builds a VLAN/MAC pairing table on each vNIC.


3. When you create a logical switch, a new dPortGroup is created on the vDS. You can verify this by going into your network inventory and checking the presence of the newly created portgroup.


Migrating VM’s to Logical Switch

Once logical switch is created, we can migrate the workloads onto this switch. There are 2 methods of doing this.

A: Go to  Networking & Security | Logical Switches and clicking on the VM icon as shown in figure. This method will allow to migrate multiple VM’s at once from their current network (portgroup) to the logical switch.


The second method is rather long and needs going VM by VM basis and edit their settings and changed the portgroup association of the vNIC.

Select the VM’s from the list and click on the blue arrow button to add them to selection window and hit next.



On vNIC selection page, select the vNIC’s (in case your VM has more than one vNIC) for which you want to change portgroup association and hit next. In my case all my VM was equipped with one vNIC.


On ready to complete page review your settings and hit Finish to complete logical switch creation wizard.


You can verify the change of portgroup association by selecting the VM and go to Manage > VM hardware tab.


So now we have created our logical switch and migrated a few VM’s on that. In next post of this series we will learn about Distributed Logical Router.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)


Posted in NSX, Vmware | 3 Comments