HEWLETT PACKARD ENTERPRISE HP 1950-12XGT User guide

HPE OfficeConnect 1950 Switch Series
User Guide
P Document version: 6W104-20190520
art number: 5998-8111b
Enterprise products and services are set f ort h i n the express warranty statements accompany i ng such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for techni cal or editorial errors or omissions contained herein.
Confidential computer software. Valid li cense from Hewlett Packa rd Enterprise required for posse ssion, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer S oftware Documentation, and Te chnical Data for Commercial Items are licen sed to the U.S. Government under vendor’s standard commercial license.
Links to third-party websites take you out side the Hewlett Packard Enterprise website. Hewlett Packard Enterprise has no control over and is not responsible for information outside the Hewlett Packard Enterprise website.
Acknowledgments
Intel®, Itanium®, Pentium®, Intel I nside®, and the Intel Inside logo are trademar ks of Intel Corporation in the United States and other countries.
Microsoft® and Windows® are trademarks of the Microsoft group of companies. Adobe® and Acrobat® are trademarks of Adobe Systems Incorpor ated. Java and Oracle are registered trademarks of O racle and/or its affiliates. UNIX® is a registered trademark of The Open Group.

Contents

Overview ························································································ 1 Restrictions: Applicable hardware platforms and software versions ············· 1 Logging in to the Web interface ··························································· 2
Restrictions and guidelines ·········································································································· 2
Web browser requirements ···································································································· 2 Default login settings ············································································································ 2
Concurrent login users ········································································································· 3 Logging in to the Web interface for the first time ··············································································· 3 Logging out of the Web interface ··································································································· 4
Using the Web interface ···································································· 5
Types of webpages ···················································································································· 6
Using a feature page ············································································································ 6
Using a table page ··············································································································· 6
Using a configuration page ···································································································· 7 Icons and buttons ······················································································································ 8 Performing basic tasks ················································································································ 9
Saving the configuration ······································································································· 9
Displaying or modifying settings of a table entry ········································································· 9
Rebooting the device ········································································································· 10
Feature navigator ··········································································· 11
Dashboard menu ····················································································································· 11 Device menu ··························································································································· 11 Network menu ························································································································· 12 Resources menu ····················································································································· 16 QoS menu ······························································································································ 17 Security menu ························································································································· 17 PoE menu ······························································································································ 18 Log menu ······························································································································· 18
Device management ······································································· 19
Settings ································································································································· 19
System time sources ·········································································································· 19
Clock synchronization protocols ··························································································· 19
NTP/SNTP operating modes ································································································ 19
NTP/SNTP time source authentication ··················································································· 20 Administrators ························································································································· 20
User account management ·································································································· 21
Role-based access control ·································································································· 21
Password control ··············································································································· 22 HPE OfficeConnect 1950 stacking (IRF) ······················································································· 24
Stack member roles ··········································································································· 25
Stack port ························································································································ 25
Stack physical interfaces ····································································································· 25
Stack domain ID ················································································································ 25
Stack split and stack merge ································································································· 25
Member priority ················································································································· 26
Network services features ································································ 27
Link aggregation ······················································································································ 27
Aggregation group ············································································································· 27
Link aggregation modes ······································································································ 28 Storm control ·························································································································· 31 Port isolation ··························································································································· 31
i
VLAN ···································································································································· 31
Port-based VLANs ············································································································· 31
VLAN interface ················································································································· 32 Voice VLAN ···························································································································· 32
OUI addresses ·················································································································· 32
QoS priority setting mode for voice traffic ················································································ 32
Voice VLAN assignment modes ··························································································· 33
Security mode and normal mode of voice VLANs ····································································· 33 MAC ····································································································································· 33
Types of MAC address entries ····························································································· 33
Aging timer for dynamic MAC address entries ········································································· 34
MAC address learning ········································································································ 34 STP ······································································································································ 34
Spanning tree modes ········································································································· 35
MSTP basic concepts ········································································································· 35
Port roles ························································································································· 35
Port states ······················································································································· 36 LLDP ····································································································································· 36
LLDP agent ······················································································································ 36
Transmitting LLDP frames ··································································································· 36
Receiving LLDP frames ······································································································ 37
LLDP reinitialization delay ··································································································· 37
LLDP trapping ·················································································································· 37
LLDP TLVs ······················································································································ 37
CDP compatibility ·············································································································· 38 DHCP snooping ······················································································································· 38 IP ········································································································································· 39
IP address classes ············································································································ 39
Subnetting and masking ····································································································· 39
IP address configuration methods ························································································· 40
MTU for an interface ·········································································································· 40 ARP ······································································································································ 40
Types of ARP table entries ·································································································· 40
Gratuitous ARP ················································································································· 41
ARP attack protection ········································································································· 41 DNS ······································································································································ 44
Dynamic domain name resolution ························································································· 44
Static domain name resolution ····························································································· 45
DNS proxy ······················································································································· 45
DDNS ····························································································································· 45 IPv6 ······································································································································ 46
IPv6 address formats ········································································································· 46
IPv6 address types ············································································································ 46
EUI-64 address-based interface identifiers ·············································································· 47
IPv6 global unicast address configuration methods ··································································· 47
IPv6 link-local address configuration methods ········································································· 48 ND ········································································································································ 49
Neighbor entries ················································································································ 49
RA messages ··················································································································· 49
ND proxy ························································································································· 51 Port mirroring ·························································································································· 52 Static routing ··························································································································· 52 Policy-based routing ················································································································· 52
Policy ······························································································································ 52
PBR and Track ················································································································· 53 IGMP snooping ······················································································································· 53 MLD snooping ························································································································· 53 DHCP ···································································································································· 53
DHCP server ···················································································································· 53
DHCP relay agent ············································································································· 55 HTTP/HTTPS ·························································································································· 56 SSH ······································································································································ 56
ii
FTP ······································································································································ 57 Telnet ···································································································································· 57 NTP ······································································································································ 57 SNMP ··································································································································· 57
MIB ································································································································ 57
SNMP versions ················································································································· 58
SNMP access control ········································································································· 58
Resources features ········································································ 60
ACL ······································································································································ 60
ACL types and match criteria ······························································································· 60
Match order ······················································································································ 60
Rule numbering ················································································································ 61 Time range ····························································································································· 62 SSL ······································································································································ 62 Public key ······························································································································ 62
Managing local key pairs ····································································································· 63
Managing peer public keys ·································································································· 63 PKI ······································································································································· 64
PKI architecture ················································································································ 64
Managing certificates ········································································································· 65 Certificate access control ··········································································································· 66
Certificate access control policies ························································································· 66
Attribute groups ················································································································ 66
QoS features ················································································· 68
QoS policies ··························································································································· 68
Traffic class ······················································································································ 68
Traffic behavior ················································································································· 68
QoS policy ······················································································································· 68
Applying a QoS policy ········································································································ 68 Hardware queuing ···················································································································· 68
SP queuing ······················································································································ 69
WRR queuing ··················································································································· 69
WFQ queuing ··················································································································· 70
Queue scheduling profile ···································································································· 71 Priority mapping ······················································································································ 71
Port priority ······················································································································ 71
Priority map ······················································································································ 72 Rate limit ································································································································ 72
Security features ············································································ 73
Packet filter ···························································································································· 73 IP source guard ······················································································································· 73
Overview ························································································································· 73
Interface-specific static IPv4SG bindings ················································································ 73
802.1X ··································································································································· 73
802.1X architecture ············································································································ 73
802.1X authentication methods ···························································································· 74
Access control methods ······································································································ 74
Port authorization state ······································································································· 74
Periodic online user reauthentication ····················································································· 75
Online user handshake ······································································································· 75
Authentication trigger ········································································································· 75
Auth-Fail VLAN ················································································································· 75
Guest VLAN ····················································································································· 76
Critical VLAN ···················································································································· 76
Mandatory authentication domain ························································································· 77
EAD assistant ··················································································································· 77 MAC authentication ·················································································································· 78
Overview ························································································································· 78
MAC authentication configuration on a port ············································································· 78
iii
Port security ··························································································································· 79
Overview ························································································································· 79
Port security settings ·········································································································· 80
Port security features ········································································································· 82
Secure MAC addresses ······································································································ 83 Portal ···································································································································· 83
Portal authentication server ································································································· 84
Portal Web server ·············································································································· 85
Local portal Web server ······································································································ 86
Portal-free rules ················································································································ 88
Interface policy ················································································································· 88 ISP domains ··························································································································· 89 RADIUS ································································································································· 90
RADIUS protocol ··············································································································· 90
Enhanced RADIUS features ································································································ 91
Log features ·················································································· 92
Log levels ························································································································ 92
Log destinations ················································································································ 92
Configuration examples ··································································· 93
Device maintenance examples ··································································································· 93
System time configuration example ······················································································· 93
Administrators configuration example ···················································································· 93
Stack configuration example ································································································ 94
NTP configuration example ································································································· 96
SNMP configuration example ······························································································· 97 Network services configuration examples ······················································································ 97
Ethernet link aggregation configuration example ······································································ 97
Port isolation configuration example ······················································································ 98
VLAN configuration example ································································································ 99
Voice VLAN configuration example ····················································································· 100
MAC address entry configuration example ············································································ 101
MSTP configuration example ····························································································· 101
LLDP configuration example ······························································································ 103
DHCP snooping configuration example ················································································ 103
Static ARP entry configuration example················································································ 104
Static DNS configuration example ······················································································· 105
Dynamic DNS configuration example ··················································································· 106
DDNS configuration example with www.3322.org ··································································· 107
Static IPv6 address configuration example ············································································ 108
ND configuration example ································································································· 109
Port mirroring configuration example ··················································································· 110
IPv4 static route configuration example ················································································ 111
IPv4 local PBR configuration example·················································································· 112
IGMP snooping configuration example ················································································· 112
MLD snooping configuration example ·················································································· 114
DHCP configuration example ····························································································· 115
Password authentication enabled Stelnet server configuration example ······································ 117 QoS configuration example ······································································································ 118 Security configuration examples ································································································ 119
ACL-based packet filter configuration example ······································································ 119
Static IPv4 source guard configuration example ····································································· 120
802.1X RADIUS authentication configuration example ···························································· 121
802.1X local authentication configuration example ·································································· 123
RADIUS-based MAC authentication configuration example ······················································ 124
RADIUS-based port security configuration example ································································ 126
Direct portal authentication configuration example ·································································· 127
Re-DHCP portal authentication configuration example ···························································· 129
Cross-subnet portal authentication configuration example ························································ 132
Direct portal authentication using local portal Web server configuration example ··························· 134
AAA for SSH users by a TACACS server configuration example ··············································· 135
iv
PoE configuration example ······································································································ 137
Network requirements ······································································································ 137
Configuration procedure ··································································································· 137
Appendix A Managing the device from the CLI ··································· 138
display poe pse ··············································································································· 139
initialize ························································································································· 140
ipsetup dhcp ··················································································································· 141
ipsetup ip address ··········································································································· 141
ipsetup ipv6 address ········································································································ 142
ipsetup ipv6 auto ············································································································· 143
password ······················································································································· 144
ping ······························································································································ 144
ping ipv6 ························································································································ 145
poe update ····················································································································· 145
quit ······························································································································· 146
reboot ··························································································································· 146
summary ······················································································································· 147
telnet ···························································································································· 149
telnet ipv6 ······················································································································ 150
transceiver phony-alarm-disable ························································································· 150
upgrade ························································································································· 151
xtd-cli-mode ··················································································································· 153
Document conventions and icons ···················································· 155
Conventions ························································································································· 155 Network topology icons ··········································································································· 156
Support and other resources ·························································· 157
Accessing Hewlett Packard Enterprise Support ············································································ 157 Accessing updates ················································································································· 157
Websites ······················································································································· 158
Customer self repair ········································································································· 158
Remote support ·············································································································· 158
Documentation feedback ·································································································· 158
Index ························································································· 160
v

Overview

This user guide provides the following information:
Information Section
How to log in to the Web interface for the first time. Logging in to the Web interface for the first time How to use the Web interface. Using the Web interface What features you can configure from the Web
interface. How to access the page for a feature or task.
How to use features in typical scenarios. Configuration examples How to manage the device from the CLI. Appendix A Managing the device from the CL I
This user guide does not include step-by-step configuration procedures, because the webpages are task oriented by design. A configuration page typically provides links to any pages that are required to complete the task. Users do not have to navigate to multiple pages. For tasks that require navigation to multiple pages, this user guide provides configuration examples.
Feature navigator
This user guide also does not provide detailed information about parameters. You can obtain sufficient online help, feature i nformation, and parameter information from the webpages.
1

Restrictions: Applicable hardware platforms and software versions

Product code HPE description Software version
JG960A HPE OfficeConnect 1950 24G 2SFP+ 2XGT Switch JG961A HPE OfficeConnect 1950 48G 2SFP+ 2XGT Switch
Release 3111P02 Release 3113P05
JG962A
HPE OfficeConnect 1950 24G 2SFP+ 2XGT PoE+(370W) Switch
JG963A
JH295A HPE OfficeConnect 1950 12XGT 4SFP+ Switch Release 5103P03
HPE OfficeConnect 1950 48G 2SFP+ 2XGT PoE+(370W) Switch
1
admin
NOTE:
If the network has a DHCP server, you must use the DHCP assigned IP address to access the device. For more information, see "Logging in to the Web interface for the first time."

Logging in to the Web interface

Log in to the Web interface through HTTP or HTTPS.

Restrictions and guidelines

To ensure a successful login, verify that your operating system and Web browser meet the requirements, and follow the guidelines in this section.

Web browser requirements

As a best practice, use one of the following Web browsers to log in:
Internet Explorer 8 or higher.
Google Chrome 10 or higher.
Mozilla Firefox 4 or higher.
Opera 11.11 or higher.
Safari 5.1 or higher.
To access the Web interface, you must use the following browser settings:
Accept the first-party cookies (cookies from the site you are accessing).
T o ensure co rrect display of webpage contents after sof tware upgrade or downgrade, clear data
cached by the browser before you log in.
Enable active scripting or JavaScript, depending on the Web browser .
If you are using a Microsoft Internet Expl orer browser, you must enable the following security
settings:
Run ActiveX controls and plug-ins. Script ActiveX controls marked safe for scripting.

Default login settings

Use the settings in Table 1 for the first login.
Table 1 Default login settings
Item Setting
Device IP (VLAN-interface 1) IP address mask Username
See "Logging in to the Web interfac e for the first
time."
Password None User role network-admin
2
IMPORTANT:
As a best practice, the first successful login for security purposes.

Concurrent login users

The Web interface allows a maximum of 32 concurrent accesses. If this limit is reached, login attempts will fail.

Logging in to the Web interface for the first time

change the login information and assign a cc ess permissions immediately after
By default, HTTP and HTTPS are enabled. To log in to the Web interface:

1. Use an Ethernet cable to connect the configuration ter m inal to an Ethernet port on the device.

2. Identify the IP address and mask of the device.

If the device is not connected to the network, or no DHCP server e xi sts on the network, the
device uses the default IP address an d mask. The default mas k is 255.255. 0.0. The defa ult IP address is 169.254.xxx.xxx, where xxx.xxx depends on the last two bytes of the MAC address. Find the MAC address label on the device and use the following rules to determine the last two bytes for the IP addre ss:
Last two bytes of the MAC address
All 0s 0.1 All Fs 255.1 Not all 0s or all Fs Decimal values of the last two bytes of the MAC address
Last two bytes for the IP address
For example:
MAC address IP address
08004E080000 169.254.0.1 08004E08FFFF 169.254.255.1
08004E082A3F
If a DHCP server is available, the device obtains an IP address from the server. To identify
the address, log in to the device through the console port , and then execute the summary command. The following is the sample output:
<Sysname> summary Select menu option: Summary IP Method: DHCP IP address: 10.153.96.86 Subnet mask: 255.255.255.0 Default gateway: 0.0.0.0
For more information about console login, see the getting started guide for the device.

3. Assign the login host an IP address in the same subnet as the device.

4. Open the browser, and then enter login informatio n:

169.254.42.63 (The decimal value of 2A is 42. The value of 3F is 63.)
3
IMPORTANT:
hen you log out of the Web i nterfa ce.
To prevent the loss of configuration when the device reboots, you m ust save the configuration.

a. In the address bar, enter the IP address of the device.

HTTP access—Enter the address in the http://ip-address:port or ip-address:port format.
HTTPS access—Enter the address in the https://ip-address:port format.
The ip-address argument represents the IP address of the device. The port argument represents the HTTP or HTTPS service port. The default port number is 80 for HTTP and 443 for HTTPS. You do not need to enter the port number if you have not changed the service port setting.

b. On the login page, enter the default username (admin) and the verification code.

You do not need to enter a password at the fi rst logi n.

c. Click Login.

5. Change the login information:

To change the password of the login user (admin at the first login), click the Admin icon
.
To add ne w user accounts and a ssign access permis sions to dif ferent users, s elect Device >
Maintenance > Administrators.

Logging out of the Web interface

For security purposes, log out of the Web interface immediately after you finish your tasks. You cannot log out by closing the browser. The device does not automatically save the configuration w

1. Use one of the following methods to save the curre nt configuration.

Click the Save icon in the left corner. Select Device > Maintenance > Configuration to access the configuration management
page.
2. Click Logout in the upper-left corner of the Web interface.
4
1) Banner and auxiliary area
2) Navigation tree
3) Content pane
(
1
)
(2)
(3)

Using the Web interface

The Web interface contains the following areas:
Area Description
Contains the following items:
Basic information, including the Hewlett Packard Enterprise logo, device name, and information about the current login user.
Basic management icons:
(1) Banner and auxiliary area
Admin icon —Click this icon to change the login
password.
Logout icon —Click this icon to log out. Save icon —Click this icon to save the configurat i on.
(2) Navigation tree Organizes feature menus in a tree.
Displays information and provides an area for you to configure features. Depending on the content in this pane, the webpages include the following
types:
(3) Content pane
Feature page—Contains functions or featur es that a feature module can provide (see "Using a featur e page").
Table page—Displays entries in a table (see "Using a table page").
Configuration page—Contains parameters for you to configure a
feature or function (see "Using a configuration page").
Figure 1 Web interface layout
5

Types of webpages

Webpages include feature, table, and configuration pages. This section provides basic information about these pages. For more information about using the icons and butt ons on the pages, see "Icons
and buttons."

Using a feature page

As shown in Figure 2, a feature page contains info rmation about a feature module, i ncluding its table entry statistics, features, and functions. From a feature page, you c an configure features prov ided by a feature module.
Figure 2 Sample feature page

Using a table page

As shown in Figure 3, a table page displays entries in a tabl e. To sort entries by a field in ascending or descending order, click the field. For example, click MAC Address to sort entries by MAC address.
6
Figure 3 Sample table page

Using a configuration page

As shown in Figure 4, one configuration page contains all parameters for a configuration task. If a parameter must be configured on another page, the conf iguration page ty pically provides a link. You do not need to navigate to the destination page.
For example, you must use an ACL when you configure a packet filter . If no ACLs are available when you perform the task, you can click the Add icon to create an ACL. In this situation, you do not
need to navigate to the ACL management page.
7
Counter icon
Status control icon
Search icons
Figure 4 Sample configuration page

Icons and buttons

Table 2 describes icons and buttons you can use to configure and manage the d evice.
Table 2 Icons and buttons
Icon/button
Help icons
Navigation icon
Icon/button name
Help Obtain help information for a feature.
Hint Obtain help information for a funct ion or parameter.
Counter Identify the total number of table entries.
Next
Status control
Task
Access the lower-level page to display information or configure settings.
Control the enable status of the featur e.
If ON is displayed, the feature is enabled. To disable the feature, click the button.
If OFF is displayed, the feature is disabled. To enable the feature, click the button.
Search
Enter a search expression in the search box, and then click this icon to perform a basic search.
8
icon
Icon/button
Entry management icons
Advanced settings
Icon/button name
Advanced search
Refresh Refresh t able entries manually.
Add
Detail
Delete
Bulk-delete
Field selector Select fields to be displayed.
Task
Click this icon, and then enter a combi nation of criteria to perform an advanced search.
Add a new entry.
Confirm the addition of an entry and continue to add an
additional entry.
Display or modify settings of an entry. This icon appears at the end of an entry when you hover
over the entry. Delete an entry.
This icon appears at the end of an entry when you hover over the entry.
Select one or multiple entries, and then click this icon to delete the selected entries.
Advanced settings Access the configuration page to configure settings.

Performing basic tasks

This section describes the basic tasks that must be frequently performed when you configure or manage the device.

Saving the configuration

Typically, settings take effect immediately after you create them. However, the system does not automatically save the settings to the configuration file. They are lost when the device reboots.
To prevent settings from being lost, use one of the following methods to sav e the configuration:
Click the Save icon in the left corner.
Select Device > Maintenance > Configuration to access the configuration management
page.

Displaying or modifying settings of a table entry

1. Hover over the entry.
2. Click the Detail icon at the end of the entry.
9

Rebooting the device

Reboot is required for some settings (for exam pl e, the stack setup) to take effect. To reboot the device:
1. Save the configuration.
2. Select Device > Maintenance > Reboot.
3. On the reboot page, click the reboot button.
10
NOTE:
In the navigator tables, a menu is in boldface if it has submenus.

Feature navigator

Menu items and icons available to you depend on the user roles you have. By default, you can use any user roles to display information. To configure features, you must have the network-admin user role.
This chapter describes all menus available for the network-admin user role. The top-level menu includes Dashboard, Device, Network, Resources, QoS, Security, PoE, and Log. For each top menu, a navigator table is provided. Use the navigator tables to navigate to the pages for the tasks you want to perform.
For example:
To change the default device name, select Device > Maintenance > Settings from the navigation tree.
To delete an IPv4 ACL, sel ect Resources > ACL > IPv4 from the navigation tree.

Dashboard menu

The dashboard menu provides an overview of t he sy stem and its running status, including:
System logs.
System utilization.
System info.
This menu does not contain submenus.

Device menu

