BLADE OS™ Application Guide HP GbE2c Ethernet Blade Switch for c-Class BladeSystem Version 5.1 Advanced Functionality Software
Table Of Contents
- Contents
- Figures
- Tables
- Preface
- Part 1: Basic Switching
- Accessing the Switch
- The Management Network
- Local Management Using the Console Port
- The Command Line Interface
- Remote Management Access
- Client IP Address Agents
- Securing Access to the Switch
- Setting Allowable Source IP Address Ranges
- RADIUS Authentication and Authorization
- TACACS+ Authentication
- LDAP Authentication and Authorization
- Secure Shell and Secure Copy
- Configuring SSH/SCP Features on the Switch
- Configuring the SCP Administrator Password
- Using SSH and SCP Client Commands
- SSH and SCP Encryption of Management Messages
- Generating RSA Host and Server Keys for SSH Access
- SSH/SCP Integration with Radius Authentication
- SSH/SCP Integration with TACACS+ Authentication
- End User Access Control
- Ports and Trunking
- Port-Based Network Access Control
- VLANs
- Spanning Tree Protocol
- RSTP and MSTP
- Link Layer Discovery Protocol
- Quality of Service
- Accessing the Switch
- Part 2: IP Routing
- Basic IP Routing
- Routing Information Protocol
- IGMP
- OSPF
- OSPF Overview
- OSPF Implementation in BLADE OS
- OSPF Configuration Examples
- Remote Monitoring
- Part 3: High Availability Fundamentals
- High Availability
- Layer 2 Failover
- Server Link Failure Detection
- VRRP Overview
- Failover Methods
- BLADE OS Extensions to VRRP
- Virtual Router Deployment Considerations
- High Availability Configurations
- High Availability
- Part 4: Appendices
- Index
BLADE OS 5.1 Application Guide
80 Chapter 3: Port-Based Network Access Control BMD00113, September 2009
EAPoL Message Exchange
During authentication, EAPOL messages are exchanged between the client and the GbE2c
authenticator, while RADIUS-EAP messages are exchanged between the GbE2c authenticator and
the RADIUS server.
Authentication is initiated by one of the following methods:
The GbE2c authenticator sends an EAP-Request/Identity packet to the client
Client sends an EAPOL-Start frame to the GbE2c authenticator, which responds with an
EAP-Request/Identity frame.
The client confirms its identity by sending an EAP-Response/Identity frame to the GbE2c
authenticator, which forwards the frame encapsulated in a RADIUS packet to the server.
The RADIUS authentication server chooses an EAP-supported authentication algorithm to verify
the client’s identity, and sends an EAP-Request packet to the client via the GbE2c authenticator. The
client then replies to the RADIUS server with an EAP-Response containing its credentials.
Upon a successful authentication of the client by the server, the 802.1X-controlled port transitions
from unauthorized to authorized state, and the client is allowed full access to services through the
controlled port. When the client later sends an EAPOL-Logoff message to the GbE2c authenticator,
the port transitions from authorized to unauthorized state.
If a client that does not support 802.1X connects to an 802.1X-controlled port, the GbE2c
authenticator requests the client's identity when it detects a change in the operational state of the
port. The client does not respond to the request, and the port remains in the unauthorized state.
Note – When an 802.1X-enabled client connects to a port that is not 802.1X-controlled, the client
initiates the authentication process by sending an EAPOL-Start frame. When no response is
received, the client retransmits the request for a fixed number of times. If no response is received,
the client assumes the port is in authorized state, and begins sending frames, even if the port is
unauthorized.