To understand the vNetwork components in detail, it is important to understand the vSphere datacenter architecture.

A typical vSphere datacenter comprises basic physical building blocks such as x86 computing servers, storage networks and arrays, IP networks, a management server, and desktop clients. The computing servers are industry standard x86 servers that run VMware ESXi Server on the bare metal hardware. The virtual machines are hosted on an ESXi Server. All resources needed by a virtual machine is provided by the ESXi Server. Each computing server is referred to as a standalone host in the virtual environment. A number of similarly configured x86 servers can be grouped together with connections to the same network and storage subsystems to provide a pool of resources in the virtual environment. Fiber Channel Storage Area Network or SAN arrays, Internet Small Computer Systems Interface or iSCSI SAN arrays, and Network-attached Arrays or NAS arrays are widely-used storage technologies supported vSphere to meet different datacenter storage needs. Sharing the storage arrays between groups of servers through the storage area networks allows the IT department to pool storage resources and provides more flexibility in provisioning storage resources for virtual machines. Each computing server can have multiple gigabit Ethernet network interface cards to provide high bandwidth and reliable networking to the entire datacenter. VMware vCenter provides a convenient single point of control to the datacenter. It runs on the top of Windows 2003 and 2008 Server 64-bit versions to provide many essential datacenter services such as access control, performance monitoring, and configuration. vCenter Server unifies resources from the individual computing servers to be shared among virtual machines in the entire datacenter. It accomplishes this by managing the assignment of virtual machines to computing servers and the assignment of resources to virtual machines within a given computing server based on the policies set by the system administrator. Computing servers continue to function even if vCenter Server becomes unreachable, for example, when the network is severed. Computing servers can be managed separately and continue to run the virtual machines assigned to them based on the resource assignment that was last set. After vCenter Server becomes reachable, it can manage the datacenter again. vSphere provides a selection of interfaces for managing datacenters and accessing virtual machines. Users can select the interface that best meets their needs. This includes VMware vSphere Client , vSphere Web Client through a Web browser, or terminal services such as Windows Terminal Services or Xterm. You will now learn how networking operates in the physical and virtual worlds. Historically, network administrators have owned the core, distribution, and access layers of a physical network in a physical computing environment. In a physical world, each server has a dedicated network cable plugged into a physical port on a switch.

The access layer provides a good place to monitor network traffic and interpose on network traffic if the need arises. For organizations that manage physical infrastructure with separate administrators for servers and networks, the switch port is the line of demarcation between servers and network. Virtualization moves the edge of the network or the access layer into the realm of the server as virtual machines access the network layer through virtual switches. These virtual switches are configured either independently on each ESXi host or through a centrally configured virtual switch. The vSphere infrastructure provides two types of virtual networking architecture, the standard virtual switch architecture and the distributed virtual switch architecture. Standard virtual switches manage virtual machines and networking at the host level. This networking architecture is supported on all versions of vSphere. Distributed virtual switch manages virtual machines and networking at the datacenter level. Distributed virtual switches are not available in all versions of vSphere. VMware recommends that all networks be set up or migrated using the distributed virtual switch architecture, since it simplifies the datacenter by centralizing network configuration in addition to providing a more robust feature set. Although the distributed network architecture is recommended for setting up virtual networks in vSphere 5.0, it is important to understand how the components of the standard virtual switch work so you can successfully either migrate components from this architecture to the distributed network architecture as required or support environments that only have standard virtual switches implemented. The next few screens will explain each type of networking architecture in detail. The components of the standard virtual switch architecture are configured at the host level. The standard virtual environment provides similar networking elements as those found actual physical switches. Like a physical machine, each virtual machine has one or more virtual network adapters or virtual network interface cards or vNICs. The operating system and applications communicate with the vNIC through a standard device driver or a VMware optimized device driver just as though the vNIC is a physical NIC. The vNIC has its own MAC address, can be configured with multiple IP addresses and responds to the standard Ethernet protocol exactly like a physical NIC would. Nonetheless, an outside agent can determine that it is communicating with a virtual machine only if it checks the six byte vendor identifier in the MAC address. A standard virtual switch, or also referred to as a vSwitch, operates just like a layer-2 physical switch. It maintains a MAC, a port forwarding table and performs three important functions. These include looking up each frame s destination MAC when it arrives, forwarding a frame to one or more ports for transmission, and avoiding unnecessary deliveries.

Each host server can have multiple standard virtual switches. You can create up to 127 virtual switches on each ESXi host. Each standard virtual switch has two sides to it. On one side of the virtual switch you have port groups. Port groups connect virtual machines to the standard virtual switch. On the other side of the standard virtual switch you have what are known as uplink ports. Uplink ports connect the standard virtual switch to physical Ethernet adapters which resides on the host. In turn, these physical Ethernet adapters connect to physical switches leading to the outside world. A standard virtual switch can connect its uplink ports to more than one physical Ethernet adapter to enable NIC teaming. With NIC teaming, two or more physical adapters can be used for load balancing or to provide failover capabilities in the event of a physical adapter hardware failure or a network outage. The virtual ports on a virtual standard switch provide logical connection points among and between virtual and physical devices. You can think of the virtual ports as virtual RJ-45 ports. Each virtual switch can have up to 1,016 virtual ports, with a limit of 4,096 ports on all virtual switches on a host. This system-wide limit includes eight reserved ports per standard virtual switch. Virtual Ethernet adapters or vNICs connect to virtual ports when you power on the virtual machine on which the adapters are configured, when you take an explicit action to connect the device, or when you migrate a virtual machine using VMware vSphere vMotion. A virtual Ethernet adapter updates the virtual switch port with the MAC filtering information when it is initialized and whenever it changes. A virtual port may ignore any requests from the virtual Ethernet adapter that would violate the Layer 2 security policy in effect for the port. For example, if MAC spoofing is blocked, the port drops any packets that violate this rule. Let us now discuss port groups. A port group is a unique concept in the virtual environment. A port group is a mechanism for setting policies that govern the network connected to it. Instead of connecting to a particular port on standard virtual switch, a virtual machine connects its vNIC to a port group. All virtual machines that connect to the same port group belong to the same network inside the virtual environment. Port groups can be configured to enforce a number of policies that provide enhanced network security, network segmentation, better performance, higher availability, and traffic management. Just like port groups that can be created to handle the virtual machine traffic, VMkernel connection type or VMkernel Port can also be created to provide network connectivity for the host and handling VMware vMotion, IP storage, and Fault Tolerance. Moving a virtual machine from one host to another is called migration. Using vMotion you can migrate powered on virtual machines with no downtime. Please note that your VMkernel networking stack must be set up properly to accommodate vMotion.

IP storage refers to any form of storage that uses TCP/IP network ESXi. Because these storage types are network based, therefore, they can use the same VMkernel interface and port group. The main drawback of a standard virtual switch is that every ESXi host should have separate vSwitches configured on it. That means that virtual local area networks or VLAN, security policies, and teaming policies have to be individually configured on each and every ESXi host. If a policy needs to change, the vSphere administrator must change that policy on every host. While vCenter Server does allow the administrator to centrally manage the ESXi hosts, the changes to standard virtual switches still have to be done on each ESXi host. Another drawback is that when a virtual machine is migrated with VMware vMotion, the networking state of the virtual machine gets reset. This makes network monitoring and troubleshooting a more complex task in a virtual environment. Distributed virtual switches or dvSwitch are configured and managed using vCenter Server. Distributed virtual switches are the recommended architecture to use when setting up a vNetwork. A distributed virtual switch acts as a single virtual switch across all associated hosts. This allows virtual machines to maintain a consistent network configuration as they migrate across hosts. Like a standard virtual switch, a distributed virtual switch is a layer 2 network mechanism for virtual machines. A distributed virtual switch can route traffic internally between virtual machines or link to an external network. Distributed switches exist across two or more clustered ESXi hosts. vCenter owns the configuration of distributed virtual switches, and the configuration is consistent across all hosts. The uplink ports on the distributed virtual switch connects to uplink ports on hidden standard virtual switches. The hidden standard virtual switch uplink ports connect to physical NICs, which then connect to physical switches in the outside world. Be careful not to confuse a distributed virtual switch with a single switch spanning across several hosts. Two virtual machines on different hosts can communicate with each other only if both virtual machines have uplinks in the same broadcast domain with each other. Each distributed switch includes distributed ports. A distributed port is a port on a vSphere distributed switch that connects to the VMkernel or to a virtual machine's network adapter. vCenter Server stores the state of distributed ports in the vCenter Server database, so networking statistics and policies migrate with virtual machines when moved across hosts. Migrating the state of a distributed port with vMotion is important when implementing statedependent features, such as inline intrusion detection systems, firewalls, and third-party virtual switches. Distributed port groups perform the same functions as port groups in standard virtual switches. They provide a way to logically group distributed ports to simplify configuration and they inherit all distributed switch properties. A distributed port groups does not constitute the means to segregate traffic within the distributed switch unless you use private VLANs.

Within a distributed virtual switch, the control and I/O planes are separate. The control plane resides in and is owned by vCenter Server. The control plane is responsible for configuring distributed switches, distributed port groups, distributed ports, uplinks, and NIC teaming. The control plane also coordinates the migration of the ports and is responsible for the switch configuration. For example, in the case of a conflict in the assignment of a distributed port (say, because a virtual machine and its template are powered on), the control plane is responsible for deciding what to do. The I/O Plane is implemented as a hidden standard virtual switch inside the VMkernel of each ESXi host. The I/O plane manages the actual I/O hardware on the host and is responsible for forwarding packets. The diagram on the screen shows the components of the I/O plane of a distributed virtual switch. On each host, an I/O plane agent runs as a VMkernel process and is responsible for communicating between the control and the I/O planes. I/O filters are attached to the I/O chains connecting the vNICs to the distributed ports and the distributed ports to the uplinks. vNetwork Appliance APIs make it possible to define custom filters and apply them to the I/O chains. The APIs also provide the means to preserve filtering information for the virtual machine connected to each port, even after a vMotion migration. Inside the I/O plane, the forwarding engine decides how to forward packets to other distributed ports. The engine can forward the packets towards other virtual machines on the same distributed switch or to an uplink, requiring it to make NIC teaming decisions. Forwarding functions can also be customized using the vNetwork Appliance APIs. Network configuration at the datacenter level offers several advantages. First, it simplifies datacenter setup and administration by centralizing network configuration. For example, adding a new host to a cluster and making it vMotion compatible is much easier. Second, distributed ports migrate with their clients. So, when you migrate a virtual machine with vMotion, the distributed port statistics and policies move with the virtual machine, thus simplifying debugging and troubleshooting. Finally, enterprise networking vendors can provide proprietary networking interfaces to monitor, control, and manage virtual networks. vNetwork Appliance APIs allow third-party developers to create distributed switch solutions for use in a vSphere datacenter. Third-party solutions allow network administrators to extend existing network operations and management into the vSphere datacenter. This diagram shows the basic way a third-party solution plugs in to the vNetwork architecture. The Custom Control Plane is implemented outside of vCenter Server, for example it may be implemented as a virtual appliance. The vSphere Client includes a plug-in to provide a management interface.

vCenter Server includes an extension to handle the communication with the control plane. On the host, a custom I/O plane agent replaces the standard I/O plane agent and the I/O plane itself may be replaced for customization of forwarding and filtering. An example of a third-party switch that leverages the vNetwork APIs is the Cisco Nexus 1000V. Network administrators can use this solution in place of the distributed switch to extend vCenter Server to manage Cisco Nexus and Cisco Catalyst switches. This concludes the VMware vSphere Network: An Overview module. In summary - A typical vSphere datacenter comprises of basic physical building blocks such as x86 computing servers, storage networks and arrays, IP networks, a management server, and desktop clients. - The components of the standard virtual switch architecture are configured at the host level. The standard virtual switch provides similar networking capabilities as its physical counterparts in the real world. - vCenter Server owns and stores the state of distributed port in its database, so networking statistics and policies migrate with virtual machines when moved from host to host. This capability is important to supporting state-dependent

