Virtual network visibility and control

The Visibility and Control section allows you to monitor network behavior and configure network policy. To access the pages, select the Visibility and Control icon at the top of the vSwitch Controller interface.

View status

The Status tab provides detailed information in table form about the node that is selected in the resource tree. The type of information that is presented varies according to the selected node. Most individual table entries are links. You can click these links to display the status page that applies to that table entry.

All byte counts and error counts continue to accumulate even when a XenServer host restarts or a VM restarts or migrates. The color codes follow the same rules as the color codes in the side panel. See Color-coded icons.

Global level

At the global level, the Status page presents a table listing all resources pools with the following information:

  • Resource pool: Name of the resource pool.
  • # Servers: Number of servers in the pool.
  • # Networks: Number of networks in the pool.
  • # VMs: Number of VMs in the pool.
  • Status: Color-coded icon that shows the current pool status.

Clicking the gear icon on the right side of a row provides options for modifying the resource pool.

On this page, you can also specify available target VLANs for port configuration policies. See Set up port configuration policies.

Resource pool level

For a selected resource pool, the Status page presents the following information:

  • Status: Color-coded icon that shows the current pool status.
  • Pool Master: IP address or DNS name of the master server in the pool.
  • Pool-Wide Networks: Number of networks in the pool.
  • XenServer: Number of servers in the pool.
  • All VMs: Number of VMs in the pool.
  • Server list: List of servers in the pool, including server name, number of networks, number of VMs, and status.

In addition to displaying status information, you can configure how the XenServer hosts in the pool forward Netflow data. Select the following check boxes as appropriate, and click Save Netflow Configuration:

  • vSwitch Controller (selected by default): Forwards Netflow information to the vSwitch Controller for use by the Flow Statistics section of the GUI. If you deselect this check box, the Netflow data is not sent to the vSwitch Controller and the Flow Statistics pages do not show data.
  • External Netflow Controller: Allows you to forward Netflow data to an external third party Netflow collector. Enter the IP address of the external collector.

Fail-safe mode

Use the Fail Mode section to configure how a vSwitch enforces the access control rules when it can’t connect to its vSwitch Controller. It is important to maintain a high level of vSwitch Controller availability to avoid data loss. During times when the vSwitch Controller is not available, the following fail modes apply:

  • Fail-open: all traffic is allowed, previously defined ACLs no longer apply until the vSwitch is able to reconnect with the vSwitch Controller.
  • Fail-safe: existing ACLs continue to apply.

Under normal operation, the vSwitch maintains connections to its configured vSwitch Controller to exchange network management and status information. If the vSwitch Controller becomes unavailable, the vSwitch waits up to an inactivity timeout during which network traffic is dropped. After the inactivity timeout, the vSwitch enters into the configured fail mode.

In fail-safe mode, existing ACLs continue to apply after the vSwitch loses the connection to its configured vSwitch Controller. Traffic that does not match existing ACLs are denied. All ACLs, at any level of the policy hierarchy presented by the Controller, are enforced as sets of rules on VIFs in the vSwitch. As a result, new VIFs that appear in fail-safe mode while the Controller is unavailable cannot communicate until the Controller becomes available again. Existing VIFs that are unplugged then replugged have the same behavior as new VIFs. This situation occurs even if higher-level ACL policy rules (global, per-resource pool, per-network, or per-VM) that allow communication are present on existing VIFs. Furthermore, the vSwitch Controller can define ACLs based on IP addresses it has learned. In fail-safe mode, packets sent by a VM using an IP address the Controller has not associated with the VM before it became unavailable are denied. For example, an existing VM that uses a new IP address cannot communicate until the Controller is reachable again. Other examples where traffic is denied while in fail-safe mode include:

  • Newly plugged VIFs
  • A new VM
  • A migrated VM (for example XenMotion or Workload Balancing)
  • VMs on hosts added to a pool
  • Applications that act like a router

If the vSwitch restarts in fail-safe mode and the controller is still unavailable after the vSwitch starts, all ACLs are lost and all traffic is denied. The vSwitch stays in fail-safe mode until a connection with the Controller is re-established and ACLs are pushed down to the vSwitch by the Controller.

Warning:

Removing a resource pool from vSwitch Controller management while in fail-safe mode can result in the vSwitch losing network connectivity and forcing an emergency reset situation. To prevent this situation, only remove a resource pool while its status is green.

