Category: NSX

NOTE –  

• All hosts in the cluster must be in the vSphere Distributed Switch that is being leveraged by NSX.
• VMware vSphere Update Manager™ must be disabled before preparing clusters for network virtualization.

To prepare a vSphere cluster for network virtualization:

• Log in to the vSphere Web Client and click Networking & Security.
• Select Installation under the Networking & Security section and select the Host Preparation tab.
• Select the cluster you want to prepare for NSX:

1. In the Installation Status column, click Install.
2. Click OK to continue.

The Installation Status column will display In Progress for each member of the cluster.

• After the Host Preparation installation has finished, the Installation Status and Firewall columns display a green checkmark, as well as the NSX version number.

If the Installation Status column contains a red warning icon displaying Not Ready, click Resolve. Clicking Resolve might result in a reboot of the host. If the installation is still not successful, click the warning icon to display all errors. Take the required action and click Resolve again.

Happy Learning 🙂

The NSX for vSphere control plane manages logical networks and the overlay transport, and it must be configured in one of the following modes:

• Multicast Mode ‒ If multicast replication mode is chosen for a given logical switch, VMware NSX relies on the Layer 2 and Layer 3 multicast capability of the physical network to ensure VXLAN encapsulated multi-destination traffic is sent to all the VXLAN tunnel end points (VTEPs). The control plane uses multicast IP addresses on the physical network in this mode.
• Unicast Mode ‒ In this mode, the control plane is managed by the NSX Controller instances and all replication is done locally on the host. No multicast IP addresses or physical network configurations are required. This mode is very well suited for smaller deployments.
• Hybrid Mode ‒ An optimized version of unicast mode, where local traffic replication for the subnet is offloaded to the physical network. This mode requires IGMP snooping on the first hop switch, and IGMP querier must be available. However, PIM is not required.

The NSX Controller provides East-West routing by programming traffic flows on the VMware NSX Virtual Switch. If you plan to use the unicast or hybrid control plane mode for the logical switch, you must add an NSX Controller. The NSX Controller optimizes virtual machine broadcast traffic (ARP only), and it stores the learning on the host.

As stated in my previous post – NSX for vSphere 6.2 only supports controller clusters with three nodes.

Following are the resource requirement for deploying controllers….

• 4 vCPUs
• 4 GB of memory (2 GB are reserved)
• 20 GB of disk space.

To deploy NSX Controller nodes

Log in to the vSphere Web Client and click Networking & Security.

Select Installation under the Networking & Security section and select the Management tab.

In the Add Controller dialog box:

1. Select the appropriate NSX Manager from the NSX Manager drop-down menu.
2. From the Datacenter drop-down menu, select the data center where you are adding the node.
3. From the Cluster/Resource Pool drop-down menu, select the appropriate cluster or resource pool where the NSX Controller is to be deployed.
4. From the Datastore drop-down menu, select the datastore in which the NSX Controller will be deployed.
5. (Optional) From the Host drop-down menu, select the host.
6. (Optional) From the Folder drop-down menu, select the folder.
7. In the Connected To selection box, click Select to choose the logical switch, port group, or distributed port group to which the node is to be connected.
8. In the IP Pool selection box, click Select to choose the IP pool from which IP addresses are to be assigned to the node.
9. Type and re-type a password for the NSX Controller.
10. Click OK.

Deploy two additional NSX Controller nodes to provide a greater level of resiliency.

Now we have deployed all the required controllers and ready for production , next thing is to prepare our vSphere clusters.

---

---

---

 

I am delightfully honoured to share with you that I have been designated as VMware vExpert 2016. I am truly happy and would like to thank all bloggers, contributors, readers and customers for letting me achieve that 🙂

here is the list…

http://blogs.vmware.com/vmtn/2016/08/vexpert-2016-second-half-announcement.html

 

When accessing vRealize Automation, the FQDN of the vRA appliance in the browser will take you to a page that looks like this

though this can be useful page when first getting started but it is not exactly what customer want end users to see when trying to access the vRA portal. It can be particularly troublesome if they use the link to access the vRA portal and they should be using a specific tenant URL.

Lets add a redirect that will directly send them to the login page. we will archive this using  NSX edge LB Application rules.

Open the NSX edge which is working as LB and go to Application Rules and Click on green “+”  to add a rule like this:

Save this and add to your vRA VIP.

This will help your end users will go straight to the login page when pointing their browser to the FQDN of the vRA appliance.

