Some questions and answers about VMware NSX #SDN

In the software defined datacenter (SDDC), software is the foundation that is powering the evolution of network and data center infrastructure. The SDDC increases flexibility, agility and scalability. In the vision of VMware, the SDDC consists of vSphere for virtualization of cpu and memory, VSAN and vVOLs for storage virtualization and VMware NSX for network virtualization. In this article I’ve included some common questions with answers about VMware NSX. So read on if you want to know more about VMware’s Software Defined Networking (#SDN) solution!

What is network virtualization?
Network virtualization is of course….about virtualizing the network. It’s about decoupling the network from the physical layer and implementing & configuring your network infrastructure in the virtual layer. VMware NSX offers virtual switches, routers, load balancers, firewalls and more. Of course you already know virtual switches, but NSX virtual switches are little different (more about that later). SDN increases flexibility, agility and scalability and is an important next step in your SDDC.

Do I need new hardware switches to implement #SDN?
In the case of VMware NSX, no! You can just use your existing physical network. However, some (limited) changes are required for NSX to function properly. First a minimum MTU of 1600 is required in the physical network. This is because NSX uses VXLAN as a overlay technique. VM network packets are encapsulated in the VXLAN packet. You probably also need to configure multicast in your physical network. Depending on the exact configuration you will need IGMP, IGMP snooping and sometimes PIM (Protocol Independent Multicast). Again, this is depending on your exact requirements and NSX deployment scenario. You can run NSX without the multicast part, but this will limit scalability.

Okay, and in regards to NSX: what components do I need to install?
With NSX life start with the NSX Manager. The NSX manager connects to your vCenter Server and deploys NSX controllers. The controllers (3 are required) are a prerequisite for NSX to function. After the controllers are deployed you can implement logical switches, distributed logical routers and the distributed firewall. You can also deploy NSX edges in case you need a permitter firewall, VPN or a load balancer. The NSX manager will also install the vSphere Installation Bundles (VIBs) on your ESXi hosts, adding some new kernel-level networking features: VXLAN, the distributed router and the distributed firewall. For VXLAN you will need to configure “VTEPs”.

VXLAN, VTEPS? What is VXLAN exactly doing in an NSX implementation?
Using VXLAN, you can create logical networks for your virtual machines across different layer 2 segments. Logical networks are interconnected using logical switches and distributed logical routers. A VXLAN starts and ends at a VTEP, a Virtual Tunnel EndPoints. VTEPs are configured at the ESXi level and represented by a VMkernel port. A VXLAN can span layer 2 and layer 3 segments, it’s not problem to route VXLAN traffic. In this way it’s possible to stretch a layer 2 logical network across a layer 3 boundary! Wow, that will certainly solve some challenges. VXLAN is creating an overlay network, this network is used to shape your virtual network.

So about these logical switches and distributed logical routers, why do I need them?
You already know the (distributed) virtual switch (DVS) if you’re using vSphere. The (NSX) logical switch and the distributed logical router (DLR) work a little different.

In a traditional environment you have different VLANs available, that are connected to each other through a (physical) router. Most of the times the core switch is the central router in your network. So if two virtual machines in different VLANs want to talk to each other, the network flow goes from VM A, through the DVS, through the physical network, physical router, physical network again (other VLAN), DVS and finally to VM B. In a world of logical switches and DLRs, each ESXi host has its own router instance. If VM A and VM B run on the same physical host, the network traffic will never exit the host because the routing takes place in the local instance of the DLR. If the VM’s are running on different hosts, the network traffic only travels between the host using VXLAN and will never pass the physical router, that’s pretty efficient right?

Wow that sounds pretty cool. Can I do more with these logical switches and distributed logical routers?
Well, the logical switches and routers also integrate with the NSX distributed firewall. Maybe you know vShield App; well the NSX distributed firewall is the evolution of vShield App and enables you to create per VM firewall rules, both on layer 2 and layer 3. The distributed firewall can be used to implement micro segmentation, which will certainly improve security in your SDDC! You can create firewall rules and link them to a particular VM or a group of VMs. A VM group is based on VM name, the guest OS, connected network, a particular cluster or datacenter. It’s also possible to activate firewall rules based on the user that logs on to a particular VM. In an earlier article titled “Identity-based firewalling using NSX” I’ve described this scenario.

Now let’s say I want to integrate my NSX environment with the physical world. What are my options?
With the distributed logical router (DLR) you can bridge or route network traffic from logical network to existing (physical) VLANs. With bridging you create a transparent connection so both virtual machines and physical servers/dekstops can communicatie with each other in the same layer 2 domain. You can also choose to connect a distributed port group on the underlying distributed virtual switch to a port on the distributed logical router. The DLR is connected to a VLAN Logical Interface (VLAN LIF) in that case.

Another option is to deploy an NSX edge and route traffic to one or more VLANs. An NSX Edge (f.k.a. vShield Edge) is a virtual machine that offers a broad set of services: routing, permitter firewall, network address translation (NAT), DHCP, virtual private network (VPN), load balancing and high availability. In this case the routing service allows you to route traffic from a logical network to a VLAN. Note that bridging is not option with NSX Edge.

Ok, and if I want to use this NSX Edge as my perimeter firewall?
You can use NSX Edge as a perimeter firewall, although it depends exact requirements if this is a valid use-case. The Edge firewall offers some good basic firewalling options, but lacks some of the advanced (IDS, IPS) features. Same counts for the VPN service which pretty powerful: you can use this service for RoBo scenario’s (routed or stretched layer 2) and also for remote access scenarios. But, if you’re looking for an enterprise level VPN solution, the NSX service might not be the best option…it just depends on what you’re looking for.

Talking about security, is NSX offering any other security features besides the firewall options?
Well, a very powerful part of NSX is the service composer. With the service composer you can create security policies and apply these policies to security groups. A security group is a group of virtual machines based on for example the port group, cluster, logical switch, datacenter or virtual machine name. A security policy on its turn can include guest introspection services such as AntiVirus (f.k.a. vShield Endpoint), data security, network introspection services and/or firewall rules. With the service composer an administrator can graphically see information about security groups and policies.

You can extend the NSX operation model to third-party services. After registering and deploying the 3rd party solution, you can consume the service in NSX. Let’s say you’re using a 3rd party AV solution and the solution detects a virus in a particular virtual machine. The virtual machine is now tagged as infected. Because of this tag the infected policy  becomes active for this virtual machine. The policy applies two rules: isolate the virtual machine using the distributed firewall and remove the virus. After the virus is removed and the virtual machine is safe again, the infected tag is also removed and the virtual machine can continue normal operation.

A last subject I want to touch is integration of NSX with vRealize Automation (vRA). Especially when you’re building multi-machine blueprints in vRA, NSX will help you to create network configurations for multi-tier applications. There’s also a vRealize Orchestrator (vRO) plugin available for NSX. With this plugin is possible to add NSX functionality to your vRA virtual machine deployment workflows. In this way you can for example add a newly deployed virtual machines to a security group which is linked to a ruleset in the distributed firewall. Possibilities are endless!

It’s time to wrap up now! I hope this was useful, if you have any questions please leave a comment below!