You can also specify available target VLANs for port configuration policies on this page. For more information, see Set up port configuration policies.

Server level

For a selected server, the Status page presents the following information:

  • Server Status: Color-coded icon that shows the current server status.
  • Server Networks: Number of networks in the resource pool.
  • MAC Address: MAC address of the server management interface.
  • IP Address: IP address of the server management interface.
  • vSwitch Version: Build and version number of the vSwitch running on this XenServer.
  • Server Networks: List of all networks associated with the server. This information includes:
    • The number of VMs on the server using that network
    • The associated physical interface,
    • The VLAN
    • The number of bytes transmitted and received
    • The number of errors
    • The status
  • Server VMs: List of all VMs associated with the server. For each VIF on the VM, this information also includes:
    • The MAC address
    • The network
    • The IP address
    • The total bytes transmitted and received since the VM was booted
    • The status

On this page, you can also specify available target VLANs for port configuration policies. See Set up port configuration policies.

Network level

The Status tab for pool-wide networks lists summary information about each network in the resource pool. The Status tab for an individual network lists information about the network itself. The tab includes hyperlinked tables of information about the physical interfaces and VM interfaces currently connected to the network.

The status icon can be displayed in the following colors:

  • Green if the network is active and properly managed by the vSwitch Controller
  • Red if the network has no connected interfaces
  • Orange if there is an error condition. The associated text describes the error.

For pool-wide networks, the following information is displayed:

  • Network name: Specific network.
  • VMs: Number of VMs associated with the network.
  • XenServer: Server for the network.
  • Physical Interface: Server interface for the network.
  • Transmit (Tx) and receive (Rx) packets: Aggregated counters across all VIFs on the specified network.
  • Errors: Aggregated counters across all VIFs on the specified network.
  • Status: Color-coded icon that shows the current network.

For a selected network, the following information is presented:

  • Network Status: Color-coded icon that shows the current network.
  • VMs: Number of VMs associated with the network.
  • Physical interfaces: List of physical interfaces, including VLAN, number of bytes transmitted and received, errors, and status.
  • Switching XenServer (present on cross-server private networks only): Specifies the current active switching host for the network. A cross-server private network enables communication between VMs in the same resource pool, without need for any additional configuration of the physical network. The VMs can be running on different hosts. This capability is accomplished by having a “switching host” establish GRE tunnels to each of the other hosts in the pool. The GRE tunnels are set up in a star topology. The other hosts have an active VM running on the private network. If a switching host becomes unavailable or is deleted, a new switching host is automatically selected and new GRE tunnels are configured. See Networking for more information on cross-server private networks.
  • VM interfaces: List of VMs, including MAC address, IP address, number of bytes transmitted and received, and status.

On this page, you can also specify available target VLANs for port configuration policies. For more information, see Set up port configuration policies.

Virtual Machine (VM) level

The following information is displayed for all VMs:

  • VM name: Name of the specific VM.
  • MAC address: MAC address assigned to the VM.
  • Network name: Network to which the VM is assigned.
  • Detected IP address: IP addresses assigned to the VM.
  • Transmit (Tx) and receive (Rx) packets: Aggregated counters across all VIFs on the specified VM.
  • Errors: Aggregated counters across all VIFs on the specified VM.

For a selected VM, the Status page displays the following information:

  • Status: Color-coded icon that displays the current VM status.
  • Resource Pool: Resource pool to which the VM belongs.
  • Server Name: Name of the server to which the VM is assigned. This information is blank if the VM is not running and is not tied to a specific server.
  • VM Group Membership: List of administrative groups to which the VM is assigned.
  • VM interfaces: List of the VIFs on the VM. This information includes:
    • MAC address
    • Network name
    • Detected IP address
    • Transmit and receive bytes, packet, and error counts
    • Status
  • Network Events: List of network events involving the VM, including priority, date/time, and description.

Virtual Interface (VIF) level

For a selected VIF, the Status page presents the following information:

  • Status: Color-coded icon that shows the current VIF status.
  • Resource Pool: Resource pool to which the VIF belongs.
  • Network: Network to which the VIF belongs.
  • VM Name: VM to which the VIF belongs.
  • MAC Address: MAC address of the VIF.
  • IP Address: IP address of the VIF.
  • Transmit and Receive bytes, packets, and errors: Traffic counts for the VIF.
  • Switch Port ACL Statistics: Unlike transmit and receive counts, the ACL hit counts are instantaneous statistics read from the ACL rule statistics of the current vSwitch. Therefore, policy changes and VM actions, such as suspension, shut down, or migration causes these statistics to reset. The vSwitch ACL statistics require an IP address to be identified on the network and able to collect statistics for IP-based protocols. If you find that there are no counts on IP-based rules, verify that an IP address is displayed in the IP address field.

