Category: NSX

Hi Friends , today set for VCIX-NV (advanced level of certification for VMware NSX) exam and really felling happy and exited to share that i have cleared it , now i am VCIX-NV certified.

MY EXAM EXPERIENCE

The VCIX-NV exam is the advanced level of certification for VMware NSX in the Network Virtualization track. If you plan on passing this exam, you’ll need good knowledge on NSX-v , vSphere  and also some advanced networking concepts. Personally, I found this to be the most difficult VMware exam I’ve taken so far. The topics covered were fair, nothing was asked that was not clearly defined in the blueprint. I found the tasks to be fairly difficult, compared to what I had experienced in other VCAP exams. So this is one exam that you’ll really need lots of hands on experience to pass I believe it will make passing the exam very difficult otherwise.

The version of NSX used for the exam was 6.0.4, you can expect some minor differences if you are using the latest versions, 6.2.x. The exam environment here is Mumbai was very slow , require lots of patience while clicking on links . My Firefox browser did crash a few times though and I did have to restart it.

Advise for the guys who are preparing for VCIX-NV , have lots of practice specially on VMware Hols and get your networking and vSphere fundas refreshed.

Best of Luck !!!!!

I hope first part of NSX Learn series should be as per your expectation and you must have now understanding , what components of NSX are part of which plane.

Now Here is the deployment architecture…

1. First you will deploy NSX Manager.
2. Register NSX Manager with vCenter.
3. Deploy NSX Controllers.
4. Prepare hosts , which internally will install vibs.
5. Then deploy Edge Gateways and Network Services.

in future posts , I will cover all above NSX component and their Deployment one by one , Lets first start with – NSX Manager.

NSX Manager: provides the centralized management plane for the NSX for vSphere architecture and has a one-to-one mapping with vCenter Server for workloads. NSX Manager performs the following functions:

• Provides a single point of configuration and the REST API entry points in a vSphere environment configured for NSX for vSphere.
• Responsible for deploying NSX Controller clusters, NSX Edge distributed routers, and NSX Edge services gateways (in the form of OVF format appliances), Guest Introspection Services, and so on.
• Responsible for preparing ESXi hosts for NSX for vSphere by installing VXLAN, distributed routing, and firewall kernel modules, as well as the User World Agent (UWA).
• Communicates with NSX Controller clusters through REST and hosts through the VMware vFabric^® RabbitMQ message bus. Note that this is an internal message bus specific to NSX for vSphere and does not require any additional services to be set up.
• Generates certificates for the NSX Controller nodes and ESXi hosts to secure control plane communications with mutual authentication.

VMware NSX 6.2 allows linking multiple vCenter VMware NSX deployments together, and manage them from a single NSX Manager that is designated as primary.In such a Cross-vCenter NSX environment, there is both an NSX Manager primary instance, and one or more secondary instances. The primary NSX Manager instance is linked to the primary vCenter Server instance and allows the creation and management of universal logical switches, universal logical (distributed) routers and universal firewall rules. Secondary NSX Manager instances are used to manage networking services that are local to itself. Up to seven secondary NSX Manager instances can be associated with the primary NSX Manager in a Cross-vCenter NSX environment. The configuration of network services on all NSX Manager instances can be performed from one central location.

Note – that there is still a one-to-one relationship between an NSX Manager and a vCenter Server.

To manage all NSX Manager instances from the primary NSX Manager in a Cross-vCenter VMware NSX deployment, the vCenter Server instances must be connected with Platform Services Controllers in Enhanced Linked Mode. See the ESXi and vCenter Server 6.0 documentation for details.

An NSX manager outage may affect only specific functionalities such as identity based firewall or flow monitoring collection.

NSX manager data (e.g., system configuration, events, audit log tables) can be backed up at any time by performing an on-demand backup from the NSX Manager GUI. It is also possible to schedule periodic backups to be performed (e.g., hourly, daily or weekly). Restoring a backup is only possible on a freshly deployed NSX manager appliance that can access one of the previously backed up instances.