Use Table 3 to navigate to the tasks you can perform from the Device menu.
Table 3 Device menu navigator
Menus Tasks
Maintenance
Settings
Administrators
Configure basic device settings, including the device name, location, and contact.
Configure the system time settings. You can manually set the system time, or configure the device to obtain the UTC time from a trusted time source and calculate the system time.
Create, modify, or delete user roles.
Create, modify, or delete user accounts.
Assign user roles to administrators for access control.
Manage passwords.
11
Menus Tasks
Save the running configuration.
Import configuration and export the running configuration. This task is
Configuration
File System
Upgrade
not supported in Release 3111P02.
Display the running configuration.
Restore the factory-default configuration.
Display storage medium information.
Display file and folder information.
Delete files.
Download and upload files
Upgrade software images.
Display software image lists, incl uding:
Current software images. Main and backup startup software images.
Diagnostics
Reboot Reboot the device.
About
Virtualization
IRF

Network menu

Use Table 4 to navigate to the tasks you can perform from the Network menu.
Collect diagnostic information used for system diagnostics and troubleshooting.
Display basic device information, including:
Device name.
Serial number.
Version information.
Electronic label.
Legal statement.
Configure the following settings to set up an HPE OfficeConnect 1950
stack:
Member ID. Priority. Domain ID. Stack port bindings.
Display the stack topology.
Table 4 Network menu navigator
Menus Tasks
Probe
Ping
Tracert
Interfaces
Test the connectivity to a device in an IPv4 network.
Test the connectivity to a device in an IPv6 network.
IPv4 Tracert.
IPv6 Tracert.
12
Menus Tasks
Display interfaces and their attributes, including:
Interface status. IP address.
Interfaces
Speed and duplex mode. Interface description.
Change interface settings.
Delete logical interfaces.
Link Aggregation Create, modify, or delete Layer 2 aggregation groups.
Set the statistics polling interval.
Storm Constrain
Set storm control parameters.
Display storm control informati on.
Isolation
Links
VLAN
Create isolation groups.
Modify isolation groups.
Configure port-based VLANs.
Create VLAN-interfaces.
Assign ports to voice VLANs.
Set the port mode to manual or automatic.
Voice VLAN
Set the voice VLAN mode to normal or security.
Configure the QoS settings for voice packets.
Add OUI addresses.
Create or delete static MAC entries, dynamic MAC entries, and
MAC
blackhole MAC entries.
Display existing MAC entries.
Enable or disable STP globally.
Enable or disable STP on interfaces.
STP
Configure the STP operating mode as STP, RSTP, PVST, or MSTP.
Configure instance priorities.
Configure MST regions.
Enable or disable LLDP.
LLDP
Modify the LLDP operating mode.
Modify the interface mode.
Configure LLDP to advertise the specified TLVs.
Configure a port as a trusted or untrusted port.
Record and back up DHCP snooping entries.
Configure the following features for DHCP snooping ports:
MAC address check.
DHCP Snooping
DHCP-REQUEST check. DHCP packet rate limit. Max DHCP snooping entries.
Enable support for Option 82. If Option 82 is enabled, you can configure the handling strategy, the padding format, and the padding contents for Option 82.
IP
IP
Configure the method to obtain an IP address (DHCP or static).
Configure the IP address or MTU of an interfac e.
Create a loopback interface.
13
Menus Tasks
Manage dynamic ARP entries and static ARP entries.
ARP
DNS
Configure ARP proxy.
Configure gratuitous ARP .
Configure ARP attack protection.
Configure IPv4 static domain name resolut ion.
Configure IPv4 dynamic domain name resolution.
Configure the DNS proxy.
Configure IPv4 domain name suffixes.
Dynamic DNS
IPv6
IPv6
ND
DNS
Manage dynamic DNS policies.
Configure an interface to be associat ed with the dynamic DNS policy.
Configure the method to obtain an IPv6 address (manual assignment,
dynamic assignment, or auto generati on).
Configure the IPv6 address of an interface.
Create a loopback interface.
Manage dynamic ND entries and static ND entries.
Configure the aging time for stale ND entries.
Minimize link-local ND entries.
Configure hop limit.
Configure RA prefix attributes, including:
Address prefix. Prefix length. Valid lifetime. Preferred lifetime.
Configure RA settings for an interface, including:
RA message suppression. Maximum and minimum intervals for sending RA messages. Hop limit. M-flag. O-flag. Router lifetime. NS retransmission interval. Router preference. Neighbor reachable time.
Enable common and local ND proxy on an interface.
Configure ND rules for the interface.
Configure static and dynamic IPv 6 domain name resolution.
Configure the IPv6 DNS proxy.
Configure IPv6 domain name suffixes.
Mirroring
Port Mirroring
Routing
Routing Table
Configure local mirroring groups.
Configure remote mirroring groups.
Display IPv4 and IPv6 routing table information, including brief routin g table information and route statistics.
14
Menus Tasks
Static Routing
Policy-Based Routing
Multicast
IGMP Snooping
MLD Snooping
Service
DHCP
HTTP/HTTPS
SSH (not available in Release 3111P02)
FTP
Display IPv4 and IPv6 static route ent ries.
Create, modify, and delete IPv4 and IPv6 static route entries.
Create, modify, and delete IPv4 and IPv6 policies.
Configure interface PBR.
Configure local PBR.
Configure IGMP snooping functions, including:
Enable dropping unknown mul ticast data. Configure the IGMP snooping querier. Enable fast-leave processing. Set the maximum number of multicas t groups on a port.
Configure MLD snooping functions, including:
Enable dropping unknown IPv 6 m ul ticast data. Configure the MLD snooping querier. Enable fast-leave processing. Set the maximum number of IPv6 multi c ast groups on a port.
Configure DHCP server functions, including:
Configure DHCP services. Configure the interface to operate in the DHCP server mode. Configure DHCP address pools. Configure the IP address conflict detection.
Configure DHCP relay agent functions, including:
Configure DHCP services. Configure the DHCP relay agent mode Configure the IP address of the DHCP server
Configure settings for DHCP relay entry, include:
Recording of DHCP relay entries. Periodic refreshing of DHCP relay entr i es . Interval for refreshing DHCP relay ent r i es .
Enable or disable HTTP service.
Enable or disable HTTPS service.
Set the Web connection idle timeout.
Set the HTTP service port number.
Set the HTTPS service port number.
Specify Web access control ACLs.
Enable the Stelnet, SFTP, and SCP services.
Set the DSCP in packets sent by the device.
Filter SSH clients by using an ACL.
Set the SFTP connection idle timeout time.
Enable or disable FTP service.
Set the DSCP value for the device to use for outgoing FTP packets.
Specify the FTP access control ACL.
Set the FTP connection idle timeout.
15
Public key
NOTE:
You can create ACLs from ACL pages or during th e process of configuring a featu re that uses ACLs. However, to modify or delete an ACL, you must access the ACL menu.
Menus Tasks
Telnet
NTP Configure the device to use the local cloc k as the reference clock.
SNMP

Resources menu

The Resources menu contains common resources that can be used by multiple features. For example, you can use an ACL both in a p acket filter to filter traffic and in a QoS pol icy to match traf fic.
Use Table 5 to navigate to the tasks you can perform from the Resources menu.
Table 5 Resources menu navigator
Enable or disable Telnet service.
Set the DSCP values for the device to use for outgoing IPv4 or IPv6
Telnet packets.
Specify Telnet access control ACLs.
Enable SNMP.
Configure SNMP parameters such as version, community name, group,
and users.
Configure the notification sendi ng function.
Menus Tasks
ACLs
IPv4
IPv6
Ethernet Create, modify, or delete an Ethernet frame header ACL.
Time Range
Time Range
SSL
SSL
Public key
PKI
PKI
Certificate Access Control
Create, modify, or delete an IPv4 basic ACL.
Create, modify, or delete an IPv4 advanced ACL.
Create, modify, or delete an IPv6 basic ACL.
Create, modify, or delete an IPv6 advanced ACL.
Create, modify, or delete an SSL client policy.
Create, modify, or delete an SSL server policy.
Manage local asymmetric key pairs.
Manage peer host public keys.
Manage CA and local certificates.
Create, modify, or delete a PKI domain or PKI entity.
Create, modify, or delete a certificate access control policy.
Create, modify, or delete a certificate attribute group.
16
QoS
Packet Filter

QoS menu

Use Table 6 to navigate to the tasks you can perform from the QoS menu.
Table 6 QoS menu navigator
Menus
QoS Policies
Hardware Queuing Modify hardware queuing configuration.
Priority Mapping
Rate Limit Create, modify, or delete rate limit.
Tasks

Security menu

Use Table 7 to navigate to the tasks you can perform from the Security menu.
Table 7 Security menu navigator
Create, modify, or delete interface QoS policies.
Create, modify, or delete VLAN QoS policies.
Create, modify, or delete global QoS policies.
Configure the port priority.
Configure the priority trust mode for a port.
Configure priority maps:
Apply and reset the 802.1p-to-local priority map. Apply and reset the DSCP-to-802.1p pr iority map. Apply and reset the DSCP-to-DSCP priorit y map.
Menus Tasks
Create, modify, or delete a packet filter for an interface, a VLAN, or the
Packet Filter
IP Source Guard Configure an interface-specific static IPv4 source guard binding.
Access Control
802.1X
MAC Authentication
Port Security
system.
Configure the default action for t he packet filter.
Enable or disable 802.1X.
Configure the 802.1X authentication method.
Configure the port access control met hod.
Configure the port authorization state.
Configure the authentication ISP domain on a por t.
Enable or disable MAC authentication.
Configure the username format.
Configure the MAC authentication IS P domain.
Enable or disable port security
Configure the port security mode.
Configure the intrusion protection action.
Configure the NTK mode.
Configure secure MAC aging mode.
17
Authentication
Menus Tasks
Configure a portal authentication server.
Configure a portal Web server.
Portal
ISP Domains Conf igure ISP domains.
Configure a local portal Web server.
Create portal-free rules.
Create interface policies.
RADIUS Configure RADIUS schemes. TACACS Configure TACACS schemes. Local Users Configure local users.

PoE menu

Use Table 8 to navigate to the tasks you can perform from the PoE menu.
Table 8 PoE menu navigator
Menus Tasks
PoE

Log menu

Use Table 9 to navigate to the tasks you can perform from the Log menu.
Configure the maximum PoE power and power alarm threshold for the device.
Enable or disable PoE on an interface.
Configure the maximum PoE power, power supply priority, PD
description, and fault descript ion for an interface.
Table 9 Log menu navigator
Menus Tasks
Log
System Log
Settings
Display log information.
Query, collect, and delete log information.
Enable or disable log output to the log buffer, and configure the
Configure the address and port number of log hosts.
maximum number of logs in the log buffer.
18

Device management

Settings

Access the Settings page to change the device name, location, and system time.

System time sources

Correct system time is essential to network managem ent and communic ation. Configur e the system time correctly before you run the device on the network.
The device can use the manually set system time, or obtain the UTC time fr om a time source on the network and calculate the system time.
When using the locally set system time, the device uses the clock signals generated by its built-in crystal oscillator to maintain the system time.
If you change the time zone or daylight saving settings without changing the date or time, the device adjusts the system time based on the new settings.
After obtaining the UTC time from a time source, the dev i ce uses the UTC time and the time zone and daylight saving settings to calculate the system time. Then, the device periodically synchronizes the UTC time and recalculates the sy st em time.
If you change the time zone or daylight saving settings, the device recalculates the system time.
The system time calculated by using the UTC time from a time source is more precise. Make sure the time zone and daylight saving setting are the same as the parameters of the place
where the device resides. If the system time does not change accordingly when the daylight saving period ends, refresh the
Web interface.

Clock synchronization protocols

The device supports the following clock synchronization protocols:
NTP—Network Time Protocol. NTP is typically used in large networks to dynamically synchronize time among network devices. It provides higher clock accuracy than manual system time configuration.
SNTP—Simple NTP, a simpler implementation of NTP. SNTP uses the same packet formats and exchange procedures as NTP. However, SNTP simplifies the clock synchronization procedure. Compared with NTP, SNTP uses less resources and implements clock synchronization in shorter time, but it is not as accurate as NTP.

NTP/SNTP operating modes

NTP supports two operating modes: client/server mode and symmetric active/passive mode. The device can act only as a client in client/server mode or the active peer in symmetr ic active/passive mode.
SNTP supports only the client/server mode. The device can act only as a client.
19
Table 10 NTP/SNTP operating modes
Mode Operating process Principle Application scenario
1. A client sends a clock
synchronization message to the NTP servers.
2. Upon receiving the message, the servers automatically operate in server mode and send a
Client/server
Symmetric active/passive
reply.
3. If the client is synchronized to multiple time servers, it selects an optimal clock and synchronizes its local clock to the optimal reference source.
You can configure multiple time servers for a client.
This operating mode requires that you specify the IP address of the NTP server on the client.
1. A symmetric active peer periodically sends clock synchronization messages to a symmetric passive peer.
2. The symmetric passive peer automatically operates in symmetric passive mode and sends a reply.
3. If the symmetric active peer can be synchronized to multiple time servers, it selects an optimal clock and synchronizes its local clock to the optimal reference source.
You must specify the IP address of the symmetric passive peer on the symmetric active peer.
A client can synchronize to a server, but a server cannot synchronize to a client.
A symmetric active peer and a symmetric passive peer can be synchronized to each other. If both of them are synchronized, the peer with a higher stratum is synchronized to the peer with a lower stratum.
This mode is intended for scenarios where devices of a higher stratum synchronize to devices with a lower stratum.
This mode is most often used between servers with the same stratum to operate as a backup for one another. If a server fails to communicate with all the servers of a lower stratum, the server can still synchronize to the servers of the same stratum.

NTP/SNTP time source authentication

The time source authentication function enables the device to authenticate the received NTP or SNTP packets. This feature ensures that the device obtains the correct GMT.

Administrators

An administrator configures and manages the device from the following aspects:
User account management—Manages user account i nformat ion a nd att ribute s ( for ex ample, username and password).
Role-based access control—Manages user access permissions by user role.
Password control—Manages user passwords and controls user login status based on
predefined policies.
20
IMPORTANT:
The security supported on the current Web interface, so do not assign the security-audit user role to any users.
The service type of an administrator can be SSH, Telnet, FTP, HTTP, HTTPS, PAD, or terminal. A terminal user can access the device through the console, Aux, or Async port.

User account management

A user account on the device manages attributes for users who log in to the device with the same username. The attributes include the username, password, services, and password control parameters.

Role-based access control

Assign users user roles to control the users' access to functions and system resources. Assigning permissions to a user role includes the following:
Defines a set of rules to determine accessible or i naccessible functions for the user role.
Configures resource access policies to s pecify which interfaces and VLANs are accessible to
the user role.
To configure a function related to a resource (an interface or VLAN), a user role must have access to both the function and the resource.
Resource access policies
Resource access policies control access of user roles to syst em resources and include the following types:
Interface policy—Controls access to interfaces.
VLAN policy—Controls access to VLANs.
You can perform the following tasks on an accessible interface, VLAN:
Create or remove the interface or VLAN.
Configure attributes for the interface or VLA N.
Apply the interface or VLAN to other parameters.
Predefined user roles
The system provides predefined user roles. These user roles have access to all system resources (interfaces and VLANs). Their access permissions differ.
If the predefined user roles cannot meet t he access requirements, you can define new user roles to control the access permissions for users.
-audit user role has access only to securit y log menus. Security log menus are not
Assigning user roles
Depending on the authentication method, user role assignment has the following methods:
Local authorization—If the user passes local authorization, the device assigns the user roles specified in the local user account.
Remote authorization—If the user passes remote authorization, the remote AAA server assigns the user roles specified on the server.
A user who fails to obtain a user role is logged out of the device. If multiple user roles are assigned to a user, the user can use the collection of functions and
resources accessible to all the user roles.
21

Password control

Password control allows you to implement the following features:
Manage login and super password setup, ex pi rat i ons, and updates for device management users.
Control user login status based on predefined policies.
Local users are divided into device management users and network access users. This feature applies only to device management users.
Minimum password length
You can define the minimum length of user passwords. If a user enters a password that is shorter than the minimum length, the system rejects the password.
Password composition policy
A password can be a combination of characters from the following types:
Uppercase letters A to Z.
Lowercase letters a to z.
Digits 0 to 9.
Special characters. See Table 11.
Table 11 Special characters
Character name Symbol Character name Symbol
Ampersand sign & Apostrophe ' Asterisk * At sign @ Back quote ` Back slash \ Blank space N/A Caret ^ Colon : Comma , Dollar sign $ Dot . Equal sign = Exclamation point ! Left angle bracket < Left brace { Left bracket [ Left parenthesis (
Minus sign - Percent sign % Plus sign + Pound sign # Quotation marks " Right angle bracket > Right brace } Right brac k et ] Right parenthesis ) Semi-colon ; Slash / Tilde ~ Underscore _ Vertical bar |
Depending on the system's security requirements, you can set the minimum number of character types a password must contain and the minimum number of characters for each type, as shown in
Table 12.
22
Table 12 Password composition policy
Password combination level
Level 1 One One Level 2 Two One Level 3 Three One Level 4 Four One
Minimum number of character types
When a user sets or changes a password, t he system checks if the password meets the combi nation requirement. If the password does not meet t he requirement, the operation fails.
Password complexity checking policy
A weak password such as a password that contains the username or repeated characters is easy to be cracked. For higher security, you can configure a password compl exity checking poli cy to ensure that all user passwords are complex enough to be secure. With such a policy co nfigured, the sy stem checks password complexity when a user configures a password. If the password is complexity-incompliant, the configuration wil l fail.
You can apply the following password complexity requirements:
A password cannot contain the username or the reverse of the username. For example, if the username is abc, a password such as abc982 or 2cba is not complex enough.
A chara ct er or number cannot be included three or more times consecutively. For example, password a111 is not complex enough.
Minimum number of characters for each type
Password updating
This feature allows you to set the minimum interval at which users can change their pa ss words. If a user logs in to change the password but the time passed since the last change is less than this interval, the system denies the request. For example, if you set this interval to 48 hours, a user cannot change the password twice within 48 hours.
The set minimum interval is not effective when a use r is prompted to change the password at the first login or after its password aging time expires.
Password expiration
Password expiration imposes a lifecycle on a user password. After the password expires , the user needs to change the password.
If a user enters an expired password when logging in, the system displays an error message. The user is prompted to provide a new password and to confirm it by entering it again. The new password must be valid, and the user must enter exactly the same password when confirming it.
Telnet users, SSH users, and console users can change their own passwords. The administrator must change passwords for FTP users.
Early notice on pending password expiration
When a user logs in, the system checks whether the password will expire in a time equal to or less than the specified notification period. I f so, the system notifies the user when the password will expire and provides a choice for the user to change the password. If the user sets a new password that is complexity-compliant, the system records the new pa ssword and the setup time. If the user chooses not to change the password or the user fails to change it, the system allows the user to log in using the current password.
Telnet users, SSH users, and console users can change their own passwords. The administrator must change passwords for FTP users.
23
Login with an expired password
You can allow a user to log in a certain number of times within a period of time after the password expires. For example, if you set the maximum number of logins with an expired password to 3 and the time period to 15 days, a user can log in three times within 15 days after the password expires.
Password history
With this feature enabled, the system stores passwords that a user has u sed. Wh en a user changes the password, the system checks the new password against the c urrent pa ssword and t hos e stor ed in the password history records. The new password must be different from the current one and those stored in the history records by at least four characters. The four characters must be different from one another. Otherwise, the system will display an error message, and the password will not be changed.
You can set the maximum number of history password records fo r the system to maintain for each user. When the number of history password records exceeds your setting, the most recent record overwrites the earliest one.
Current login passwords of device management users are not stored in the password history, because a device management user password is saved in cipher text and cannot be recover ed t o a plaintext password.
Login attempt limit
Limiting the number of consecutive login failures can effectively prevent password guessing. Login attempt limit takes effect on FT P and VTY users. It does not take effect on the following types
of users:
Nonexistent users (users not configured on t he device).
Users logging in to the device through console ports.
If a user fails to use a user account to log in after making the maximum number of consecutive attempts, login attempt limit takes the following actions:
Adds the user account and the user's IP addres s to the password control blacklist. This account is locked for only this user. Other users can still use this account, and the blacklisted user can use other user accounts.
Limits the user and user account in any of the following ways:
Disables the user account until the account is manually removed from the password c ontrol
blacklist.
Allows the user to continue using the user account. The user's IP address and user account
are removed from the password control blacklist when the user uses this account to successfully log in to the device.
Disables the user account for a period of time.
The user can use the account to log in when either of the following conditions exist:
The locking timer expires.
The account is manually removed from the password control blacklist before the locking
timer expires.
Maximum account idle time
Y ou can set the maximum account idle time for user acc ounts. When an account is idle for t his period of time since the last successful login, the account becomes invalid.

HPE OfficeConnect 1950 stacking (IRF)

Intelligent Resilient Framework (IRF) is true stacking technology that creates a large virtual stack from multiple devices to provide high availability and scalability. This stacking technology offers
24
NOTE:
Stacking and stack are called IRF on the webpages and in online help.
processing power, interaction, unified management, and uninterrupted maintenance of multiple devices.
A stack prov ides a single point of management. You can access the stack from any member device to configure and manage all the members as if they were interface modules on one node. Settings will be issued to all member devices in the stack.
The following information describes the concepts that you might encounter when y ou use st acking.

Stack member roles

HPE OfficeConnect 1950 stacking uses two member roles: master and standby (also called subordinate).
When devices form a stack, they elect a master to manage and control the stack. All the other members process services while backing up the master. When the master device fails, the other devices automatically elect a new master.

Stack port

A sta ck port is a logical interface for the c onnection between stack membe r devices. Every stackable device supports two stack ports. The st ack ports are referred to as IRF-port 1 and IRF-port 2.
To use a stack port, you must bind a minimum of one physical interface to it. The physical interfaces assigned to a stack port automatically form an aggregate stack link.
When you connect two neighboring stack members, connect the physical interfaces of I RF-port 1 on one member to the physical interfaces of IRF-port 2 on the other.

Stack physical interfaces

Stack physical interfaces connect stack member devices and must be bound to a stack port. They forward stack protocol packets and data packets between stack member devices.
You can use 10GBase-T or SFP+ ports for stack links. To connect the 10GBase-T Ethernet ports in a short distance, you can use Category 6A (or above)
twisted-pair cables. To connect the SFP+ ports in a short distance, you can use SFP+ DAC cables. To connect the SFP+ ports in a long distance, you must use SFP+ transceiver modules and fibers. You can assign fiber and copper ports to the same stack port. Howev er, the ports at the two ends of
a stack link must be the same type.

