Key features of PowerEdge MX7000 chassis include:

• 7U modular enclosure with eight slots that can accommodate 2S single or four 4S double-width compute sleds and 12 Gb/s single-width storage sleds.
• 25 Gb Ethernet, 12 Gb SAS, and 32 Gb Fiber channel I/O options.
• Three I/O network fabrics—two for general use and one for storage only; each with redundant modules.
• Multichassis networking up to 10 chassis.
• Single management point for compute, storage, and networking.
• High-speed technology connections, now and into the future, with no mid-plane upgrade.

• Four PowerEdge MX740c sleds in slots one through four
• One PowerEdge MX840C sled in slots five and six (not used in this guide)
• Two PowerEdge MX5016s sleds in slots seven and eight

• Two Networking MX5108n Ethernet switches installed in fabric slots A1 and A2
• Two PowerEdge MX9002m management modules that are installed in management slots MM1 and MM2
• Two PowerEdge MX5000s SAS fabric switch modules that are installed in fabric slots C1 and C2
• Empty or available fabric slots B1 and B2

 Dell  PowerEdge MX7000 chassis supports three fabrics: two for general use and one for storage only. All three fabrics support redundant modules.

The  Dell  PowerEdge MX740c and MX750c are two-socket, full-height, single-width compute sleds that offer impressive performance and scalability. The MX740c and MX750c are ideal for dense virtualization environments and can serve as a foundation for collaborative workloads. An MX7000 chassis can support up to eight MX740c and MX750c sleds. Mixing compute sleds of different generations is supported.

Key features include:

• Single-width slot design
• One or two CPU sockets
• 24 or 32 DIMM slots of DDR4 memory (MX740c and MX750c)
• Boot options include BOSS-S1 or Internal Dual SD Modules (IDSDM)
• Up to six SAS/SATA SSD/HDD and NVMe PCIe SSDs
• Two PCIe mezzanine card slots for connecting to network Fabric A and B
• One PCIe mini-mezzanine card slot for connecting to storage Fabric C
• iDRAC with Lifecycle Controller

1. Handle release
2. Gigabit Ethernet port 1
3. Gigabit Ethernet port 2
4. ID button and health status LED
5. Power status LED
6. Micro-B USB port

• Two 100 GbE QSFP28 ports
• Two 100 GbE QSFP28 unified ports
• Twelve 2x100 GbE QSFP28-Double Density (DD) ports

The ports can be used to provide a combination of network uplinks, VLT interconnects (VLTi), or for FCoE connectivity. The MX5108n switch supports FCoE Initialization Protocol (FIP) Snooping Bridge (FSB) mode but does not support NPG or direct attach FC capabilities. The PowerEdge MX7000 chassis supports up to four MX5106n Ethernet switches in Fabric A or Fabric B, or both.

1. Express service tag
2. Storage USB port
3. Micro-B USB console port
4. Power and indicator LEDs
5. Module insertion or removal latch
6. One QSFP+ port
7. Two QSFP28 ports
8. Four 10GBASE-T ports

PowerEdge MX5000s provides Fabric C SAS connectivity to each compute and one or more PowerEdge MX5016s storage sleds. Compute sleds connect to the PowerEdge MX5000s using either SAS Host Bus Adapters (HBA) or a PowerEdge RAID Controller (PERC) in the mini-mezzanine PCIe slot.

The PowerEdge MX5000s switches are deployed as redundant pairs to offer multiple SAS paths to the individual SAS disk drives. The PowerEdge MX7000 chassis supports redundant PowerEdge MX5000s in Fabric C.

1. Express service tag
2. Module insertion or removal latch
3. Power and indicator LEDs

The VMware Compatibility Guide (VCG) is the system of record for versions of certain types of firmware and drivers which are certified to be compatible with vSphere and vSAN. These include server platform, vSAN disk controllers, and network interface cards. For more information on other components, see https://www.dell.com/support.

This document is written for VMware Cloud Foundation 4.0 running on ESXi 7.0. The required build and version of ESXi is specified by the version of Cloud Foundation to be installed. It is critical that the versions of both Cloud Foundation and ESXi correspond.

The Dell PowerEdge MX7000 chassis can be deployed as a single chassis or in a multi-chassis group, enabling multiple chassis to be managed as if they were a single chassis. A PowerEdge MX Scalable Fabric enables multiple chassis to behave like a single chassis from a networking perspective. To learn more about the PowerEdge MX Scalable Fabric Architecture, refer to the Dell EMC PowerEdge MX Networking Deployment Guide.

