| 1 | Confirm the spanning-tree standards supported | Check whether the switch supports classic STP (IEEE 802.1D) and Rapid Spanning Tree Protocol (RSTP, originally IEEE 802.1w and incorporated into the 2004 revision of 802.1D). | Spanning tree helps prevent Layer 2 loops in bridged Ethernet networks. RSTP generally provides faster reconvergence than classic STP, depending on the topology and configuration. | Review the data sheet and management interface for the exact protocol names, operating modes, and interoperability options. |
| 2 | Check root-bridge controls | Look for configurable bridge priority and visibility into the current root bridge and spanning-tree topology. | Bridge priority is used in the spanning-tree root-bridge election. Deliberate placement of the root can make the Layer 2 topology more predictable. | Verify that administrators can set bridge priority and inspect root identity, port roles, and port states. |
| 3 | Review loop-protection safeguards | Check for features such as BPDU Guard, Root Guard, and loop detection, and understand the conditions under which each acts. | These safeguards can help limit the effects of accidental cabling loops or unexpected spanning-tree devices. Their behavior and names can vary by implementation. | Read the configuration guide and confirm whether a protected port is blocked, disabled, or placed into another state when a condition is detected. |
| 4 | Assess recovery visibility | Confirm that spanning-tree events, topology changes, and port-state transitions can be viewed in logs or monitoring tools. | Useful event records can help operators identify the cause of connectivity changes and distinguish a link failure from a configuration issue. | Check support for event logging and standard monitoring or management interfaces used in your environment. |
| 5 | Verify IEEE 802.1X port-based access control | Confirm that the switch can act as an 802.1X authenticator and communicate with an authentication server, commonly through RADIUS. | IEEE 802.1X provides port-based network access control. A connected device typically needs a supplicant, while the switch mediates authentication with the server. | Check supported authentication methods, server settings, and whether the feature applies to the port types you plan to use. |
| 6 | Understand behavior when authentication fails | Review the available options for unauthenticated, rejected, or unreachable-server states, including any restricted or guest access modes. | Clear failure behavior helps avoid unintended access while providing a defined way to handle outages or devices that cannot perform 802.1X. | Ask whether fallback behavior is configurable and document the security implications before enabling it. |
| 7 | Check support for non-supplicant devices | Determine whether the switch supports MAC Authentication Bypass (MAB) or another explicitly documented alternative for devices without an 802.1X supplicant. | Some printers, sensors, and other embedded devices may not support 802.1X. Alternatives can help accommodate them, but they do not provide the same credential-based protection as 802.1X. | Confirm how alternative authentication is enabled, which devices it applies to, and how access can be restricted. |
| 8 | Review per-port and multi-device policies | Check whether authentication can be configured per port and how the switch handles multiple devices connected through a downstream hub or phone. | Port policy affects which devices can connect and whether each device is authenticated individually or under a shared port-level arrangement. | Compare documented modes, such as single-host and multi-host behavior, with the devices and wiring planned for each port. |
| 9 | Inspect authorization and VLAN assignment options | Verify whether successful authentication can result in policy-based access, such as an assigned VLAN, where supported by the switch and authentication system. | Separating devices by role or policy can limit unnecessary network access. Available assignment options depend on configuration and interoperability. | Confirm the required switch and server settings, and test that an authenticated device receives only its intended access. |
| 10 | Plan a test before deployment | Test spanning-tree behavior, 802.1X authentication, server-loss handling, logs, and recovery using representative devices and cabling. | Standards support alone does not guarantee that a particular topology, client, and policy will work as intended. | Use a staging setup to document expected port states, authentication outcomes, and recovery steps before applying the configuration network-wide. |