View flow statistics

By default, the vSwitch on each managed XenServer sends Netflow data to the vSwitch Controller, which uses this data to generate Flow Statistics tables and charts. The vSwitch generates Netflow records for all IPv4 flows after five seconds of no activity or 60 seconds of total activity.

The data rate of a flow is represented as the total traffic of the flow averaged across the duration of the flow. For example, if a flow lasts 10 seconds with 900 KB sent in the first second and 10 KB sent in each of the nine remaining seconds, the resulting data is plotted as if the rate were 100 KB/second for the entire flow period.

Netflow uses UDP datagrams to transport NetFlow records between a switch and a collector (for example, the vSwitch Controller). Because NetFlow uses UDP datagrams, there is usually no way for the collector to know why a NetFlow record wasn’t received. Dropped records can result in nondeterministic data with Flow Statistics tables or charts. For example, assume that a network generating 10 flows per second has a single 1 GB file transfer that lasts 10 seconds. The network generates a total of 202 flows (100 hping stimuli, 100 hping responses, 1 file transfer stimulus, and 1 file transfer response). If 50% of the UDP datagrams are dropped, there is a 50/50 probability that the collector reports either 1 GB of data, or 2 KB.

Because each vSwitch in a pool generates Netflow records, sources and destinations run on different XenServer hosts result in two records, doubling the statistics counts.

Disable flow visibility in deployments of more than 100 VMs to avoid overloading the vSwitch Controller virtual appliance and the network used to send NetFlow records.

The Flow Statistics tab displays a graph and associated table to show flows for the selected node.

A screenshot of the lists that give the options described in the following section.

Use the lists at the top of the page to specify the following:

  • Direction: Bidirectional, Inward, Outbound
  • Units: Bytes, Bits, Packets, Flows
  • The top or bottom items (highest or lowest values) of one of the following groupings:
    • VMs: VMs residing within the resource pool as sources/destinations for traffic
    • IP Addresses: IP addresses as source or destination for traffic
    • Protocols: IP protocol traffic such as ICMP, TCP, and UDP

      Note:

      Ethernet layer protocols (such as ARP) are not displayed due to the limitations in the Netflow protocol used to generate results.

    • Application: “application”-level protocol traffic, identified by TCP/UDP port or ICMP type/code
  • Traffic (by type): VMs, IP Address, Protocols, Applications (shown by protocol type and port number, this information can allow you to infer the service)
  • Time interval.

The table below the graph displays some or all of the following information, depending upon the type of item selected in the list:

  • VM
  • IP
  • Inbound bytes
  • Inbound data rate (Kbit/s)
  • Outbound bytes
  • Outbound data rate (Kbit/s)
  • Total bytes
  • Total data rate (bps)

If NetFlow is not being forwarded to the vSwitch Controller, a warning blue status text is displayed under the Flow Statistics tab: One or more selected pools are not configured to forward NetFlow records to vSwitch Controller

To reconfigure forwarding, click the blue status text to see a list of resource pools. Select the resource pool desired from the list to navigate to the pool status page. From the status page, you can configure NetFlow data forwarding.

Manage address groups

You can set up address groups to specify the IP addresses to use as the source or destination for ACLs and for reporting of flow statistics.

To add an address group:

  1. Under Visibility & Control, select Address Groups in the resource tree (side panel) to open the Status page for all address groups.
  2. Click Create Group.
  3. Enter the name to identify the group, and an optional description.
  4. Click Create Group. The new group is added to the list of address groups.
  5. Select the new group in the resource tree to open its Status page.
  6. Click the Add Members button.
  7. In the pop-up window, specify one or more IP addresses or subnets (comma separated). Example: 192.168.12.5, 192.168.1.0/24
  8. Click Add. Continue to add more networks as needed. Each set of addresses is added as a node under the network in the Address Groups list.

The new address group is now available for ACL policies and flow statistics.

You can remove an existing address group by clicking the Remove link in the row of the All Address Groups for that address group.