The PowerEdge MX I/O Guide includes detailed information on Scalable Fabric topologies and the cabling options for all configuration options.

This section provides details on the topology used in the validation of the deployment for  VMware  Cloud Foundation in this guide.

The following diagram shows the management module cabling for a dual chassis deployment. The MX7000 chassis are daisy-chained, and the management modules are pictured without the full chassis.

The following diagram shows the cabling for a dual chassis deployment with uplinks to a customer network leaf switch pair.

In this example, a host in an existing vSphere environment is used to run the services that are required to install Cloud Foundation. The management VLAN and VXLAN VLAN are extended to this management host. An NTP time server is installed on the management VLAN and a DHCP server on the VXLAN VLAN.

The  VMware  Cloud Builder VM must be able to communicate with the hosts that become the Cloud Foundation management cluster. In this example, the new cluster hosts were given IP addresses on the 172.17.11.0/24 subnet and placed on the management VLAN (1711). A port group on the management host that was tagged with VLAN 1711 was created and connected to a port on a switch that accepted (ingress) traffic. The switchports between that initial ingress port and the new hosts were tagged with VLAN 1711.

There are three network services that are essential for VMware Cloud Foundation deployment.

Domain Name System (DNS) is required to provide both forward and reverse name resolution. The IP addresses of name servers, search domains, and hostnames of all the VMware Cloud Foundation VMs must be inserted into the Cloud Builder deployment parameter sheet. Forward and reverse DNS entries of any hostname that are indicated in the parameter sheet should be tested and retested for both forward and reverse lookups. Test the DNS entries using their Fully Qualified Domain Name (FQDN) and their short name (hostname).

A VTEP (VxLAN Tunnel End Point) is the software-based endpoint of a VXLAN connection that communicates over IP. The IP addresses can be provided via an IP address pool defined in the VMware Cloud Builder parameter file or via Dynamic Host Configuration Protocol (DHCP). Whenever a new cluster node is added to Cloud Foundation, a new tunnel endpoint is created which requires an IP address.

If DHCP is selected, place the DHCP server (or VM) on a reliable and well-maintained part of your infrastructure. The validation process checks to ensure that an IP address pool is being provisioned or that a DHCP server is available on the VXLAN network as specified in the parameter sheet. Validation fails if no IP address pool is provisioned or there is no DHCP response on the VXLAN network.

Time synchronization is critical to the VMware Cloud Foundation stack. All hosts and the Cloud Builder VM are synchronized to a reference time source before attempting to run the validation phase of the Cloud Builder process. Network Time Protocol (NTP) traffic is routed from client to source or it can travel over the same L2 network.

Cloud Foundation requires seven networks and at least one connection to a customer network (for external access to your Cloud Foundation stack). In the following example, a private IP address range is used for all connectivity within the management stack. There is also an IP network that connects back to an external network.

Each of these networks is propagated to the Cloud Foundation stack using tagged VLANs. Using tagged VLANs enables mapping of port groups to VLANs, allowing access to resources as needed. All of these networks are routable to and from each other. The routing task is executed at some layer above the access level switched fabric that is deployed here.

The networks required to deploy Cloud Foundation are listed in the following table:

Installing physical hardware to provide additional network interfaces in an MX7000 chassis environment requires the installation of devices into the B fabric of the MX7000 chassis. More MX9116n IOMs are installed into slots B1 and B2 on the rear of the chassis. Extra network mezzanine cards are installed into the B connector of each of MX740c compute sleds to interface with the B fabric IOMs.

Installing dedicated hardware provides better throughput, lower latency, and simplified monitoring of network performance and metrics.

Deploying Dell Networking MX9116n Fabric Switching Engines (FSEs) and Networking MX7116n Fabric Expansion Modules (FEMs) is a different process. The FSEs are installed into the A1 fabric of the first chassis and the A2 fabric of the second chassis. The FEMs are distributed across both PowerEdge MX7000 chassis in the remaining A fabric slots. The FEMs connect back to the FSEs using a double data rate, 200 Gbps cable. The connection between the compute sleds and the MX modular switches do not use any kind of link aggregation protocol. Additional PowerEdge MX7000 chassis (up to 8 more) can be added and require only the MX7116n FEMs in the A1 and A2 fabric slots. The additional ports available for uplink make the MX9116n an excellent choice for the deployment of VMware NSX-T edge nodes. Since NSX-T is now a part of Cloud Foundation 4.0, we place the emphasis of this document on the MX9116n Scalable Fabric Architecture.