This particular use-case is to implement network security to allow or block network access to certain applications/servers in the datacenter, depending on the logged-on user in a horizon view envir…

Source: VMware NSX Firewalling using AD Groups

Friends, In my Previous NSX series posts , we have successfully deployed NSX Manager , now to move on further , Next thing is deploy NSX controllers , in this post i will explain you what is the role of NSX controllers and next post we will deploy Controller cluster.

The NSX Controller cluster is the control plane component that is responsible for managing the switching and routing modules in the hyper-visors.The controller cluster consists of controller nodes that manage specific logical switches. The use of controller cluster in managing VXLAN based logical switches eliminates the need for multicast configuration at the physical layer for VXLAN overlay.

NSX Controller nodes perform the following functions:

• Provides control plane to distribute VXLAN and logical routing information to ESXi hosts.
• Nodes are clustered for scale-out and high availability.
• Network information is sliced across nodes in a cluster for redundancy purposes.
• Eliminates the need for multicast support from the physical network infrastructure.
• Provides ARP-suppression of broadcast traffic in VXLAN networks.

NSX Controller nodes are deployed in a cluster with a minimum of three members to provide high availability and scale.The high availability of NSX Controller reduces downtime in the case of one physical host failure.

Below information has been taken from NSX Reference Design.

For resiliency and performance, production deployments of controller VM should be in three distinct hosts. The NSX controller cluster represents a scale-out distributed system, where each controller node is assigned a set of roles that define the type of tasks the node can implement.In order to increase the scalability characteristics of the NSX architecture, a slicing mechanism is utilized to ensure that all the controller nodes can be active at any given time.

Above Figure illustrates the distribution of roles and responsibilities between all three cluster nodes. This demonstrates how distinct controller nodes act as master for given entities such as logical switching, logical routing and other services. Each node in the controller cluster is identified by a unique IP address. When an ESXi host establishes a control-plane connection with one member of the cluster, a full list of IP addresses for the other members is passed down to the host. This enables establishment of communication channels with all members of the controller cluster, allowing the ESXi host to know at any given time which specific node is responsible for any given logical network.

In the case of failure of a controller node, the slices owned by that node are reassigned to the remaining members of the cluster. In order for this mechanism to be resilient and deterministic, one of the controller nodes is elected as a master for each role. The master is responsible for allocating slices to individual controller nodes, determining when a node has failed, and reallocating the slices to the other nodes. The master also informs the ESXi hosts about the failure of the cluster node so that they can update their internal node ownership mapping.

The election of the master for each role requires a majority vote of all active and inactive nodes in the cluster. This is the primary reason why a controller cluster must always be deployed with an odd number of nodes.

                                

Above figure highlights the different majority number scenarios depending on the number of available controller nodes. In a distributed environment, node majority is required. During the failure of one the node, with only two nodes working in parallel, the majority number is maintained. If one of those two nodes were to fail or inter-node communication is lost (i.e., dual-active scenario), neither would continue to function properly. For this reason, NSX supports controller clusters with a minimum configuration of three nodes. In the case of second node failure the cluster will have only one node. In this condition controller reverts to read only mode. In this mode, existing configuration should continue to work however any new modification to the configuration is not allowed.

NSX controller nodes are deployed as virtual appliances from the NSX manager UI. Each appliance communicates via a distinct IP address. While often located in the same subnet as the NSX manager, this is not a hard requirement. Each appliance must strictly adhere to the specifications in below table.

	Per Controller VM Configurations
No. of Controller VMs	vCPU	Reservation	Memory	OS Disk
3	4	2048 MHz	4GB	20 GB

It is recommended to spread the deployment of cluster nodes across separate ESXi hosts. This ensure that the failure of a single host does not cause the loss of a majority number in the cluster. you can leverage the native vSphere anti-affinity rules to avoid deploying more than one controller node on the same ESXi server.

In the Next post we will learn how to deploy NSX controllers….:)

VMware vRealize Network Insight 3.0.0 (Arkin) is now generally available. vRNI delivers intelligent operations for software-defined networking and security, with converged visibility across virtual and physical networks, planning and recommendations for micro-segmentation and operations management for NSX.vRealize Network Insight provides converged operations plane between virtual and physical network.

Benefits of vRNI

–Increase speed and accuracy of micro-segmentation deployment

–Rapidly operationalize NSX environments with out of the box best practice

–Modern, simple, Google-like search

–Easy access to NSX activities and security events

–Integrates with all major 3rd party network vendors with out of the box discovery of             virtual & physical topology