You can also update the name or description of and address group:

  1. Select the new group in the resource tree to open its Status page.
  2. Click the Modify Group button.
  3. In the dialog that opens, change the name and description.
  4. Click the Modify Group button to save the changes.

Manage Virtual Machine groups

A VM group is a set of VMs that you identify as a group for viewing status and flow statistics. Each VM in a VM group must already be in a resource pool. The groups are otherwise independent of resource pools and servers.

To add a VM group:

  1. Under Visibility & Control, select VM Groups in the resource tree (side panel) to open the Status page for all VM groups.
  2. Click the Create Group button.
  3. Enter the name to identify the group, and an optional description.
  4. Click Create Group. The new group is added to the list of VM groups.
  5. Select the new group in the resource tree to open its Status page.
  6. Click Add Member.
  7. In the pop-up window, select the VM from the list.
  8. Click Add. Continue to add more VMs as needed. Each VM is added as a subnode under the group in the VM Groups list.

The following right-click options are available for each VM group:

  • Add VM to group: Add a new group member.
  • Modify Name/Description: Change the name or description.
  • Remove Group: Delete the group.

DVS policy configuration hierarchy

Use the Access Control and Port Configuration tabs within Visibility & Control to configure access control, QoS, and traffic mirroring policies within the virtual network environment. While all policies are applied at the VIF level, vSwitch Controller exposes a hierarchical policy model that supports declaring default policies across a collection of VIFs. The vSwitch Controller also provides a way to override this default policy by creating fine-grained exceptions when needed. For example, you can exempt a particular VM from the default resource pool policy.

Similar to the hierarchy used in the resource tree, the policy hierarchy has the following levels:

  • Global (most general level): Includes all VIFs in all resource pools.
  • Resource pools: All VIFs in a particular resource pool.
  • Networks: All VIFs attached to a particular network.
  • VMs: All VIFs attached to a particular VM
  • VIFs (most specific level): A single VIF.

Note:

XenServer hosts are not included in the policy hierarchy, since policies must apply regardless of what XenServer in a resource pool is running a VM.

Set up Access Control policies

Choose the Access Control tab to set up policies that allow or deny VM traffic based on packet attributes.

An ACL policy consists of a set of rules, each of which includes the following:

  • Action: Indication of whether traffic matching the rule is permitted (Allow) or dropped (Deny).
  • Protocol: Network protocol to which the rule applies. You can apply the rule to all protocols (Any), choose from an existing protocol list, or specify a new protocol.
  • Direction: Direction of traffic to which the rule applies. Read the text of the rules from left to right: “to” means traffic outbound from the VM, while “from” means traffic inbound to the VM.
  • Remote Addresses: Indicates whether the rule is limited to traffic to/from a particular set of remote IP addresses.

Management of ACL policies closely follows the resource tree hierarchy. You can specify policies at any supported level of the hierarchy. At each level, rules are organized as follows:

  • Mandatory rules: These rules are evaluated before any child policy rules. The only rules that take precedence over them are mandatory rules of parent (less specific) policies. Mandatory rules are used to specify rules that child (more specific) policies cannot override.
  • Child rules: The child policy placeholder indicates the location in the rule order at which rules in child policies are evaluated. It divides the mandatory rules from the default rules.
  • Default rules: These rules are evaluated last, after all mandatory rules and all child policy default rules. They only take precedence over default rules of parent policies. They are used to specify behavior that is only applied if a more specific child policy does not specify conflicting behavior.

The **Access Control** tab for a VIF.

Global Access Control List (ACL) rules

To set up global ACL rules, click All Resource Pools in the resource tree. The page lists all of the ACL rules that are defined at the global level.

Resource Pool Access Control List (ACL) rules

To set up ACL rules for a resource pool, select the resource pool in the resource tree.

The page shows an expandable bar for global policy, and an expanded area for resource pool rules. If you click the Expand All button, you can see how the resource pool rules are embedded in the global policy framework.

Network Access Control List (ACL) rules

To set up ACL rules at the network level, click the network in the resource tree.

The page shows the following:

  • An expandable bar for global rules
  • An expandable bar for the resource pool to which the network belongs
  • An expanded area for network rules

If you click Expand All, you can see how the network policies are embedded in the resource policy framework and in the global policy framework.

VM Access Control List (ACL) rules

To set up policies at the VM level, click the VM in the resource tree.

The page shows the following:

  • An expandable bar for global rules
  • Expandable bars for the resource pool and network to which the VM belongs
  • An expanded area for VM rules

If you click the Expand All button, you can see how the VM rules are embedded in the network, resource pool, and global framework.

If a VM contains VIFs on multiple networks, a “Change Network” link appears on the right side of the example bar for the network. This link allows you to view the rules for each network level policy that might apply to a VIF on that VM.

VIF Access Control List (ACL) rules

To set up policies at the VIF level, click the VIF in the resource tree. Because policies are packaged and applied only at the VIF level, you must display the VIF pages to see the full policy context.

The page shows the following:

  • Expandable bars for global rules
  • Expandable bars for the resource pool, network, and VM to which the VIF belongs
  • An expanded area for VIF rules

If you click the Expand All button, you can see how the VIF rules are embedded in the VM, network, resource pool, and global framework.

Access Control List (ACL) rule enforcement order

While ACLs can be defined at different levels of the policy configuration hierarchy, ACLs are enforced on a per-VIF basis. For actual enforcement, the hierarchy is combined in the order described in this section and applied to each VIF. To see currently applied rules on a VIF and the associated statistics, select the VIF in the resource tree. View the ACL list in the Status tab.

The enforcement order is as follows:

  1. Mandatory rules at the global level
  2. Mandatory rules for the resource pool containing the VIF
  3. Mandatory rules for the network containing the VIF
  4. Mandatory rules for the VM containing the VIF
  5. Rules for the VIF containing the VIF
  6. Default rules for the VM containing the VIF
  7. Default rules for the network containing the VIF
  8. Default rules for the resource pool containing the VIF
  9. Default rules for the global containing the VIF

The first rule that matches is executed, and no further rules are evaluated.

Note:

When a vSwitch Controller is unavailable, the resource pool enforces access control rules based on the configured fail mode. See the section called “Resource Pool Level” under “Viewing Status” for more details about a resource pool’s fail mode.

Define Access Control List (ACL) rules

To define a new ACL rule, use the resource tree to choose the node at the appropriate level in the policy configuration hierarchy. You can add rules at each level for that level and for higher levels. For example, if you select a resource pool, you can add rules for that resource pool and global rules.

If you choose a resource tree node that doesn’t correspond to a level in the policy configuration hierarchy, a message is displayed. The message provides links to choose another levels.

New rules can be added in the following ways:

  • To add a mandatory rule, click the gear icon in the header bar for the level, and choose Add New Mandatory ACL.
  • To add a default rule, click the gear icon in the header bar for the level, and choose Add New Default ACL.
  • To add a rule above an existing rule entry, click the gear icon for the entry, and choose Add New ACL Above.
  • To add a rule below an existing rule entry, click the gear icon for the entry, and choose Add New ACL Below.

The new rule is added to the page with the following default settings:

  • Action: Allow
  • Protocol: Any
  • Direction: To/From
  • Remote Addresses: Any
  • Description: None

To change a particular field within a rule, click the link representing the current field value and apply changes as described in the following list. When you apply a change, the rule is updated to show the values.

  • Action: Click the link and choose Change Action to Deny or Change Action to Allow.
  • Protocol: Click and choose one of these options:
    • Choose Match Any Protocol to apply the rule to all protocols.
    • Choose Use an Existing Protocol to specify a protocol. Select the protocol from the list, and click Use Protocol.
    • Choose Use a New Protocol to specify custom protocol characteristics. Specify the following information in the pop-up window, and click Save & Use:
      • Ethertype: Select IP or enter another Ethertype.
      • IP Protocol: Select one of the listed protocols, or enter another.
      • Destination Port (TCP/UDP only): Enter a port number or specify Any.
      • Source Port (TCP/UDP only): Enter a port number or specify Any. When defining an application that uses a well-known server port, define that well-known port as the destination port and leave the source port as Any. For example, you can use this approach for HTTP, which uses port 80.
      • ICMP Type (ICMP only): Choose Any or enter a specific ICMP type Protocol (ICMP) type.
      • ICMP Code (ICMP only): Choose Any or enter a specific ICMP code.
      • Match reply traffic: Indicate whether return traffic is automatically allowed as part of the rule. For example, if the rule allows UDP destination port 7777 traffic from the VM to a specified remote address and Match reply traffic is selected, UDP traffic is also allowed from source port 7777 of the remote address to the VM. Enable this option for any UDP protocol that requires bidirectional communication (the option is always enabled for TCP).
      • One-time Use vs. Multiple Uses: Select whether to use this protocol only for the current rule or to add it to the list of protocols in the protocol menu.
    • Choose View/Modify Current Protocol to modify characteristics for an already defined protocol.
  • Direction: Choose whether the rule applies from or to the specified remote addresses, or both.
  • Remote Addresses: To specify the remote addresses:
    1. Click the Any link to open a pop-up window that lists the available address groups.
    2. Select one or more address groups and use the arrows to move them to the Selected column.
    3. Use the All buttons to select or deselect all of the groups.
    4. To specify an IP address or subnet that is not part of an existing address group, enter the address or subnet (x.x.x.x or x.x.x.x/n). Click Add. Repeat to add more addresses.
    5. Click Done.
  • Description: To add a text description of the rule:
    1. Click the Description button.
    2. Click the entry (<None> if there is no current description). A text entry area is displayed. Enter the text and press Enter.
  • Rule Details: Click the Rule Details button to display a brief summary of the rule.

Click Save Policy Changes to apply the new rules. When you do so, the changes take effect immediately within the virtual network environment. If you have not already saved the rules, you can click Undo Changes to reverse the changes you have named.

When you change an ACL, all background updates for the vSwitch Controller GUI are paused. If another administrator modifies the policy simultaneously and commits changes before you, refresh the page to retrieve the new policy from the server. Reenter your changes.

You can change order of rules in a level by clicking the gear icon for the rule and choosing Move Up or Move Down. You cannot move a rule between levels in the hierarchy. To remove a rule, click the gear icon and choose Delete. Click the Description button to display the ACL description. Or the Rule button to display the ACL rule that you constructed.

ACL rules are always interpreted from the point of view of the virtual interface of the VM, even if configured higher in the policy hierarchy. This behavior is important when thinking about the meaning of the Remote Addresses field in the rules.

For example, if a VM in a pool has the IP address 10.1.1.1, you might expect a rule on the pool that specifies “deny all protocols to IP 10.1.1.1” to prevent any traffic reaching the VM. This behavior is the case for all other VMs in the resource pool because each VM enforces the rule when the VM transmits. However, machines that are external to the resource pool can communicate with the VM with IP address 10.1.1.1. This behavior is because no rules control the transmit behavior of the external machines. It is also because the VIF of the VM with IP address 10.1.1.1 has a rule that drops transmit traffic with that address. However, the rule does not drop receive traffic with that address.

If the policy behavior is unexpected, view the Status tab for the virtual interface where the entire set of rules from all policy levels is visualized.

Set up port configuration policies

Use the Port Configuration tab to configure policies that apply to the VIF ports. The following policy types are supported:

  • QoS: Quality of Service (QoS) policies control the maximum transmit rate for a VM connected to a DVS port.
  • Traffic Mirroring: Remote Switched Port Analyzer (RSPAN) policies support mirroring traffic sent or received on a VIF to a VLAN to support traffic monitoring applications.
  • Disable MAC address spoof check: MAC address spoof check policies control whether MAC address enforcement is performed on traffic outbound from a VIF. If the vSwitch Controller detects a packet with an unknown MAC address from a VIF, it drops the packet and all subsequent traffic from the VIF. MAC address spoof check policies are on by default. Disable these policies on VIFs running software like Network Load Balancing on Microsoft Windows servers.

Warning:

Enabling RSPAN without correct configuration of your physical and virtual network can cause a serious network outage. Read the instructions in Configure RSPAN carefully before enabling this feature.

You can configure QoS and Traffic Mirroring port policies at the global, resource pool, network, VM, and VIF levels. When you select a node in the resource tree and choose the Port Configuration tab, it shows the configuration for each parent level in the hierarchy. However, only the configuration at the selected policy level can be changed. For example, if you select a VM, the Port Configuration tab shows the values configured at the global, resource pool, and network levels. The tab lets you change the value at the VM level.

QoS and Traffic Mirroring configurations at a given level override the configurations at the higher levels. If a configuration is overridden, then the Port Configuration tab shows the higher level configuration crossed out. For example, the next figure shows a QoS configuration at the network level that overrides the configuration at the resource pool level.

Screenshot of the **Port Configuration** tab.

To configure port policies, choose the node in the resource tree and choose the Port Configuration tab. If you choose a node that does not support port configuration policies, a message is displayed with links to nodes that do support port configuration.

Configure QoS