The connections from the modular switches to the external network are implemented using Virtual Link Trunking (VLT) link aggregation. VLT allows you to create a single LACP-managed link aggregation from the two modular switches to an LACP-managed aggregation in the external network. Use the link aggregation only on the link between the modular switches and the customer network.

Configuring jumbo frames is a best practice for both VMware vMotion and vSAN networks, both of which are core components of Cloud Foundation. All the switch ports on the modular switches and up to the aggregation switches used to connect multiple Dell PowerEdge MX7000 chassis enclosures together must be configured for jumbo frames. It is also recommended to configure jumbo frames on the VXLAN network. The validation phase run as part of the Cloud Foundation installation process tests end-to-end connectivity of all specified devices, but fails if the jumbo frames are not correctly configured.

• MX9116n Fabric Switching Engine (FSE)
• MX9116n FSE and MX7116n Fabric Expander Module (FEM)
• MX5108n

To create a SmartFabric using the OME-M console, follow the instructions in the Create the SmartFabric section in the SmartFabric Creation chapter of the Dell EMC PowerEdge MX Networking Deployment Guide.

A SmartFabric is a logical entity that consists of a collection of physical resources (such as servers and switches) and logical resources (such as networks, templates, and uplinks). In this step, a single SmartFabric is designed for the deployment.

This example with two chassis uses the design type of two MX9116n FSEs in different chassis.

Associate network with server template

The templates that you created must be associated with the networks. VLANs set as tagged or untagged will be applied to the settings of the other compute sleds when the templates are deployed.

To associate the networks with a template, see the Deploy a server template section of the Server Deployment chapter in the Dell EMC PowerEdge MX Networking Deployment Guide.

Deploy server template

Deploy the server templates to apply the settings and parameters to the compute sleds. After a server template deployment, the interfaces on the switch are updated automatically. SmartFabric configures each interface with untagged and tagged VLANs along with associated QoS settings.

To deploy the server template, follow the instructions in the Deploy a server template section of the Server Deployment chapter in the Dell EMC PowerEdge MX Networking Deployment Guide.

A server profile is a combination of template and identity settings that are applied to a specific server or multiple servers. When the server template is deployed successfully, OME-M automatically creates and applies a server profile to that template. OME-M also allows you to manually create a server profile that you can apply to the designated compute sleds. Instead of deleting and recreating server templates, profiles can be used to deploy with modified attributes on server templates. A single profile can be applied to multiple server templates with modified attributes, or all attributes.

Profile deployment

PowerEdge MX environment supports Profiles with OME-M 1.30.00 and later. OME-M creates and automatically assigns a profile once the server template is deployed successfully. If the server template is not deployed, OME–M allows user to create server profiles and apply them to compute sled or slot.

To create and assign a server profile, follow the instructions in the Profile deployment section of the Server Deployment chapter in the Dell EMC PowerEdge MX Networking Deployment Guide.

VMware Cloud Foundation uses Active Directory (AD) for authentication and authorization to resources. The AD services must be reachable by the components that are connected to the management and vRealize networks.

You must configure user and group accounts in AD before adding them to the SDDC manager and assigning privileges.

VMware Cloud Foundation can use either Dynamic Host Configuration Protocol (DHCP) or static IP address pools to automatically configure each VM kernel port of an ESXi host that is used as a TEP with an IPv4 address. One DHCP scope must be defined and made available for this purpose.

The DHCP scope or IP address pool that is defined should be large enough to accommodate all of the initial and future servers that are used in the Cloud Foundation solution. Each host requires two IP addresses, one for each TEP configured.

During deployment, you must provide the DNS domain information to be used to configure the various components. The root DNS domain information is required and, optionally, you can also specify subdomain information.

DNS resolution must be available for all the components that are contained within the VMware Cloud Foundation solution, which includes servers, virtual machines, and any virtual IPs that are used. For more information on the components that are required for DNS resolution before starting a Cloud Foundation deployment, see Host names and IP addresses.

Ensure that both forward and reverse DNS resolutions are functional for each component before deploying Cloud Foundation or creating any workload domains.

All components must be synchronized against a common time provider by using the Network Time Protocol (NTP) on all nodes. Important components of VMware Cloud Foundation, such as vCenter Single Sign-On (SSO), are sensitive to a time drift between distributed components. Synchronized time between the various components also assists with troubleshooting.