features such as inline intrusion detection systems, firewalls, and third-party virtual switches. - vNetwork Appliance APIs allow third-party developers to create distributed switch solutions for use in a vSphere datacenter. Third-party solutions allow network administrators to extend existing network operations and management into the vSphere datacenter. Now that you have completed this module, feel free to review it until you are ready to start the next module. When you are ready to proceed, close this browser window to return to the course contents page. A vNetwork provides different servicesto the host and virtual machines. You can enable two types of network services in ESXi, VMkernel and virtual machines. The first type connects VMkernel services, such as NFS, iSCSI, or VMware vSphere vMotion to the physical network. The second type connects virtual machines to the physical network. vNetwork comprises of two types of networking architecture, the standard virtual switch and the distributed virtual switch. The next few screens explain how to create and configure each type. Setting up a networking environment using standard virtual switches can be done using the Configuration tab in the Hosts and Clusters view in vSphere Client. Port groups for virtual machine networking or networking services, such as vMotion and iSCSI networking are configured using Add Network Wizard. New standard virtual switches can be created during the port group creation process, or you can connect your new port group to an already existing standard virtual switch. A virtual machine is connected to a virtual network by assigning the virtual machine s NIC to that network s port group.

This demonstration will show you the steps for creating a standard vSwitch. It will also show you the steps for creating port groups. When you are ready to begin the demonstration, click the Play button.

In this demonstration, we will see how to create a standard virtual switch and port groups.

- After logging in to VMware vSphere Client, we will navigate to the Networking view from the vCenter Server inventory. - Now, we will select a datacenter. For the purpose of this demo, we have used the datacenter named My vPod . - Next, we will click the Networks tab. - We will right-click the datacenter and select New vSphere Distributed Switch. Alternately, we can click the New vNetwork Distributed Switch icon in the toolbar. - The Create vSphere Distributed Switch dialog box is displayed. Now, we will select the appropriate

vSphere Distributed Switch Version. For the purpose of this demo, we will use vSphere Distributed Switch Version: 5.0.0. - We will click Next. - Then, we need to enter a display name for the switch and specify the maximum number of physical adapters per host. For the demo purpose, we will keep the default values. - Then, we will click Next. - We can either add hosts and their physical network adapters to the new vSphere distributed switch now or later. Note: We do not add hosts here. We will select Add later. - Then, we will click Next. - We can now choose to Automatically create a default port group. For the purpose of this demo, we will leave this option unchecked and will add the port group later.

- We will click Finish. - A new distributed switch appears under the datacenter with the default name dvSwitch. - To add a port group, we will select the dvSwitch. - We will then right-click the dvSwitch and click New Port Group. - The Create Distributed Port Group wizard appears. - We will provide a name for the port group and provide the number of ports. For the demo purpose, we will use the default name, dvPortGroup. Note that if you are using VLAN, you can provide the VLAN ID here. - We will click Next. - We will now verify the settings for the new port group. - Finally, we will click Finish.

In this demonstration, we saw how to create a distributed virtual switch and port groups. The virtual machine network connections on a standard virtual switch allow virtual machines to access the network. The Add Network Wizard guides you through the tasks required to create a virtual network to which virtual machines can connect. These tasks include choosing

the connection type, adding the virtual network to a new or an existing standard virtual switch, and configuring the connection settings for the network label and the VLAN ID. When a virtual machine is created, you can select the networks that you want to connect to and their options. You can select the number of NICs you want to connect to, the names of the networks, and whether you want to connect to them at power on. The Network drop-down menu lists the port groups that are configured for virtual machine use on the host. If no virtual machine port groups are configured, a warning dialog box appears, and you are not allowed to configure any virtual network cards. Notice the Adapter field on the image. Your selection here, and whether you install VMware Tools, determines the virtual adapter for the virtual machine. After the virtual machine is created, you configure the IP setting in the guest operating systems for each virtual NIC configured for the virtual machine. In the example displayed on the screen, the Microsoft Windows Virtual Machines TCP/IP properties are configured in the Windows operating system. Once the network adapter has been created for the virtual machine, you can edit the connections of the virtual machine from the Virtual Machine Properties dialog in vSphere Client. VMkernel networking is used to provide network access to the host and to handle vMotion, IP Storage, and VMware Fault Tolerance. One of the uses for a VMkernel port is vMotion. vMotion uses VMkernel ports to migrate powered on virtual machines from one ESXi host to another. Dedicated Gigabit-switched paths are configured between ESXi hosts and this is considered a vMotion Network. The virtual machine can then be migrated from one host to another with no downtime. vMotion requires a Gigabit Ethernet or GigE network between all vMotion-enabled hosts. In addition to providing support for vMotion, the VMkernel TCP/IP stack provides networking support for software iSCSI and for access to the NFS datastores. If you have more than two NICs for iSCSI, you can configure iSCSI multipathing. ESXi supports only NFS version 3 over TCP/IP. Distributed virtual switches ease the management burden of every host virtual switch configuration by treating the network as an aggregate resource. In this configuration, individual host-level virtual switches are abstracted into a single large vNetwork distributed virtual switch that spans multiple hosts at the datacenter level. Although VMware supports standard virtual switches, it is a best practice and recommended that the distributed virtual switch architecture be used for all virtual networking purposes, including the virtual machine connections and the VMkernel connections to the physical network for VMkernel services such

as NFS, iSCSI, or vMotion. vSphere Distributed switches 5.0 only supports ESXi 5.0 and later versions. With a standard virtual switch, a separate configuration in a separate management panel is required to maintain each ESXi host s network configuration. So in the example on the screen, in order for an administrator to view the network configuration of the datacenter, the administrator would have to view the network configuration tab of each separate ESXi host. With a distributed virtual switch, the administrator only has to view one management panel to view the network configuration for the entire datacenter. There are different steps involved in creating a distributed switch. To begin, create a distributed virtual switch in vSphere Client using the Create vNetwork Distributed Switch wizard. Then use the same wizard to add hosts or create a distributed port group. Next, configure virtual network adapters to handle network services over the distributed switch. You can configure VMkernel network adapters for a host through an associated distributed virtual switch, either by creating new virtual adapters or by migrating existing virtual adapters on the host to the vNetwork distributed virtual switch. Finally, connect virtual machine NICs to distributed virtual port groups. You can connect virtual machine NICs through individual machine NIC configuration or by migrating virtual machine networking from the distributed virtual switch itself. This demonstration will show you the steps for creating a Distributed Virtual Switch and port groups. When you are ready to begin the demonstration, click the Play button.

