Historically and like most malware, ransomware has been targeting Windows operating systems primarily. However, cases of Linux and MacOS being infected are being seen as well. Attackers are being more proficient and keep evolving in their attacks by targeting critical infrastructure components leading to ransomware attacks on VMware ESXi. In this article, you’ll learn how Ransomware targets VMware infrastructure and what you can do to protect yourself.

What is Ransomware?

Ransomware are malicious programs that work by taking the user’s data hostage in exchange for a hefty ransom.

There are essentially 2 types of Ransomware (arguably 3):

• • Crypto Ransomware: Encrypts files so that the user cannot access them. This is the one we are dealing with in this blog.

• • Locker Ransomware: Lock the user out of his computer by encrypting system files.

• • Scareware: Arguably a third type of ransomware that is actually a fake as it only locks the screen by displaying the ransom page. Scanning the system with an Antivirus LiveCD will get rid of it quite easily.

A user computer on the corporate network is usually infected through infected USB drives or social engineering techniques such as phishing emails and shady websites. Another occurrence includes attacking a remote access server publicly exposed through brute-force attacks.

The malware then uses a public key to encrypt the victim’s data, which can span to mapped network drives as well. After which the victim is asked to make a payment to the attacker using bitcoin or some other cryptocurrency in exchange for the private key to unlock the data, hence the term Ransomware. If the victim doesn’t pay in time, the data will be lost forever.

As you can imagine, authorities advise against paying the ransom as there is no guaranty the bad actor will deliver on his end of the deal so you may end up paying the big bucks and not recover your data at all.

Can Ransomware affect VMware?

While infecting a Windows computer may yield a reward if the attacker gets lucky, chances are the OS will simply be reinstalled, no ransom is paid and the company will start tightening security measures. Game over for the bad guys.

Rather than burning bridges by locking a user’s workstation, they now try to make a lateral move from the infected workstation and target critical infrastructure components such as VMware ESXi. That way they hit a whole group of servers at once.

“VMware ESXi ransomware impact all the VMs running on the hypervisor”

From the standpoint of an attacker, infesting a vSphere host, or any hypervisor for that matter, is an “N birds, 1 stone” type of gig. Instead of impacting one workstation or one server, all the virtual machines running on the host become unavailable. Such an attack will wreak havoc in any enterprise environment!

How does a Ransomware Attack Work?

In the case of targeted attacks, the bad actor works to gain remote access to a box in the local network (LAN), usually a user computer, and then make a lateral move to access the management subnet and hit critical infrastructure components such as VMware ESXi.

There are several ways a ransomware attack on VMware ESXi can happen but reports have described the following process.

“The ransomware attack on VMware ESXi described in this blog is broken down into 5 stages”

Stage 1: Access local network

Gaining access to the LAN usually goes either of 2 ways:

• • A malware is downloaded in a phishing email or from a website. It can also come from an infected USB stick.

• • The attacker performs a Brute force attack against a remote access server exposed to the internet. This seems more unusual as it involves more resources and knowledge of the target. Brute force attacks are also often caught by DDoS protection mechanisms.

“Ransomware spread through malicious email attachments, websites, USB sticks”

Stage 2: Escalate privileges

Once the attacker has remote access to a machine on the local network, be it a workstation or a remote desktop server, he will try to escalate privileges to open doors for himself.

Several reports mentioned attackers leveraging CVE-2020-1472 which is a vulnerability in how the Netlogon secure channel connections are done. The attacker would use the Netlogon Remote Protocol (MS-NRPC) to connect to a domain controller and gain domain administrator access.

Stage 3: Access management network

Once the bad actors have domain administrator privileges, they can already deal a large amount of damage to the company. In the case of a ransomware attack on VMware ESXi, they will use it to gain access to machines on the management network, in which the vCenter servers and vSphere ESXi servers live.

Note that they might even skip this step if the company made the mistake to give user workstations access to the management network.

Stage 4: VMware ESXi vulnerabilities

When the attackers are in the management network, you can only hope that all the components in your infrastructure have the latest security patches installed and strong password policies. At this point, they are the last line of defense, unless a zero-day vulnerability is being leveraged in which case there isn’t much you can do about it.

Several remote code execution vulnerabilities have been exploited over the last year or so against VMware ESXi servers and vCenter servers.

The two critical vulnerabilities that give attackers access to vSphere hosts relate to the Service Location Protocol (SLP) used by vSphere to discover devices on the same network. By sending malicious SLP commands, the attacker can execute remote code on the host.

• • CVE-2019-5544: Heap overwrite issue in the OpenSLP protocol in VMware ESXi.

• • CVE-2020-3992: Use-after-free issue in the OpenSLP protocol in VMware ESXi.

• • CVE-2021-21985: Although no attack mentions it, we can assume the vCenter Plug-in vulnerability discovered in early 2021 can be a vector of attack as well. Accessing vSphere hosts is fairly easy once the vCenter is compromised.

They can then enable SSH to obtain interactive access and sometimes even change the root password or SSH keys of the hosts.

Note that the attacker may not even need to go through all that trouble if he manages to somehow recover valid vCenter of vSphere credentials. For instance, if they are stored in the web browser or retrieved from the memory of the infected workstation.

Stage 5: Encrypt datastore and request ransom

Now that the attacker has access to the VMware ESXi server, he will go through the following steps to lock your environment for good.

• • Uninstall Fault Domain Manager or fdm (HA agent) used to reboot VMs in case of failure.

• • Shut down all the virtual machines.

• • Encrypt all virtual machine files using an ELF executable, derived from an encrypting script that targets Linux machines. This file is usually named svc-new and stored in /tmp.

• • Write a ransom file to the datastore for the administrator to find.

Note that there are variations of the ransomware attack on VMware ESXi, which themselves are ever-evolving. Meaning the steps described above represent one way things can happen but your mileage may very well vary.

How to protect yourself from ransomware attacks on VMware ESXi

If you look online for testimonies, you will find that the breach never comes from a hooded IT mastermind in an ill-lit room that goes through your firewalls by frantically typing on his keyboard like in the movies.

The reality is nowhere near as exciting. 9 times out of 10, it will be an infected attachment in a phishing email or a file downloaded on a shady website. This is most often the doing of a distracted user that didn’t check the link and executed the payload without thinking twice.

Ensure at least the following general guidelines are being enforced in your environment to establish a first solid line of defense:

VMware environment-related recommendations

• • If you need to open internet access on your vCenter, enforce strong edge firewall rules and proxy access to specific domains. Do not expose vCenter on the internet!!! (Yes, it’s been done).

• • Enforce the vSphere Security Configuration Guide (previously Hardening guide).

• • Avoid installing third party vCenter plugins.

• • Enable Secure Boot and vSphere Trust Authority on vSphere hosts.

• • Don’t join your vSphere hosts to Active Directory.

• • Set VMware ESXi shell and SSH to manual start and stop.

• • Don’t use the same password on all the hosts and out-of-band cards.

Some recommend not to add Active Directory as an Identity Source in vCenter Server. While this certainly removes a vector of attack, configuring Multi-Factor Authentication also mitigates this risk.

Industry standards

• • Educate your users and administrators through educational campaigns.

• • Ensure the latest security patches are installed as soon as possible on all infrastructure components as well as backups servers, workstations…

• • Segregate the management subnets from other subnets.

• • Connect to the management network through a jump server. It is critical that the jump server must:

• • • Be secured and up to date

• • • Accessible only through Multifactor authentication (MFA)

• • • Must only allow a specific IP range.

• • Restrict network access to critical resources only to trained administrators.

• • Active Directory:

• • • Ensure AD is secured and users/admins are educated on phishing attacks.

• • • Apply least privilege policy.

• • • Use dedicated and named accounts.

• • • Enforce strong password policies.

• • • Segregate Admin and Domain admin accounts on AD.

• • • Log out users on inactivity on Remote Desktop Servers.

• • Don’t save your infrastructure password in the browser.

• • Use Multi-Factor Authentication (MFA) where possible, at least on admin accounts.

• • Forward infrastructure logs to a Syslog server for trail auditing.

• • Ensure all the workstations and servers have a solid antivirus with regularly updated definitions.

Where do backups fit in all this?

While there are decryption tools out there, they will not always work. In fact, they almost never will.

Restoring from backup is essentially the only way known to date that you can use to recover from a ransomware attack on VMware ESXi. You can use Altaro VM Backup to ensure your environment is protected.

Because attackers know this well, they will try to take down the backup infrastructure and erase all the files so your only option left is to pay the ransom. Which, as mentioned previously, is no guaranty that you get your files back.

Because of it, it is paramount to ensure your backup infrastructure is protected and secure by following best practices:

• • Avoid Active Directory Domain integration or use multi-factor authentication (MFA).

• • Do not use the same credentials for access to the VMware and Backup infrastructures.

• • Follow the 3-2-1 backup strategy at the very least.

• • Test your backups regularly.

• • Keep the backup infrastructure on a dedicated network. Also called Network Air-Gap.

• • Sufficient backup retention to avoid backing up infected data.

• • Maintain offsite read-only backups (air gap).

You can also check our dedicated blog for more best practice recommendations: Ransomware: Best Practices for Protecting Backups.

NIST controls for data integrity (National Institute of Standards and Technology)

VMware documents solutions for combatting ransomware by incorporating the National Institute of Standards and Technology (NIST) controls specific to data integrity. You can find VMware’s recommendations and implementation of the NIST in this dedicated document:

“National Institute of Standards and Technology logo”

The NIST framework is broken down into 5 functions:

• • Identify and Protect: SP 1800-25

• • Detect and Respond: SP 1800-26

• • Recover: SP 1800-11

In the VMware document linked above, you will find Detect, Protect and Respond recommendations that apply to various environments such as private cloud, hybrid cloud or end-user endpoints.

So How Worried Should I be?

Ransomware have always been one of the scary malware as they can deal a great amount of damage to a company, up to the point of causing some of them to go into bankruptcy. However, let us not get overwhelmed by these thoughts as you are not powerless against them. It is always best to act than to react.

In fact, there is no reason for your organization to get hit by a ransomware as long as you follow all the security best practices and you don’t cut corners. It might be tempting at some point to add an ALLOW ALL/ALL firewall rule to test something, give a user or service account full admin rights, patch a server into an extra VLAN or whatever action you know for a fact would increase your security officer’s blood pressure. In such a case, even if there is a 99.9% chance things are fine, think of the consequences it could have on the company as a whole should you hit that 0.1% lurking in the back.

If you are reading this and you have any doubts regarding the security of your infrastructure, run a full audit of what is currently in place and draw a plan to bring it into compliance with the current industry best practices as soon as possible. In any case, patch your systems as soon as possible, especially if you are behind!

The post How to Protect VMware ESXi Hosts from Ransomware Attacks appeared first on Altaro DOJO | VMware.

VMware Update Manager Download Service is a product that acts as a patch repository for the hosts in your infrastructure. It is comparable to WSUS in the sense that it downloads the patches from the internet, which can, in turn, be leveraged by VMware Lifecycle Manager on the compatible vCenter systems in your environment. 

It is particularly useful in highly secure environments that, quite rightly, block internet access for the infrastructure components. UMDS can be configured with a network interface with proxy access to the internet to download the patches and a network interface that is accessible by the vCenter servers on port 80 and/or 443. 

Just like for WSUS, another benefit of using UMDS is that you only download the patches from the internet once instead of doing it on each vCenter. Which will be interesting in large environments or if you have bandwidth limitations. 

It is important to note that UMDS supports patch recalls like the one that happened with vSphere 7.0 Update 2. Meaning if your system downloaded and exported a patch that is later recalled, it will be removed from UMDS the next time it runs. 

Prerequisites 

Considerations 

Considerations should be given prior to getting started with Update Manager Download Service. 