For QoS policies, choose from the following options:

  • Inherit QoS policy from parent (default): Applies the policy from the higher (that is, less specific) hierarchy level. This option does not exist at the global level.
  • Disable inherited QoS policy: Ignores any policies that are set at higher (that is, less specific) levels such that all VIFs included in this policy level have no QoS configuration.
  • Apply a QoS limit: Select a rate limit (with units), and a burst size (with units). Traffic to all VIFs included in this policy level is limited to the specified rate, with individual bursts limited to the specified number of packets.

Warning:

Setting a too small burst size relative to the rate limit can prevent a VIF from sending enough traffic to reach the rate limit. This behavior is especially likely for protocols that perform congestion control such as TCP.

At minimum, the burst rate must be larger than the Maximum Transmission Unit (MTU) of the local network.

Setting QoS to an inappropriately low burst rate on any interface on which the vSwitch Controller sits can result in losing all communication with the vSwitch Controller. This communication loss forces an emergency reset situation.

To prevent any inherited enforcement from taking place, disable the QoS policy at the VM level.

Click Save Port Configuration Changes to implement the changes, or click Undo Changes to remove any unsaved changes. The policy takes effect immediately after saving.

Configure RSPAN

Warning:

Configuring RSPAN when the server is connected to a switch that doesn’t understand VLANs or isn’t properly configured to support the RSPAN VLAN can cause traffic duplication and network outages. Review the documentation and configuration of your physical switches before enabling the RSPAN feature. This review is especially important at higher levels of the hierarchy where multiple physical switches might be involved.

Enabling RSPAN requires a series of steps, outlined below:

Identify your RSPAN VLAN

When RSPAN is enabled on a VIF, the vSwitch for that VIF makes a copy of each packet sent to or from that VIF. The vSwitch transmits the copy of that packet tagged with VLAN value called the target VLAN. An administrator then places a host performing monitoring on the switch port that is configured to use the target VLAN. If the monitoring host interface uses promiscuous mode, it can see all traffic that is sent to and from the VIFs configured to use RSPAN.

Configure the physical network with the target VLAN

It is critical to configure the physical network correctly to be aware of the RSPAN traffic to avoid network outages. Only enable RSPAN if the physical switching infrastructure connecting all RSPAN-enabled VIFs can be configured to disable learning on the target VLAN. For more information, see the documentation from your switch manufacturer.

Additionally, traffic sent on the target VLAN must be forwarded from each of the vSwitches to the monitoring hosts. If your physical infrastructure includes many switches in a hierarchy, this forwarding requires trunking the target VLAN between the different switches. For more information, see the documentation from your switch manufacturer.

Configure vSwitch Controller with the target VLAN

Tell the vSwitch Controller about each target VLAN before using that VLAN ID for RSPAN port configuration. You can specify available target VLAN IDs at the resource pool, network, or server level. Target VLANs added at a level of the hierarchy are available when configuring RSPAN port configuration at that level and all lower levels of the hierarchy. The correct level to specify a target VLAN depends on how widely you have configured your physical infrastructure to be aware of that target VLAN.

To specify available target VLANs:

  1. Under Visibility & Control, open the Status tab for all resource pools, a specific resource pool, a specific server, or a specific network.
  2. In the RSPAN Target VLAN IDs area, click + and enter the VLAN ID.
  3. Repeat to add more VLAN IDs.
  4. Click Save Target VLAN Change.

The VLANs are now available for selection on the Port Configuration tab, as described in this section.

Modify port configuration to enable RSPAN for a set of VIFs

To configure RSPAN policies within the Port Configuration tab, select the appropriate node in the resource tree and choose from the following options:

  • Inherit RSPAN policy from parent (default): Applies the policy from the next higher (that is, less specific) hierarchy level.
  • Disable inherited RSPAN policy: Ignores any policies that are set at higher (that is, less specific) levels such that all VIFs included in this policy level have no RSPAN configuration.
  • RSPAN traffic on VLAN: Choose a VLAN from the list of target VLANs. The only target VLANs that appear in the list are those VLANs configured for policy levels containing the currently selected node.

Configure MAC address spoof checking

To disable MAC address enforcement, select MAC address spoof checking. Enforcement can only be configured on a per VIF basis and does not inherit or override parent configurations.

Save changes

Click Save Port Configuration Changes to implement the changes, or click Undo Changes to remove any unsaved changes. The policy takes effect immediately after saving.