Stack domain ID

One stack forms one stack domain. Stack domain IDs uniquely identify stacks and prevents stacks from interfering with one another.

Stack split and stack merge

A stack split occurs when a virtual stack breaks up into two or more virtual stacks because of stac k link failures.
25
A stack merge occurs when two split virtual stacks reunite or when two independent stacks are united.

Member priority

Member priority determines the possibility of a member device to be elected the master. A member with higher priority is more likely to be elected the master.
The default m ember priority is 1. Y ou can change the member pri ority of a device to af fect the master election result.
26

Network services features

Link aggregation

Ethernet link aggregation bundles multiple physical Ethernet links into one logical link, called an aggregate link. Link aggregation has the following benefits:
Increased bandwidth beyond the limits of any single link. In an aggregate link, traffic is distributed across the member ports.
Improved link reliability. The member ports dynamically back up one another. When a mem ber port fails, its traffic is autom atically switched to other member ports.

Aggregation group

Link bundling is implemented through interface bundling. An aggregation group is a group of Ethernet interfaces bundled together. These Ethernet interfaces are called member ports of the aggregation group. Each aggregation group has a corresponding logical interface (called an aggregate interface).
When you create an aggregate interface, the device automatically creates an aggregation group of the same type and number as the aggregate interface. For example, when you create Layer 2 aggregate interface 1, Layer 2 aggregation gro up 1 i s created.
You can assign Layer 2 Ethernet interfaces only to a Layer 2 aggregation group. The port rate of an aggregate interface equal s the tot al rat e of its S electe d member p orts. Its duplex
mode is the same as that of the Selected member ports.
Aggregation states of member ports in an aggregation group
A membe r port in an aggregation group can be in any of the following aggregation states:
Selected—A Selected port can forward traffic.
Unselected—An Unselected port cannot forward traffic.
Operational key
When aggregating ports, the system automatically assigns each port an operational key based on port information, such as port rate and duplex mode. Any change to this information triggers a recalculation of the operational key.
In an aggregation group, all Selected ports have the same operational key.
Attribute configurations
To become a Selected port, a member port must have the same attribute configurations as the aggregate interface.
Feature Considerations
Port isolation
Indicates whether the port has joined an isolation group, and the isolation group to which the port belongs.
VLAN
VLAN attribute configurations i nclude:
Permitted VLAN IDs.
PVID.
VLAN tagging mode.
27

Link aggregation modes

An aggregation group operates in one of the following modes:
Static—Static aggregation is stable. An aggregation group in static mode is called a static aggregation group. The aggregation states of the member ports in a static aggre gation group are not affected by the peer ports.
Dynamic—An aggregation group in dynamic mode is called a dyna mic aggregation group. The local system and the peer system aut omatically mai ntain the agg regation state s of the mem ber ports, which reduces the administrators' workload.
An aggregation group in either mode must choose a reference port and then set the aggregation state of its member ports.
1. Aggregating links in static mode When setting the aggregation states of the ports in an aggregation group, the system
automatically picks a member port as the reference port. A Selected port must have the same operational key and attribute configurations as the reference port.
The system chooses a reference port from the member ports that are in up state and have the same attribute configurations as the aggregat e i nterface.
The candidate ports are sorted in the following order:
a. Highest port priority. b. Full duplex/high speed. c. Full duplex/low speed. d. Half duplex/high speed. e. Half duplex/low speed.
The candidate port at the top is chosen as the reference port.
If multiple ports have the same port priority, duplex mode, and speed, the port that has been
a Selected port (if any) is chosen. If multiple ports have been Selected ports, the one with the smallest port number is chosen.
If multiple ports have the same port priority, duplex m ode, and speed and none of them has
been a Selected port, the port with the smallest port number is chosen.
After the reference port is chosen, the syst em sets the aggregation state of each member port in the static aggregation group.
28
No
Operational key/attribute
configurations same as the
reference port?
More candidate ports than max.
number of Selected ports?
Is the port up
?
Is there any hardware restriction?
Port number as low as to set
the port to
the Selected state?
Set the aggregation state
of a member port
Set the port to the Selected state
Set the port to
the
Unselected state
Yes
Yes
No
Yes
No
Yes
No
Yes
No
Figure 5 Setting the aggregation state of a member port in a static aggregation group
2. Aggregating links in dynamic mode
Dynamic aggregation is implemented through I EEE 802.3ad Lin k Aggregation C ontrol Proto col (LACP).
LACP uses LACPDUs to exchange aggregation information between LACP-enabled devices. Each member port in an LACP-enabled aggregation group exchanges information with its peer.
When a member port receives an LACPDU, it com pares the received information with information received on the other member ports. In this way, the two systems reach an agreement on which ports are placed in the Selected stat e.
The system chooses a reference port from the member ports that are in up state and have the same attribute configurations as the aggregat e i nterface. A Selected port must have the same operational key and attribute configurations as the reference port.
The local system (the actor) and the peer system (the partner) negotiate a reference port by using the following workflow:
a. The two systems compare their system IDs to determine the system with the smaller system
ID. A system ID contains the system LACP priority and the system MAC address.
The two systems compare their LACP priority values. The lower the LACP priority, the smaller the syst em ID. If LACP priority values are the
same, the two systems proceed to compare their MAC addresses.
The two systems compare their MAC addresses. The lower the MAC address, the smaller the system ID.
29
No
More candidate ports than allowed
max. number of Selected ports?
Is the port up?
Is there any hardware restriction?
Port number as low as to set
the port in Selected state?
Set the aggregation state
of a member port
Set the port to the Selected state
Set the port to the
Unselected state
Yes
Yes
No
Yes
No
Yes
No Yes
No
Operational key/
attribute
configurations of the peer port same
as the peer port of the reference
port?
Yes
No
Operational key/attribute
configurations same as the
reference port?
b. The system with the smaller system ID chooses the port with the smallest port ID as the
reference port. A port ID contains a port priority and a port number. The lower the port priority, the smaller
the port ID.
The system chooses the port with the lowest priority value as the reference port. If ports have the same priority, the system proceeds to the next step.
The system compares their port numbers. The smaller the port number, the smaller t he port ID. The port with the smallest port number and the same attribute configurations as the
aggregate interface is chosen as the reference port.
After the reference port is chosen, t he system with the smaller sy stem ID s ets the state of eac h member port on its side.
Figure 6 Setting the state of a member port in a dynamic aggregation group
30
Meanwhile, the system with the higher system I D is aware of the aggre gation state change s on the peer system. The system sets the aggregation state of local m ember ports the same as their peer ports.

Storm control

Storm control compares broadcast, multicast, and unknown unicast traffic regularly with their respective traffic threshold s on an Et hernet interface. For ea ch type of traffic, storm control provides a lower threshold and an upper threshold.
Depending on your configuration, when a particular type of traffic exceeds its upper threshold, the interface performs either of the following tasks:
No actionDoes not perform any actions on the interf ace.
Block—Blocks this type of traffic and forwards other types of traffic. Even though the interface
does not forward the blocked traffic, it still counts the traffic. When the blocked traffic drops below the lower threshold, the interface begins to forward the traffic.
Shutdown—The interface goes down automatically and stops forwarding any traffic. When the blocked traffic drops below the lower threshold, the interface does not automatically come up. To bring up the interface, manually bring up the interface or disable the storm control function.
You can configure an Ethernet interface to output threshold event traps and log messages when monitored traffic meets one of the foll owing condit ions:
Exceeds the upper threshold.
Drops below the lower threshold.

Port isolation

The port isolation feature isolates Layer 2 traffic for data privacy and security without using VLANs. Ports in an isolation group cannot communicate with each other. However, they can communicate
with ports outside the isolation group.

VLAN

The Virtual Local Area Network (VLAN) technology breaks a LAN down into multiple logical LANs, which is called VLANs. Each VLAN is a broadcast domain. Hosts in the same VLAN can directly communicate with one another. Hosts in different VLANs are isolated from one another at Layer 2.

Port-based VLANs

Port-based VLANs group VLAN members by port. A port forwards packets from a VLAN only after it is assigned to the VLAN.
You can configure a port as an untagged or tagged port of a VLAN.
To configure the port as an untagged port of a VLAN, assign it to the untagged port l i st of the VLAN. The untagged port of a VLAN forwards packets from the VLAN without VLAN tags.
To configure the port as a tagged port of a VLAN, assign it to the tagged port l i st of the VLAN. The tagged port of a VLAN forwards packets from the VLAN with V LAN tags.
You can configure the link type of a port as access, trunk, or hybrid. Ports of different link types use different VLAN tag handling methods.
Access—An access port can forward packets from only one VLAN and send them untagged. Assign an access port to only the untagged po rt list of a VLAN.
31
Trunk—A trunk port can forward packets from multiple VLANs. Ex cept packets from the port VLAN ID (PVID), packets sent out of a trunk port are VLAN-tagged. Assign a trunk port to the untagged port list of the PVID of the port, and to the tagged port lists of other VLANs.
Hybrid—A hybrid port can forward packets from multip l e VLANs. You can assign a hybrid port to the untagged port lists of some VLANs, and to t he tagged port lists of other VLANs. An untagged hybrid port of a VLAN forward s pac ket s from t he VLAN wit hout VLA N ta gs. A tagged hybrid port of a VLAN forwards packets from the VLAN with VLAN tags.

VLAN interface

For hosts of different VLANs to communicate at Layer 3, you can use VLAN interfaces. VLAN interfaces are virtual interfaces used for Layer 3 communication between different VLANs. They do not exist as physical entities on devices. For each VLAN, you can create one VLAN interface and assign an IP address to it. The VLAN interface acts as the gateway of the VLAN to forward packets destined for another IP subnet.

Voice VLAN

A voice VLAN is used for transmitting voice traffic. The device can configure QoS parameters for voice packets to ensure higher transmission priority of the voice packets.

OUI addresses

A device identifies voice packets based on their source MAC addresses. A packet whose source MAC address complies with an Organizationally U nique Identifier (OUI) address of the device is regarded as a voice packet. OUI addresses are the logical AND results of MAC addresses and OUI masks.
The following table shows the default OUI addresses.
Number OUI address Vendor
1 0001-E300-0000 Siemens phone 2 0003-6B00-0000 Cisco phone 3 0004-0D00-0000 Avaya phone 4 000F-E200-0000 H3C Aolynk phone 5 0060-B900-0000 Philips/NEC phone 6 00D0-1E00-0000 Pingtel phone 7 00E0-7500-0000 Polycom phone 8 00E0-BB00-0000 3Com phone

QoS priority setting mode for voice traffic

The QoS priority settings carried in voice traffic include the CoS and DSCP values. You can configure the device to trust or modify the QoS priority settings f or voice traffic. If the device trusts the QoS priority settings in incoming voice VLAN packets, the device does not modify their CoS and DSCP values.
32

Voice VLAN assignment modes

A port can be assigned to a voice VLAN automatically or manually.
Automatic mode
When an IP phone is powered on, it sends out protocol packets. After receiving these protocol packets, the device uses the source MAC address of the protocol packets to match its OUI addresses. If the match succeeds, the d evice performs the following operations:
Assigns the receiving port of the protocol packets to the voice VLAN.
Issues ACL rules and sets the packet precedence.
Starts the voice VLAN aging timer.
If no voice packet is received from the port before the aging tim er expires, the de vice will remove t he port from the voice VLAN. The agin g timer is also configurable.
Manual mode
You must manually assign the port that connects to the IP phone to a voice VLAN. The device uses the source MAC address of the received voice packets to match its OUI addresses . If the match succeeds, the device issues ACL rules and sets the packet precedence.

Security mode and normal mode of voice VLANs

Depending on the incoming packet filtering mechanism s, a voice VLAN-enabl ed port can oper ate in one of the following modes:
Normal mode—The port receives voice-VLAN-tagged pac kets and forwards t hem in t he voice VLAN without examining their MAC addresses. If the PVID of the port is the voice VLAN and the port operates in manual VLAN assignment mode, the port forwards all the received untagged packets in the voice VLAN.
Security mode—The port uses the source MAC addresses of the received packets to match the OUI addresses of the device. Packets that fail the match will be dropped.
MAC
An Ethernet device uses a MAC address table to forward frames. A MAC address entry includes a destination MAC address, an outgoing interface (or egress RB), and a VLAN ID. When the devic e receives a frame, it uses the destination MAC address of the frame to look for a match in the MAC address table.
The device forwards the frame out of the outgoin g i nterface in the matching entry if a match is found.
The device floods the frame in the VLAN of the f rame if no match is found.

Types of MAC address entries

A MAC address table can contain the following types o f entries:
Dynamic entries—A dynamic entry can be manually configured or dynamically learned to forward frames with a specific destination M A C address out of the associated interface. A dynamic entry might age out. A manually configured dynamic entry has the same priority as a dynamically learned one.
Static entries—A static entry is manually added to forward frames with a specific destination MAC address out of the associated interface, and i t never ages out. A static entry has higher priority than a dynamically learned one.
33
Blackhole entries—A blackhole entry is manually configured and never ages out. A blackhole entry is configured for filtering out frames with a specific source or destination MAC address. For example, to block all frames destined for or s ourced from a user, you can configure the MAC address of the user as a blackhole MAC address entry.
Security entriesA security entry can be manually configured or dynami cally learned to
forward frames with a specific MAC address out of the associated interface. A security entry never ages out.

Aging timer for dynamic MAC address entries

For security and efficient us e of table space, the M AC address table uses an aging timer f or dynamic entries learned on all interfaces. If a dynamic MAC address entry is not updated before the aging timer expires, the device deletes the entry. This aging mechanism ensures that the MAC address table can promptly update to accommodate latest network topology changes.
A stable network requires a longer aging interval, and an unstable network requires a shorter aging interval.
An aging interval that is too long might cause t he MAC addres s table to retai n outdated entri es. As a result, the MAC address table resources might be exhausted, and the MAC address table might fail to update its entries to accommodate the lat est network changes.
An interval that is too short might result in rem oval of valid entries, which would cause unnecessary floods and possibly affect the device performance.
To reduce floods on a stable network, set a long aging timer or dis able t he tim er t o prevent dy namic entries from unnecessarily aging out. Reducing flood s improves the network performan ce. Reducing flooding also improves the security because it reduces the chances for a data frame to reach unintended destinations.

MAC address learning

MAC address learning is enabled by defa ult. To prevent the MAC address table from being saturated when the device is experiencing attacks, disable MAC address learning. For example, you can disable MAC address learning to prevent the device from being attacked by a large amount of frames with different source MAC addresses.
When global MAC address learning is enabled, you can disable MAC address learning on a single interface.
You can also configure the MAC learning limit on an interface to limit the MAC address table size. A large MAC address table will degrade forwarding performance. When the limit is reached, the interface stops learning any MAC addresses. You can also configure whether to forward frames whose source MAC address is not in the MAC address table.
STP
Spanning tree protocols perform the following tasks:
Prune the loop structure into a loop-free tree structure for a Layer 2 network by selectively blocking ports.
Maintain the tree structure for the live network.
Spanning tree protocols include STP, RSTP, and MSTP:
STP—Defined in IEEE 802.1d.
RSTP—Defined in IEEE 802.1w. RSTP achiev es rapid network convergence by allowing a
newly elected root port or designated port to enter the forwarding state much faster than STP.
34
PVSTPVST allows every VLAN to have its own spanning tree, which increases usage of links and bandwidth.
MSTP—Defined in IEEE 802.1s. MSTP overcomes the limitations of STP and RST P. It supports rapid network convergence and allows data f l ows of different VLANs to be forwarded along separate paths. This provides a bet ter load sharing mechanism for redundant l i nks.

Spanning tree modes

The spanning tree modes include:
STP mode—All ports of the device send STP BPDUs. S el ect this mode when the peer device of a port supports only STP.
RSTP mode—All ports of the device send RSTP BPDUs. A port in this mode automatically transits to the STP mode when it receives STP BPDUs from a peer devi ce. The port does not transit to the MSTP mode when it receives MSTP BPDUs from a peer device.
PVST mode—All ports of the device send PVST BPDUs. Each VLA N maintains a spanning tree. In a network, the number of spanning trees maintained by al l devices equals the number of PVST-enabled V LANs multiplied by the number of PVST-enabled ports. If the number of spanning trees exceeds the capacity of the netwo rk, device CPU s become overloaded, packet forwarding is interrupted, and the network becomes unstable. The num ber of spanning trees that a device can maintain varies by device model.
MSTP mode—All ports of the device send MSTP BPDUs. A port in this mode automatically transits to the STP mode when it receives STP BPDUs from a peer device. The port does not transit to the RSTP mode when it receives RSTP BPDUs from a peer device.

MSTP basic concepts

MSTP divides a switched network into multiple spanning tree regions (MST regions). MSTP maintains multiple independent spanning trees in an MST regi on, and each spanning tree i s mapped to specific VLANs. Such a spanning tree is referred to as a multiple spanning tree instance (MSTI). The common spanning tree (CST) is a single spanning tree that connects all MST regions in the switched network. A n inter nal spanning tree (IST) i s a spannin g tree that runs in an MST regio n. It is also called MSTI 0, a special MSTI to which all VLANs are mapped by default. The common and internal spanning tree (CIST) is a single spanning tree that connects all devices in the switched network. It consists of the ISTs in all MST regions and the CST.
Devices in an MST region have the following characteristics:
A spanning tree protocol enabled.
Same region name.
Same VLAN-to-instance mapping configuration.
Same MSTP revision level.
Physically linked together.

Port roles

Spanning tree calculation involves the followin g port roles:
Root port—Forwards data for a non-root bridge to the root bridge. The root bridge does not have any root port.
Designated port—Forwards data to the downstream network segment or device.
Alternate port—Serves as the backup port for a root port or master port . When the ro ot port or
master port is blocked, the alternate port takes over.
35
Backup port—Serves as the backup port of a designat ed port. When the designated port is invalid, the backup port becomes the new designated port . A loop occurs when two ports of the same spanning tree device are connected, so the device blocks one of the ports. The blocked port acts as the backup.
Master port—Serves as a port on the shortest path from the local MST region to the common root bridge. The master port is not always located on the regional root. It is a root port on the IST or CIST and still a master port on the other MSTIs.
STP calculati on involves root ports, designated po rts, and alternate ports. RSTP calculation involves root ports, designated ports, alternate ports, and backup ports. MSTP calculation involves all port roles.

Port states

RSTP and MSTP define the following port states:
State Description
Forwarding The port receives and sends BPDUs, and forwards user traffic.
Learning
Discarding The port receives and sends BPDUs, but does not forward user traffic.
STP defines the following port states: Disabled, Blocking, Listening, Learning, and Forwarding. The Disabled, Blocking, and Listening states correspond t o the Discarding state in RSTP and MSTP.

LLDP

The Link Layer Discovery Protocol (LLDP) operates on the data link layer to exchange device information between directly connected devices. With LLDP, a device sends local device information as TLV (type, length, and value) triplets in LLDP Data Units (LLDPDUs) to the directly connected devices. Local device information includes its system capabilities, management IP address, device ID, and port ID. The device stores the dev ice informati on in LLDPDUs from the LLDP neighbor s in a standard MIB. LLDP enables a network management s ystem to quickly detect and identify Layer 2 network topology changes.

LLDP agent

An LLDP agent is a mapping of an entity where LLDP runs. Multiple LLDP agents can run on the same interface.
LLDP agents are divided into t he following types:
Nearest bridge agent.
Nearest customer bridge agent.
Nearest non-TPMR bridge agent.
The port receives and sends BPDUs, but does not forward user traffic. Learning is an intermediate port state.
LLDP exchanges packets between neigh bor agents and creates and maintains neighbo r information for them.

Transmitting LLDP frames

An LLDP agent operating in TxRx mode or Tx mode sends LLDP frames to its directly connected devices both periodically and when the local configuration changes. To prevent LLDP frames from
36
overwhelming the network during times of frequent changes to local device information, LLDP uses the token bucket mechanism to rate limit LLDP frames.
LLDP automatically enables the fast LLDP frame transmission mechanism in either of the following cases:
A new LLDP frame is received and carries device information new to the local device.
The LLDP operating mode of the LLDP agent changes from Disable or Rx to TxRx or Tx.
The fast LLDP frame transmission mechanism successively sends the specified number of LLDP frames at a configurable fast LLDP frame transmission interval. The mechanism helps LLDP neighbors discover the local device as soon a s possible. Then, t he normal LLDP frame transmi ssion interval resumes.

Receiving LLDP frames

An LLDP agent operating in TxRx mode or Rx mode confirms the validity of TLVs carried in every received LLDP frame. If the TLVs are valid, the LLDP agent saves the information and starts an aging timer. The initial value of the aging timer is equal to the TTL value in the Time To Live TLV carried in the LLDP frame. When the LLDP agent receives a new LLDP frame, the aging timer restarts. When the aging timer decreases to zero, the saved information ages out.
By setting the TTL multiplier, you can configure the TTL of locally sent LLDPDUs. The TTL is expressed by using the following formula:
TTL = Min (65535, (TTL multiplier × LLDP frame transmission interval + 1)) As the expression shows, the TTL can be up to 65535 seconds. TTLs greater than 65535 will be
rounded down to 65535 seconds.

LLDP reinitialization delay

When the LLDP operating mode changes on a port, the port initializes the protocol state machines after an LLDP reinitialization delay. By adjusting the delay, you can avoid frequent initializations caused by frequent changes to the LLDP operating mode on a port.

LLDP trapping

LLDP trapping notifies the network management system of events such as newly detected neighboring devices and link failures.

LLDP TLVs

A TLV is an information element that contains the type, length, and value fields. LLDPDU TLVs include the following categories:
Basic management TLVs
Organizationally (IEEE 802.1 and IEEE 802. 3) specific TLVs
LLDP-MED (media endpoint discovery) TLVs
Basic management TLVs are essential to device management. Organizationally specific TLVs and LLDP-MED TLVs are used for enhanced device management.
They are defined by standardization or other organizations and are optional for LLDPDUs.
37

CDP compatibility