The NSX manager requires IP connectivity to vCenter, controller, NSX Edge resources, and ESXi hosts. NSX manager typically resides in the same subnet (VLAN) as vCenter and communicates over the management network. This is not a strict requirement; NSX manager supports inter-subnet IP communication where design constraints require subnet separation from vCenter (e.g., security policy, multi-domain management).

In Next post i will be covering How to deploy NSX Manager

Happy Learning 🙂

As promised in my last post , here  comes the first part of NSX learning….

NSX for vSphere creates a network virtualization layer on top of which all virtual networks are created. This layer is an abstraction between the physical and virtual networks. The components required to create this network virtualization layer are:

• vCenter Server
• NSX Manager
• NSX Controller
• NSX Virtual Switch
• NSX for vSphere API

As per the above figure , these components are separated into three different planes to create communications boundaries and provide isolation of workload data from system control messages:

• Data plane
• Control plane
• Management plane

Data Plane –  The NSX data plane is implemented by the NSX vSwitch. The vSwitch in NSX for vSphere is based on the VDS with additional components added to enable rich services. The add-on NSX components include kernel modules distributed as VMware installation bundles (VIBs). These modules run within the hypervisor kernel, providing services including distributed routing, distributed firewall, and VXLAN to VLAN bridging. The NSX VDS abstracts the physical network, providing access-level switching in the hypervisor. This is central to network virtualization as it enables logical networks that are independent of physical constructs (e.g., VLANs).
The NSX vSwitch enables support for overlay networking with the use of the
VXLAN protocol and centralized network configuration.Overlay networking with NSX enables the following capabilities:

• Creation of a flexible logical layer 2 (L2) overlay over existing IP networks on
existing physical infrastructure.
• Agile provisioning of communication – both east–west and north–south –
while maintaining isolation between tenants.
• Application workloads and VMs that are agnostic of the overlay network, operating as if   they were connected to a physical network.

The data plane also consists of gateway devices that can provide communication
from the logical networking space to the physical network (e.g., VXLAN to
VLAN). This functionality can happen at either L2 (NSX bridging) or at L3 (NSX
routing).

In Simple English ” Where your Data Runs ” , if any Management Plane (NSX Manager)  or Control Plane (NSX controller ) is Down , still your data traffic is not affected .

Control Plane – The control plane is where network virtualization control messages are located. The NSX controller is a key part of the NSX control plane. In a vSphere environment with the vSphere Distributed Switch (VDS), the controller enables multicast free VXLAN and control plane programming of elements such as the Distributed Logical Routing (DLR).
The NSX controller is a part of the control plane; it is logically separated from all data plane traffic. To further enhance high availability and scalability, NSX controller nodes are deployed in a cluster of odd number instances.
In addition to controller, the control VM, provides the routing control plane that allows the local forwarding in ESXi and allows dynamic routing between ESXI and north-south routing provided by Edge VM. It is critical to understand that data plane traffic never traverses the control plane component.

Management Plane is where the network virtualization orchestration happens. In this layer, cloud management platforms such as VMware vRealize™ Automation can be used to request, consume, and destroy networking resources for virtual workloads.

The NSX manager is the management plane for the NSX eco-system. NSX manager provides configuration and orchestration of:
• Logical networking components – logical switching and routing
• Networking and Edge services
• Security services and distributed firewall
Edge services and security services can be provided by either built-in components of NSX Manager or by integrated 3rd party vendors. NSX manager allows seamless orchestration of both built-in and external services.

All security services, whether built-in or 3rd party, are deployed and configured by
the NSX management plane. The management plane provides a single window
for viewing services availability. It also facilitates policy based service chaining,
context sharing, and inter-service events handling. This simplifies the auditing of
the security posture, streamlining application of identity-based controls. (e.g., AD,
mobility profiles).

Happy Learning 🙂

Starting a series of posts for beginners , who wants to understand what is NSX and What it does , how it can help you and your organisations to enhance networking and security inside the datacenters.

Here is the list of Components which are required to prepare NSX Infrastructure:

• vSphere ESX Agent Manager (EAM)
• NSX Manager
• Controller cluster (if using unicast, hybrid mode or distributed logical routing)
• VTEP (ESXi hypervisor)
• User world agents (UWA)
•  vSphere distributed switch

I will explain each of the Components using series of Posts…..

When you use NSX API , there are many places inside the API we need to provide Object Ids. here is the procedure by which we can get vCenter Object IDs.

We can Use the vCenter MOB (Managed Object) viewer to find the object IDs. Browse to https://<vcenter>/mob and log in with an account that has administrative privileges within vSphere.

From there, click on Content > the rootFolder value link > the childEntity value link > any object you need an ID for. below is what mine looks like….

Happy Learning 🙂

Use Case: I have a single data center with two departments on different subnets accessing their respective VDI pools sitting behind a NSX Load Balancer. suppose HR users are having a URL – hr.vdi.com and sales users are having sales.vdi.com hitting to a single NSX LB configured with a VIP and connection manager pool.

Think a scenario where HR users comes to Sales block and try to access its VDI using hr.vdi.com from sales subnet , as per security guidelines this should not be allowed.

Now think another scenario where HR user comes to sales block and try to access its VDI using sales.vdi.com from sales subnet, as per the security guidelines this should not be allowed.

Another requirement is that no user from any other subnet should be able to access any of the VDI URLs and customer does not wants to use firewall for internal traffic. So in short we have to do a subnet to URL mapping on NSX Edge Load Balancer.

To achieve this, we will be using NSX edge LB “Application Rules”. Application Rules – we can write an application rule to directly manipulate and manage IP application traffic.

The procedure is as below….

1	Log in to the vSphere Web Client.
2	Click Networking & Security and then click NSX Edges.
3	Double-click an NSX Edge.
4	Click Manage and then click the Load Balancer tab.
5	In the left navigation panel, click Application Rules and click the Add icon.
6	Type the name and script for the rule. So we have created a NSX edge Load Balancer with Connection Broker VIP and a Pool of Connection servers. Now to restrict access , the procedure is as below: Go to NSX edge and click on Load Balancer and go to Virtual Servers and set Deafult Pool – NONE This will insure that if any user try to access connection broker will get an error because there is no Pool is defined. ( So no User will be able to access any of the services ,default action) Now we will write Application Rules to allow access. #ACL for subnet –> acl host_subnet src 10.52.16.0/24   – We are allowing to this subnet #ACL for URL ->  acl host_url hdr(Host) –i abc.xyz.com – We are allowing abc.xyz.com So if the user is from subnet 10.52.16.0/24 and using the URL abc.xyz.com than only it should be allowed to access Pool  , which are hosting Horizon view Connection Broker services. Rule will be like this – Use_backend CB_Pool if host_subnet host_url If you see after “if “ there are two acl names and there is nothing between them it means these will be treated as “AND” condition (Default HAProxy setting) , so it has to be verify both the acl and if ok then it will allow user access. I hope this will be  useful in planing security at Load Balancer label where Firewall is not feasible. Some other examples of Application Rules : # Block URL Check if the request starts with “/private” or “/finance” (case insensitive) acl block_url_list path_beg -i /private /finance # If the request is part of the list of forbidden url, reply “Forbidden” (HTTP response code 403) block if block_url_list # Redirect EVERYTHING to maintenance site ================================================== redirect location http://maintenance.xyz.com/maintenance.htm

A new Automation Guide has been published by VMware to help customers to Automate the Virtual Networking using NSX APIs.

VMware NSX provides a RESTful API service via NSX Manager that can be consumed in several ways. The NSX REST API can be consumed directly via a tool/library such as cURL or a REST Client like Postman, via multiple popular programming languages, and via orchestration cloud management tools. Popular programming languages such as Python, PowerShell, Perl, Go, and Java have REST client libraries which can easily be utilized to consume the NSX REST API. This means that elaborate workflows and complete systems/portals can be created to provide custom automation, management, and monitoring capabilities.

For More details and download the guide on API Guide

 

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 environment.

This we will achieve using a feature of VMware NSX that is Identity based firewalling.

