Chapter 1 802.1x Configuration
The 802.1x protocol (802.1x for short) was developed
by IEEE802 LAN/WAN committee to address security issues of wireless LANs. It was
then used in Ethernet as a common access control mechanism for LAN ports to address
mainly authentication and security problems.
802.1x is a port-based network access
control protocol. It authenticates and controls devices requesting for access
in terms of the ports of LAN access control devices. With the 802.1x protocol
employed, a user-side device can access the LAN only when it passes the
authentication. Those failing to pass the authentication are denied when
accessing the LAN, as if they are disconnected from the LAN.
802.1x adopts a client/server architecture
with three entities: a supplicant system, an authenticator system, and an authentication
server system, as shown in the following figure.
Figure 1-1
Architecture of 802.1x authentication
l
The supplicant system is an entity residing at one
end of the LAN segment and is authenticated by the authenticator system connected
to the other end of the LAN segment. The supplicant system is usually a user
terminal device. An 802.1x authentication is initiated when a user launches
client program on the supplicant system. Note that the client program must
support the EAPoL (extensible authentication protocol over LANs).
l
The authenticator system authenticates the
supplicant system. The authenticator system is usually an 802.1x-supported network
device (such as a H3C series switch). It provides the port (physical or
logical) for the supplicant system to access the LAN.
l
The authentication server system is an entity
that provides authentication service to the authenticator system. Normally in
the form of a RADIUS server, the authentication server system serves to perform
AAA (authentication, authorization, and accounting) . It also stores user
information, such as user name, password, the VLAN a user belongs to, priority,
and the ACLs (access control list) applied.
I. PAE
A PAE (port access entity) is responsible
for the implementation of algorithm and protocol-related operations in the authentication
mechanism.
The authenticator system PAE authenticates
the supplicant systems when they log into the LAN and controls the authorizing state
(on/off) of the controlled ports according to the authentication result.
The supplicant system PAE responds to the authentication
requests received from the authenticator system and submits user authentication
information to the authenticator system. It can also send authentication and
disconnection requests to the authenticator system PAE.
II. Controlled port and uncontrolled
port
The Authenticator system provides ports for
supplicant systems to access a LAN. A port of this kind is divided into a controlled
port and an uncontrolled port.
l
The uncontrolled port can always send and
receive packets. It mainly serves to forward EAPoL packets to ensure that a supplicant
system can send and receive authentication requests.
l
The controlled port can be used to pass service
packets when it is in authorized state. It is blocked when not in authorized
state. In this case, no packets can pass through it.
l
Controlled port and uncontrolled port are two
properties of a access port. Packets reaching an access port are visible to
both the controlled port and uncontrolled port of the access port.
III. The valid direction of a
controlled port
When a controlled port is in unauthorized
state, you can configure it to be a unidirectional port, which sends packets to
supplicant systems only.
By default, a controlled port is a
unidirectional port.
IV. The way a port is controlled
A port of a H3C series switch can be
controlled in the following two ways.
l
Port-based authentication. When a port is
controlled in this way, all the supplicant systems connected to the port can
access the network without being authenticated after one supplicant system
among them passes the authentication. And when the authenticated supplicant
system goes offline, the others are denied as well.
l
MAC address-based authentication. All supplicant
systems connected to a port have to be authenticated individually in order to
access the network. And when a supplicant system goes offline, the others are
not affected.
IEEE 802.1x authentication system uses
extensible authentication protocol (EAP) to exchange information between the
supplicant system and the authentication server.
Figure 1-2
The mechanism of an 802.1x authentication system
l
EAP protocol packets transmitted between the supplicant
system and the authenticator system are encapsulated as EAPoL packets.
l
EAP protocol packets transmitted between the supplicant
system PAE and the RADIUS server can either be encapsulated as EAPoR (EAP over
RADIUS) packets or be terminated at system PAEs (The system PAEs then communicate
with RADIUS servers through PAP (password authentication protocol) or CHAP (challenge-handshake
authentication protocol) protocol packets.)
l
When a supplicant system passes the
authentication, the authentication server passes the information about the
supplicant system to the authenticator system. The authenticator system in turn
determines the state (authorized or unauthorized) of the controlled port
according to the instructions (accept or reject) received from the RADIUS
server.
I. The format of an EAPoL packet
EAPoL is a packet encapsulation format
defined in 802.1x. To enable EAP protocol packets to be transmitted between
supplicant systems and authenticator systems through LANs, EAP protocol packets
are encapsulated in EAPoL format. The following figure illustrates the
structure of an EAPoL packet.
Figure 1-3 The format of an EAPoL packet
In an EAPoL packet:
l
The PAE Ethernet type field holds the protocol
identifier. The identifier for 802.1x is 888E.
l
The Protocol version field holds the version of
the protocol supported by the sender of the EAPoL packet.
l
The Type field can be one of the following:
00: Indicates that
the packet is an EAP-packet, which carries authentication information.
01: Indicates that
the packet is an EAPoL-start packet, which initiates authentication.
02: Indicates that
the packet is an EAPoL-logoff packet, which sends logging off requests.
03: Indicates that
the packet is an EAPoL-key packet, which carries key information packets.
04: Indicates that
the packet is an EAPoL-encapsulated-ASF-Alert packet, which is used to support
the alerting messages of ASF (alert standard forum).
l
The Length field indicates the size of the
Packet body field. A value of 0 indicates that the Packet Body field does not
exist.
l
The Packet body field differs with the Type
field.
Note that EAPoL-Start, EAPoL-Logoff, and EAPoL-Key
packets are only transmitted between the supplicant system and the authenticator
system. EAP-packets are encapsulated by RADIUS protocol to allow them
successfully reach the authentication servers. Network management-related
information (such as alarming information) is encapsulated in EAPoL-Encapsulated-ASF-Alert
packets, which are terminated by authenticator systems.
II. The format of an EAP packet
For an EAPoL packet with the Type value
being EAP-packet, the corresponding Packet body is an EAP packet. Its format is
illustrated in Figure 1-4.
Figure 1-4 The format of an EAP packet
In an EAP packet:
l
The Code field specifies the EAP packet type, which
can be Request, Response, Success, or Failure.
l
The Identifier field is used to match a Response
packets with the corresponding Request packet.
l
The Length field indicates the size of an EAP
packet, which includes the Code, Identifier, Length, and Data fields.
l
The Data field differs with the Code field.
A Success or Failure packet, whose format
is shown in Figure 1-5, does not contain the Data field, so has the Length field of 4.
Figure 1-5
Data fields
In a Success or Failure packet, the Type field
specifies the EAP authentication type. A Type value of 1 indicates Identity and
that the packet is used to query the identity of the peer. A type value of 4 represents
MD5-Challenge (similar to PPP CHAP) and indicates that the packet includes
query information.
III. Newly added fields for EAP
authentication
Two fields, EAP-message and
Message-authenticator, are added to a RADIUS protocol packet for EAP
authentication. (Refer to the Introduction to RADIUS protocol section in the AAA
and RADIUS Operation Manual for format of a RADIUS protocol packet.)
The EAP-message field, shown in Figure 1-6, is used to encapsulate EAP packets. The maximum size of the string field is 253 bytes. EAP packets with their size larger than 253 bytes are fragmented and stored in multiple EAP-message fields. The type code of
the EAP-message field is 79.
Figure 1-6 The format of an EAP-message
field
The Message-authenticator field, as shown in
Figure 1-7, is used to prevent unauthorized interception of access requesting packets during authentications using CHAP, EAP, and so on. A packet with the EAP-message field must also have the Message-authenticator field, otherwise
the packet is regarded as invalid and is discarded.
Figure 1-7 The format of an Message-authenticator field
A H3C S3100-SI series switch can authenticate
supplicant systems in EAP terminating mode or EAP relay mode.
I. EAP relay mode
This mode is defined in 802.1x. In this
mode, EAP-packets are encapsulated in higher level protocol (such as EAPoR) packets
to allow them successfully reach the authentication server. This mode normally requires
the RADIUS server to support the two newly-added fields: the EAP-message field
(with a value of 79) and the Message-authenticator field (with a value of 80).
Three authentication ways, EAP-MD5, EAP-TLS
(transport layer security), and PEAP (protected extensible authentication
protocol), are available for the EAP relay mode.
l
EAP-MD5 authenticates the supplicant system. The
RADIUS server sends MD5 keys (contained in EAP-request/MD5 challenge packets)
to the supplicant system, which in turn encrypts the passwords using the MD5
keys.
l
EAP-TLS authenticates both the supplicant system
and the RADIUS server by checking their security licenses to prevent data from
being stolen.
l
PEAP creates and uses TLS security channels to
ensure data integrity and then performs new EAP negotiations to verify
supplicant systems.
Figure 1-8 describes the basic EAP-MD5 authentication procedure.
Figure 1-8 802.1x authentication
procedure (in EAP relay mode)
The detailed procedure is as follows.
l
A supplicant system launches an 802.1x client to
initiate an access request through the sending of an EAPoL-start packet to the
switch, with its user name and password provided. The 802.1x client program
then forwards the packet to the switch to start the authentication process.
l
Upon receiving the authentication request
packet, the switch sends an EAP-request/identity packet to ask the 802.1x
client for the user name.
l
The 802.1x program responds by sending an
EAP-response/identity packet to the switch with the user name included. The
switch then encapsulates the packet in a RADIUS Access-Request packet and forwards
it to the RADIUS server.
l
Upon receiving the user name from the switch,
the RADIUS server retrieves the user name, finds the corresponding password by
matching the user name in its database, encrypts the password using a
randomly-generated key, and sends the key to the switch through an RADIUS
access-challenge packet. The switch then sends the key to the 802.1x client.
l
Upon receiving the key(encapsulated in an
EAP-request/MD5 challenge packet) from the switch, the client program encrypts
the password of the supplicant system with the key and sends the encrypted
password (contained in an EAP-response/MD5 challenge packet) to the RADIUS
server through the switch. (The encryption is irreversible.)
l
The RADIUS server compares the received encrypted
password (contained in a RADIUS access-request packet) with the
locally-encrypted password. If the two match, it will then send feedbacks
(through a RADIUS access-accept packet and an EAP-success packet) to the switch
to indicate that the supplicant system is authorized.
l
The switch changes the state of the corresponding
port to accepted state to allow the supplicant system access the network.
l
The supplicant system can also terminate the
authenticated state by sending EAPoL-Logoff packets to the switch. The switch
then changes the port state from accepted to rejected.
In EAP relay mode,
packets are not modified during transmission. Therefore if one of the three ways
are used (that is, PEAP, EAP-TLS, or EAP-MD5) to authenticate, ensure that the
authenticating ways used on the supplicant system and the RADIUS server are the
same. However for the switch, you can simply enable the EAP relay mode by using
the dot1x authentication-method eap command.
II. EAP terminating mode
In this mode, packet transmission is
terminated at authenticator systems and the EAP packets are converted to RADIUS
packets. Authentication and accounting are accomplished through RADIUS
protocol.
In this mode, PAP or CHAP is employed
between the switch and the RADIUS server. The authentication procedure
(assuming that CHAP is employed between the switch and the RADIUS server) is
illustrated in the following figure.
Figure 1-9
802.1x authentication procedure (in EAP terminating
mode)
The authentication procedure in EAP
terminating mode is the same as that in the EAP relay mode except that the
randomly-generated key in the EAP terminating mode is generated by the switch,
and that it is the switch that sends the user name, the randomly-generated key,
and the supplicant system-encrypted password to the RADIUS server for further
authentication.
In 802.1 x authentication, the following
timers are used to ensure that the supplicant system, the switch, and the
RADIUS server interact in an orderly way:
l
Transmission timer: This timer sets the tx-period
and is triggered by the switch when the switch sends a request/identity packet
to a supplicant system. The switch sends another request/identity packet to the
supplicant system if the supplicant system fails to send a reply packet to the
switch when this timer times out.
l
Supplicant system timer: This timer sets the
supp-timeout period and is triggered by the switch when the switch sends a
request/challenge packet to a supplicant system. The switch sends another
request/challenge packet to the supplicant system if the supplicant system
fails to respond when this timer times out.
l
Authentication server timer: This timer sets the
server-timeout period. The switch sends another authentication request packet
if the authentication server fails to respond when this timer times out.
l
Handshake timer (handshake-period): This timer sets
the handshake-period and is triggered after a supplicant system passes the
authentication. It sets the interval to for a switch to send handshake request
packets to online users. If you set the number of retries to N by using the dot1x
retry command, an online user is considered offline when the switch does not
receive response packets from it in a period N times of the handshake-period.
l
Quiet-period timer: This timer sets the
quiet-period. When a supplicant system fails to pass the authentication, the
switch quiets for the set period before it processes another authentication
request re-initiated by the supplicant system.
In addition to the earlier mentioned 802.1x
features, an S3100-SI series switch is also capable of the following:
l
Cooperating with a CAMS server to check
supplicant systems for proxies, dual-network adapters, and so on
l
Checking client version
l
Implementing the Guest VLAN function
CAMS server is a
service management system developed by H3C Technology Co., Ltd. It can
cooperate with network devices such as S3100-SI series switch to carry out
functions such as AAA and permission management. It enables a network to
operate in the desired way and enables you to manage a network in a easy way.
It also ensures network security.
I. Checking the supplicant system
An S3100-SI switch checks:
l
Supplicant systems logging on through proxies
l
Supplicant systems logging on through IE proxies
l
Whether or not a supplicant system logs in
through more than one network cards (that is, whether or not more than one
network adapters are active in a supplicant system when the supplicant system
logs in)
In response to any of the three cases, a
switch can optionally take the following measures:
l
Only disconnects the supplicant system but sends
no Trap packets (achieved via the dot1x supp-proxy-check logoff command.)
l
Send Trap packets without disconnecting the
supplicant system (achieved via the dot1x supp-proxy-check trap
command.)
This function needs the support of 802.1x
clients and CAMS:
l
The 802.1x clients are capable of detecting
multi-network adapter, proxies, and IE proxies.
l
CAMS is configured to disable the use of
multiple network adapters, proxies, or IE proxies.
By default, an 802.1x client program allows
use of multiple network adapters, a proxy server, and an IE proxy server. If
CAMS is configured to disable use of multiple network adapters, proxies, or IE
proxies, it prompts the 802.1x client to disable use of multiple network
adapters, proxies, or IE proxies through messages after the supplicant system
passes the authentication.
l
The client-checking function needs the support
of H3C’s 802.1x client program (iNode).
l
The proxy detecting function should be enabled on
both the 802.1x client program and CAMS. The client version detecting should be
enabled on the switch (achieved via the dot1x version-check command).
II. Chekcing the client version
With the 802.1x client-version-checking function
enabled, a switch will check the version and validity of an 802.1x client to
prevent unauthorized users or users with earlier versions of 802.1x from logging
in.
This function makes the switch to send
version-requesting packets again if the 802.1x client fails to send
version-reply packet to the switch before the version-checking timer times out.
The client-version-checking function needs the support of H3C’s
802.1x client program (iNode).
III. The Guest VLAN function
The Guest VLAN function enables supplicant
systems that do not pass the authentication to access a LAN in a restrained
way.
With the Guest VLAN function enabled, supplicant
systems that do not have 802.1x client installed can access specific network
resources. They can also upgrade their 802.1x clients without being
authenticated.
With this function enabled:
l
The switch broadcasts active authentication
packets to all 802.1x-enabled ports.
l
After the maximum number of authentication
retries have been made and there are still ports that have not sent any
response back, the switch will then add these ports into the Guest VLAN.
l
When the maximum number of authentication
retries is reached, the switch adds the ports that do not return response
packets to Guest VLAN.
l
Users belonging to the Guest VLAN can access the
resources of the Guest VLAN without being authenticated. But they need to be
authenticated before accessing external resources.
Normally, the Guest VLAN function is
coupled with the dynamic VLAN delivery function.
1.2 802.1x Configuration
802.1x provides a solution for
authenticating users. To implement this solution, you need to execute 802.1x-related
commands. You also need to configure AAA schemes on switches and to specify the
authentication scheme (RADIUS authentication scheme or local authentication
scheme).
Figure
1-10 802.1x configuration
l
802.1x users use domain names to associate with
the ISP domains configured on switches
l
Configure the AAA scheme (a local authentication
scheme or the RADIUS scheme) to be adopted in the ISP domain.
l
If you specify to use the RADIUS scheme, that is
to say the supplicant systems are authenticated by a remote RADIUS server, you
need to configure the related user names and passwords on the RADIUS server and
perform RADIUS client-related configuration on the switches.
l
If you specify to adopt a local authentication
scheme, you need to configure user names and passwords manually on the
switches. Users can pass the authentication through 802.1x client if they
provide the user names and passwords that match with those stored in the
switches.
l
You can also specify to adopt RADIUS
authentication scheme, with a local authentication scheme as a backup. In this
case, the local authentication scheme is adopted when the RADIUS server fails.
Refer to the AAA&RADIUS Operation
Manual for detailed information about AAA configuration.
To utilize 802.1x features, you need to
perform basic 802.1x configuration.
1.3.1 Prerequisites
l
Configure ISP domain and its AAA scheme, specify
the authentication scheme ( RADIUS or a local scheme) .
l
Ensure that the service type is configured as lan-access
(by using the service-type command) for local authentication scheme.
Table 1-1 Configure basic 802.1x
functions
|
Operation
|
Command
|
Description
|
|
Enter system view
|
system-view
|
—
|
|
Enable 802.1x globally
|
dot1x
|
Required
By default, 802.1x is disabled globally.
|
|
Enable 802.1x for specified ports
|
Use the following command in system view:
dot1x [ interface
interface-list ]
|
Required
By default, 802.1x is disabled for all
ports.
|
|
Use the following command in port view:
dot1x
|
|
Set port access control mode for
specified ports
|
dot1x port-control
{ authorized-force | unauthorized-force | auto } [ interface
interface-list ]
|
Optional
By default, an 802.1x-enabled port
operates in an auto mode.
|
|
Set port access method for specified
ports
|
dot1x port-method
{ macbased | portbased } [ interface interface-list
]
|
Optional
The default port access method is
MAC-address-based (that is, the macbased keyword is used by default).
|
|
Set authentication method for 802.1x
users
|
dot1x authentication-method
{ chap | pap | eap }
|
Optional
By default, a switch performs CHAP
authentication in EAP terminating mode.
|
|
Enter ISP domain view to configure the
ISP domain
|
domain isp-name
|
Optional
The default ISP domain is
“system”. This command is required if the name of the ISP domain
to which the current 802.1x user belongs is not “system”.
|
|
Configure the AAA scheme to be adopted in
the ISP domain
|
scheme { radius-scheme
radius-scheme-name [ local ] | local | none
}
|
Optional
By default, a switch adopts a local
authentication scheme.
|
|
Quit the current view and enter system
view
|
quit
|
—
|
|
Create a local user account and enter
local user view
|
local-user user-name
|
Optional
This command is required if you specify
to adopt a local authentication scheme.
|
|
Set a password for the local user account
|
password {
simple | cipher } password
|
—
|
|
Set the service type and user level for
the local user
|
service-type lan-access
|
Optional
This command is required if you specify
to adopt a local authentication scheme.
The default user level is 0
|
|
Quit the current view and enter system
view
|
quit
|
—
|
|
Create a RADIUS scheme and enter RADIUS scheme
view
|
radius scheme radius-scheme-name
|
Optional
The default RADIUS scheme is
“system”. This command is required if the name of the RADIUS
scheme adopted in the ISP domain is not “system”.
|
|
Set the IP address and port number used
by the primary RADIUS authentication/authorization server
|
primary authentication ip-address [ port-number ]
|
Optional
This command is required if the name of
the RADIUS scheme adopted in the ISP domain is not “system”.
|
Caution:
l
802.1x-related configurations can all be performed
in system view. Port access control mode and port access method can also be
configured in port view.
l
If you perform a configuration in system view
and do not specify the interface-list argument, the configuration
applies to all ports. Configurations performed in Ethernet port view apply to
the current Ethernet port only and the interface-list argument is not
needed in this case.
l
802.1x configurations take effect only after you
enable 802.1x both globally and for specified ports.
l
When both MAC-authentication and 802.1x function
are enabled, the MAC address which was defined to "quiet" status by
MAC-authentication can not pass the 802.1x authentication.
Table 1-2 Configure 802.1x timers and
the maximum number of users
|
Operation
|
Command
|
Description
|
|
Enter system view
|
system-view
|
—
|
|
Configure the maximum number of
concurrent on-line users for specified ports
|
In system view:
dot1x max-user
user-number [ interface interface-list ]
|
Optional
By default, up to 256 concurrent on-line users
are allowed on each port.
|
|
In port view:
dot1x max-user
user-number
|
|
Configure the maximum retry times to send
request packets
|
dot1x retry max-retry-value
|
Optional
By default, the maximum retry times to
send a request packet is 2. That is, the authenticator system sends a request
packet to a supplicant system for up to two times by default.
|
|
Configure 802.1x timers
|
dot1x timer { handshake-period handshake-period-value | quiet-period
quiet-period-value | tx-period tx-period-value |
supp-timeout supp-timeout-value | server-timeout server-timeout-value
}
|
Optional
The default values of 802.1x timers are
as follows:
l
handshake-period-value: 15 seconds
l
quiet-period-value: 60 seconds
l
tx-period-value: 30 seconds
l
supp-timeout-value: 30 seconds
l
server-timeout-value: 100 seconds
|
|
Trigger the quiet-period timer
|
dot1x quiet-period
|
Optional
By default, a quiet-period timer is disabled.
|
l
As for the dot1x max-user command, if you
execute it in system view without specifying the interface-list
argument, the command applies to all ports. You can also use this command in
port view. In this case, this command applies to the current port only and the interface-list
argument is not needed.
l
As for the configuration of 802.1x timers, the
default values are recommended.
Advanced 802.1x configurations, as listed
below, are all optional.
l
CAMS cooperation configuration, including multiple
network adapters detecting, proxy detecting, and so on
l
Client version checking configuration
l
Static IP address checking configuration
l
Guest VLAN configuration
Configuration of basic 802.1x
This function needs the support of 802.1x
client program and CAMS, as listed below.
l
The 802.1x clients must be able to check whether
multiple network cards, proxy servers, or IE proxy servers are used on the user
devices.
l
On CAMS, enable the function that forbids
clients from using multiple network cards, a proxy server, or an IE proxy.
By default, the use of multiple network cards,
proxy server, and IE proxy are allowed on 802.1x client. If you specify CAMS to
disable use of multiple network cards, proxy server, and IE proxy, CAMS sends
messages to 802.1x client to request the latter to disable the use of multiple
network cards, proxy server, and IE proxy when a user passes the
authentication.
Table 1-3 Configure user proxy checking
|
Operation
|
Command
|
Description
|
|
Enter system view
|
system-view
|
—
|
|
Enable user checking and control for
users logging in through proxies
|
dot1x supp-proxy-check { logoff | trap } [ interface
interface-list ]
|
Optional
|
l
The proxy checking function needs the support of
H3C’s 802.1x client program (iNode).
l
The configuration listed in Table 1-3 takes effect only when it is performed on CAMS as well as on the switch and the client version checking function is enabled on the switch (by the dot1x version-check command).
Table 1-4 Configure client version
checking
|
Operation
|
Command
|
Description
|
|
Enter
system view
|
system-view
|
—
|
|
Enable 802.1x client version checking
|
dot1x version-check [ interface interface-list ]
|
Required
By default, 802.1x client version
checking is disabled on a port.
|
|
Configure the maximum number of retires
to send version checking request packets
|
dot1x retry-version-max max-retry-version-value
|
Optional
Defaults to 3.
|
|
Configure the client-version-checking period
timer
|
dot1x timer
ver-period ver-period-value
|
Optional
The default ver-period-value is 30
seconds
|
As for the dot1x
version-user command, if you execute it in system view without specifying
the interface-list argument, the command applies to all ports. You can
also use this command in port view. In this case, this command applies to the
current port only and the interface-list argument is not needed.
Table 1-5 Enable
DHCP-triggered authentication
|
Operation
|
Command
|
Description
|
|
Enter system view
|
system-view
|
—
|
|
Enable DHCP-triggered authentication
|
dot1x dhcp-launch
|
Optional
By default, DHCP-triggered authentication
is disabled.
|
1.5.5 Configuring Guest VLAN
Table 1-6 Configure Guest VLAN
|
Operation
|
Command
|
Description
|
|
Enter
system view
|
system-view
|
—
|
|
Configure
port access method
|
dot1x port-method { macbased | portbased }
|
Optional
The
default port access method is MAC-address-based. That is, the macbased
keyword is used by default.
|
|
Enable the
Guest VLAN function
|
dot1x
guest-vlan vlan-id [ interface interface-list
]
|
Required
By
default, the Guest VLAN function is disabled.
|
Caution:
l
The Guest VLAN function is available only when
the switch operates in a port-based authentication mode.
l
Only one Guest VLAN can be configured for each switch.
l
Supplicant systems that are not authenticated,
fail to pass the authentication, or are offline belong to Guest VLANs.
l
The Guest VLAN function is not available to
switches that are configured not to authenticate users that use static IP
addresses (refer to the dot1x dhcp-launch command). (Because switches of
this type do not send active authentication packets.)
1.6 Displaying
and Debugging 802.1x
You can verify the 802.1x-related
configuration by executing the display command in any view.
You can clear 802.1x-related statistics
information by executing the reset command in user view.
Table 1-7 Display and debug 802.1x
|
Operation
|
Command
|
|
Display
the configuration, session, and statistics information about 802.1x.
|
display
dot1x [ sessions | statistics ] [
interface interface-list ]
|
|
Clear 802.1x-related statistics
information
|
reset dot1x statistics [ interface interface-list ]
|
I. Network requirements
l
Authenticate users on all ports to control their
accesses to the Internet. The switch operates in MAC address-based access
control mode. The access control mode is MAC-address-based.
l
All supplicant systems that pass the
authentication belong to the default domain named “aabbcc.net”. The
domain can accommodate up to 30 users. As for authentication, a supplicant
system is authenticated locally if the RADIUS server fails. And as for
accounting, a supplicant system is disconnected by force if the RADIUS server
fails. The name of an authenticated supplicant system is not suffixed with the
domain name. A connection is terminated if the total size of the data passes
through it during a period of 20 minutes is less than 2,000 bytes. All
connected clients belong to the same default domain: aabbcc.net, which accommodates
up to 30 clients. Authentication is performed either on the RADIUS server, or
locally ( in case that the RADIUS server fails to respond). A client is disconnected
in one of the following two situations: RADIUS accounting fails; the connected
user has not included the domain name in the username, and there is a
continuous below 2000 bytes of traffic for over 20 minutes.
l
The switch is connected to a server comprising
of two RADIUS servers whose IP addresses are 10.11.1.1 and 10.11.1.2. The
RADIUS server with an IP address of 10.11.1.1 operates as the primary
authentication server and the secondary accounting server. The other operates
as the secondary authentication server and primary accounting server. The
password for the switch and the authentication RADIUS servers to exchange
message is “name”. And the password for the switch and the
accounting RADIUS servers to exchange message is “money”. The
switch sends another packet to the RADIUS servers again if it sends a packet to
the RADIUS server and does not receive response for 5 seconds with a maximum
number of retries of 5. And the switch sends a real-time accounting packet to
the RADIUS servers once in every 15 minutes. A user name is sent to the RADIUS
servers with the domain name truncated. Connected to the switch is a server
group comprised of two RADIUS servers whose IP addresses are 10.11.1.1 and
10.11.1.2 respectively, with the former being the primary authentication and the
secondary counting server, and the latter the secondary au
