Access Security Guide K/KA/KB.15.15

Shows the port-access supplicant configuration (excluding the secret parameter) for
all ports or < portlist > ports configured on the switch as supplicants. The Supplicant
State can include the following:
Connecting
Starting authentication. Authenticated - Authentication completed (regardless
of whether the attempt was successful).
Acquired
The port received a request for identification from an authenticator.
Authenticating
Authentication is in progress.
Held
Authenticator sent notice of failure. The supplicant port is waiting for the
authenticator’s held-period.
For descriptions of the supplicant parameters, see “Configuring a Supplicant Switch
Port” (page 479).
show port-access supplicant [< port-list >] statistics
Shows the port-access statistics and source MAC address(es) for all ports or <
port-list > ports configured on the switch as supplicants. See the “Note on Supplicant
Statistics”, below.
Note on Supplicant Statistics.
For each port configured as a supplicant, show port-access supplicant statistics < port-list >] displays
the source MAC address and statistics for transactions with the authenticator device most recently
detected on the port. If the link between the supplicant port and the authenticator device fails, the
supplicant port continues to show data received from the connection to the most recent authenticator
device until one of the following occurs:
• The supplicant port detects a different authenticator device.
• You use the aaa port-access supplicant < port-list > clear-statistics command to clear the
statistics for the supplicant port.
• The switch reboots.
Thus, if the supplicant’s link to the authenticator fails, the supplicant retains the transaction statistics
it most recently received until one of the above events occurs. Also, if you move a link with an
authenticator from one supplicant port to another without clearing the statistics data from the first
port, the authenticator’s MAC address will appear in the supplicant statistics for both ports.
How RADIUS/802.1X Authentication Affects VLAN Operation
Static VLAN Requirement. RADIUS authentication for an 802.1X client on a given port can include
a (static) VLAN requirement. (Refer to the documentation provided with your RADIUS application.)
The static VLAN to which a RADIUS server assigns a client must already exist on the switch. If it
does not exist or is a dynamic VLAN (created by GVRP), authentication fails. Also, for the session
to proceed, the port must be an untagged member of the required VLAN. If it is not, the switch
temporarily reassigns the port as described below.
If the Port Used by the Client Is Not Configured as an Untagged Member of the Required Static
VLAN: When a client is authenticated on port “N”, if port “N” is not already configured as an
untagged member of the static VLAN specified by the RADIUS server, then the switch temporarily
assigns port “N” as an untagged member of the required VLAN (for the duration of the 802.1X
session). At the same time, if port “N” is already configured as an untagged member of another
VLAN, port “N” loses access to that other VLAN for the duration of the session. (This is because
a port can be an untagged member of only one VLAN at a time.) Using a RADIUS server to
474 Port-Based and User-Based Access Control (802.1X)