Test Plan: Network Controller Certification Level 2

### Network Controller Certification
Level 2 Test Plan

  Introduction
  Required Hardware and Software

  Required Hardware Configuration

  System Configuration I
  System Configuration II

  Required Software Configuration
  Test Network Setup

  Hardware Certification Tests

  Manual Tests
  Automated Tests

### Introduction

This document provides detailed descriptions of the manual network controller certification tests. After you successfully complete the manual tests described in this document, use the HCTS to run the automated tests.

These Level 2 tests provide greater test coverage than the Level 1 tests. See Network Level 1 Tests and Network Level 2 Tests for further details.

When a driver supports multiple controllers, the controller that supports the most extensive feature set is designated the primary controller. Additional controllers supported by the same device driver are known as supplementary controllers.

The tests described in this document are used for one of these two purposes:

- Functional testing of controllers at Level 2
- Certifying the primary controller that has supplementary controllers supported by the same driver under test

Note: The tests described in the Network Controller Certification Level 1 Test Plan are for functional testing of controllers at Level 1 or for certifying any supplementary controllers that are supported by the same driver under test as a primary controller.

These tests require two systems.

1. Run all tests from the test manager system. The test manager system is System Configuration I.
2. Run all tests on the system under test. The system under test is System Configuration II.

In this testing, the system under test serves data to the test manager system. In this way, the test manager system is a client of the system under test.

### Required Hardware and Software

Make sure both systems meet the general hardware and software requirements for all certifications stated in the Hardware Certification Test Suite Installation Guide.

This section describes additional hardware and software required to execute the network controller certification tests.

#### Required Hardware Configuration

System Configuration I

This is the hardware configuration required for the test manager system.

The minimum requirements for this configuration are as follows:

- System
  - One single-processor machine that meets the minimum requirements stated in the Hardware Certification Test Suite Installation Guide
  - Diskette drive
- Controllers
  - One network controller supported by the driver under test
- Devices
  - At least one disk drive that is at least 3 Gbytes in size

System Configuration II

This is the hardware configuration required for the system under test.

The minimum requirements for this configuration are as follows:

- System
  - One dual-processor or quad-processor machine that meets the minimum requirements stated in the Hardware Certification Test Suite Installation Guide. A quad-processor is recommended.
  - PCI slot behind a PCI-to-PCI bridge
  - Diskette drive
- Controllers
  - Multiple network controllers supported by the driver under test (see Maximum Number of Controllers Test)
- Devices
  - At least one disk drive that is at least 3 Gbytes in size

Back to Top

#### Required Software Configuration

This is the required software configuration for both the system under test and the test manager system.

- At least 500 Mbytes for `/` (root)
- At least 1 Gbyte for `/export/home` for single-processor machines
- At least 1.5 Gbytes for `/export/home` for multi-processor machines
- At least 3 Gbytes for `/export/home` for dual port NIC certification
- At least 6 Gbytes for `/export/home` for quad port NIC certification
- The size of the `/swap` slice in each test machine must be at least twice the amount of RAM in the machine.
- SUNWpkgd. Click on the "Download" line near the top of the Solaris Third-Party Packaging Tools page to download the SUNWpkgd package. To install the SUNWpkgd package, see Installing the SUNWpkgd Tools.

Back to Top

#### Test Network Setup

Both test machines must be configured on their own private network. They should be isolated as much as possible from any other systems. The test environment must be customized for the particular network technology being tested. Only the one network card under test should be configured. Do not configure multiple cards or logical interfaces or virtual interfaces.

HCTS supports single port NIC and multiport NIC certification. For multiport NIC, HCTS supports dual port and quad port NIC certification.

For multiport NIC certification, you must configure each port of the multiport NIC. The IP bound to each port must be in a different subnet.

If you enable IPv6 certification, you do not need to configure the IPv6 interface. HCTS automatically configures IPv6 interfaces.

Fast Ethernet

- All machines are connected to a hub or switch.

- When switches are used, set the ports to different speeds (for example, 10/100 Mbps or 1000 Mbps for Ethernet) and vary the transmission type (for example, full-duplex, half-duplex, or auto-negotiate).

Gigabit Ethernet

- All machines are connected to a switch.

Notes:

1. Do not use NIS (Network Information Service). You might encounter problems if you use NIS.

2. Set up the IP addresses for the system under test and the test manager system in the same subnet.

3. Set up the IP addresses for each port on a multiport NIC in different subnets.

4. Both system hostnames must be resolved on both systems. On the system under test, add the test manager system hostname to the `/etc/hosts` file. On the test manager system, add the system under test hostname to the `/etc/hosts` file.

5. If the Solaris version is 10 or later, make sure the `NFSMAPID_DOMAIN` in `/etc/default/nfs` is set to the same domain name for both the system under test and the test manager system.

For example, to set `NFSMAPID_DOMAIN` to `sun.com`, manually edit `/etc/default/nfs` as follows:

Change:

    #NFSMAPID_DOMAIN=domain

to:

    NFSMAPID_DOMAIN=sun.com

Then do the following restart the nfsmapid daemon:

    # pkill -HUP nfsmapid

Back to Top

### Hardware Certification Tests

These tests require two systems. Run all tests from the test manager system. The test manager system is System Configuration II. Run all tests on the system under test. The system under test is System Configuration I.

Run all tests as user `root` unless otherwise indicated in the HCTS test ReadMe file.

#### Manual Tests

First run the set of tests for all controllers, then run the tests specific to the network technology of the controller under test.

All Controllers

- Verify Driver Diskette Format and Contents
- Installation
  - Pre-Boot Execution Environment Test
  - Testing Driver Installation on a System Running Solaris
- Driver Post-Installation Checklist
- Cable Pull Test
- Behind PCI Bridge Test
- Using Different Slots Test
- Maximum Number of Controllers Test
- Missing Controller Test

Fast Ethernet

- Auto-Negotiate Connection Speed Test [1]
- Auto-Negotiate Connection Duplex Test

Gigabit Ethernet

- Auto-Negotiate Connection Speed Test [1]

[1] This test is required only if it is supported by the controller under test.

Note: For multiport NIC certification, apply the above procedures to all ports on the multiport NIC if applicable.

Back to Top

#### Verify Driver Diskette Format and Contents

You only need to perform this test if you are doing one of the following:

- Certifying a bootable device driver
- Delivering an ITU for your driver

Required Hardware

- Test machine with a diskette drive

Required Software

- The `audit_itu`(1M) utility, which is in the SUNWpkgd package.

Test Strategy

The `audit_itu`(1M) utility verifies the format and contents of a driver diskette created using `pkg_drv`(1M) or `pkg_drv2patch`(1M).

Test Procedure

1. Insert the driver diskette into the diskette drive.

2. Verify the driver diskette format and contents.

   `# volcheck`
   `# audit_itu`

Expected Results

- No error messages appear.
- The `audit_itu`(1M) command returns a value of 0.

Back to Top

#### Pre-Boot Execution Environment Test

The Pre-Boot Execution Environment (PXE) is one of the components of the open-industry specification Wired for Management (WFM) developed by Intel. This technology allows you to automate client-PC management over a network. PXE enables a system to boot from a server on a network before booting the operating system on the local hard drive.

This test verifies that the Solaris Operating System can be installed through a network using the PXE technology.

Required Hardware

- Installation server with the appropriate Solaris Operating System release installed

- Client to install the Solaris Operating System with a PXE-enabled BIOS and PXE-enabled NIC

- Functional network connection between client and server

Test Strategy

This test involves:

- Testing only one server and one client on the working network.
- Setting up the installation server and DHCP server.
- Configuring the DHCP server for network booting.
- Booting the client to start the PXE installation.

Test Procedure

In this procedure, the examples shown are for Solaris 9. Replace steps as appropriate for your Solaris release.

Before beginning this procedure, you must have the following information.

- IP address of DHCP server
- Name and IP address of the installation server

In addition, you must have already set up the `/etc/netmasks` properly.

Note: In this test procedure, the DHCP server and installation server is set up on one machine. The hostname is `server1`, the IP address is `10.13.22.100`, and the netmask is `255.255.255.0`.

Set Up the Installation Server

1. Create an empty directory on the installation server.

   `# mkdir /export/install/ia_9`

2. Copy the Solaris Operating System into this directory according to the Solaris installation instructions.

Set Up the DHCP Server

1. Configure the DHCP server.

   # `/usr/sbin/dhcpconfig -D -r SUNWbinfiles -p /var/dhcp`

2. Add a DHCP network.

   # `/usr/sbin/dhcpconfig -N 10.13.22.100 -m 255.255.255.0`

3. Add addresses to the DHCP service.
   Multiple addresses can be added with `pntadm` as necessary.

   # `pntadm -A 10.13.22.101 10.13.22.0`

4. Create the DHCP new options.

   `# dhtadm -A -s SrootOpt -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30 SUNW.i86pc,1,ASCII,1,0'
   # dhtadm -A -s SrootIP4 -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30 SUNW.i86pc,2,IP,1,1'
   # dhtadm -A -s SrootNM -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30 SUNW.i86pc,3,ASCII,1,0'
   # dhtadm -A -s SrootPTH -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30 SUNW.i86pc,4,ASCII,1,0'
   # dhtadm -A -s SswapIP4 -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30 SUNW.i86pc,5,IP,1,0'
   # dhtadm -A -s SswapPTH -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30 SUNW.i86pc,6,ASCII,1,0'
   # dhtadm -A -s SbootFIL -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30 SUNW.i86pc,7,ASCII,1,0'
   # dhtadm -A -s Stz -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30 SUNW.i86pc,8,ASCII,1,0'
   # dhtadm -A -s SbootRS -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30 SUNW.i86pc,9,NUMBER,2,1'
   # dhtadm -A -s SinstIP4 -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30 SUNW.i86pc,10,IP,1,1'
   # dhtadm -A -s SinstNM -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30 SUNW.i86pc,11,ASCII,1,0'
   # dhtadm -A -s SinstPTH -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30 SUNW.i86pc,12,ASCII,1,0'
   # dhtadm -A -s SsysidCF -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30 SUNW.i86pc,13,ASCII,1,0'
   # dhtadm -A -s SjumpsCF -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30 SUNW.i86pc,14,ASCII,1,0'
   # dhtadm -A -s Sterm -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30 SUNW.i86pc,15,ASCII,1,0'
   # dhtadm -A -s SbootURI -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30 SUNW.i86pc,16,ASCII,1,0'`

5. Configure DHCP server for network booting by creating the DHCP macro using the following commands:

   `# dhtadm -A -m PXEClient:Arch:00000:UNDI:002001 -d ':BootFile="nbp.SUNW.i86pc"` \
   `:BootSrvA=10.13.22.100:SbootFIL="SUNW.i86pc":'`

   `# dhtadm -A -m SUNW.i86pc -d` \
   `':SinstNM="server1":SinstIP4=10.13.22.100:SinstPTH="/export/install/ia_9":\`
   `SrootNM="server1":SrootIP4=10.13.22.100:SrootPTH="/export/install/ia_9/Solaris_9/Tools/Boot":'`

Configure the Client.

1. In the installation server's Tools directory, set up the installation client:

   `# ./add_install_client -d SUNW.i86pc i86pc`

Reboot the DHCP Server.

1. Use the following command to reboot the DHCP server:

   `# pkill -HUP in.dhcpd`

Boot the Client.

1. Configure the client BIOS as Enabled with PXE.
2. Boot the client to start the PXE installation.

Expected Results

- The client should be booted using the PXE boot process.
- The client should then begin to install Solaris.

References

- PXE: Intel® Preboot Execution Environment (PXE) Specification Version 2.1 [PDF 504K]
- DHCP: Solaris DHCP Service Developer's Guide

Back to Top

#### Testing Driver Installation on a System Running Solaris

Required Hardware

- Test machine with System Configuration II
- Network controller supported by the driver under test

Required Software

- The `audit_itu`(1M) utility, which is in the SUNWpkgd package.

Test Strategy

- This test is performed after the Verify Driver Diskette Format and Contents test, to eliminate the possibility of encountering problems caused by a defective driver diskette.
- The test is performed on a machine running the appropriate Solaris release. The driver under test should not yet be installed.
- The driver is installed on a running system. Then the system is rebooted to create device files. To ensure good results, reinstall the test machine so you start with a system that is free of changes introduced by previous testing.

Test Procedure

1. Verify that the system is running.

2. Install the driver by inserting the driver media.

   - For a realmode driver in `pkg_drv` format, type the following:

     `# volcheck`
     `# /floppy/floppy0/DU/sol_xx/i86pc/Tools/install.sh -i`

     xx is the Solaris release number, for example, `sol_9`.

   - For a protected mode (Solaris) driver in `pkgadd` format, type the following:

     `# volcheck`
     `# cd /floppy/floppy0`
     `# pkgadd -d . $PKG_NAME`

3. Reboot the system, if necessary.

4. Use the Driver Post-Installation Checklist to verify that the driver is installed correctly.

Expected Results

- The driver is installed correctly.
- Other computers connected to the same network as the controller supported by the driver under test are accessible.

Back to Top

#### Driver Post-Installation Checklist

Required Hardware

- Test machine with System Configuration II

Test Strategy

- After a driver is installed, certain files specific to the driver are created and other files are modified. By checking these files, you can determine whether the driver is properly installed.

Test Procedure

1. Verify that one of these two sets of files are present.
   driver_name is the name of the driver under test.

   - `/kernel/drv/`driver_name
   - `/kernel/drv/`driver_name`.conf`
   or:
   - `/platform/i86pc/kernel/drv/`driver_name
   - `/platform/i86pc/kernel/drv/`driver_name`.`conf

2. Verify that entries for the installed driver appear in these files:

   - `/boot/solaris/devicedb/master` (realmode drivers only)
   - `/etc/driver_aliases`
   - `/etc/driver_classes`
   - `/etc/name_to_major`
   - `/etc/path_to_inst`

   For example, to locate the `ncrs` driver entry in the `/etc/name_to_major` file, type:

   `# grep ncrs /etc/name_to_major`
   `ncrs 20`

Expected Results

- The files `/kernel/drv/`driver_name and `/kernel/drv/`driver_name`.conf` exist
  or
  The files `/platform/i86pc/kernel/drv/`driver_name and `/platform/i86pc/kernel/drv/`driver_name`.conf` exist.

- Each of these files contains an entry for the driver installed:

  - `/boot/solaris/devicedb/master` (realmode drivers only)
  - `/etc/driver_aliases`
  - `/etc/driver_classes`
  - `/etc/name_to_major`
  - `/etc/path_to_inst`

Back to Top

#### Cable Pull Test

Required Hardware

- Test machine with System Configuration II

- Network controller(s) supported by the driver under test

- Another machine connected through the network to the test machine, either back-to-back or through a concentrator

Test Strategy

- This test ensures that the driver can survive a boot when the connecting cable is either missing or disconnected while the system is active. The driver should be able to tolerate any loss of connectivity.

Test Procedure

1. Bring down the system.

2. Disconnect all cables belonging to the controller supported by the driver under test.

3. Reboot the system. If any error messages display, verify that they are from the driver and indicate that a cable is disconnected. The system should continue booting normally.

4. Using the `ifconfig` command, verify that the driver has configured the interface properly.

5. Bring down the system.

6. Reconnect the cables that were disconnected in Step 2.

7. Reboot the system; it should boot correctly.

8. Verify that the connection works correctly again.

9. Disconnect the cables while the system is running. The only error messages that should display are those indicating the connection is lost. The system continues working correctly.

10. Attempt a basic network connection, such as `telnet`(1) or `ftp`(1), to another machine. The connection should not be successful, but the rest of the system should be unaffected.

11. Reconnect the cables and attempt a basic connection again. It should succeed.

Expected Results

- Error messages about the missing cable display, but the system continues to boot normally. Any delays caused by the driver searching for the missing connection can be expected. Booting continues normally if the cable is missing.
- If a cable is disconnected and reconnected while Solaris is running, there are no undue effects on the rest of the system, and the connection re-establishes itself when the cable is reconnected.

Back to Top

#### Behind PCI Bridge Test

Required Hardware

- Test machine with System Configuration II

- Network controller supported by the driver under test

- Another machine connected to the controller supported by the driver under test, either through a switch or back-to-back

Note: The multiprocessor machine (see System Configuration II) might be the only one to have a PCI bridge.

Test Strategy

- This test ensures that the controller works correctly when inserted in a PCI slot that is behind a PCI bridge.

Test Procedure

1. Bring down the system and turn off the machine.

2. Open the case and move the controller supported by the driver under test to a slot behind a PCI bridge on the motherboard.

3. Reboot the system. Check that there are no error messages. For some drivers, it might be necessary to reconfigure the network such that the instance of the driver used is different. For example, if the driver is called `abc` and the instance originally used was `abc0`, you might now be using instance `abc1`. If so, rename the host file as appropriate, as shown in this example.

   `# mv /etc/hostname.abc0 /etc/hostname.abc1`

   Then reboot the system again, and check that the controller is configured correctly.

Expected Results

The controller works as before, with no loss of performance or configuration issues.

Back to Top

#### Using Different Slots Test

Required Hardware

- Test machine with System Configuration II

- Network controller supported by the driver under test

- Another machine connected to the controller supported by the driver under test, either through a switch or back-to-back

Test Strategy

This test ensures that the controller works correctly when inserted in any slot in the machine.

Test Procedure

1. Bring down the system and turn off the machine.

2. Open the case and move the controller supported by the driver under test to a different slot on the motherboard.

3. Reboot the system. Verify that there are no error messages. For some drivers, it might be necessary to reconfigure the network such that the instance of the driver used is different. For example, if the driver is called `abc` and the instance originally used was `abc0`, you might now be using instance `abc1`. If so, rename the host file as appropriate, as shown in this example.

   `# mv /etc/hostname.abc0 /etc/hostname.abc1`

   Then reboot the system again, and check that the controller is configured correctly.

4. Repeat this procedure for every slot in the machine.

Expected Results

The controller works as before, with no loss of performance or configuration issues, regardless of the PCI slot used.

Back to Top

#### Maximum Number of Controllers Test

Required Hardware

- Test machine with System Configuration II

- Network controllers supported by the driver under test

- Another machine connected to each controller supported by the driver under test, either through a switch or back-to-back

Test Strategy

This test ensures that the driver can handle a system with all slots in use, such as a router.

Test Procedure

1. Bring down the system and turn off the machine.

2. Open the case and add a network controller of the same type to all vacant PCI slots in the machine.

3. Reboot the system. Check that there are no error messages.

4. Prevent the machine from acting as a router.

   `# touch /etc/notrouter`

5. Configure each additional interface with a separate IP address by using the `ifconfig` command. For example, if the original controller was `abc0` and had address 192.168.10.1, you might configure the next controller using this command.

   `ifconfig abc1 inet 192.168.20.1 netmask + broadcast + up`

6. Check the basic functionality of all controllers. Tests using separate interfaces work correctly in parallel.

Expected Results

All controllers work correctly, with no interference between the interfaces.

Back to Top

#### Missing Controller Test

Required Hardware

- Test machine with System Configuration II

Test Strategy

This test ensures that the driver does not cause a panic or hang the operating system if the corresponding controller is missing.

Test Procedure

1. Bring down the system and turn off the machine.

2. Open the case and remove all network controllers associated with the driver under test.

3. Reboot the system. Check that the only error messages are from the driver, indicating that the controller(s) are missing. The system should then continue booting normally.

Expected Results

There is an error message about the missing controller, but the system continues to boot normally. Any delays caused by the driver searching for the missing controller are not unreasonable.

Back to Top

#### Auto-Negotiate Connection Speed Test

Required Hardware

- Two test machines

- Two network controllers supported by the driver under test, one per test machine

- A 100-Mbps switch supporting 100-Mbps and 10-Mbps transmission or a 1000-Mbps switch supporting 1000-Mbps, 100-Mbps, and 10-Mbps transmission, appropriate for the technology you are testing.

Test Strategy

This test ensures that the driver is capable of automatically detecting the highest transmission speed while the interface is active.

Test Procedure

1. Connect both machines to the 10-Mbps ports or switch, and boot both systems.

2. Display various driver and controller settings.

   `# kstat driver | grep -i ifspeed`

   For a 10-Mbps connection, this is shown:

   `ifspeed 10000000`

3. Disconnect both machines from the 10-Mbps ports or switch, and connect them to the 100-Mbps ports or switch.

4. Display various driver and controller settings.

   `# kstat driver | grep -i ifspeed`

   For a 100-Mbps connection, this is shown:

   `ifspeed 100000000`

5. Change the connections back to the 10-Mbps ports or switch, and verify that the connection speed has dropped back to 10000000.

6. Repeat these tests while executing a TCP stress test from the HCTS, such as `ftpstress` or `rcp`.

Expected Results

- Both machines correctly identify the connection speeds as indicated.
- The stress tests continue to run before, during, and after any of the changes in this test. The only loss of connectivity occurs when the cables are unplugged.

Back to Top

#### Auto-Negotiate Connection Duplex Test

Required Hardware

- Two test machines
- A network switch that can be set to force full-duplex or half-duplex connections

Test Strategy

This test ensures that the driver is capable of automatically detecting whether the connection should be established in full-duplex or half-duplex mode while the interface is active.

Test Procedure

1. Set two ports on the switch to half-duplex only, and another two ports to full-duplex only. (See the switch hardware's documentation for instructions.)

2. Connect the systems to the half-duplex ports, and boot both systems.

3. Display various driver and controller settings.

   `# kstat driver | grep -i duplex`

   One shows:

   `duplex half`

4. Disconnect both systems from the half-duplex ports, and connect them to the full-duplex ports.

5. Display various driver and controller settings.

   `# kstat driver | grep -i duplex`

   One shows:

   `duplex full`

6. Change the connections back to the half-duplex ports, and verify that the controller has changed to half-duplex mode.

7. Repeat these tests while executing a TCP stress test from the HCTS, such as `ftpstress` or `rcp`.

Expected Results

- Both machines correctly identify the connection mode.
- The stress tests continue to run before, during, and after any of the changes in this test. The only loss of connectivity occurs when the cables are unplugged.

Back to Top

Copyright 2005 Sun Microsystems, Inc. All rights reserved.