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
|
1.5 802.1x Configuration Example
I. Network requirements
l
The access control method of macbased is
required on the port to control supplicants.
l
All supplicants belong to default domain
aabbcc.net, which can accommodate up to 30 users. RADIUS authentication is
performed at first, and then local authentication when no response from the
RADIUS server is received. If the RADIUS accounting fails, the authenticator
gets users offline.
l
A server group with two RADIUS servers is
connected to the switch. The IP addresses of the servers are 10.1.1.1 and
10.1.1.2 respectively. Use the former as the primary authentication/secondary
accounting server, and the latter as the secondary authentication/primary
accounting server.
l
Set the shared key for the switch to exchange
packets with the authentication server and the accounting server as secret.
l
Specify the switch to try up to five times at an
interval of 5 seconds in transmitting a packet to the RADIUS server until it
receives a response from the server, and to send real time accounting packets
to the accounting server every 15 minutes.
l
