Total Pageviews

My YouTube Channel

Wednesday, 20 June 2018

vRA Tenant URL Name Contains Dot Leads to REPO404 error in infrastructure tab

If you have created tenant in vRA and this tenant URL Name contains dot (.) as shown in below given screenshot

then you will be in the trouble as you will not be able to access options in Infrastructure tab. You will see this error message

The system cannot reach a required service at the expected address.
Contact your system administrator for assistance.
Reference error REPO404.
 Note:- Tenant URL Name Must Not Contain any Dot.

Sunday, 17 June 2018

DLR to DLR Static Routing Setup Using ESG

In this blog post i will share, how can you Setup Static Routing Between the VM's Connected on two different DLR's and as well as Routing for communication with Physical Network


Note: In this Scenario, ESG is connected with Network. This Network represents physical network.
Static Routes Created in DLR-1

 Static Routes Created in DLR-2

 Static Routes Created in ESG

Bingo!!!!! It's Configured. Now VM's can communicate with each other connected on different DLR's as well as physical network.

Tuesday, 12 June 2018

VTEP Table FAQ's

For any VNI, VTEP table is available on esxi hosts only when if any vm related to that VNI running on same esxi host.

Q1. When this VTEP Table gets created?
Ans. Whenever any VM related to this VNI running on same ESXi Host is powered on.

Q2. When this VTEP Table gets deleted?
Ans. Whenever all VM's related to this VNI running on same ESXi Host gets powered off or migrated

Monday, 11 June 2018

How to access Tech Support Mode (TSM) in NSX-V 6.4

NSX Manager has TSM to execute unix commands to handle operational and configuration issues. Let's discuss how to access TSM?

1. SSH to NSX Manager
2. Type "en"

3. Enter Password
4. Type "st eng" > Type "y" at Security Message > Enter Password

Password is predefined and it is always IAmOnThePhoneWithTechSupport

Now you can execute unix commands in NSX Manager

Reference KB 2149630

NSX Series Part 2 – NSX Control Plane

NSX Series Part 1 - NSX Management Plane

Impact of un-assignment of Enterprise Admin Role at NSX Manager from vCenter Admin

Scenario: What is impact of un-assignment of  Enterprise Admin Role at NSX Manager from vCenter Admin which is used for vCenter Registration in NSX Manager?
Whenever vCenter Server is required to be registered in NSX Manager at that time vCenter Admin Role User is needed for this  registration process and NSX Enterprise Admin Role automatically gets assigned to this user. As you can see in this below given screenshot

I have manually unassigned the Enterprise Role from the vCenter Admin User Account, as you can see in this below given screenshot

Immediately error message gets pop up "Could not establish the communication with NSX Manager. Please contact administrator"

And NSX manager become unknown in vSphere Web Client

To Fix this "I have re-connected my vCenter Server in NSX Manager Admin Console" by just entering the credentials again.
Bingo "It's back in NSX Manager" and Role gets assigned automatically again

Note: If this enterprise admin role is manually un-assigned from any other account to whom it was manually assigned then this will have no impact on NSX Manager.

Monday, 4 June 2018

End of Availability (EOA) for the Cisco Nexus 1000V

VMware is announcing the End of Availability (EOA) for the Cisco Nexus 1000V SKU and its associated support SKUs from VMware effective February 2, 2015.
This notification has NO IMPACT on existing use of the Nexus 1000V in a VMware vSphere 5.x or older environment. It also has NO IMPACT on support already purchased from VMware for the Nexus 1000V.
VMware recommends that the Nexus 1000V users move to the VMware vSphere Distributed Switch as it simplifies operations (e.g., upgrade) and provides advanced monitoring capabilities plus a broader feature set. VMware will also offer migration assistance to make this change. For additional details, please contact your VMware account team or support representative. Customers that use the Nexus 1000V already do so in conjunction with VMware vSphere Enterprise Plus Edition and have the correct licensing in place to make this change.

Customers who want to buy additional licenses and support for the Cisco Nexus 1000V after February 2, 2015 can buy those licenses directly from Cisco.

For More Info:-

Saturday, 2 June 2018

When DLR Control VM Deployment is Needed in VMware NSX?

Question: When DLR Control VM Deployment is Needed in VMware NSX?
Answer: It is needed when you want to configure dynamic routing, if you are looking for only static routing configuration for east-west traffic then DLR Control VM is not required

