As you already have vCloud set up, you must have a vCloud Network and Security appliance (vCNS) deployed (formally known as vShield), and it should be configured to use your vCenter. For this recipe, you will need to be able to log in to the vCNS appliance with an administrator account.

Additionally, we need a VLAN on which the VXLANs will exist, and having a DHCP in that VLAN makes things easier. If no DHCP is accessible on this VLAN, you will need to provide one IP address per ESXi server in this VLAN.

The Segment ID you have to enter in step 14 in the How to do it… section is rather important, especially when you have multiple vCNS or vCloud installations (not multiple cells). Each of these installations should have a different range. If this is your first VXLAN installation, just use the range that is supplied in the steps.

Last but not least, you should have a multicast address range (see http://en.wikipedia.org/wiki/Multicast_address); this is best arranged with the network administrator. If you can't figure out what to use, the range given in the steps will work fine for a VXLAN that exists only in one location.

VXLANs were created by VMware together with Cisco. The idea was to solve the problems of modern data centers. Typically, these problems relate to the inflexibility of VLAN and Switching boundaries due to too much subnetting, IP, and VLAN management. The idea behind VXLANs is to create virtualized networking that is used on top of the common networking layer. They are in use just like the Network isolation-backed Network Pools we discussed in the other recipe; however, VXLANs have the benefit of being routable, flexible, and can transcend to different locations. This makes them extremely flexible and elegant to use.

VXLANs are actually like VLANs; the main difference is that VLANs (802.1q) have a 12-bit namespace whereas VXLANs have a 24-bit one, which increases the number of VLANs from 4,096 to more than 16 million unique namespaces.

VXLANs use layer 2 in layer 3 encapsulation. This means they use the Internet Protocol (IP, layer 3) to propagate the networks (from layer 2 upward), making them routable and far more flexible across network borders. One could envision VXLANs as a tunnel between two endpoints where additional networks exist.

VXLANs don't really exist in vCloud Director; VXLANs are defined in the vCNS appliance. vCNS creates the VXLAN tunnel endpoints and manages the VXLANs for the whole virtual infrastructure. For all this to happen, vCNS must install an agent on each ESXi server. This is done when you click on Finish, as explained in step 12 in the How to do it… section of this recipe. These agents provide the connection between VMs and the VXLANs. As the VXLAN packages are bigger than the common network packages, we have to adjust the MTU to avoid frame fragmentation. A safe setting is 1600. Each agent will be deployed and connected to a new vmknic. The IP for the vmknic is assigned via DHCP; however, this can be changed in vCNS for each ESXi server.

The Fail Over policy that you set on the Distributed Switches depends on what the physical switching architecture can do. If EtherChannels are set up, choose them. Link Aggregation Control Protocol (LACP) can be chosen either in active or passive mode. LACP in an active mode sends out packages to talk to LACP-activated devices, whereas in a passive mode it waits until a LACP-activated device talks to it. If in doubt about all of this, please involve your network team.

If you want to configure VXLANs with Static IPs for each vmknic, follow the ensuing procedure:

The following are some links for further reading: