Your Browser is Out of Date

Nytro.ai uses technology that works best in other browsers.
For a full experience use one of the browsers below
Dell VxRail Network Planning Guide
Introduction Plan the VxRail network VxRail Cluster Types VxRail feature-driven decision points VxRail hardware and switch selection decision points Prepare the data center to implement VxRail
Prepare the data center to implement VxRail
Prepare external network connectivity for VxRail
Prepare service connectivity for VxRail
Prepare for VMware vSphere+ subscription licensing
Prepare data center routing services
Prepare for multirack VxRail cluster
Prepare for VMware vSAN HCI mesh topology
Prepare external FC storage for dynamic clusters
Prepare for VxRail custom uplink assignments
Prepare data center network MTU
Prepare for LAG of VxRail networks
Identify switch ports to be configured for LAG
Plan LAG on switch port pairs
Prepare certificate authority server for VxRail
Identify isolation IP addresses for VMware vSphere High Availability
Plan the VxRail cluster implementation Planning vSAN Witness Networking Planning VxRail Satellite Nodes Networking Configure the Network for VxRail Prepare to build the VxRail cluster VxRail network considerations after implementation Appendix A: VxRail Network Configuration Table Appendix B: VxRail Passwords Appendix C: VxRail cluster setup checklist Appendix D: VxRail Open Ports Requirements Appendix E: VMware VDS port group default settings Appendix F: Physical Network Switch Examples

Prepare for LAG of VxRail networks

Prepare for LAG of VxRail networks

  • LAG for specific VxRail networks is supported starting with VxRail 7.0.130.

    NIC teaming in VxRail is the foundation to support LAG, which is the bundling of two physical network links to form a single logical channel. LAG allows ports on a VxRail node to peer with a matching pair of ports on the ToR switches to support load-balancing and optimize network traffic distribution across the physical ports. VxRail networks with heavy resource requirements, such as VMware vSAN and perhaps VMware vSphere vMotion, benefit most from network traffic optimization.

    Figure 45. Dependent LAG features. Dependent LAG features
    Overview of LAG peering relationship between VxRail and the adjacent switches

    Each VxRail network is assigned two uplinks by default during the initial implementation operation. Even if the virtual distributed switch port group is assigned a teaming and fail over policy to enable better distribution across the two uplinks, true load balancing is not achievable without LAG. Enabling LAG allows the VxRail network to better use the bandwidth of both uplinks, with the traffic flow coordinated based on the load-balancing hash algorithm that is configured on the virtual distributed switch and the ToR switches.

    The following functionality dependencies must be understood if considering LAG with VxRail:
    • The switches that are targeted for the VxRail cluster must support LACP. LACP is the protocol that dynamically forms a peering relationship between ports on two separate switches. Dynamic LAG requires an LACP policy to be configured on the VMware VDS to enable this peering to be established with the adjacent ToR switches.
    • LACP is considered the best practice for LAG because it offers support for more load-balancing hashing algorithms and superior management capabilities.
    • For network topologies using two or more switches to support VxRail networking:
      • The switch operating system must support a feature to allow LAG to span the two switches. This is known as Multi-Chassis Link Aggregation (MLAG) with Dell networking products.
      • The switch operating system must support a feature that enables the networks in a port channel to pass through the two switches at one end of a LAG group. This is known as Virtual Link Trunking with Dell networking products.
    • LAG is not supported if the Ethernet adapters supporting the VMware vSAN network are enabled for RDMA over Converged Ethernet (RoCE).
    LAG is not supported on the VxRail management networks prior to VxRail 7.0.450. The following minimum VxRail versions must used when using LAG with VxRail:
    • Customer-managed VMware VDS: VxRail 7.0.130
    • VxRail-managed VMware VDS: VxRail 7.0.450
    • All VxRail networks: VxRail 7.0.450
    The following VxRail network guidelines must be adhered to enable LAG:
    • VxRail supports a single LAG group per cluster.
    • Two Ethernet ports can only be configured into a LAG group.
    • The Ethernet ports that are selected for LAG can be all NDC/OCP-based, all PCIe-based, or a mixture of NDC/OCP and PCIe Ethernet ports.
    • All ports that are configured for LAG must be running at the same speed.
    Figure 46. Sample LAG options for VxRail networking. Sample LAG options for VxRail networking
    Sample link aggregation options for VxRail networking
    The following guidelines must be followed to enable LAG on a customer-managed VMware VDS:
    • You must supply a compatible VMware vCenter Server instance to serve as the target for the VxRail cluster.
    • You must supply a compatible and pre-configured virtual distributed switch to support the VxRail networking requirements.
    • The LACP policy to support LAG and load-balancing must be pre-configured on the virtual distributed switch.
    Follow these guidelines to enable LAG on a VxRail-managed VMware VDS:
    • The default mode for switch ports configured as port channels is that the ports shut down if they do not form a pairing with another pair of ports on another switch.
    • VxRail requires those switch ports to remain open and active during the VxRail initial implementation process.
    • The switches that are targeted for the VxRail cluster must support enabling the individual ports in the port channel to stay open and active if they do not form a LAG partnership with other switch port pairs within the configured timeout setting. (On Dell-branded switches running OS10, this is known as the LACP individual’ feature.)

    On Cisco-branded switches, the feature is LACP suspend-individual. This feature should be disabled on the switch ports in an EtherChannel to prevent the ports from shutting down. Check the documentation for switches from other vendors for the proper feature description.

    Verify that the switches support LAG

    Support for LACP, the selection of load-balancing hashing algorithms and the formation of LAG on the physical switches depends on the switch vendor and operating system. These features are branded by the vendor, using names such as Ether-Channel, Ethernet trunk, or Multi-Link Trunking. Consult your switch vendor to verify that the switch models that are planned for the VxRail cluster supports this feature.

    Verify support for multi-chassis LAG

    To deploy a pair of switches to support the VxRail cluster, and enable load-balancing across both switches, the switches must support the ability for the networks in a LAG group to logically flow across both switches. The switch operating system must support the multi-chassis LAG feature, such as Cisco Virtual Port Channel. See the guides provided by your switch vendor for the steps to complete this task.

    Verify support for LACP individual or similar feature

    If you plan to deploy VxRail with a VxRail-supplied virtual distributed switch, then the switches must support the LACP individual or compatible feature. By default, switch ports that are configured for LAG are set to an inactive state until such time it has exchanged LACP PDUs with a LAG on another adjacent switch. When these PDUs are exchanged, the two LAGs can then sync into a partnership, and the sets of ports become active.

    Figure 47. Enable connectivity for VxRail initial implementation with LAG. Enable connectivity for VxRail initial implementation with LAG
    Enabling connectivity for VxRail initial implementation with LAG

    An individual VxRail node connects to the adjacent ToR with a standard virtual switch at power-on, and virtual switches do not support LAG. The LACP policy that is configured by VxRail on the VxRail-managed VMware VDS during the initial implementation process cannot exchange LACP DPUs at the power-on stage. This peering relationship does not occur until VxRail begins the virtual network formation stage later in the initial implementation process. Using this feature enables a switch port that is configured for LAG to be set to an active state in order to enable VxRail connectivity and allow initial implementation to proceed.