When configuring 802.1x, go to these
sections for information you are interested in:
l
802.1x
Overview
l
Configuring
802.1x
l
Configuring
a Guest VLAN
l
Displaying
and Maintaining 802.1x
l
802.1x
Configuration Example
l
Guest
VLAN Configuration Example
l
ACL
Assignment Configuration Example
1.1 802.1x Overview
The 802.1x protocol was proposed by IEEE 802
LAN/WAN committee for security problems on wireless LANs (WLAN). Currently, it
is widely used on Ethernet as a common port access control mechanism.
As a port-based network access control
protocol, 802.1x authenticates and controls accessing devices at the level of
port. A device connected to an 802.1x-enabled port of an access control device can
access the resources on the LAN only after passing authentication.
To get more information about 802.1x, go to
these topics:
l
Architecture
of 802.1x
l
Operation
of 802.1x
l
EAP
Encapsulation over LANs
l
EAP
Encapsulation over RADIUS
l
Authentication
Process of 802.1x
l
802.1x
Timers
l
Implementation
of 802.1x in the Devices
l
Features
Working Together with 802.1x
1.1.1 Architecture of 802.1x
802.1x operates in the typical
client/server model and defines three entities: supplicant system,
authenticator system, and authentication server system, as shown in Figure 1-1.
Figure 1-1 Architecture of 802.1x
l
Supplicant system: A system at one end of the
LAN segment, which is authenticated by the authenticator system at the other
end. A supplicant system is usually a user-end device and initiates 802.1x
authentication through 802.1x client software supporting the EAP over LANs
(EAPOL) protocol.
l
Authenticator system: A system at the other end
of the LAN segment, which authenticates the connected supplicant system. An
authenticator system is usually an 802.1x-enabled network device and provides
ports (physical or logical) for supplicants to access the LAN.
l
Authentication server system: The system
providing authentication, authorization, and accounting services for the
authenticator system. The authentication server, usually a Remote Authentication
Dial-in User Service (RADIUS) server, maintains user information like username,
password, VLAN that the user belongs to, committed access rate (CAR) parameters,
priority, and ACLs.
The above systems involve three basic concepts: PAE, controlled
port, control direction.
Port access entity (PAE) refers to the
entity that performs the 802.1x algorithm and protocol operations.
l
The authenticator PAE uses the authentication
server to authenticate a supplicant trying to access the LAN and controls the
status of the controlled port according to the authentication result, putting
the controlled port in the state of authorized or unauthorized. In authorized
state, the supplicant can access network resources without authentication; in unauthorized
state, the supplicant can receive and send EAPOL frames rather than accessing
network resources.
l
The supplicant PAE responds to the
authentication request of the authenticator PAE and provides authentication
information. The supplicant PAE can also send authentication requests and
logoff requests to the authenticator.
II. Controlled port and uncontrolled port
An
authenticator provides ports for supplicants to access the LAN. Each of the
ports can be regarded as two logical ports: a controlled port and an uncontrolled
port.
l
The uncontrolled port is always open in both the
inbound and outbound directions to allow EAPOL protocol frames to pass,
guaranteeing that the supplicant can always send and receive authentication
frames.
l
The controlled port is open to allow normal
traffic to pass only when it is in the authorized state.
l
The controlled port and uncontrolled port are
two parts of the same port. Any frames arriving at the port are visible to both
of them.
III. Control direction
In the unauthorized state, the controlled
port can be set to deny traffic to and from the supplicant or just the traffic
from the supplicant.
Currently, the devices
support only denying the traffic from the supplicant.
The 802.1x authentication system employs
the Extensible Authentication Protocol (EAP) to exchange authentication
information between the supplicant PAE, authenticator PAE, and authentication
server.
Figure
1-2 Operation of 802.1x
l
Between the supplicant PAE and authenticator
PAE, EAP protocol packets are encapsulated using EAP Encapsulation over LANs
and transferred over the LAN.
l
Between the authenticator PAE and authentication
server, EAP protocol packets can be handled in two modes: EAP relay and EAP termination.
In EAP relay mode, EAP protocol packets are encapsulated by using the EAP Encapsulation
over RADIUS (Remote Authentication Dial-In User Service) and then relayed to
the RADIUS server. In EAP termination mode, EAP protocol packets are terminated
at the authenticator PAE, repackaged in the Password Authentication Protocol (PAP)
or Challenge Handshake Authentication Protocol (CHAP) attributes of RADIUS
packets, and then transferred to the RADIUS server.
l
After a user passes the authentication, the
authentication server passes information about the user to the authenticator,
which then controls the status of the controlled port according to the
instruction of the authentication server.
1.1.3 EAP Encapsulation over LANs
I. EAPOL frame format
EAPOL, defined by 802.1x, is intended to
carry EAP protocol packets between supplicants and authenticators over LANs. Figure 1-3 shows the
EAPOL frame format.
Figure 1-3 EAPOL frame format
l
PAE Ethernet type: Protocol type. It takes the
value 0x888E.
l
Protocol version: Version of the EAPOL protocol
supported by the EAPOL frame sender.
l
Type: Type of the EAPOL frame. Table 1-1 shows the
defined types of EAPOL frames.
Table 1-1 Types
of EAPOL frames
|
Type
|
Description
|
|
EAP-Packet (a value of 0x00)
|
Frame for carrying authentication information,
present between an authenticator system and the
authentication server.
A frame of this type is repackaged and
transferred by RADIUS to get through complex networks to reach the
authentication server.
|
|
EAPOL-Start (a value of 0x01)
|
Frame for initiating authentication,
present between a supplicant and an authenticator.
|
|
EAPOL-Logoff (a value of 0x02)
|
Frame for logoff request, present between
a supplicant and an authenticator.
|
|
EAPOL-Key (a value of 0x03)
|
Frame for carrying key information,
present between a supplicant and an authenticator.
|
|
EAPOL-Encapsulated-ASF-Alert
(a value of 0x04)
|
Frame for
carrying alerting information compliant to Alert
Standard Forum (ASF).
A frame of
this type carries network management-related information like warning
messages and is terminated at the authenticator.
|
l
Length: Length of the data, that is, length of
the Packet body field, in bytes. If the value of this field is 0, no subsequent
data field is present.
l
Packet body: Content of the packet. The format
of this field varies with the value of the Type field.
II. EAP Packet Format
An EAPOL frame of the type of EAP-Packet
carries an EAP packet in its Packet body field. The format of the EAP packet is
shown in Figure 1-4.
Figure 1-4 EAP packet format
l
Code: Type of the EAP packet, which can be
Request, Response, Success, or Failure.
An EAP packet of the type of Success or
Failure has no Data field, and has a length of 4.
An EAP packet of the type of Request or
Response has a Data field in the format shown in Figure 1-5. The Type field indicates the EAP
authentication type. A value of 1 represents Identity, indicating that the
packet is for querying the identity of the supplicant. A value of 4 represents
MD5-Challenge, which corresponds closely to the PPP CHAP protocol.
Figure 1-5 Format of the Data field in
an EAP request/response packet
l
Identifier: Allows matching of responses with
requests.
l
Length: Length of the EAP packet, including the
Code, Identifier, Length, and Data fields, in bytes.
l
Data: Content of the EAP packet. This field is
zero or more bytes and its format is determined by the Code field.
1.1.4 EAP Encapsulation over RADIUS
Two attributes of RADIUS are intended for supporting
EAP authentication: EAP-Message and Message-Authenticator. For information
about RADIUS packet format, refer to AAA RADIUS HWTACACS Configuration.
I. EAP-Message
The EAP-Message attribute is used to
encapsulate EAP packets. Figure
1-6 shows its encapsulation format. The value of
the Type field is 79. The String field can be up to 253 bytes. If the EAP
packet is longer than 253 bytes, it can be fragmented and encapsulated into
multiple EAP-Message attributes.
Figure 1-6 Encapsulation format of the
EAP-Message attribute
II. Message-Authenticator
Figure 1-7 shows the encapsulation format of the Message-Authenticator attribute.
The Message-Authenticator attribute is used to prevent access requests from
being snooped during EAP or CHAP authentication. It must be included in any
packet with the EAP-Message attribute; otherwise, the packet will be considered
invalid and get discarded.
Figure 1-7 Encapsulation format of the
Message-Authenticator attribute
1.1.5 Authentication Process of 802.1x
802.1x authentication can be initiated by
either a supplicant or the authenticator system. A supplicant initiates
authentication by launching the 802.1x client software to send an EAPOL-Start
frame to the authenticator system, while the authenticator system sends an
EAP-Request/Identity packet to an unauthenticated supplicant when detecting
that the supplicant is trying to login.
An 802.1x
authenticator system communicates with a remotely located RADIUS server in two
modes: EAP relay and EAP termination. The following description takes the first
case as an example to show the 802.1x authentication process.
I. EAP relay
EAP relay is an IEEE 802.1x standard mode.
In this mode, EAP packets are carried in an upper layer protocol, such as
RADIUS, so that they can go through complex networks and reach the
authentication server. Generally, EAP relay requires that the RADIUS server
support the EAP attributes of EAP-Message and Message-Authenticator.
At present, the EAP relay mode supports four
authentication methods: EAP-MD5, EAP-TLS (Transport Layer Security), EAP-TTLS
(Tunneled Transport Layer Security), and PEAP (Protected Extensible
Authentication Protocol).
l
EAP-MD5: EAP-MD5 authenticates the identity of a
supplicant. The RADIUS server sends an MD5 challenge (through an EAP-Request/MD5
Challenge packet) to the supplicant. Then the supplicant encrypts the password
with the offered challenge.
l
EAP-TLS: With EAP-TLS, a supplicant and the
RADIUS server verify each other’s security certificates and identities,
guaranteeing that EAP packets are sent to the intended destination and thus preventing
network traffic from being snooped.
l
EAP-TTLS: EAP-TTLS extends EAP-TLS. EAP-TLS
allows for mutual authentication between a supplicant and the authentication
server. EAP-TTLS extends this implementation by transferring packets through the
secure tunnels set up by TLS.
l
PEAP: With PEAP, the RADIUS server sets up a TLS
tunnel with a supplicant system for integrity protection and then performs a new
round of EAP negotiation with the supplicant system for identity authentication.
Figure 1-8 shows the
message exchange procedure with EAP-MD5.
Figure 1-8 Message exchange in EAP relay
mode
1)
When a user launches the 802.1x client software
and enters the registered username and password, the 802.1x client software generates
an EAPOL-Start frame and sends it to the authenticator to initiate an
authentication process.
2)
Upon receiving the EAPOL-Start frame, the
authenticator responds with an EAP-Request/Identity packet for the username of
the supplicant.
3)
When the supplicant receives the
EAP-Request/Identity packet, it encapsulates the username in an
EAP-Response/Identity packet and sends the packet to the authenticator.
4)
Upon receiving the EAP-Response/Identity packet,
the authenticator relays the packet in a RADIUS Access-Request packet to the
authentication server.
5)
When receiving the RADIUS Access-Request packet,
the RADIUS server compares the identify information against its user
information table to obtain the corresponding password information. Then, it
encrypts the password information using a randomly generated challenge, and
sends the challenge information through a RADIUS Access-Challenge packet to the
authenticator.
6)
After receiving the RADIUS Access-Challenge packet,
the authenticator relays the contained EAP-Request/MD5 Challenge packet to the
supplicant.
7)
When receiving the EAP-Request/MD5 Challenge packet,
the supplicant uses the offered challenge to encrypt the password part (this
process is not reversible), creates an EAP-Response/MD5 Challenge packet, and
then sends the packet to the authenticator.
8)
After receiving the EAP-Response/MD5 Challenge packet,
the authenticator relays the packet in a RADIUS Access-Request packet to the
authentication server.
9)
When receiving the RADIUS Access-Request packet,
the RADIUS server compares the password information encapsulated in the packet
with that generated by itself. If the two are identical, the authentication
server considers the user valid and sends to the authenticator a RADIUS
Access-Accept packet.
10)
Upon receiving the RADIUS Access-Accept packet, the
authenticator opens the port to grant the access request of the supplicant. After
the supplicant gets online, the authenticator periodically sends handshake
requests to the supplicant to check whether the supplicant is still online. By
default, if two consecutive handshake attempts end up with failure, the
authenticator concludes that the supplicant has gone offline and performs the
necessary operations, guaranteeing that the authenticator always knows when a
supplicant goes offline.
11)
The supplicant can also send an EAPOL-Logoff
frame to the authenticator to go offline unsolicitedly. In this case, the
authenticator changes the status of the port from authorized to unauthorized.
In EAP relay mode, a
supplicant must use the same authentication method as that of the RADIUS server,
no matter whichever of the above mentioned authentication methods is used. On
the device, however, you only need to execute the dot1x authentication-method
eap command to enable EAP relay.
II. EAP termination
In EAP termination mode, EAP packets are
terminated at the authenticator and then repackaged into the PAP or CHAP
attributes of RADIUS and transferred to the RADIUS server for authentication,
authorization, and accounting. Figure 1-9 shows the message exchange
procedure with CHAP authentication.
Figure 1-9
Message exchange in EAP termination mode
Different from the authentication process
in EAP relay mode, it is the authenticator that generates the random challenge
for encrypting the user password information in EAP termination authentication
process. Consequently, the authenticator sends the challenge together with the
username and encrypted password information from the supplicant to the RADIUS server
for authentication.
1.1.6 802.1x
Timers
Several timers are used in the 802.1x
authentication process to guarantee that the supplicants, the authenticators,
and the RADIUS server interact with each other in a reasonable manner. The
following are the major 802.1x timers:
l
Username request timeout timer (tx-period): This
timer is used in two cases, one is when an authenticator retransmits an
EAP-Request/Identity frame and the other is when an authenticator multicasts an
EAP-Request/Identity frame. Once an authenticator sends an EAP-Request/Identity
frame to a supplicant, it starts this timer. If this timer expires but it
receives no response from the supplicant, it retransmits the request. To cooperate
with a supplicant system that does not send EAPOL-Start requests unsolicitedly,
the authenticator multicasts EAP-Request/Identity frames to the supplicant
system at an interval defined by this timer.
l
Supplicant timeout timer (supp-timeout): Once an
authenticator sends an EAP-Request/MD5 Challenge frame to a supplicant, it
starts this timer. If this timer expires but it receives no response from the
supplicant, it retransmits the request.
l
Server timeout timer (server-timeout): Once an
authenticator sends a RADIUS Access-Request packet to the authentication server,
it starts this timer. If this timer expires but it receives no response from
the server, it retransmits the request.
l
Handshake timer (handshake-period): After a
supplicant passes authentication, the authenticator sends to the supplicant
handshake requests at this interval to check whether the supplicant is online. If
the authenticator receives no response after sending the allowed maximum number
of handshake requests, it considers that the supplicant is offline.
l
Quiet timer (quiet-period): When a supplicant
fails the authentication, the authenticator refuses further authentication
requests from the supplicant in this period of time.
1.1.7 Implementation of 802.1x in the Devices
The devices extend and optimize the
mechanism that the 802.1x protocol specifies by:
l
Allowing multiple users to access network
services through the same physical port.
l
Supporting two authentication methods: portbased
and macbased. With the portbased method, after the first user of
a port passes authentication, all other users of the port can access the
network without authentication, and when the first user goes offline, all other
users get offline at the same time. With the macbased method, each user
of a port must be authenticated separately, and when an authenticated user goes
offline, no other users are affected.
After an 802.1x
supplicant passes authentication, the authentication server sends authorization
information to the authenticator. If the authorization information contains
VLAN authorization information, the authenticator adds the port connecting the
supplicant to the assigned VLAN. This neither changes nor affects the
configurations of the port. The only result is that the assigned VLAN takes
precedence over the manually configured one, that is, the assigned VLAN takes
effect. After the supplicant goes offline, the configured one takes effect.
1.1.8 Features Working Together with 802.1x
I. VLAN assigning
After an 802.1x user passes the authentication,
the server will send an authorization message to the device. If the server is enabled
with the VLAN assigning function, the assigned VLAN information will be
included in the message. The device, depending on the link type of the port used
to log in, adds the port to the assigned VLAN according to the following rules:
l
If the port link type is Access, the port leaves
its current VLAN and joins the assigned VLAN.
l
If the port link type is Trunk, the assigned VLAN
is allowed to pass the current trunk port. The default VLAN ID of the port is
that of the assigned VLAN.
l
If the port link type is Hybrid, the assigned VLAN
is allowed to pass the current port without carrying the tag. The default VLAN
ID of the port is that of the assigned VLAN.
The assigned VLAN neither changes nor affects
the configuration of a port. However, as the assigned VLAN has higher priority than
the user-configured VLAN, it is the assigned VLAN that takes effect after a
user passes authentication. After the user goes offline, the port returns to
its original VLAN.
For details about VLAN configuration, refer
to VLAN Configuration.
l
With a Hybrid port, the VLAN assigning will fail
if you have configured the assigned VLAN to carry tags.
l
With a Hybrid port, you cannot configure an assigned
VLAN to carry tags after the VLAN has been assigned.
II. Guest VLAN
Guest VLAN allows
unauthenticated users to access some special resources.
Guest VLAN
is the default VLAN that a supplicant on a port can access without
authentication. After the supplicant passes 802.1x authentication, the port
leaves the guest VLAN and the supplicant can access other network resources.
A user of
the guest VLAN can perform operations such as downloading and upgrading the
authentication client software. If a supplicant does not have the required
authentication client software or the version of the client software is lower,
the supplicant will fail the authentication. If no supplicant on a port passes
authentication in a certain period of time (45 seconds by default), the port
will be added into the guest VLAN.
If a device with 802.1x enabled and the guest
VLAN correctly configured sends an EAP-Request/Identity packet for the allowed
maximum number of times but gets no response, it adds the port into the guest
VLAN according to port link type in the similar way as described in VLAN
assigning.
When a supplicant added into the guest VLAN
initiates another authentication process, if the authentication is not
successful, the supplicant stays in the guest VLAN; otherwise, two cases may
occur:
l
The authentication server assigns a VLAN: The
port leaves the guest VLAN and joins the assigned VLAN. If the supplicant goes
offline, the port returns to its original VLAN, that is, the VLAN to which it
is configured to belong and it belongs before joining the guest VLAN.
l
The authentication server does not assign any
VLAN: The port leaves the guest VLAN and returns to its original VLAN. If the
supplicant goes offline, the port just stays in its original VLAN.
III. ACL assignment
ACLs provide a way of controlling access to
network resources and defining access rights. When a user logs in through a
port, and the RADIUS server is configured with authorization ACLs, the device
will permit or deny data flows traversing through the port according to the authorization
ACLs. Before specifying authorization ACLs on the server, you need to configure
the ACL rules on the device. You can change the access rights of users by
modifying authorization ACL settings on the RADIUS server or changing the
corresponding ACL rules on the device.
1.2 Configuring
802.1x
802.1x provides
a user identity authentication scheme. However, 802.1x cannot implement the
authentication scheme solely by itself. RADIUS or local authentication must be configured
to work with 802.1x.
l
Configure the ISP domain to which the 802.1x
user belongs and the AAA scheme to be used (that is, local authentication or
RADIUS).
l
For remote RADIUS authentication, the username
and password information must be configured on the RADIUS server.
l
For local authentication, the username and
password information must be configured on the authenticator and the service
type must be set to lan-access.
For detailed configuration of the RADIUS
client, refer to AAA RADIUS HWTACACS Configuration.
Follow these steps to configure 802.1x
globally:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enable 802.1x globally
|
dot1x
|
Required
Disabled by default
|
|
Set the authentication method
|
dot1x authentication-method
{ chap | eap | pap }
|
Optional
CHAP by default
|
|
Set the port access control parameters
|
Set the port access control mode for specified
or all ports
|
dot1x port-control
{ authorized-force | auto | unauthorized-force } [ interface
interface-list ]
|
Optional
auto by
default
|
|
Set the port access control method for specified
or all ports
|
dot1x port-method
{ macbased | portbased } [ interface interface-list
]
|
Optional
macbased
by default
|
|
Set the maximum number of users for
specified or all ports
|
dot1x max-user
user-number [ interface interface-list ]
|
Optional
By default, the maximum number of
concurrent users accessing a port is 256.
|
|
Set the maximum number of attempts to send
an authentication request to a supplicant
|
dot1x retry max-retry-value
|
Optional
2 by default
|
|
Set timers
|
dot1x timer { handshake-period handshake-period-value | quiet-period
quiet-period-value | server-timeout server-timeout-value
| supp-timeout supp-timeout-value | tx-period tx-period-value
}
|
Optional
The defaults are as follows:
15 seconds for the handshake timer,
60 seconds for the quiet timer,
100 seconds for the server timeout timer,
30 seconds for the supplicant timeout
timer, and
30 seconds for the username request
timeout timer.
|
|
Enable the quiet timer
|
dot1x quiet-period
|
Optional
Disabled by default
|
Note that:
l
For 802.1x to take effect on a port, you must
enable it both globally in system view and for the port in system view or
Ethernet interface view.
l
You can also enable 802.1x and set port access
control parameters (that is, the port access control mode, port access method,
and the maximum number of users) for a port in Ethernet interface view. For
detailed configuration, refer to Configuring 802.1x for a Port. The only difference
between configuring 802.1x globally and configuring 802.1x for a port lies in the
applicable scope. If both a global setting and a local setting exist for an
argument of a port, the last configured one is in effect.
l
Generally, it is unnecessary to change 802.1x
timers unless in some special or extreme network environments.
Follow these steps to enable 802.1x for a
port:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Enable
802.1x for one or more ports
|
In system
view
|
dot1x interface interface-list
|
Required
Use either
approach.
Disabled
by default
|
|
In
Ethernet interface view
|
interface interface-type interface-number
|
|
dot1x
|
II. Configuring 802.1x parameters
for a port
Follow these steps to configure 802.1x
parameters for a port:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enter Ethernet interface view
|
interface interface-type
interface-number
|
—
|
|
Set the port access control mode for the
port
|
dot1x port-control
{ authorized-force | auto | unauthorized-force }
|
Optional
auto by
default
|
|
Set the port access control method for
the port
|
dot1x port-method
{ macbased | portbased }
|
Optional
macbased
by default
|
|
Set the maximum number of users for the
port
|
dot1x max-user
user-number
|
Optional
By default, the maximum number of
concurrent users accessing a port is 256.
|
|
Enable online user handshake
|
dot1x handshake
|
Optional
Enabled by default
|
|
Enable multicast trigger
|
dot1x multicast-trigger
|
Optional
Enabled by default
|
Note that:
l
You can neither add an 802.1x-enabled port into
an aggregation group nor enable 802.1x on a port being a member of an
aggregation group.
l
Once enabled with the 802.1x multicast trigger
function, a port sends multicast trigger messages to the client periodically to
initiate authentication.
l
For a user-side device sending untagged traffic,
the voice VLAN function and 8021.x are mutually exclusive and cannot be
configured together on the same port. For details about voice VLAN, refer to VLAN
Configuration.
l
In EAP relay authentication mode, the
authenticator encapsulates the 802.1x user information in the EAP attributes of
RADIUS packets and sends the packets to the RADIUS server for authentication.
In this case, you can configure the user-name-format command but it does
not take effect. For information about the user-name-format command,
refer to AAA RADIUS HWTACACS Commands.
l
If the username of a supplicant contains the
version number or one or more blank spaces, you can neither retrieve
information nor disconnect the supplicant by using the username. However, you
can use items such as IP address and connection index number to do so.
1.3 Configuring a Guest VLAN
l
Enable 802.1x
l
Set the port access control method to portbased
for the port
l
Set the port access control mode to auto
for the port
l
Create the VLAN to be specified as the guest VLAN
Follow these steps to configure Guest VLAN:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Configure the guest VLAN for specified or
all ports
|
dot1x guest-vlan vlan-id [ interface interface-list ]
|
Required
By default, a port is configured with no
guest VLAN.
|
|
Or in Ethernet interface view
interface interface-type interface-number
dot1x guest-vlan
vlan-id
|
l
You can specify a tagged VLAN as the guest VLAN for
a Hybrid port, but the guest VLAN does not take effect. Similarly, if a guest
VLAN for a Hybrid port is in operation, you cannot configure the guest VLAN to
carry tags.
l
Configurations in system view are effective to all
ports while configurations in interface view are effective to the current port only.
l
If a port’s access control method is portbased,
its guest VLAN can take effect; if a port’s access control method is macbased,
its guest VLAN can be configured but cannot take effect.
l
A port can be configured with only one guest
VLAN. But different ports can have different guest VLANs.
Caution:
If the data flows from
a user-side device include VLAN tags, and 802.1x and guest VLAN are enabled on
the access port, you are recommended to configure different VLAN IDs for the
Voice VLAN, the default port VLAN, and the guest VLAN of 802.1x.
1.4 Displaying and Maintaining 802.1x
|
To do…
|
Use the command…
|
Remarks
|
|
Display 802.1x session information,
statistics, or configuration information of specified or all ports
|
display dot1x [ sessions | statistics ] [ interface interface-list
]
|
Available in any view
|
|
Clear 802.1x statistics
|
reset dot1x statistics [ interface interface-list ]
|
Available in user view
|