The components of the SDDC require SSL certificates for secure operation. During deployment, self-signed certificates are used for each of the deployed components. These certificates can be replaced with certificates that are signed by an internal enterprise certificate authority (CA) or by a third-party commercial CA.

If you plan to replace the self-signed certificates, the CA must be able to sign a Certificate Signing Request (CSR) and return the signed certificate. All endpoints within the enterprise must also trust the root CA of the CA.

If you plan to deploy vRealize Automation, a CA is required, and the certificates are required during installation.

Before deploying VMware Cloud Foundation, configure the physical network to enable the following features:

• VLAN Tagging (802.1Q)
• Jumbo frames
  • A minimum MTU value of 1600 is required, however it is recommended that you set the MTU to 9216.

Cloud Foundation uses a construct that is called a network pool to automatically configure VM kernel ports for vSAN, NFS, and vMotion.

Cloud Foundation uses an Internet Protocol Address Management (IPAM) solution to automate the IP configuration of VM kernel ports for vMotion, vSAN, and NFS (depending on the storage type being used).

When a server is added to the inventory of Cloud Foundation, it goes through a process called host commissioning. During this process, the hosts are associated with an existing network pool. When the host is provisioned during the create VI workload domain, add cluster, or add host workflow, it automatically configures the VMkernel ports and allocates IP addresses for vMotion, vSAN, and NFS from the network pool the host was associated with.

You can expand the included IP address range of a network pool at any time, however you cannot modify the other network information. Ensure that you have defined each subnet in the network pool to account for current and future growth in your environment.

Network traffic types within VMware Cloud Foundation are isolated from each other by using VLANs. Before deploying your SDDC, you must allocate VLAN IDs and IP subnets for each required traffic type. Configure the VLAN IDs and IP subnets in your network to pass traffic through your network devices. Before you start the Cloud Foundation deployment, verify that the allocated network information is configured and does not conflict with pre-existing services before starting your Cloud Foundation deployment.

The following table lists the basic allocation of VLANs and IP subnets for a sample deployment. Use this sample to define the VLANs and IP subnets in your environment.

Before deploying a VMware Cloud Foundation, or creating or expanding a workload domain, you must define the hostnames and IP addresses for various system components.

Most of the defined hostnames and IP addresses need to exist in DNS and be resolvable, through forward and reverse lookups.

The following table provides sample information for the external services. This example uses a DNS domain called osevcf17.local for illustration purposes. Modify the sample information to conform to the configuration of your site.

Most of the virtual infrastructure components that are installed by VMware Cloud Foundation require their hostnames and IP addresses to be defined before deployment.

During the initial deployment of Cloud Foundation, the management domain is created and you must define components specific to the management domain before installation.

After the initial deployment, additional workload domains are created and you must define components specific to each additional workload domain.

Planning ahead for the initial deployment and the workload domains to be created avoids delays in deployment.

The following table provides an example of the information for the virtual infrastructure layer using the standard deployment model with a single workload domain. This example uses a DNS domain called osevcf17.local for illustration purposes. Modify the sample information to conform to the configuration of your site.

• Dell OME-Modular and iDRAC IP addresses or FQDNs
• OME-Modular and iDRAC credentials
• iDRAC Enterprise license that is applied on all nodes
• Dell -customized ESXi image
• Host names, Management VLAN ID, IP address information
• Credentials for vSphere
• Hostnames added to DNS server

    admin@cloudbuilder [ ~ ]$ ntpq -p
remote refid st t when poll reach delay offset jitter
============================================================================
*ntp.osevcf.loca 143.166.226.32 2 u 588 1024 377 0.264 -0.134 0.137
   