• vCenter Server instances is only supported with UMDS installed in the same version, 7.0 Update 2 in our case. Note that it will probably work across minor versions though. 
• The UMDS server must have HTTPS access (port 443) to at least VMware’s public repositories. You can obviously allow *.vmware.com/* to simplify your proxy rules and allow for more flexibility. You can also add additional repos such as vendors like HP, Dell… 

• All vCenter servers that will use UMDS must have access to it on port 80 (http) or 443 (https) according to which one you configure. 
• UMDS updates are not supported. If an instance of UMDS is already installed you need to uninstall it first along with its PostgreSQL database. However, the patch store can be retained. 
• You need a Web server to distribute the patches to the vCenter instances. The easiest is to install it on the UMDS server itself if you can. If you do not want to use a web server you can still export the patches to a location of your choice and import them to vCenter but then do you actually need UMDS? 

Also, if you want to use the FQDN of the server instead of the IP address to connect vLCM, make sure that there is a DNS record in your environment. 

Space requirements

While you don’t need particularly large disks to run UMDS, you will still need some amount of storage to store all the patches that you download. How much will depend on the number of vSphere versions you want to cover. 

VMware provided a sizing estimator tool up until vSphere 6.7 Update 3 which I couldn’t find an updated version for in version 7.0. However, it will still give you a ballpark idea of how much space to allocate to your Linux server even though vSphere 7.0 is not on the list. 

As an example, the server in my lab downloaded 3.6GB of data for vSphere 7.0.x. 

Compatibility

Update Manager Download Service used to be available both on Windows and Linux platforms up until version 6.7 Update 3. Starting UMDS 7.0, only 64-bits linux OSes are supported. You will need to make sure that you pick a Linux distribution and version from the list of supported Operating Systems by VMware.

• Ubuntu 14.0.4
• Ubuntu 18.04
• Ubuntu 18.04 LTS
• Ubuntu 20.04 LTS
• Red Hat Enterprise Linux 7.4
• Red Hat Enterprise Linux 7.5
• Red Hat Enterprise Linux 7.7
• Red Hat Enterprise Linux 8.1 (libnsl package version 2.28 or later required)

In this blog we are running Ubuntu 20.04 LTS so your mileage may vary when it comes to Linux commands.

Note that UMDS 7.0 works with both images and baselines. Meaning UMDS will download updates as well as components.

How to install UMDS 7.0

The bundle for VMware’s Update Manager Download Service is embedded in the vCenter appliance ISO. Once again, make sure to retrieve the UMDS bundle from the vCenter ISO of the same version as the vCenter that will connect to it.

• The first step is an obvious one but we’ll mention it. Download the vCenter ISO in the right version if you don’t already have it. Then extract the archive (VMware-UMDS-7.0.2.00000-8786438.tar.gz in my case) which is located in the umds folder to the location of your choice.
• Open WinSCP and connect to the UMDS server. Then copy the UMDS archive to /tmp.

Note that if SSH is not available on this server, you can connect the vCenter ISO to the VM and extract it from there.

• Create a umds folder under /tmp.

mkdir /tmp/umds

• Extract the archive to /tmp/umds.

tar -zxvf /tmp/VMware-UMDS-7.0.2.00000-8786438.tar.gz -C /tmp/umds

• The installation of UMDS is done with a perl script that you launch with elevated privileges.

sudo /tmp/umds/vmware-umds-distrib/vmware-install.pl

• You will first have to accept the EULA and then the script will ask you several questions.
• Press Enter if you are OK with the default /usr/local/vmware-umds install location and to create the folder.

• You can choose to configure a proxy if your environment requires it. Note that you can change it later. I leave it to the default as I don’t have any.

• The last step is to accept the default patch store location if it works for you or type a different one. You can also change this setting later on. This is where the patches are downloaded to. If everything goes to plan, UMDS is now installed on your system, easy.

Configuration of UMDS 7.0

All interactions with UMDS are done through /usr/local/vmware-umds/bin/vmware-umds. In the next few steps, I elevated my session to avoid permission warnings. You can find more about how to use the command with the “–help” parameter.

• We will first disable all the vSphere versions so we can enable only the ones that will be relevant to our environment. There is no point in downloading patches for vSphere 6.5 if it is not in use by your company.

/usr/local/vmware-umds/bin/vmware-umds -N -S

• You can now enable only the vSphere versions you want to download with the “-e” parameter and the “-S” switch which is required when making a change. In my case I only added vSphere 7.0. You can add more by running the command for each one of them.

/usr/local/vmware-umds/bin/vmware-umds -S -e embeddedEsx-7.0-INTL

• Check the UMDS configuration with the “-G” parameter. It will display only the versions you chose in the previous step.

/usr/local/vmware-umds/bin/vmware-umds -G

• Trigger the download of the patches with the “-D” switch. It may take a little while depending on your bandwidth and how many vSphere versions you enabled. In my case, it took a little while as it had to download 3.6GB of patches.

/usr/local/vmware-umds/bin/vmware-umds -D

Installation of the Web Server

The web server is what allows vCenter to retrieve the patches from the UMDS server. As mentioned previously, you could do without it, in which case UMDS becomes less relevant.

• As usual with Linux, I suggest you start by running “apt-get update” or “yum update” according to your distro.
• Install Apache from the public repo.

sudo apt-get install apache2

• You can check that its current status is “active (running)”. I also suggest you reboot the server to ensure the web server starts automatically. If it doesn’t you may have to run “systemctl enable apache2”.

Systemctl status apache2

• We will now create a folder in the root of the webserver to export the downloaded patches to. You cannot export directly to the root.

mkdir /var/www/html/umds-export

• Set the UMDS Export location to that folder using the “-o” parameter, with “-S” again.

/usr/local/vmware-umds/bin/vmware-umds -S -o /var/www/html/umds-export/

• Once again you can check that the change was made.

/usr/local/vmware-umds/bin/vmware-umds -G

• We now need to export the patches to the webserver with the “-E” switch.

• You can check in a web browser that you see the content when browsing to the UMDS server.

http://core-umds.lab.priv/umds-export/

Configuration of vSphere Lifecycle Manager

So far, we have installed and configured UMDS with a web server, downloaded the patches and exported them to the webserver. We now need to configure vSphere Lifecycle Manager to use it as a download source for the patches.

• Log in the vSphere client and go to LifecycleManager > Settings > Patch Setup. Click CHANGE DOWNLOAD SOURCE.

• Check Download Patches from a UMDS shared repository and type the URL where the patches are stored, then click SAVE.

http://core-umds.lab.priv/umds-export

• The Patch Setup window should now look like the following.

• You can synchronize the update in Lifecycle Manager like you would with the default configuration.

What to do next

You are now ready to pull the vSphere patches from UMDS 7.0 in your secure environment. In the current state you will have to manually trigger the UMDS download and export tasks. It is recommended to create a cron job to automate these 2 actions in a weekly fashion for instance.

Maintaining an up-to-date vSphere environment should be taken seriously. It is critical to ensure that all the latest security patches are installed and reduce the attack footprint on your servers.

The post How to install and configure Update Manager Download Service (UMDS) 7.0 appeared first on Altaro DOJO | VMware.

Software-defined networking is revolutionizing the world of networking as we know it. It is doing for the networking world what server virtualization has accomplished for the datacenter. Software-defined networking is allowing organizations to overcome and even eliminate obstacles in the networking arena for the enterprise. It has also opened up a whole new world of possibilities.

VMware’s NSX is arguably one of the most popular software-defined networking (SDN) solutions in use today. VMware NSX-V uses an overlay encapsulation protocol called Virtual Extensible LAN (VXLAN) to create the overlay network used to create the virtual networks. What is VXLAN? Why is it required? What role does it play in virtual networking? What is the difference between VXLAN and traditional VLANs? How are VXLANs configured using VMware NSX-V?

Importance of network virtualization

Organizations are increasingly adopting cloud technologies and infrastructure. It includes increasingly virtualized constructs as part of this move toward cloud environments. New, very complex modern applications may require connectivity to components located in many different geographic regions. Network virtualization is allowing multiple virtual servers to connect to the same logical network despite different locations.

Network virtualization has made possible more robust east-west data center traffic than the more traditional north-south traffic flow between client-server architectures. Also, businesses today are moving at a rapid pace. One of the appealing facets of the cloud is the agility provided to provision infrastructure, including networks. Traditional network infrastructure has long been a roadblock to efficient and quick infrastructure provisioning. Making changes to typical physical network environments could take weeks with the various change control and technical configuration involved.

What is VXLAN?

VXLAN is an encapsulation protocol initially documented by the IETF in RFC 7348. It allows software solutions to tunnel Layer 2 communication over Layer 3 networks as described in the process above. VXLAN allows encapsulating Layer 2 network frames within UDP datagrams and transmitting them across Layer 3 boundaries. So, simply put, it encapsulates Layer 2 frames inside Layer 3 packets. Compared to the relatively limited number of Layer 2 VLANs possible, VXLAN offers the ability to create up to 16 million logical networks providing Layer 2 adjacency across Layer 3 IP networks. This increased scalability is made possible by a 24-bit header attached to the frame. This specialized header is known as the Virtual Network Identifier (VNI).

The increased scalability is an excellent feature for service providers and others who may have many different tenants. The 16 million VNIs means a unique ID can be assigned to potentially millions of customers, and this ID can remain unique across the entire network. Like a VLAN ID, the VNI establishes a boundary that allows isolation from one tenant to another. Since the VXLAN protocol is based on the IETF standard, it is an open standard not reliant on any particular vendor solution. The VXLAN encapsulation protocol is what provides the underlying technology upon which solutions can construct network virtualization solutions.

Another point to consider with VXLAN is that it is not merely a technology that can only be taken advantage of by virtualized solutions. VXLAN is an encapsulation protocol that can also be used by hardware devices that have the feature built-in. An example of a VXLAN-aware device is the Cisco Nexus 9000-EX platform.

VXLAN VTEPs

There is another unique construct of VXLAN that is important to understand. The VXLAN Tunnel Endpoint (VTEP) is responsible for encapsulating and decapsulating the Layer 2 frame traffic. The VTEP can be a virtualized solution like VMware NSX-V or a hardware gateway. Creating the VXLAN VTEPs is part of configuring a VXLAN implementation. We will see how this is configured in VMware NSX-V.

Overlay vs. Underlay

The VXLAN encapsulation protocol encapsulation of Layer 2 frames inside of Layer 3 packets creates what is known as an overlay. In contrast, the physical IP network that transmits the packets constitutes the underlay. The network overlay creates a layer of abstraction that allows the virtualized network to overlay “on top of” the physical network.

The network overlay is created when a packet or frame is encapsulated at its source and transmitted to the destination edge device. The encapsulation adds an outer header that allows the intermediary network devices to transmit the packet and forward it based on the outer header. They remain unaware of the original packet payload with the Layer 2 frame underneath. Once the packet arrives at the destination, the packet is decapsulated, and the receiving device strips off the outer header. The encapsulation process described is handled with an encapsulation protocol such as VXLAN.

This overlay created through the encapsulation protocol allows Layer 2 boundaries to stretch across the Layer 3 network underlay. In traditional networking constructs within a physical network with physical devices outside of network virtualization, Layer 2 segments are not “routed” or carried across Layer 3 boundaries. Certain technologies in the physical world, such as EoMPLS, VPLS, and OTV, allow stretching Layer 2 segments across routed boundaries. However, their implementation and flexibility aren’t nearly as seamless as using VXLAN.

One of the tremendous advantages of the overlay and underlay network design is it decouples the network configuration of the overlay and underly from one another. You can make changes in the overlay network without affecting the underlay and vice versa. However, it is essential to note that the underlay network’s stability and reachability affect the overlay networks created on top of them.

• Underlay – The underlay network includes the physical Layer 3 IP network used to transmit packets. The physical IP network includes all the physical hardware, cabling, and routing protocols used to transmit and receive these packets. OSPF, IS-IS, and BGP are examples of standard routing protocols for this purpose.
• Overlay – The overlay network is formed “on top of” the underlay physical network architecture. Configuration of the overlay network is decoupled from the configuration of the underlay network. Multiple virtual networks can overlay on top of a single physical network. Standard routing protocols are used to transmit VXLAN encapsulated packets.

Logical Overview of the VXLAN overlay network

VXLAN vs. VLAN

Those familiar with traditional networking constructs like VLANs will note similarities between the functionality of VXLAN and VLANs. VLANs provide a Layer 2 boundary in conventional networking that provides the “home” for a particular IP subnet. However, when comparing VLAN and VXLAN, the capabilities of VXLAN exceed those found in traditional VLANs in several areas. Let’s look at a quick comparison:

• VLANs allow some 4000+ different network segments
• VXLANs allows 16 million different network segments
• VLAN IDs are 12-bits in length, while VXLAN is 24-bit
• VLANs require trunking, whereas VXLAN does not
• VXLAN does not require spanning tree
• VLANs require physical network configuration
• VXLAN does not require physical network configuration to segment traffic

VMware NSX-V VXLAN Implementation

VMware NSX-V uses VXLAN for the network overlay encapsulation technology. It allows creating isolated multi-tenant broadcast domains and enables customers to have the ability to create logical networks that span between physical networks and underlying network locations. VMware NSX-V networking makes use of VXLAN to create logical networks and abstract networking resources.

It does this in much the same way as compute resources are virtualized and combined in virtual pools of resources consumed in the vSphere environment. VMware NSX-V allows doing this using VXLAN across clusters, pods, and even geographically separated data centers. As described above, VXLAN creates Layer 2 logical networks encapsulated in standard Layer 3 IP packets. A unique identifier called the Segment ID exists in each frame that designates VXLAN logical networks. It is different than VLAN tags, and we will see a bit later. The segment IDs allow creating isolated Layer 2 VXLAN networks that can coexist on the same Layer 3 network.

You may wonder where the encapsulation happens in VMware vSphere with NSX-V. The encapsulation is carried out between the virtual NIC of the guest workload VM and the logical port on the vSphere virtual switch. This encapsulation process benefits the VXLAN encapsulation by being transparent to the guest VM and underlying Layer 3 network infrastructure. How does a receiving server or device outside of the VXLAN construct communicate with nodes found on the VXLAN segment? It is made possible by the NSX Edge services gateway appliance. It translates VXLAN segment IDs to the VLAN IDs needed to communicate between the VMs on the VXLAN and these physical devices. What infrastructure is required to create the VXLAN VMware configuration?

NSX-V Manager

VMware NSX-V is the NSX Data Center solution for vSphere environments. The NSX Manager is a special-purpose service VM (SVM) that provides the GUI and REST APIs needed to create, configuring, and monitor NSX components. These components include the NSX Controllers, logical switches, and edge services gateways. Also, it provides the centralized network management component of NSX Data for vSphere. VMware packages the VMware NSX Manager appliance for NSX-V as an OVA appliance deployed into a VMware vSphere environment. It is the first component of the NSX-V infrastructure provisioned to begin configuring NSX-V.

Installing VMware VXLAN using NSX-V Manager

Let’s take a look at installing VMware VXLAN using the NSX-V Manager appliance in VMware vSphere. Deploying the VMware NSX-V Manager appliance is the first step to deploy VXLAN in your vSphere environment. After deploying the NSX-V Manager, you will integrate it with vCenter Server, which makes installing the special VMware NSX-V VIBs possible in your vSphere clusters. Once the VMware NSX-V Manager appliance is integrated with vCenter Server, you can configure VXLAN and the other logical constructs that make up your vSphere virtualized network.

After you download the VMware NSX-V Manager OVA appliance file, you deploy this using the standard means in the vSphere Client. Choose the OVA file on the Deploy OVF Template wizard.

Choosing the NSX-V Manager OVA

Select the name of the NSX-V Manager appliance and the folder location in your vSphere datacenter.

 
Choose the virtual machine name and folder

Select the compute resource in which you will run the NSX-V Manager appliance. It is standard best practice to run service VMs such as the VMware NSX-V Manager in a management cluster that houses other infrastructure VMs such as vCenter, vROPs, and others.

Choose the compute resource from your VMware vSphere datacenter

The wizard will display the initial deployment details for review.

Review the details of the VMware NSX-V Manager deployment

Next, select the datastore in which you want to deploy the VMware NSX-V Manager. You can also select the disk format during the deployment.

Choose the storage and disk policy

Select the virtual network to attach the VMware NSX-V manager appliance. This network connection is for connecting to the management interface that you will configure during the template customization process.

Choose the port group for the management network for the VMware NSX-V Manager

There are many important details to give attention to in the template customization step. Here you will configure the passwords for accessing the manager appliance as well as the pertinent network configuration information.

Customize the NSX-V Manager template

Finally, we arrive at the summary screen that displays the configuration before finalizing the deployment. Make sure all the information shown is correct before clicking Finish.

Ready to complete and finalize the VMware NSX-V Manager appliance deployment

Integrate VMware NSX-V Manager with vCenter Server

To enable VMware NSX-V’s functionality and configure VMware VXLAN in your environment, you integrate the newly deployed VMware NSX-V Manager with VMware vCenter Server. To do this involves registering the vCenter Server Lookup Service URL and the vCenter Server hostname. It will be the same address for most now who run the integrated Platform Services Controller configuration (recommended) with vCenter Server.

Registering the Lookup Service URL and vCenter Server address

Deploy NSX Controller Cluster

After deploying the NSX Manager and integrating it with vCenter Server, you will want to deploy the NSX Controller Cluster in your environment. The NSX Controller provides essential functionality in VMware NSX-V virtualized networking. The NSX Controller provides the control plane functions for NSX logical switching and Distributed Logical Router (DLR) functionality.

The NSX Controller maintains information about all hosts and logical switches and distributed logical routers in the environment. The Logical Switches are the VXLANs in the vSphere environment. The NSX Controller is a required component if you want to deploy DLRs and VXLAN in unicast or hybrid operation mode.

To deploy the NSX Controller, navigate to Networking and Security > Installation and Management > NSX Controller Nodes and choose to Add a new Controller Node.

Adding a new NSX Controller Node

Choosing the Add function launches the Add Controller wizard. First, choose a password for the controller.

Configuring a password for the NSX Controller Node

Next, on the Deployment & Connectivity screen, choose a name for the controller, datacenter, cluster/resource, datastore, host, folder, IP Pool, and select which vSphere Distributed Switch it will connect.

Configuring deployment and connectivity options for the VMware NSX Controller Node

After completing the wizard, the NSX Controller Node will begin deploying. The deployment will generally take a few minutes. As a note, you will want to deploy three controller nodes for high-availability for a production environment.

New NSX Controller Node is deployed successfully

Now, let’s prepare the ESXi hosts in the vSphere cluster for VMware VXLAN configuration.

Preparing ESXi Hosts for VMware VXLAN

One of the first steps you will go through to prepare the ESXi hosts for VMware VXLAN is installing NSX. This process installs the special VMware NSX-V ESXi VIBs needed for interacting with VMware NSX-V. Under the Networking and Security > Host Preparation screen, you will see your vSphere cluster(s) displayed with the option to Install NSX. Click the Install NSX button.

Before proceeding, you need to have a valid VMware NSX Data Center license installed before installing the NSX VIBs on your vSphere cluster ESXi hosts.

Choosing to Install NSX

Verify the installation of the VMware NSX-V VIBs

Configure VMware VXLAN

After installing the special VMware NSX-V VIBs on your vSphere cluster ESXi hosts, the next step is configuring VXLAN. Configuring VMware VXLAN on your vSphere cluster ESXi hosts is the process that creates the VXLAN VTEPs on your ESXi hosts used for encapsulating and decapsulating the Layer 2 frames sent via network virtualization.

On the Networking and Security > Installation and Upgrade > Host Preparation screen, after installing the NSX VIBs, choose to Configure the VXLAN.

Configuring VXLAN as part of the VMware NSX-V configuration

The Configure VXLAN Networking dialog box appears. Here you choose the vSphere Distributed Switch you want to use for VXLAN traffic and how you want to perform IP Addressing on your vmkNICs created for VTEP endpoints. You can also configure the specific vmkNIC Teaming Policy for the vmkNIC configuration.

Configuring VMware VXLAN networking

Once you click Save, you will see the VXLAN configuration turn to a green checkmark showing it is configured. When you click the View configuration link, you can view the configured settings.

VXLAN successfully configured in VMware NSX-V

After configuring the VXLAN settings, on the Logical Network Settings tab, you will see the default VXLAN port shown – 4789. As noted, you will want to verify the VXLAN port is allowed between the various ESXi VXLAN hosts, particularly if these reside in different networks and need to form VXLAN tunnels.

On the Logical Network Settings tab, the Segment ID configuration is the configuration that

Verifying the VXLAN port and editing Segment IDs

On the Edit Segment ID Settings dialog box, you choose a Segment ID pool range. The Segment ID range will essentially be the pool of VNIs (VXLAN Network Identifiers) assigned to the logical networks. Note, this is a range and not a single value.

Assigning a Segment ID pool

Next, we need to create the Transport Zones that defines the scope of any Logical Switches or Distributed Logical Routers (DLR) created. It controls which hosts a logical switch can reach, and it can span one or more vSphere clusters. It also defines which clusters and, by extension, which virtual machines can participate in a particular logical network.

Beginning the process to create VMware NSX-V Transport Zones

When creating a new Transport Zone, you define the Transport Zone’s name, its replication mode and select which clusters participate.

Creating a new Transport Zone

At this point, we have everything configured and ready to go for starting to create the Logical Switch (VXLAN) constructs in the environment. After assigning a Segment ID pool, we will start allocating logical resources as part of the VMware VXLAN implementation. Below, as you can see, the VXLAN configuration has been completed for the ESXi hosts in the vSphere cluster and we have “green” indicators across the board which is what we want to see.

VXLAN VMware configuration completed

VXLAN VMware Logical Switch Configuration

After completing the infrastructure configuration required for VMware NSX-V, we are now ready to create Logical Switches. Each Logical Switch is essentially a VXLAN in the environment. Navigate to Networking and Security > Logical Switches. Click the Add button to create a new Logical Switch.

Creating a new VMware NSX-V Logical Switch

You will configure the Logical Switch name, description, Transport Zone, Replication mode, IP Discover, and MAC learning configuration on the New Logical Switch dialog.

Configuring a new VMware NSX-V Logical Switch (VXLAN)

The new VMware NSX-V Logical Switch is created successfully. You will note the Segment ID configured uses the first available segment ID in the segment ID range configured earlier.

A VXLAN Logical Switch created in VMware NSX-V

Once the new Logical Switch is created, it will appear in the list of available networks to which a new virtual machine can be connected.

Connecting a new virtual machine to a new Logical Switch

Concluding Thoughts

VXLAN is a robust encapsulation protocol used to create software-defined overlay networks that can create Layer 2 segments across routed boundaries. It offers many benefits when compared to convention VLAN segments. Using VXLAN software-defined networks decouples the overlay network configuration from the underlay physical network. It allows making configuration changes on either the overlay or underlay networks without interdependencies between them. VXLAN encapsulates a Layer 2 Ethernet frame within an IP packet. These special packets are transmitted across the IP network and encapsulated/decapsulated using the VXLAN Tunnel Endpoint (VTEP).

VMware NSX-V is VMware’s software-defined networking technology based on VXLAN encapsulation that allows easily building out VXLAN-based SDN in VMware vSphere environments. As shown, various components allow creating the VXLAN tunnel in a VMware vSphere environment. These include the NSX Manager, NSX Controller, ESXi VIBs, Segment IDs, and Transport Zones.

By configuring the required VXLAN VMware components, you can provision Logical Switches in the environment representing a VXLAN allowing Layer 2 communication transmitted over the physical IP network. Using this approach, VMs that reside across Layer 3 boundaries can be connected to the same Logical Switch and communicate as if they reside on the same physical network switch.

The post VMware VXLAN: What is it and how to use it appeared first on Altaro DOJO | VMware.

There have been many advancements in modern IT infrastructure. Virtualization has totally revolutionized the way that organizations view compute, storage, and networking. The notion of “virtualizing” the modern datacenter was a paradigm shift in many areas of IT infrastructure and datacenter technology. Workloads abstracted from the physical hardware have opened up tremendous efficiencies, and advantages in the way businesses can provide digital resources.

Along with server virtualization that allowed businesses to abstract running operating systems from the physical hardware, network virtualization has brought tremendous networking advantages. Much as they were in the area of server virtualization, VMware has been a pioneer in the area of network virtualization. VMware NSX is well-known in network virtualization and is a powerful solution that enables network virtualization, both in the data center, public cloud, and multi-cloud environments.

What challenges exist in data centers still leveraging traditional networking? What is VMware NSX? What is the difference between NSX-V and NSX-T? What advantages does NSX-T offer over NSX-V? What is the migration process to get from NSX-V to NSX-T? What features does NSX-T offer today to empower modern workloads?

Traditional data center networking challenges

VMware’s Software-Defined Data Center (SDDC) vision incorporates next-generation virtualization technologies. It allows organizations to realize automated, non-disruptive deployments of business-critical infrastructure in a way that helps reduce operational complexity and extend technical agility to deliver applications. By now, most organizations have virtualized most of their server infrastructure in their data centers and are also taking advantage of software-defined storage technologies.

Datacenter networks have historically been extremely slow to respond to the changing needs of the enterprise. Networking is often too rigid, complicated and presents many barriers to innovation and realizing the full potential of virtualizing other data center components such as servers and storage. Traditional networking technologies constrain the advantages gained by virtualizing servers and storage.

Traditional networking presents the following challenges:

• Provisioning new routers, switches, and other technologies is slow
• Proprietary networking technologies historically bind traditional networking from specific networking vendors
• Automated network configuration is generally non-existent
• Changes generally require manual interaction
• Even for experienced network engineers, network changes are error-prone
• Many traditional network constructs such as VLANs, firewalls, load balancers, ACLs, and others present roadblocks to fast-paced development and DevOps-style infrastructure
• Traditional networking depends on workload placement
• Workload mobility is limited
• Firewall rule sprawl
• VLAN and IP topology sprawl

What if the network could be abstracted from the underlying physical network infrastructure and placed into the software layer? VMware NSX allows eliminating the challenges mentioned above with traditional physical networks.

What is VMware NSX?

VMware NSX is a robust software-defined networking (SDN) technology that solves complex networking challenges in the modern data center environment. It enables organizations to move rapidly to deploy new networks, change existing network designs, and effectively automate networks in code. It allows businesses to connect their virtual cloud networks and protect applications across on-premises data centers, multi-cloud environments, bare-metal workloads, and modern container infrastructure with ease. Aside from delivering software-defined networking capabilities to the enterprise, VMware NSX empowers businesses with an L2-L7 security virtualization solution. With VMware NSX, companies can manage their virtual networking and network security from a single pane of glass UI with the management and security tools in a seamless interface.

VMware NSX brings both networking and security constructs closer to where the application lives. Applications can reside inside virtual machines, bare-metal physical servers, and modern containerized applications. Regardless of where the application lives or the underlying physical network, networks can be provisioned and managed independently. Since VMware NSX is a software-defined solution and does not rely on physical networking gear, it provides logical networking and security capabilities, including:

• Logical switching – VMware NSX provides logical switching capabilities that extend Layer 2 switching boundaries across a routed Layer 3 fabric. The extensions can include both within and across data center environments and public/private clouds.
• Routing – With VMware NSX, organizations have a much more modern approach to Layer 3 routing distributed in the hypervisor kernel.
• Gateway firewall – The software-defined gateway firewall provides stateful firewall capabilities up to Layer 7, with NSX providing app identification and distributed FQDN whitelisting. Again this is distributed with centralized policy and management.
• Distributed firewall – Similar to the gateway firewall, the distributed firewall as part of the VMware NSX solution provides stateful Layer 7 firewall capabilities with app ID and distributed FQDN whitelisting
• Load balancing – Organizations can use the VMware NSX load balancer to provide L4-L7 load balancing features with SSL offloading. Other features such as server health checks and passive health checks and API interaction are part of the solution.
• Virtual Private Network (VPN) – Site-to-Site VPN, remote-access VPN, and cloud gateway services are possible with VMware NSX VPN
• NSX Gateway – You can bridge physical Layer 2 VLANs from the physical network with NSX overlay networks using the NSX Gateway
• NSX Intelligence – The NSX Intelligence platform uses automated artificial intelligence (AI) and machine learning (ML) to provide continuous monitoring and visualization for network traffic flows to recognize malicious traffic and intent
• NSX Distributed IDS/IPS – VMware NSX has evolved to provide centralized advanced threat detection and prevention engine that allows detecting and preventing east-west movement of malicious threats. It provides a distributed architecture and application context in software that can replace the functionality provided by discrete security appliances.
• Federation – For organizations managing multiple VMware NSX environments, the Federation capability allows managing and configuring numerous environments with a single pane of glass using centralized policy and enforcement
• Virtual Routing and Forwarding (VRF) – For multi-tenant environments, VMware NSX provides complete data plan isolation using the NSX Tier 0 gateway that provides separate routing tables, NAT, and edge firewall support in each VRF.
• NSX Data Center API – Developers and DevOps automation tools have access to RESTful APIs that allow interacting with VMware NSX programmatically.
• Operations – VMware NSX includes native tools such as traceflow, overlay logical SPAN, and IPFIX and also allows easy integration with other tools such as vRealize Network Insight (vRNI).
• Quality of Service (QoS) – Define software-based QoS features to applications
• Context-aware micro-segmentation – Security groups and policies with VMware NSX can automatically be created and updated based on various environmental attributes outside of the typical network constructs such as IP address, port, and others.

The logical, software-defined architecture allows easily provisioning networking non-disruptively over existing physical networks. VMware NSX logical networks can extend across data centers, public and private cloud environments, containers, and bare-metal servers.

How does VMware NSX work?

Software-defined network solutions, including VMware NSX, make use of an underlay and an overlay network. It provides the ability to separate the control and data planes between the two. Let’s see how both the underlay and overlay networks play a part in network communication with a software-defined network (SDN) solution.

• Underlay – The underlay network includes the physical network infrastructure that enables the transmission of packets. The underlay network also consists of the routing protocols needed to allow for IP connectivity between locations. Routing protocols including OSPF, IS-IS, and BGP are examples of common routing protocols for this purpose.
• Overlay – The overlay network is where the “magic” of a software-defined network happens. The overlay network is formed “on top of” the underlay physical network architecture. Both the data plane traffic and control plane signalling are controlled within the virtualized network. Multiple virtual networks can overlay on top of a single physical network. Overlay networks use overlay protocols such as VXLAN, NVGRE, OTV, and GENEVE

A high-level overview of the Overlay and Underlay network in software-defined networking

VMware NSX key benefits

VMware NSX provides many critical benefits to organizations looking to modernize networking operations in their environments. These include the following:

• Micro-segmentation – The notion of having a “trusted” internal network is no longer practical with new-age threats and the way attackers are compromising networks via east-west attacks
• Automated network provisioning – The ability to automate network provisioning, configuration, and security policy management allows businesses to be much more agile in their operations
• Consistent management of networking and security policies – Since logical networks can be controlled through code, it allows much more consistent management of networking and security policies
• Built-in network visualization and monitoring – VMware NSX provides monitoring and visualization of application topologies, security policies, and flow monitoring
• Advanced east-west threat prevention and distributed IPS/IDS – To bolster the built-in micro-segmentation capabilities of VMware NSX, distributed IPS/IDS provides automated threat protection and prevention capabilities. The benefits include elastic throughput, reduce false positives, improved utilization of computing capacity.

VMware NSX use cases

These are alluded to with the key benefits covered. However, what are the specific use cases for using VMware NSX solutions? These include the following:

• Security
• Multi-cloud networking
• Network automation
• Networking and security for cloud-native applications

Security

Arguably the most obvious use case with using VMware NSX is security. There is a new cybersecurity best practice model known as “Zero-Trust.” The traditional network operates on the notion of an “untrusted” zone, typically the Internet, and a “trusted” zone, which has historically included the internal LAN. With new threats that have emerged, such as ransomware and other malicious tools used by attackers, there the “trusted” network is no longer a practical approach for security

Using the Zero-Trust approach, all network traffic is viewed as untrusted, regardless of where the traffic originates. In the Zero-Trust model, even if two servers share the same network, they should not implicitly trust all network traffic communicated between them. Using micro-segmentation, distributed IPS/IDS, and context-aware firewalling, VMware NSX allows organizations to have the tools to implement a Zero-Trust model in their networks effectively. It helps to prevent attackers from compromising internal resources due to lateral east-west movement.

Multi-cloud networking

Traditional networking in a single on-premises data center can be difficult, let alone networking between data centers and even on-premises and cloud environments. With VMware NSX software-defined solutions, networking and security boundaries can be extended between heterogeneous sites. It allows stretching sites and moving workloads between on-premises and cloud environments without disruption.

Traditional physical networking cannot achieve the mobility and flexibility that VMware NSX provides for workloads. It decouples the requirements that a physical network exists in a particular location and allows networks to be placed where logically needed to solve challenging technical and business use cases.

Network Automation

One of the compelling capabilities afforded by the VMware NSX platform is the ability to automate the solution. The deployment of full-stack solutions can be accomplished in code without entering a CLI interface or deploying physical appliances. VMware NSX exposes various APIs that allow interacting with the solution through RESTful API calls. You can also integrate VMware NSX with other automation solutions such as Ansible, Terraform, and vRealize Automation, automation solutions commonly used within the enterprise.

Networking and security for cloud-native applications

VMware NSX allows your organization to provide both networking and security capabilities for modern workloads and containerized applications. You can do this with a very granular policy based on each container. It allows applying the same micro-segmentation capabilities for virtual machines to containers.

VMware NSX-V vs. VMware NSX-T

If you have been keeping up with the evolution of VMware NSX, you will be quick to note VMware NSX has evolved in the past few years from the early days of its initial releases. VMware NSX now comes in two different versions of the product. There are VMware NSX-V and VMware NSX-T. Each version of VMware NSX has specific use cases and characteristics. It is essential to recognize the differences between the two solutions and understand which version you should deploy. Let’s take a detailed comparison between VMware NSX-V and VMware NSX-T to see how the solutions are different, why NSX-T is an improvement over NSX-V, and the migration path from NSX-V to NSX-T.

What is VMware NSX-V?

VMware introduced the original VMware NSX product after VMware’s purchase in 2012 of a company called Nicira. VMware integrated Nicira’s R&D teams and shortly after that introduced the first version of VMware NSX. This became the mainstream VMware NSX-V. The “V” in the NSX-V solution stands for “vSphere.” VMware NSX-V is a vSphere-only solution. It is VMware’s software-defined networking platform supported to run in a vSphere environment. Currently, the solution is marketed as NSX Data Center for vSphere. Installing VMware NSX-V requires you have a vCenter Server in the environment. When VMware NSX-V is installed, it registers with your vCenter Server, and the solution integrates into vSphere through the connection with vCenter.

The vCenter Server is defined as the compute manager for the VMware NSX-V solution. VMware NSX-V connections are made through the vCenter Server APIs to interact with vSphere and onboard ESXi hosts. One of the reasons that VMware NSX-V is reliant on vCenter Server is the vSphere Distributed Switch (VDS) requirement for the more advanced VMware NSX-V functionality, including logical switches, etc. The vSphere Distributed Switch is a vCenter Server construct that requires a vCenter Server in the environment. Unlike the vSphere Standard Switch that resides on the ESXi host itself, vCenter Server maintains the vSphere Distributed Switch (VDS). The vCenter Server synchronizes the VDS switches with the ESXi hosts.

As described earlier with software-defined networking, an overlay network creates the virtual network on top of the underlay network or the physical network that transmits the packets. To create the overlay network, VMware NSX-V uses the VXLAN network encapsulation protocol. What is VXLAN? VXLAN is short for Virtual Extensible LAN. It is an encapsulation protocol that provides connectivity between data centers through tunneling. It effectively allows connecting two Layer 2 segments over Layer 3. VXLAN is not a VMware-only technology. It is an open standard used in many different vendor technologies, including EVPN, Cisco ACI, etc.

VXLAN uses packet encapsulation similar to VLANs that creates VXLAN tunnels between VXLAN tunnel endpoints (VTEPs). The problem with VLANs is they were developed with a fixed 12-bit field, which means there are roughly 4000 VLANs that can be provisioned in a single environment. However, VXLAN overcomes this issue as each VXLAN segment uses a 24-bit segment ID known as the VXLAN Network Identifier (VNI) for identification. The 24-bit segment ID allows up to 16 million unique VXLAN segments in the same administrative domain as opposed to the 4000 with VLANs.

Through VXLAN, VMware NSX-V can create logical, virtual networks and the ability to “stretch” and architect networks in a way that solves very complex problems. It also allows creating virtual constructs such as the L2 logical switch, distributed logical routers, load balancers, and other features.

Why is it being deprecated?

As organizations have transitioned from mainly on-premises data centers to leverage the cloud for many workloads, it became apparent a new version of VMware NSX was needed. A modern network virtualization solution needs to scale beyond VMware vSphere and allow organizations to use network virtualization with modern cloud-native platforms. For quite some time, VMware NSX-V was VMware’s preferred network virtualization solution for VMware vSphere. However, VMware introduced a new version of VMware NSX, known as VMware NSX-T (which will be described in detail to follow).

The early stages of the VMware NSX-T release lacked many of the features that enterprise customers had with VMware NSX-V and lacked the seamless installation process with VMware NSX-V. Since VMware NSX-V has been around much longer than NSX-T, there were many more third-party integrations with VMware NSX-V than NSX-T, as you would expect. In the early stages of VMware NSX-T, customers with many third-party integration requirements were better suited to install VMware NSX-V.

VMware NSX-V at this point is considered the legacy VMware NSX solution in the portfolio of VMware NSX Data Center solutions. VMware NSX-T is a much more robust and fully-featured modern implementation of VMware NSX that is no longer limited to the confines of VMware vSphere. VMware is steering customers with greenfield implementations of VMware NSX to install VMware NSX-T, even in VMware vSphere environments. They have also created a migration process with the technical tools needed to migrate from the VMware NSX-V platform to NSX-T.

VMware is committed to supporting NSX-V environments until the end of general support date. The end of general support date is January 16, 2022. The end of technical guidance given by VMware for VMware NSX-V follows on January 16, 2023.

What is VMware NSX-T?

VMware NSX-T is the new, modern release of VMware NSX Data Center. NSX-T is the solution that will be moving forward with VMware network virtualization, covering all platforms, including VMware vSphere. The “T” in NSX-T stands for “Transformers.” Intuitively, NSX-“Transformers” allows the solution to transform beyond the initial use case of network virtualization with VMware vSphere and into the realm of public cloud and modern containerized workloads.

VMware NSX-T is a very flexible solution businesses can implement with VMware vSphere and KVM hypervisors and bare-metal servers, and containerized workloads. It is the network virtualization platform VMware has chosen for their VMware on AWS cloud IaaS solution. It is also running under the hood of Amazon AWS Outposts.

VMware NSX-T is VMware’s solution to modernize networking and security in the enterprise and cloud-native environments and everything in between. You can think of VMware NSX-T as a multi-cloud solution that allows organizations to stitch networking together in an effective, efficient, and seamless way. This type of solution is needed as modern applications may contain many different infrastructure components. It may include virtual machines, containers, and even bare-metal workloads.

Businesses need an API-driven solution, flexible, intrinsic security, and streamlined operations to solve the challenges with the diverse infrastructure and cloud environments that back modern applications. These are the types of challenges that VMware NSX-T is purpose-built to address.

VMware NSX-T removes the requirement for VMware vCenter Server to deploy the solution. You can deploy VMware NSX-T VMware ESXi host transport nodes without vCenter Server altogether.

Adding a VMware NSX-T ESXi transport node

Compatibility and interoperability with VMware vSphere is still very strong. VMware vCenter Server is now referred to as a Compute Manager. You add vCenter as a Compute Manager to allow easy integration with ESXi hosts if you want to onboard ESXi hosts in mass.

Adding vCenter Server as a Compute Manager in NSX-T

It is due to VMware NSX-T being a standalone solution in its own right. It does not depend on a particular hypervisor compute manager such as VMware vCenter Server to function. However, many of the basic concepts highlighted with VMware NSX-V apply with NSX-T. VMware NSX-T uses an encapsulation protocol to create an overlay network on top of the physical network underlay.

Adding virtual network segments in NSX-T

Instead of using the very common VXLAN, VMware NSX-T has moved forward using the GENEVE network encapsulation protocol. What is GENEVE? GENEVE is short for Generic Network Virtualization Encapsulation. Compared to other popular network encapsulation protocols, GENEVE is believed to be the modern technology moving forward. It helps to solve many of the problems or limitations found with earlier encapsulation protocols like VXLAN. While it works almost identically to VXLAN, it offers more flexibility in its implementation because of control plane independence.

GENEVE is an open standard that does not include information or specification for the control plane. The IETF draft states this:

Although some protocols for network virtualization have included a control plane as part of the tunnel format specification (most notably, the original VXLAN spec prescribed a multicast learning-based control plane), these specifications have largely been treated as describing only the data format. The VXLAN frame format has actually seen a wide variety of control planes built on top of it.

There is a clear advantage in settling on a data format: most of the protocols are only superficially different, and there is little advantage in duplicating effort. However, the same cannot be said of control planes, which are diverse in very fundamental ways. The case for standardization is also less clear given the wide variety in requirements, goals, and deployment scenarios.

Another slight variation, when compared to VXLAN, is the terminology difference between the tunnel endpoints. While VXLAN tunnel endpoints are referred to as VTEPs, the GENEVE tunnel endpoints are simply called tunnel endpoints (TEPs). With GENEVE under the hood of VMware NSX-T, NSX-T has “future-proofing” built into the solution from an encapsulation protocol perspective.

While VMware NSX-V uses a more traditional approach to routing, VMware NSX-T introduces a new two-tier routing architecture that is better suited for multi-tenant environments and scaling for today’s very complex cloud architectures. With VMware NSX-T, it has introduced a new TIER-0 and TIER-1 routing topology.

Why should organizations migrate to VMware NSX-T?

If you are running VMware NSX-V, besides the end of life looming in 2022, why should organizations migrate to VMware NSX-T from a feature perspective? VMware NSX-T provides an extremely robust solution with modern features and capabilities that align with the cloud-native applications organizations are using today. VMware cites four reasons that organizations should migrate from NSX-V to NSX-T from a feature perspective. These include:

• Scale-out networking, including NSX Federation – VMware NSX-T provides the means to federate and manage numerous installations of VMware NSX across multiple locations.
• Full-stack networking for modern distributed applications – This sets VMware NSX-T apart from VMware NSX-V. NSX-T is purpose-built to handle modern applications, including containerized workloads, something NSX-V was never designed to do.
• NSX Intelligence with best-in-class security – NSX Intelligence is a modern AI and ML-driven solution that provides proactive security intelligence in your environment to find and prevent cybersecurity attacks.
• Networking and security automation – NSX-T provides a robust API-driven interface that helps to simplify network automation.
• More intuitive dashboard and monitoring capabilities

New features in VMware NSX-T 3.1

VMware NSX-T 3.1 contains many new features, including the following:

• Cloud scalability improvements
• Simplified operations
• East-west traffic security improvements
• Distributed IDS/IPS
• NSX Intelligence 1.2
• NSX-V to NSX-T Migration for large scale networks

Cloud scalability improvements

VMware NSX-T 3.1 contains many new cloud scalability improvements. These include NSX T auto-scaling build into the platform that allows growing as your network needs change. NSX-T 3.1 provides clustering support for the NSX Global Manager, simplified disaster recovery workflows, a terraform provider for better automation, and improved scalability for large deployments.

New enhancements to multicast traffic have also been provided. It enables multicast in a multi-tenant environment. New tenant multicast deployments can be automated with APIs and no longer require changing the network’s underlying configuration.

Simplified operations

VMware NSX-T 3.1 provides simplified operations for use with both private and public cloud environments. It includes deep integration with vREalize Network Insight (vRNI) to enhance network modelling, configuration, and intent verification. It helps to understand the impacts of network changes as well as offers better network planning overall.

With the new vSphere 7.0 and higher releases, VMware has introduced the new vSphere Lifecycle Manager (vLCM). With vLCM, organizations can access simplified lifecycle management across their environment that understands VMware NSX-T and provides NSX lifecycle management.

VMware NSX-T provides a better dashboard for monitoring and viewing traffic, compliance, and other reporting. It allows admins to get information about the network quickly.

VMware NSX-T monitoring and compliance report

The VMware NSX-T dashboard is searchable and displays information about the virtual network environment and security in a single intuitive dashboard.

VMware NSX-T provides an intuitive seamless dashboard for viewing the environment

East-west traffic security improvements

VMware has introduced the ability to purchase Internal Firewall and Advanced Threat Prevention (ATP) independently of the networking features in VMware NSX-T 3.1. The Advanced Threat Prevention capabilities include Distributed IDS/IPS, Network Traffic Analytics/Networking Detection and Response, and Network Sandboxing.

VMware NSX-T provides network introspection capabilities for east-west traffic

Distributed IDS/IPS

VMware NSX-T 3.1 introduces the world’s first distributed IDS/IPS solution that provides the ability to detect and stop east-west lateral threat movement across your environment. It also helps to replace discrete hardware appliances and strengthens compliance capabilities.

The IDS/IPS’s virtual patching capabilities help patch vulnerabilities at a workload level without new signatures from an endpoint security perspective. From a performance perspective, the overhead is minimal.

VMware NSX-T Distributed IDS/IPS

NSX Intelligence 1.2

With NSX Intelligence 1.2, VMware has added NSX Intelligence’s ability to cover physical servers and improves recommendations across the entire environment, including VMs and bare-metal servers. This also includes L7 content profile recommendations with App-ID support. Visualizations include the display of user and process level context from workloads.

VMware NSX-T NSX Intelligence provides a modern security solution

VMware NSX-T application context

NSX-V to NSX-T Migration for large scale networks

VMware has added integration with vRealize Automation and provided Migration Coordinator enhancements. It is all to help organizations accelerate their migrations from NSX-V to NSX-T. The migration coordinator’s new capabilities allow customers to migrate things like firewall rules with lift and shift ease from NSX-V environments over to NSX-T.

NSX-T migration coordinator

Comparing NSX-V with NSX-T

Any way you look at it, VMware NSX is a revolutionary technology. It has evolved into an even more powerful solution since its inception in the early days of 2012. Let’s review by comparing the differences between the two solutions.

Reliance on VMware vCenter

VMware NSX-V is a VMware vSphere-only solution. It is VMware’s initial NSX solution based on the original code acquired from Nicira. With VMware NSX-V, it requires a connection to vCenter Server for integration with the ESXi hosts. Another reason for the vCenter Server integration is the requirement for vSphere Distributed Switches (VDS). The VDS is required for the advanced functionality that VMware NSX-V provides such as Logical Switching.

VMware NSX-T does not require a vCenter Server and allows interacting with ESXi hosts directly and onboard those as transport nodes. VMware vCenter Server can be used as a compute manager to integrate with multiple ESXi hosts. However, the key here is that VMware NSX-T is not a vSphere-specific network virtualization platform.

Overlay technology

VMware NSX-V uses Virtual Extensible LAN (VXLAN) as the overlay technology that creates the virtualized network infrastructure. VXLAN is a vendor-neutral protocol and provides a 24-bit segment ID that provides 16 million possible virtual network segments. It is far above the traditional VLAN, which provides roughly 4000 useable network segments.

VMware NSX-T uses the Generic Network Virtualization Encapsulation (GENEVE) as the overlay network encapsulation protocol. GENEVE is regarded as an even more modern encapsulation protocol that helps overcome some of the limitations of more traditional network encapsulation protocols like VXLAN.

Routing

VMware NSX-V uses a more traditional routing architecture. VMware NSX-T introduces a multi-tier routing architecture using what is known as a TIER-0 and TIER-1 routing topology. It is a much better approach for today’s multi-tenant environments.

Multi-cloud capabilities

In terms of multi-cloud capabilities, VMware NSX-V is limited. Since it is limited to VMware vSphere environments, it is not considered a multi-cloud platform. Even “VMware” cloud environments such as VMware Cloud on AWS do not use VMware NSX-V, but rather VMware NSX-T.

VMware NSX-T is a multi-cloud network virtualization technology. Since it is not a VMware vSphere-only technology and is designed for modern workloads, VMware NSX-T is a true multi-cloud platform. It allows organizations to leverage the power of virtual networking on-premises as well as in the cloud.

Feature parity

In the early days of the solution, VMware NSX-T did not have feature parity with VMware NSX-V. However, now, VMware NSX-T has effectively surpassed VMware NSX-V in terms of what it can do and the powerful integrations with other solutions like NSX Intelligence.

Lifecycle and End of Life

VMware NSX-V is a solution that will be going end of life in 2022 and then extended technical guidance will be ended in 2023. Considering this fact alone, VMware NSX-T is a solution that organizations will be installing moving forward for greenfield installations. Also, environments that are currently on VMware NSX-V will need to migrate to VMware NSX-T.

VMware NSX-T is the modern solution moving forward for both VMware vSphere and multi-cloud environments. New features and functionality will be included in VMware NSX-T. At this point, VMware NSX-V will be maintained and patched. It would not be surprising to see a few new features added. However, for the most part, VMware NSX-T will receive the majority of new capabilities.

The post NSX-T vs NSX-v: What is the difference? appeared first on Altaro DOJO | VMware.

VMware has recently enlarged NSX’s service defined firewall security capabilities with the acquisition of LastLine, an anti-malware and AI-powered network detection response solution. LastLine’s network traffic analysis (NTA) will help protect east-west traffic across multi-cloud environments and uses unsupervised and supervised machine learning to identify threats and reduces false positives by up to 90%. On top of that, virtual patches can be added at every workload in the environment and not limited to just the perimeter.

NSX Advanced Threat Detection can be installed in less than an hour and immediately starts sensing the north, south, east and west network traffic. Within a few days, you will gain visibility into all the devices communicating on the network as well as their operating system, as well as which services and application are involved.

It will process the network traffic and narrow down the search through several hoops. In the example below from the VMworld session, we can see that 4 intrusions were identified out of almost 20TB of data analysed.

It will first process terabytes of network data by applying various forms of machine learning to identify potentially suspect and malicious network activity. Artificial Intelligence will then leverage all the knowledge about these anomalies to identify what malicious actors might be doing on the network and prioritize intrusions based on the risk associated. This is where Advanced Threat Protection can expect to reduce the number of false positives in the threat detection compared to a Legacy IDS solution.

The management console offers a holistic view of the detected threats associated with the affected hosts with a colour-coded display to highlight the most dangerous threats. Amazingly, it even provides insight into the context of the attack and its different stages.

To go even further, an “intrusion blueprint” of the attack is generated to quickly get an idea of the scale of the attack with a visual representation of the different flows of internal and external assets involved. That intrusion blueprint can also be displayed as a detailed timeline of events detailing the stage of the action (delivery of payload via email, lateral movement with psexec, exfiltration with data upload and so on).

This interface offers an incredibly in-depth graphical view of actions that were in the past identifiable in gigabytes of logs.

The analysis shows the network interactions of each stage and the threat level of the payload. AI will also warn on unusual operations that deviate from a typically observed pattern. For instance, a host that uploads 1GB of data while it usually sends around 150MB will be reported as suspicious data upload.

NSX Network Detection Response provides a Flexible, distributed and scalable cloud architecture with a rich set of APIs which integrates with existing workflows. It will help block malicious network flows, prevent data exfiltration and render attackers attempts unsuccessful.

Conclusion

This new release fits right into VMware’s drive towards providing customers with the intrinsic security mindset. VMware NSX Advanced Threat Prevention brings network detection and prevention to a whole new level by providing security engineers with visibility never seen before on malicious activity.

The post VMware NSX Advanced Threat Prevention in a Nutshell appeared first on Altaro DOJO | VMware.

Anyone who’s been following this blog on a regular basis, has probably seen Virtual SAN (vSAN) mentioned a number of times. Like similar offerings on the market, vSAN is yet another iteration of what is known as Software Defined Storage or SDS which, simply put, is the abstraction of the storage layer from its underlying hardware. The rationale behind this concept lies in providing a simplified management and provisioning experience while concurrently reducing complexity and maximizing efficiency. This brings me to today’s subject matter which goes by the name of NSX. Similar to vSAN, NSX is VMware’s spin on virtualizing the network layer by embedding it directly in the hypervisor kernel.

Software-Defined Networking (SDN) which is what NSX is, turns out to be one of the cornerstones of a more encompassing idea referred to as Software-Defined Data Center (SDDC), a virtualized rendering of all the components defining a datacenter i.e. servers, storage and the networks that tie everything together.

A historical note of interest worth mentioning is that virtualization, surprisingly, is anything but a recent development. In fact, the CP-40 developed for IBM was the first system capable of running multiple operating systems in parallel and independently of each other using the same hardware. I’m talking way back in the late ’60s. Fast forward six or so decades, and not only do we take virtualized compute resources (virtualized servers, desktops, etc) for granted but we now demand the same level of virtualization prowess in both storage and networking departments.

So, what is NSX exactly?

I’m going to take a short-cut here and quote directly from VMware’s NSX product page;

“NSX embeds networking and security functionality that is typically handled in hardware directly into the hypervisor. The NSX network virtualization platform fundamentally transforms the data center’s network operational model like server virtualization did 10 years ago, and is helping thousands of customers realize the full potential of a SDDC. With NSX, you can reproduce in software your entire networking environment. NSX provides a complete set of logical networking elements and services including logical switching, routing, firewalling, load balancing, VPN, QoS, and monitoring. Virtual networks are programmatically provisioned and managed independent of the underlying hardware.”

NSX comes in three flavors; standard, advanced and enterprise each with its own feature set. The full details are available here.

Figure 1 – VMware NSX Editions (Source: VMware.com)

The key benefits to NSX are micro-segmentation and granular security, drastically reduced network provisioning times, workload mobility independent of physical networks, enhanced security and advanced networking services via 3^rd party vendor integration.

The basic architecture

There are a number of layers comprising NSX, each with its own set of components and services offered. These are;

Data Plane – the main sub-component found here is the NSX vSwitch. This is basically a modified vSphere Distributed Switch with added functionality. Some of the benefits include, a reduction in the use of VLAN IDs and the ease with which a flexible L2 virtualized architecture can be overlaid on existing physical networks. Moreover, the data plane provides the mechanics for services such as distributed routing, VXLAN capabilities and logical firewalling.

Control Plane – this plane consists of what is known as an NSX Controller Cluster which is in turn comprised of three NSX Controllers. An NSX controller, which is a Linux based virtual machine, acts as a control point for all the logical switching and routing functions provided by NSX and provides hosts with the required network information. A cluster is tasked with several roles including an API provider, Switch manager, Logical manager, Directory server and a Persistence server.

Management Plane – the NSX Manager is the primary component at this level which provides a single point of configuration and entry point for the REST API provided. The NSX Manager is the first thing you’ll install as an appliance on a unique instance of vCenter Server.

Consumption Platform – this is where integration with most cloud management platforms occurs via the provided REST API. Integration is also available through VMware vCloud Automation Center, vCloud Director, and OpenStack with the Neutron plug-in for NSX.

NSX Edge – Deployed either as an Edge Service Gateway (ESG) or a Distributed Logical Router (DLR), NSX Edge provides a ton of services including firewalling, natting, VPN, load balancing and HA if deployed as an ESG and East-West (server to server) routing using DLR.

Figure 2 – NSX layers and components (source: VMware.com)

Services offered

The NSX Manager in vSphere Web Client, shown in Figure 3, exposes a number of services.  Once again I’ve opted to quote directly from VMware’s documentation instead of paraphrasing the whole lot.

Figure 3 – NSX Manager in vSphere Web Client

• Logical Switches: A cloud deployment or a virtual data center has a variety of applications across multiple tenants. These applications and tenants require isolation from each other for security, fault isolation, and non-overlapping IP addresses. NSX allows the creation of multiple logical switches, each of which is a single logical broadcast domain. An application or tenant virtual machine can be logically wired to a logical switch. This allows for flexibility and speed of deployment while still providing all the characteristics of a physical network’s broadcast domains (VLANs) without physical Layer 2 sprawl or spanning tree issues. A logical switch is distributed and can span across all hosts in vCenter (or across all hosts in a cross-vCenter NSX environment). This allows for virtual machine mobility (vMotion) within the data center without limitations of the physical Layer 2 (VLAN) boundary. The physical infrastructure is not constrained by MAC/FIB table limits, because the logical switch contains the broadcast domain in software.
• Logical Routers: Routing provides the necessary forwarding information between Layer 2 broadcast domains, thereby allowing you to decrease the size of Layer 2 broadcast domains and improve network efficiency and scale. NSX extends this intelligence to where the workloads reside for East-West routing. This allows more direct VM-to-VM communication without the costly or timely need to extend hops. At the same time, NSX logical routers provide North-South connectivity, thereby enabling tenants to access public networks.
• Logical Firewall: Logical Firewall provides security mechanisms for dynamic virtual data centers. The Distributed Firewall component of Logical Firewall allows you to segment virtual datacenter entities like virtual machines based on VM names and attributes, user identity, vCenter objects like datacenters, and hosts, as well as traditional networking attributes like IP addresses, VLANs, and so on. The Edge Firewall component helps you meet key perimeter security requirements, such as building DMZs based on IP/VLAN constructs, and tenant-to-tenant isolation in multi-tenant virtual data centers. The Flow Monitoring feature displays network activity between virtual machines at the application protocol level. You can use this information to audit network traffic, define and refine firewall policies, and identify threats to your network.
• Logical Virtual Private Networks (VPNs): SSL VPN-Plus allows remote users to access private corporate applications. IPsec VPN offers site-to-site connectivity between an NSX Edge instance and remote sites with NSX or with hardware routers/VPN gateways from 3rd-party vendors. L2 VPN allows you to extend your datacenter by allowing virtual machines to retain network connectivity while retaining the same IP address across geographical boundaries.
• Logical Load Balancer: The NSX Edge load balancer distributes client connections directed at a single virtual IP address (VIP) across multiple destinations configured as members of a load balancing pool. It distributes incoming service requests evenly among multiple servers in such a way that the load distribution is transparent to users. Load balancing thus helps in achieving optimal resource utilization, maximizing throughput, minimizing response time, and avoiding overload.
• Service Composer: Service Composer helps you provision and assign network and security services to applications in a virtual infrastructure. You map these services to a security group, and the services are applied to the virtual machines in the security group using a Security Policy. Data Security provides visibility into sensitive data stored within your organization’s virtualized and cloud environments and reports any data security violations.
• NSX Extensibility: 3rd-party solution providers can integrate their solutions with the NSX platform, thus enabling customers to have an integrated experience across VMware products and partner solutions. Data center operators can provision complex, multi-tier virtual networks in seconds, independent of the underlying network topology or components.

Getting acquainted

I must confess that prior to doing the research for this post, I never had the opportunity to work with NSX despite having worked for an IaaS provisioning company whose infrastructure and offerings were heavily VMware centric. So off I went and downloaded the latest NSX version which, at the time of writing, stands at v6.2.4.

You should be aware that the default license supplied, NSX for vShield Endpoint, limits your deployment options to anti-virus offload capabilities only. There’s no full feature trial period as you’d find say with vSphere products. Apparently if you pull the right strings, VMware sales will supply you with a trial license unlocking the full feature set but I honestly did not bother trying. NSX is somewhat resource hungry and my lab is already over-subscribed as it is so, license or not, I’d still be limited in what I can do.  Memory-wise you’ll be needing at least 16GB for NSX Manager (it installs nevertheless with less but will keep reminding you to upgrade), 4GB for each NSX Controller and much more once you start rolling out the various components and services.

If you still want to have a go at it – especially if you’re lucky enough to have a valid product key – installing NSX isn’t really that hard but you need to do some reading and be familiar with a few networking concepts prior to diving in. Using the default license key supplied, I only got so far as installing and configuring NSX Manager. For instance, attempting to deploy an ESG, results in the following error message;

More to come in the Installing It section further down.

There is however a very good alternative if you lack a lab, product key or otherwise. VMware offers a number of free courses and labs which are in my opinion very well paced and worth pursuing. Here’s the link for anyone who’d like to give them a try.

I suggest completing the HOL-SDC-1603 and 1625 courses. These cover the basics and some of the more of advanced concepts. I did both and must say that they’re worth their weight in gold.

Figure 4 – VMware’s NSX online labs

Installing NSX

NSX is shipped as an OVA so it’s just a simple matter of importing it via vCenter Server as shown in Figure 5.

Figure 5 – Deploying the NSX appliance

There are a number of mandatory fields you need to fill in which include passwords for both the admin user and enable mode as well as network properties.

Figure 6 – NSX appliance properties

Once installed, you can log in with the admin account using either SSH (if you chose to enable it) or directly from the vm’s console window. Typing enable at the prompt, gives you access to the privileged mode exposing more commands and options. At this stage, however, you’re not even close to being done.

Figure 7 – Accessing NSX Manager from the vm’s console

Figure 8 – Enabling privileged mode from an SSH session

Once the NSX appliance has been installed and powered up, it’s time to set it up. You’ll do this using the appliance’s web interface (Figure 9). To log on, use the admin account and the password entered in the OVA’s properties section during the installation process.

Figure 9 – The NSX Manager Virtual Appliance’s web interface

The first step is to register vCenter Server with NSX Manager and configuring SSO. You should also make sure that the time on both the NSX Appliance and vCenter Server is in sync otherwise SSO configuration will fail. It’s best to use the same NTP source on both vCenter Server and NSX.

Figure 10 – Managing the appliance’s settings and vCenter Server registration

Figure 11 – Configuring the NTP source

Figure 12 – Configuring SSO and registering vCenter Server

Figure 13 – SSL certs security check when configuring SSO and registering vCenter Server

Once you’ve registered vCenter Server and configured SSO, close any instance of vSphere Web Client you might be using and log in back again. Under Home, you should see a new icon labelled Networking & Security. You’ll also find a similarly labeled menu item under Navigator (Figure 14).

Figure 14 – NSX Manager UI embedded in vSphere Web Client

From here onward it really all depends on what you want to achieve by deploying NSX. In general, you’ll;

• Deploy an NSX cluster + three controllers (Fig. 15)
• Prepare host clusters for NSX (Fig. 16)
• Configure VXLAN and Transport Zones (Fig. 17)
• Deploy one or more logical switches (Fig. 18)
• Deploy one or more Distributed Logical Routers (DLRs) and/or Edge Services Gateways (Fig. 19)
• Configure routing, firewalling, switching, etc. (Fig. 20)

Figure 15 – Deploying an NSX Controller	Figure 16 – Preparing a host for NSX	Figure 17 – Configuring VXLAN and Transport Zones
Figure 18 – Deploying logical switches	Figure 19 – Deploying ESX Edges	Figure 20 – Setting up firewall rules

The details and fine print are all covered here.

Conclusion

NSX is definitely an impressive piece of software suited for both converged and hyper-converged infrastructures. With NSX’s release, VMware’s SDDC ambitions come full circle with vSphere catering for compute virtualization, vSAN for SDS and NSX for SDN. That said, NSX is not for everyone and it certainly does not come cheap especially if you want to leverage the full feature set. Suffice is to say that the Enterprise edition nears the $7000 mark per processor.

There’s also a substantial learning curve and learning to use NSX is easier said than done. On top of that, if you’re not a networking guru – count me in – life can get a tad complicated. Then again, this should be taken as an impetus to further learning, standard procedure for anyone pursing this line of work.

[the_ad id=”4738″][the_ad id=”4796″]

The post VMware NSX – Abstracting the network layer appeared first on Altaro DOJO | VMware.