–Quickly onboard existing teams to operate NSX easily

Some of the Features-

East-West Traffic Analysis (Deep insight within your VMware Infrastructure)

• East-West Traffic Flow Analysis
• Breakdown of Data Center Traffic by East-West, VM-to-VM, VM-to-Physical, Switched, Routed, etc.
• Get Detailed Flow stats behind each number

Micro-Segmentation – Security Policy Automation

• Discover vCenter and NSX constructs (folders, clusters, vlans, security tags)
• Automated Security Groupings Based on vCenter and NSX Constructs, Workload Characteristics, Ports, Common Services
• Recommended Security Policies / Firewall Rules (Zero-Trust Model)
• See Network Traffic Per Host, Per VM
• Export as CSV

If you see above figure , “Prod-Web” vm’s having connectivity with “Prod-Midtier” , as well as Internet ,shared Physical servers and DC Physical Servers.

Have you ever seen like this , so much of visibility in your virtual infrastructure.

Data Paths Across Overlay (vxlan) And Underlay (Physical/vLAN)

• VM to VM, VM to Physical, VM to Internet
• Hop-by-Hop Path across Overlay (LDRs, Edge Gateways) and Underlay (Physical VDCs & VRFs)

 

Two appliances have to be deployed:

• vRealize Network Insight Platform
• vRealize Network Insight Proxy

Resource requirements:

• vRealize Network Insight Platform OVA:

1. 750 GB – HDD, Thin provisioned
2. 32 GB RAM – Reservation – 16GB
3.  8 cores – Reservation 4096 Mhz

• vRealize Network Insight Proxy OVA:

1. 4 cores – Reservation 2048 Mhz
2. 10 GB RAM – Reservation – 5GB
3. 150 GB – HDD, Thin provisioned

• VMware vCenter Server (version 5.5 and 6.0).
• To configure and use IPFIX
• vCenter Server Credentials with privileges:
  • Distributed Switch: Modify
  • dvPort group: Modify
• VMware ESXi:
  • 5.5 Update 2 (Build 2068190) and above
  • 6.0 Update 1b (Build 3380124) and above
• Recommended that VMware Tools is installed on all the Virtual Machines in the data center. This helps in identifying the VM to VM traffic.

Software requirements

•  Google Chrome browser

Installation Workflow

Download From Here

Friends , this get a bit delayed as i was busy with other commitments , here comes the next part…

You must log in to the NSX Manager virtual appliance to register vCenter Server and review the settings specified during installation.

Prerequisites to Configure –

• The NSX management service must be running.
• You must have a vCenter Server user account with administrative access to synchronize NSX Manager with the vCenter Server.
• If your vCenter password has non-ASCII characters, you must change it before synchronizing the NSX Manager with the vCenter Server.
• FTPS (or FTP) server available.
• To use the VMware vCenter Single Sign-On™ service on NSX Manager, you must have vCenter Server 5.5 or later and the vCenter Single Sign-On service must be installed on vCenter Server. Note that this is for embedded single sign-on (SSO). Your deployment might use an external centralized SSO server based on Active Directory.

1 – Connect to the NSX Manager using DNS/IP address of NSX manager appliance.

The default user name is admin. The password was set during the deployment of the             NSX Manager OVA.

2 – In the NSX Manager main screen, select View Summary and verify that the following              services are running:

• VMware vFabric^® Postgres
• Pivotal RabbitMQ
• NSX Management Service

3 – From the NSX Manager main screen, select Manage Appliance Settings > Settings >                General. In the Time Settings section, verify that the NTP server entries are correct.

4 – In the Syslog Server section, click Edit, enter the appropriate Syslog server settings and        click OK.

5 – In Components > NSX Management Service, in the vCenter Server section, click Edit to connect NSX Manager to vCenter Server.

In the vCenter Server dialog box:

1. Enter the vCenter Server FQDN in the vCenter Server text box.
2. Enter the vCenter user name in the vCenter User Name text box.
3. Enter the password for the vCenter user in the Password text box.
4. Click OK.

6 – In the Trust Certificate dialog box:

1. Click Yes to proceed with the SSL certificate.
2. After a short period, verify that the vCenter Server status displays Connected.

7 – In Components > NSX Management Service, in the Lookup Service section, click Edit to        connect to the SSO Server.

In the Lookup Service dialog box, enter the appropriate values:

1. Enter the IP address of the SSO server in the Lookup Service IP text box.
2. Enter 7444 in the Lookup Service Port text box
   1. NOTE – use port 443 for vSphere 6 VMware Platform Services Controller™.
3. Enter the user name for the SSO Administrator in the SSO Administrator User Name text box.
4. Enter the password for the SSO Administrator in the Password text box.
5. Click OK.

8 – In the Trust Certificate? dialog box:

1. Click Yes to proceed with the SSL Certificate.

After a short period, verify that the Lookup Service status displays Connected.

Now with all above steps , NSX Manager is integrated  with vCenter. now lets move ahead with deployment of Controllers , Happy Learning 🙂

If VXLAN Connectivity isn’t operational, It means if a VM on a VXLAN cannot ping another one on the same logical switch the most common reason is a misconfiguration on the transport network.

As all of you are aware VXLAN has its own vmkernel networking stack , so ping connectivity testing between two different vmknics on the transport VLAN must be done from ESXi console using the syntax below:

ping ++netstack=vxlan -d -s 1572 -I vmk3  <vmknic IP>

or

vmkping ++netstack=vxlan <vmknic IP> -d -s <packet size>

or

esxcli network diag ping --netstack=vxlan --host <vmknic IP> --df --size=<packetsize>

or

If the ping fails, launch another one without the don’t fragment/size argument set

ping ++netstack=vxlan -I vmk3 <vmknic IP>

If this one succeed, it means your MTU isn’t correctly set to at least 1600 on your transport network.

++netstack=vxlan -> instruct the ESXi host to use the VXLAN TCP/IP stack.
-d -> set Don’t Fragment bit on IPv4 packet
-s 1572 -> set packet size to 1572 to check if MTU is correctly setup up to 1600
-I – > VXLAN vmkernel interface name
-<vmknic IP> ->  Destination ESXi host vmkernel IP Address.

If all the ping fails it’s a VLAN ID or Uplink misconfiguration. Before going any further you have to make sure that these pings works , than only we can successfully configure NSX virtual Networking.

Happy Learning 🙂

 

Here comes the NSX Manager deployment Pre-requisite and Procedure…

Prerequisites…

• You must be assigned the Enterprise Administrator or NSX for vSphere administrator role.
• Verify that a datastore is configured and accessible on the target ESXi host. Shared storage is recommended.
• The resource requirements are:
  • 4 vCPUs
  • 16 GB of memory (16 GB are reserved)
  • 60 GB of disk space
• As a general guideline, if the NSX managed environment contains more than 256 hypervisors, VMware recommends to increase NSX Manager resources to 8 vCPU and 24GB of RAM.
• Decide whether the NSX Manager will have IPv4 addressing only, IPv6 addressing only, or dual-stack network configuration. The host name of the NSX Manager will be used by other entities. Therefore, the NSX Manager host name must be mapped to the right IP address in the DNS servers used in the network.
• Make sure that you know the IP address and gateway, DNS server IP addresses, domain search list, and the NTP server IP address that the NSX Manager will use.
• The NSX Manager management interface, vCenter Server, and ESXi hosts must be reachable by all future VMware NSX Edge™ and NSX Guest Introspection instances.

Deploy NSX Manager

1. Download the NSX for vSphere 6.2 OVA file from the VMware Web site.
2. To deploy the OVA file:
a. Connect to the VMware vSphere Web Client.
b. Select the vCenter Server on which to deploy the appliance.
c. Select Actions and select Deploy OVF template.

3. In the Select source dialog box:
a. Choose Local File, click Browse and select the OVA file.
b. Click Next.

4. In the Review details dialog box, select the Accept extra configuration options check box and click Next.

5. In the Accept EULAs dialog, click Accept and click Next.

6. In the Select name and folder dialog box:
a. Enter the name for the NSX Manager appliance.
b. Select a folder or data center on which to deploy the virtual machine and click Next.
c. Select the appropriate host and cluster for deployment.

7. In the Select storage dialog box:
a. Select the destination datastore for the appliance and click Next.
b. (Optional) Select a VM Storage Policy if necessary.

8. In the Setup network dialog box, select the port group for the appliance and click Next.

9. In the Customer template dialog box:
a. Enter the CLI administrator user and privilege passwords.
b. Enter the Network properties.
c. Enter the DNS settings.
d. Enter the Services Configuration.
e. Click Next.

10. In the Ready to complete dialog box:
a. Review the configuration.
b. Select the Power on after deployment check box and click Finish.

In the Next part i will be covering NSX Manager Configuration….

Happy Learning 🙂