• Cloud Builder OVA file with version and build numbers specified in the Validated components section must be deployed to an available ESXi host outside of the Cloud Foundation target nodes with network access to the Cloud Foundation Management VLAN.
• Target hardware certified on VMware Compatibility Guide (VCG) with appropriate firmware versions are specified in the Validated components section.
• Clean install of ESXi on each target server node, with SSH/NTP/DNS enabled and configured.
• Physical switches configured with jumbo frames and necessary VLANs.
• All prior sections are reviewed and any listed steps completed.
• A completed parameter sheet (can be downloaded during the CloudBuilder process.

This worksheet is incorporated into the Cloud Builder VM and specific version of Cloud Foundation that is deployed. Save the worksheet to a safe location and edit the file modifying the information to match your deployment environment.

• ESXi hosts
• vSAN
• vCenter
• NSX-T
• SDDC Manager Appliance

In the Users and Groups tab, you can set the passwords for your initial  VMware  Cloud Foundation components.

• Specify the VLAN IDs, subnets, gateways, and MTU for the networks that are used for the four required  VMware Cloud Foundation networks.
  • The MTU value should be the MTU size that can be tested during validation. For an actual MTU value of 9000 set this value to 9000.
• Specify the management IP addresses of the deployed hosts which are on the Cloud Foundation management VLAN.
• Specify the range of IP addresses for both the vSAN and vMotion networks.
• Host names that you enter in the Management Domain ESXi Hosts section are also auto-populated in the ESXi Host column of the ESXi Host Security Thumbprint section.

By default, use of DSA fingerprints as a more secure method to validate a host's authenticity is optional and disabled. Unique fingerprints are automatically generated on each host during installation. You can view the fingerprints using the DCUI under View Support Information. Due to the complexity of fingerprints, it is easier to access the hosts using SSH where they can be copied and pasted into the cloud builder deployment parameter sheet. Change the Validate ESXi Thumbprints option to Yes to enable fingerprint validation.

• All the hostnames must be configured for forward and reverse look-ups.
• Test all the hostnames before attempting validation.
• Ensure that all the values provided are consistent with the values used to deploy the  VMware  Cloud Builder VM.
• The NTP server would have already been tested as the ESXi hosts have already been configured to this same NTP server(s).
• Change the hostnames that are listed and the domain that meets the customer required specifications.
• For a simplified network installation where a multi-tiered BGP environment is not available make sure that field K27 is set to No.

Log in to  VMware  SDDC Manager using a web browser at: https://<ip address or DNS name>. The SSO user ID is  administrator@vsphere.local  and the password is the one you specified during installation.

Join  VMware  Customer Experience Improvement Program (CEIP) when prompted. CEIP provides statistical data to SDDC Manager, allowing for improved performance and troubleshooting.

The following figure shows a sample SDDC Manager dashboard. In this example, the host usage is yellow because the management cluster has consumed all of the hosts currently available to Cloud Foundation.

Validate that the VMs created during deployment are all up and running. Validate that your VSAN is running and available. Look at the disk groups that are created and ensure they are consistent with the disks available in the hosts. Look at the virtual networking components that are deployed to vCenter.

• Configure your VMware account credentials in SDDC manager
• If you chose simplified networking, configure your SDDC for VLAN backed Application Virtual Networks
• Install additional products such as:
  • Life Cycle Manager
  • vRealize Suite
  • Other licensed bundles.
• Deploy a Workload Domain

Upgrading  VMware  ESXi 7.0 U2 from A05 to Patch 7.0 U2c with ESXCLI fails when you run the following command:

Sample log entries:

. . .
. . .
2021-10-27T14:01:11Z esxupdate: 2193582: root: ERROR: Traceback (most recent call last):
2021-10-27T14:01:11Z esxupdate: 2193582: root: ERROR: File "/usr/lib/vmware/esxcli-software", line 794, in <module>
2021-10-27T14:01:11Z esxupdate: 2193582: root: ERROR: main()
2021-10-27T14:01:11Z esxupdate: 2193582: root: ERROR: File "/usr/lib/vmware/esxcli-software", line 785, in main
2021-10-27T14:01:11Z esxupdate: 2193582: root: ERROR: ret = CMDTABLE[command](options)
2021-10-27T14:01:11Z esxupdate: 2193582: root: ERROR: File "/usr/lib/vmware/esxcli-software", line 252, in ProfileUpdateCmd
2021-10-27T14:01:11Z esxupdate: 2193582: root: ERROR: res = t.UpdateProfileFromDepot([], opts.profile, depotUrls=depoturls,
2021-10-27T14:01:11Z esxupdate: 2193582: root: ERROR: File "/lib64/python3.8/site-packages/vmware/esximage/Transaction.py", line 353, in UpdateProfileFromDepot
2021-10-27T14:01:11Z esxupdate: 2193582: root: ERROR: patcherVibs = _getPatcherForProfileCmd(profileName,
2021-10-27T14:01:11Z esxupdate: 2193582: root: ERROR: File "/lib64/python3.8/site-packages/vmware/esximage/Transaction.py", line 2550, in _getPatcherForProfileCmd
2021-10-27T14:01:11Z esxupdate: 2193582: root: ERROR: newProfile, _ = Transaction.GetProfileAndCompsFromSources(
2021-10-27T14:01:11Z esxupdate: 2193582: root: ERROR: File "/lib64/python3.8/site-packages/vmware/esximage/Transaction.py", line 1437, in GetProfileAndCompsFromSources
2021-10-27T14:01:11Z esxupdate: 2193582: root: ERROR: raise Errors.NoMatchError(profilename,
2021-10-27T14:01:11Z esxupdate: 2193582: root: ERROR: vmware.esximage.Errors.NoMatchError: ('VMware-ESXi-7.0U2c-18426014', "No image profile found with name 'VMware-ESXi-7.0U2c-18426014'")
   

Resolution

Run the following command:

Alternatively, upgrade ESXi with another method, such as vLCM.

While updating the  VMware  ESXi 7.0 U2 host to ESXi 7.0 U2c, the upgrade might fail and the following entries might be logged in the  esxupdate.log  file:

2021-10-29T14:11:21Z esxupdate: 2102510: esxupdate: ERROR: File /tmp/esx-update-2102510/lib64/python3.8/site-packages/vmware/esximage/Transaction.py, line 928, in checkBaseImageUpgrade
2021-10-29T14:11:56Z esxupdate: 2102510: esxupdate: ERROR: esximage.Errors.InstallationError: This upgrade transaction would skip ESXi Base Image VIB(s) VMW_bootbank_i40en_1.11.1.31-1vmw.703.0.0.49537716, which could cause failures post upgrade. Please use an alternative upgrade method that would install the above VIB(s). For example, use an image profile instead of VIBs to perform the upgrade.
   

NTP settings

DNS settings

MTU settings

Configure VLAN ID on a portgroup

Enable the CEIP (Customer Experience Improvement Program)

Install depot files

Depot files are installed from the command line. Depot files must first be copied on to the server. There are many utilities that can be used to copy the depot file to the ESXi host. After the file has been copied, the following command will apply the updates contained in the depot file. The installation of the depot file update will not be complete until the host is rebooted.

Maintenance mode

MX7K-IOM-A2# show switch-operating-mode
MX7K-IOM-A2# Switch-Operating-Mode : Full Switch Mode   

    interface vlan1711
description 1711-Mgmt
no shutdown
mtu 9216
interface vlan1712
description 1712-VMotion
no shutdown
mtu 9216
interface vlan1713
description 1713-VSAN
no shutdown
mtu 9216
interface vlan1714
description 1714-host-overlay
no shutdown
mtu 9216
interface vlan2711
description 2711-Uplink1
no shutdown
mtu 9216
interface vlan2712
description 2712-Uplink2
no shutdown
mtu 9216
interface vlan2713
description Edge-Overlay
no shutdown
mtu 9216
   

VLTi ports are specified during the configuration of the VLT domain by specifying the interconnect ports as discovery interfaces. The resulting VLTi port group cannot be managed manually. The VLT domain must be created on both VLT peer switches.

To configure the ethernet1/1/37 through 1/1/40 ports, ensure that the:

• Ports are preconfigured correctly.
• Ports are set to the correct frame size.
• Ports are not set in any switchport (VLAN) mode.
• Ports are not shut down.

 interface ethernet1/1/40
 no shutdown
 no switchport
 mtu 9216
 flowcontrol receive off
   

MX9116-A1(config)#
MX9116-A1(config)# vlt-domain 10
MX9116-A1(conf-vlt-100)# discovery-interface ethernet1/1/37,1/1/38,1/1/39,1/1/40
MX9116-A1(conf-vlt-10)# backup destination 100.71.242.220
MX9116-A1(conf-vlt-10)# exit   

MX9116-A1# show vlt 10
Domain ID : 10
Unit ID : 2
Role : secondary
Version : 2.3
Local System MAC address : 3c:2c:30:80:a8:80
Role priority : 32768
VLT MAC address : aa:bb:cc:11:11:11
IP address : fda5:74c8:b79e:1::2
Delay-Restore timer : 90 seconds
Peer-Routing : Disabled
Peer-Routing-Timeout timer : 0 seconds
VLTi Link Status
 port-channel1000 : up
VLT Peer Unit ID System MAC Address Status IP Address Version
----------------------------------------------------------------------------------
 1 3c:2c:30:80:aa:80 up fda5:74c8:b79e:1::1 2.3
MX9116-A1# show port-channel summary
Flags: D - Down I - member up but inactive P - member up and active
 U - Up (port-channel) F - Fallback Activated
--------------------------------------------------------------------------------
Group Port-Channel Type Protocol Member Ports
--------------------------------------------------------------------------------
1 port-channel1 (D) Eth DYNAMIC 1/1/41(P) 1/1/42(P)
1000 port-channel1000 (U) Eth STATIC 1/1/37(P) 1/1/38(P) 1/1/39(P) 1/1/40(P)
   

MX9116-A1#
MX9116-A1# show port-channel summary
Flags: D - Down I - member up but inactive P - member up and active
 U - Up (port-channel) F - Fallback Activated
--------------------------------------------------------------------------------
Group Port-Channel Type Protocol Member Ports
--------------------------------------------------------------------------------
1000 port-channel1000 (U) Eth STATIC 1/1/37(P) 1/1/38(P) 1/1/39(P) 1/1/40(P)
MX9116-A1#
   

A VLT link aggregation is created by creating a VLT port channel on each of the MX9116N switches. First create the uplink VLT port channel on both switches and assign the appropriate VLANs.

Here are the port channels that are created on switch one:

MX9116-A1# show running-configuration interface port-channel 1
!
interface port-channel1
 description "Uplink to DataCenter"
 no shutdown
 switchport mode trunk
 switchport trunk allowed vlan 96, 1711-1714, 2711-2713
 mtu 9216
 vlt-port-channel 1
MX9116-A1# show port-channel summary
Flags: D - Down I - member up but inactive P - member up and active
 U - Up (port-channel) F - Fallback Activated
--------------------------------------------------------------------------------
Group Port-Channel Type Protocol Member Ports
--------------------------------------------------------------------------------
1 port-channel1 (D) Eth DYNAMIC 1/1/41(P) 1/1/42(P)
1000 port-channel1000 (U) Eth STATIC 1/1/37(P) 1/1/38(P) 1/1/39(P) 1/1/40(P)
MX9116-A1#
   

MX9116-A1# show running-configuration interface port-channel 1
!
interface port-channel1
 description "Uplink to DataCenter"
 no shutdown
 switchport mode trunk
 switchport access vlan 1
 switchport trunk allowed vlan 96, 1711-1714, 2711-2713
 mtu 9216
 vlt-port-channel 1
    

On switch one:

MX9116-A2(config)# 
MX9116-A2(config)# interface range ethernet 1/1/1-1/1/16
MX9116-A2(conf-range-eth1/1/1-1/1/16)# switchport mode trunk
MX9116-A2(conf-range-eth1/1/1-1/1/16)# switchport trunk allowed vlan 96, 1711-1714, 2711-2713
MX9116-A2(conf-range-eth1/1/1-1/1/16)# mtu 9216
MX9116-A2(conf-range-eth1/1/1-1/1/16)# no shutdown
MX9116-A2(conf-range-eth1/1/1-1/1/16)# exit
MX9116-A2(config)#
   

On switch two:

MX9116-A2(config)# 
MX9116-A2(config)# interface range ethernet 1/1/1-1/1/16
MX9116-A2(conf-range-eth1/1/1-1/1/16)# switchport mode trunk
MX9116-A2(conf-range-eth1/1/1-1/1/16)# switchport trunk allowed vlan 96, 1711-1714, 2711-2713
MX9116-A2(conf-range-eth1/1/1-1/1/16)# mtu 9216
MX9116-A2(conf-range-eth1/1/1-1/1/16)# no shutdown
MX9116-A2(conf-range-eth1/1/1-1/1/16)# exit
   

Save your switch configuration on each MX9116N switch using the following command:

MX9116-A2(config)# do write mem   

• All required VLANs and subnets
• VLT Domain
• VLTi
• VLT Link Aggregations
• Link Aggregations
• Host facing ports

For more information about PowerEdge baselines, refer to Dell PowerEdge MX7000 Solution Baselines.

The Dell EMC OpenManage Enterprise-Modular Edition for PowerEdge MX7000 Chassis User's Guide provides information on new and previous versions of  Dell  MX7000 components. To find the version table, refer to the MX7000 Solution Baselines section in the chapter Updating firmware for PowerEdge MX solution.

The MX7000 Chassis baseline information can also be found in the Networking Support & Interoperability Matrix.