Deploy Edge Appliance is selected by default. An edge appliance (also called a logical router virtual
appliance) is required for dynamic routing and the logical router appliance's firewall, which applies to
logical router pings, SSH access, and dynamic routing traffic.
You can deselect the edge appliance option if you require only static routes, and do not want to
deploy an Edge appliance. You cannot add an Edge appliance to the logical router after the logical router has been created. If you have created it from vSphere Web Client GUI Mode, it remains in the Un-deployed State

Reference Document

Hypervisor-embedded first-hop routing for east-west traffic optimization in VMware NSX

Each ESXi host has its own copy of each configured DLR instance. Each DLR instance has its own unique set of tables containing the information needed to forward packets. This information is synchronized across all hosts where this DLR instance exists. Instances of an individual DLR across different hosts have exactly the same information.

Routing is always handled by a DLR instance on the same host where the source VM is running because the same DLR Instance is running on the another host too. This means that when source and destination VMs are on different hosts, the DLR instance that provides routing between them sees packets only in one direction, from source VM to destination. Return traffic is only seen by the corresponding instance of the same DLR on the destination VM’s host.

After the DLR has completed routing, delivery to the final destination is the responsibility of the DVS via L2 – VXLAN or VLAN if the source and destination VMs are on different hosts, or by the DVS locally if they are on the same host.

First-hop routing is handled on the host, and traffic is switched to the appropriate logical switch. If the destination is at another host, the Ethernet frame is placed in a VXLAN frame and forwarded.

Routing is always handled by a DLR instance on the same host where the source VM is running:
  1. VM1 sends a packet toward VM4, which is addressed to VM1’s gateway for VM4’s subnet (or default).
  2. The logical switch on ESXi01 delivers the packet to the DLR on that host, where the lookup is performed, and the egress LIF is determined (in this case for VXLAN 8284 LIF).
  3. The packet is sent out of that destination LIF, which returns the packet to the logical switch but on a different logical switch (8284).
  4. The logical switch performs L2 delivery of that packet to the destination host.   
Routing is performed at Hypervisor kernel level and in this way it avoids hair-pinning and east-west traffic gets optimized.

VMware vSAN 6.7 Technical Preview

NSX for vSphere 6.4 Update 3 Recommended Configuration Maximums

Looking for VMware Recommended Configuration Maximums for NSX for vSphere 6.4 Update 3. Refer this link to know Configuration Maximums:-

Tuesday, 29 May 2018

Some FAQs Related to NSX Logical Switch

What is Impact of Deletion of Logical Switch
VNI gets released by it.

What if New Logical Switch Created Post Old Logical Switch Deletion
New Logical Switch Will reuse this released VNI (that was released by old Logical Switch Deletion)

Monday, 28 May 2018

Nice System Scale Dashboard in NSX 6.4

Have you noticed System  Scale Dashboard in NSX 6.4? If not, check it today in your NSX Environment. It looks like as given below:

The System Scale dashboard collects information about the current system scale and displays the configuration maximums for the supported scale parameters. You can configure a warning threshold for the alerts when the system scale exceeds the configured threshold value. When the threshold is crossed, system event is generated which is used to set up notifications. This information is also logged and included in the support bundle.
If the current value exceeds a specified threshold percentage, a warning indicator is displayed to alert that the maximum supported scale is approaching. A red indicator shows that configuration maximum is reached. The listing is sorted in descending order of the current scale percent value which ensures that the warning indicators are always displayed at the top.
The data is collected every hour to verify if the threshold values are exceeding the limits, and creates an indicator when the thresholds are exceeded. The information is logged twice a day to the NSX Manager technical support logs.
System events are generated when the following conditions occur:

  • A warning event when a parameter crosses the threshold limit.
  • A critical event when a parameter crosses the supported system scale configuration.
  • An informational event when a parameter comes below the threshold value.

Retrieve Current Scale Threshold Limits for All Parameters
You can find out the current and the supported system scale configuration using the GET /api/2.0/capacity-parameters/report API. The API output displays scale summary, current scale value, supported system scale value, and the threshold value for each parameter.
Configure Scale Threshold for the System
You can set the scale threshold limit for your system.
To configure the threshold limit:
  1. Retrieve the global system threshold using the GET /api/2.0/capacity-parameters/thresholds API. For example, the API output shows global threshold as 80. It means the System Scale dashboard displays Usage Warning Threshold as 80%.
By default, the global threshold value is set at 80.
  1. To change the system threshold, use the PUT /api/2.0/capacity-parameters/thresholds API. For example, you change the global threshold value to 70. Now the System Scale dashboard displays Usage Warning Threshold as 70%.