In this demonstration, we will see how to create a distributed virtual switch and port groups.

- After logging in to VMware vSphere Client, we will navigate to the Networking view from the vCenter Server inventory. - Now, we will select a datacenter. For the purpose of this demo, we have used the datacenter named My vPod . - Next, we will click the

Networks tab. - We will right-click the datacenter and select New vSphere Distributed Switch. - Alternately, we can click the New vNetwork Distributed Switch icon in the toolbar. - The Create vSphere Distributed Switch dialog box is displayed. Now, we will select the appropriate vSphere Distributed Switch Version. For the purpose of this demo, we will use vSphere Distributed Switch Version: 5.0.0. - We will click Next. - Then, we need to enter a display name for the switch and specify the maximum number of physical adapters per host. For the demo purpose, we will keep the default values. - Then, we will click Next. - We can either add hosts and their physical network adapters to the new vSphere distributed switch now or later. Note:

We do not add hosts here. We will select Add later. - Then, we will click Next. - We can now choose to Automatically create a default port group. For the purpose of this demo, we will uncheck this option to add the port group later. - We will click Finish. - A new distributed switch appears under the datacenter with the default name dvSwitch. - To add a port group, we will select the dvSwitch. - We will then right-click the dvSwitch and click New Port Group. - The Create Distributed Port Group wizard appears. - We will provide a name for the port group and provide the number of ports. For the demo purpose, we will use the default name, dvPortGroup. Note that if you are using VLAN, you can provide the VLAN ID here. - We will click Next. - We will now verify the settings

for the new port group. - Finally, we will click Finish.

In this demonstration, we saw how to create a distributed virtual switch and port groups. It is possible to migrate a group of virtual machines from standard virtual switches on the host to a distributed virtual switch. In this example, the virtual machines on Host2 are all connected to the production port group. On the distributed virtual switch, a port group that virtual machines will migrate to is created. Then the Migrate Distributed Virtual Machine Networking wizard is used to move the virtual machines from the standard to the distributed switch.

This demonstration will show you the steps to migrate virtual machines from a Standard vSwitch to a Distributed vSwitch.

When you are ready to begin the demonstration, click the Play button.

In this demonstration, we will see how to migrate virtual machines from a standard virtual switch to a distributed virtual switch.

- After logging in to VMware vSphere Client, we will navigate to the Networking view from the vCenter Server inventory. - Then, we will select the distributed switch where we want our virtual machines to migrate to. - We will right-click the distributed switch and select Migrate Virtual Machine

Networking. - The Migrate Virtual Machine Networking wizard appears. - Now, we need to select the source and destination network for the virtual machine network adapters to migrate. For the purpose of this demo, we will migrate all virtual machines from VM Network to dvPortGroup dvSwitch. - First, we will select VM Network from the drop-down menu under Source Network. - The dvPortGroup is selected by default in the Destination Network. We will keep the default selection. - Remember to make your selection based on your setup. - We will click Next. - Next, we will select All Virtual Machines. - We will click Next. - We will review the summary and click Finish to start migrating the selected virtual machine network

adapters. - Now, we will click the Virtual Machines tab. - We can now see the migrated virtual machines.

In this demonstration, we saw how to migrate virtual machines from a standard virtual switch to a distributed virtual switch. A VMkernel port on a distributed virtual switch works similar to a standard virtual switch. The VMkernel port is used by VMkernel to provide services like vMotion or access to storage such as NFS or Software iSCSI. This demonstration will show you the steps to create a VMkernel network adapter on a vSphere distributed switch. When you are ready to begin the demonstration, click the Play button.

In this demonstration, we will see how to create a VMkernel network adapter on a vSphere distributed virtual switch.

- After logging in to VMware vSphere Client, we will navigate to the Hosts and Clusters view from the vCenter Server inventory. - We will select one of the hosts in the Inventory pane. - Then, we will click the Configuration tab. - Next, we will click Networking under the Hardware panel.

- Now, we will click the vSphere Distributed Switch view. - Next, we will click the Manage Virtual Adapters link. - We will click Add. - Then, we will keep the default selection of New virtual adapter on the Creation Type screen. - We will click Next. - On the Virtual Adapter Type screen, VMkernel is selected. Click Next. - We will choose a distributed port or distributed port group connection for the virtual adapter. For the purpose of the demo, we have selected dvPortGroup. - In this demo, we are creating the virtual adapter for vMotion, so we will select the Use this virtual adapter for vMotion checkbox so that this virtual adapter can advertise itself to other ESXi hosts as network connection where vMotion traffic is sent. Note that you

can enable this property for only one vMotion and IP storage port group for each host. If this property is not enabled for any port group, migration with vMotion to this host is not possible. - We will click Next. - Now, we will specify the VMkernal IP Settings. - We will click Edit to set the VMkernel default gateway for the VMkernel services, such as vMotion, NAS, and iSCSI. Note that we will keep the default gateway. - On the Routing tab, we will use the existing default gateway information for VMkernel. - On the DNS Configuration tab, the name of the host is entered by default. The DNS server addresses and domain that were specified during installation are also preselected. - The Static IP settings is the default. Do not use routing with software iSCSI Multipathing

configurations or dependent hardware iSCSI adapters. We will click OK. - Here, we will enter the static IP address and its Subnet Mask. - We will click Next. - Further, we will click Finish to confirm the new virtual adapter configuration. - Finally, we will click Close. - Under dvSwitch in the Networking section, we can see the newly created adapter as VMkernal Ports.

In this demonstration, we saw how to create a VMkernel network adapter on a vSphere distributed virtual switch. This demonstration will show you the steps to create a VMkernel network adapter on a vSphere distributed switch. When you are ready to begin the demonstration, click the Play button.