CDP compatibility enables your device to receive and recognize CDP packets from a Cisco IP phone and respond with CDP packets.

DHCP snooping

DHCP snooping works between the D HCP client and server , or b etween the DHCP client and DHCP relay agent. DHCP snooping provides the following functions:
Ensures that DHCP obtain IP addresses only from authorized DHCP servers. DHCP snooping defines trusted and untrusted port s to make sure clients obtain IP addresses
only from authorized DHCP servers.
Trusted—A t rusted port can forward DHCP messages correctly to make sure the clients get
IP addresses from authorized DHCP servers.
Untrusted—An untrusted port discards received DHCP-ACK and DHCP-OFFER
messages to prevent unauthorized servers from assigning IP addresses.
Configure ports facing the DHCP server as trusted ports, and configure other ports as untr usted ports.
Records DHCP snooping entries. DHCP snooping reads DHCP-ACK messages received from trusted ports and
DHCP-REQUEST messages to create DHCP snooping ent ries. A DHCP snooping entry includes the MAC and IP addresses of a client, the port that connects to the DHCP client, and the VLAN. ARP detection uses DHCP snoopi ng entries to filter ARP packets from unauthoriz ed clients.
Backs up DHCP snooping entries automatically. The auto backup function saves DHCP snooping entries to a backu p file, and allows the DHCP
snooping device to download the entries from the backup file at device reboot. The entries on the DHCP snooping device cannot survive a reboot. The auto backup helps some other features provide services if these features must use DHCP snooping entries for user authentication.
Supports Option 82. Option 82 records the location information about the DHCP client so the administrator can
locate the DHCP client for security and accounting purposes. Option 82 contains two sub-options: Circuit ID and Remote ID.
If the DHCP relay agent supports Option 82, i t handles DHCP requests by the strategies described in the following table.
If a response returned by the DHCP server contains Option 82, DHCP snooping removes Option 82 before forwarding the respon se to the client. If the response does not contain Option 82, DHCP snooping forwards it immediately.
The following table shows the Option 82 handling strategies for DHCP requests:
If a DHCP request has…
Option 82
Handling strategy
Drop Drops the message. Keep Forwards the message without changing Option 82.
Replace
DHCP snooping…
Forwards the message after replacing the original Option 82 with the Option 82 padded accordi ng to the configured padding format, padding content, and code type.
38
If a DHCP request has…
No Option 82 N/A
IP

IP address classes

IP addressing uses a 32-bit address to identify each host on an IPv4 network. To make addresses easier to read, they are written in dotted decimal notation, each add res s being four octets in length. For example, address 00001010000000010000000100000001 in binary is written as 10.1.1.1.
Each IP address breaks down into the following sections:
Net ID—Identifies a network. T he first sev eral bits of a net ID, known as the class field or class bits, identify the class of the IP address.
Host ID—Identifies a host on a network.
IP addresses are divided int o five classes. The following table shows IP address classes and ranges. The first three classes are most typically used.
Handling strategy
DHCP snooping…
Forwards the message after adding the Option 82 padded according to the configured paddi ng format, padding content, and code type.
Class Address range Remarks
A 0.0.0.0 to 127.255.255.255
B 128.0.0.0 to 191.255.255.255 N/A C 192.0.0.0 to 223.255.255.255 N/A D 224.0.0.0 to 239.255.255.255 Multicast addresses.
E 240.0.0.0 to 255.255.255.255

Subnetting and masking

Subnetting divides a network into smal l er net wor ks ca lled su bnet s by using so m e bit s of t he host ID to create a subnet ID.
Masking identifies the boundary between the host ID and the combinati on of net ID and subnet ID. Each subnet mask comprises 32 bits that correspond to the bits in an IP addres s. I n a subnet mask,
consecutive ones represent the net ID and subnet ID, and consecutive zeros represent the host ID.
The IP address 0.0.0.0 is used by a host at startup for temporary communication. This address is never a valid destination addres s .
Addresses starting with 127 are reserv ed for loopback test. Packets destined to t hes e addresses are processed locall y as input packets rather than sent to the link.
Reserved for future use, except for the broadcast address 255.255.255.255.
Before being subnetted, Class A, B, and C network s use these default masks (also called natural masks): 255.0.0.0, 255.255.0.0, and 255.255.255.0, respectively.
Subnetting increases the number of addresses that cannot be assigned to hosts. Therefore, using subnets means accommodating fewer hosts.
39
For example, a Class B network without subnetting can accommodate 1022 more hosts than the same network subnetted into 512 subnets.
Without subnetting—65534 (216 – 2) hosts. (The two deducted addresses are the broadcast address, which has an all-one host ID, and the network address, which has an all-zero host ID.)
With subnetting—Using the first nine bits of the host-id for subnetting provides 512 (29) subnets. However, only seven bits remain available for the host ID. This allows 126 (2 hosts in each subnet, a total of 64512 (512 × 126) hosts.

IP address configuration methods

You can use the following methods to enable an interface to obtain an IP address:
Manually assign an IP address to the interface.
Configure the interface to obtain an IP address through DHCP.

MTU for an interface

When a packet exceeds the MTU of the output interface, the device processes the packet in one of the following ways:
If the packet disallows fragmentation, the dev i ce discards it.
If the packet allows fragmentation, the dev ice fragments it and forwards the fragments.
7
– 2)
Because fragmentation and reassembling consume system resources, set an appropriate MTU for an interface based on the network environment to avoid fragmentation.
ARP
ARP resolves IP addresses into MAC addresses on Ethernet networks.

Types of ARP table entries

An ARP table stores dynamic and static ARP entries.
Dynamic ARP entry
ARP automatically creates and up dates dynamic entries. A dynamic ARP entry is removed when its aging timer expires or the output interface goes down. In addition, a dynamic ARP entr y can be overwritten by a static ARP entry.
Static ARP entry
A static ARP entry is manually configured and maintained. It does not age out and cannot be overwritten by any dynamic ARP entry .
Static ARP entries protect communication between devices because attack packets cannot modify the IP-to-MAC mapping in a static ARP entry.
The device supports the following types of static ARP entries:
Long static ARP entry—It contains the IP address, MAC address, VLAN, and output interface. It is directly used for forwarding packets.
Short static ARP entry—It contains only the IP address and MAC address.
If the output interface is a VLAN interface, the device sends an A RP request whose target IP
address is the IP address in the short entry. If the sender IP and MAC addresses in the received ARP reply match the short static ARP entry, the device performs the following operations:
40
Adds the interface that received the ARP reply to the short static ARP entry.
Uses the resolved short static ARP entry to forward IP packets.
To communicate with a host by using a fixed IP-to-MAC mapping, conf igure a short stat ic A RP entry on the device. To communicate with a ho st by using a fix ed IP-to-MAC mapping through an interface in a VLAN, configure a long static ARP entry on the device.

Gratuitous ARP

In a gratuitous ARP packet, the sender IP address and the target IP address are the IP address of the sending device.
A device s ends a gratuitous ARP packet for either of the following purposes:
Determine whether its I P address is already used by another device. If the IP address is already used, the device is informed of the conflict by an ARP reply.
Inform other devices of a MAC address change.
Gratuitous ARP packet learning
This functionfeature enables a device to create or update ARP entries by using the sender IP and MAC addresses in received gratuitous ARP packets.
When this feature is disabled, the device uses received gratuitous ARP packets to update existing ARP entries only. ARP entries are not cr eated based o n the received grat uitous ARP packets, which saves ARP table space.
Periodic sending of gratuitous ARP packets
Enabling periodic sending of gratuitous ARP packets helps downstream devices update ARP entries or MAC entries in a timely manner.
This feature can implement the following f unct i ons:
Prevent gateway spoofing. Gateway spoofing occurs when an attacker uses the gateway address to send grat ui tous ARP
packets to the hosts on a network. The traffic destined for the gateway from the hosts is sent to the attacker instead. As a result, the hosts cannot access the external network.
To prevent such gateway spoofing atta cks, you can enable the gateway t o send gratuitous ARP packets at intervals. Gratuitous ARP packets contain the primary IP addres s and manually configured secondary IP addresses of the gate way , so hosts can learn correct gateway information.
Prevent A RP entries from aging out. If network traffic is heavy or if the host CPU usage is high, receiv ed ARP packets can be
discarded or are not promptly processed. E ventually, the dynamic ARP entries on the receiving host age out. The traffic between the host and the corresponding devices is interrupted until the host re-creates the ARP entries.
To prevent this problem, you can enable the gat eway to send gratuitous ARP packets periodically. Gratuitous ARP packets contain the primary I P address and manually configured secondary IP addresses of the gateway, so the receiv ing hosts can update ARP entries in a timely manner.

ARP attack protection

ARP attacks and viruses threaten LAN secu rity. Although ARP is easy to implement, it does not provide a security mechanism and is vulnerable to network attacks. Multiple features are used to detect and prevent ARP attacks.
The gateway supports the following features:
ARP blackhole routing.
41
ARP source suppression. ARP packet source MAC consistency check. ARP active acknowledgement. Source MAC-based ARP attack detection. Authorized ARP .
ARP scanning and fixed ARP.
The access device supports the following features:
ARP packet rate limit. ARP gateway protection. ARP filtering. ARP detection.
Unresolvable IP attack protection
If a device receives a large number of unresolvable IP packets from a host, the following situations can occur:
The device sends a large number of ARP requests, overloading the target subnets.
The device keeps trying to resolve the destination IP addresses, overloading its CPU.
To protect the device from such IP attacks, you can configure the following features:
ARP source suppression—Stops resolving packets f rom a host if the numb er of unresolvable IP packets from the host exceeds t he upper limit within 5 seconds. The device continues ARP resolution when the interval elapses. This feature is applicable if the attack pack ets have the same source addresses.
ARP blackhole routing—Creates a blackhole ro ute destined for an unresolvable IP address. The device drops all matching packets until the blackhole route ages out. This feature is applicable regardless of whether the attack packets have the same source addresses.
ARP packet source MAC consistency check
This feature enables a gateway to filt er out ARP pac kets whose source MAC address in the Ethernet header is different from the sender MAC address in the message body. This feature allows the gateway to learn correct ARP entries.
ARP active acknowledgement
Configure this feature on gateways to prevent user spoof i ng. ARP active acknowledgement prevents a gateway from generating incorrect ARP entries. In strict mode, a gateway performs more st rict validity checks before creating an ARP entry:
Upon receiving an ARP req uest destined f or the gateway, the gateway sends an ARP reply but does not create an ARP entry.
Upon receiving an ARP reply, the gateway determines whether it has resolved the sen der IP address:
If yes, the gateway performs active acknowledgement. When the ARP reply is verified as
valid, the gateway creates an ARP entry.
If not, the gateway discards the packet.
Source MAC-based ARP attack detection
This feature checks the number of ARP packets delivered to the CPU. If the number of packet s from the same MAC address within 5 second s exceeds a t hre shold, the device adds the MAC address to an ARP attack entry. Before the entry is aged out, the device handles the attack by using either of the following methods:
Monitor—Only generates log messages.
42
Filter—Generates log messages and filters out subsequent ARP packets from that MAC address.
Y ou can exclude the MAC addresses of some gateways and servers from this detection. This feature does not inspect ARP packets from those devices even if they are attackers.
Authorized ARP
Authorized ARP entries are generated based on the DHCP clients' address leases on the DHCP server or dynamic client entries on the DHCP relay agent.
With authorized ARP enabled, an interface is disabled from learning dynamic ARP entries. This feature prevents user spoofing and allows only authorized clients to access network resources.
ARP scanning and fixed ARP
ARP scanning is typically used together wit h the fixed A RP feature in small-scale networks. ARP scanning automatically creates ARP entries for devices in an address range. The device
performs ARP scanning using the following steps:
1. Sends ARP requests for each IP address in the addr ess range.
2. Obtains their MAC addresses through received ARP replies.
3. Creates dynamic ARP entries.
Fixed ARP converts existing dynamic AR P entries (including those generat ed through ARP scanning) to static ARP entries. This feature prevents ARP entries from being modified by attackers.
ARP packet rate limit
The ARP packet rate limit feature allows you to limit the rate of ARP packets delivered to the CPU. An ARP detection enabled device will send all received ARP packets to the CPU for inspection. Processing excessive ARP packets will make the device malfunction or even crash. To solve this problem, configure the ARP packet rate limit.
Configure this feature when ARP detection is enabled, or when ARP flood attacks are detected. If logging for ARP packet rate limit is enabled, the device sends the highest threshold-crossed ARP
packet rate within the sending interval in a log message to the information center. You can configure the information center module to set the log output rules.
ARP gateway protection
Configure this feature on interfaces not connected with a gateway to prevent gateway spoofing attacks.
When such an interface receives an ARP packet, it checks whether the sender IP address in the packet is consistent with that of any protected gateway. If yes, it discards the packet. If not, it handles the packet correctly.
ARP filtering
The ARP filtering feature can prevent gateway spoofing and user spoofing attacks. An interface enabled with this feature checks the sender IP and MAC addresses in a received ARP
packet against permitted entries. If a match is found, the packet is handled correctly. If not, the packet is discarded.
ARP detection
ARP detection enables access devices to block ARP packets from unauthorized clients to prevent user spoofing and gateway spoofing attacks. ARP detection does not check ARP packets received from ARP trusted ports.
ARP detection provides the foll owing functions:
User validity check
43
If you only enable ARP detection for a VLAN, ARP detection provides only the user validity check.
Upon receiving an ARP packet from an ARP untrusted interface, the device matches the sender IP and MAC addresses with the following entries:
Static IP source guard binding entries. DHCP snooping entries.
If a match is found, the ARP packet is considered v alid and is forwarded. If no match is found, the ARP packet is considered invalid and is discarded.
ARP packet validity check Enable validity check for ARP packets received on untrusted ports and specify the following
objects to be checked:
Sender MAC—Checks whether the sender MAC address in the message body is identical
to the source MAC address in the Ethernet header. If they are identical, the packet is forwarded. Otherwise, the packet is discarded.
Target MAC—Checks the target MAC address of ARP replies. If the target MAC address is
all-zero, all-one, or inconsistent with the destination MAC address in the Ethernet header, the packet is considered invalid and discarded.
IP—Checks the sender and target IP addresses of ARP replies, and the sender IP address
of ARP requests. All-one or multicast IP addresses are considered invalid and the corresponding packets are discarded.
ARP restricted forwa rding ARP restricted forwarding controls the forwarding of ARP packets that are received on
untrusted interfaces and have passed user vali di ty check as follows:
If the packets are ARP requests, they are forwarded through the trusted interface. If the packets are ARP replies, they are forwarded according to their destination MAC
address. If no match is found in the MAC address ta ble, they are forwarded through the trusted interface.
ARP does not have security mechanisms and is vulnerable to network attacks. To protect the network from ARP attacks, the device provides the ARP scanning and fixed ARP features.
ARP scanning is typically used together wit h the fixed A RP feature in small-scale networks. ARP scanning automatically creates ARP entries for devices in an address range. The device
performs ARP scanning in the following steps:
1. Sends ARP requests for each IP address in the addr ess range.
2. Obtains their MAC addresses through received ARP replies.
3. Creates dynamic ARP entries.
Fixed ARP converts existing dynamic AR P entries (including those generat ed through ARP scanning) to static ARP entries. This feature prevents ARP entries from being modified by attackers.
DNS
Domain Name System (DNS) is a distributed database used by TCP/IP applications to translate domain names into IP addresses. IPv4 DNS translates domain names into IPv4 addresses. IPv6 DNS translates domain names into IPv6 addresses. The domain name-to-IP address mapping is called a DNS entry.

Dynamic domain name resolution

To use dynamic domain name resolution, you must specify a DNS server address for a device. The device sends DNS queries to the DNS server for domain name resolution.
44
Y ou can configure a d omain name suf fix list so that the resolver can use the list to supply the missing part of an incomplete n ame. For example, you can configure com as t he suf f ix f or aabbcc. com. The user only needs to enter aabbcc to obtain the IP address of aabbcc.com. The resolver adds the suffix and delimiter before passing the name to the DNS server.
The name resolver handles the queries based on the domain names that the user enters:
If the user enters a domain name without a dot (.) (for example, aabbcc), the resolver considers the domain name as a host name. It adds a DNS suffix to the host name before performing the query operation. If no match is found for any host name and suffix combination, the resolver uses the user-entered domain name (for ex am pl e, aabbcc) for the IP address query.
If the user enters a domain name with a dot (.) among the let ters (for example, www.aabbcc), the resolver directly uses this domain name for the query operation. If the query f ai l s, the resolver adds a DNS suffix for anot her query operation.
If the user enters a domain name with a dot (.) at the end (for example, aabbcc.com.), the resolver considers t he domain name an FQDN and returns the successful o r failed query result. The dot at the end of the domain name is considered a terminating symbol.

Static domain name resolution

Static domain name resolution means manually creating mappings between domain names and IP addresses. For exampl e, you can create a static DNS mapping for a device so that you can Telnet to the device by using the domain name.
After a user specifies a name, the device checks t he static name resolution t able for an IP ad dress. If no IP address is available, it contacts the DNS server for dynamic name resolution, which takes more time than static name resolution. To improve efficiency, you can put frequently queried name-to-IP address mappings in the local static name resolution table.

DNS proxy

The DNS proxy performs the following operations:
Forwards the request from the DNS client to the designated DNS server.
Conveys the reply from the DNS server to the client .
The DNS proxy simplifies network management. When the DNS server addr ess is changed, you can change the configuration on only the DNS proxy instead of on each DNS client.

DDNS

DNS provides only the static mappings between domain names and IP addresses. When the IP address of a node changes, your access to the node fails.
Dynamic Domain Name System (DDNS) can dynamically update the mappings between domain names and IP addresses for DNS se rvers.
To use DDNS, a user must access the website of a DDNS service provide r and register an account. When its IP address changes, the user, as a DDNS client, sends a DDNS update request to the DDNS server to update the mapping betwee n its dom ain nam e and I P address. When receiving the update request, the DDNS server verifies the following:
The account information is correct.
The domain name to be updated belongs to the account.
If the DDNS client passes the verification, the DDNS server tells the DNS server to re-map the domain name and the IP address of the DD NS client.
45
A DDNS policy contains the DDNS server address, login I D, password, associ ated SSL client policy, and update time interval. After creating a DDNS policy, you can apply it to multiple interfaces to simplify DDNS configuration.
DDNS is supported by only IPv4 DNS, and it is used to update the mappings between domain names and IPv4 addresses.

IPv6

IPv6, also called IP next generation (IP ng), was designed by the I ETF as the successor to IPv4. One significant difference between IPv6 and IPv4 is that IPv6 increases the IP address size from 32 bits to 128 bits.

IPv6 address formats

An IPv6 address is represented as a set of 16-bit hexadecimals separated by colons (:). An IPv6 address is divided into eight groups, and each 16-bit group is represented by four hexadecimal numbers, for example, 2001:0000:130F:0000:0000:09C0:876A:130B.
To simplify the representation of IPv6 addresses, you can handle zeros in IPv6 addresses by using the following methods:
The leading zeros in each group can be removed. F or example, the above address can be represented in a shorter format as 2001:0:130F:0:0:9C0:876A:130B.
If an IPv6 address contains one or more consecutive group s of zeros, they can be repla ced by a double colon (::). For example, the above address can be represented in the shortest forma t as 2001:0:130F::9C0:876A:130B.
An IPv6 address consists of an address prefix and an interface ID, which are equivalent to the network ID and the host ID of an IPv4 address.
An IPv6 address prefix is written in IPv6-address/prefix-length notation. The prefix-length is a decimal number indicating how many leftm ost bi ts of the IPv6 address are in the address prefix.

IPv6 address types

IPv6 addresses include the following types:
Unicast address—An identifier for a single interface, similar to an IPv4 unicast address. A packet sent to a unicast address is delivered to the i nterface identified by that address.
Multicast address—An identifier for a set of int erface s (typic ally be longing to dif f erent node s), similar to an IPv4 multicast address. A packet sent to a multicast address is delivered to all interfaces identified by that address.
Broadcast addresses are replaced by multicast addre ss es in IPv6.
Anycast address—An identifier for a set of interfaces (typically belonging to different nodes). A
packet sent to an anycast address is delivered t o the nearest interface among the interfaces identified by that address. The nearest interface is chosen according to the routing protocol's measure of distance.
The type of an IPv6 address is designated by the first several bits, called the format prefix. The following table shows mappings between address types and format prefixes:
46
Type
Unicast address
Unspecified address
Loopback address
Link-local address
Global unicast address
Format prefix (binary)
00...0 (128 bits) ::/128
00...1 (128 bits) ::1/128
1111111010 FE80::/10
Other forms N/A
IPv6 prefix ID Remarks
It cannot be assigned to any node. Before acquiring a valid IPv6 address, a node fills this address in the source address field of IPv6 packets. The unspecified address cannot be used as a destination IPv6 address.
It has the same function as the loopback address in IPv4. It cannot be assigned to any physical interface. A node uses this address to send an IPv6 packet to itself.
Used for communication among link-local nodes for neighbor discovery and stateless autoconfiguration. Packets with link-local source or destination addresses are not forwarded to other links.
Equivalent to public IPv4 addresses, global unicast addresses are provided for Internet service providers. This type of address allows for prefix aggregation to restrict the number of global routing entries.
Multicast address 11111111 FF00::/8 N/A
Anycast addresses use the unicast
Anycast address
address space and have the identical structure of unicast addresses.
N/A

EUI-64 address-based interface identifiers

An interface identifier is 64-bit long and uniqu ely identif ies an interface on a link. Int erfaces generate EUI-64 address-based interface identifiers differently.
On an IEEE 802 interface (such as a VLAN interface), the interface identifier is derived from the link-layer address (typically a MAC address) of the int erf ace. The MAC address is 48-bit long.
To obtain an EUI-64 address-based interface identifier, follow these steps:
1. Insert the 16-bit binary number 1111111111111110 (hexadecimal value of FFFE) behind the 24th high-order bit of the MAC address.
2. Invert the universal/local (U/L) bit (the s eventh high-order bit). This operation makes the interface identifier have the same local or global significance as the MAC address.

IPv6 global unicast address configuration methods

