On August 26th at VMworld 2013 VMware announced vSphere 5.5, the latest release of VMware’s industry-leading virtualization platform. This latest release includes a lot of improvements and many new features and capabilities. In an effort to try and get my head around all this exciting new “stuff” I decided to go through the what’s new paper and compile a brief summary (well, relatively brief anyway).
Here’s the list I came up with. I’m sure I missed some things, but this list should help you get started with learning about what’s new in vSphere 5.5.
The 2013 VMware Fling Contest is now open. Do you have an idea on how certain features or functionality could be improved upon? Can you think of an app that would make the life of a system administrator so much easier? Do you have a repetitive task that you wished you could have automated in your vSphere environment? Or a decision making tool for certain tasks? We are looking for you, our customers & users, to propose ideas for new VMware Flings. Our panel of judges will pick the winner. The submitter of the winning entry will win a free pass to VMworld 2014.
Last year we got over 120 submissions. We’re also planning to release a new Fling (Proactive DRS) at VMworld that was built based on last year’s winning winning idea.
People are madly registering for VMworld sessions as the 10 year anniversary of the conference opens in less than 2 weeks. I highly recommend this next session in the Extreme Performance Series Continue reading →
I am sorry that it took me a while to do this post on VXLAN. I was on summer vacation to India for three weeks and then got busy with the VMworld 2013 preparation. I hope you have registered for VMworld US conference. If you are interested in learning more about network virtualization please checkout the catalogue. I have couple of sessions in the networking track so hope to see you there.
After that shameless promotion about my sessions and before I jump in to explain the vMotion packet flow in VXLAN deployment, I want to address some of the questions that were raised in the comments section of the last blog. Please refer to the diagrams in the blog here.
This blog provides best practices for deploying vCloud Networking and Security 5.1 App Firewall. Thanks to Shubha Bheemarao, Ray Budavari and Rob Randell for helping me in compiling this.
Install vCloud Networking and Security Manager (aka vShield Manager) on a dedicated management cluster. Other components that get installed on this cluster are VMware vCenter Server, vCloud Director etc.
vCloud Networking and Security Manager should be run on an ESXi host that is not affected by downtime, such as frequent reboots or maintenance mode operations. Use vSphere HA to increase the resilience of the Manager. Thus, a cluster with more than one ESXi host is recommended.
Install vCloud Networking and Security App Firewall on all vSphere hosts within a cluster so that virtual machines remain protected as they migrate between vSphere hosts.
The management interfaces of vCloud Networking and Security components should be placed in a common network, such as the vSphere management network. Manager requires IP connectivity to the vCenter Server, ESXi host, and App Firewall virtual machine. Refer the KB article for the network port requirements for vCloud Networking and Security. It is a best practice to separate management traffic from the production traffic.
If the vCenter Server or vCenter Server database virtual machines are on the ESXi host on which you are installing App Firewall, migrate them to another host before installing App Firewall or exclude these virtual machines from vCloud Networking and Security App Firewall protection.
Install VMware Tools on each Virtual Machine. The vCloud Networking and Security Manager collects the IP addresses of virtual machines from VMware Tools on each virtual machine. Use App Firewall SpoofGuard to authorize the IP addresses reported by VMware Tools to prevent spoofing. With SpoofGuard use trust on first use to reduce the administrative overhead.
In this post I am going to describe how VTEPs learn about the virtual machines connected to the logical Layer 2 networks. The learning process is quite similar to a transparent bridge function. As transparent bridges learn based on the packets received on the bridge ports, the VTEP also learn based on the inner and outer header of the packets received.
Let’s take an example to illustrate the VTEP learning process.
I am happy to announce the availability of the VMware vCloud Networking and Security – DMZ Design and Deployment Guide. This paper highlights how securing a virtual DMZ environment using vCloud Networking and Security can be a strategic enabler to your organization as it helps you to reduce your capital expenditure and increase agility, while building a cloud ready, secure and scalable environment for business applications. The paper also highlights the different design approaches to securing business critical applications and enables you to make the choice that is most suited to your organization in the cloud journey. Further, it gives prescriptive configuration guidance to help you get started with the deployment of your preferred approach.
Get notification of these blogs and more vCloud Networking and Security information by following me on Twitter @vCloudNetSec.
In this post I am going to address a common question about the security and performance impact when multiple logical Layer 2 networks are mapped to one multicast group address.
As mentioned in earlier post here, vCloud Networking and Security (vCNS) Manager is responsible for mapping the logical Layer 2 networks to multicast group addresses. If you provide less number of multicast group addresses than the logical layer 2 networks, vCNS manager will assign the logical layer 2 networks to multicast addresses in a round robin fashion. For example, if there are 4 logical L2 networks (A1,A2,A3,A4) and 2 multicast group addresses (M1, M2), Logical networks A1 and A3 will be mapped to multicast group address M1 while A2 and A4 are mapped to M2.
I covered some basics on Multicast in the last blog entry here. Let’s now take a look how multicast is utilized in VXLAN deployments. During the configuration of VXLAN, it is required to allocate a multicast address range and also define the number of logical Layer 2 networks that will be created. For more details on the configuration steps please refer to the VXLAN Deployment Guide.
Ideally, one logical Layer 2 network is associated with one multicast group address. Sixteen million logical Layer 2 networks can be identified in VXLAN, using 24 bit field in the encapsulation header, but the multicast group addresses are limited (184.108.40.206 to 220.127.116.11). In some scenarios it might not be possible to have one to one mapping of a logical Layer 2 network to multicast group address. In such scenarios the vCloud Networking and Security Manager maps multiple logical networks to a multicast group address. After the discussion on the association of multicast group to logical network, let’s take a look at some details on the logical network properties.
VMware vCloud Networking and Security App Firewall is a hypervisor-based firewall that protects applications in the virtual datacenter from network-based attacks. In this blog, let’s look at how to micro-segment a VXLAN network to deploy a 3-tier application using vCloud Networking and Security 5.1 App Firewall.
Each application is deployed using a separate VXLAN network as shown below. To keep the diagram simple, only one application is shown below. The application has three tiers – web, app and db.