In this demonstration, we will see how to create a VMkernel network adapter on a vSphere distributed virtual switch.

- After logging in to VMware vSphere Client, we will navigate to the Hosts and Clusters view from the vCenter Server inventory. - We will select one of the

hosts in the Inventory pane. - Then, we will click the Configuration tab. - Next, we will click Networking under the Hardware panel. - Now, we will click the vSphere Distributed Switch view. - Next, we will click the Manage Virtual Adapters link. - We will click Add. - Then, we will keep the default selection of New virtual adapter on the Creation Type screen. - We will click Next. - On the Virtual Adapter Type screen, VMkernel is selected. Click Next. - We will choose a distributed port or distributed port group connection for the virtual adapter. For the purpose of the demo, we have selected dvPortGroup. - In this demo, we are creating the virtual adapter for vMotion, so we will select the Use this

virtual adapter for vMotion checkbox so that this virtual adapter can advertise itself to other ESXi hosts as network connection where vMotion traffic is sent. Note that you can enable this property for only one vMotion and IP storage port group for each host. If this property is not enabled for any port group, migration with vMotion to this host is not possible. - We will click Next. - Now, we will specify the VMkernal IP Settings. - We will click Edit to set the VMkernel default gateway for the VMkernel services, such as vMotion, NAS, and iSCSI. Note that we will keep the default gateway. - On the Routing tab, we will use the existing default gateway information for VMkernel. - On the DNS Configuration tab, the name of the host is entered by default. The DNS server

addresses and domain that were specified during installation are also preselected. - The Static IP settings is the default. Do not use routing with software iSCSI Multipathing configurations or dependent hardware iSCSI adapters. We will click OK. - Here, we will enter the static IP address and its Subnet Mask. - We will click Next. - Further, we will click Finish to confirm the new virtual adapter configuration. - Finally, we will click Close. - Under dvSwitch in the Networking section, we can see the newly created adapter as VMkernal Ports.

In this demonstration, we saw how to create a VMkernel network adapter on a vSphere distributed virtual switch. vSphere 5.0 supports both Internet Protocol version 4 or IPv4 and Internet Protocol version 6 or IPv6 environments. IPv6 has been designated by the Internet Engineering Task Force as the successor to IPv4. The adoption of IPv6, both as a standalone protocol and in a mixed environment with IPv4, is increasing. Most notably, the United States Federal Government requires that all new purchases include IPv6 support. The most obvious difference between IPv4 and IPv6 is the address length. IPv6 uses 128-bit addresses rather than the 32-bit addresses used by IPv4. This combats the problem of address exhaustion that is present with IPv4 and eliminates the need for network address translation.

Other notable differences include link-local addresses that appear as the interface is initialized, addresses that are set by router advertisements, and the ability to have multiple IPv6 addresses on an interface. IPv6 is disabled by default. An IPv6-specific configuration in vSphere involves providing IPv6 addresses, either by entering static addresses or by using DHCP for all relevant vSphere networking interfaces. IPv6 addresses can also be configured using stateless autoconfiguration sent by router advertisement. IPv6 support is configured at the host level, and it is disabled by default. To enable or disable IPv6 support through the vSphere client, you must adhere to certain steps. To begin, select the Hosts and Clusters view from the vSphere Client Home page. Next, select the host and click the Configuration tab. Then, click the Networking link under Hardware. In the vSphere Standard Switch view, click the Properties link. Next, select Enable IPv6 support on the host system, and click OK. Finally, reboot the host. You can also configure IPv6 support through the command line. In either case, you must reboot the host for the change to take effect. Enabling IPv6 on the host does not disable IPv4. IPv4 and IPv6 can co-exist without any problems. You can enable IPv6 support when you create or edit a virtual adapter to connect to either a standard or distributed virtual switch. After IPv6 is enabled you have the option to specify IPv4 or IPv6 addresses. There are three ways to assign an IPv6 address to an adapter. The first way is automatically, using DHCP. The second way is also automatically, but using the IPv6 stateless autoconfiguration. This option automatically generates a Link-Local IP address assigned to communicate with potential routers in the same link, for example through advertisement. The third way is by entering static IPv6 addresses. You also have the option to set a unique default gateway. This concludes the vNetwork: Configuring Virtual Switches module. In summary:

- Setting up a networking environment using standard virtual switches can be done on the Configuration tab of the host view in vSphere Client.

- Distributed virtual switches ease the management burden of every host virtual switch configuration by treating the network as an aggregate resource. In this configuration, individual host-level virtual switches are abstracted into a single large vNetwork distributed virtual switch that spans multiple hosts at the datacenter level. - In a standard virtual switch configuration, a separate configuration in a separate management panel is required to maintain each ESXi host s network configuration. In a distributed virtual switch configuration, the administrator would only have to view one management panel to view the network configuration for the entire datacenter. Now that you have completed this module, feel free to review it until you are ready to start the next module. When you are ready to proceed, close this browser window to return to the course contents page.