Let’s first connect NSX to Active Directory. This step can be completed on the NSX Manager under manage -> domains. Add the domain you want to use to NSX:

Once AD sync is completed. now , we need to chose an AD group inside NSX “Grouping Object”.

1. Go to Grouping Objects
2. Click on + sign, a New Window will open, provide a proper Name.
3. Click on + sign
4. Choose “Entity” from drop down.
5. Click on the next box , it will open a list of AD groups.
6. Choose your AD group

Go to IP Sets and lets create an IP set , these will contain the list of IPs which we don’t want users to access.

1. Click on + Sign.
2. Enter descriptive Name.
3. Enter IP address to block.
4. Click OK.

Now Lets’ go to Firewall and create a Rule.

• Click in Firewall
• Click on + Sign.
• Give a descriptive Name.
• Chose Group , that we have created in Grouping Object , in our case it is “Demo”.
• Choose IP Set , that we have created in IP set , in our case “no_access_server”.
• Chose “Block” as we would need to block the traffic.

I hope this should be useful and helpful. Please Review and comment.

In my last post i have created a DLR using API , now as per requirement we have to add a default route on DLR.

Request Type : PUT

https://<NSX-MGR-IP>/api/4.0/edges/edge-35/routing/config/static

Request Body:
<staticRouting>
<staticRoutes>
<route>
<description>route2</description>
<vnic>2</vnic>
<network>0.0.0.0/0</network>
<nextHop>192.168.10.2</nextHop>
<mtu>1500</mtu>
<type>user</type>
</route>
</staticRoutes>
</staticRouting>

 

I am working on a NSX Design and Deployment engagement, this includes deployment of NSX on many sites and all sites spread across many cities of India and working on web client from the central location was very slow due to bandwidth issues. so we decided to deploy all the NSX components using NSX API.this will also help in keeping this code as a backup handy , so can be executed in case of restore required.

In my first post i have shown how to create Logical Switch , Now lets create a Distributed Logical Router….

Since we are using static Routing and there is no Firewall requirement  , so we have decided to not to deploy DLR edge VM at this point of time.

Request Type :POST   https://<NSX-MGR-IP>/api/4.0/edges

Request Body:

<edge>
<datacenterMoid>datacenter-21</datacenterMoid>
<name>ODC-A1</name>
<type>distributedRouter</type>
<appliances>
<deployAppliances>false</deployAppliances>
</appliances>
<mgmtInterface>
<connectedToId>dvportgroup-50</connectedToId>
</mgmtInterface>
<interfaces>
<interface>
<name>Towards_Transit</name>
<addressGroups>
<addressGroup>
<primaryAddress>192.168.10.1</primaryAddress>
<subnetMask>255.255.255.0</subnetMask>
<subnetPrefixLength>24</subnetPrefixLength>
</addressGroup>
</addressGroups>
<mtu>1500</mtu>
<type>uplink</type>
<isConnected>true</isConnected>
<isSharedNetwork>false</isSharedNetwork>
<connectedToId>virtualwire-16</connectedToId>
<connectedToName>vxw-dvs-35-virtualwire-16-sid-5011-LS_ODC_A_Transit</connectedToName>
</interface>
<interface>
<name>Towards_ODC_LS</name>
<addressGroups>
<addressGroup>
<primaryAddress>10.112.203.1</primaryAddress>
<subnetMask>255.255.255.0</subnetMask>
<subnetPrefixLength>24</subnetPrefixLength>
</addressGroup>
</addressGroups>
<mtu>1500</mtu>
<type>internal</type>
<isConnected>true</isConnected>
<connectedToId>virtualwire-15</connectedToId>
<connectedToName>vxw-dvs-35-virtualwire-15-sid-5010-LS_ODC_A</connectedToName>
</interface>
</interfaces>
</edge>

Distributed Logical Router successfully created.

Note – At the time of Writing with NSX 6.2.2,The example given in the API doc in the DLR section is actually for an ESG. the use of “vnic” for DLR does not work. we must use <interface> </interface>.