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 Figure 1-1.
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.
Following are the four
basic concept related with the above three entities, namely the PAE, controlled
port and uncontrolled port, the valid direction of a controlled port and the
way a port is controlled.
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 0x888E.
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 (alerting standards 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 does not contain the Data field, so has the Length field of 4.
Figure
1-5 shows the Data field of Request and Response type packet.
Figure 1-5 Data
fields
l
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.
l
The Type Date field differs
according to different types of Request and Response packets.
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&RADIUS&RADIUS&HWTACACS&EAD
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 S7500 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 (tx-period):
This timer sets the tx-period and is triggered by the switch in one of the
following two cases: The first case is when the client requests for
authentication. The switch sends a unicast request/identity packet to a
supplicant system and then enables the transmission timer. 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.
The second case is when the switch authenticates the 802.1x client who does not
request for authentication actively. The switch sends multicast
request/identity packets continuously through the port enabled with 802.1x
function, with the interval of tx-period.
l
Supplicant system timer (supp-timeout):
This timer sets the supp-timeout period and is triggered by the switch after
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
RADIUS server timer (server-timeout):
This timer sets the server-timeout period. The switch sends another
authentication request packet if the RADIUS 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 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
Re-authentication timer (reauth-period):
Within this timer period, a supplicant system initializes 802.1x
re-authentication.
l
Quiet-period timer (quiet-period):
This timer sets the quiet-period. When a supplicant system fails to pass the
authentication, the switch quiets for the set period (set by the quiet-period
timer) before it processes another authentication request re-initiated by the
supplicant system.
l
ver-period: This timer sets the client version request
timer. If the supplicant system does not send the version response packets
within the set period, the switch sends another version request packet.
In addition to the
earlier mentioned 802.1x features, an S7500 series switch is also capable of
the following:
l
Cooperating with a CAMS
server to perform proxy detection, such as detecting login through proxy and
multiple network adapters
l
Checking client version
l
Implementing the Guest VLAN
function
I. Proxy
detection
An S7500 series switch
implements 802.1x proxy detection to check:
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
Disconnect the supplicant
system and send 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. Client
version detection
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.
l 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 multicasts
trigger packets to all 802.1x-enabled ports.
l
After the maximum number
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
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.
Refer to AAA&RADIUS&RADIUS&HWTACACS&EAD
Operation Manual for detailed
information about dynamic VLAN assignment 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&RADIUS&HWTACACS&EAD 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.
|
|
Enable 802.1x
re-authentication
|
In system
view:
dot1x
re-authenticate [
interface interface-list ]
In port view:
dot1x
re-authenticate
|
Optional
By default,
802.1x re-authentication is disabled on all ports.
|
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 You can enable 802.1x re-authentication on the
switch either by using the dot1x re-authenticate command or through the
RADIUS server. The switch re-authenticates the user periodically if the
Termination-Action attribute value of the Access-Accept packet sent by the
server to the switch is set to 1.
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 1,024 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
|
reauth-period reauth-period-value |
quiet-period
quiet-period-value | tx-period tx-period-value | supp-timeout supp-timeout-value
| server-timeout server-timeout-value | ver-period ver-period-value
}
|
Optional
The default
values of 802.1x timers are as follows:
l
handshake-period-value: 15 seconds
l
reauth-period-value: 3,600 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
l
ver-period-value: 30 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.
l You can set 802.1x re-authentication timer on
the switch either by using the dot1x reauth-period command or through
the RADIUS server. Upon receiving an Access-Accept packet, with
Termination-Action attribute value set to 1, from the server, the switch
performs authentication at an interval of the session-timeout value of the
Access-Accept packet. In actual authentication, the switch uses the latest time
value obtained as the authentication interval.
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
DHCP –triggered
authentication
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 global proxy checking function
|
dot1x supp-proxy-check { logoff | trap }
|
Required
By default, the global 802.1X proxy
checking is disabled.
|
|
Enable proxy checking for a port
|
In system view:
dot1x supp-proxy-check { logoff | trap } [ interface
interface-list ]
|
Required
By default, the 802.1X proxy checking is
disabled for the port.
|
|
In port view:
dot1x supp-proxy-check { logoff | trap }
|
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.
After performing the
following configuration, 802.1X allows running DHCP on access users, and
triggers authentication when the user dynamically applies IP address.
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
|
—
|
|
Config |