Private VLANs support broader compatibility with existing networking environments using the private VLAN technology. Private VLANs enable users to restrict communication between virtual machines on the same VLAN or network segment, significantly reducing the number of subnets required for certain network configurations. The next few screens will explain how to set up and configure private VLANs. Private VLANs or PVLANs allow you to isolate traffic between virtual machines in the same VLAN. This allows PVLANs to provide additional security between virtual machines on the same subnet without exhausting the VLAN number space. PVLANs are useful on a DMZ where the server needs to be available to external connections and possibly internal connections, but rarely needs to communicate with the other servers on the DMZ. A PVLAN can be configured in a way that allows the servers to communicate only with the default gateway on the DMZ, denying communication between the servers. If one of the servers is compromised by a hacker, or infected with a virus, the other servers on the DMZ are safe. The basic concept behind PVLANs is to divide an existing VLAN, now referred to as the primary PVLAN, into one or more segments. These segments are called secondary PVLANs. A PVLAN is identified by its primary PVLAN ID. A primary PVLAN ID can have multiple secondary PVLAN IDs associated with it. Primary PVLANs are promiscuous, so virtual machines on a promiscuous PVLAN are reachable by and can reach any node in the same promiscuous PVLAN, as well as any node in the primary PVLAN. Ports on secondary PVLANs can be configured as either isolated or community. Virtual machines on isolated ports communicate only with virtual machines on promiscuous ports, whereas virtual machines on community ports communicate with both promiscuous ports and other ports on the same secondary PVLAN. Virtual machines in a promiscuous private VLAN are reachable by and can reach any node in the same promiscuous private VLAN, as well as any node in the primary PVLAN. In the example depicted on the screen, virtual machines E and F are in the promiscuous private VLAN 5, so all virtual machines communicate with each other as well as with any nodes in the primary private VLAN 5. Virtual machines in an isolated private VLAN cannot communicate with other virtual machines except those in the promiscuous private VLAN. In this example, virtual machines C and D are in isolated private VLAN 155, so they cannot communicate with each other. However, virtual machines C and D can communicate with virtual machines E and F. Virtual machines in a community private VLAN can communicate with each other and with the virtual machines in the promiscuous private VLAN , but not with any other virtual machine. In this example, virtual machines A and B can communicate with each other and with E and F because they are in the promiscuous private VLAN. However, they cannot communicate with C or D because they are not in the community private VLAN. Network packets originating from a community are tagged with the secondary PVLAN ID as it transverses the network. There are a couple of things to note about how vNetwork implements private VLANs. First, vNetwork does not encapsulate traffic inside private VLANs. In other words, there is no

secondary private VLAN encapsulated inside a primary private VLAN packet. Also, traffic between virtual machines on the same private VLAN, but on different ESXi hosts, moves through the physical switch. Therefore, the physical switch must be private VLAN-aware and configured appropriately so that traffic in the secondary private VLAN can reach its destination. The Creating a Private VLAN demonstration will show you the steps to create a private VLAN. When you are ready to begin the demonstration, click the Play button.

In this demonstration, we will see how to create a private VLAN.

- After logging in to VMware vSphere Client, we will navigate to the Networking view from the vCenter Server Inventory. - We will right-click the distributed switch in the inventory pane. For the purpose of this demo, we will select Production dvSwitch. - Now, we will select Edit Settings. - Then, we will select the Private VLAN tab. - Here, we can see two sections, Primary private VLAN ID and Secondary private VLAN ID. - Primary VLANs are Promiscuous, so that ports on a private VLAN

can communicate with ports configured as the primary VLAN. - Ports on a secondary VLAN can be either Isolated or Community. Isolated ports communicate only with Promiscuous ports while Community ports communicate with both Promiscuous ports and other ports on the same secondary VLAN. - To create a private VLAN, we will click [Enter a Private VLAN ID here] under Primary private VLAN ID. - We will enter the number of the primary private VLAN as 100. Note that you can choose any number between 1 -4094. - Now, we will select the primary private VLAN that we just added. - The Primary private VLAN appears under Secondary private VLAN ID. - Now, under Secondary private VLAN ID, we will add VLAN IDs corresponding to the primary

VLAN. - For each VLAN, we will create two secondary VLANs. In the demo, for VLAN with VLAN ID 100, we have created two secondary VLANs with VLAN ID 101 and 102. - After entering the VLAN ID, we will select whether they should be Isolated or Community. We need to click the drop down next to the VLAN ID and select Isolated for 101 and Community for 102. For the purpose of this demo, we have selected the port types as Isolated and Community respectively. - Finally, we will click OK to close the wizard. In this demonstration, we saw how to create a private VLAN. Virtual machines in a promiscuous private VLAN are reachable by and can reach any node in the same promiscuous private VLAN, as well as any node in the primary PVLAN. In the example depicted on the screen, virtual machines E and F are in the promiscuous private VLAN 5, so all virtual machines communicate with each other as well as with any nodes in the primary private VLAN 5. Virtual machines in an isolated private VLAN cannot communicate with other virtual machines except those in the promiscuous private VLAN. In this example, virtual machines C and D are in isolated private VLAN 155, so they cannot communicate with each other. However, virtual machines C and D can communicate with virtual machines E and F. Virtual machines in a community private VLAN can communicate with each other and with the virtual machines in the promiscuous private VLAN , but not with any other virtual machine. In

this example, virtual machines A and B can communicate with each other and with E and F because they are in the promiscuous private VLAN. However, they cannot communicate with C or D because they are not in the community private VLAN. Network packets originating from a community are tagged with the secondary PVLAN ID as it transverses the network. There are a couple of things to note about how vNetwork implements private VLANs. First, vNetwork does not encapsulate traffic inside private VLANs. In other words, there is no secondary private VLAN encapsulated inside a primary private VLAN packet. Also, traffic between virtual machines on the same private VLAN, but on different ESXi hosts, moves through the physical switch. Therefore, the physical switch must be private VLAN-aware and configured appropriately so that traffic in the secondary private VLAN can reach its destination. You will now learn about the load balancing and failover policies and how they are configured. Load balancing and failover policies allow you to determine how network traffic is distributed between adapters and how to re-route traffic in the event of a failure. You can edit your load balancing and failover policies by configuring the load balancing policy, failover detection, and network adapter order. Load balancing and failover policies can be controlled at either the standard virtual switch level or at the port group level on a distributed virtual switch and can be set in the vSphere Client. Although teaming can be configured on a standard virtual switch, load-based teaming is only available with distributed virtual switches. Initially, ports are assigned the way they are assigned in source port-based load balancing. The algorithm in load-based teaming regularly checks the load of all teaming NICs. If one NIC gets overloaded while another has bandwidth available, the distributed virtual switch reassigns the port-NIC mapping to reach a balanced status. Until the next check is performed, the mapping maintains a stable state. The settings for load balancing enable you to specify how a physical uplink should be selected by the VMkernel. The next few screens will take you through different load balancing policies. These include route based on the originating port ID and route based on IP or MAC hash. Routing traffic based on the originating port ID balances the load based on the virtual port where the traffic enters the vSwitch or dvSwitch. Port ID-based assignments use fixed assignments. In some cases, multiple heavy loaded virtual machines are connected to the same pNIC and the load across the pNICs is not balanced. The image on the screen shows that pNIC1 is connected to two virtual machines with heavier load and is overloaded, whereas pNIC0 has only one virtual machine with a low load.