Use one of the following methods to configure an IPv 6 gl obal unicast address for an interface:
EUI-64 IPv6 address—The IPv6 addres s prefix of the interface is m anually configured, and the interface identifier is generated automatically by the interface.
Manual configuration—The IPv6 global unicast address is manually configured.
47
Stateless address autoconfiguration—The IPv6 global unicast address is generated automatically according to the addres s prefix inf ormation contain ed in the RA message and the EUI-64 address-based interface identifier.
Stateful address autoconfiguration—Enables a host to acquire an IPv6 address from a DHCPv6 server.
You can configure multiple IPv6 global unicast addresses on an interface.

IPv6 link-local address configuration methods

Configure IPv6 link-local addresses by using one of the following met hods for an interface:
Automatic generation—The device automatically generates a link-local address for an interface according to the link-local address prefix (FE80::/10) and the EUI-64 address-based interface identifier.
Manual assignment—An IPv6 link-local address is manually configured.
An interface can have only one link-local address. As a best practice, use the automatic generation method to avoid link-local address conflicts. If both methods are used, manual assignment takes precedence.
If you first use automatic generation and then manual assignment, the manually assigned link-local address overwrites the automatically generated one.
If you first use manual assignment and then automatic generation, both of the following occur:
The link-local address is still the manually assigned one. The automatically generated link-local address does not take effect. If you delete the
manually assigned address, the automatically generated link-local address takes effect.
48
ND
The IPv6 Neighbor Discovery (ND) protocol uses ICMPv6 messages to provide the following functions:
Address resolution
Neighbor reachability detection
DAD
Router/prefix discovery
Stateless address autoconfiguration
Redirection
Table 13 describes the ICMPv6 messages used by ND.
Table 13 ICMPv6 messages used by ND
ICMPv6 message Type Function
Acquires the link-layer addres s of a neighbor.
Neighbor Solicitation (NS) 135
Neighbor Advertisement (NA) 136
Router Solicitation (RS) 133
Router Advertisement (RA) 134
Redirect 137

Neighbor entries

A neighbor entry stores information about a neighboring node on the link. Neighbor entries can be dynamically configured through NS and NA messages or manually configured.
You can configure a static neighbor entry by using one of the following methods:
Method 1—Associate a neighbor's IPv6 address and link-layer address with the local Layer 3 interface.
If you use Method 1, the device automatically finds the Layer 2 port connected t o the neighbor.
Method 2—Associate a neighbor's IPv6 address and li nk-layer address with a La yer 2 port in a VLAN.
If you use Method 2, make sure the corresponding V LAN interface exists and the Layer 2 port belongs to the VLAN.
Verifies whether a neighbor is reachable. Detects duplicate addresses. Responds to an NS message. Notifies the neighboring nodes of l ink layer changes. Requests an address prefix and other configuration
information for autoconfiguration after startup. Responds to an RS message. Advertises information, such as the Prefix Information
options and flag bits. Informs the source host of a better next hop on the path to
a particular destination.

RA messages

An RA me ssage is advertised by a router to all hosts on t he same link. The RA message contains the address prefix and other configuration i nformatio n fo r the hosts t o gene rate IPv 6 addre sses throu gh stateless address autoconfiguration.
49
You can enable an interface to send RA messages, specify the maximum and minimum sending intervals, and configure parameters in RA messages. The device sends RA messages at random intervals between the maximum and minimum interval s. The minimum interval should be less than or equal to 0.75 times the maximum interval.
Table 14 describes the configurable parameters in an RA message.
Table 14 Parameters in an RA message and thei r d escriptions
Parameter Description
IPv6 prefix/prefix length
Valid lifetime
Preferred lifetime
No-autoconfig flag
Off-link flag Specifies the address with the prefix to be indirectly re ac hable on the link. MTU Guarantees that all nodes on the link use the same MTU. Unlimited hops flag Specifies unlimited hops in RA messages.
M flag
The IPv6 prefix/prefix length for a host to generate an IPv6 global unicast address through stateless autoconfiguration.
Specifies the valid lifetime of a prefix. The generated IPv6 address is valid within the valid lifetime and becom es i nvalid when the valid lifetime expires.
Specifies the preferred lifetime of a prefix used for stateless autoconfiguration. After the preferred lifetime expires, the node cannot use the generated IPv6 address to establish new connections, but can receive packets destined for the IPv6 addres s . The preferred lifetime cannot be greater than the valid lifetime.
Tells the hosts not to use the address prefix for stateless autoconfiguration.
Determines whether a host uses stateful autoconfiguration to obtain an IPv6 address.
If the M flag is set, the host uses stateful autoconfiguration (for example, from a DHCPv6 server) to obtain an IPv6 address. If the flag is not set, the host uses stateless autoconfig uration to generate an IPv6 address according to its link-layer addr ess and the prefix information in the RA message.
O flag
Router Lifetime
Retrans Timer
Router Preference
Reachable Time
Determines whether a host uses stateful autoconfiguration to obtain configuration information other than IPv6 address.
If the O flag is set, the host uses stateful autoconfiguration (for example, from a DHCPv6 server) to obtain configuration information other than IPv6 address. If the flag is not set, the host uses stateless autoconfiguration.
Advertises the lifetime of an advertising router. If the lifetime is 0, the router cannot be used as the default gateway.
Specifies the interval for retransmitting the NS message after the device does not receive a response for an NS mes sage within a time period.
Specifies the router preference in an RA message. A host selects a router as the default gateway according to the router preference. If router preferences are the same, the host select s the router from which the first RA message is received.
Specifies the reachable period for a neighbor after the device detects that a neighbor is reachable. If the device needs to send a packet to the neighbor after the reachable period, the device reconfi r ms whether the neighbor is reachable.
50
4:1::100/16
4:2::100/16
IntA
4:1::99/64
IntB 4:2::99/64
Host A
Host B
Device
Device A
Device B
IntA
IntC
IntB
Host A
4:1::100/16
Host B
4:2::100/16
IntB
4:3::100/16
VLAN 2
VLAN 3

ND proxy

ND proxy enables a device to answer an NS message requesting the hardware addre ss of a host on another network. With ND proxy, hosts in different broadcast domains can communicate with each other as they would on the same network.
ND proxy includes common ND proxy and local ND proxy.
Common ND proxy
As shown in Figure 7, Interface A with IPv6 address 4:1::96/64 and Interface B with IPv6 address 4:2::99/64 belong to different subnets. Host A and Host reside on the same network but in different broadcast domains.
Figure 7 Application environment of common ND proxy
Because Host A's IPv6 address is on the same subnet as Host B's, Host A directly sends an NS message to obtain Host B's MAC address. However, Host B cannot receive the NS message because they belong to different broadcast domains.
To solve this problem, enable common ND proxy on Interface A and Interface B of the Device. The Device replies to the NS message from Host A, and forwards packets from other hosts to Host B.
Local ND proxy
As shown in Figure 8, Host A belongs to VLAN 2 and Host B belongs to VLAN 3. Host A and Host B connect to Interface A and Interface C, respectively.
Figure 8 Application environment of local ND proxy
Because Host A's IPv6 address is on the same subnet as Host B's, Host A directly sends an NS message to obtain Host B's MAC address. However, Host B cannot receive the NS message because they are in different V LA Ns.
To solve this problem, enable local ND proxy on Interface B of the router so that the router can forward messages between Host A and Host B.
51

Port mirroring

Port mirroring copies the packets passing through a port to the destination port that connects to a data monitoring device for packet analysis. The copies are called mirrored packets.
Port mirroring includes the following terms:
Source port—Monitored port on the device. Packets of the monitored port will be copied and sent to the destination port.
Source device—Device where a source port resides.
Destination port—Port that connects to the data monitoring device. Packets of the source port
will be copied and sent to the destination port.
Destination device—Device where the destin ation port resides.
Mirroring group—Includes local mirroring group and remote mirroring group.
Local mirroring group—The source port and the destination port are on the same device.
A local mir roring group is a mirroring group that cont ains the source ports and the destination port on the same device.
Remote port mirroring—The source port and the destination port are on diff erent devices.
A remote s ource group is a mirroring group that cont ains the source ports. A remote destination group is a mirroring group that contains the destination port. In remote port mirroring, mirrored packets are transmitted by the remote probe VLAN from the source device to the destination device.

Static routing

Static routes are manually configured. If a network's topology is simple, you only need to configure static routes for the network to work correctly.
Static routes cannot adapt to network topology changes. If a fault or a topological change occurs in the network, the network administrator m ust m odi fy the static routes manually.
A default rout e i s used t o forw ard packets that do not match any specific routing entry in the routing table. You can configure a default IPv4 route with destination address 0.0.0.0/0 and configure a default IPv6 route with destination address ::/0.

Policy-based routing

Policy-based routing (PBR) uses user-defined policies to route packets. A policy can specify next hops for packets that match specific criteria such as ACLs.

Policy

A policy includes match criteria and actions to be taken on the matching packets. A policy can have one or multiple nodes as follows:
Each node is identified by a node number. A smaller node number has a higher priority.
A node cont ains the following elements:
Match criterion—Uses an ACL to mat ch packets. Action—Sets a next hop for the permitted packets. You can associate a next hop with a
track entry, and specify whether the next hop is directly connected.
A node has a match mode of permit or deny.
52
A policy matches nodes in priority order against packets. If a packet mat ches th e criteri a on a node, it is processed by the action on the node. If the packet does not match the criteria on the node, it goes to the next node for a match. If the packet does not match the criteria on any node, it is forwarded according to the routing table.

PBR and Track

PBR can work with the Track feature to dynamically adapt the status of an action to the availability status of a tracked next hop.
When the track entry changes to Negative, the action is invalid.
When the track entry changes to Positive or NotReady, the action is valid.

IGMP snooping

IGMP snooping runs on a Layer 2 device as a multicast constraining mechanism. It creates Layer 2 multicast forwarding entries from IGMP packets that are exchanged between the hosts and the Layer 3 device.
The Layer 2 device forwards multicast da ta based on Layer 2 m ulticast forwa rding entries. A Layer 2 multicast forwarding entry contains the VLAN, multicast group address, multicast source address, and host ports. A host port is a multicast receiver-side port on the Layer 2 multicast device.

MLD snooping

MLD snooping runs on a Layer 2 device as an IPv6 multicast constraining mechanism. It creates Layer 2 IPv6 multicast forwarding entries from MLD packets that are exchanged between the hosts and the Layer 3 device.
The Layer 2 device forwards multicast data based on Layer 2 IPv6 multicast forwarding entries. A Layer 2 IPv6 multicast forwarding entry contains the VLAN, IPv6 multicast group address, IPv6 multicast source address, and host ports. A host port is a multicast receiver -side port on the Layer 2 multicast device.

DHCP

The Dynamic Host Configuration Protocol (DHCP) provides a framework to assign configuration information to network devices.
A typi cal DHCP applicat ion scenario has a DHCP s erver and mul tiple DHCP cli ents deployed o n the same subnet. DHCP clients can also obtain configuration parameters from a DHCP server on another subnet through a DHCP relay agent.

DHCP server

The DHCP server is well suited to networks where the following conditions exist:
Manual configuration and centralized management are difficult to implement .
IP addresses are limited. For example, an ISP limits the number of concurrent online user s, and
users must acquire IP addresses dynamically.
Most hosts do not need fixed IP addresses.
The DHCP server selects IP addresses and other parameters from an address pool and assigns them to DHCP clients. A DHCP address pool contains the following items:
Assignable IP addresses.
53
Lease duration.
Gateway addresses.
Domain name suffix.
DNS server addresses.
WINS server addresses.
NetBIOS node type.
DHCP options.
Before assigning an IP address, the DHCP server performs IP address conflict detection to verify that the IP address is not in use.
DHCP address pool
The DHCP server supports the fol l owing address assignment mechanisms:
Static address allocation—Manually bind the M AC address or ID of a client to an IP address in a DHCP address pool. When the client requests an IP address, the DHCP server assigns the IP address in the static binding to the client.
Dynamic address allocation—Specify IP address ranges in a DHCP address pool. Upon receiving a DHCP request, the DH CP server dynamically selects an IP address from the matching IP address range in the address pool.
You can specify the lease duration for IP addresses in the DHCP address pool. The DHCP server observes the fol l owing principles to select an address pool for a client:
If there is an address pool where an IP address is statically boun d to the M AC addre ss or ID of the client, the DHCP server sele cts this address pool and assigns the statically bound IP address and other configuration parameters to the client.
If no static address pool is configured, the DHCP se rver select s an addres s pool depe nding on the client location.
Client on the same subnet as the server—The DHCP server compares the IP address of
the receiving interface with the subnets of all address pools. If a match is found, the server selects the address pool with the longest-matching subnet .
Client on a different subnet than the server—The DHCP server compares the IP
address in the giaddr field of the DHCP request with the subnets of all address pools. If a match is found, the server selects the address pool with the longest-mat ching sub net.
IP address allocation sequence
The DHCP server selects an IP address for a client in the following sequence:
1. IP address statically bound to the client's MAC address or ID.
2. IP address that was ever assigned to the client.
3. IP address designated by the Option 50 field i n the DHCP-DISCOVER message sent by the
client. Option 50 is the Requested IP Address option. The client uses this o ption to specify the wanted IP address in a DHCP-DISCOVER message. The content of Option 50 is user defined.
4. First assignable IP address found in the way of selecting an address pool.
5. IP address that was a conflict or passed its lease duration. If no IP address is assignable, the
server does not respond.
DHCP options
DHCP uses the options field to carry information for dynamic address allocation and provide additional configuration information for clients.
You can customize options for the following purposes:
Add newly released DHCP option s.
54
Add options for which the vendor defines the cont ents, for example, Option 43. DHCP servers and clients can use vendor-specific options to exchange vendor-specific configuration information.
Add options for which the Web interface does not provide a dedicated configuration page. For example, you can use Option 4 to specify the time server address 1.1.1.1 for DHCP clients.
Add all option values if the actual requirement exceeds the limit for a dedicated option configuration page. For example, on the DNS server configuration page, you can specify up to eight DNS servers. To specify more than eight DNS servers, you can use Option 6 to specify all DNS servers.
The following table shows the most commonly used DHCP options.
Option number Option name Recommended padding format
3 Router IP address 6 Domain Name Server IP address 15 Domain Name ASCII string 44 NetBIOS over TCP/IP Name Server IP address 46 NetBIOS over TCP/IP Node Type Hexadecimal string 66 TFTP server name ASCII string 67 Bootfile name ASCII string 43 Vendor Specific Information Hexadecimal string
IP address conflict detection
Before assigning an IP address, the DHCP server pings the IP address.
If the server receives a response within the specified period, it selects and pings another IP address.
If it does not receive a response, the server continues to ping the IP address until a specific number of ping packets are sent. If it still does not receive a response, the server assigns the IP address to the requesting client.

DHCP relay agent

The DHCP relay agent enables clients to get IP addresses from a DHCP server on another subnet. This feature centralizes management and reduces investment by not deploying a DHCP server for each subnet.
DHCP relay entry recording
This feature enables the DHCP relay agent to automatically record clients' IP-to-MAC bindings (relay entries) after they obtain IP addresses through DHCP.
Some security functions use the relay entries to check incoming packets and block packets that do not match any entry. In this way, illegal hosts are not able to access external networks through the relay agent. Examples of the security functions are ARP address check, authorized ARP, and IP source guard.
Periodic refreshing of dynamic DHCP relay entries
A DHCP client unicasts a DHCP-RELEASE message to the DHCP server to release its IP address. The DHCP relay agent conveys the message to the DHCP server and does not remove the IP-to-MAC entry of the client.
55
With this feature, the DHCP relay agent uses the following information to periodically send a DHCP-REQUEST message to the DHCP server:
The IP address of a relay entry.
The MAC address of the DHCP relay i nterface.
The relay agent maintains the relay entries depending on what it receives from the DHCP server:
If the server returns a DHCP-ACK message or does not return any message with in an int erval, the DHCP relay agent removes the relay entry. In addition, upon receiving the DHCP-ACK message, the relay agent sends a DHCP-RELEASE message to release the IP address.
If the server returns a DHCP-NAK message, the relay agent keeps the relay entry.

HTTP/HTTPS

The device provides a built-in Web server. After you enable the Web server on th e device, users can log in to the Web interface to m anage and monitor the device.
The device's built-in Web server supports both Hypertext Transfer Protocol (HTTP) (version 1) and Hypertext Transfer Protocol Secure (HTTPS). HTTPS is more secure than HTTP because of the following items:
HTTPS uses SSL to ensure the integrity and security of data exchanged between the client and the server.
HTTPS allows you to define a certificate attribute-based access control policy to allow only legal clients to access the Web interface.
SSH
You can also specify a basic ACL for HTTP or HTTPS to prevent unauthorized Web access.
If you does not specify an ACL f or HTTP or HTTPS, or the spe cified ACL does not ex ist or does not have rules, the device permits all HTTP or HTTPS logins.
If the specifies ACL has rules, only users permitted by the ACL can log in to the Web interface through HTTP or HTTPS.
SSH is not available in Release 3111P02. Secure Shell (SSH) is a network security protocol. Using encryption and authentication, SSH can
implement secure remote access and file transfer over an insecure network. SSH uses the typical client-server model to es tablish a channel for secure data transfer based on
TCP. SSH includes two versions: SSH1.x and SSH2.0 (hereinafter referred to as SSH1 and SSH2), which
are not compatible. SSH2 is better than SSH1 in performance and security. The device can act as an SSH server to provide the f ol lowing SSH applications to SSH clients:
Secure Telnet—Stelnet provides secure and reliable network terminal access servi ces. Through Stelnet, a user can securely log in to a remote server. Stelnet can protect devices against attacks, such as IP spoofi ng and plain text password interception. The device can act as an Stelnet server or an Stelnet client.
Secure File Transfer Protocol—Based on SSH2, SFTP uses SSH connections to provide secure file transfer.
Secure Copy—Based on SSH2, SCP offers a secure method to copy files.
When acting as an Stelnet, SFTP, or SCP server, the device supports both SSH2 and SSH1 in non-FIPS mode and only SSH2 in FIPS mode.
56
FTP
File Transfer Protocol (FTP) is an application layer protocol for transferring files from one host to another over an IP network. I t uses TCP port 20 to transfer data and TCP port 21 to transfer control commands.
The device can act as the FTP server.

Telnet

The device can act as a Telnet server to allow Telnet login. Af ter you config ure Telnet service on the device, users can remotely log in to the device t o m anage and monitor the device.
To prevent unauthorized Telnet logins, you can use ACLs to filter Telnet logins.
If you does not specify an ACL for Telnet service, or the specified ACL does not exist or does not
If the specified ACL has rules, only users permitted by the ACL can Telnet to the device.
NTP
have rules, the device permits all Telnet logins.
Synchronize your device with a trusted time source by using the Network Time Protocol (NTP) or changing the system time before you run it on a li ve network.
NTP uses stratum to define the accuracy of each server. The value is in the range of 1 to 15. A smaller value represents a higher accuracy.
If the devices in a network cannot synchronize to an authoritative time source, you can perform the following tasks:
Select a device that has a relatively accurate clock from t he network.
Use the local clock of the device as the reference clock to synchronize other devices in the
You can configure the local clock as a reference clock in the Web interface.

SNMP

Simple Network Management Protocol (SNMP) is an Internet standard protocol widely used for a network management station (NMS) to access and manage the devices (agents) on a network. After you enable SNMP on the device, the device acts as an SNMP agent.
SNMP enables an NMS to read and set the values of the variables on an agent. The agent sends traps to report events to the NMS.
MIB
network.
Management Information Base (MIB) is a collection of objects. It defines hierarchical relations between objects and object properties, i ncluding object name, access privilege, and data type.
An NMS manages a device by reading and setting the values of variables (for example, interface status and CPU usage) on the device. These variables are objects in the MIB.
57
NOTE:
btree mask is smaller than the number of nodes of the OID, the short
matching.
OID and subtree
A MIB store s variables called "node s" or "objects" in a t ree hierarchy and identif ies each node with a unique OID. An OI D is a dotted numeric string that uniquely ident ifies the pat h from the root node to a leaf node. For example, the object internet is uniquely identified by the OID {1.3.6.1}.
A subtree is like a branch in the tree hierarchy. It contains a root node and the lower-level nodes of the root node. A subtree is identified by the OID of the root node.
MIB view
A MIB view is a subset of a MIB. You can control NMS access to MIB objects by specifying a MIB view for the username or community name t hat the NMS uses. For a subtree included in a MIB view, all nodes in the subtree are accessible to the NMS. For a subt ree excluded in a MIB view, all nodes in the subtree are inaccessible to the NMS.
Subtree mask
A subtree m ask is in hexadecimal format. It ident ifies a MIB view collectively with the subtree OID. T o determi ne whether an MIB object is in a MIB view , convert t he subnet mask to binary bits (0 and 1)
and match each bit with each node number of the object OID from left to right. If the 1-bit corresponded node numbers of the object OID are the same as those of the subtree OID, the MIB object is in the MIB view. The 0-bit corresponded node numbers can be different from those of the subtree OID.
For example, the view determined by the subtree OID 1.3.6.1.6.1.2.1 and the subtree mask 0xDB (1 1011011 in binary) includes all the no des under the subtree OI D 1.3.*.1.6.*.2.1, where * rep resents any number.
If the number of bits in the subtree mask i s great er than the number of nodes of the OID, the
excessive bits of the subtree mask will be ignored during subtree mask-OID matching.
If the number of bits in the su
bits of the subtree mask will be set to 1 during subtree mask-OID matching.
If no subtree mask is specified, the default subt ree mask (all ones) will be used for mask-OID

SNMP versions

You can enable SNMPv1, SNMPv2c, or SNMPv3 on a device. For an NMS and an agent to communicate, they must run the same SNMP version.
SNMPv1 and SNMPv2c use community name for authentication. An NMS can access a device only when the NMS and the device use the same community name.
SNMPv3 uses username for authentication and all ows you to configure an authentication key and a privacy key to enhance communica tion security . T he authentication key auth enticates the validity of the packet sender. The privacy key is used to encrypt the packets transmitted between the NMS and the device.

SNMP access control

