Users Guide
Table Of Contents
- Table of Contents
- Preface
- 1 Functionality and Features
- 2 Configuring Teaming in Windows Server
- 3 Virtual LANs in Windows
- 4 Installing the Hardware
- 5 Manageability
- 6 Boot Agent Driver Software
- 7 Linux Driver Software
- Introduction
- Limitations
- Packaging
- Installing Linux Driver Software
- Load and Run Necessary iSCSI Software Components
- Unloading or Removing the Linux Driver
- Patching PCI Files (Optional)
- Network Installations
- Setting Values for Optional Properties
- Driver Defaults
- Driver Messages
- bnx2x Driver Messages
- bnx2i Driver Messages
- BNX2I Driver Sign-on
- Network Port to iSCSI Transport Name Binding
- Driver Completes Handshake with iSCSI Offload-enabled C-NIC Device
- Driver Detects iSCSI Offload Is Not Enabled on the C-NIC Device
- Exceeds Maximum Allowed iSCSI Connection Offload Limit
- Network Route to Target Node and Transport Name Binding Are Two Different Devices
- Target Cannot Be Reached on Any of the C-NIC Devices
- Network Route Is Assigned to Network Interface, Which Is Down
- SCSI-ML Initiated Host Reset (Session Recovery)
- C-NIC Detects iSCSI Protocol Violation - Fatal Errors
- C-NIC Detects iSCSI Protocol Violation—Non-FATAL, Warning
- Driver Puts a Session Through Recovery
- Reject iSCSI PDU Received from the Target
- Open-iSCSI Daemon Handing Over Session to Driver
- bnx2fc Driver Messages
- BNX2FC Driver Signon
- Driver Completes Handshake with FCoE Offload Enabled C-NIC Device
- Driver Fails Handshake with FCoE Offload Enabled C-NIC Device
- No Valid License to Start FCoE
- Session Failures Due to Exceeding Maximum Allowed FCoE Offload Connection Limit or Memory Limits
- Session Offload Failures
- Session Upload Failures
- Unable to Issue ABTS
- Unable to Recover the IO Using ABTS (Due to ABTS Timeout)
- Unable to Issue I/O Request Due to Session Not Ready
- Drop Incorrect L2 Receive Frames
- Host Bus Adapter and lport Allocation Failures
- NPIV Port Creation
- Teaming with Channel Bonding
- Statistics
- Linux iSCSI Offload
- 8 VMware Driver Software
- Introduction
- Packaging
- Download, Install, and Update Drivers
- Driver Parameters
- FCoE Support
- iSCSI Support
- 9 Windows Driver Software
- Supported Drivers
- Installing the Driver Software
- Modifying the Driver Software
- Repairing or Reinstalling the Driver Software
- Removing the Device Drivers
- Viewing or Changing the Properties of the Adapter
- Setting Power Management Options
- Configuring the Communication Protocol to Use with QCC GUI, QCC PowerKit, and QCS CLI
- 10 Citrix XenServer Driver Software
- 11 iSCSI Protocol
- iSCSI Boot
- Supported Operating Systems for iSCSI Boot
- iSCSI Boot Setup
- Configuring the iSCSI Target
- Configuring iSCSI Boot Parameters
- MBA Boot Protocol Configuration
- iSCSI Boot Configuration
- Enabling CHAP Authentication
- Configuring the DHCP Server to Support iSCSI Boot
- DHCP iSCSI Boot Configuration for IPv4
- DHCP iSCSI Boot Configuration for IPv6
- Configuring the DHCP Server
- Preparing the iSCSI Boot Image
- Booting
- Other iSCSI Boot Considerations
- Troubleshooting iSCSI Boot
- iSCSI Crash Dump
- iSCSI Offload in Windows Server
- iSCSI Boot
- 12 Marvell Teaming Services
- Executive Summary
- Teaming Mechanisms
- Teaming and Other Advanced Networking Properties
- General Network Considerations
- Application Considerations
- Troubleshooting Teaming Problems
- Frequently Asked Questions
- Event Log Messages
- 13 NIC Partitioning and Bandwidth Management
- 14 Fibre Channel Over Ethernet
- Overview
- FCoE Boot from SAN
- Preparing System BIOS for FCoE Build and Boot
- Preparing Marvell Multiple Boot Agent for FCoE Boot (CCM)
- Preparing Marvell Multiple Boot Agent for FCoE Boot (UEFI)
- Provisioning Storage Access in the SAN
- One-Time Disabled
- Windows Server 2016/2019/Azure Stack HCI FCoE Boot Installation
- Linux FCoE Boot Installation
- VMware ESXi FCoE Boot Installation
- Booting from SAN After Installation
- Configuring FCoE
- N_Port ID Virtualization (NPIV)
- 15 Data Center Bridging
- 16 SR-IOV
- 17 Specifications
- 18 Regulatory Information
- 19 Troubleshooting
- Hardware Diagnostics
- Checking Port LEDs
- Troubleshooting Checklist
- Checking if Current Drivers Are Loaded
- Running a Cable Length Test
- Testing Network Connectivity
- Microsoft Virtualization with Hyper-V
- Removing the Marvell 57xx and 57xxx Device Drivers
- Upgrading Windows Operating Systems
- Marvell Boot Agent
- Linux
- NPAR
- Kernel Debugging Over Ethernet
- Miscellaneous
- A Revision History
12–Marvell Teaming Services
Executive Summary
Doc No. BC0054508-00 Rev. R
January 21, 2021 Page 146 Copyright © 2021 Marvell
The following information provides a high-level overview of the concepts of
network addressing used in an Ethernet network. Every Ethernet network
interface in a host platform, such as a computer system, requires a globally
unique Layer 2 address and at least one globally unique Layer 3 address. Layer 2
is the data link layer, and Layer 3 is the network layer as defined in the OSI model.
The Layer 2 address is assigned to the hardware and is often referred to as the
MAC address or physical address. This address is pre-programmed at the factory
and stored in NVRAM on a network interface card or on the system motherboard
for an embedded LAN interface. The Layer 3 addresses are referred to as the
protocol or logical address assigned to the software stack. IP and IPX are
examples of Layer 3 protocols. In addition, Layer 4 (Transport Layer) uses port
numbers for each network upper level protocol such as Telnet or FTP. These port
numbers are used to differentiate traffic flows across applications. Layer 4
protocols such as TCP or UDP are most commonly used in today’s networks. The
combination of the IP address and the TCP port number is called a socket.
Ethernet devices communicate with other Ethernet devices using the MAC
address, not the IP address. However, most applications work with a host name
that is translated to an IP address by a naming service such as Windows Internet
Name Service (WINS) and DNS. Therefore, a method of identifying the MAC
address assigned to the IP address is required. The address resolution protocol
for an IP network provides this mechanism. For IPX, the MAC address is part of
the network address and ARP is not required. ARP is implemented using an ARP
Request and ARP Reply frame. ARP Requests are typically sent to a broadcast
address while the ARP Reply is typically sent as unicast traffic. A unicast address
corresponds to a single MAC address or a single IP address. A broadcast address
is sent to all devices on a network.
Teaming and Network Addresses
A team of adapters function as a single virtual network interface and does not
appear any different to other network devices than a non-teamed adapter. A
virtual network adapter advertises a single Layer 2 and one or more Layer 3
addresses. When the teaming driver initializes, it selects one MAC address from
one of the physical adapters that make up the team to be the Team MAC address.
This address is typically taken from the first adapter that gets initialized by the
driver. When the system hosting the team receives an ARP request, it selects one
MAC address from among the physical adapters in the team to use as the source
MAC address in the ARP Reply. In Windows operating systems, the IPCONFIG
/all command shows the IP and MAC address of the virtual adapter and not the
individual physical adapters. The protocol IP address is assigned to the virtual
network interface and not to the individual physical adapters.