Route based on IP hash chooses an uplink based on a hash of the source and destination IP addresses of each packet. Evenness of traffic distribution depends on the number of TCP/IP sessions to unique destinations. When using route based on source MAC hash option on a drop-down menu in the vSphere Client, an uplink is selected based on the hash from the source Ethernet adapter. When you use this setting, traffic from a given virtual Ethernet adapter is consistently sent to the same physical adapter unless there is a failover to another adapter in the NIC team. The replies are received on the same physical adapter as the physical switch learns the port association. This setting provides an even distribution of traffic if the number of virtual Ethernet adapters is greater than the number of physical adapters. A given virtual machine cannot use more than one physical Ethernet adapter at any given time unless it uses multiple source MAC addresses for traffic it sends. Route based on IP hash chooses an uplink based on a hash of the source and destination IP addresses of each packet. Evenness of traffic distribution depends on the number of TCP/IP sessions to unique destinations. When using route based on source MAC hash option on a drop-down menu in the vSphere Client, an uplink is selected based on the hash from the source Ethernet adapter. When you use this setting, traffic from a given virtual Ethernet adapter is consistently sent to the same physical adapter unless there is a failover to another adapter in the NIC team. The replies are received on the same physical adapter as the physical switch learns the port association. This setting provides an even distribution of traffic if the number of virtual Ethernet adapters is greater than the number of physical adapters. A given virtual machine cannot use more than one physical Ethernet adapter at any given time unless it uses multiple source MAC addresses for traffic it sends. Failover policies determine the method to be used for failover detection and how traffic is rerouted in the event of a physical adapter failure on the host. The failover policies that can be set are network failure detection, notify switches, failback, and failover order. The next few screens will explain each policy in detail. Network failover detection specifies the method to use for failover detection. The policy can be set to either the Link Status only option or the Beacon Probing option within the vSphere Client.

When the policy is set to Link Status only, failover detection will rely solely on the link status that the network adapter provides. This option detects failures, such as cable pulls and physical switch power failures. However, it does not detect configuration errors, such as a physical switch port being blocked by spanning tree protocol or misconfigured to the wrong VLAN or cable pulls on the other side of a physical switch.

The Beaconing option sends out and listens for beacon probes on all NICs in the team and uses this information, along with link status, to determine link failure. This option detects many failures that are not detected by Link Status only alone. When you use the notify switches policy, you must specify how the VMkernel communicates with the physical switches in the event of a failover. The notify switches can be set to either Yes or No. If you select Yes, whenever a virtual Ethernet adapter is connected to the vSwitch or dvSwitch or whenever that virtual Ethernet adapter s traffic is routed over a different physical Ethernet adapter in the team due to a failover event, a notification is sent out over the network to update the lookup tables on physical switches. In almost all cases, this is desirable for the lowest latency when a failover occurs. By default, NIC teaming applies a failback policy. This means that if a physical Ethernet adapter that had failed comes back online, the adapter is returned to active duty immediately, displacing the standby adapter that took over its slot. This policy is in effect when the Rolling Failover setting is set to No. If the primary physical adapter experiences intermittent failures, this setting can lead to frequent changes in the adapter in use. Another approach is to set Rolling Failover to Yes. With this setting, a failed adapter is left inactive even after recovery until another currently active adapter fails, requiring replacement. Please note that the Failover Order policy can be set in the vSphere Client. You can use the Failover Order policy setting to specify how to distribute the work load for the physical Ethernet adapters on the host. You can place some adapters in active use, designate a second group as standby adapters for use in failover situations, and designate other adapters as unused, excluding them from NIC Teaming. Please note that the Failover Order policy can be set for vSphere Client. You will now learn about network I/O control and its architecture.

In environments that use 1 Gigabit Ethernet or GigE physical uplinks, it is not uncommon to see multiple physical adapters dedicated to certain traffic types.

1 GigE is rapidly being replaced by 10 GigE networks. While it provides an ample bandwidth for all the traffic, it creates a new challenge. Different kind of traffic, which was limited to the bandwidth of a single 1 GigE can now use up to 10 GigE. So, for optimum utilization of 10 GigE link, there has to be a way to prioritize the network traffic by traffic flows. Prioritizing traffic will ensure that latency sensitive and critical traffic flows can access the bandwidth they require.

Network I/O control provides control to converge different kinds of traffic flows on a single pipe. It provides control to the administrator to ensure predictable network performance when multiple traffic types are flowing in the same pipe. Network I/O control enables the convergence of diverse workloads on a single networking pipe. It provides sufficient controls to the vSphere administrator in the form of limits and shares parameters to enable and ensure predictable network performance when multiple traffic types contend for the same physical network resources.

Network I/O control provides its users with different features. These include isolation, shares, and limits.

The next few screens will explain each of the features in detail. Isolation ensures traffic isolation so that a given flow will never be allowed to dominate over others, thus preventing drops and undesired jitter. When network I/O control is enabled, distributed switch traffic is divided into the following predefined network resource pools: VMware Fault Tolerance traffic, iSCSI traffic, management traffic, NFS traffic, virtual machine traffic, vMotion traffic vSphere Replication or VR traffic. Shares allow a flexible networking capacity partitioning to help users in dealing with over commitment when flows compete aggressively for the same resources. Network I/O control uses shares to specify the relative importance of traffic flows. The system administrator can specify the relative importance of a given resource-pool flow using shares that are enforced at the dvUplink level. The underlying dvUplink bandwidth is then divided among resource-pool flows based on their relative shares in a work-conserving way. This means that unused capacity will be redistributed to other contending flows and won t go to waste. As shown in the image, the network flow scheduler is the entity responsible for enforcing shares and therefore is in charge of the overall arbitration under over commitment. Each resource-pool flow has its own dedicated software queue inside the scheduler so that packets from a given resource pool are not dropped due to high utilization by other flows. Limits specify an absolute bandwidth for a traffic flow. Traffic from a given flow is never allowed to exceed its limit. The limit is specified in megabits per second. Limits are useful when you do not want to have the other traffic affected too much by other network events.