SNMPv1 and SNMPv2 access control
SNMPv1 and SNMPv2 uses community name for authentication. To control NMS access to MIB objects, configure one or both of the following setti ngs on the community name that the NMS uses:
Specify a MIB view for the community. You can specify only one MIB view for a community.
58
If you grant read-only permission to the community , the NMS can only read the value s of the
objects in the MIB view.
If you grant read-write permission to the community , t he NMS can read and set th e values of
the objects in the MIB view.
Specify a basic IPv4 ACL or a basic IPv6 ACL for the community to filter illegitimate NMSs from accessing the agent.
Only NMSs with the IPv4/IPv6 address permitted in the IPv4/IPv6 ACL can access the
SNMP agent.
If you do not specify an ACL, or the specified ACL does not exist, all NMSs in the SNMP
community can access the SNMP agent. If the specified ACL does not have any rules, no NMS in the SNMP community can ac cess the SNMP agent.
SNMPv3 access control
SNMPv3 uses username for authentication. To control NMS access to MIB objects, configure one or both of the following settings on the username that the NMS uses:
Create an SNMPv3 group and assign the usernam e to the group. The user has the same access right as the group.
When you create the group, specify one or more MIB views for the group. The M IB views include read-only MIB view, read-write MIB view, or notify MIB view. You can specify only one MIB view of a type for a group.
Read-only MIB view only allows the group t o read the values of the objects in the view. Read-write MIB view allows the group to read and set the values of the object in the view. Notify MIB view automatically sends a notification to the NMS when the group accesses the
view.
Specify a basic IPv4 ACL or a basic IPv6 ACL for both the user and group to filter illegitimate NMSs from accessing the agent.
Only the NMSs permitted by ACLs specified for both the user and group can access the
agent.
If you do not specify an ACL, or the specified ACL does not exist, all NMSs in the SNMP
community can access the SNMP agent. If the specified ACL does not have any rules, no NMS in the SNMP community can acce ss the SNMP agent.
59

Resources features

Resource features are common resources that can be used by multiple features. For example, you can use an A CL both in a packet filter to filter traffic and in a QoS policy to match traffic.
The Web interface provides access to the resource creation page for features that might use the resources. When you configure these features, you can create a resource with out having to navigate to the Resources menu. However , to modify or remove a resource, you must access the Resources menu.
ACL
An access control list (ACL) is a set of rules (or permit or deny statements) for identifying traffic based on criteria such as source IP address, destination IP address, and port number.
ACLs are primarily used for packet filtering. You can use ACLs in QoS, security, routing, and other feature modules for identifying traffic. The packet drop or forwarding decisions depend on the modules that use ACLs.

ACL types and match criteria

Table 15 shows the ACL types available on the switch and the fields that can be used to filter or
match traffic.
Table 15 ACL types and match criteria
Type ACL number IP version Match criteria
Basic ACLs 2000 to 2999
Advanced ACLs 3000 to 3999
Ethernet frame header ACLs
4000 to 4999 IPv4 and IPv6
IPv4 Source IPv4 address. IPv6 Source IPv6 address.
Source IPv4 address.
Destination IPv4 address.
IPv4
IPv6
Packet priority.
Protocol number.
Other Layer 3 and Layer 4 header fields .
Source IPv6 address.
Destination IPv6 address.
Packet priority.
Protocol number.
Other Layer 3 and Layer 4 header fields .
Layer 2 header fields, including:
Source and destination MAC addresses.
802.1p priority.
Link layer protocol type.

Match order

The rules in an ACL are sorted in a specific order. When a packet matches a rule, the device stops the match process and performs the action defined in the rule. If an ACL contains overlapping or conflicting rules, the matching result and act i on to take depend on the rule order.
60
2.
NOTE:
A wildcard
bit binary number represented in dotte d decimal notation. In contrast to a network mask, the 0 bits in a wildcard mask re present "do care" bits, and the 1 bits represent "don't care" bits. If the "do care" bits in identical to the "do care" bits in an IP add ress criterion, t he IP address matche s the criterion. A ll "don't care" bits are ignored. The 0s and 1s in a wil dcard mask can be noncontiguous. For example, 0.255.0.255 is a valid wildcard mask.
The following ACL match orders are available:
config—Sorts ACL rule s in ascending o rder of rule ID. A rule with a lower ID is matched before a rule with a higher ID. If you use this method, check the rules and their order carefully.
auto—Sorts ACL rules in depth-first order. Depth-first ordering makes sure any subset of a rule is always matched before the rule. Table 16 lists the sequence of tie breakers that depth-first ordering uses to sort rules for each type of ACL.
Table 16 Sort ACL rules in depth-first order
ACL category Sequence of tie breakers
1. More 0s in the source IPv4 address wildcard (more 0s means a
IPv4 basic ACL
IPv4 advanced ACL
IPv6 basic ACL
IPv6 advanced ACL
Ethernet frame header ACL
narrower IPv4 address range).
2. Rule configured earlier.
1. Specific protocol number.
2. More 0s in the source IPv4 address wildcard mask.
3. More 0s in the destination IPv4 address wildcard.
4. Narrower TCP/UDP service port number range.
5. Rule configured earlier.
1. Longer prefix for the source IPv6 address (a longer prefix means a
narrower IPv6 address range). Rule configured earlier.
1. Specific protocol number.
2. Longer prefix for the source IP v6 address.
3. Longer prefix for the destination IPv6 address.
4. Narrower TCP/UDP service port number range.
5. Rule configured earlier.
1. More 1s in the source MAC address mask (more 1s means a smaller
MAC address).
2. More 1s in the destination MAC address mask.
3. Rule configured earlier.
mask, also called an inverse mask, is a 32-

Rule numbering

ACL rules can be manually or automatically numbered.
Rule numbering step
If you do not assign an ID to the rule you are creating, the system automatically assigns it a rule ID. The rule numbering step sets the increment by which the system automatically numbers rules. For example, the default ACL rule numbering step is 5. If you do not assign IDs to rules you are creating, they are automatically numbered 0, 5, 10, 15, and so on. The wider the numbering step, the more rules you can insert between two rules.
By introducing a gap between rules rather than contiguou sly numbering rules, you have the f lexibility of inserting rules in an ACL. This feature is important for a config-order ACL, where ACL rules are matched in ascending order of rule ID.
61
an IP address are
Automatic rule numbering and renumbering
The ID automatically assigned to an ACL rule takes the nearest higher multiple of the numbering step to the current highest rule ID, starting with 0.
For example, if the numbering step is 5 (t he default), and t here are fi ve ACL rules numbered 0, 5, 9, 10, and 12, the newly defined rule is numbered 15. If the ACL does not contain any rule, the first rule is numbered 0.
Whenever the step c hanges, the rules are renumbered, starting from 0. For example, if there are five rules numbered 5, 10, 13, 15, and 20, changing the step from 5 to 2 causes the rules to be renumbered 0, 2, 4, 6, and 8.

Time range

You can implement a service based on the time of the day by applying a time range to it. A time-based service only takes effect in any time periods specified by the time range. For example, you can implement time-based A CL rules by applying a time range to them. If a time range does not exist, the service based on the time range does not take effect.
The following basic types of time ranges are avail able:
Periodic time range—Recurs periodically on a day or days of t he week.
Absolute time range—Represents only a period of time and does not recur.
A time range i s uniquely identified by the time range name. A time range can include multipl e periodic statements and absolute statements. The active period of a time range is calculated as follows:

1. Combining all periodic statements.

2. Combining all absolute statements.

3. Taking the intersection of the two statement sets as the active period of the time range.

SSL
Secure Sockets Layer (SSL) is a cryptographic protocol that provides communication security for TCP-based application layer protocols such as HTTP. SSL has been widely used in applications such as e-business and online banking to provide secure data transmission over the Internet.
SSL provides the f ol l owing security services:
Privacy—SSL uses a symmetric encryption algorithm to encrypt data. I t uses the asymmetric key algorithm RSA to encrypt the key used by the symmetric encryption algorithm.
Authentication—SSL uses certificate-based digital signatures to authenticate the SSL server and client. The SSL server and client obtain digital certificates through PKI.
Integrity—SSL uses the message authentication code (MAC) to verif y message integrity.

Public key

The device supports the following asymmetric key algorithm s:
Revest-Shamir-Adleman Algorithm (RSA).
Digital Signature Algorithm (DSA).
Elliptic Curve Digital Signature Algorithm (ECDSA).
Many security applications, including SSH, SSL, and PKI, use asymmetric key algorit h ms to secure communications. Asymm etric key algorit hms use two separate key s (one public and one priva te) for encryption and decryption.
62
The device manages both local asymmetric key pairs and peer public keys for data encryption, decryption, and digital signature.

Managing local key pairs

Generating local key pairs
You can generate RSA, DSA, or ECDSA key pai rs on the device.
Distributing the public key of a local key pair
You can distribute the public key of a local key pair to a peer device by using one of the following methods:
Display the public key, record the key , and then import the key to the peer device through copy-and-paste.
Export the public key in a specific format to a fi le, and then import th e public key fi le to the peer device.
Display the public key in a specific format, save it to a file, and import the public key file to the peer device.
Destroying a local key pair
To avoid key compromise, destroy the local key pair and generate a new pair after any of the following conditions occurs:
An intrusion event has occurred.
The storage media of the device is replaced.
The local certificate has expired.

Managing peer public keys

To encrypt information sent to a peer device or authenticate the digital signature of the peer device, you must configure the peer device's public key on the local device.
You can import, view, and delete peer publi c keys on the local device.
Table 17 describes the peer public key configuration methods.
Table 17 Peer public key configuration methods
Method Prerequisites Remarks
1. Save the host public key in a file
Import the peer public key from a public key file (recommended)
Manually enter (type or copy) the peer public key
on the peer device.
2. Get the file from the peer device, for example, by using FTP or TFTP in binary mode.
Display and record the public key on the peer device.
The system automatically converts the imported public key to a string i n the Public Key Cryptography Standards (PKCS) format.
Be sure to enter the key in the format in which the key is displayed on the peer device. If the key is not in the correct format, the system discards the key.
Always use the first method if you are not sure of the format of the recorded public key.
63
PKI
Public Key Infrastructure (PKI) is an asymmetric key infrastructure to encrypt and decrypt data for securing network services.
PKI uses digital certificates to distribute and employ public keys, and provides network communication and e-commerce with security services such as user authentication, data confidentiality, and data integrity.
PKI provides certificate management for SSL.

Digital certificate and CRL

Digital certificate—An electronic document signed by a CA that binds a public key with the identity of its owner.
A digital certificate includes the following i nformation:
Issuer name. Subject name (name of the individual or group to which the certificate is issued). Subject's public key. Signature of the CA. Validity period.
A digital certificate must comply wit h the international standards of ITU-T X.509, of which X.509 v3 is the most commonly used.
This help covers the following types of certificates:
CA certificate—Certificate of a CA. Multiple CAs in a PKI system form a CA tree, with the
root CA at the top. The root CA gener ates a self-signed certificate, and each l ower level CA holds a CA certificate issued by the CA immediately a bove it. The chain of these certificates forms a chain of trust.
Local certificate—Digital certificate issued by a CA to a PKI entity, which contains the
entity's public key.
CRL—A certificate revocation list (CRL) is a list of seri al numbers for certificate s that have been revoked. A CRL is created and signed by the CA t hat originally issued the certificates.
The CA publishes CRLs periodically to revoke ce rtificate s. Ent ities that are associat ed with t he revoked certificates should not be trusted.
The CA must revoke a certificate when any of the following conditions occurs:
The certificate subject name is changed. The private key is compromised. The association between the subject and CA is changed. For example, when an employee
terminates employment with an organization.

PKI architecture

A PKI system consists of PKI entities, CAs, RAs and a certificate/CRL repository.
PKI entity—An end user using PKI certificates. The PKI entity can be an operator, an organization, a device like a router or a switch, or a process runni ng on a computer. A v alid PKI entity must include one or more of following identi ty categories:
Distinguished name (DN) of the entity, which further includes the common name, county
code, locality , organizat ion, unit in the organizati on, and state. If you config ure the DN for an entity, a common name is required.
FQDN of the entity. IP address of the entity.
64
CA—Certification authority that issues and manages certificates. A CA issues certificates, defines the certificate validity periods, and revokes certificates by publishing CRLs.
RA—Registration authority, which offloads the CA by processing enrollment requests. The RA accepts certificate requests, verifies user identity, and determines whether to forward the certificate requests to the CA.
Certificate/CRL repository—A certificate distribution point that stores certificates and CRLs, and distributes these certi ficates and CRLs to PKI entities. It also provides the query function. A PKI repository can be a directory server using the LDAP or HTTP protocol, of which LDAP is commonly used.

Managing certificates

The device manages certificates in PKI d omains. A PKI domain contains enr ollment information for a PKI entity . It is locally significant and is intended only for reference by other applicati ons like IKE and SSL.
Importing certificates
Y ou can import CA certificates and loc al certificates related to a P KI entity to a PKI domain. You must import certificates in the following situations:
The CRL repository is not specified on the device.
The CA server does not support SCEP.
The CA server generates the key pair for the certificates.
Before you import certificates, perform t he following tasks:
Use FTP or TFTP to upload the certificate files to the storage media of the device.
Obtain the CA certificate chain if it is neither available in the PKI domain nor contained in the
certificate to be imported.
When you import local certificates, follow these guidelines:
If the certificate to be imported contains the CA certificate chain, you also import the CA certificate by importing the local certificate.
You can directly import the local certificate if its associated CA certificate already exists on the device.
If the certificate file to be imported contains the root CA certificate, you must verify the fingerprint of the root certificate during the import. Contact the CA administrator to obtain the fingerprint of the root CA certificate.
To import a local certificate containing an encrypted key pair, you must provide the challenge password. Contact the CA administrator to obtain the password. During the import, the syst em searches the PKI domain for the key pair settings and saves the key pair accordingly. If the domain already contains the key pair, the system prompts whether you want to overwrite the existing key pair. If the PKI domain does not contain settings for the key pair, the system generates the key pair locally based on the algorithm and usage of the key pai r in the certificate.
You can import the following CA certifi cates:
Root CA certificate.
Non-root CA certificate that contains the complete certificate chain.
Non-root CA certif ic ate that cont ai ns partial certificate chain and can form complete certificate
chain with existing CA certificates on the device.
Exporting certificates
You can export the CA certificate and the local certificates in a PKI domain to certificate files. The exported certificate files can then be imported back to the device or other PKI applications.
65
Requesting certificates
To request a certificate, a PKI entity must provide its identity information and public key to a CA. You can first generate the certificate request on the device, and then send the request to the CA by
using an out-of-band method such as phone and email. Before you submit a certificate request, make sure t h e CA certificate exists in the PKI domain and a
key pair is specified for the PKI domain.
The CA certi ficate is used to verify the authenticity and validity of the obtained local certificate.
The key pair is used for certificate request. Upon receiving the public key and the identity
information, the CA signs and issues a certificate.
When generating the certificate request, the system automatically creates a key pair if the key pair specified in the PKI domain does not exist. The name, algorithm, and length of the key pair are configured in the PKI domain.

Certificate access control

Certificate access control policies

Certificate access control policies allow you to authorize acces s to a device (for example, an HTTPS server) based on the attributes of an authent icat ed client's certificate.
A certificate access control policy is a set of access control rules (permit or deny statements). Each access control rule associates an action with an attribute group.
Action—Determines whether a certificate is considered valid (Permit) or invalid (Deny).
Attribute group—Contains multiple attribute rules, each defining a matching criterion for an
attribute in the certificate issuer name, subject name, or alternative subject name field.
If a certificate matches all attribute rules in a certificate attribute group associated with an access control rule, the system determines that the certificate matches the access control rule. In this scenario, the match process stops, and the system perf orms the access control action def ined in the access control rule.
The following conditions describe how a certificate access control policy verifies the validity of a certificate:
The system matches a certificate with the access control rules (statements) in a policy in ascending order of the rule ID.
If a certificate matches a permit statement, the certificate passes the verification.
If a certificate matches a deny statement or does not match any statements in the policy, the
certificate is regarded invalid.
If a statement is associated with a non-existing attribute group, or the attribute group does not have attribute rules, the certificate matches the statement.
If the certificate access control policy r eferenced by a security appli cation (for example, HTTPS) does not exist, all certificates in the appl i cat i on pass the verification.

Attribute groups

A certific ate attribute group contains multiple attribut e rules, each defining a matc hing criterion for an attribute in the certificate issuer name, subject name, or alternativ e subject name field.
An attribute rule is a combination of an attribute-value pair with an operation keyword, as listed in
Table 18.
66
Table 18 Combinations of attribute-value pairs and operation keywords
Operation DN FQDN/IP
ctn
nctn
equ
nequ
The DN contains the specified attribute value.
The DN does not contain the specified attribute value.
The DN is the same as the specified attribute value.
The DN is not the same as the specified attribute value.
Any FQDN or IP address contains the specified attribute value.
None of the FQDNs or IP addresses contains the specified attribute value.
Any FQDN or IP address is the same as the specified attribute value.
None of the FQDNs or IP addresses are the same as the specified attribute value.
A certific ate matches an attribute rule only if it contains an attribute that matches the criterion defined in the rule.
A certificate matches an attribute group if it matches all attribute rules in the group.
67

QoS features

QoS policies

In data communications, Quality of Service (QoS) provides differentiated service guarantees for diversified traffic in terms of bandwi dth, delay, jitter, and drop rate, all of which can affect QoS.
By associating a traffic behavior with a traffic class in a QoS policy, you apply QoS actions in the traffic behavior to the traffic class.

Traffic class

A traffic class defines a set of match criteria for classifying traffic.

Traffic behavior

A traffic behavior defines a set of QoS actions to take on packets.

QoS policy

A QoS policy associates traffic classes with traffic behaviors and performs the actions in each behavior on its associated traffic class.

Applying a QoS policy

You can apply a QoS policy to the following destinations:
Interface—The QoS policy takes effect on the traf fic sent or received on the interface. The QoS policy applied to the outgoing traff i c on an interface does not regulate local packets. Local packets refer to critical protocol packets sent by the local system for operation maintenance. The most common local packets include link maintenance packets.
VLAN—The QoS policy takes effect on the traffic sent or received on all ports in the VLAN. QoS policies cannot be applied to dynamic VLANs, for example, VLANs created by GVRP.
Globally—The QoS policy takes effect o n the traffic sent or received on all ports.
Release 31 11P02 does not support applying a QoS policy to the outb ound direction of an inte rface, a VLAN, or globally.

Hardware queuing

Congestion occurs on a link or node when the traffic size exceeds the processing capability of the link or node. Congestion is unav oidable in switche d networks or mul tiuser applicat ion environments. To improve the service performance of your network, implement congestion management policies. Queuing is a typical c ongestion management technique. SP, WRR, and WFQ are typical queuing methods.
68
Queue 7
Queue 6
Queue 1
Queue 0
……
Packets to be sent through
this port
Packet
classification
High priority
Low priority
Sent packets
Interface
Sending queue
Queue
scheduling
Queue 0Weight 1
……
Queue 1Weight 2
Queue N-2Weight N-1
Queue N-1 Weight N
Packets to be sent through
this port
Sent packets
Interface
Queue
scheduling
Sending queue
Packet
classification

SP queuing

Figure 9 SP queuing
SP queuing is designed for mission -critical applications that require prefe rential service to reduce the response delay when congestion occurs. SP queuing classifies eight queues on a port into eight classes, numbered 7 to 0 in descending priority order.
SP queuing schedules the eight queues in the descending order of priority. SP queuing sends packets in the queue with the highest pri ority first. Wh en the queue with the highest prio rity is empty, it sends packets in the queue with the second highest priority, and so on. You can assign mission-critical packets to a high priority queue to make sure they are always serviced first. Common service packets can be assigned to low priority queues to be transmitted when high priority queues are empty.
The disadvantage of SP queuing is that packet s in the lower priorit y queues ca nnot be transmit ted if packets exist in the higher priority queues. In the worst case, lower priority traffic might never get serviced.

WRR queuing

Figure 10 WRR queuing
69
Queue 0Weight 1
……
Queue 1Weight 2
Queue N-2Weight N-1
Queue N-1 Weight N
Packets to be sent through
this port
Sent packets
Interface
Queue
scheduling
Sending queue
Packet
classification
WRR queuing schedules all the queues in turn to ensure every queue is serviced. For example, a port provides eight output queues. WRR assigns each queue a weig ht value (represented by w7, w6, w5, w4, w3, w2, w1, or w0). The weight value of a queue decides the proportion of resources assigned to the queue. On a 1 Gbps port, you can set the weight values to 50, 30, 10, 10, 50, 30, 10, and 10 for w7 through w0. In this way, the queue with the lowest priority can get a minimum of 50 Mbps bandwidth. In comparison, SP queuing might fail to service packets in low-priority queues for a long period of time.
Another advantage of WRR queuing is that whe n the queues are s cheduled in t urn, the servi ce time for each queue is not fixed. If a queue is empty, the next queue will be scheduled immediately. This improves bandwidth resource use efficiency.
WRR queuing includes the following types:
Basic WRR queuing—Contains multiple queues. You can configure the weight for each queue, and WRR schedules these queues based on the u ser-defined parameters in a round robin manner.
Group-based WRR queuing—All the queues are scheduled by WRR. You can divide output queues to WRR group 1 and WRR group 2. Round robin queue scheduling is performed for group 1 first. When group 1 is empty, round robin queue scheduling is performed for group 2.
On an interface enabled with group-based WRR queuing, you can assign queues to the SP group. Queues in the SP group are sc heduled with SP. The SP group has higher scheduling priority than t he WRR groups.
Only group-based WRR queuing is supported in the current software version, and only WRR group 1 is supported.

WFQ queuing

Figure 11 WFQ queuing
WFQ automatically classifies traffic based on packet fields including protocol type, TCP or UDP source/destination port numbers, source/destination IP addresses, and IP precedence bits in the T oS field. To ensure proportional scheduling fairness, WFQ provides as many queues as possible so that each traffic flow has a separate queue When dequeuing packets, WFQ assigns the outgoing interface bandwidth to each traffic flow by precedence. The higher precedence value a traffic flow has, the more bandwidth it gets.
For example, five flows exist in the current interface with precedence 0, 1, 2, 3, and 4. The total bandwidth quota is the sum of all the (precedence value + 1): 1 + 2 + 3 + 4 + 5 = 15. The bandwidth percentage assigned to each flow is (precedence value of the flow + 1)/total bandwidth quota. The bandwidth percentages for the flows are 1/15, 2/15, 3/15, 4/15, and 5/15.
70
Q7 Q6 Q5 Q4 Q3 Q2 Q1 Q0
WRR Group 2SP Group WRR Group 1
WFQ is similar to WRR. On an interface with group-based WFQ queuing enabled, you can assign queues to the SP group. Queues in the SP group are scheduled with SP. The SP group has higher scheduling priority than the WFQ groups . The dif ference is that WFQ enable s you to set guaranteed bandwidth that a WFQ queue can get during congestion.

