Translate

Total Pageviews

My YouTube Channel

Saturday, 2 June 2018

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:-

https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.4/NSX%20for%20vSphere%20Recommended%20Configuration%20Maximums_64.pdf

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%.
Note:
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%.