The system administrator can specify an absolute shaping limit for a given resource-pool flow using a bandwidth capacity limiter. As opposed to shares that are enforced at the dvUplink level, limits are enforced on the overall vNetwork distributed switch or vDS set of dvUplinks, which means that a flow of a given resource pool will never exceed a given limit for a vDS out of a given vSphere host. Consider an example where virtual machine and iSCSI traffic use nearly all the available bandwidth. vMotion starts and consumes a large percentage of the bandwidth. In this case, it might be a good idea to limit the bandwidth of vMotion. In the Network Resource Pool Settings, you can configure QoS priority. You can tag userdefined network resource pools with this tag. The QoS priority tag field allows you to select a priority code in the range of 1 to 7, where 1 is the lowest priority and 7 is the highest priority. When a physical switch is 802.1p enabled, the network receives a packet and prioritizes the traffic based on the tag. Please note that priority tagging is available only with distributed switches. vSphere 5.0 provides several improvements to the functionality of distributed switches. These include NetFlow, Cisco discovery protocol or CDP and link layer discovery protocol or LLDP, and port mirroring. Please note that CDP is actually available in the earlier versions of vSphere. The next few screens will explain these enhancements in detail. vSphere 5.0 provides several improvements to the functionality of distributed switches. These include NetFlow, Cisco discovery protocol or CDP and link layer discovery protocol or LLDP, and port mirroring. Please note that CDP is actually available in the earlier versions of vSphere. The next few screens will explain these enhancements in detail. NetFlow is a common tool for analyzing network traffic. It is a specification for collecting types of network data for monitoring and reporting. NetFlow has multiple uses, including network monitoring and profiling, billing, intrusion detection and prevention, networking forensics, and Sarbanes-Oxley compliance. It sends aggregated networking flow data to a third-party collector, such as an appliance or a server. The collector and analyzer reports on various information such as the current top flows consuming the maximum bandwidth in a particular distributed virtual switch, the IP addresses that are behaving irregularly, and the number of bytes a particular virtual machine has sent and received in the past 24 hours. NetFlow enables visibility into the virtual machine traffic for ESXi deployments. vSphere 5.0 sends data in the format that adheres to the NetFlow specification. The collector and analyzer are not a part of vSphere and must come from a third party. Port mirroring is a technology that duplicates network packets of a switch port (the source) to another port (mirrored port). The source s network traffic can monitored at the mirrored.

On physical switches, administrators are accustomed to being able to mirror the traffic to special ports in order to assist in troubleshooting. Mirrored traffic can also be used as an input for security and other network analysis appliances.

Port mirroring overcomes the limitations of promiscuous mode. That is, if you enable the promiscuous mode on a distributed port, this port will see all the network traffic going through the distributed switch. There is no way to select which traffic from a port or port group that a particular promiscuous port is allowed to see. It can see all the traffic on the same broadcast domain. Port mirroring overcomes this limitation by allowing the administrator to control which traffic on the distributed virtual switch can be seen by the port enabled for promiscuous mode. vSphere 5.0 supports CDP and LLDP. CDP is available for both standard switches and distributed switches. LLDP is only available for distributed switches.

CDP is a Cisco protocol and is design to interact with Cisco physical switches. LLDP is an industry standard protocol and is designed to interact with any physical switch that supports it.

CDP or LLDP are used by network devices for advertising their identity and capabilities on a network. When CDP or LLDP are enabled between peer virtual and physical switches, you can use the vSphere Client to view properties of the physical switch. These properties include such items as the device ID, the software version, port number, and timeout values.

CDP was supported on vSphere 4.x, however, LLDP is available only in vSphere 5.0. Networking enhancements have been made to vSphere 5.0 that improves firewall management.

In classic ESX, the service console was protected with a firewall based on iptables to filter connections coming in and going out to the service console. ESXi does not have a service console, so it cannot take advantage of the capabilities of iptables.

The ESXi 5.0 management interface is protected by a new service-oriented and stateless firewall. It is enabled by default and at installation time, it is configured to block incoming/outgoing traffic, except for default services such as DNS Client, DHCP Client, and SNMP Server.

The vSphere Client interface for configuring the firewall on ESXi is similar to that used with the classic ESX firewall. This means that users who are familiar with the classic ESX firewall should not have any difficulty with the ESXi version.

With this firewall, users have the ability to restrict access to specific services based on IP address and subnet mask.

This concludes the vNetwork: Advanced Topics module. In summary:

- Private VLANs support broader compatibility with existing networking environments using the private VLAN technology. Private VLANs enable users to restrict communication between virtual machines on the same VLAN or network segment, significantly reducing the number of subnets required for certain network configurations. - Load balancing and failover policies allow you to determine how network traffic is distributed between adapters and how to re-route traffic in the event of a failure. You can edit your load balancing and failover policies

by configuring the load balancing policy, failover detection, and network adapter order. - Network I/O control provides control to converge different traffic flows on a single pipe. It provides control to the administrator to ensure predictable network performance when multiple traffic types are flowing in the same pipe. In vSphere 5.0, various enhancements have been made to network I/O control. These include user-defined network resource pools, QoS tagging, and bandwidth control for vSphere replication. Network I/O control provides its users with different features. These include isolation, shares, limits, and load-based teaming. - vSphere 5.0 provides several improvements to the functionality of distributed switches. These include NetFlow, LLDP, and

port mirroring. - NetFlow increases the visibility of traffic flowing between virtual machines, LLDP improves network monitoring, and port mirroring can assist in network troubleshooting and in many ways is similar to Cisco s SPAN feature. - The ESXi 5.0 management interface is protected by a new service-oriented and stateless firewall. It is enabled by default and at installation time, it is configured to block incoming/outgoing traffic, except for default services such as DNS Client, DHCP Client, and SNMP Server.

Now that you have completed this course, feel free to review it. When you are ready to proceed, close this browser window to return to the myLearn Learning Management System.