Queue scheduling profile

Queue scheduling profiles support three queue scheduling algorithms: SP, WRR, and WFQ. In a queue scheduling profile, you can configure SP + WRR or SP + WFQ. When the three queue scheduling algorithms are configured, SP queues, WRR gr oup s, and WFQ groups are scheduled in descending order of queue ID. In a WRR or WFQ group, queues are scheduled based on their weights. When SP and WRR groups are configured in a queue scheduling profile, the following figure shows the scheduling order.
Queue 7 has the highest priority. Its packets are sent preferentially.
Queue 6 has the second highest priority. Packets in queue 6 are sent when queue 7 is empty.
Queue 3, queue 4, and queue 5 are scheduled a ccording to their weights. When both queue 6
and queue 7 are empty, WRR group 1 is scheduled.
Queue 1 and queue 2 are scheduled according to their weights. WRR group 2 is scheduled when queue 7, queue 6, queue 5, queue 4, and que ue 3 are all empty.
Queue 0 has the lowest priority, and it is scheduled when all other queues are empty.

Priority mapping

When a packet arrives, a device assigns values of priority parameters to the packet for the purpose of queue scheduling and congestion control.
Priority mapping allows you to modify the priority values of the packet according to priority mapping rules. The priority parameters decide the scheduling priority and forwarding priority of the packet.

Port priority

When a port is configured with a priority trust mode, the device trusts the priorities included in incoming packets. The device can automatically re solve the priorities or flag bits included i n packets. The device then maps the trusted priority to the target priority types and values according to the priority maps.
When a port is not configured with a priority trust mode but is configured with a port priority, the device does not trust the priorities included in incoming packets. The device uses its port priority to look for priority parameters for the incoming packets.
Configuring the port priority
After you configure a port priority for a port, the device uses its port priority to look for priority parameters for incoming packets.
71
Configuring the priority trust mode
After you configure a priority trust mode for a port, the device maps the trusted priority in incoming packets to the target priority types and values according to the priority maps.
The available priority trust modes include the following types:
Untrust—Does not trust any priority included in p ackets.
Dot1pTrusts the 802.1p priorities included in packets.
DSCPTrusts t he DSCP priorities included in IP packets.

Priority map

The device provides three priority maps: 802.1p-lp, DSCP-802.1p, and DSCP-DSCP. If a default priority map cannot meet your requirements, you can modify the priority map as required.

Rate limit

Rate limit uses token buckets for traffic control. If there are tokens in the t oken bucket, bursty traffic is allowed. Otherwise, packets are not forwar ded until new tokens are generated. In this way, packets are limited to the token generation rate while bursty traffic is allowed.
A token bu cket has the following configurable parame ters:
Mean rate at which tokens are put into the bucket, whi ch is the permitted av erage rate of traf fic. It is typically set to the committed information rate (CIR).
Burst size or the capacity of the token bucket. It is the maximum traffic size permitted in each burst. It is typically set to the committed burst size (CBS). The set burst size must be greater than the maximum packet size.
Each arriving packet is evaluated. In ea ch evaluation, if the number of tokens in the bucket is enough, the traffic conforms to the specification and the tokens for forwarding the packet are taken away. If the number of tokens in the bucket is not enough, the traffic is excessive.
When rate limit is configured on an interface, a token bucket handles all packets to be sent through the interface for rate limiting. If enough tokens are in the token bucket, packets can be forwarded. Otherwise, packets are put into QoS queues for congestion management. In this way, the traffic passing the interface is controlled.
72

Security features

Packet filter

Packet filter uses ACLs to filter incoming or outgoing packets on interfaces, VLANs, or globally. An interface permits packets that match per mit statements to pass through, and denies packets that match deny statements. The def aul t action applies to packets that do not match any ACL rules.
The packet filter feature does not support displaying the hardwarecounting result. The packet filter feature does not support applying an ACL to VLANs to filter packets.

IP source guard

Overview

IP source guard (IPSG) prevents spoofing attacks by using an IPSG binding table to match legitimate packets. It drops all packets that do not match the table.
The IPSG binding table can include the followin g bi ndings:
IP-interface.
MAC-interface.
IP-MAC-interface.
IP-VLAN-interface.
MAC-VLAN-interface.
IP-MAC-VLAN-interface.

Interface-specific static IPv4SG bindings

Interface-specific static IPv4SG bindings are configured manually and take effect only on the interface. They are suitable for scenarios where a few hosts exist on a LAN and their IP addresses are manually configured. For example, you can configure a static IPv4SG binding on an interface that connects to a server. This binding allows the interface to receive packets only f rom the server.
Static IPv4SG bindings on an interface implements the following functions:
Filter incoming IPv4 packets on the interface.
Cooperate with ARP detection for user validity checking.
You can configure the same static IPv4SG binding on different interfaces.

802.1X

802.1X is a port-based network access control protocol that controls network access by
authenticating the devices connected to 802. 1X-enabled LAN ports.

802.1X architecture

802.1X includes the following entities:
73
Client—A user term inal seeking access to t he LAN. The terminal must hav e 802.1X software to authenticate to the access device.
Access device—Authenticates the client to control access to the LAN. In a typical 802.1X environment, the access device uses an authent ication server to perform authentication.
Authentication server—Provides authent i cat i on services for the access device. The authentication server first authenticates 802.1X clients by using the data sent from the access device. Then, the server returns the auth entication results to t he access device to make ac cess decisions. The authentication server i s typically a RADI US serve r. In a small LAN, you can use the access device as the authentication server.

802.1X authentication methods

The access device can perform EAP relay or EAP termination to communicate with the RADIUS server.
EAP termination—The access device performs the following operations in EAP termination mode:
a. Terminates the EAP packets received from the client. b. Encapsulates the client authentication information in standard RADIUS packets. c. Uses PAP or CHAP to authenticate to the RADIUS server.
CHAP does not send plaintext password to t he RADIUS server, and PAP sends plaintext password to the RADIUS server.
EAP relay—The access devi ce uses EAPOR packets t o send authentication inf ormation to the RADIUS server.

Access control methods

Comware implements port -based acce ss cont rol as d efined in the 802. 1X prot ocol, an d extends t he protocol to support MAC-based access control.
Port-based access control—Once an 802.1X user passes authentication on a port , all subsequent users can access the network through the port without authentication. When the authenticated user logs off, all other users are logged off.
MAC-based access control—Each user is separately aut henticated on a port. When a user logs off, no other online users are affected.

Port authorization state

The port authorization state determines whether the client is granted access t o the network. You can control the authorization state of a port by using t he following options:
Authorized—Places the port in the authorized state, enabling users on the port to access the network without authentication.
Unauthorized—Places the port in the unauthorized state, denying any access requests from users on the port.
Auto—Places the port initially in unauthorized state to allow only EA POL packets to pass. A fter a user passes authentication, sets the port in the authorized state to allow access to the network. You can use this option in most scenarios.
74
of the port applies. The user and all subsequent 802.1X users are

Periodic online user reauthentication

Periodic online user reauthentication tracks the connection status of online users, and updates the authorization attributes assigned by the server. The attributes include the ACL, VLAN, and user profile-based QoS. The reauthentication interval is user configurable.

Online user handshake

The online user handshake feature checks the connectivity status of online 802.1X users. The access device sends handshake messages to online users at the handshake interval. If the device does not receive any responses from an online user after it has made the maximum handshake attempts, the device sets the user to offline state.
You can also enable the online user handshake security feature to check authentication infor m ation in the handshake packets from client s. Wit h thi s feature, the devic e preve nts 8 0 2.1X user s who use illegal client software from bypassing iNode security check such as dual network interface cards (NICs) detection.

Authentication trigger

The access device initiates authentication, if a client cannot send EAPOL-Start packets. One example is the 802.1X client available with Window s X P.
The access device supports the following m odes:
Unicast trigger mode—Upon receiving a frame from an unk nown MAC address, the access device sends an Identity EAP-Request packet out of the receiving port to the MAC addres s. The device retransmits the packet if no respons e has been received within the specified interval.
Multicast trigger mode—The access device multicasts Identity EAP-Request packets periodically (every 30 seconds by default) t o i nitiate 802.1X authentication.

Auth-Fail VLAN

The 802.1X Auth-Fail VLAN on a port accommodates users who have failed 802.1X authentication because of the failure to comply with the organization's security strategy. For example, the VLAN accommodates users who have entered a wrong password. The Auth-Fail VLAN does not accommodate 802.1X users who have failed authentication for authentication timeouts or network connection problems.
The access device handles VLANs on an 802.1X-enabled port based on its 802.1X access control method.
On a port that performs port-based access control:
Authentication status VLAN manipulation
A user fails 802.1X authentication.
The device assigns the Auth-Fail VLA N to the port as the PVID. All 802.1X users on this port can access only resour c es in the Auth-Fail VLAN.
A user in the 802.1X Auth-Fail VLAN fails 802.1X reauthentication
A user passes 802.1X authentication.
The Auth-Fail VLAN is still the PVID on the port, and all 802.1X users on this port are in this VLAN.
The device assigns the authorization VLAN of the user to the port as the PVID, and it removes the port from the Auth-Fail VLAN. After the user logs off, the guest VLAN is assigned to the port as the PVID. If no guest VLAN is configured, the initial PV ID of the port is restored.
If the authentication server does not author i ze a VLAN, the initial PVID
75
assigned to the initial PVID. After the user logs off, the PVID remains
Authentication status VLAN manipulation

Guest VLAN

The 802.1X guest VLAN on a port accommodates users who have not performed 802.1X authentication. Once a user in the gues t VLAN passes 802.1X authentication, it is removed from the guest VLAN and can access authorized network resources.
The access device handles VLANs on an 802.1X-enabled port based on its 802.1X access control method.
On a port that performs port-based access control:
Authentication status VLAN manipulation
A user has not passed
802.1X authentication.
A user in the 802.1X guest VLAN fails 802.1X authentication.
A user in the 802.1X guest VLAN passes 802.1X authentication.
unchanged.
The device assigns the 802.1X guest VLAN to the port as the PVID. All
802.1X users on this port can access res ources only in the guest VLAN. If no 802.1X guest VLAN is configured, the access device does not perform
any VLAN operation. If an 802.1X Auth-Fail VLAN (see "Auth-Fail VLAN") is available, the device
assigns the Auth-Fail VLAN to the port as the PVID. All users on this port can access only resources in the Auth-Fail VLAN.
If no Auth-Fail VLAN is configured, the P V ID on the port is still the 802.1X guest VLAN. All users on the port are in th e gues t VLAN.
The device assigns the authorization VLAN of the user to the port as the PVID, and it removes the port from the 802.1X guest VLAN. After the user logs off, the initial PVID of the port is restored.
If the authentication server does not author i ze a VLAN, the initial PVID applies. The user and all subs equent 802.1X users are assigned to the initial port VLAN. After the user logs off, the port VLAN remains unchanged.
NOTE: The initial PVID of an 802.1X-enabled port refers to the PVID used by the
port before the port is assigned to any 802.1X VLANs.

Critical VLAN

The 802.1X critical VLAN on a port accommodates 802.1X users who have failed authentication because none of the RADIUS servers in their ISP domain is reachable. The critical VLAN feature takes effect when 802.1X authentication is performed only through RADIUS servers. If an 802.1X user fails local authentication after RADIUS authentication, the user is not assigned to the critical VLAN.
The access device handles VLANs on an 802.1X-enabled port based on its 802.1X access control method.
On a port that performs port-based access control:
Authentication status VLAN manipulation
A user that has not been assigned to any VLAN fails 802.1X authentication because all the RADIUS servers are
The device assigns the critical V LA N to the port as the PVID. The 802.1X user and all subsequent 802.1X users on this port can access resources only in the 802.1X critical VLAN.
76
unreachable.
Authentication status VLAN manipulation
A user in the 802.1X critical VLAN fails authentication because all the R A D IUS servers are unreachable.
A user in the 802.1X critical VLAN fails authentication for any other reasons except for unreachable servers.
A user in the 802.1X critical VLAN passes
802.1X authentication.
A user in the 802.1X guest VLAN fails authentication because all the RADIUS servers are unreachable.
A user in the 802.1X Auth-Fail VLAN fails authentication because all the RADIUS servers are unreachable.
The critical VLAN is still the PVID of the port, and all 802.1X users on this port are in this VLAN.
If an 802.1X Auth-Fail VLAN has been co nfigured, the PVID of the port changes to the Auth-Fail VLAN ID, and all 802.1X users on this port are moved to the Auth-Fail VLAN. If no 802.1X Auth-Fail VLAN is configured, the init ial PVID of the port is restored.
The device assigns the authorization VLAN of the user to the port as the PVID, and it removes the port from the
802.1X critical VLAN. After the user logs off, the guest VLAN ID changes to the PVID. If no 802.1X guest VLAN is configured, the initial PVID of the port i s restored.
If the authentication server (either the local access device or a RADIUS server) does not authorize a VLAN, the initial PVID of the port applies. The user and all subsequent
802.1X users are assigned to this port VLAN. After the user logs off, the PVID remains unchanged.
The device assigns the 802.1X critical VLAN to the port as the PVID, and all 802.1X users on this por t are in this VLAN.
The PVID of the port remains unchanged. All 802.1X users on this port can access resources only in the 802.1X Auth-Fail VLAN.
A user who has passed authenticatio n fails reauthentication because all the RADIUS servers are unreachable, and the user is logged out of the device.
The device assigns the 802.1X critical VLAN to t he por t as the PVID.

Mandatory authentication domain

You can place all 802.1X users in a mandatory authentication domain for authentication, authorization, and accounting on a port. No user can use an accou nt in any ot her domain to acces s the network through the port. The implementation of a mandatory authentication domain enhances the flexibility of 802.1X access control deploy m ent.

EAD assistant

Endpoint Admission Defense (EA D) is an integrated endp oint access contr ol solution to im prove the threat defensive capability of a network. The solution enables the security client, security policy server, a ccess device, and third-party ser ver to operate together . If a terminal device seeks to access an EAD network, it must have an EAD client, which performs 802.1X authentication.
The EAD assistant feature enables the access device to redirect a user who is se eking to access the network to download and install an EAD client. This feature eliminates the administrative task to deploy EAD clients.
77

MAC authentication

Overview

MAC authentication controls network access by authenticating source MAC addresses on a port. The feature does not require client software, and users do not have to enter usernames and passwords fo r network access. The device initiat es a MAC authentication process when it detects an unknown source MAC address on a MAC authenticat ion-enabled port.
Silent MAC address information
When a user fails MAC authentication, the device marks the user's MAC address as a silent MAC address, drops the packet, and starts a quiet timer. The device drops all subsequent packets from the silent MAC address within the quiet time. The quiet mechanism avoids repeated authentication during the quiet time.
Username format
MAC authentication supports the following username formats:
Individual MAC address—The device uses the MAC address of each user as the username and password for MAC authentication. This format is suitable for an insecure environment.
Shared username—Y ou s pecify one username and password, w hich is not necessarily a MAC address, for all MAC authentication users on the device. This format is suitable for a secure environment.
MAC authentication domain
By default, MAC authentication users ar e in the system default authentication d omain. To implement different access policies for users, you can use one of the following methods to specify authentication domains for MAC authenticat i on users:
Specify a global authentication domain. This domain setting applies to all ports enabled with MAC authentication.
Specify an authentication domain for an individual port.
MAC authentication chooses an authentication domain for users on a port in the following order: the port-specific domain, the global domain, and the defaul t domain.
Offline detect timer
This timer sets the interval that the device waits for traffi c f rom a user before the device regards the user idle. If a user connection has been idle within the interval, the device logs the user out and stops accounting for the user.
Quiet timer
This timer sets the interval that the device must wait before the device can perform MAC authentication for a user who has failed MAC authentication. All packets from the MAC address are dropped during the quiet time.
Server timeout timer
This timer sets the interval that the device waits for a response from a RADIUS server before the device regards the RADIUS server unavailable. If the timer expires during MAC authentication, the user cannot access the network.

MAC authentication configuration on a port

For MAC authentication to take eff ect on a port, you must enable this feature globally and on the port.
78
Authentication delay
When both 802.1X authentication and MAC authentication are enabled on a port, you can delay MAC authentication so that 802.1X authent i cat ion is preferentially triggered.
If no 802.1X authentication is triggered or 802.1X authentication fails within the delay period, the port continues to process MAC authentication.
Do not set the port security mode to mac-else-userlogin-secure or mac-else-userlogin-secure-ext when you use MAC authentication delay. The delay does not take effect on a port in either of the two modes.
Multi-VLAN mode
The MAC authentication multi-VLAN mode prevents an authenticated online user from service interruption caused by VLAN changes on a port. When the port receives a packet sourced from the user in a VLAN that does not match the existing MAC-VLAN mapping, the device does not logs off the user or reauthenticates the user. The device creates a new MAC-VLAN mapping for the user, and traffic transmission is not interr upte d. The origi nal MAC-VLAN m appin g for t he user remai ns on the device until it dynamically ages out.
This feature improves transmission of d at a that is vul nera ble t o del ay and int e rfe rence. It is ty pically applicable to IP phone users.
Periodic MAC reauthentication
Periodic MAC reauthentication tracks the connection status of online users, and updates the authorization attributes assigned by the RADIUS server. The attributes include the ACL, VLAN, and user profile-based QoS.
The device reauthenticates an online MAC authentic ation user periodically only after it receives the termination action Radius-request from the authentication server for this user. The Session-Timeout attribute (session timeout period) assigned by the server is the reauthentication interval. To display the server-assigned Session-Timeout and Termination-Action attributes, use the display mac-authentication connection command. Support for the server configuration and assignment of Session-Timeout and Termination-Action attributes depends on the server model.
When no server is reachable for MAC reauthentication, the device keeps the MAC authentication users online or logs off the users, de pending on the keep-online feat ure configur ation on the d evice.
Keep-online
By default, the device logs off online MAC authentication users if no server is reac hable for MAC reauthentication. The keep-online feature keeps authenticated MAC authentication users online when no server is reachable for MAC reauthentication.
In a fast-recovery network, you can use t he keep-online feature t o prevent MAC authentication use rs from frequently coming online and going offline.

Port security

Overview

Port security combines and extends 802. 1X and MAC authenticat ion t o provide MAC-based network access control. Port security provides the following functions:
Prevents unauthorized access to a netw ork by checking the s ource MAC addresses of inbound traffic.
Prevents access to unauthorized devic es or ho sts by chec king the destin ation M AC addre sses of outbound traffic.
Controls MAC address learning and authenticati on on a port to make sure the port learns only source trusted MAC addresses.
79
In this mode, port security is disabled on the port
A frame is illegal if its source MAC address cannot be learned in a port security mode or it is from a client that has failed 802.1X or MAC authentication. The port security feature automatically takes a predefined action on illegal frames. This automatic mechanism enhances network security and reduces human intervention.
Authorization-fail-offline
The authorization-fail-offline feature logs off port security users who fail ACL or user profile authorization.
A user fai l s ACL or user profile authori zation in the following situations:
The device fails to authorize the specified ACL or user profile to the user.
The server assigns a nonexistent ACL or user profile to the user.
If this feature is disabled, the device does not log off users who fail ACL or user profile authorization.
Aging timer for secure MAC addresses
When secure MAC addresses are aged out, t hey are removed from the secure MAC address table. The aging timer applies to all configured sticky secure MAC addresses and those automatically
learned by a port. To disable the aging timer, set the timer to 0.
Silence period
This period sets the duration during which a port remains disabled when the port receives illegal frames. The intrusion protection action on the port must be Disable port temporarily.
Authentication OUI
The configured OUI value takes effect only when the port authentication mode is userLoginWithOUI.
In userLoginWithOUI mode, the port allows a maximum of two users to pass through, including:
One user who passes 802.1X authentication.
One user whose MAC address matches any one of the OUIs configured on the device.

Port security settings

Port security modes
Port security supports the following categories of security modes:
MAC learning control—Includes two modes: autoLearn and secu re. MA C addre ss lear ning is permitted on a port in autoLearn mode and disabled in secure mode.
Authentication—Security modes in this category implement MAC authentication, 802.1X authentication, or a combination of these two authentication methods.
Upon receiving a frame, the port in a security mode searches the MA C addres s t able f or the source MAC address. If a match is found, the port forwards the frame. If no match is found, the port learns the MAC address or performs authentication, depending on the security mode. If the frame is illegal, the port takes the predefined NTK or intrusion protection action. Outgoing frames are not restricted by port security's NTK action unless they trigger the NTK feature.
Table 19 describes the port security modes and the security features.
Table 19 Port security modes
Purpose Security mode
Turning off the port security feature
noRestrictions (the default mode)
80
Features that can be triggered
N/A
and access to the port is not restrict ed.
Purpose Security mode
Control MAC address learning:
Perform 802.1X authentication:
Perform MAC authentication: macAddressWithRadius
Perform a combination of MAC authentication and 802.1X authentication:
autoLearn secure userLogin N/A userLoginSecure userLoginSecureExt userLoginWithOUI
Or
Else
macAddressOrUserLoginSecure macAddressOrUserLoginSecureExt macAddressElseUserLoginSecure macAddressElseUserLoginSecureE
xt
Control MAC address learning:
autoLearn.
A port in this mode can learn MAC addresses. The automatically learned MAC addresses are not added to the MAC address table as dynami c MAC address. Instead, these MAC addresses are added to th e secure MAC address table as secure MAC addresses. You ca n also manually add secure MAC addresses.
A port in autoLearn mode allows frames sourced from the following MAC addresses to pass:
Secure MAC addresses.
Manually configured static and dynamic MAC addresses.
When the number of secure MAC addresses reaches the upper limit , the port transitions to secure mode.
secure.
MAC address learning is disabled on a port in secure mode. A port in secure mode allows only frames sourced from the following MAC add resses to pass:
Secure MAC addresses.
Manually configured static and dynamic MAC addresses.
Perform 802.1X authentication:
userLogin.
A port in this mode performs 802.1X authenticati on and implements port-based access control. The port can service multiple 802.1X users. Once an 802.1X user passes authentication on the port, any subsequent 802.1X users can access the network through the port without authentication.
userLoginSecure.
A port in this mode performs 802.1X authenticati on and implements MAC-based access control. The port services only one user passing 802.1X authentication.
userLoginSecureExt.
This mode is similar to the userLoginSecure mode except that this mode supports multiple online 802.1X users.
Features that can be triggered
NTK/intrusion protection
NTK/intrusion protection
NTK/intrusion protection
NTK/intrusion protection
81
userLoginWithOUI.
This mode is similar to the userLoginSecure mode. The difference is that a port in this mode also permits frames from one user whose MAC address contains a specific OUI.
In this mode, the port performs OUI check at first. If the OUI check fails, the port performs
802.1X authentication. The port permits frame s t hat pass OUI check or 802.1X authentication.
Perform MAC authentication: macAddressWithRadius: A port in this mode performs MAC authentication, and services
multiple users.
Perform a combination of MAC authentication and 802.1X authentication:
macAddressOrUserLoginSecure.
This mode is the combination of the macAddressWith Radius and user LoginSe cure mode s. The mode allows one 802.1X aut henticat ion user and mult iple MAC aut henticatio n users to log in.
In this mode, the port performs 802.1X authentication first. If 802.1X authentication fails, MAC authentication is performed.
macAddressOrUserLoginSecureExt.
This mode is similar to the macAddressOrUserLoginSecure mode, except that this mode supports multiple 802.1X and MAC authentication users.
macAddressElseUserLoginSecure.
This mode is the combination of the macAddre ssWithRadi us and userLogi nSe cure modes, with MAC authentication having a higher priority as the Else keyword implies. The mode allows one 802.1X authentication user and m ul tiple MAC authentication users to log in.
In this mode, the port performs MAC aut hentication upon receiving non-802.1X frames. Upon receiving 802.1X frames, the port performs MAC authentication and then, if the authentication fails, 802.1X authentication.
macAddressElseUserLoginSecureExt.
This mode is similar to the macAddressElseUserLoginSecure mode except that this mode supports multiple 802.1X and MAC authentication users as the Ext keyword implies.

Port security features

Intrusion protection mode
The intrusion protection feature checks the source MAC addresses in inbound frames for illegal frames, and takes one of the following actions in response to illegal f ram es:
Block MAC—Adds the source MAC addresses of illegal frames to the blocked MAC address list and discards the frames. All subsequent frames sourced from a blocked MAC address are dropped. A blocked MAC address is restored to normal state after being blocked for 3 minutes. The interval is fixed and cannot be changed.
Disable port—Disables the port until you bring it up manually.
Disable port temporarily—Disables the port for a period of time. The silence period is user
configurable.
NTK mode
The NTK feature checks the destination MAC addresses in outbound frames to make sure frames are forwarded only to authenticated devices.
The NTK feature supports the following modes:
ntkonly—Forwards only unicast frames with authenticated destination MAC addresses.
82
ntk-withbroadcasts—Forwards only broadcast frames and unicast frames with authenticated destination MAC addresses.
ntk-withmulticasts—Forwards only broadcast frames, multicast frames, and unicast frames with authenticated destination MAC addr esses.
The NTK feature drops any unicast frame with an unknown destination MAC address.

Secure MAC addresses

Secure MAC addresses are configured or learned in autoLearn mode. Secure MAC addresses include static, sticky, and dynamic secure MAC addresses.
Aging mode for secure MAC addresses
Secure MAC addresses can be aged out when you u se one of the following aging modes:
Timeout—Secure MAC addresses age out when the aging timer expires. The aging timer counts up regardless of whether traf fic data has been sent from secure MAC addresses. By default, this mode is used.
Inactivity—Secure MAC addresses age out only when no traffic is detected during the aging interval. The device detects whet her traffic data has been sent from a secure MAC address when the aging timer expires for the secure MAC address. If traffic is detected, the aging ti m er restarts. This feature prevents the unauthorized use of a secu re MAC address when the authorized user is offline.
Dynamic secure MAC
This feature converts sticky MAC addresses to dynamic and disables saving them to the configuration file.
When this feature is enabled, you cannot manually configure sticky MAC addresses. All dynamic MAC addresses are lost at reboot. Use this feat ure when you want to clear all sticky MAC addresses after a device reboot.
When this feature is disabled, all dynami c secure MAC addr esses on the port ar e converted to sti cky MAC addresses, and you can manually configure sticky MAC addresses.
Authorization information ignore
A port can be configured to ignore the authorization information received from the server (local or remote) after an 802.1X or MAC authentication user p asses authentication.
Max users
This function specifies the maximum number of sec ure MAC addresses that port security allows on a port. The maximum number is configured for the following purposes:
Control the number of concurrent users on the port. For a port operating in a security mode (except for autoLearn and secure), the upper limit
equals the smaller of the following values:
The limit of the secure MAC addresses that port security allows. The limit of concurrent users allowed by the authentication mode in use.
Control the number of secure MAC addresse s on the port in autoLearn mode.

Portal

Portal authentication controls user access to networks. Portal authenticates a user by the username and password the user enters on a portal authentication page. Therefore, portal authentication is also known as Web authentication.
83
Portal authentication flexibly imposes a ccess control on the access layer an d vital data entries. It has the following advantages:
Allows users to perform authentication th rough a Web brows er without installing client soft ware.
Provides ISPs with diversified management choices and extended functions. For exampl e, the
ISPs can place advertisements, provide comm uni ty services, and publish information on the authentication page.
Supports multiple authentication modes . For example, re-DHCP authenticatio n i m pl em ents a flexible address assignment scheme and saves public IP addresses. Cross-subnet authentication can authenticate users who re side i n a different subnet than the access device.
A typi cal portal system consists of the following components:
Authentication client—A Web browser that runs HTTP/HTTPS or a user host that runs a portal client application.
Access device—Broadband access device such as a switch or a router.
Portal authentication server—Receives authentication req uests from authentication clients
and interacts user authentication information wit h the access device.
Portal Web server—Pushes the Web authentication page to authentication clients and forwards user authentication informatio n (username and pa ssword) to the portal aut henticatio n server.
The portal authentication server and the port al Web server are usually the same device, but they can also be separate devices.
AAA server—Interacts wi th the access device to implement authentication, authorization, accounting for portal users.

Portal authentication server

A portal authentication server receives authentication requests from authentication clients and interacts user authentication information with the access dev i ce.
Portal authentication server detection
During portal authentication, if the communication between the access device and portal authentication server is broken, both of the following occur:
New portal users are not able to log in.
The online portal users are not able to log out normally.
T o addres s this problem, the access device n eeds to be able to detect the rea chability changes of the portal server quickly and take corresponding actions to deal with the changes.
With the detection feature enabled, the device periodically detects portal login, logout, or heartbeat packets sent by a portal authentication server to determine the reachabi lity of the server . If the device receives a portal packet within a detection timeout and the portal packet is valid, the device determines the portal authentication server to be reachable. Otherwise, the device determines the portal authentication server to be unreachable.
You can configure the device to take one or more of the following actions when the server reachability status changes:
Sending a trap message to the NMS. The t rap message contains t he name and cur rent state of the portal authentication server.
Sending a log message, which contains the name, the curre nt state, and the original state of the portal authentication server.
Portal user synchronization
Once the access device loses communication with a portal authentication server, the portal user information on the access device and the server might be inconsistent after the communication
84
resumes. To address this problem, the device provides the portal user synchronizatio n feature. This feature is implemented by sending and detecting portal synchronization packets, as follows:
1. The portal authentication server sends the onl i ne user information to the access device in a synchronization packet at the user heartbeat interval.
The user heartbeat interval is set on the portal aut hentication server.
2. Upon receiving the synchronization packet, the access device compares the users carried in the packet with its own user list and performs t he following operations:
If a user contained in the packet does not exist on the access device, the access device
informs the portal authentication server to delete the user.
If the user does not appear in any synchronization packet within a synchronization detection
interval, the access device determines the user does not exist on the server and logs the user out.

Portal Web server

A portal W eb server pushes the W eb authenticat ion page to authentication clie nts and forwards user authentication information (username and password) to the portal authentication server.
The portal authentication server and the portal Web se rver are usually the sam e device, but they can also be separate devices.
Redirection URL parameters
This feature configure the parameters to be carried in the redirection URL. Commonly required parameters include the user IP addr ess, user MAC address, and the URL that the user originally visits.
After you configure the URL parameters, the access device sends the portal Web server URL with these parameters to portal users. Assume that the URL of a portal Web server is http://www.test.com/portal, the originally visited URL of the user whose IP address 1.1.1.1 is http://www/abc.com/welcome, and you configure the user IP address and original URL parameters. Then, the access device sends to the user whose IP address is 1.1.1.1 the URL http://www.test.com/portal?userip=1.1.1.1&userurl=http://www.abc.com/welcome.
Portal Web server detection
A portal authentication process cannot complete if the communication between the access device and the portal Web server is broken. To address this problem, you can enable portal Web server detection on the access device.
With the portal Web server detection fea ture, t he access dev ice sim ulat es a Web access process to initiate a TCP connection to the portal Web server. If the TCP connection can be established successfully, the access device considers the detection successful, and the portal Web server is reachable. Otherwise, it considers the detection to have failed. Portal authentication status on interfaces of the access device does not affect the portal Web server detection feature.
You can configure the following detection parameters:
Detection interval—Interval at which the device dete ct s t he server reachability.
Maximum number of consecutive failures—If the number of consecutive detection failures
reaches this value, the access device considers that the portal Web serv er is unreachable.
You can configure the device to take one or more of the following actions when the server reachability status changes:
Sending a trap message to the NMS. The t rap message contain s the name and current state of the portal Web server.
Sending a log message, which contains the name, the curre nt state, and the original state of the portal Web server.
85

Local portal Web server

Using this feature, the access device also acts as t he portal Web serv er and the portal authentication server to perform local portal authentication on portal users. In this case, the portal system consist s of only three components: authentication client, access device, and AAA server .
Client and local portal Web server interaction protocols
HTTP and HTTPS can be used for interaction between an authentication client and a local portal Web server. If HTTP is used, there are potential security problems because HTTP packets are transferred in plain text. If HTTPS is used, secure data transmission is ensured because HTTP packets are secured by SSL.
Portal page customization
To perform l ocal portal authentication, you must customize a set of authentication pages that the device will push to users. You can customize multiple sets of authentication pages, compress each set of the pages to a .zip file, and upload the compressed files to the storage medium of the device. On the device, you must specify one of the fil es as t he default authentication page file.
Authentication pages are HTML files. Local portal authentication requires the following authentication pages:
Logon page
Logon success page
Logon failure page
Online page
System busy page
Logoff success page
You must customize the authentication pages, including the page elements that the authentication pages will use, for example, back.jpg for authentication page Logon.htm.
Follow the authentication page customiz ation rules when you edit the authentication page files.
File name rules
The names of the main authentication page fi les a re fixed (see Table 20). You can define the names of the files other than the main authentication page files. File names and directory names are case insensitive.
Table 20 Main authentication page file names
Main authentication page File name
Logon page logon.htm Logon success page logonSuccess.htm Logon failure page logonFail.htm Online page
Pushed after the user gets online for online notification System busy page
Pushed when the system is busy or the user is in the logon process Logoff success page logoffSuccess.htm
online.htm
busy.htm
Page request rules
The local portal Web server supports only Get and Post requests.
86
Get requests—Used to get the static files in the authent icat i on pages and allow no recursion. For example, if file Logon.htm includes contents that perfo rm G et action on file ca.htm, file ca.htm cannot include any reference to file Logon.htm.
Post requests—Used when users submit username and password pairs, log in, and log out.
Post request attribute rules
1. Observe the following requirements whe n edi ting a form of an authentication page:
An authentication page can have multiple forms, but there must be one and only one form
whose action is logon.cgi. Otherwise, user information cann ot be sent to the local portal Web server.
The username attribute is fixed as PtUser. The password attribute is fixed as PtPwd. The value of the PtButton attribute is either Logon or Logoff, which indicates the action
that the user requests.
A logon Post request must contain PtUser, PtPwd, and PtButton attributes. A logoff Post request must contain t he PtButton attribute.
2. Authentication pages logon.htm and logonFail.htm m ust contain the logon Post request. The following example shows part of the script in page logon.htm.
<form action=logon.cgi method = post > <p>User name:<input type="text" name = "PtUser" style="width:160px;height:22px"
maxlength=64> <p>Password :<input type="password" name = "PtPwd" style="width:160px;height:22px"
maxlength=32> <p><input type=SUBMIT value="Logon" name = "PtButton" style="width:60px;"
onclick="form.action=form.action+location.search;"> </form>
3. Authentication pages logonSuccess.htm and online.htm must contain the logoff Post request.
The following example shows part of the script in page online.htm.
<form action=logon.cgi method = post > <p><input type=SUBMIT value="Logoff" name="PtButton" style="width:60px;"> </form>
Page file compression and saving rules
You must compress the authentication pages and their page elements into a standard zip file.
The name of a zip file can contain only letters, numbers, and underscores.
The authentication pages must be placed in the root directory of the zip file.
Zip files can be transferred to the device through FTP or TFTP and must be saved in the root
directory of the device. Examples of zip files on the device:
<Sysname> dir Directory of flash: 0 -rw- 1405 Feb 28 2008 15:53:31 ssid2.zip 1 -rw- 1405 Feb 28 2008 15:53:20 ssid1.zip 2 -rw- 1405 Feb 28 2008 15:53:39 ssid3.zip 3 -rw- 1405 Feb 28 2008 15:53:44 ssid4.zip 2540 KB total (1319 KB free)
Redirecting authenticated users to a specific webpage
To make the device automatically redirect authenticated users to a specific webpage, do the following in logon.htm and logonSuccess.htm :
87
1. In logon.htm, set the target attribute of Form to _blank. See the contents in gray:
<form method=post action=logon.cgi target="_blank">
2. Add the function for page loading pt_init() t o l ogonSucceess.htm. See the contents in gray:
<html> <head> <title>LogonSuccessed</title> <script type="text/javascript" language="javascript"
src="pt_private.js"></script> </head> <body onload="pt_init();" onbeforeunload="return pt_unload();">
... ...
</body> </html>

Portal-free rules

A portal-free rule allows specified users to access specified external websites without portal authentication.
IP-based portal-free rules The matching items for an IP-based portal-free rule include the IP address and TCP/UDP port.
Source-based portal-free rules The matching items for an IP-based portal-free rule i nclude source MAC address, acces s
interface, and VLAN.
Packets matching a portal-free rule will not trigger portal authentication, so users sending the packets can directly access the specified external websites.

Interface policy

An interface policy is a set of portal features co nfigured on an interface.
Portal fail-permit feature
This feature allows users on an interf ace to hav e network access wi thout port al authenti cation when the access device detects that the portal aut hentication server or portal Web server is unreachable.
If you enable fail-permit for both a portal authentication server and a portal Web server on an interface, the interface performs the followi ng operations:
Disables portal authentication when either server is unreachable.
Resumes portal authentication when both servers are reachable.
After portal authentication resumes, unauthenticated users must pass portal authentication to access the network. Users who have passed portal authentication before the fail-permit event can continue accessing the network.
BAS-IP attribute
This feature allows you to configure the B AS-IP or BAS-IPv6 attribute on a portal-enabled interface. The device uses the configured BAS-IP or BAS-IPv6 address as the source IP address of the portal notifications sent from the interface to the portal authentication server.
88
If you do not configure this feature, the BAS-IP/BAS-IPv6 attribute of a portal notification packet sent to the portal authentication server is the IPv4/IPv6 address of the packet output interface. The BAS-IP/BAS-IPv6 attribute of a portal reply packet is the source I P v4/IPv6 address of the packet.
User detection
This feature implements quick detection of abnormal logouts of portal users. It supports ARP or ICMP detection for IPv4 portal us ers and ND or ICMPv6 detection for I P v6 portal users.
ARP and ND detections apply only to direct and re-DHCP portal authentication. ICMP detection applies to all portal authentication modes.
If the device receives no packets from a portal user wi thin the idle time, t he device detects the user's online status as follows:
ICMP or ICMPv6 detection—Sends ICMP or ICMPv6 requests to the user at configurable intervals to detect the user status.
If the device receives a reply within the maximum number of detection attempts, it
If the device receives no reply after the maximum number of detection attempt s, the devi ce
ARP or ND detection—S ends ARP or ND requests to the use r and detects the ARP or ND entry status of the user at configurable int erv al s.
If the ARP or ND entry of the user is refreshed within the m aximum number of detection
If the ARP or ND entry of the user is not refreshed after the maximum number of detection attempts, the device logs out the user.
determines that the user is online and stops sending detection packets. Then, the device resets the idle timer and repeats the detection pr ocess when the timer expires.
logs out the user.
attempts, the device considers that the user is onli ne and stops the detection. Then the device resets the idle timer and repeats the detection process when the timer expires.

ISP domains

The device manages users based on ISP domains. An ISP domain includes authentication, authorization, and accounting methods f or users. The device determines the ISP domai n and access type of a user. It also uses the methods configured for the access type in the domain to control the user's access.
The device supports the following authenticat ion methods:
No authentication—This method trusts all users and does not perform authentication. For security purposes, do not use this method.
Local authentication—The device authenticates users by itself, based on the locally configured user information including the usernames, passwords, and attributes. Local authentication allows high speed and low cost, but the amount of information that can be stored is limited by the size of the storage space.
Remote authentication—The device works with a remote RADIUS server or TACACS server to authenticate users. The server man ages user information in a centralized manner. Remote authentication provides high capacity, reliable, and centralized authentication services for multiple devices. You can configure backup methods to be used when the remote server is not available.
The device supports the following authorization methods:
No authorization—The device performs no aut horization exchange. The following default authorization information applies after u sers pass authentication:
Non-login users can access the network. FTP, SFTP, and SCP users have the root directory of the device set as the working directory.
However, the users do not have permission to access the root directory.
89
Other login users obtain the default user role.
Local authorization—The device performs authorization accordi ng to the user attributes locally configured for users.
Remote authorization—The device works with a remote RADIUS server or TA CACS server to authorize users. RADIUS authorization is bound with RADIUS auth entication. RADIUS authorization can work only after RADIUS aut hentication is successful, and the authorization information is included in the Access-Accept packet. TACACS authorization is separate from TACACS authentication, and the authorization information is included in the authorization response after successful authentication. You can configure backup methods to be used when the remote server is not available.
The device supports the following accounting methods:
No accounting—The device does not perform accounting for the users.
Local accounting—Local accounting is implemented on the device. It counts and controls the
number of concurrent users who use the same local user account, but does not provide statistics for charging.
Remote accounting—The device works with a remote RADIUS server or TACACS server for accounting. You can configure backup methods to be used when the remote server is not available.
On the device, each user belongs to one ISP domain. The device determines the ISP domain to which a user belongs based on the username ente red by the user at login.
AAA manage s users in the same ISP domain based on the users' access types. The device supports the following user access types:
LAN—LAN users must pass 802.1X authentication t o come online.
Login—Login users include Telnet, FTP, and terminal users who log in to the device. Terminal
users can access through a console or AUX port.
Portal—Portal users.
In a networking scenario with multiple ISPs, the device can connect to users of different ISPs. The device supports multiple ISP domains, in cluding a system-d efined ISP dom ain named system. One of the ISP domains is the default domain. If a user does not provide an ISP domain name for authentication, the device considers the user belongs to the default ISP domain.
The device chooses an authentication domain f or each user in the following order:
The authentication domain specified for the access module (for example, 802.1X).
The ISP domain in the username.
The default ISP domain of the devi ce.

RADIUS

RADIUS protocol

Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction protocol that uses a client/server model. The protocol can protect networks against unauthorized access and is often used in network environments that require both high security and remote user access.
The RADIUS client runs on the NASs located throughout the network. It passes user information to RADIUS servers and acts on the responses t o, for example, reject or accept user access requests.
The RADIUS server runs on the computer or workstation at the network center and maintains information related to user authentication and network service access.
90
RADIUS uses UDP to transmit packets. The RADIUS client and server exchange information with the help of shared keys.
When AAA is implemented by a remote RADIUS server, configure the RADIUS server settings on the device that acts as the NAS for the users.

Enhanced RADIUS features

The device supports the following enhanced RA DI US features:
Accounting-on—This feature enables the device to automatically sen d an accounting-on packet to the RADIUS server after a reboot. Upon receiving the accounting-on packet, the RADIUS server logs out all online users so they can log in again through the device. Without this feature, users cannot log in again after the reboot , because the RADIUS server considers them to be online.
You can configure the interval for which the devi ce waits to resend the accounting-on packet and the maximum number of retries.
The RADIUS server must run on IMC to correctly log out users when a card reboot s on the distributed device to which the users connect.
Session-control—A RADIUS server running on IMC can use s ession-control packets to inform disconnect or dynamic authorization change requ est s. Enable se ssion-cont rol on t he device to receive RADIUS session-control packets on UDP port 1812.
91

Log features

Log levels

Logs are classified into eight severity levels from 0 through 7 in descending order.
Table 21 Log levels
Severit y value
0 Emergency The system is unusable. For example, the system authorization has expired.
1 Alert
2 Critical
3 Error
4 Warning
5 Notification
6 Informational
7 Debugging Debug message.
Level Description

Log destinations

The system outputs logs to destinations su ch as the lo g buffer and log host. Log output destinations are independent and you can configure them in the Web interface.
Action must be taken immediately. For example, traffic on an interface exceeds the upper limit.
Critical condition. For example, the device temperature exceeds the upper limit, the power module fails, or the fan tray fails.
Error condition. For example, the link stat e changes or a storage card is unplugged.
Warning condition. For example, an inter face is disconnected, or the memory resources are used up.
Normal but significant condition. For example, a terminal logs in to the device, or the device reboots.
Informational message. For exampl e, a command or a ping operation is executed.
92
Loading...