HPE FlexNetwork 5520 HI Switch Series

Security Configuration Guide

Part number: 5200-8308

Software version: Release 6525 and later
Document version: 6W100-20210810
© Copyright 2021 Hewlett Packard Enterprise Development LP
The information contained herein is subject to change without notice. The only warranties for Hewlett Packard
Enterprise products and services are set forth in the express warranty statements accompanying such
products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett
Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein.
Confidential computer software. Valid license from Hewlett Packard Enterprise required for possession, use, or
copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software
Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s
standard commercial license.
Links to third-party websites take you outside 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 Inside®, and the Intel Inside logo are trademarks of Intel Corporation in the
United States and other countries.
Microsoft® and Windows® are either registered trademarks or trademarks of Microsoft Corporation in the
United States and/or other countries.
Adobe® and Acrobat® are trademarks of Adobe Systems Incorporated.
Java and Oracle are registered trademarks of Oracle and/or its affiliates.
UNIX® is a registered trademark of The Open Group.
Contents
Configuring AAA ···························································································· 1
About AAA·························································································································································· 1
AAA implementation··································································································································· 1
AAA network diagram ································································································································ 1
RADIUS······················································································································································ 2
HWTACACS··············································································································································· 5
LDAP ·························································································································································· 8
User management based on ISP domains and user access types·························································· 11
Authentication, authorization, and accounting methods··········································································· 11
AAA extended functions ··························································································································· 12
AAA for VPNs··········································································································································· 13
RADIUS server feature of the device ······································································································· 13
Protocols and standards ·························································································································· 14
FIPS compliance ·············································································································································· 15
AAA tasks at a glance ······································································································································ 15
Configuring local users····································································································································· 16
About local users······································································································································ 16
Local user configuration tasks at a glance ······························································································· 16
Configuring attributes for device management users··············································································· 17
Configuring attributes for network access users ······················································································ 18
Configuring user group attributes ············································································································· 20
Configuring the local user auto-delete feature ························································································· 21
Display and maintenance commands for local users and local user groups ··········································· 21
Configuring RADIUS ········································································································································ 21
RADIUS tasks at a glance························································································································ 21
Restrictions and guidelines for RADIUS configuration ············································································· 22
Configuring an EAP profile ······················································································································· 22
Configuring a test profile for RADIUS server status detection ································································· 23
Creating a RADIUS scheme ···················································································································· 24
Specifying RADIUS authentication servers ······························································································ 24
Specifying the RADIUS accounting servers ····························································································· 25
Specifying the shared keys for secure RADIUS communication ····························································· 26
Specifying the MPLS L3VPN instance for a RADIUS scheme································································· 26
Setting the status of RADIUS servers ······································································································ 27
Setting RADIUS timers····························································································································· 28
Specifying the source IP address for outgoing RADIUS packets····························································· 29
Setting the username format and traffic statistics units············································································ 30
Setting the maximum number of RADIUS request transmission attempts··············································· 31
Setting the maximum number of real-time accounting attempts ······························································ 31
Setting the DSCP priority for RADIUS packets ························································································ 32
Configuring the Login-Service attribute check method for SSH, FTP, and terminal users ······················ 32
Interpreting the RADIUS class attribute as CAR parameters··································································· 33
Configuring the format of the RADIUS Called-Station-Id attribute ··························································· 33
Configuring the MAC address format for the RADIUS Called-Station-Id attribute ··································· 34
Configuring the MAC address format for the RADIUS Calling-Station-Id attribute ·································· 34
Setting the data measurement unit for the Remanent_Volume attribute ················································· 35
Including subattribute 218 of vendor 25506 in outgoing RADIUS packets ·············································· 35
Configuring the RADIUS attribute translation feature ·············································································· 36
Configuring RADIUS stop-accounting packet buffering ··········································································· 37
Enabling forcibly sending stop-accounting packets ················································································· 38
Enabling the RADIUS server load sharing feature ··················································································· 38
Specifying a RADIUS server selection mode for reauthentication ··························································· 39
Configuring the RADIUS accounting-on feature ······················································································ 39
Configuring the RADIUS session-control feature ····················································································· 40
Configuring the RADIUS DAS feature······································································································ 41
Enabling SNMP notifications for RADIUS ································································································ 41
Disabling the RADIUS service ················································································································· 42

i
 Display and maintenance commands for RADIUS ·················································································· 43
Configuring HWTACACS ································································································································· 43
HWTACACS tasks at a glance················································································································· 43
Creating an HWTACACS scheme ··········································································································· 44
Specifying the HWTACACS authentication servers ················································································· 44
Specifying the HWTACACS authorization servers ··················································································· 45
Specifying the HWTACACS accounting servers ······················································································ 45
Specifying the shared keys for secure HWTACACS communication ······················································ 46
Specifying an MPLS L3VPN instance for the scheme ············································································· 47
Setting HWTACACS timers······················································································································ 47
Specifying the source IP address for outgoing HWTACACS packets······················································ 48
Setting the username format and traffic statistics units············································································ 49
Configuring HWTACACS stop-accounting packet buffering ···································································· 50
Display and maintenance commands for HWTACACS ··········································································· 50
Configuring LDAP ············································································································································ 51
LDAP tasks at a glance ···························································································································· 51
Creating an LDAP server ························································································································· 51
Configuring the IP address of the LDAP server ······················································································· 51
Specifying the LDAP version···················································································································· 52
Setting the LDAP server timeout period ··································································································· 52
Configuring administrator attributes ········································································································· 52
Configuring LDAP user attributes············································································································· 53
Configuring an LDAP attribute map ········································································································· 54
Creating an LDAP scheme······················································································································· 54
Specifying the LDAP authentication server ······························································································ 55
Specifying the LDAP authorization server································································································ 55
Specifying an LDAP attribute map for LDAP authorization ······································································ 55
Display and maintenance commands for LDAP······················································································· 55
Creating an ISP domain ··································································································································· 56
About ISP domains ·································································································································· 56
Restrictions and guidelines for ISP domain configuration ········································································ 56
Creating an ISP domain ··························································································································· 56
Specifying the default ISP domain ··········································································································· 57
Specifying an ISP domain for users that are assigned to nonexistent domains ······································ 57
Configuring ISP domain attributes ··················································································································· 57
Setting ISP domain status ························································································································ 57
Configuring authorization attributes for an ISP domain············································································ 57
Including the idle timeout period in the user online duration to be sent to the server ······························ 58
Configuring AAA methods for an ISP domain ·································································································· 59
Configuring authentication methods for an ISP domain ··········································································· 59
Configuring authorization methods for an ISP domain············································································· 60
Configuring accounting methods for an ISP domain ················································································ 61
Display and maintenance commands for ISP domains············································································ 62
Setting the maximum number of concurrent login users ·················································································· 62
Configuring a NAS-ID······································································································································· 63
Configuring the device ID ································································································································· 63
Enabling password change prompt logging ····································································································· 64
Configuring the RADIUS server feature ··········································································································· 64
RADIUS server feature tasks at a glance ································································································ 64
Restrictions and guidelines for the RADIUS server feature ····································································· 65
Configuring RADIUS users ······················································································································ 65
Specifying RADIUS clients ······················································································································· 65
Activating the RADIUS server configuration ···························································································· 65
Display and maintenance commands for RADIUS users and clients ······················································ 66
Configuring the connection recording policy ···································································································· 66
About the connection recording policy ····································································································· 66
Restrictions and guidelines ······················································································································ 66
Procedure················································································································································· 66
Display and maintenance commands for the connection recording policy ·············································· 66
Configuring the AAA test feature······················································································································ 67
AAA configuration examples ···························································································································· 69
Example: Configuring AAA for SSH users by an HWTACACS server ····················································· 69

ii
 Example: Configuring local authentication, HWTACACS authorization, and RADIUS accounting for SSH
users ························································································································································ 71
Example: Configuring authentication and authorization for SSH users by a RADIUS server ·················· 73
Example: Configuring authentication for SSH users by an LDAP server ················································· 76
Example: Configuring AAA for 802.1X users by a RADIUS server ·························································· 79
Example: Configuring authentication and authorization for 802.1X users by the device as a RADIUS server
································································································································································· 86
Troubleshooting AAA ······································································································································· 88
RADIUS authentication failure ················································································································· 88
RADIUS packet delivery failure ················································································································ 88
RADIUS accounting error························································································································· 89
Troubleshooting HWTACACS ·················································································································· 89
LDAP authentication failure······················································································································ 89
Appendixes ······················································································································································ 90
Appendix A Commonly used RADIUS attributes ····················································································· 90
Appendix B Descriptions for commonly used standard RADIUS attributes ············································· 92
Appendix C RADIUS subattributes (vendor ID 25506) ············································································ 94
Appendix D Format of dynamic authorization ACLs ················································································ 97
802.1X overview ·························································································· 99
About the 802.1X protocol ······························································································································· 99
802.1X architecture ·································································································································· 99
Controlled/uncontrolled port and port authorization status······································································· 99
Packet exchange methods ····················································································································· 100
Packet formats ······································································································································· 101
802.1X authentication procedures ········································································································· 103
802.1X authentication initiation ·············································································································· 105
Access control methods ································································································································· 106
802.1X VLAN manipulation ···························································································································· 106
Authorization VLAN ································································································································ 106
Guest VLAN ··········································································································································· 109
Auth-Fail VLAN ······································································································································ 110
Critical VLAN ·········································································································································· 111
Critical voice VLAN ································································································································ 113
802.1X VSI manipulation································································································································ 113
802.1X support for VXLANs ··················································································································· 113
Authorization VSI ··································································································································· 114
Guest VSI ··············································································································································· 114
Auth-Fail VSI ·········································································································································· 115
Critical VSI ············································································································································· 115
ACL assignment ············································································································································· 116
User profile assignment ································································································································· 117
Redirect URL assignment ······························································································································ 117
CAR attribute assignment ······························································································································ 118
Periodic 802.1X reauthentication ··················································································································· 118
EAD assistant················································································································································· 119
Configuring 802.1X ···················································································· 120
Restrictions and guidelines: 802.1X configuration ························································································· 120
802.1X tasks at a glance ································································································································ 120
Prerequisites for 802.1X································································································································· 121
Enabling 802.1X ············································································································································· 122
Enabling EAP relay or EAP termination ········································································································· 122
Setting the port authorization state ················································································································ 123
Specifying an access control method············································································································· 123
Specifying a mandatory authentication domain on a port ·············································································· 124
Setting the 802.1X authentication timeout timers ·························································································· 124
Configuring 802.1X reauthentication ·············································································································· 125
Setting the quiet timer ···································································································································· 126
Configuring an 802.1X guest VLAN ··············································································································· 126
Enabling 802.1X guest VLAN assignment delay···························································································· 127
Configuring an 802.1X Auth-Fail VLAN·········································································································· 128

iii
 Configuring an 802.1X critical VLAN ·············································································································· 129
Enabling the 802.1X critical voice VLAN feature ··························································································· 130
Configuring an 802.1X guest VSI ··················································································································· 130
Enabling 802.1X guest VSI assignment delay ······························································································· 131
Configuring an 802.1X Auth-Fail VSI ············································································································· 131
Configuring an 802.1X critical VSI ················································································································· 132
Configuring 802.1X unauthenticated user aging ···························································································· 132
Sending EAP-Success packets on assignment of users to the 802.1X Auth-Fail VLAN or VSI ···················· 133
Sending EAP-Success packets on assignment of users to the 802.1X critical VLAN or VSI ························ 134
Enabling 802.1X online user synchronization ································································································ 134
Configuring the authentication trigger feature ································································································ 135
Setting the maximum number of concurrent 802.1X users on a port ····························································· 136
Setting the maximum number of authentication request attempts ································································· 136
Discarding duplicate 802.1X EAPOL-Start requests ······················································································ 136
Configuring online user handshake················································································································ 137
Specifying supported domain name delimiters ······························································································ 138
Removing the VLAN tags of 802.1X protocol packets sent out of a port ······················································· 139
Setting the maximum number of 802.1X authentication attempts for MAC authenticated users ··················· 139
Enabling 802.1X user IP freezing··················································································································· 140
Enabling generation of dynamic IPSG binding entries for 802.1X authenticated users ································· 140
Configuring 802.1X MAC address binding ····································································································· 141
Configuring the EAD assistant feature ··········································································································· 142
Setting the maximum size of EAP-TLS fragments sent to the server ···························································· 143
Logging off 802.1X users ······························································································································· 143
Enabling 802.1X user logging ························································································································ 144
Display and maintenance commands for 802.1X ·························································································· 144
802.1X authentication configuration examples ······························································································ 145
Example: Configuring basic 802.1X authentication················································································ 145
Example: Configuring 802.1X guest VLAN and authorization VLAN ····················································· 147
Example: Configuring 802.1X with ACL assignment·············································································· 149
Example: Configuring 802.1X guest VSI and authorization VSI ···························································· 151
Example: Configuring 802.1X with EAD assistant (with DHCP relay agent) ·········································· 153
Example: Configuring 802.1X with EAD assistant (with DHCP server) ················································· 156
Troubleshooting 802.1X ································································································································· 158
EAD assistant URL redirection failure ···································································································· 158
Configuring MAC authentication ································································ 159
About MAC authentication ····························································································································· 159
User account policies ····························································································································· 159
Authentication methods·························································································································· 160
VLAN assignment ·································································································································· 161
VSI manipulation ···································································································································· 165
ACL assignment ····································································································································· 167
User profile assignment ························································································································· 168
Redirect URL assignment ······················································································································ 169
CAR attribute assignment ······················································································································ 169
Blackhole MAC attribute assignment ····································································································· 169
Periodic MAC reauthentication··············································································································· 169
RESTful server-assisted MAC authentication user recovery ································································· 170
Restrictions and guidelines: MAC authentication configuration ····································································· 171
MAC authentication tasks at a glance ············································································································ 171
Prerequisites for MAC authentication············································································································· 172
Enabling MAC authentication ························································································································· 172
Specifying a MAC authentication method ······································································································ 173
Specifying a MAC authentication domain ······································································································ 173
Configuring user account policy ····················································································································· 174
Configuring MAC authentication timers·········································································································· 175
Configuring periodic MAC reauthentication···································································································· 176
Configuring a MAC authentication guest VLAN ····························································································· 177
Specifying a MAC authentication guest VLAN on a port ········································································ 177
Enabling guest VLAN reauthentication in MAC authentication ······························································ 177
Configuring a MAC authentication critical VLAN ···························································································· 178

iv
 Enabling the MAC authentication critical voice VLAN feature········································································ 179
Configuring a MAC authentication guest VSI ································································································· 180
Specifying a MAC authentication guest VSI on a port ··········································································· 180
Enabling guest VSI reauthentication in MAC authentication ·································································· 180
Configuring a MAC authentication critical VSI ······························································································· 181
Configuring unauthenticated MAC authentication user aging ········································································ 182
Configuring MAC authentication offline detection ·························································································· 182
Enabling online user synchronization for MAC authentication ······································································· 183
Setting the maximum number of concurrent MAC authentication users on a port ········································· 184
Enabling MAC authentication multi-VLAN mode on a port ············································································ 185
Configuring MAC authentication delay ··········································································································· 185
Including user IP addresses in MAC authentication requests ········································································ 186
Enabling parallel MAC authentication and 802.1X authentication ································································· 187
Configuring RESTful server-assisted MAC authentication user recovery ······················································ 188
Configuring Web proxy ports for URL redirection in MAC authentication ······················································ 189
Logging off MAC authentication users ··········································································································· 190
Enabling MAC authentication user logging ···································································································· 190
Display and maintenance commands for MAC authentication ······································································ 191
MAC authentication configuration examples ·································································································· 192
Example: Configuring local MAC authentication ···················································································· 192
Example: Configuring RADIUS-based MAC authentication ··································································· 194
Example: Configuring ACL assignment for MAC authentication ···························································· 196
Example: Configuring MAC authentication authorization VSI assignment············································· 199
Configuring portal authentication ······························································· 203
About portal authentication ···························································································································· 203
Advantages of portal authentication ······································································································· 203
Extended portal functions······················································································································· 203
Portal system ········································································································································· 203
Portal authentication using a remote portal server················································································· 204
Local portal service ································································································································ 205
Portal authentication modes··················································································································· 205
Portal authentication process ················································································································· 206
Portal support for EAP ··························································································································· 208
Portal filtering rules ································································································································ 208
Restrictions and guidelines: Portal configuration ··························································································· 209
Portal authentication tasks at a glance ·········································································································· 209
Prerequisites for portal authentication ··········································································································· 210
Configuring a remote portal authentication server ························································································· 211
Configuring a portal Web server ···················································································································· 212
Portal Web server tasks at a glance ······································································································ 212
Configure basic parameters for a portal Web server ············································································· 212
Enabling the captive-bypass feature ······································································································ 212
Configuring a match rule for URL redirection ························································································· 213
Configuring local portal service features ········································································································ 213
About the local portal service ················································································································· 213
Restrictions and guidelines for configuring local portal service features················································ 213
Customizing authentication pages ········································································································· 214
Configuring a local portal Web service··································································································· 216
Enabling portal authentication on an interface ······························································································· 216
Specifying a portal Web server on an interface ····························································································· 217
Enabling portal to support IPv4/IPv6 dual stack ···························································································· 217
Specifying a preauthentication IP address pool ····························································································· 218
Specifying a portal authentication domain ····································································································· 219
About portal authentication domains ······································································································ 219
Restrictions and guidelines for specifying a portal authentication domain ············································· 219
Specifying a portal authentication domain on an interface····································································· 220
Controlling portal user access ························································································································ 220
Configuring a portal-free rule ················································································································· 220
Configuring an authentication source subnet ························································································· 221
Configuring an authentication destination subnet ·················································································· 222
Configuring support of Web proxy for portal authentication ··································································· 222

v
 Checking the issuing of category-2 portal filtering rules········································································· 223
Setting the maximum number of portal users ························································································ 223
Enabling strict-checking on portal authorization information ·································································· 224
Allowing only users with DHCP-assigned IP addresses to pass portal authentication ·························· 225
Enabling portal roaming ························································································································· 225
Configuring the portal fail-permit feature ································································································ 226
Configuring portal detection features ············································································································· 226
Configuring online detection of portal users ··························································································· 226
Configuring portal authentication server detection ················································································· 227
Configuring portal Web server detection ································································································ 228
Configuring portal user synchronization ································································································· 229
Configuring portal packet attributes ··············································································································· 230
Configuring the BAS-IP or BAS-IPv6 attribute ······················································································· 230
Specifying the device ID························································································································· 230
Configuring attributes for RADIUS packets ···································································································· 231
Specifying a format for the NAS-Port-Id attribute ··················································································· 231
Configuring the NAS-Port-Type attribute ······························································································· 231
Applying a NAS-ID profile to an interface······························································································· 232
Logging out online portal users ······················································································································ 232
Enabling portal user login/logout logging ······································································································· 233
Disabling the Rule ARP or ND entry feature for portal clients ······································································· 233
Configuring Web redirect ······························································································································· 234
Display and maintenance commands for portal ····························································································· 234
Portal configuration examples ························································································································ 235
Example: Configuring direct portal authentication·················································································· 235
Example: Configuring re-DHCP portal authentication ············································································ 241
Example: Configuring cross-subnet portal authentication ······································································ 244
Example: Configuring extended direct portal authentication ·································································· 248
Example: Configuring extended re-DHCP portal authentication ···························································· 251
Example: Configuring extended cross-subnet portal authentication ······················································ 255
Example: Configuring portal server detection and portal user synchronization ····································· 259
Example: Configuring direct portal authentication using a local portal Web service ······························ 264
Troubleshooting portal ··································································································································· 267
No portal authentication page is pushed for users ················································································· 267
Cannot log out portal users on the access device ················································································· 267
Cannot log out portal users on the RADIUS server ··············································································· 268
Users logged out by the access device still exist on the portal authentication server···························· 268
Re-DHCP portal authenticated users cannot log in successfully ··························································· 269
Configuring Web authentication ································································· 270
About Web authentication ······························································································································ 270
Advantages of Web authentication ········································································································ 270
Web authentication system ···················································································································· 270
Web authentication process ··················································································································· 271
Web authentication support for VLAN assignment ················································································ 271
Web authentication support for authorization ACLs ··············································································· 272
Restrictions and guidelines: Web authentication configuration ······································································ 272
Web authentication task at a glance ·············································································································· 273
Prerequisites for Web authentication ············································································································· 273
Configuring a Web authentication server ······································································································· 274
Configuring a local portal service ··················································································································· 274
Enabling Web authentication ························································································································· 274
Specifying a Web authentication domain ······································································································· 275
Setting the redirection wait time ····················································································································· 275
Configuring a Web authentication-free subnet ······························································································· 276
Setting the maximum number of Web authentication users ·········································································· 276
Configuring online Web authentication user detection ··················································································· 276
Configuring an Auth-Fail VLAN ······················································································································ 277
Configuring Web authentication to support Web proxy ·················································································· 277
Display and maintenance commands for Web authentication ······································································· 278
Web authentication configuration examples ·································································································· 278
Example: Configuring Web authentication by using the local authentication method ···························· 278

vi
 Example: Configuring Web authentication by using the RADIUS authentication method······················ 280
Troubleshooting Web authentication ············································································································· 282
Failure to come online (local authentication interface using the default ISP domain ····························· 282
Configuring triple authentication ································································ 283
About triple authentication ····························································································································· 283
Typical network of triple authentication ·································································································· 283
Triple authentication mechanism ··········································································································· 283
Triple authentication support for VLAN assignment ··············································································· 284
Triple authentication support for ACL authorization ··············································································· 284
Triple authentication support for online user detection ·········································································· 285
Restrictions and guidelines: Triple authentication ·························································································· 285
Triple authentication tasks at a glance ··········································································································· 285
Triple authentication configuration examples ································································································· 285
Example: Configuring basic triple authentication ··················································································· 285
Example: Configuring triple authentication to support authorization VLAN and authentication failure VLAN
······························································································································································· 289
Configuring port security ············································································ 295
About port security ········································································································································· 295
Major functions ······································································································································· 295
Port security features ····························································································································· 295
Port security modes ······························································································································· 295
Restrictions and guidelines: Port security configuration················································································· 298
Port security tasks at a glance ······················································································································· 299
Enabling port security····································································································································· 299
Setting the port security mode ······················································································································· 300
Setting port security's limit on the number of secure MAC addresses on a port ············································ 301
Configuring secure MAC addresses ·············································································································· 302
About secure MAC addresses ··············································································································· 302
Prerequisites ·········································································································································· 302
Adding secure MAC addresses·············································································································· 303
Enabling inactivity aging for secure MAC addresses ············································································· 303
Enabling the dynamic secure MAC feature ···························································································· 303
Configuring NTK············································································································································· 304
Configuring intrusion protection ····················································································································· 304
Ignoring authorization information from the server························································································· 305
Configuring MAC move ·································································································································· 305
Enabling the authorization-fail-offline feature ································································································· 306
Setting port security's limit on the number of MAC addresses for specific VLANs on a port ························· 307
Enabling open authentication mode ··············································································································· 307
Configuring free VLANs for port security········································································································ 308
Applying a NAS-ID profile to port security ······································································································ 309
Enabling the escape critical VSI feature for 802.1X and MAC authentication users ····································· 310
Enabling SNMP notifications for port security ································································································ 311
Enabling port security user logging ················································································································ 311
Display and maintenance commands for port security ·················································································· 312
Port security configuration examples ············································································································· 312
Example: Configuring port security in autoLearn mode ········································································· 312
Example: Configuring port security in userLoginWithOUI mode ···························································· 314
Example: Configuring port security in macAddressElseUserLoginSecure mode··································· 317
Troubleshooting port security ························································································································· 321
Cannot set the port security mode ········································································································· 321
Cannot configure secure MAC addresses ····························································································· 322
Configuring user profiles ············································································ 323
About user profiles ········································································································································· 323
Prerequisites for user profile ·························································································································· 323
Configuring a user profile Configuring a user profile ······················································································ 323
Display and maintenance commands for user profiles ·················································································· 323
User profile configuration examples ··············································································································· 324
Example: Configuring user profiles and QoS policies ············································································ 324

vii
Configuring password control ···································································· 328
About password control·································································································································· 328
Password setting ···································································································································· 328
Password updating and expiration ········································································································· 329
User login control ··································································································································· 330
Password not displayed in any form ······································································································ 331
Logging ·················································································································································· 331
FIPS compliance ············································································································································ 332
Restrictions and guidelines: Password control configuration ········································································· 332
Password control tasks at a glance················································································································ 332
Enabling password control ····························································································································· 332
Setting global password control parameters ·································································································· 333
Setting user group password control parameters ·························································································· 335
Setting local user password control parameters ···························································································· 336
Setting super password control parameters··································································································· 337
Display and maintenance commands for password control ··········································································· 338
Password control configuration examples ····································································································· 338
Example: Configuring password control································································································· 338
Configuring keychains ··············································································· 342
About keychains ············································································································································· 342
Restrictions and guidelines: Keychain configuration ······················································································ 342
Configuring a keychain··································································································································· 342
Display and maintenance commands for keychain ························································································ 343
Keychain configuration example ···················································································································· 343
Example: Configuring keychains ············································································································ 343
Managing public keys ················································································ 349
About public key management ······················································································································· 349
Asymmetric key algorithm overview ······································································································· 349
Usage of asymmetric key algorithms ····································································································· 349
FIPS compliance ············································································································································ 349
Public key management tasks at a glance ····································································································· 349
Creating a local key pair································································································································· 350
Distributing a local host public key ················································································································· 351
About distribution of local host public keys ···························································································· 351
Exporting a host public key ···················································································································· 351
Displaying a host public key ··················································································································· 352
Configuring a peer host public key ················································································································· 352
About peer host public key configuration ······························································································· 352
Restrictions and guidelines for peer host public key configuration ························································ 353
Importing a peer host public key from a public key file ·········································································· 353
Entering a peer host public key ·············································································································· 353
Destroying a local key pair ····························································································································· 354
Display and maintenance commands for public keys ···················································································· 354
Examples of public key management ············································································································ 354
Example: Entering a peer host public key ······························································································ 354
Example: Importing a public key from a public key file ·········································································· 356
Configuring PKI ························································································· 359
About PKI ······················································································································································· 359
PKI terminology ······································································································································ 359
PKI architecture······································································································································ 360
Retrieval, usage, and maintenance of a digital certificate ······································································ 361
PKI applications ····································································································································· 361
FIPS compliance ············································································································································ 361
PKI tasks at a glance ····································································································································· 361
Configuring a PKI entity ································································································································· 362
Configuring a PKI domain ······························································································································ 363
About PKI domain ·································································································································· 363
PKI domain tasks at a glance················································································································· 363

viii
 Creating a PKI domain ··························································································································· 364
Specifying the trusted CA······················································································································· 364
Specifying the PKI entity name ·············································································································· 364
Specifying the certificate request reception authority············································································· 364
Specifying the certificate request URL ··································································································· 365
Setting the SCEP polling interval and maximum polling attempts ························································· 365
Specifying the LDAP server ··················································································································· 365
Specifying the fingerprint for root CA certificate verification··································································· 365
Specifying the key pair for certificate request ························································································ 366
Specifying the intended purpose for the certificate ················································································ 366
Specifying the source IP address for PKI protocol packets ··································································· 367
Specifying the storage path for certificates and CRLs ··················································································· 367
Requesting a certificate·································································································································· 368
About certificate request configuration ··································································································· 368
Restrictions and guidelines for certificate request configuration ···························································· 368
Prerequisites for certificate request configuration ·················································································· 368
Enabling the automatic online certificate request mode········································································· 369
Manually submitting an online certificate request ·················································································· 369
Manually submitting a certificate request in offline mode······································································· 370
Aborting a certificate request ························································································································· 370
Obtaining certificates······································································································································ 371
Verifying PKI certificates ································································································································ 372
About certification verification ················································································································ 372
Restrictions and guidelines for certificate verification ············································································ 372
Verifying certificates with CRL checking ································································································ 373
Verifying certificates without CRL checking ··························································································· 373
Exporting certificates ······································································································································ 374
Removing a certificate···································································································································· 374
Configuring a certificate-based access control policy ···················································································· 375
About certificate-based access control policies ····················································································· 375
Procedure··············································································································································· 375
Display and maintenance commands for PKI ································································································ 376
PKI configuration examples ··························································································································· 376
Example: Requesting a certificate from an RSA Keon CA server·························································· 377
Example: Requesting a certificate from a Windows Server 2003 CA server ········································· 379
Example: Requesting a certificate from an OpenCA server··································································· 383
Example: Configuring IKE negotiation with RSA digital signature from a Windows Server 2003 CA server
······························································································································································· 386
Example: Importing and exporting certificates ······················································································· 388
Troubleshooting PKI configuration ················································································································· 393
Failed to obtain the CA certificate ·········································································································· 394
Failed to obtain local certificates ············································································································ 394
Failed to request local certificates ·········································································································· 395
Failed to obtain CRLs····························································································································· 396
Failed to import the CA certificate ·········································································································· 396
Failed to import the local certificate········································································································ 397
Failed to export certificates ···················································································································· 397
Failed to set the storage path················································································································· 398
Configuring IPsec ······················································································ 399
About IPsec ···················································································································································· 399
IPsec framework ···································································································································· 399
IPsec security services··························································································································· 399
Benefits of IPsec ···································································································································· 399
Security protocols··································································································································· 399
Encapsulation modes ····························································································································· 400
Security association ······························································································································· 401
Authentication and encryption ················································································································ 401
IPsec-protected traffic ···························································································································· 402
ACL-based IPsec ··································································································································· 402
IPv6 routing protocol-based IPsec ········································································································· 403
IPsec policy and IPsec profile ················································································································ 403

ix
 IPsec RRI ··············································································································································· 404
Protocols and standards ························································································································ 405
FIPS compliance ············································································································································ 405
Restrictions and guidelines: IPsec configuration···························································································· 405
Implementing ACL-based IPsec····················································································································· 405
ACL-based IPsec tasks at a glance ······································································································· 405
Configuring an ACL ································································································································ 406
Configuring an IPsec transform set ········································································································ 408
Configuring a manual IPsec policy ········································································································· 411
Configuring an IKE-based IPsec policy ·································································································· 412
Applying an IPsec policy to an interface ································································································ 415
Enabling ACL checking for de-encapsulated packets ············································································ 416
Configuring IPsec anti-replay ················································································································· 416
Configuring IPsec anti-replay redundancy ····························································································· 417
Binding a source interface to an IPsec policy ························································································ 417
Enabling QoS pre-classify ······················································································································ 418
Configuring the DF bit of IPsec packets ································································································· 419
Configuring IPsec RRI···························································································································· 419
Configuring IPsec for IPv6 routing protocols ·································································································· 420
IPsec protection for IPv6 routing protocols tasks at a glance ································································ 420
Configuring a manual IPsec profile ········································································································ 420
Applying the IPsec profile to an IPv6 routing protocol············································································ 422
Configuring the global IPsec SA lifetime and idle timeout·············································································· 422
Configuring IPsec fragmentation ···················································································································· 422
Setting the maximum number of IPsec tunnels ····························································································· 423
Enabling logging for IPsec packets ················································································································ 423
Configuring SNMP notifications for IPsec ······································································································ 423
Display and maintenance commands for IPsec ····························································································· 424
IPsec configuration examples ························································································································ 425
Example: Configuring a manual mode IPsec tunnel for IPv4 packets ··················································· 425
Example: Configuring an IKE-based IPsec tunnel for IPv4 packets ······················································ 427
Example: Configuring IPsec for RIPng··································································································· 430
Example: Configuring IPsec RRI············································································································ 433
Configuring IKE ························································································· 438
About IKE ······················································································································································· 438
Benefits of IKE ······································································································································· 438
Relationship between IPsec and IKE ····································································································· 438
IKE negotiation process ························································································································· 438
IKE security mechanism························································································································· 440
Protocols and standards ························································································································ 440
FIPS compliance ············································································································································ 441
IKE tasks at a glance ····································································································································· 441
Prerequisites for IKE configuration················································································································· 441
Configuring an IKE profile ······························································································································ 442
Creating an IKE profile ··························································································································· 442
Configuring peer IDs for the IKE profile ································································································· 442
Specifying the IKE keychain or PKI domain ··························································································· 442
Configuring the IKE phase 1 negotiation mode······················································································ 443
Specifying IKE proposals for the IKE profile ·························································································· 443
Configuring the local ID for the IKE profile ····························································································· 444
Specifying an inside VPN instance for the IKE profile············································································ 444
Configuring optional features for the IKE profile ···················································································· 444
Configuring an IKE proposal ·························································································································· 445
Configuring an IKE keychain ·························································································································· 446
Configuring the global identity information ····································································································· 447
Configuring the IKE keepalive feature ··········································································································· 448
Configuring the IKE NAT keepalive feature ··································································································· 448
Configuring global IKE DPD ··························································································································· 449
Enabling invalid SPI recovery ························································································································ 449
Setting the maximum number of IKE SAs ······································································································ 450
Configuring SNMP notifications for IKE ········································································································· 450

x
 Display and maintenance commands for IKE ································································································ 451
IKE configuration examples ··························································································································· 451
Example: Configuring main-mode IKE with preshared key authentication ············································ 451
Example: Configuring an IKE-based IPsec tunnel for IPv4 packets ······················································ 454
Troubleshooting IKE······································································································································· 456
IKE negotiation failed because no matching IKE proposals were found ················································ 456
IKE negotiation failed because no IKE proposals or IKE keychains are specified correctly ·················· 457
IPsec SA negotiation failed because no matching IPsec transform sets were found ···························· 458
IPsec SA negotiation failed due to invalid identity information ······························································· 458
Configuring IKEv2 ······················································································ 461
About IKEv2 ··················································································································································· 461
IKEv2 negotiation process ····················································································································· 461
New features in IKEv2···························································································································· 462
Protocols and standards ························································································································ 462
IKEv2 tasks at a glance·································································································································· 462
Prerequisites for IKEv2 configuration ············································································································· 463
Configuring an IKEv2 profile ·························································································································· 463
Creating an IKEv2 profile ······················································································································· 463
Specifying the local and remote identity authentication methods ·························································· 464
Configuring the IKEv2 keychain or PKI domain ····················································································· 464
Configuring the local ID for the IKEv2 profile ························································································· 464
Configuring peer IDs for the IKEv2 profile······························································································ 465
Specifying a VPN instance for the IKEv2 profile ···················································································· 465
Specifying an inside VPN instance for the IKEv2 profile ········································································ 466
Configuring optional features for the IKEv2 profile················································································· 466
Configuring an IKEv2 policy ··························································································································· 467
Configuring an IKEv2 proposal ······················································································································ 468
Configuring an IKEv2 keychain ······················································································································ 469
Configure global IKEv2 parameters ··············································································································· 470
Enabling the cookie challenging feature ································································································ 470
Configuring the IKEv2 DPD feature ······································································································· 470
Configuring the IKEv2 NAT keepalive feature························································································ 471
Display and maintenance commands for IKEv2 ···························································································· 471
Troubleshooting IKEv2 ··································································································································· 472
IKEv2 negotiation failed because no matching IKEv2 proposals were found ········································ 472
IPsec SA negotiation failed because no matching IPsec transform sets were found ···························· 472
IPsec tunnel establishment failed··········································································································· 473
Configuring SSH ························································································ 474
About SSH ····················································································································································· 474
SSH applications ···································································································································· 474
How SSH works ····································································································································· 474
SSH authentication methods·················································································································· 475
SSH support for Suite B ························································································································· 476
FIPS compliance ············································································································································ 477
Configuring the device as an SSH server ······································································································ 477
SSH server tasks at a glance ················································································································· 477
Generating local key pairs······················································································································ 478
Specifying the SSH service port············································································································· 478
Enabling the Stelnet server ···················································································································· 479
Enabling the SFTP server ······················································································································ 479
Enabling the SCP server ························································································································ 479
Enabling NETCONF over SSH ·············································································································· 480
Configuring the user lines for SSH login ································································································ 480
Configuring a client's host public key ····································································································· 480
Configuring an SSH user ······················································································································· 482
Configuring the SSH management parameters ····················································································· 483
Specifying a PKI domain for the SSH server ························································································· 485
Disconnecting SSH sessions ················································································································· 485
Configuring the device as an Stelnet client ···································································································· 486
Stelnet client tasks at a glance··············································································································· 486

xi
 Generating local key pairs······················································································································ 486
Specifying the source IP address for outgoing SSH packets ································································· 486
Establishing a connection to an Stelnet server ······················································································ 487
Deleting server public keys saved in the public key file on the Stelnet client········································· 489
Establishing a connection to an Stelnet server based on Suite B ·························································· 489
Configuring the device as an SFTP client ······································································································ 489
SFTP client tasks at a glance················································································································· 489
Generating local key pairs······················································································································ 490
Specifying the source IP address for outgoing SFTP packets ······························································· 490
Establishing a connection to an SFTP server ························································································ 491
Deleting server public keys saved in the public key file on the SFTP client··········································· 492
Establishing a connection to an SFTP server based on Suite B ···························································· 493
Working with SFTP directories ··············································································································· 493
Working with SFTP files ························································································································· 494
Displaying help information ···················································································································· 495
Terminating the connection with the SFTP server ················································································· 495
Configuring the device as an SCP client········································································································ 495
SCP client tasks at a glance ·················································································································· 495
Generating local key pairs······················································································································ 496
Specifying the source IP address for outgoing SCP packets ································································· 496
Establishing a connection to an SCP server ·························································································· 497
Deleting server public keys saved in the public key file on the SCP client ············································ 498
Establishing a connection to an SCP server based on Suite B······························································ 499
Specifying algorithms for SSH2 ····················································································································· 499
About algorithms for SSH2····················································································································· 499
Specifying key exchange algorithms for SSH2 ······················································································ 499
Specifying public key algorithms for SSH2 ···························································································· 500
Specifying encryption algorithms for SSH2 ···························································································· 500
Specifying MAC algorithms for SSH2 ···································································································· 500
Display and maintenance commands for SSH ······························································································ 501
Stelnet configuration examples ······················································································································ 501
Example: Configuring the device as an Stelnet server (password authentication) ································ 502
Example: Configuring the device as an Stelnet server (publickey authentication)································· 504
Example: Configuring the device as an Stelnet client (password authentication) ·································· 510
Example: Configuring the device as an Stelnet client (publickey authentication) ·································· 514
Example: Configuring Stelnet based on 128-bit Suite B algorithms······················································· 516
SFTP configuration examples ························································································································ 520
Example: Configuring the device as an SFTP server (password authentication) ·································· 520
Example: Configuring the device as an SFTP client (publickey authentication) ···································· 522
Example: Configuring SFTP based on 192-bit Suite B algorithms························································· 525
SCP configuration examples ·························································································································· 529
Example: Configuring SCP with password authentication ····································································· 529
Example: Configuring SCP file transfer with a Linux SCP client ···························································· 531
Example: Configuring SCP based on Suite B algorithms ······································································ 533
NETCONF over SSH configuration examples ······························································································· 539
Example: Configuring NETCONF over SSH with password authentication ··········································· 539
Configuring SSL ························································································ 542
About SSL ······················································································································································ 542
SSL security services ····························································································································· 542
SSL protocol stack ································································································································· 542
SSL protocol versions ···························································································································· 543
FIPS compliance ············································································································································ 543
Restrictions and guidelines: SSL configuration ······························································································ 543
SSL tasks at a glance ···································································································································· 543
Configuring the SSL server ···················································································································· 543
Configuring the SSL client······················································································································ 544
Configuring an SSL server policy ··················································································································· 544
Configuring an SSL client policy ···················································································································· 545
Disabling SSL protocol versions for the SSL server ······················································································ 546
Disabling SSL session renegotiation·············································································································· 546
Display and maintenance commands for SSL ······························································································· 547

xii
Configuring attack detection and prevention ·············································· 548
Overview ························································································································································ 548
Attacks that the device can prevent ··············································································································· 548
TCP fragment attack ······························································································································ 548
Login dictionary attack ··························································································································· 548
Configuring TCP fragment attack prevention ································································································· 548
Enabling the login delay ································································································································· 549
Configuring TCP attack prevention ···························································· 550
About TCP attack prevention ························································································································· 550
Configuring Naptha attack prevention ············································································································ 550
Configuring IP source guard ······································································ 551
About IPSG ···················································································································································· 551
IPSG operating mechanism ··················································································································· 551
Static IPSG bindings ······························································································································ 551
Dynamic IPSG bindings ························································································································· 552
IPSG bindings synchronized by routing protocols·················································································· 553
IPSG tasks at a glance··································································································································· 553
Configuring the IPv4SG feature ····················································································································· 553
Enabling IPv4SG ···································································································································· 553
Configuring a static IPv4SG binding ······································································································ 554
Excluding IPv4 packets from IPSG filtering···························································································· 555
Enabling IPv4SG alarming ····················································································································· 556
Configuring the IPv6SG feature ····················································································································· 556
Enabling IPv6SG ···································································································································· 556
Configuring a static IPv6SG binding ······································································································ 557
Setting the maximum number of IPv6SG bindings on an interface························································ 558
Enabling IPv6SG alarming ····················································································································· 558
Display and maintenance commands for IPSG ····························································································· 559
IPSG configuration examples ························································································································ 560
Example: Configuring static IPv4SG ······································································································ 560
Example: Configuring DHCP snooping-based dynamic IPv4SG ··························································· 561
Example: Configuring DHCP relay agent-based dynamic IPv4SG ························································ 562
Example: Configuring static IPv6SG ······································································································ 563
Example: Configuring DHCPv6 snooping-based dynamic IPv6SG address bindings ··························· 563
Example: Configuring DHCPv6 snooping-based dynamic IPv6SG prefix bindings ······························· 564
Example: Configuring DHCPv6 relay agent-based dynamic IPv6SG ···················································· 565
Configuring ARP attack protection ····························································· 567
About ARP attack protection ·························································································································· 567
ARP attack protection tasks at a glance ········································································································ 567
Configuring unresolvable IP attack protection ······························································································· 567
About unresolvable IP attack protection································································································· 567
Configuring ARP source suppression ···································································································· 568
Configuring ARP blackhole routing ········································································································ 568
Display and maintenance commands for unresolvable IP attack protection ·········································· 569
Example: Configuring unresolvable IP attack protection········································································ 569
Configuring ARP packet rate limit ·················································································································· 570
Configuring source MAC-based ARP attack detection ·················································································· 571
Display and maintenance commands for source MAC-based ARP attack detection····························· 572
Example: Configuring source MAC-based ARP attack detection ·························································· 572
Configuring ARP packet source MAC consistency check ·············································································· 573
About ARP packet source MAC consistency check ··············································································· 573
Procedure··············································································································································· 573
Configuring ARP active acknowledgement ···································································································· 573
Configuring authorized ARP··························································································································· 574
About authorized ARP···························································································································· 574
Procedure··············································································································································· 574
Example: Configuring authorized ARP on a DHCP server ···································································· 574
Example: Configuring authorized ARP on a DHCP relay agent····························································· 575

xiii
 Configuring ARP attack detection ·················································································································· 577
About ARP attack detection ··················································································································· 577
Restrictions and guidelines: ARP attack detection················································································· 577
Configuring user validity check ·············································································································· 577
Configuring ARP packet validity check ·································································································· 579
Configuring ARP restricted forwarding ··································································································· 580
Ignoring ingress ports of ARP packets during user validity check ························································· 581
Configuring ARP attack detection for a VSI ··························································································· 581
Enabling ARP attack detection logging ·································································································· 582
Display and maintenance commands for ARP attack detection ···························································· 583
Example: Configuring user validity check ······························································································ 583
Example: Configuring user validity check and ARP packet validity check ············································· 584
Example: Configuring ARP restricted forwarding ··················································································· 586
Configuring ARP scanning and fixed ARP ····································································································· 587
About this task········································································································································ 587
Restrictions and guidelines ···················································································································· 588
Triggering an ARP scanning ·················································································································· 588
Configuring automatic ARP scanning ···································································································· 588
Configuring fixed ARP ···························································································································· 589
Configuring ARP gateway protection ············································································································· 589
About ARP gateway protection ·············································································································· 589
Restrictions and guidelines ···················································································································· 589
Procedure··············································································································································· 589
Example: Configuring ARP gateway protection ····················································································· 589
Configuring ARP filtering ································································································································ 590
ARP filtering ··········································································································································· 590
Restrictions and guidelines ···················································································································· 590
Procedure··············································································································································· 591
Example: Configuring ARP filtering ········································································································ 591
Configuring ARP sender IP address checking ······························································································· 592
About ARP sender IP address checking ································································································ 592
Restrictions and guidelines ···················································································································· 592
Procedure··············································································································································· 592
Example: Configuring ARP sender IP address checking ······································································· 592
Configuring ND attack defense ·································································· 595
About ND attack defense ······························································································································· 595
ND attack defense tasks at a glance·············································································································· 595
Enabling source MAC consistency check for ND messages ········································································· 596
Configuring ND attack detection ···················································································································· 596
About ND attack detection ····················································································································· 596
Restrictions and guidelines for ND attack detection configuration ························································· 597
Enabling ND attack detection on an interface ························································································ 597
Configuring ND attack detection for a VLAN ·························································································· 597
Configuring ND attack detection for a VSI ····························································································· 598
Ignoring ingress ports of ND packets ····································································································· 598
Enabling ND attack detection logging ···································································································· 599
Display and maintenance commands for ND attack detection······························································· 599
Example: Configuring ND attack detection ···························································································· 599
Configuring RA guard····································································································································· 601
About RA guard······································································································································ 601
Specifying the role of the attached device ····························································································· 601
Configuring and applying an RA guard policy ························································································ 602
Enabling the RA guard logging feature ·································································································· 603
Display and maintenance commands for RA guard ··············································································· 603
Example: Configuring RA guard············································································································· 603
Configuring uRPF ······················································································ 606
About uRPF···················································································································································· 606
uRPF application scenario ····················································································································· 606
uRPF check modes ································································································································ 606
Network application ································································································································ 606

xiv
 Enabling uRPF globally ·································································································································· 607
Display and maintenance commands for uRPF ····························································································· 607
Configuring SAVI ······················································································· 608
About SAVI····················································································································································· 608
SAVI application scenarios ···························································································································· 608
SAVI tasks at a glance ··································································································································· 608
Enabling SAVI ················································································································································ 608
Configuring IPv6 source guard······················································································································· 609
Configuring DHCPv6 snooping ······················································································································ 609
Configuring ND parameters ··························································································································· 609
Setting the entry deletion delay ······················································································································ 609
Enabling packet spoofing logging and filtering entry logging ········································································· 610
SAVI configuration examples ························································································································· 610
Example: Configuring DHCPv6-only SAVI ····························································································· 610
Example: Configuring SLAAC-only SAVI ······························································································· 612
Example: Configuring DHCPv6+SLAAC SAVI ······················································································· 613
Configuring MFF ························································································ 615
About MFF ····················································································································································· 615
MFF network model ······························································································································· 615
Port roles ················································································································································ 615
Processing of ARP packets in MFF ······································································································· 616
MFF default gateway······························································································································ 616
Protocols and standards ························································································································ 616
MFF tasks at a glance ···································································································································· 616
Enabling MFF ················································································································································· 617
Configuring a network port ····························································································································· 617
Enabling periodic gateway probe ··················································································································· 618
Specifying the IP addresses of servers ·········································································································· 618
Display and maintenance commands for MFF ······························································································ 618
MFF configuration examples ·························································································································· 619
Example: Configuring MFF in a tree network ························································································· 619
Example: Configuring MFF in a ring network ························································································· 620
Configuring FIPS ······················································································· 622
About FIPS ····················································································································································· 622
FIPS security levels································································································································ 622
FIPS functionality ··································································································································· 622
FIPS self-tests ········································································································································ 622
Restrictions and guidelines: FIPS ·················································································································· 623
Entering FIPS mode ······································································································································· 624
About entering FIPS mode ····················································································································· 624
Restrictions and guidelines ···················································································································· 625
Using the automatic reboot method to enter FIPS mode ······································································· 625
Using the manual reboot method to enter FIPS mode ··········································································· 625
Manually triggering self-tests ························································································································· 626
Exiting FIPS mode ········································································································································· 627
Display and maintenance commands for FIPS ······························································································ 628
FIPS configuration examples ························································································································· 628
Example: Entering FIPS mode through automatic reboot ······································································ 628
Example: Entering FIPS mode through manual reboot·········································································· 629
Example: Exiting FIPS mode through automatic reboot ········································································ 631
Example: Exiting FIPS mode through manual reboot ············································································ 631
Configuring crypto engines ········································································ 633
About crypto engines ····································································································································· 633
Display and maintenance commands for crypto engines ·············································································· 633
Configuring MACsec ·················································································· 634
About MACsec ··············································································································································· 634
Basic concepts ······································································································································· 634

xv
 MACsec services ··································································································································· 635
MACsec application modes···················································································································· 635
MACsec operating mechanism ·············································································································· 636
Protocols and standards ························································································································ 637
Restrictions: Hardware compatibility with MACsec ························································································ 638
MACsec tasks at a glance······························································································································ 638
Enabling MKA ················································································································································ 638
Enabling MACsec desire ································································································································ 639
Configuring a preshared key ·························································································································· 639
Configuring the MKA key server priority ········································································································ 640
Setting the MKA life time ································································································································ 640
Configuring MACsec protection parameters ·································································································· 640
About MACsec protection parameters ··································································································· 640
Restrictions and guidelines for MACsec protection parameter configuration········································· 641
Configuring MACsec protection parameters in interface view ······························································· 641
Configuring MACsec protection parameters by MKA policy ·································································· 642
Enabling MKA session logging······················································································································· 643
Display and maintenance commands for MACsec ························································································ 643
MACsec configuration examples···················································································································· 644
Example: Configuring client-oriented MACsec······················································································· 644
Example: Configuring device-oriented MACsec····················································································· 646
Troubleshooting MACsec ······························································································································· 650
Cannot establish MKA sessions between MACsec devices ·································································· 650
Configuring an 802.1X client ······································································ 651
About 802.1X clients ······································································································································ 651
802.1X client tasks at a glance ······················································································································ 651
Enabling the 802.1X client feature ················································································································· 651
Configuring an 802.1X client username and password ················································································· 652
Specifying an 802.1X client EAP authentication method ··············································································· 652
Configuring an 802.1X client MAC address ··································································································· 653
Specifying an 802.1X client mode for sending EAP-Response and EAPOL-Logoff packets ························· 653
Configuring an 802.1X client anonymous identifier ························································································ 654
Specifying an SSL client policy ······················································································································ 655
Display and maintenance commands for 802.1X client ················································································· 655
Configuring SAVA ······················································································ 656
About SAVA ··················································································································································· 656
Benefits ·················································································································································· 656
Mechanism ············································································································································· 656
Application scenarios ····························································································································· 657
Restrictions: Hardware compatibility with SAVA ···························································································· 658
SAVA tasks at a glance·································································································································· 658
Enabling SAVA··············································································································································· 659
Enabling SAVA entry creation based on synchronized remote routes ·························································· 659
Adding an interface to a SAVA access group ································································································ 660
Configuring SAVA logging······························································································································ 660
Display and maintenance commands for SAVA ···························································································· 661
SAVA configuration examples ······················································································································· 661
Example: Configuring SAVA on border devices directly connected the LAN········································· 661
Example: Configuring SAVA on border devices indirectly connected the LAN (OSPFv3) ····················· 662
Example: Configuring SAVA on border devices indirectly connected the LAN (IPv6 IS-IS) ·················· 666
Example: Configuring SAVA on inter-AS border devices indirectly connected the LAN ························ 670
Document conventions and icons ······························································ 675
Conventions ··················································································································································· 675
Network topology icons ·································································································································· 676
Support and other resources ····································································· 677
Accessing Hewlett Packard Enterprise Support····························································································· 677
Accessing updates ········································································································································· 677
Websites ················································································································································ 678

xvi
 Customer self repair ······························································································································· 678
Remote support······································································································································ 678
Documentation feedback ······················································································································· 678
Index·········································································································· 680

xvii
Configuring AAA
About AAA
AAA implementation
Authentication, Authorization, and Accounting (AAA) provides a uniform framework for implementing
network access management. This feature specifies the following security functions:
• Authentication—Identifies users and verifies their validity.
• Authorization—Grants different users different rights, and controls the users' access to
resources and services. For example, you can permit office users to read and print files and
prevent guests from accessing files on the device.
• Accounting—Records network usage details of users, including the service type, start time,
and traffic. This function enables time-based and traffic-based charging and user behavior
auditing.

AAA network diagram

AAA uses a client/server model. The client runs on the access device, or the network access server
(NAS), which authenticates user identities and controls user access. The server maintains user
information centrally. See Figure 1.
Figure 1 AAA network diagram

Internet

Network

Remote user NAS RADIUS server

HWTACACS server

To access networks or resources beyond the NAS, a user sends its identity information to the NAS.
The NAS transparently passes the user information to AAA servers and waits for the authentication,
authorization, and accounting result. Based on the result, the NAS determines whether to permit or
deny the access request.
AAA has various implementations, including HWTACACS, LDAP, and RADIUS. RADIUS is most
often used.
You can use different servers to implement different security functions. For example, you can use an
HWTACACS server for authentication and authorization, and use a RADIUS server for accounting.
You can choose the security functions provided by AAA as needed. For example, if your company
wants employees to be authenticated before they access specific resources, you would deploy an
authentication server. If network usage information is needed, you would also configure an
accounting server.

1
 The device performs dynamic password authentication.

RADIUS
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 authorization process is combined with the RADIUS authentication process, and user
authorization information is piggybacked in authentication responses. RADIUS uses UDP port 1812
for authentication and UDP port 1813 for accounting.
RADIUS was originally designed for dial-in user access, and has been extended to support
additional access methods, such as Ethernet and ADSL.
Client/server model
The RADIUS client runs on the NASs located throughout the network. It passes user information to
RADIUS servers and acts on the responses to, 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.
The RADIUS server operates using the following process:
1. Receives authentication, authorization, and accounting requests from RADIUS clients.
2. Performs user authentication, authorization, or accounting.
3. Returns user access control information (for example, rejecting or accepting the user access
request) to the clients.
The RADIUS server can also act as the client of another RADIUS server to provide authentication
proxy services.
The RADIUS server maintains the following databases:
• Users—Stores user information, such as the usernames, passwords, applied protocols, and IP
addresses.
• Clients—Stores information about RADIUS clients, such as shared keys and IP addresses.
• Dictionary—Stores RADIUS protocol attributes and their values.
Figure 2 RADIUS server databases

RADIUS servers

Users Clients Dictionary

Information exchange security mechanism

The RADIUS client and server exchange information between them with the help of shared keys,
which are preconfigured on the client and server. A RADIUS packet has a 16-byte field called
Authenticator. This field includes a signature generated by using the MD5 algorithm, the shared key,
and some other information. The receiver of the packet verifies the signature and accepts the packet
only when the signature is correct. This mechanism ensures the security of information exchanged
between the RADIUS client and server.
The shared keys are also used to encrypt user passwords that are included in RADIUS packets.

2
User authentication methods
The RADIUS server supports multiple user authentication methods, such as PAP, CHAP, and EAP.
Basic RADIUS packet exchange process
Figure 3 illustrates the interactions between a user host, the RADIUS client, and the RADIUS server.
Figure 3 Basic RADIUS packet exchange process
Host RADIUS client RADIUS server

1) Username and password

2) Access-Request

3) Access-Accept/Reject

4) Accounting-Request (start)

5) Accounting-Response

6) The host accesses the resources

7) Teardown request
8) Accounting-Request (stop)

9) Accounting-Response
10) Notification of access termination

RADIUS uses in the following workflow:

1. The host sends a connection request that includes the user's username and password to the
RADIUS client.
2. The RADIUS client sends an authentication request (Access-Request) to the RADIUS server.
The request includes the user's password, which has been processed by the MD5 algorithm
and shared key.
3. The RADIUS server authenticates the username and password. If the authentication succeeds,
the server sends back an Access-Accept packet that contains the user's authorization
information. If the authentication fails, the server returns an Access-Reject packet.
4. The RADIUS client permits or denies the user according to the authentication result. If the result
permits the user, the RADIUS client sends a start-accounting request (Accounting-Request)
packet to the RADIUS server.
5. The RADIUS server returns an acknowledgment (Accounting-Response) packet and starts
accounting.
6. The user accesses the network resources.
7. The host requests the RADIUS client to tear down the connection.
8. The RADIUS client sends a stop-accounting request (Accounting-Request) packet to the
RADIUS server.
9. The RADIUS server returns an acknowledgment (Accounting-Response) and stops accounting
for the user.
10. The RADIUS client notifies the user of the termination.

3
RADIUS packet format
RADIUS uses UDP to transmit packets. The protocol also uses a series of mechanisms to ensure
smooth packet exchange between the RADIUS server and the client. These mechanisms include the
timer mechanism, the retransmission mechanism, and the backup server mechanism.
Figure 4 RADIUS packet format
0 7 15 31
7
Code Identifier Length

Authenticator (16bytes)

Attributes

Descriptions of the fields are as follows:

• The Code field (1 byte long) indicates the type of the RADIUS packet. Table 1 gives the main
values and their meanings.
Table 1 Main values of the Code field

Code Packet type Description

From the client to the server. A packet of this type includes user
information for the server to authenticate the user. It must contain the
1 Access-Request
User-Name attribute and can optionally contain the attributes of
NAS-IP-Address, User-Password, and NAS-Port.
From the server to the client. If all attribute values included in the
2 Access-Accept Access-Request are acceptable, the authentication succeeds, and
the server sends an Access-Accept response.
From the server to the client. If any attribute value included in the
3 Access-Reject Access-Request is unacceptable, the authentication fails, and the
server sends an Access-Reject response.
From the client to the server. A packet of this type includes user
Accounting-Reques information for the server to start or stop accounting for the user. The
4
t Acct-Status-Type attribute in the packet indicates whether to start or
stop accounting.

From the server to the client. The server sends a packet of this type to
Accounting-Respon
5 notify the client that it has received the Accounting-Request and has
se
successfully recorded the accounting information.

• The Identifier field (1 byte long) is used to match response packets with request packets and to
detect duplicate request packets. The request and response packets of the same exchange
process for the same purpose (such as authentication or accounting) have the same identifier.
• The Length field (2 bytes long) indicates the length of the entire packet (in bytes), including the
Code, Identifier, Length, Authenticator, and Attributes fields. Bytes beyond this length are
considered padding and are ignored by the receiver. If the length of a received packet is less
than this length, the packet is dropped.
• The Authenticator field (16 bytes long) is used to authenticate responses from the RADIUS
server and to encrypt user passwords. There are two types of authenticators: request
authenticator and response authenticator.

4
 • The Attributes field (variable in length) includes authentication, authorization, and accounting
information. This field can contain multiple attributes, each with the following subfields:
 Type—Type of the attribute.
 Length—Length of the attribute in bytes, including the Type, Length, and Value subfields.
 Value—Value of the attribute. Its format and content depend on the Type subfield.
Extended RADIUS attributes
The RADIUS protocol features excellent extensibility. The Vendor-Specific attribute (attribute 26)
allows a vendor to define extended attributes. The extended attributes can implement functions that
the standard RADIUS protocol does not provide.
A vendor can encapsulate multiple subattributes in the TLV format in attribute 26 to provide extended
functions. As shown in Figure 5, a subattribute encapsulated in attribute 26 consists of the following
parts:
• Vendor-ID—ID of the vendor. The most significant byte is 0. The other three bytes contains a
code compliant to RFC 1700.
• Vendor-Type—Type of the subattribute.
• Vendor-Length—Length of the subattribute.
• Vendor-Data—Contents of the subattribute.
The device supports RADIUS subattributes with a vendor ID of 25506. For more information, see
"Appendix C RADIUS subattributes (vendor ID 25506)."
Figure 5 Format of attribute 26
0 7 15 23 31
Type Length Vendor-ID

Vendor-ID (continued) Vendor-Type Vendor-Length

Vendor-Data
(Specified attribute value……)

……

HWTACACS
HW Terminal Access Controller Access Control System (HWTACACS) is an enhanced security
protocol based on TACACS (RFC 1492). HWTACACS is similar to RADIUS, and uses a client/server
model for information exchange between the NAS and the HWTACACS server.
HWTACACS typically provides AAA services for PPP, VPDN, and terminal users. In a typical
HWTACACS scenario, terminal users need to log in to the NAS. Working as the HWTACACS client,
the NAS sends users' usernames and passwords to the HWTACACS server for authentication. After
passing authentication and obtaining authorized rights, a user logs in to the device and performs
operations. The HWTACACS server records the operations that each user performs.
Differences between HWTACACS and RADIUS
HWTACACS and RADIUS have many features in common, such as using a client/server model,
using shared keys for data encryption, and providing flexibility and scalability. Table 2 lists the
primary differences between HWTACACS and RADIUS.
Table 2 Primary differences between HWTACACS and RADIUS

HWTACACS RADIUS
Uses TCP, which provides reliable network
Uses UDP, which provides high transport efficiency.
transmission.

5
 HWTACACS RADIUS
Encrypts the entire packet except for the Encrypts only the user password field in an
HWTACACS header. authentication packet.
Protocol packets are complicated and authorization
Protocol packets are simple and the authorization
is independent of authentication. Authentication and
process is combined with the authentication
authorization can be deployed on different
process.
HWTACACS servers.
Supports authorization of configuration commands.
Does not support authorization of configuration
Access to commands depends on both the user's
commands. Access to commands solely depends on
roles and authorization. A user can use only
the user's roles. For more information about user
commands that are permitted by the user roles and
roles, see Fundamentals Configuration Guide.
authorized by the HWTACACS server.

Basic HWTACACS packet exchange process

Figure 6 describes how HWTACACS performs user authentication, authorization, and accounting for
a Telnet user.

6
Figure 6 Basic HWTACACS packet exchange process for a Telnet user
Host HWTACACS client HWTACACS server

1) The user tries to log in

2) Start-authentication packet

3) Authentication response requesting the username

4) Request for username

5) The user enters the username

6) C ontinue-authentication packet with the username

7) Authentication response requesting the password

8) Request for password

9) The user enters the password

10) C ontinue-authentication packet with the password

11) Response indicating successful authentication

12) User authorization request packet

13) Response indicating successful authorization

14) The user logs in successfully

15) Start-accounting request

16) Response indicating the start of accounting

17) The user logs off

18) Stop-accounting request

19) Stop-accounting response

HWTACACS operates using in the following workflow:

1. A Telnet user sends an access request to the HWTACACS client.
2. The HWTACACS client sends a start-authentication packet to the HWTACACS server when it
receives the request.
3. The HWTACACS server sends back an authentication response to request the username.
4. Upon receiving the response, the HWTACACS client asks the user for the username.
5. The user enters the username.
6. After receiving the username from the user, the HWTACACS client sends the server a
continue-authentication packet that includes the username.
7. The HWTACACS server sends back an authentication response to request the login password.
8. Upon receipt of the response, the HWTACACS client prompts the user for the login password.
9. The user enters the password.

7
 10. After receiving the login password, the HWTACACS client sends the HWTACACS server a
continue-authentication packet that includes the login password.
11. If the authentication succeeds, the HWTACACS server sends back an authentication response
to indicate that the user has passed authentication.
12. The HWTACACS client sends a user authorization request packet to the HWTACACS server.
13. If the authorization succeeds, the HWTACACS server sends back an authorization response,
indicating that the user is now authorized.
14. Knowing that the user is now authorized, the HWTACACS client pushes its CLI to the user and
permits the user to log in.
15. The HWTACACS client sends a start-accounting request to the HWTACACS server.
16. The HWTACACS server sends back an accounting response, indicating that it has received the
start-accounting request.
17. The user logs off.
18. The HWTACACS client sends a stop-accounting request to the HWTACACS server.
19. The HWTACACS server sends back a stop-accounting response, indicating that the
stop-accounting request has been received.

LDAP
The Lightweight Directory Access Protocol (LDAP) provides standard multiplatform directory service.
LDAP was developed on the basis of the X.500 protocol. It improves the following functions of X.500:
• Read/write interactive access.
• Browse.
• Search.
LDAP is suitable for storing data that does not often change. The protocol is used to store user
information. For example, LDAP server software Active Directory Server is used in Microsoft
Windows operating systems. The software stores the user information and user group information
for user login authentication and authorization.
LDAP directory service
LDAP uses directories to maintain the organization information, personnel information, and resource
information. The directories are organized in a tree structure and include entries. An entry is a set of
attributes with distinguished names (DNs). The attributes are used to store information such as
usernames, passwords, emails, computer names, and phone numbers.
LDAP uses a client/server model, and all directory information is stored in the LDAP server.
Commonly used LDAP server products include Microsoft Active Directory Server, IBM Tivoli
Directory Server, and Sun ONE Directory Server.
LDAP authentication and authorization
AAA can use LDAP to provide authentication and authorization services for users. LDAP defines a
set of operations to implement its functions. The main operations for authentication and authorization
are the bind operation and search operation.
• The bind operation allows an LDAP client to perform the following operations:
 Establish a connection with the LDAP server.
 Obtain the access rights to the LDAP server.
 Check the validity of user information.
• The search operation constructs search conditions and obtains the directory resource
information of the LDAP server.
In LDAP authentication, the client completes the following tasks:

8
 1. Uses the LDAP server administrator DN to bind with the LDAP server. After the binding is
created, the client establishes a connection to the server and obtains the right to search.
2. Constructs search conditions by using the username in the authentication information of a user.
The specified root directory of the server is searched and a user DN list is generated.
3. Binds with the LDAP server by using each user DN and password. If a binding is created, the
user is considered legal.
In LDAP authorization, the client performs the same tasks as in LDAP authentication. When the
client constructs search conditions, it obtains both authorization information and the user DN list.
Basic LDAP authentication process
The following example illustrates the basic LDAP authentication process for a Telnet user.
Figure 7 Basic LDAP authentication process for a Telnet user
Host LDAP client LDAP server

1) The user logs in by Telnet

2) Establish a TCP connection

3) Administrator bind request

4) Bind response

5) User DN search request

6) Search response

7) User DN bind request

8) Bind response

9) Authorization process

10) The user logs in successfully

The following shows the basic LDAP authentication process:

1. A Telnet user initiates a connection request and sends the username and password to the
LDAP client.
2. After receiving the request, the LDAP client establishes a TCP connection with the LDAP
server.
3. To obtain the right to search, the LDAP client uses the administrator DN and password to send
an administrator bind request to the LDAP server.
4. The LDAP server processes the request. If the bind operation is successful, the LDAP server
sends an acknowledgment to the LDAP client.
5. The LDAP client sends a user DN search request with the username of the Telnet user to the
LDAP server.
6. After receiving the request, the LDAP server searches for the user DN by the base DN, search
scope, and filtering conditions. If a match is found, the LDAP server sends a response to notify
the LDAP client of the successful search. There might be one or more user DNs found.
7. The LDAP client uses the obtained user DN and the entered user password as parameters to
send a user DN bind request to the LDAP server. The server will check whether the user
password is correct.

9
 8. The LDAP server processes the request, and sends a response to notify the LDAP client of the
bind operation result. If the bind operation fails, the LDAP client uses another obtained user DN
as the parameter to send a user DN bind request to the LDAP server. This process continues
until a DN is bound successfully or all DNs fail to be bound. If all user DNs fail to be bound, the
LDAP client notifies the user of the login failure and denies the user's access request.
9. The LDAP client saves the user DN that has been bound and exchanges authorization packets
with the authorization server.
 If LDAP authorization is used, see the authorization process shown in Figure 8.
 If another method is expected for authorization, the authorization process of that method
applies.
10. After successful authorization, the LDAP client notifies the user of the successful login.
Basic LDAP authorization process
The following example illustrates the basic LDAP authorization process for a Telnet user.
Figure 8 Basic LDAP authorization process for a Telnet user
Host LDAP client LDAP server

1) The user logs in by Telnet

2) Authentication process
3) Establish a TCP connection

4) Administrator bind request

5) Bind response

6) User authorization search request

7) Search response
8) The user logs in
successfully

The following shows the basic LDAP authorization process:

1. A Telnet user initiates a connection request and sends the username and password to the
device. The device will act as the LDAP client during authorization.
2. After receiving the request, the device exchanges authentication packets with the
authentication server for the user:
 If LDAP authentication is used, see the authentication process shown in Figure 7.
− If the device (the LDAP client) uses the same LDAP server for authentication and
authorization, skip to step 6.
− If the device (the LDAP client) uses different LDAP servers for authentication and
authorization, skip to step 4.
 If another authentication method is used, the authentication process of that method applies.
The device acts as the LDAP client. Skip to step 3.
3. The LDAP client establishes a TCP connection with the LDAP authorization server.
4. To obtain the right to search, the LDAP client uses the administrator DN and password to send
an administrator bind request to the LDAP server.
5. The LDAP server processes the request. If the bind operation is successful, the LDAP server
sends an acknowledgment to the LDAP client.

10
 6. The LDAP client sends an authorization search request with the username of the Telnet user to
the LDAP server. If the user uses the same LDAP server for authentication and authorization,
the client sends the request with the saved user DN of the Telnet user to the LDAP server.
7. After receiving the request, the LDAP server searches for the user information by the base DN,
search scope, filtering conditions, and LDAP attributes. If a match is found, the LDAP server
sends a response to notify the LDAP client of the successful search.
8. After successful authorization, the LDAP client notifies the user of the successful login.

User management based on ISP domains and user access

types
AAA manages users based on the users' ISP domains and access types.
On a NAS, each user belongs to one ISP domain. The NAS determines the ISP domain to which a
user belongs based on the username entered by the user at login.
Figure 9 Determining the ISP domain for a user by username

NAS

A user enters the

username in the form Username contains Yes The user belongs to
userid@domain-name @domain-name? domain domain-name.
or userid

No

The user belongs to the

default domain.

AAA manages 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 or MAC authentication to come online.
• Login—Login users include SSH, Telnet, FTP, and terminal users that log in to the device.
Terminal users can access through a console port.
• Portal—Portal users must pass portal authentication to access the network.
• HTTP/HTTPS—Users log in to the device through HTTP or HTTPS.
The device also provides authentication modules (such as 802.1X) for implementation of user
authentication management policies. If you configure these authentication modules, the ISP
domains for users of the access types depend on the configuration of the authentication modules.

Authentication, authorization, and accounting methods

AAA supports configuring different authentication, authorization, and accounting methods for
different types of users in an ISP domain. The NAS determines the ISP domain and access type of a
user. The NAS also uses the methods configured for the access type in the domain to control the
user's access.
AAA also supports configuring a set of default methods for an ISP domain. These default methods
are applied to users for whom no AAA methods are configured.
Authentication methods
The device supports the following authentication methods:

11
 • No authentication—This method trusts all users and does not perform authentication. For
security purposes, do not use this method.
• Local authentication—The NAS 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 NAS works with a remote server to authenticate users. The NAS
communicates with the remote server through the RADIUS, LDAP, or HWTACACS protocol.
The server manages user information in a centralized manner. Remote authentication provides
high capacity, reliable, and centralized authentication services for multiple NASs. You can
configure backup methods to be used when the remote server is not available.
Authorization methods
The device supports the following authorization methods:
• No authorization—The NAS performs no authorization exchange. The following default
authorization information applies after users pass authentication:
 Login users obtain the level-0 user role. For more information about the level-0 user role,
see RBAC configuration in Fundamentals Configuration Guide.
 The working directory for FTP, SFTP, and SCP login users is the root directory of the NAS.
However, the users do not have permission to access the root directory.
 Non-login users can access the network.
• Local authorization—The NAS performs authorization according to the user attributes locally
configured for users.
• Remote authorization—The NAS works with a remote server to authorize users. RADIUS
authorization is bound with RADIUS authentication. RADIUS authorization can work only after
RADIUS authentication is successful, and the authorization information is included in the
Access-Accept packet. HWTACACS or LDAP authorization is separate from 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.
Accounting methods
The device supports the following accounting methods:
• No accounting—The NAS does not perform accounting for the users.
• Local accounting—Local accounting is implemented on the NAS. It counts and controls the
number of concurrent users that use the same local user account, but does not provide
statistics for charging.
• Remote accounting—The NAS works with a RADIUS server or HWTACACS server for
accounting. You can configure backup methods to be used when the remote server is not
available.

AAA extended functions

The device provides the following login services to enhance device security:
• Command authorization—Enables the NAS to let the authorization server determine whether
a command entered by a login user is permitted. Login users can execute only commands
permitted by the authorization server. For more information about command authorization, see
Fundamentals Configuration Guide.
• Command accounting—When command authorization is disabled, command accounting
enables the accounting server to record all valid commands executed on the device. When
command authorization is enabled, command accounting enables the accounting server to
record all authorized commands. For more information about command accounting, see
Fundamentals Configuration Guide.

12
 • User role authentication—Authenticates each user that wants to obtain another user role
without logging out or getting disconnected. For more information about user role authentication,
see Fundamentals Configuration Guide.

AAA for VPNs

You can deploy AAA across VPNs to enable forwarding of authentication, authorization, and
accounting packets across VPNs. For example, as shown in Figure 10, The MCE at the left side of
the MPLS backbone acts as a NAS. The NAS transparently delivers the AAA packets of private
users in VPN 1 and VPN 2 to the AAA servers in VPN 3 for centralized authentication. Authentication
packets of private users in different VPNs do not affect each other.
Figure 10 Network diagram

VPN 1
VPN 3
MPLS backbone
MCE RADIUS
Host server
PE
PE
P CE
VPN 2

HWTACACS
server
Host

This feature can also help an MCE to implement portal authentication for VPNs. For more
information about MCE, see MCE Configuration Guide. For more information about portal
authentication, see "Configuring portal authentication."

RADIUS server feature of the device

Enable the RADIUS server feature of the device to work with RADIUS clients for user authentication
and authorization. The device can act as a dedicated RADIUS server or as both a RADIUS server
and a RADIUS client at the same time.
The RADIUS server feature provides for flexible networks with less cost. As shown in Figure 11,
Device A provides RADIUS server functions at the distribution layer; Device B and Device C are
configured with RADIUS schemes to implement user authentication and authorization at the access
layer.

13
 Figure 11 Network diagram

IP network

RADIUS server
Device A

Device B Device C

The RADIUS server feature supports the following operations:

• Manages RADIUS user data, which is generated from local user information and includes user
name, password, description, authorization ACL, authorization VLAN, and expiration time.
• Manages RADIUS clients. You can add, modify, and delete RADIUS clients. A RADIUS client is
identified by the IP address, and it includes attribute information such as the shared key. The
RADIUS server feature processes authentication requests only from the managed RADIUS
clients and ignores requests from unknown clients.
• Authenticates and authorizes users of the network access type. The server does not provide
accounting.
When the RADIUS server receives a RADIUS packet, it performs the following actions:
1. Verifies that the packet is sent from a managed RADIUS client.
2. Verifies the packet with the shared key.
3. Verifies that the user account exists, the password is correct, and other attributes meet the
requirements (for example, the account is in the validity period).
4. Determines the authentication result and authorizes specific privileges to the authenticated
user.
The RADIUS server feature of the device has the following restrictions:
• The authentication port is fixed at UDP 1812 and cannot be modified.
• The feature is supported on IPv4 networks, but not on IPv6 networks.
• The server provides only PAP and CHAP authentication methods.
• User names sent to the RADIUS server cannot include a domain name.

Protocols and standards

• RFC 2865, Remote Authentication Dial In User Service (RADIUS)
• RFC 2866, RADIUS Accounting
• RFC 2867, RADIUS Accounting Modifications for Tunnel Protocol Support
• RFC 2868, RADIUS Attributes for Tunnel Protocol Support
• RFC 2869, RADIUS Extensions
• RFC 3576, Dynamic Authorization Extensions to Remote Authentication Dial In User Service
(RADIUS)
• RFC 4818, RADIUS Delegated-IPv6-Prefix Attribute

14
 • RFC 5176, Dynamic Authorization Extensions to Remote Authentication Dial In User Service
(RADIUS)
• RFC 1492, An Access Control Protocol, Sometimes Called TACACS
• RFC 1777, Lightweight Directory Access Protocol
• RFC 2251, Lightweight Directory Access Protocol (v3)

FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for
features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and
non-FIPS mode.

AAA tasks at a glance

To configure AAA, perform the following tasks:
1. Configuring AAA schemes
If local authentication is used, configure local users and the related attributes. If remote
authentication is used, configure the required RADIUS, LDAP, or HWTACACS schemes.
 Configuring local users
 Configuring RADIUS
 Configuring HWTACACS
 Configuring LDAP
2. Configuring an ISP domain
a. Creating an ISP domain
b. Configuring ISP domain attributes
3. Configuring AAA methods for an ISP domain
Configure authentication, authorization, and accounting methods for an ISP domain as needed.
These methods use existing AAA schemes.
 Configuring authentication methods for an ISP domain
 Configuring authorization methods for an ISP domain
 Configuring accounting methods for an ISP domain
4. (Optional.) Configuring advanced AAA features
 Setting the maximum number of concurrent login users
 Configuring a NAS-ID
 Configuring the device ID
 Enabling password change prompt logging
 Configuring the RADIUS server feature
 Configuring the connection recording policy
 Configuring the AAA test feature

15
Configuring local users
About local users
To implement local authentication, authorization, and accounting, create local users and configure
user attributes on the device. The local users and attributes are stored in the local user database on
the device. A local user is uniquely identified by the combination of a username and a user type.
Local users are classified into the following types:
• Device management user—User that logs in to the device for device management.
• Network access user—User that accesses network resources through the device.
The following shows the configurable local user attributes:
• Description—Descriptive information of the user.
• Service type—Services that the user can use. Local authentication checks the service types of
a local user. If none of the service types is available, the user cannot pass authentication.
• User state—Whether or not a local user can request network services. There are two user
states: active and blocked. A user in active state can request network services, but a user in
blocked state cannot.
• Upper limit of concurrent logins using the same user name—Maximum number of users
that can concurrently access the device by using the same user name. When the number
reaches the upper limit, no more local users can access the device by using the user name.
• User group—Each local user belongs to a local user group and has all attributes of the group.
The attributes include the password control attributes and authorization attributes. For more
information about local user group, see "Configuring user group attributes."
• Binding attributes—Binding attributes control the scope of users, and are checked during
local authentication of a user. If the attributes of a user do not match the binding attributes
configured for the local user account, the user cannot pass authentication.
• Authorization attributes—Authorization attributes indicate the user's rights after it passes
local authentication.
Configure the authorization attributes based on the service type of local users.
You can configure an authorization attribute in user group view or local user view. The setting of
an authorization attribute in local user view takes precedence over the attribute setting in user
group view.
The attribute configured in user group view takes effect on all local users in the user group.
The attribute configured in local user view takes effect only on the local user.
• Password control attributes—Password control attributes help control password security for
local users. Password control attributes include password aging time, minimum password
length, password composition checking, password complexity checking, and login attempt limit.
You can configure a password control attribute in system view, user group view, or local user
view. A password control attribute with a smaller effective range has a higher priority. For more
information about password management and global password configuration, see "Configuring
password control."
• Validity period—Time period in which a network access user is considered valid for
authentication.

Local user configuration tasks at a glance

To configure local users, perform the following tasks:
1. Configuring local user attributes

16
  Configuring attributes for device management users
 Configuring attributes for network access users
2. (Optional.) Configuring user group attributes
3. (Optional.) Configuring the local user auto-delete feature

Configuring attributes for device management users

Restrictions and guidelines
When you configure the interface binding attribute for a device management user, follow these
restrictions and guidelines to avoid authentication failure:
• Specify the actual access interface of the user as the binding interface for the user.
• Make sure the user's authentication packets include the user's access interface.
If password control is globally enabled for device management users by using the
password-control enable command, the device neither displays local user passwords nor
retains them in the running configuration. When you globally disable password control for device
management users, local user passwords are automatically restored to the running configuration. To
display the running configuration, use the display current-configuration command.
You can configure authorization attributes and password control attributes in local user view or user
group view. The setting in local user view takes precedence over the setting in user group view.
Procedure
1. Enter system view.
system-view
2. Add a device management user and enter device management user view.
local-user user-name class manage
3. Configure a password for the device management user.
In non-FIPS mode:
password [ { hash | simple } string ]
A non-password-protected user passes authentication if the user provides the correct
username and passes attribute checks. To enhance security, configure a password for each
device management user.
In FIPS mode:
password
Only password-protected users can pass authentication. You must set the password in
interactive mode for a device management user.
4. Assign services to the device management user.
In non-FIPS mode:
service-type { ftp | { http | https | ssh | telnet | terminal } * }
In FIPS mode:
service-type { https | ssh | terminal } *
By default, no services are authorized to a device management user.
5. (Optional.) Set the status of the device management user.
state { active | block }
By default, a device management user is in active state and can request network services.
6. (Optional.) Set the upper limit of concurrent logins using the device management username.
access-limit max-user-number

17
 By default, the number of concurrent logins is not limited for a device management user.
This command takes effect only when local accounting is configured for device management
users. This command does not apply to FTP, SFTP, or SCP users that do not support
accounting.
7. (Optional.) Configure the interface binding attribute for the device management user.
bind-attribute location interface interface-type interface-number
By default, no interface binding attribute is configured for a device management user.
8. (Optional.) Configure authorization attributes for the device management user.
authorization-attribute { idle-cut minutes | user-role role-name |
work-directory directory-name } *
The following default settings apply:
 The working directory for FTP, SFTP, and SCP users is the root directory of the NAS.
However, the users do not have permission to access the root directory.
 The network-operator user role is assigned to local users that are created by a
network-admin or level-15 user.
9. (Optional.) Configure password control attributes for the device management user. Choose the
following tasks as needed:
 Set the password aging time.
password-control aging aging-time
 Set the minimum password length.
password-control length length
 Configure the password composition policy.
password-control composition type-number type-number [ type-length
type-length ]
 Configure the password complexity checking policy.
password-control complexity { same-character | user-name } check
 Configure the maximum login attempts and the action to take if there is a login failure.
password-control login-attempt login-times [ exceed { lock |
lock-time time | unlock } ]
By default, a device management user uses password control attributes of the user group to
which the user belongs.
10. (Optional.) Assign the device management user to a user group.
group group-name
By default, a device management user belongs to user group system.

Configuring attributes for network access users

Restrictions and guidelines
If password control is globally enabled for network access users by using the password-control
enable network-class command, the device neither displays local user passwords nor retains
them in the running configuration. When you globally disable password control for network access
users, local user passwords are automatically restored to the running configuration. To display the
running configuration, use the display current-configuration command.
You can configure authorization attributes and password control attributes in local user view or user
group view. The setting in local user view takes precedence over the setting in user group view.
Configure the location binding attribute based on the service types of users.

18
 • For 802.1X users, specify the 802.1X-enabled Layer 2 Ethernet interfaces or Layer 2 aggregate
interfaces through which the users access the device.
• For MAC authentication users, specify the MAC authentication-enabled Layer 2 Ethernet
interfaces or Layer 2 aggregate interfaces through which the users access the device.
• For Web authentication users, specify the Web authentication-enabled Layer 2 Ethernet
interfaces through which the users access the device.
• For portal users, specify the portal-enabled interfaces through which the users access the
device. Specify the Layer 2 Ethernet interfaces if portal is enabled on VLAN interfaces and the
portal roaming enable command is not used.
Procedure
1. Enter system view.
system-view
2. Add a network access user and enter network access user view.
local-user user-name class network
3. (Optional.) Configure a password for the network access user.
password { cipher | simple } string
4. (Optional.) Configure a description for the network access user.
description text
By default, no description is configured for a local user.
5. Assign services to the network access user.
service-type { lan-access | portal }
By default, no services are authorized to a network access user.
6. (Optional.) Set the status of the network access user.
state { active | block }
By default, a network access user is in active state and can request network services.
7. (Optional.) Set the upper limit of concurrent logins using the network access username.
access-limit max-user-number
By default, the number of concurrent logins is not limited for a network access user.
8. (Optional.) Configure binding attributes for the network access user.
bind-attribute { ip ip-address | location interface interface-type
interface-number | mac mac-address | vlan vlan-id } *
By default, no binding attributes are configured for a network access user.
9. (Optional.) Configure authorization attributes for the network access user.
authorization-attribute { acl acl-number | idle-cut minutes | ip-pool
ipv4-pool-name | ipv6-pool ipv6-pool-name | session-timeout minutes |
user-profile profile-name | vlan vlan-id } *
By default, a network access user does not have authorization attributes.
10. (Optional.) Configure password control attributes for the network access user. Choose the
following tasks as needed:
 Set the minimum password length.
password-control length length
 Configure the password composition policy.
password-control composition type-number type-number [ type-length
type-length ]
 Configure the password complexity checking policy.

19
 password-control complexity { same-character | user-name } check
By default, a network access user uses password control attributes of the user group to which
the user belongs.
11. (Optional.) Assign the network access user to a user group.
group group-name
By default, a network access user belongs to user group system.
12. (Optional.) specify the validity period for the local user.
validity-datetime { from start-date start-time to expiration-date
expiration-time | from start-date start-time | to expiration-date
expiration-time }
By default, the validity period for a network access user does not expire.

Configuring user group attributes

About this task
User groups simplify local user configuration and management. A user group contains a group of
local users and has a set of local user attributes. You can configure local user attributes for a user
group to implement centralized user attributes management for the local users in the group. Local
user attributes that are manageable include authorization attributes.
Procedure
1. Enter system view.
system-view
2. Create a user group and enter user group view.
user-group group-name
By default, a system-defined user group exists. The group name is system.
3. Configure authorization attributes for the user group.
authorization-attribute { acl acl-number | idle-cut minutes | ip-pool
ipv4-pool-name | ipv6-pool ipv6-pool-name | session-timeout minutes |
user-profile profile-name | vlan vlan-id | work-directory
directory-name } *
By default, no authorization attributes are configured for a user group.
4. (Optional.) Configure password control attributes for the user group. Choose the following tasks
as needed:
 Set the password aging time.
password-control aging aging-time
 Set the minimum password length.
password-control length length
 Configure the password composition policy.
password-control composition type-number type-number [ type-length
type-length ]
 Configure the password complexity checking policy.
password-control complexity { same-character | user-name } check
 Configure the maximum login attempts and the action to take for login failures.
password-control login-attempt login-times [ exceed { lock |
lock-time time | unlock } ]
By default, a user group uses the global password control settings. For more information, see
"Configuring password control."

20
Configuring the local user auto-delete feature
About this task
This feature enables the device to examine the validity of local users at fixed time periods of 10
minutes and automatically delete expired local users.
Procedure
1. Enter system view
system-view
2. Enable the local user auto-delete feature.
local-user auto-delete enable
By default, the local user auto-delete feature is disabled.

Display and maintenance commands for local users and local

user groups
Execute display commands in any view.

Task Command
display local-user [ class { manage | network }
| idle-cut { disable | enable } | service-type
Display the local user { ftp | http | https | lan-access | portal | ssh |
configuration and online user
statistics.
telnet | terminal } | state { active | block } |
user-name user-name class { manage | network } |
vlan vlan-id ]
Display user group
display user-group { all | name group-name }
configuration.

Configuring RADIUS
RADIUS tasks at a glance
To configure RADIUS, perform the following tasks:
1. Configuring an EAP profile
To perform EAP-based RADIUS server status detection, you must configure an EAP profile and
specify the EAP profile in a test profile.
2. Configuring a test profile for RADIUS server status detection
To detect the status of a RADIUS server, you must configure a test profile and configure the
RADIUS server to use the test profile in a RADIUS scheme.
3. Creating a RADIUS scheme
4. Specifying RADIUS authentication servers
5. Specifying the RADIUS accounting servers
6. Specifying the shared keys for secure RADIUS communication
Perform this task if no shared keys are specified when configuring RADIUS authentication or
accounting servers.
7. Specifying the MPLS L3VPN instance for a RADIUS scheme

21
 Perform this task if no MPLS L3VPN instances are specified when configuring RADIUS
authentication or accounting servers.
8. (Optional.) Setting the status of RADIUS servers
9. (Optional.) Setting RADIUS timers
10. (Optional.) Configuring parameters for RADIUS packets
 Specifying the source IP address for outgoing RADIUS packets
 Setting the username format and traffic statistics units
 Setting the maximum number of RADIUS request transmission attempts
 Setting the maximum number of real-time accounting attempts
 Setting the DSCP priority for RADIUS packets
11. (Optional.) Configuring parameters for RADIUS attributes
 Configuring the Login-Service attribute check method for SSH, FTP, and terminal users
 Interpreting the RADIUS class attribute as CAR parameters
 Configuring the format of the RADIUS Called-Station-Id attribute
 Configuring the MAC address format for the RADIUS Called-Station-Id attribute
 Configuring the MAC address format for the RADIUS Calling-Station-Id attribute
 Setting the data measurement unit for the Remanent_Volume attribute
 Including subattribute 218 of vendor 25506 in outgoing RADIUS packets
 Configuring the RADIUS attribute translation feature
12. (Optional.) Configuring extended RADIUS features
 Configuring RADIUS stop-accounting packet buffering
 Enabling forcibly sending stop-accounting packets
 Enabling the RADIUS server load sharing feature
 Specifying a RADIUS server selection mode for reauthentication
 Configuring the RADIUS accounting-on feature
 Configuring the RADIUS session-control feature
 Configuring the RADIUS DAS feature
 Enabling SNMP notifications for RADIUS
 Disabling the RADIUS service

Restrictions and guidelines for RADIUS configuration

If the authentication server in a RADIUS scheme is provided by the RADIUS server feature on the
device, you need to configure only the following items for the RADIUS scheme:
• RADIUS authentication server.
• Shared key for RADIUS communication.
• Username format for interaction with the RADIUS server.

Configuring an EAP profile

About this task
An EAP profile is a collection of EAP authentication settings, including the EAP authentication
method and the CA certificate file to be used for some EAP authentication methods.
Restrictions and guidelines
You can specify an EAP profile in multiple test profiles.

22
 You can configure a maximum of 16 EAP profiles.
Prerequisites
Before you specify a CA certificate file, use FTP or TFTP to transfer the CA certificate file to the root
directory of the default storage medium on the device.
In an IRF fabric, make sure the CA certificate file exists in the root directory of the default storage
medium on the master device before you specify the file.
Procedure
1. Enter system view.
system-view
2. Create an EAP profile and enter EAP profile view.
eap-profile eap-profile-name
3. Specify the EAP authentication method.
method { md5 | peap-gtc | peap-mschapv2 | ttls-gtc | ttls-mschapv2 }
By default, the EAP authentication method is MD5-challenge.
4. Specify a CA certificate file for EAP authentication.
ca-file file-name
By default, no CA certificate file is specified for EAP authentication.
You must specify a CA certificate file to verify the RADIUS server certificate if the EAP
authentication method is PEAP-GTC, PEAP-MSCHAPv2, TTLS-GTC, or TTLS-MSCHAPv2.

Configuring a test profile for RADIUS server status detection

About this task
To detect the reachability or availability of a RADIUS authentication server, specify a test profile for
the RADIUS server when you specify the server in a RADIUS scheme. With the test profile, the
device refreshes the RADIUS server status at each detection interval according to the detection
result. If the server is unreachable or unavailable, the device sets the status of the server to blocked.
If the server is reachable or available, the device sets the status of the server to active.
The device supports the following RADIUS server status detection methods:
• Simple detection—For a RADIUS server, the device simulates an authentication request with
the username and password specified in the test profile used by the server. The authentication
request is sent to the RADIUS server within each detection interval. The device determines that
the RADIUS server is reachable if the device receives a response from the server within the
interval.
• EAP-based detection—For a RADIUS server, the device simulates an EAP authentication
with the username and password specified in the test profile used by the server. The simulated
EAP authentication starts at the beginning of each detection interval. If the EAP authentication
completes within a detection interval, the device determines that the RADIUS server is
available.
Simulating a complete EAP authentication process, EAP-based detection provides more reliable
detection results than simple detection. As a best practice, configure EAP-based detection on a
network environment where EAP authentication is configured.
Restrictions and guidelines
You can configure multiple test profiles in the system.
The device starts detecting the status of a RADIUS authentication server only if an existing test
profile is specified for the server.

23
 If you specify a nonexistent EAP profile in a test profile, the device performs simple detection for the
RADIUS servers that use the test profile. After the EAP profile is configured, the device will start
EAP-based detection at the next detection interval.
The device stops detecting the status of a RADIUS server when one of the following operations is
performed:
• The RADIUS server is removed from the RADIUS scheme.
• The test profile configuration for the RADIUS server is removed in RADIUS scheme view.
• The test profile specified for the RADIUS server is deleted.
• The RADIUS server is manually set to the blocked state.
• The RADIUS scheme that contains the RADIUS server is deleted.
Procedure
1. Enter system view.
system-view
2. Configure a test profile for detecting the status of RADIUS authentication servers.
radius-server test-profile profile-name username name [ password
{ cipher | simple } string ] [ interval interval ] [ eap-profile
eap-profile-name ]

Creating a RADIUS scheme

Restrictions and guidelines
You can configure a maximum of 16 RADIUS schemes. A RADIUS scheme can be used by multiple
ISP domains.
Procedure
1. Enter system view.
system-view
2. Create a RADIUS scheme and enter RADIUS scheme view.
radius scheme radius-scheme-name

Specifying RADIUS authentication servers

About this task
A RADIUS authentication server completes authentication and authorization together, because
authorization information is piggybacked in authentication responses sent to RADIUS clients.
You can specify one primary authentication server and a maximum of 16 secondary authentication
servers for a RADIUS scheme. Secondary servers provide AAA services when the primary server
becomes unreachable. The device searches for an active server in the order the secondary servers
are configured.
When RADIUS server load sharing is enabled, the device distributes the workload over all servers
without considering the primary and secondary server roles. The device checks the weight value and
number of currently served users for each active server, and then determines the most appropriate
server in performance to receive an authentication request.
Restrictions and guidelines
If redundancy is not required, specify only the primary server.
A RADIUS authentication server can function as the primary authentication server for one scheme
and a secondary authentication server for another scheme at the same time.

24
 Two authentication servers in a scheme, primary or secondary, cannot have the same combination
of VPN instance, host name, IP address, and port number.
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Specify the primary RADIUS authentication server.
primary authentication { host-name | ipv4-address | ipv6 ipv6-address }
[ port-number | key { cipher | simple } string | test-profile
profile-name | vpn-instance vpn-instance-name | weight weight-value ]
*
By default, no primary RADIUS authentication server is specified.
The weight keyword takes effect only when the RADIUS server load sharing feature is
enabled for the RADIUS scheme.
4. (Optional.) Specify a secondary RADIUS authentication server.
secondary authentication { host-name | ipv4-address | ipv6
ipv6-address } [ port-number | key { cipher | simple } string |
test-profile profile-name | vpn-instance vpn-instance-name | weight
weight-value ] *
By default, no secondary RADIUS authentication servers are specified.
The weight keyword takes effect only when the RADIUS server load sharing feature is
enabled for the RADIUS scheme.

Specifying the RADIUS accounting servers

About this task
You can specify one primary accounting server and a maximum of 16 secondary accounting servers
for a RADIUS scheme. Secondary servers provide AAA services when the primary server becomes
unavailable. The device searches for an active server in the order the secondary servers are
configured.
When RADIUS server load sharing is enabled, the device distributes the workload over all servers
without considering the primary and secondary server roles. The device checks the weight value and
number of currently served users for each active server, and then determines the most appropriate
server in performance to receive an accounting request.
Restrictions and guidelines
If redundancy is not required, specify only the primary server.
A RADIUS accounting server can function as the primary accounting server for one scheme and a
secondary accounting server for another scheme at the same time.
Two accounting servers in a scheme, primary or secondary, cannot have the same combination of
VPN instance, host name, IP address, and port number.
RADIUS does not support accounting for FTP, SFTP, and SCP users.
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.

25
 radius scheme radius-scheme-name
3. Specify the primary RADIUS accounting server.
primary accounting { host-name | ipv4-address | ipv6 ipv6-address }
[ port-number | key { cipher | simple } string | vpn-instance
vpn-instance-name | weight weight-value ] *
By default, no primary RADIUS accounting server is specified.
The weight keyword takes effect only when the RADIUS server load sharing feature is
enabled for the RADIUS scheme.
4. (Optional.) Specify a secondary RADIUS accounting server.
secondary accounting { host-name | ipv4-address | ipv6 ipv6-address }
[ port-number | key { cipher | simple } string | vpn-instance
vpn-instance-name | weight weight-value ] *
By default, no secondary RADIUS accounting servers are specified.
The weight keyword takes effect only when the RADIUS server load sharing feature is
enabled for the RADIUS scheme.

Specifying the shared keys for secure RADIUS

communication
About this task
The RADIUS client and server use the MD5 algorithm and shared keys to generate the Authenticator
value for packet authentication and user password encryption. The client and server must use the
same key for each type of communication.
A key configured in this task is for all servers of the same type (accounting or authentication) in the
scheme. The key has a lower priority than a key configured individually for a RADIUS server.
Restrictions and guidelines
The shared key configured on the device must be the same as the shared key configured on the
RADIUS server.
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Specify a shared key for secure RADIUS communication.
key { accounting | authentication } { cipher | simple } string
By default, no shared key is specified for secure RADIUS communication.

Specifying the MPLS L3VPN instance for a RADIUS scheme

About this task
The VPN instance specified for a RADIUS scheme applies to all authentication and accounting
servers in that scheme. If a VPN instance is also configured for an individual RADIUS server, the
VPN instance specified for the RADIUS scheme does not take effect on that server.
Procedure
1. Enter system view.
system-view

26
 2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Specify a VPN instance for the RADIUS scheme.
vpn-instance vpn-instance-name
By default, a RADIUS scheme belongs to the public network.

Setting the status of RADIUS servers

About this task
To control the RADIUS servers with which the device communicates when the current servers are no
longer available, set the status of RADIUS servers to blocked or active. You can specify one primary
RADIUS server and multiple secondary RADIUS servers. The secondary servers function as the
backup of the primary server. When the RADIUS server load sharing feature is disabled, the device
chooses servers based on the following rules:
• When the primary server is in active state, the device first tries to communicate with the primary
server. If the primary server is unreachable, the device searches for an active secondary server
in the order the servers are configured.
• When one or more servers are in active state, the device tries to communicate with these active
servers only, even if the servers are unavailable.
• When all servers are in blocked state, the device only tries to communicate with the primary
server.
• If a server is unreachable, the device performs the following operations:
 Changes the server status to blocked.
 Starts a quiet timer for the server.
 Tries to communicate with the next secondary server in active state that has the highest
priority.
• When the quiet timer of a server expires or you manually set the server to the active state, the
status of the server changes back to active. The device does not check the server again during
the authentication or accounting process.
• The search process continues until the device finds an available secondary server or has
checked all secondary servers in active state. If no server is reachable, the device considers the
authentication or accounting attempt a failure.
• When you remove a server in use, communication with the server times out. The device looks
for a server in active state by first checking the primary server, and then checking secondary
servers in the order they are configured.
• When a RADIUS server's status changes automatically, the device changes this server's status
accordingly in all RADIUS schemes in which this server is specified.
• When a RADIUS server is manually set to blocked, server detection is disabled for the server,
regardless of whether a test profile has been specified for the server. When the RADIUS server
is set to active state, server detection is enabled for the server on which an existing test profile
is specified.
By default, the device sets the status of all RADIUS servers to active. However, in some situations,
you must change the status of a server. For example, if a server fails, you can change the status of
the server to blocked to avoid communication attempts to the server.
Restrictions and guidelines
The configured server status cannot be saved to any configuration file, and can only be viewed by
using the display radius scheme command.
After the device restarts, all servers are restored to the active state.

27
 The device selects a reachable server for the authentication or accounting of a new user according
to the server selection rules in this section if the RADIUS server load sharing feature is disabled.
However, these rules are inapplicable to the reauthentication of online users if the RADIUS server
selection mode for reauthentication is set to inherit by using the reauthentication
server-select inherit command.
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Set the RADIUS server status. Choose the following tasks as needed:
 Set the status of the primary RADIUS authentication server.
state primary authentication { active | block }
 Set the status of the primary RADIUS accounting server.
state primary accounting { active | block }
 Set the status of a secondary RADIUS authentication server.
state secondary authentication [ { host-name | ipv4-address | ipv6
ipv6-address } [ port-number | vpn-instance vpn-instance-name ] * ]
{ active | block }
 Set the status of a secondary RADIUS accounting server.
state secondary accounting [ { host-name | ipv4-address | ipv6
ipv6-address } [ port-number | vpn-instance vpn-instance-name ] * ]
{ active | block }
By default, a RADIUS server is in active state.

Setting RADIUS timers

About this task
The device uses the following types of timers to control communication with a RADIUS server:
• Server response timeout timer (response-timeout)—Defines the RADIUS request
retransmission interval. The timer starts immediately after a RADIUS request is sent. If the
device does not receive a response from the RADIUS server before the timer expires, it
resends the request.
• Server quiet timer (quiet)—Defines the duration to keep an unreachable server in blocked
state. If one server is not reachable, the device changes the server status to blocked, starts this
timer for the server, and tries to communicate with another server in active state. After the
server quiet timer expires, the device changes the status of the server back to active.
• Real-time accounting timer (realtime-accounting)—Defines the interval at which the device
sends real-time accounting packets to the RADIUS accounting server for online users.
Restrictions and guidelines
Consider the number of secondary servers when you configure the maximum number of RADIUS
packet transmission attempts and the RADIUS server response timeout timer. If the RADIUS
scheme includes many secondary servers, the retransmission process might be too long and the
client connection in the access module, such as Telnet, can time out.
When the client connections have a short timeout period, a large number of secondary servers can
cause the initial authentication or accounting attempt to fail. In this case, reconnect the client rather
than adjusting the RADIUS packet transmission attempts and server response timeout timer.

28
 Typically, the next attempt will succeed, because the device has blocked the unreachable servers to
shorten the time to find a reachable server.
Make sure the server quiet timer is set correctly. A timer that is too short might result in frequent
authentication or accounting failures. This is because the device will continue to attempt to
communicate with an unreachable server that is in active state. A timer that is too long might
temporarily block a reachable server that has recovered from a failure. This is because the server will
remain in blocked state until the timer expires.
A short real-time accounting interval helps improve accounting precision but requires many system
resources. When there are 1000 or more users, set the interval to 15 minutes or longer.
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Set RADIUS timers. Choose the following tasks as needed:
 Set the RADIUS server response timeout timer.
timer response-timeout seconds
The default setting is 3 seconds.
 Set the quiet timer for the servers.
timer quiet minutes
The default setting is 5 minutes.
 Set the real-time accounting timer.
timer realtime-accounting interval [ second ]
The default setting is 12 minutes.

Specifying the source IP address for outgoing RADIUS

packets
About this task
The source IP address of RADIUS packets that a NAS sends must match the IP address of the NAS
configured on the RADIUS server. A RADIUS server identifies a NAS by its IP address. Upon
receiving a RADIUS packet, the RADIUS server checks the source IP address of the packet.
• If it is the IP address of a managed NAS, the server processes the packet.
• If it is not the IP address of a managed NAS, the server drops the packet.
Before sending a RADIUS packet, the NAS selects a source IP address in the following order:
1. The source IP address specified for the RADIUS scheme.
2. The source IP address specified in system view for the VPN or public network, depending on
where the RADIUS server resides.
3. The IP address of the outbound interface specified by the route.
Restrictions and guidelines for source IP address configuration
You can specify a source IP address for outgoing RADIUS packets in RADIUS scheme view or in
system view.
• The IP address specified in RADIUS scheme view applies only to one RADIUS scheme.
• The IP address specified in system view applies to all RADIUS schemes.

29
 The source IP address of RADIUS packets that a NAS sends must match the IP address of the NAS
that is configured on the RADIUS server.
As a best practice, specify a loopback interface address as the source IP address for outgoing
RADIUS packets to avoid RADIUS packet loss caused by physical port errors.
The source address of outgoing RADIUS packets is typically the IP address of an egress interface on
the NAS to communicate with the RADIUS server. However, in some situations, you must change
the source IP address. For example, when VRRP is configured for stateful failover, configure the
virtual IP of the uplink VRRP group as the source address.
You can directly specify a source IP address for outgoing RADIUS packets or specify a source
interface to provide the source IP address for outgoing RADIUS packets. The source interface
configuration and the source IP address configuration overwrite each other.
Specifying a source interface or source IP address for all RADIUS schemes
1. Enter system view.
system-view
2. Specify a source interface or source IP address for outgoing RADIUS packets.
radius nas-ip { interface interface-type interface-number |
{ ipv4-address | ipv6 ipv6-address } [ vpn-instance
vpn-instance-name ] }
By default, the source IP address of an outgoing RADIUS packet is the primary IPv4 address or
the IPv6 address of the outbound interface.
Specifying a source interface or source IP address for a RADIUS scheme
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Specify a source interface or source IP address for outgoing RADIUS packets.
nas-ip { ipv4-address | interface interface-type interface-number |
ipv6 ipv6-address }
By default, the source IP address of an outgoing RADIUS packet is that specified by using the
radius nas-ip command in system view. If the radius nas-ip command is not used, the
source IP address is the primary IP address of the outbound interface.

Setting the username format and traffic statistics units

About this task
A username is in the userid@isp-name format, where the isp-name part represents the user's ISP
domain name. By default, the ISP domain name is included in a username. However, older RADIUS
servers might not recognize usernames that contain the ISP domain names. In this case, you can
configure the device to remove the domain name of each username to be sent.
The device reports online user traffic statistics in accounting packets. The traffic measurement units
are configurable.
Restrictions and guidelines
If two or more ISP domains use the same RADIUS scheme, configure the RADIUS scheme to keep
the ISP domain name in usernames for domain identification.
For accounting accuracy, make sure the traffic statistics units configured on the device and on the
RADIUS accounting servers are the same.

30
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Set the format for usernames sent to the RADIUS servers.
user-name-format { keep-original | with-domain | without-domain }
By default, the ISP domain name is included in a username.
If the device is specified as the RADIUS server in the scheme, the username format must be set
to without-domain.
4. Set the data flow and packet measurement units for traffic statistics.
data-flow-format { data { byte | giga-byte | kilo-byte | mega-byte }
| packet { giga-packet | kilo-packet | mega-packet | one-packet } }*
By default, traffic is counted in bytes and packets.

Setting the maximum number of RADIUS request

transmission attempts
About this task
RADIUS uses UDP packets to transfer data. Because UDP communication is not reliable, RADIUS
uses a retransmission mechanism to improve reliability. A RADIUS request is retransmitted if the
NAS does not receive a server response for the request within the response timeout timer. For more
information about the RADIUS server response timeout timer, see "Setting the status of RADIUS
servers."
You can set the maximum number for the NAS to retransmit a RADIUS request to the same server.
When the maximum number is reached, the NAS tries to communicate with other RADIUS servers in
active state. If no other servers are in active state at the time, the NAS considers the authentication
or accounting attempt a failure.
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Set the maximum number of RADIUS request transmission attempts.
retry retries
By default, the maximum number is 3 for RADIUS request transmission attempts.

Setting the maximum number of real-time accounting

attempts
About this task
If you set the maximum number of real-time accounting attempts, the device will disconnect users
from whom no accounting responses are received within the permitted attempts.
Procedure
1. Enter system view.

31
 system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Set the maximum number of real-time accounting attempts.
retry realtime-accounting retries
By default, the maximum number is 5 for real-time accounting attempts.

Setting the DSCP priority for RADIUS packets

About this task
The DSCP priority in the ToS field determines the transmission priority of RADIUS packets. A larger
value represents a higher priority.
Procedure
1. Enter system view.
system-view
2. Set the DSCP priority for RADIUS packets.
radius [ ipv6 ] dscp dscp-value
By default, the DSCP priority is 0 for RADIUS packets.

Configuring the Login-Service attribute check method for

SSH, FTP, and terminal users
About this task
The device supports the following check methods for the Login-Service attribute (RADIUS attribute
15) of SSH, FTP, and terminal users:
• Strict—Matches Login-Service attribute values 50, 51, and 52 for SSH, FTP, and terminal
services, respectively.
• Loose—Matches the standard Login-Service attribute value 0 for SSH, FTP, and terminal
services.
An Access-Accept packet received for a user must contain the matching attribute value. Otherwise,
the user cannot log in to the device.
Restrictions and guidelines
Use the loose check method only when the server does not issue Login-Service attribute values 50,
51, and 52 for SSH, FTP, and terminal users.
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Configure the Login-Service attribute check method for SSH, FTP, and terminal users.
attribute 15 check-mode { loose | strict }
The default check method is strict.

32
Interpreting the RADIUS class attribute as CAR parameters
About this task
A RADIUS server may deliver CAR parameters for user-based traffic monitoring and control by using
the RADIUS class attribute (attribute 25) in RADIUS packets. You can configure the device to
interpret the class attribute to CAR parameters.
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Interpret the RADIUS class attribute as CAR parameters.
attribute 25 car
By default, the RADIUS class attribute is not interpreted as CAR parameters.

Configuring the format of the RADIUS Called-Station-Id

attribute
About this task
In a wireless network, RADIUS servers of different types might have different requirements for the
format of the RADIUS Called-Station-Id attribute (attribute 30). The device supports the following
formats:
• AP name. For example, ap1.
• AP MAC. For example, 0AC1-F9B2-B1C2.
• AP MAC plus delimiter plus SSID. For example, 0AC1-F9B2-B1C2:test1, in which
0AC1-F9B2-B1C2 is the AP's MAC address, test1 is the SSID, and a colon (:) is used as the
delimiter.
• AP name plus delimiter plus SSID. For example, ap1-test1, in which ap1 is the AP's name,
test1 is the SSID, and a hyphen (-) is used as the delimiter.
The format of the MAC address in this attribute can be customized by using the attribute 30
mac-format command.
Restrictions and guidelines
This configuration takes effect only on RADIUS packets for portal, 802.1X, and MAC authentication
users in a wireless network.
Make sure the format of the Called-Station-Id attribute meets the requirements of the RADIUS
servers.
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Configure the format of the RADIUS Called-Station-Id attribute.
attribute 30 format { apmac-only | apname-only | { apmac-ssid |
apname-ssid } delimiter { colon | hyphen } }

33
 By default, the RADIUS Called-Station-Id attribute is in the format of
HH-HH-HH-HH-HH-HH:SSID. The HH-HH-HH-HH-HH-HH argument is the AP's MAC address,
the SSID argument is the SSID, and a colon (:) is used as the delimiter.

Configuring the MAC address format for the RADIUS

Called-Station-Id attribute
Restrictions and guidelines
RADIUS servers of different types might have different requirements for the MAC address format in
the RADIUS Called-Station-Id attribute. Configure the MAC address format for this attribute to meet
the requirements of the RADIUS servers.
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Configure the MAC address format for the RADIUS Called-Station-Id attribute.
attribute 30 mac-format section { one | { six | three } separator
separator-character } { lowercase | uppercase }
By default, the MAC address in the RADIUS Called-Station-Id attribute is in the format of
HH-HH-HH-HH-HH-HH. The MAC address is separated by hyphen (-) into six sections with
letters in upper case.

Configuring the MAC address format for the RADIUS

Calling-Station-Id attribute
Restrictions and guidelines
RADIUS servers of different types might have different requirements for the MAC address format in
the RADIUS Calling-Station-Id attribute (attribute 31). Configure the MAC address format for this
attribute to meet the requirements of the RADIUS servers.
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Configure the MAC address format for the RADIUS Calling-Station-Id attribute.
attribute 31 mac-format section { one | { six | three } separator
separator-character } { lowercase | uppercase }
By default, the MAC address in the RADIUS Calling-Station-Id attribute is in the format of
HH-HH-HH-HH-HH-HH. The MAC address is separated by hyphen (-) into six sections with
letters in upper case.

34
Setting the data measurement unit for the
Remanent_Volume attribute
About this task
The RADIUS server uses the Remanent_Volume attribute in authentication or real-time accounting
responses to notify the device of the current amount of data available for online users.
Restrictions and guidelines
Make sure the configured measurement unit is the same as the user data measurement unit on the
RADIUS server.
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Set the data measurement unit for the Remanent_Volume attribute.
attribute remanent-volume unit { byte | giga-byte | kilo-byte |
mega-byte }
By default, the data measurement unit is kilobyte.

Including subattribute 218 of vendor 25506 in outgoing

RADIUS packets
About this task
The RADIUS Vendor-Specific attribute (attribute 26) allows vendors to define extended attributes to
implement functions that the standard RADIUS protocol does not provide. Vendor 25506 defines
subattribute 218 to carry user DHCP option information.
To send user DHCP option information to RADIUS servers, perform this task to include subattribute
218 of vendor 25506 in outgoing RADIUS start-accounting and update-accounting requests.
In the current software version, only DHCP Option 55 and DHCP Option 66 can be carried in the
subattribute.
Restrictions and guidelines
You can repeat the include-attribute 218 vendor-id 25506 command to configure the
device to encapsulate both DHCP Option 55 and DHCP Option 61 in the subattribute. The length of
each option is limited to 246 bytes.
If you repeat this command multiple times with the same DHCP option specified, the most recent
configuration takes effect.
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Include subattribute 218 of vendor 25506 in outgoing RADIUS packets.
include-attribute 218 vendor-id 25506 dhcp-option { 55 | 61 } *
{ format1 | format2 }

35
 By default, the device uses format 1 to encapsulate DHCP Option 61 in subattribute 218 of
vendor 25506 in RADIUS packets.

Configuring the RADIUS attribute translation feature

About this task
The RADIUS attribute translation feature enables the device to work correctly with the RADIUS
servers of different vendors that support RADIUS attributes incompatible with the device.
RADIUS attribute translation has the following implementations:
• Attribute conversion—Converts source RADIUS attributes into destination RADIUS attributes
based on RADIUS attribute conversion rules.
• Attribute rejection—Rejects RADIUS attributes based on RADIUS attribute rejection rules.
When the RADIUS attribute translation feature is enabled, the device processes RADIUS packets as
follows:
• For the sent RADIUS packets:
 Deletes the rejected attributes from the packets.
 Uses the destination RADIUS attributes to replace the attributes that match RADIUS
attribute conversion rules in the packets.
• For the received RADIUS packets:
 Ignores the rejected attributes in the packets.
 Interprets the attributes that match RADIUS attribute conversion rules as the destination
RADIUS attributes.
To identify proprietary RADIUS attributes, you can define the attributes as extended RADIUS
attributes, and then convert the extended RADIUS attributes to device-supported attributes.
Restrictions and guidelines for RADIUS attribute translation configuration
Configure either conversion rules or rejection rules for a RADIUS attribute.
Configure either direction-based rules or packet type-based rules for a RADIUS attribute.
For direction-based translation of a RADIUS attribute, you can configure a rule for each direction
(inbound or outbound). For packet type-based translation of a RADIUS attribute, you can configure a
rule for each RADIUS packet type (RADIUS Access-Accept, RADIUS Access-Request, or RADIUS
accounting).
Configuring the RADIUS attribute translation feature for a RADIUS scheme
1. Enter system view.
system-view
2. (Optional.) Define an extended RADIUS attribute.
radius attribute extended attribute-name [ vendor vendor-id ] code
attribute-code type { binary | date | integer | interface-id | ip | ipv6 |
ipv6-prefix | octets | string }
3. Enter RADIUS scheme view.
radius scheme radius-scheme-name
4. Enable the RADIUS attribute translation feature.
attribute translate
By default, this feature is disabled.
5. Configure a RADIUS attribute conversion rule or a RADIUS attribute reject rule. Choose the
following tasks as needed:
 Configure a RADIUS attribute conversion rule.

36
 attribute convert src-attr-name to dest-attr-name { { access-accept
| access-request | accounting } * | { received | sent } * }
By default, no RADIUS attribute conversion rules are configured.
 Configure a RADIUS attribute rejection rule.
attribute reject attr-name { { access-accept | access-request |
accounting } * | { received | sent } * }
By default, no RADIUS attribute rejection rules are configured.
Configuring the RADIUS attribute translation feature for a RADIUS DAS
1. Enter system view.
system-view
2. (Optional.) Define an extended RADIUS attribute.
radius attribute extended attribute-name [ vendor vendor-id ] code
attribute-code type { binary | date | integer | interface-id | ip | ipv6 |
ipv6-prefix | octets | string }
3. Enter RADIUS DAS view.
radius dynamic-author server
4. Enable the RADIUS attribute translation feature.
attribute translate
By default, this feature is disabled.
5. Configure a RADIUS attribute conversion rule or a RADIUS attribute rejection rule. Choose the
following tasks as needed:
 Configure a RADIUS attribute conversion rule.
attribute convert src-attr-name to dest-attr-name { { coa-ack |
coa-request } * | { received | sent } * }
By default, no RADIUS attribute conversion rules are configured.
 Configure a RADIUS attribute rejection rule.
attribute reject attr-name { { coa-ack | coa-request } * | { received |
sent } * }
By default, no RADIUS attribute rejection rules are configured.

Configuring RADIUS stop-accounting packet buffering

About this task
The device sends RADIUS stop-accounting requests when it receives connection teardown requests
from hosts or connection teardown commands from an administrator. However, the device might fail
to receive a response for a stop-accounting request in a single transmission. Enable the device to
buffer RADIUS stop-accounting requests that have not received responses from the accounting
server. The device will resend the requests until responses are received.
To limit the transmission times, set a maximum number of transmission attempts that can be made
for individual RADIUS stop-accounting requests. When the maximum attempts are made for a
request, the device discards the buffered request.
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name

37
 3. Enable buffering of RADIUS stop-accounting requests to which no responses have been
received.
stop-accounting-buffer enable
By default, the buffering feature is enabled.
4. (Optional.) Set the maximum number of transmission attempts for individual RADIUS
stop-accounting requests.
retry stop-accounting retries
The default setting is 500.

Enabling forcibly sending stop-accounting packets

About this task
Typically, if the device does not send a start-accounting packet to the RADIUS server for an
authenticated user, it does not send a stop-accounting packet when the user goes offline. If the
server has generated a user entry for the user without start-accounting packets, it does not release
the user entry when the user goes offline. This feature forces the device to send stop-accounting
packets to the RADIUS server when the user goes offline for timely releasing the user entry on the
server.
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Enable the device to send stop-accounting packets when users for which no start-accounting
packets are sent go offline.
stop-accounting-packet send-force
By default, forcibly sending stop-accounting packets is disabled. The device does not send
stop-accounting packets when users for which no start-accounting packets are sent go offline.

Enabling the RADIUS server load sharing feature

About this task
By default, the device communicates with RADIUS servers based on the server roles. It first attempts
to communicate with the primary server, and, if the primary server is unreachable, it then searches
for the secondary servers in the order they are configured. The first secondary server in active state
is used for communication. In this process, the workload is always placed on the active server.
Use the RADIUS server load sharing feature to dynamically distribute the workload over multiple
servers regardless of their server roles. The device forwards an AAA request to the most appropriate
server of all active servers in the scheme after it compares the weight values and numbers of
currently served users. Specify a weight value for each RADIUS server based on the AAA capacity of
the server. A larger weight value indicates a higher AAA capacity.
In RADIUS server load sharing, once the device sends a start-accounting request to a server for a
user, it forwards all subsequent accounting requests of the user to the same server. If the accounting
server is unreachable, the device returns an accounting failure message rather than searching for
another active accounting server.
Procedure
1. Enter system view.
system-view

38
 2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Enable the RADIUS server load sharing feature.
server-load-sharing enable
By default, this feature is disabled.

Specifying a RADIUS server selection mode for

reauthentication
About this task
Use this feature to configure the RADIUS server selection mechanism in reauthentication. The
following RADIUS server selection modes are available:
• Inherit—The device uses the RADIUS server that performed authentication for a user to
reauthenticate that user. This mode reduces the amount of time used in reauthentication.
However, if the RADIUS server is unreachable, the reauthentication will fail.
• Reselect—The device searches for a reachable RADIUS server to reauthenticate a user. This
mode requires more time than the inherit mode. However, this mode ensures that the device
uses the optimal reachable RADIUS server for reauthentication. The following factors affect the
RADIUS server selection:
 Server configuration in the RADIUS scheme, including the configuration order.
 Enabling status of the RADIUS server load sharing feature.
 Status of the RADIUS servers in the RADIUS scheme.
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Specify a RADIUS server selection mode for reauthentication.
reauthentication server-select { inherit | reselect }
By default, the inherit mode is used.

Configuring the RADIUS accounting-on feature

About this task
When the accounting-on feature is enabled, the device automatically sends an accounting-on packet
to the RADIUS server after the entire device reboots. 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
come online.
You can configure the interval for which the device waits to resend the accounting-on packet and the
maximum number of retries.
The extended accounting-on feature enhances the accounting-on feature in a distributed
architecture.
The extended accounting-on feature is applicable to LAN users. The user data is saved to the IRF
member devices through which the users access the system. When the extended accounting-on
feature is enabled, the system automatically sends an accounting-on packet to the RADIUS server
after a member device reboots. The packet contains the member device identifier. Upon receiving

39
 the accounting-on packet, the RADIUS server logs out all online users that access the system
through the member device. If no users have come online through the member device, the IRF fabric
does not send an accounting-on packet after the member device reboots.
Restrictions and guidelines
For the extended accounting-on feature to take effect, the RADIUS server must run on IMC and the
accounting-on feature must be enabled.
Procedure
1. Enter system view.
system-view
2. Enter RADIUS scheme view.
radius scheme radius-scheme-name
3. Enable accounting-on.
accounting-on enable [ interval interval | send send-times ] *
By default, the accounting-on feature is disabled.
4. (Optional.) Enable extended accounting-on.
accounting-on extended
By default, extended accounting-on is disabled.

Configuring the RADIUS session-control feature

About this task
Enable this feature for the RADIUS server to dynamically change the user authorization information
(for example, authorization ACL, VLAN, user group, VSI, or blackhole MAC) or forcibly disconnect
users by using session-control packets. This task enables the device to receive RADIUS
session-control packets on UDP port 1812.
To verify the session-control packets sent from a RADIUS server, specify the RADIUS server as a
session-control client to the device.
Restrictions and guidelines
The RADIUS session-control feature can only work with RADIUS servers running on IMC. The
session-control client configuration takes effect only when the session-control feature is enabled.
If the device acts as the NAS and the IMC server deployed with EAD assigns authorization ACLs to
the device, you must enable the session-control feature on the device. This ensures that the
authorization ACLs can take effect.
Procedure
1. Enter system view.
system-view
2. Enable the session-control feature.
radius session-control enable
By default, the session-control feature is disabled.
3. Specify a session-control client.
radius session-control client { ip ipv4-address | ipv6 ipv6-address }
[ key { cipher | simple } string | vpn-instance vpn-instance-name ] *
By default, no session-control clients are specified.

40
Configuring the RADIUS DAS feature
About this task
Dynamic Authorization Extensions (DAE) to RADIUS, defined in RFC 5176, can log off online users
and change online user authorization information.
In a RADIUS network, the RADIUS server typically acts as the DAE client (DAC) and the NAS acts
as the DAE server (DAS).
When the RADIUS DAS feature is enabled, the NAS performs the following operations:
1. Listens to the default or specified UDP port to receive DAE requests.
2. Logs off online users that match the criteria in the requests, changes their authorization
information, shuts down or reboots their access ports, or reauthenticates the users.
3. Sends DAE responses to the DAC.
DAE defines the following types of packets:
• Disconnect Messages (DMs)—The DAC sends DM requests to the DAS to log off specific
online users.
• Change of Authorization Messages (CoA Messages)—The DAC sends CoA requests to the
DAS to change the authorization information of specific online users.
Procedure
1. Enter system view.
system-view
2. Enable the RADIUS DAS feature and enter RADIUS DAS view.
radius dynamic-author server
By default, the RADIUS DAS feature is disabled.
3. Specify a RADIUS DAC.
client { ip ipv4-address | ipv6 ipv6-address } [ key { cipher | simple }
string | vpn-instance vpn-instance-name ] *
By default, no RADIUS DACs are specified.
4. (Optional.) Specify the RADIUS DAS port.
port port-number
By default, the RADIUS DAS port is 3799.

Enabling SNMP notifications for RADIUS

About this task
When SNMP notifications are enabled for RADIUS, the SNMP agent supports the following
notifications generated by RADIUS:
• RADIUS server unreachable notification—The RADIUS server cannot be reached. RADIUS
generates this notification if it does not receive a response to an accounting or authentication
request within the specified number of RADIUS request transmission attempts.
• RADIUS server reachable notification—The RADIUS server can be reached. RADIUS
generates this notification for a previously blocked RADIUS server after the quiet timer expires.
• Excessive authentication failures notification—The number of authentication failures
compared to the total number of authentication attempts exceeds the specified threshold.
For RADIUS SNMP notifications to be sent correctly, you must also configure SNMP on the device.
For more information about SNMP configuration, see Network Management and Monitoring
Configuration Guide.

41
Restrictions and guidelines
Make sure the RADIUS server status change notifications sent by the device can be recognized by
the NMS. Choose a MIB node version depending on the NMS requirements. For more information
about the MIB node versions, see AAA in Security Command Reference.
Procedure
1. Enter system view.
system-view
2. Enable SNMP notifications for RADIUS.
snmp-agent trap enable radius [ accounting-server-down |
accounting-server-up | authentication-error-threshold |
authentication-server-down | authentication-server-up ] *
By default, all SNMP notifications are disabled for RADIUS.
3. Set the version of RADIUS server status change MIB nodes.
radius trap-version { v1 | v2 } [ accounting-server-down |
accounting-server-up | authentication-server-down |
authentication-server-up ] *
By default, the device sends notifications about RADIUS server status change MIB nodes over
SNMPv1.

Disabling the RADIUS service

About this task
By default, the RADIUS service is enabled. The device can send and receive RADIUS packets.
Attackers might use RADIUS session-control and DAE ports to attack the device. To protect the
device when such an attack occurs, disable the RADIUS service temporarily on the device. After the
network is secure, re-enable the RADIUS service.
If settings on the RADIUS servers require modification or the RADIUS servers cannot provide
services temporarily, you can temporarily disable the RADIUS service on the device.
When the RADIUS service is disabled, the device stops sending and receiving RADIUS packets. If a
new user comes online, the device uses the backup authentication, authorization, or accounting
method to process that user. If the device has not finished requesting authentication or accounting
for a user before the RADIUS service is disabled, it uses the following rules to process that user:
• If the device has sent RADIUS authentication requests for that user to a RADIUS server, the
device processes that user depending on whether it receives a response from the RADIUS
server.
 If the device receives a response from the RADIUS server, it uses the response to
determine whether that user has passed authentication. If that user has passed
authentication, the device assigns authorization information to that user according to the
response.
 If the device does not receive any response from the RADIUS server, it attempts to use the
backup authentication method to authenticate that user.
• If the device has sent RADIUS start-accounting requests for that user to a RADIUS server, the
device processes that user depending on whether it receives a response from the RADIUS
server.
 If the device receives a response from the RADIUS server, it allows that user to come online.
However, the device cannot send out accounting-update or stop-accounting requests to the
RADIUS server. It cannot buffer the accounting requests, either. When that user goes offline,
the RADIUS server cannot log off that user in time. The accounting result might be
inaccurate.

42
  If the device does not receive any response from the RADIUS server, it attempts to use the
backup accounting method.
Restrictions and guidelines
Disabling the RADIUS service does not affect the RADIUS server feature of the device.
The authentication, authorization, and accounting processes undertaken by other methods are not
switched to RADIUS when you re-enable the RADIUS service.
Procedure
1. Enter system view.
system-view
2. Disable the RADIUS service.
undo radius enable
By default, the RADIUS service is enabled.
To re-enable the RADIUS service, use the radius enable command.

Display and maintenance commands for RADIUS

Execute display commands in any view and reset commands in user view.

Task Command
Display the RADIUS scheme
display radius scheme [ radius-scheme-name ]
configuration.

Display authentication and accounting

display radius server-load statistics
load statistics for all RADIUS servers.

Display RADIUS packet statistics. display radius statistics

Display information about buffered display stop-accounting-buffer

RADIUS stop-accounting requests to { radius-scheme radius-scheme-name |
which no responses have been session-id session-id | time-range
received. start-time end-time | user-name user-name }
Clear history authentication and
accounting load statistics for all reset radius server-load statistics
RADIUS servers.

Clear RADIUS statistics. reset radius statistics

reset stop-accounting-buffer
Clear the buffered RADIUS { radius-scheme radius-scheme-name |
stop-accounting requests to which no
responses have been received.
session-id session-id | time-range
start-time end-time | user-name user-name }

Configuring HWTACACS
HWTACACS tasks at a glance
To configure HWTACACS, perform the following tasks:
1. Creating an HWTACACS scheme
2. Specifying the HWTACACS authentication servers
3. Specifying the HWTACACS authorization servers

43
 4. Specifying the HWTACACS accounting servers
5. Specifying the shared keys for secure HWTACACS communication
Perform this task if no shared keys are specified when configuring HWTACACS servers.
6. Specifying an MPLS L3VPN instance for the scheme
Perform this task if no MPLS L3VPN instances are specified when configuring HWTACACS
servers.
7. (Optional.) Setting HWTACACS timers
8. (Optional.) Configuring parameters for HWTACACS packets
Specifying the source IP address for outgoing HWTACACS packets
Setting the username format and traffic statistics units
9. (Optional.) Configuring HWTACACS stop-accounting packet buffering

Creating an HWTACACS scheme

Restrictions and guidelines
You can configure a maximum of 16 HWTACACS schemes. An HWTACACS scheme can be used
by multiple ISP domains.
Procedure
1. Enter system view.
system-view
2. Create an HWTACACS scheme and enter HWTACACS scheme view.
hwtacacs scheme hwtacacs-scheme-name

Specifying the HWTACACS authentication servers

About this task
You can specify one primary authentication server and a maximum of 16 secondary authentication
servers for an HWTACACS scheme. When the primary server is unreachable, the device searches
for the secondary servers in the order they are configured. The first secondary server in active state
is used for communication.
Restrictions and guidelines
If redundancy is not required, specify only the primary server.
An HWTACACS server can function as the primary authentication server in one scheme and as the
secondary authentication server in another scheme at the same time.
Two HWTACACS authentication servers in a scheme, primary or secondary, cannot have the same
combination of VPN instance, host name, IP address, and port number.
Procedure
1. Enter system view.
system-view
2. Enter HWTACACS scheme view.
hwtacacs scheme hwtacacs-scheme-name
3. Specify the primary HWTACACS authentication server.
primary authentication { host-name | ipv4-address | ipv6 ipv6-address }
[ port-number | key { cipher | simple } string | single-connection |
vpn-instance vpn-instance-name ] *

44
 By default, no primary HWTACACS authentication server is specified.
4. (Optional.) Specify a secondary HWTACACS authentication server.
secondary authentication { host-name | ipv4-address | ipv6
ipv6-address } [ port-number | key { cipher | simple } string |
single-connection | vpn-instance vpn-instance-name ] *
By default, no secondary HWTACACS authentication servers are specified.

Specifying the HWTACACS authorization servers

About this task
You can specify one primary authorization server and a maximum of 16 secondary authorization
servers for an HWTACACS scheme. When the primary server is not available, the device searches
for the secondary servers in the order they are configured. The first secondary server in active state
is used for communication.
Restrictions and guidelines
If redundancy is not required, specify only the primary server.
An HWTACACS server can function as the primary authorization server of one scheme and as the
secondary authorization server of another scheme at the same time.
Two HWTACACS authorization servers in a scheme, primary or secondary, cannot have the same
combination of VPN instance, host name, IP address, and port number.
Procedure
1. Enter system view.
system-view
2. Enter HWTACACS scheme view.
hwtacacs scheme hwtacacs-scheme-name
3. Specify the primary HWTACACS authorization server.
primary authorization { host-name | ipv4-address | ipv6 ipv6-address }
[ port-number | key { cipher | simple } string | single-connection |
vpn-instance vpn-instance-name ] *
By default, no primary HWTACACS authorization server is specified.
4. (Optional.) Specify a secondary HWTACACS authorization server.
secondary authorization { host-name | ipv4-address | ipv6 ipv6-address }
[ port-number | key { cipher | simple } string | single-connection |
vpn-instance vpn-instance-name ] *
By default, no secondary HWTACACS authorization servers are specified.

Specifying the HWTACACS accounting servers

About this task
You can specify one primary accounting server and a maximum of 16 secondary accounting servers
for an HWTACACS scheme. When the primary server is not available, the device searches for the
secondary servers in the order they are configured. The first secondary server in active state is used
for communication.
Restrictions and guidelines
If redundancy is not required, specify only the primary server.

45
 An HWTACACS server can function as the primary accounting server of one scheme and as the
secondary accounting server of another scheme at the same time.
Two HWTACACS accounting servers in a scheme, primary or secondary, cannot have the same
combination of VPN instance, host name, IP address, and port number.
HWTACACS does not support accounting for FTP, SFTP, and SCP users.
Procedure
1. Enter system view.
system-view
2. Enter HWTACACS scheme view.
hwtacacs scheme hwtacacs-scheme-name
3. Specify the primary HWTACACS accounting server.
primary accounting { host-name | ipv4-address | ipv6 ipv6-address }
[ port-number | key { cipher | simple } string | single-connection |
vpn-instance vpn-instance-name ] *
By default, no primary HWTACACS accounting server is specified.
4. (Optional.) Specify a secondary HWTACACS accounting server.
secondary accounting { host-name | ipv4-address | ipv6 ipv6-address }
[ port-number | key { cipher | simple } string | single-connection |
vpn-instance vpn-instance-name ] *
By default, no secondary HWTACACS accounting servers are specified.

Specifying the shared keys for secure HWTACACS

communication
About this task
The HWTACACS client and server use the MD5 algorithm and shared keys to generate the
Authenticator value for packet authentication and user password encryption. The client and server
must use the same key for each type of communication.
Perform this task to configure shared keys for servers in an HWTACACS scheme. The keys take
effect on all servers for which a shared key is not individually configured.
Restrictions and guidelines
Make sure the shared key configured on the device is the same as the shared key configured on the
HWTACACS server.
Procedure
1. Enter system view.
system-view
2. Enter HWTACACS scheme view.
hwtacacs scheme hwtacacs-scheme-name
3. Specify a shared key for secure HWTACACS authentication, authorization, or accounting
communication.
key { accounting | authentication | authorization } { cipher | simple }
string
By default, no shared key is specified for secure HWTACACS communication.

46
Specifying an MPLS L3VPN instance for the scheme
About this task
The VPN instance specified for an HWTACACS scheme applies to all servers in that scheme. If a
VPN instance is also configured for an individual HWTACACS server, the VPN instance specified for
the HWTACACS scheme does not take effect on that server.
Procedure
1. Enter system view.
system-view
2. Enter HWTACACS scheme view.
hwtacacs scheme hwtacacs-scheme-name
3. Specify a VPN instance for the HWTACACS scheme.
vpn-instance vpn-instance-name
By default, an HWTACACS scheme belongs to the public network.

Setting HWTACACS timers

About this task
The device uses the following timers to control communication with an HWTACACS server:
• Server response timeout timer (response-timeout)—Defines the HWTACACS server
response timeout timer. The device starts this timer immediately after an HWTACACS
authentication, authorization, or accounting request is sent. If the device does not receive a
response from the server within the timer, it sets the server to blocked. Then, the device sends
the request to another HWTACACS server.
• Real-time accounting timer (realtime-accounting)—Defines the interval at which the device
sends real-time accounting packets to the HWTACACS accounting server for online users.
• Server quiet timer (quiet)—Defines the duration to keep an unreachable server in blocked
state. If a server is not reachable, the device changes the server status to blocked, starts this
timer for the server, and tries to communicate with another server in active state. After the
server quiet timer expires, the device changes the status of the server back to active.
The server quiet timer setting affects the status of HWTACACS servers. If the scheme includes one
primary HWTACACS server and multiple secondary HWTACACS servers, the device communicates
with the HWTACACS servers based on the following rules:
• When the primary server is in active state, the device communicates with the primary server.
When the primary server is unreachable, the device researches a secondary server in active
status in the order they are configured.
• When one or more servers are in active state, the device tries to communicate with these
servers only, even if they are unreachable.
• When all servers are in blocked state, the device only tries to communicate with the primary
server.
• If the primary server is unreachable, the device changes the server status to blocked and starts
a quiet timer for the server. When the quiet timer of the server expires, the status of the server
changes back to active. The device does not check the server again during the authentication,
authorization, or accounting process.
• The search process continues until the device finds an available secondary server or has
checked all secondary servers in active state. If no server is available, the device considers the
authentication, authorization, or accounting attempt a failure.

47
 • When you remove a server in use, communication with the server times out. The device looks
for a server in active state by first checking the primary server, and then checking secondary
servers in the order they are configured.
• When an HWTACACS server's status changes automatically, the device changes this server's
status accordingly in all HWTACACS schemes in which this server is specified.
Restrictions and guidelines
A short real-time accounting interval helps improve accounting precision but requires many system
resources. When there are 1000 or more users, set a real-time accounting interval longer than 15
minutes.
Procedure
1. Enter system view.
system-view
2. Enter HWTACACS scheme view.
hwtacacs scheme hwtacacs-scheme-name
3. Set the HWTACACS timers. Choose the following tasks as needed:
 Set the HWTACACS server response timeout timer.
timer response-timeout seconds
By default, the HWTACACS server response timeout timer is 5 seconds.
 Set the real-time accounting interval.
timer realtime-accounting minutes
By default, the real-time accounting interval is 12 minutes.
 Set the server quiet timer.
timer quiet minutes
By default, the server quiet timer is 5 minutes.

Specifying the source IP address for outgoing HWTACACS

packets
About this task
The source IP address of HWTACACS packets that a NAS sends must match the IP address of the
NAS configured on the HWTACACS server. An HWTACACS server identifies a NAS by IP address.
When the HWTACACS server receives a packet, it checks the source IP address of the packet.
• If it is the IP address of a managed NAS, the server processes the packet.
• If it is not the IP address of a managed NAS, the server drops the packet.
Before sending an HWTACACS packet, the NAS selects a source IP address in the following order:
1. The source IP address specified for the HWTACACS scheme.
2. The source IP address specified in system view for the VPN or public network, depending on
where the HWTACACS server resides.
3. The IP address of the outbound interface specified by the route.
Restrictions and guidelines for source IP address configuration
You can specify the source IP address for outgoing HWTACACS packets in HWTACACS scheme
view or in system view.
• The IP address specified in HWTACACS scheme view applies to one HWTACACS scheme.
• The IP address specified in system view applies to all HWTACACS schemes.

48
 The source IP address of HWTACACS packets that a NAS sends must match the IP address of the
NAS that is configured on the HWTACACS server.
As a best practice, specify a loopback interface address as the source IP address for outgoing
HWTACACS packets to avoid HWTACACS packet loss caused by physical port errors.
To communicate with the HWTACACS server, the source address of outgoing HWTACACS packets
is typically the IP address of an egress interface on the NAS. However, in some situations, you must
change the source IP address. For example, when VRRP is configured for stateful failover, configure
the virtual IP of the uplink VRRP group as the source address.
You can directly specify a source IP address for outgoing HWTACACS packets or specify a source
interface to provide the source IP address for outgoing HWTACACS packets. The source interface
configuration and the source IP address configuration overwrite each other.
Specifying a source interface or source IP address for all HWTACACS schemes
1. Enter system view.
system-view
2. Specify a source interface or source IP address for outgoing HWTACACS packets.
hwtacacs nas-ip { interface interface-type interface-number |
{ ipv4-address | ipv6 ipv6-address } [ vpn-instance
vpn-instance-name ] }
By default, the source IP address of an HWTACACS packet sent to the server is the primary
IPv4 address or the IPv6 address of the outbound interface.
Specifying a source interface or source IP address for an HWTACACS scheme
1. Enter system view.
system-view
2. Enter HWTACACS scheme view.
hwtacacs scheme hwtacacs-scheme-name
3. Specify a source interface or source IP address for outgoing HWTACACS packets.
nas-ip { ipv4-address | interface interface-type interface-number |
ipv6 ipv6-address }
By default, the source IP address of an outgoing HWTACACS packet is that configured by
using the hwtacacs nas-ip command in system view. If the hwtacacs nas-ip command
is not used, the source IP address is the primary IP address of the outbound interface.

Setting the username format and traffic statistics units

About this task
A username is typically in the userid@isp-name format, where the isp-name part represents the
user's ISP domain name. By default, the ISP domain name is included in a username. If HWTACACS
servers do not recognize usernames that contain ISP domain names, you can configure the device
to send usernames without domain names to the servers.
The device reports online user traffic statistics in accounting packets.
Restrictions and guidelines
If two or more ISP domains use the same HWTACACS scheme, configure the HWTACACS scheme
to keep the ISP domain name in usernames for domain identification.
For accounting accuracy, make sure the traffic measurement units configured on the device are the
same as the traffic measurement units configured on the HWTACACS accounting servers.

49
Procedure
1. Enter system view.
system-view
2. Enter HWTACACS scheme view.
hwtacacs scheme hwtacacs-scheme-name
3. Set the format of usernames sent to the HWTACACS servers.
user-name-format { keep-original | with-domain | without-domain }
By default, the ISP domain name is included in a username.
4. Set the data flow and packet measurement units for traffic statistics.
data-flow-format { data { byte | giga-byte | kilo-byte | mega-byte }
| packet { giga-packet | kilo-packet | mega-packet | one-packet } }*
By default, traffic is counted in bytes and packets.

Configuring HWTACACS stop-accounting packet buffering

About this task
The device sends HWTACACS stop-accounting requests when it receives connection teardown
requests from hosts or connection teardown commands from an administrator. However, the device
might fail to receive a response for a stop-accounting request in a single transmission. Enable the
device to buffer HWTACACS stop-accounting requests that have not received responses from the
accounting server. The device will resend the requests until responses are received.
To limit the transmission times, set a maximum number of attempts that can be made for transmitting
individual HWTACACS stop-accounting requests. When the maximum attempts are made for a
request, the device discards the buffered request.
Procedure
1. Enter system view.
system-view
2. Enter HWTACACS scheme view.
hwtacacs scheme hwtacacs-scheme-name
3. Enable buffering of HWTACACS stop-accounting requests to which no responses have been
received.
stop-accounting-buffer enable
By default, the buffering feature is enabled.
4. (Optional.) Set the maximum number of transmission attempts for individual HWTACACS
stop-accounting requests.
retry stop-accounting retries
The default setting is 100.

Display and maintenance commands for HWTACACS

Execute display commands in any view and reset commands in user view.

Task Command
Display the configuration or server display hwtacacs scheme
statistics of HWTACACS schemes. [ hwtacacs-scheme-name [ statistics ] ]

50
 Task Command
Display information about buffered
HWTACACS stop-accounting requests display stop-accounting-buffer
to which no responses have been hwtacacs-scheme hwtacacs-scheme-name
received.

reset hwtacacs statistics { accounting | all

Clear HWTACACS statistics.
| authentication | authorization }
Clear the buffered HWTACACS reset stop-accounting-buffer
stop-accounting requests to which no
responses have been received.
hwtacacs-scheme hwtacacs-scheme-name

Configuring LDAP
LDAP tasks at a glance
To configure LDAP, perform the following tasks:
1. Configuring an LDAP server
a. Creating an LDAP server
b. Configuring the IP address of the LDAP server
c. (Optional.) Specifying the LDAP version
d. (Optional.) Setting the LDAP server timeout period
e. Configuring administrator attributes
f. Configuring LDAP user attributes
2. (Optional.) Configuring an LDAP attribute map
3. Creating an LDAP scheme
4. Specifying the LDAP authentication server
5. (Optional.) Specifying the LDAP authorization server
6. (Optional.) Specifying an LDAP attribute map for LDAP authorization

Creating an LDAP server

1. Enter system view.
system-view
2. Create an LDAP server and enter LDAP server view.
ldap server server-name

Configuring the IP address of the LDAP server

Restrictions and guidelines
You can configure either an IPv4 address or an IPv6 address for an LDAP server. If you configure the
IP address for an LDAP server multiple times, the most recent configuration takes effect.
Procedure
1. Enter system view.
system-view
2. Enter LDAP server view.

51
 ldap server server-name
3. Configure the IP address of the LDAP server.
{ ip ipv4-address | ipv6 ipv6-address } [ port port-number ]
[ vpn-instance vpn-instance-name ]
By default, an LDAP server does not have an IP address.

Specifying the LDAP version

Restrictions and guidelines
The device supports LDAPv2 and LDAPv3.
A Microsoft LDAP server supports only LDAPv3.
The LDAP version specified on the device must be consistent with the version specified on the LDAP
server.
Procedure
1. Enter system view.
system-view
2. Enter LDAP server view.
ldap server server-name
3. Specify the LDAP version.
protocol-version { v2 | v3 }
By default, LDAPv3 is used.

Setting the LDAP server timeout period

About this task
If the device sends a bind or search request to an LDAP server without receiving the server's
response within the server timeout period, the authentication or authorization request times out.
Then, the device tries the backup authentication or authorization method. If no backup method is
configured in the ISP domain, the device considers the authentication or authorization attempt a
failure.
Procedure
1. Enter system view.
system-view
2. Enter LDAP server view.
ldap server server-name
3. Set the LDAP server timeout period.
server-timeout time-interval
By default, the LDAP server timeout period is 10 seconds.

Configuring administrator attributes

About this task
To configure the administrator DN and password for binding with the LDAP server during LDAP
authentication:

52
Procedure
1. Enter system view.
system-view
2. Enter LDAP server view.
ldap server server-name
3. Specify the administrator DN.
login-dn dn-string
By default, no administrator DN is specified.
The administrator DN specified on the device must be the same as the administrator DN
configured on the LDAP server.
4. Configure the administrator password.
login-password { cipher | simple } string
By default, no administrator password is specified.

Configuring LDAP user attributes

About this task
To authenticate a user, an LDAP client must complete the following operations:
1. Establish a connection to the LDAP server.
2. Obtain the user DN from the LDAP server.
3. Use the user DN and the user's password to bind with the LDAP server.
LDAP provides a DN search mechanism for obtaining the user DN. According to the mechanism, an
LDAP client sends search requests to the server based on the search policy determined by the LDAP
user attributes of the LDAP client.
The LDAP user attributes include:
• Search base DN.
• Search scope.
• Username attribute.
• Username format.
• User object class.
Restrictions and guidelines
If the LDAP server contains many directory levels, a user DN search starting from the root directory
can take a long time. To improve efficiency, you can change the start point by specifying the search
base DN.
Procedure
1. Enter system view.
system-view
2. Enter LDAP server view.
ldap server server-name
3. Specify the user search base DN.
search-base-dn base-dn
By default, no user search base DN is specified.
4. (Optional.) Specify the user search scope.
search-scope { all-level | single-level }

53
 By default, the user search scope is all-level.
5. (Optional.) Specify the username attribute.
user-parameters user-name-attribute { name-attribute | cn | uid }
By default, the username attribute is cn.
6. (Optional.) Specify the username format.
user-parameters user-name-format { with-domain | without-domain }
By default, the username format is without-domain.
7. (Optional.) Specify the user object class.
user-parameters user-object-class object-class-name
By default, no user object class is specified, and the default user object class on the LDAP
server is used. The default user object class for this command varies by server model.

Configuring an LDAP attribute map

About this task
Configure an LDAP attribute map to define a list of LDAP-AAA attribute mapping entries. To apply the
LDAP attribute map, specify the name of the LDAP attribute map in the LDAP scheme used for
authorization.
The LDAP attribute map feature enables the device to convert LDAP attributes obtained from an
LDAP authorization server to device-recognizable AAA attributes based on the mapping entries.
Because the device ignores unrecognized LDAP attributes, configure the mapping entries to include
important LDAP attributes that should not be ignored.
An LDAP attribute can be mapped only to one AAA attribute. Different LDAP attributes can be
mapped to the same AAA attribute.
Procedure
1. Enter system view.
system-view
2. Create an LDAP attribute map and enter LDAP attribute map view.
ldap attribute-map map-name
3. Configure a mapping entry.
map ldap-attribute ldap-attribute-name [ prefix prefix-value
delimiter delimiter-value ] aaa-attribute { user-group | user-profile }

Creating an LDAP scheme

Restrictions and guidelines
You can configure a maximum of 16 LDAP schemes. An LDAP scheme can be used by multiple ISP
domains.
Procedure
1. Enter system view.
system-view
2. Create an LDAP scheme and enter LDAP scheme view.
ldap scheme ldap-scheme-name

54
Specifying the LDAP authentication server
1. Enter system view.
system-view
2. Enter LDAP scheme view.
ldap scheme ldap-scheme-name
3. Specify the LDAP authentication server.
authentication-server server-name
By default, no LDAP authentication server is specified.

Specifying the LDAP authorization server

1. Enter system view.
system-view
2. Enter LDAP scheme view.
ldap scheme ldap-scheme-name
3. Specify the LDAP authorization server.
authorization-server server-name
By default, no LDAP authorization server is specified.

Specifying an LDAP attribute map for LDAP authorization

About this task
Specify an LDAP attribute map for LDAP authorization to convert LDAP attributes obtained from the
LDAP authorization server to device-recognizable AAA attributes.
Restrictions and guidelines
You can specify only one LDAP attribute map in an LDAP scheme.
Procedure
1. Enter system view.
system-view
2. Enter LDAP scheme view.
ldap scheme ldap-scheme-name
3. Specify an LDAP attribute map.
attribute-map map-name
By default, no LDAP attribute map is specified.

Display and maintenance commands for LDAP

Execute display commands in any view.

Task Command
display ldap scheme
Display the configuration of LDAP schemes.
[ ldap-scheme-name ]

55
Creating an ISP domain
About ISP domains
In a networking scenario with multiple ISPs, the device can connect to users of different ISPs. These
users can have different user attributes, such as different username and password structures,
different service types, and different rights. To manage users of different ISPs, configure
authentication, authorization, and accounting methods and domain attributes for each ISP domain
as needed.
The device supports a maximum of 16 ISP domains, including the system-defined ISP domain
system. You can specify one of the ISP domains as the default domain.
On the device, each user belongs to an ISP domain. If a user does not provide an ISP domain name
at login, the device considers the user belongs to the default ISP domain.
Each ISP domain has a set of system-defined AAA methods, which are local authentication, local
authorization, and local accounting. If you do not configure any AAA methods for an ISP domain, the
device uses the system-defined AAA methods for users in the domain.
The device chooses an authentication domain for each user in the following order:
1. The authentication domain specified for the access module.
2. The ISP domain in the username.
3. The default ISP domain of the device.
If the chosen domain does not exist on the device, the device searches for the ISP domain that
accommodates users assigned to nonexistent domains. (Support for the authentication domain
configuration depends on the access module.) If no such ISP domain is configured, user
authentication fails.

Restrictions and guidelines for ISP domain configuration

An ISP domain cannot be deleted when it is the default ISP domain. Before you use the undo
domain command, change the domain to a non-default ISP domain by using the undo domain
default enable command.
You can modify the settings of the system-defined ISP domain system, but you cannot delete the
domain.
To avoid RADIUS authentication, authorization, or accounting failures, use short domain names to
ensure that usernames containing a domain name do not exceed 253 characters.
To avoid RADIUS accounting failures, make sure the domain name contained in usernames sent to
the RADIUS server does not exceed 247 characters.

Creating an ISP domain

1. Enter system view.
system-view
2. Create an ISP domain and enter ISP domain view.
domain isp-name
By default, a system-defined ISP domain exists. The domain name is system.

56
Specifying the default ISP domain
1. Enter system view.
system-view
2. Specify the default ISP domain.
domain default enable isp-name
By default, the default ISP domain is the system-defined ISP domain system.

Specifying an ISP domain for users that are assigned to

nonexistent domains
1. Enter system view.
system-view
2. Specify the ISP domain to accommodate users that are assigned to nonexistent domains.
domain if-unknown isp-name
By default, no ISP domain is specified to accommodate users that are assigned to nonexistent
domains.

Configuring ISP domain attributes

Setting ISP domain status
About this task
By placing the ISP domain in active or blocked state, you allow or deny network service requests
from users in the domain.
Procedure
1. Enter system view.
system-view
2. Enter ISP domain view.
domain isp-name
3. Set the status of the ISP domain.
state { active | block }
By default, an ISP domain is in active state, and users in the domain can request network
services.

Configuring authorization attributes for an ISP domain

About this task
The device supports the following authorization attributes:
• ACL—The device restricts authenticated users to access only the network resources permitted
by the ACL.
• CAR action—The attribute controls the traffic flow of authenticated users.
• Maximum number of multicast groups—The attribute restricts the maximum number of
multicast groups that an authenticated user can join concurrently.

57
 • IPv4 address pool—The device assigns IPv4 addresses from the pool to authenticated users
in the domain.
• IPv6 address pool—The device assigns IPv6 addresses from the pool to authenticated users
in the domain.
• Redirect URL—The device redirects users in the domain to the URL after they pass
authentication.
• User group—Authenticated users in the domain obtain all attributes of the user group.
• User profile—The device restricts the user's behavior based on the user profile.
The device assigns the authorization attributes in the ISP domain to the authenticated users that do
not receive these attributes from the server.
Procedure
1. Enter system view.
system-view
2. Enter ISP domain view.
domain isp-name
3. Configure authorization attributes for authenticated users in the ISP domain.
authorization-attribute { acl acl-number | car inbound cir
committed-information-rate [ pir peak-information-rate ] outbound cir
committed-information-rate [ pir peak-information-rate ] | igmp
max-access-number max-access-number | ip-pool ipv4-pool-name |
ipv6-pool ipv6-pool-name | mld max-access-number max-access-number |
url url-string | user-group user-group-name | user-profile
profile-name }
The default settings are as follows:
 An IPv4 user can concurrently join a maximum of four IGMP multicast groups.
 An IPv6 user can concurrently join a maximum of four MLD multicast groups.
 No other authorization attributes exist.

Including the idle timeout period in the user online duration to

be sent to the server
About this task
If a user goes offline due to connection failure or malfunction, the user's online duration sent to the
server includes the idle timeout period assigned by the authorization server. The online duration
generated on the server is longer than the actual online duration of the user.
For portal users, the device includes the idle timeout period set for the online portal user detection
feature in the user online duration. For more information about online detection for portal users, see
"Configuring portal authentication."
Procedure
1. Enter system view.
system-view
2. Enter ISP domain view.
domain isp-name
3. Configure the device to include the idle timeout period in the user online duration to be sent to
the server.
session-time include-idle-time

58
 By default, the user online duration sent to the server does not include the idle timeout period.

Configuring AAA methods for an ISP domain

Configuring authentication methods for an ISP domain
Restrictions and guidelines
When you configure remote authentication, follow these restrictions and guidelines:
• If the authentication method uses a RADIUS scheme and the authorization method does not
use a RADIUS scheme, AAA accepts only the authentication result from the RADIUS server.
The Access-Accept message from the RADIUS server also includes the authorization
information, but the device ignores the information.
• If an HWTACACS scheme is specified, the device uses the entered username for role
authentication. If a RADIUS scheme is specified, the device uses username $enabn$ on the
RADIUS server for role authentication. The variable n represents a user role level. For more
information about user role authentication, see Fundamentals Configuration Guide.
The none keyword is not supported in FIPS mode.
Prerequisites
Before configuring authentication methods, complete the following tasks:
1. Determine the access type or service type to be configured. With AAA, you can configure an
authentication method for each access type and service type.
2. Determine whether to configure the default authentication method for all access types or
service types. The default authentication method applies to all access users. However, the
method has a lower priority than the authentication method that is specified for an access type
or service type.
Procedure
1. Enter system view.
system-view
2. Enter ISP domain view.
domain isp-name
3. (Optional.) Specify default authentication methods for all types of users.
authentication default { hwtacacs-scheme hwtacacs-scheme-name
[ radius-scheme radius-scheme-name ] [ local ] [ none ] | ldap-scheme
ldap-scheme-name [ local ] [ none ] | local [ none ] | none | radius-scheme
radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ]
[ none ] }
By default, the default authentication method is local.
4. Specify authentication methods for a user type or a service.
 Specify authentication methods for LAN users.
authentication lan-access { ldap-scheme ldap-scheme-name [ local ]
[ none ] | local [ none ] | none | radius-scheme radius-scheme-name
[ local ] [ none ] }
By default, the default authentication methods are used for LAN users.
 Specify authentication methods for login users.
authentication login { hwtacacs-scheme hwtacacs-scheme-name
[ radius-scheme radius-scheme-name ] [ local ] [ none ] | ldap-scheme
ldap-scheme-name [ local ] [ none ] | local [ none ] | none |

59
 radius-scheme radius-scheme-name [ hwtacacs-scheme
hwtacacs-scheme-name ] [ local ] [ none ] }
By default, the default authentication methods are used for login users.
 Specify authentication methods for portal users.
authentication portal { ldap-scheme ldap-scheme-name [ local ]
[ none ] | local [ none ] | none | radius-scheme radius-scheme-name
[ local ] [ none ] }
By default, the default authentication methods are used for portal users.
 Specify authentication methods for obtaining a temporary user role.
authentication super { hwtacacs-scheme hwtacacs-scheme-name |
radius-scheme radius-scheme-name } *
By default, the default authentication methods are used for obtaining a temporary user role.

Configuring authorization methods for an ISP domain

Restrictions and guidelines
The device does not support LDAP authorization in the current software version.
To use a RADIUS scheme as the authorization method, specify the name of the RADIUS scheme
that is configured as the authentication method for the ISP domain. If an invalid RADIUS scheme is
specified as the authorization method, RADIUS authentication and authorization fail.
The none keyword is not supported in FIPS mode.
Prerequisites
Before configuring authorization methods, complete the following tasks:
1. Determine the access type or service type to be configured. With AAA, you can configure an
authorization scheme for each access type and service type.
2. Determine whether to configure the default authorization method for all access types or service
types. The default authorization method applies to all access users. However, the method has a
lower priority than the authorization method that is specified for an access type or service type.
Procedure
1. Enter system view.
system-view
2. Enter ISP domain view.
domain isp-name
3. (Optional.) Specify default authorization methods for all types of users.
authorization default { hwtacacs-scheme hwtacacs-scheme-name
[ radius-scheme radius-scheme-name ] [ local ] [ none ] | local [ none ]
| none | radius-scheme radius-scheme-name [ hwtacacs-scheme
hwtacacs-scheme-name ] [ local ] [ none ] }
By default, the authorization method is local.
4. Specify authorization methods for a user type or a service.
 Specify command authorization methods.
authorization command { hwtacacs-scheme hwtacacs-scheme-name
[ local ] [ none ] | local [ none ] | none }
By default, the default authorization methods are used for command authorization.
 Specify authorization methods for LAN users.

60
 authorization lan-access { local [ none ] | none | radius-scheme
radius-scheme-name [ local ] [ none ] }
By default, the default authorization methods are used for LAN users.
 Specify authorization methods for login users.
authorization login { hwtacacs-scheme hwtacacs-scheme-name
[ radius-scheme radius-scheme-name ] [ local ] [ none ] | local [ none ]
| none | radius-scheme radius-scheme-name [ hwtacacs-scheme
hwtacacs-scheme-name ] [ local ] [ none ] }
By default, the default authorization methods are used for login users.
 Specify authorization methods for portal users.
authorization portal { local [ none ] | none | radius-scheme
radius-scheme-name [ local ] [ none ] }
By default, the default authorization methods are used for portal users.

Configuring accounting methods for an ISP domain

Restrictions and guidelines
FTP, SFTP, and SCP users do not support accounting.
Local accounting does not provide statistics for charging. It only counts and controls the number of
concurrent users that use the same local user account. The threshold is configured by using the
access-limit command.
The none keyword is not supported in FIPS mode.
Prerequisites
Before configuring accounting methods, complete the following tasks:
1. Determine the access type or service type to be configured. With AAA, you can configure an
accounting method for each access type and service type.
2. Determine whether to configure the default accounting method for all access types or service
types. The default accounting method applies to all access users. However, the method has a
lower priority than the accounting method that is specified for an access type or service type.
Procedure
1. Enter system view.
system-view
2. Enter ISP domain view.
domain isp-name
3. (Optional.) Specify default accounting methods for all types of users.
accounting default { hwtacacs-scheme hwtacacs-scheme-name
[ radius-scheme radius-scheme-name ] [ local ] [ none ] | local [ none ]
| none | radius-scheme radius-scheme-name [ hwtacacs-scheme
hwtacacs-scheme-name ] [ local ] [ none ] }
By default, the accounting method is local.
4. Specify accounting methods for a user type.
 Specify the command accounting method.
accounting command hwtacacs-scheme hwtacacs-scheme-name
By default, the default accounting methods are used for command accounting.
 Specify accounting methods for LAN users.

61
 accounting lan-access { broadcast radius-scheme
radius-scheme-name1 radius-scheme radius-scheme-name2 [ local ]
[ none ] | local [ none ] | none | radius-scheme radius-scheme-name
[ local ] [ none ] }
By default, the default accounting methods are used for LAN users.
 Specify accounting methods for login users.
accounting login { hwtacacs-scheme hwtacacs-scheme-name
[ radius-scheme radius-scheme-name ] [ local ] [ none ] | local [ none ]
| none | radius-scheme radius-scheme-name [ hwtacacs-scheme
hwtacacs-scheme-name ] [ local ] [ none ] }
By default, the default accounting methods are used for login users.
 Specify accounting methods for portal users.
accounting portal { broadcast radius-scheme radius-scheme-name1
radius-scheme radius-scheme-name2 [ local ] [ none ] | local [ none ] |
none | radius-scheme radius-scheme-name [ local ] [ none ] }
By default, the default accounting methods are used for portal users.
5. (Optional.) Configure extended accounting policies.
 Configure access control for users that encounter accounting-start failures.
accounting start-fail { offline | online }
By default, the device allows users that encounter accounting-start failures to stay online.
 Configure access control for users that have failed all their accounting-update attempts.
accounting update-fail { [ max-times max-times ] offline | online }
By default, the device allows users that have failed all their accounting-update attempts to
stay online.
 Configure access control for users that have used up their data or time accounting quotas.
accounting quota-out { offline | online }
By default, the device logs off users that have used up their accounting quotas.

Display and maintenance commands for ISP domains

Execute display commands in any view.

Task Command
Display configuration information about an ISP
display domain [ isp-name ]
domain or all ISP domains.

Setting the maximum number of concurrent login

users
About this task
Perform this task to set the maximum number of concurrent users that can log on to the device
through a specific protocol, regardless of their authentication methods. The authentication methods
include no authentication, local authentication, and remote authentication.
Procedure
1. Enter system view.

62
 system-view
2. Set the maximum number of concurrent login users.
In non-FIPS mode:
aaa session-limit { ftp | http | https | ssh | telnet } max-sessions
In FIPS mode:
aaa session-limit { https | ssh } max-sessions
By default, the maximum number of concurrent login users is 32 for each user type.

Configuring a NAS-ID
About this task
During RADIUS authentication, the device uses a NAS-ID to set the NAS-Identifier attribute of
RADIUS packets so that the RADIUS server can identify the access location of users.
Configure a NAS-ID profile to maintain NAS-ID and VLAN bindings on the device so that the device
can send different NAS-Identifier attribute strings in RADIUS requests from different VLANs.
Restrictions and guidelines
You can apply a NAS-ID profile to portal- or port security-enabled interfaces. For more information,
see "Configuring portal authentication" and "Configuring port security."
You can configure multiple NAS-ID and VLAN bindings in a NAS-ID profile.
A NAS-ID can be bound with more than one VLAN, but a VLAN can be bound with only one NAS-ID.
If you configure multiple bindings for the same VLAN, the most recent configuration takes effect.
Procedure
1. Enter system view.
system-view
2. Create a NAS-ID profile and enter NAS-ID profile view.
aaa nas-id profile profile-name
3. Configure a NAS-ID and VLAN binding in the profile.
nas-id nas-identifier bind vlan vlan-id

Configuring the device ID

About this task
RADIUS uses the value of the Acct-Session-ID attribute as the accounting ID for a user. The device
generates an Acct-Session-ID value for each online user based on the system time, random digits,
and device ID.
Procedure
1. Enter system view.
system-view
2. Configure the device ID.
aaa device-id device-id
By default, the device ID is 0.

63
Enabling password change prompt logging
About this task
Use this feature to enhance the protection of passwords for Telnet, SSH, HTTP, HTTPS, NETCONF
over SSH, and NETCONF over SOAP users and improve the system security.
This feature enables the device to generate logs to prompt users to change their weak passwords at
an interval of 24 hours and at the users' login.
A password is a weak password if it does not meet the following requirements:
• Password composition restriction configured by using the password-control
composition command.
• Minimum password length restriction set by using the password-control length
command.
• Password complexity checking policy set by using the password-control complexity
command.
For a NETCONF over SSH or NETCONF over SOAP user, the device also generates a password
change prompt log if any of the following conditions exists:
• The current password of the user is the default password or has expired.
• The user logs in to the device for the first time or uses a new password to log in after global
password control is enabled.
The device will no longer generate password change prompt logs for a user when one of the
following conditions exists:
• The password change prompt logging feature is disabled.
• The user has changed the password and the new password meets the password control
requirements.
• The enabling status of a related password control feature has changed so the current password
of the user meets the password control requirements.
• The password composition policy or the minimum password length has changed.
Restrictions and guidelines
You can use the display password-control command to display password control
configuration. For more information about password control commands, see password control
commands in Security Command Reference.
Procedure
1. Enter system view.
system-view
2. Enable password change prompt logging.
local-server log change-password-prompt
By default, password change prompt logging is enabled.

Configuring the RADIUS server feature

RADIUS server feature tasks at a glance
To configure the RADIUS server feature, perform the following tasks:
1. Configuring RADIUS users

64
 2. Specifying RADIUS clients
3. Activating the RADIUS server configuration

Restrictions and guidelines for the RADIUS server feature

To ensure correct operation of the RADIUS server feature, disable RADIUS session-control on the
device.

Configuring RADIUS users

To configure RADIUS users, you must configure network access users, which are the basis of
RADIUS user data.
A RADIUS user has the following attributes: user name, password, description, authorization ACL,
authorization VLAN, and expiration time. For more information, see "Configuring attributes for
network access users."

Specifying RADIUS clients

About this task
Perform this task to specify RADIUS clients and shared keys for centralized management. The
RADIUS server feature does not accept requests from RADIUS clients that are not managed by the
system.
Restrictions and guidelines
The IP address of a RADIUS client must be the same as the source IP address for outgoing RADIUS
packets specified on the RADIUS client.
The shared key of a RADIUS client specified on the RADIUS server must be the same as the setting
on the RADIUS client.
Procedure
1. Enter system view.
system-view
2. Specify a RADIUS client.
radius-server client ip ipv4-address key { cipher | simple } string

Activating the RADIUS server configuration

About this task
At the device startup, the RADIUS server configuration is automatically activated, including RADIUS
users and RADIUS clients. You can immediately activate the most recent RADIUS server
configuration if you have added, modified, or deleted RADIUS clients and network access users from
which RADIUS user data is generated.
Procedure
1. Enter system view.
system-view
2. Activate the RADIUS server configuration.
radius-server activate
Executing this command restarts the RADIUS server process and an authentication service
interruption will occur during the restart.

65
Display and maintenance commands for RADIUS users and
clients
Execute display commands in any view.

Task Command
display radius-server active-user
Display information about activated RADIUS users.
[ user-name ]
display radius-server
Display information about activated RADIUS clients.
active-client

Configuring the connection recording policy

About the connection recording policy
Use this feature on scenarios where the device acts as an FTP, SSH, SFTP, or Telnet login client to
establish a connection with a login server. This feature enables the device to provide an accounting
server with the connection start and termination information. When the login client establishes a
connection with the login server, the system sends a start-accounting request to the accounting
server. When the connection is terminated, the system sends a stop-accounting request to the
accounting server.

Restrictions and guidelines

The device includes the username entered by a user in the accounting packets to be sent to the AAA
server for connection recording. The username format configured by using the
user-name-format command in the accounting scheme does not take effect.

Procedure
1. Enter system view.
system-view
2. Create a connection recording policy and enter its view.
aaa connection-recording policy
3. Specify the accounting method for the connection recording policy.
accounting hwtacacs-scheme hwtacacs-scheme-name

Display and maintenance commands for the connection

recording policy
Execute display commands in any view.

Task Command
Display the connection recording policy display aaa connection-recording
configuration. policy

66
Configuring the AAA test feature
About this task
This feature enables the device to send authentication or accounting requests to the specified AAA
servers to simulate an authentication or accounting process of a user. Use this feature to identify the
reasons for the failure of the interaction between the device and the AAA servers. This feature is
applicable only to RADIUS.
When performing an AAA test, the device ignores the status of the specified AAA servers and the
RADIUS server load sharing feature. The process of an AAA test is as follows:
1. The device sends authentication requests that carry the specified username and password to
the specified authentication server or to the authentication servers in the specified RADIUS
scheme. The device tries to communicate with the authentication servers in the specified
scheme in sequence.
The process goes to the next step in the following situations:
 The device receives an authentication response (no matter the authentication succeeds or
fails).
 The device does not receive any authentication response after making all authentication
request attempts.
This step is skipped if no correct authentication server is specified for the AAA test or no
authentication servers are configured in the specified RADIUS scheme.
2. The device sends start-accounting requests to the specified accounting server or to the
accounting servers in the specified RADIUS scheme. The device tries to communicate with the
accounting servers in the specified scheme in sequence.
The process goes to the next step in the following situations:
 The device receives a start-accounting response (no matter the accounting succeeds or
fails).
 The device does not receive any start-accounting response after making all
start-accounting request attempts.
This step and the next step are skipped if no correct accounting server is specified for the AAA
test or no accounting servers are configured in the specified RADIUS scheme.
3. The device sends stop-accounting requests to the accounting servers to which it has sent a
start-accounting request.
The process finishes in the following situations:
 The device receives a stop-accounting response.
 The device does not receive any stop-accounting response after making all stop-accounting
request attempts.
To identify attributes that cause authentication or accounting failures, you can configure the device to
carry specific attributes in RADIUS requests or define values for specific attributes in the requests.
Table 3 shows the attributes that RADIUS requests carry by default.

67
 Table 3 Attributes that RADIUS requests carry by default

Packet type Attributes that the type of packets carry by default

User-Name
CHAP-Password (or User-Password)
CHAP-Challenge
NAS-IP-Address (or NAS-IPv6-Address)
RADIUS authentication request Service-Type
Framed-Protocol
NAS-Identifier
NAS-Port-Type
Acct-Session-Id
User-Name
Acct-Status-Type
NAS-IP-Address (or NAS-IPv6-Address)
RADIUS accounting request NAS-Identifier
Acct-Session-Id
Acct-Delay-Time
Acct-Terminate-Cause

Restrictions and guidelines

When you perform an AAA test, follow these restrictions and guidelines:
• The device might communicate with the AAA servers incorrectly during an AAA test. Make sure
no users come online or go offline during an AAA text.
• If the configuration of the specified RADIUS scheme changes, the new configuration does not
affect the current AAA test. The modification will take effect in the next test.
• The system can have only one AAA test at a time. Another AAA test can be performed only after
the current test finishes.
When you configure attributes to be included in or excluded from RADIUS requests, follow these
restrictions and guidelines:
• Before you include an attribute that is already configured to be excluded from RADIUS requests,
you must cancel the exclusion configuration by using the undo exclude command.
• Before you exclude an attribute that is already configured to be included in RADIUS requests,
you must cancel the inclusion configuration by using the undo include command.
Prerequisites
Before you perform an AAA test, you must configure a RADIUS scheme that contains the RADIUS
servers to be tested.
Plan the RADIUS attributes to be included in RADIUS requests. Besides the attributes carried by
default, the device adds the specified attributes to RADIUS packets in the order that they are
specified by using the include command. Additional attributes cannot be added to a RADIUS
request if the length of the RADIUS request reaches 4096 bytes.
Procedure
1. (Optional.) Configure a RADIUS attribute test group:
a. Enter system view.
system-view
b. Create a RADIUS attribute test group and enter its view.

68
 radius attribute-test-group attr-test-group-name
You can create multiple RADIUS attribute test groups.
c. Include an attribute in RADIUS requests.
include { accounting | authentication } { name attribute-name |
[ vendor vendor-id ] code attribute-code } type { binary | date |
integer | interface-id | ip | ipv6 | ipv6-prefix | octets | string }
value attribute-value
Use this command to add attributes that RADIUS requests do not carry by default to the
RADIUS requests.
For an attribute that RADIUS requests carry by default, you can use this command to
change its attribute value.
d. Exclude an attribute from RADIUS requests.
exclude { accounting | authentication } name attribute-name
Use this command to exclude an attribute that RADIUS requests carry by default from the
RADIUS requests sent during an AAA test to help troubleshoot authentication or accounting
failures.
e. Return to system view.
quit
f. Return to user view.
quit
2. Perform an AAA test in user view.
test-aaa user user-name password password radius-scheme
radius-scheme-name [ radius-server { ipv4-address | ipv6
ipv6-address } port-number [ vpn-instance vpn-instance-name ] ] [ chap
| pap ] [ attribute-test-group attr-test-group-name ] [ trace ]

AAA configuration examples

Example: Configuring AAA for SSH users by an HWTACACS
server
Network configuration
As shown in Figure 12, configure the switch to meet the following requirements:
• Use the HWTACACS server for SSH user authentication, authorization, and accounting.
• Assign the default user role network-operator to SSH users after they pass authentication.
• Exclude domain names from the usernames sent to the HWTACACS server.
• Use expert as the shared keys for secure HWTACACS communication.

69
 Figure 12 Network diagram

HWTACACS server
10.1.1.1/24

Vlan-int3
Vlan-int2 10.1.1.2/24
192.168.1.70/24
Internet
SSH user Switch

Configuring the HWTACACS server

# Set the shared keys to expert for secure communication with the switch, add an account for the
SSH user, and specify the password. (Details not shown.)
Configuring the switch
# Configure IP addresses for the interfaces. (Details not shown.)
# Create an HWTACACS scheme.
<Switch> system-view
[Switch] hwtacacs scheme hwtac

# Specify the primary authentication server.

[Switch-hwtacacs-hwtac] primary authentication 10.1.1.1 49

# Specify the primary authorization server.

[Switch-hwtacacs-hwtac] primary authorization 10.1.1.1 49

# Specify the primary accounting server.

[Switch-hwtacacs-hwtac] primary accounting 10.1.1.1 49

# Set the shared keys to expert in plaintext form for secure HWTACACS communication.
[Switch-hwtacacs-hwtac] key authentication simple expert
[Switch-hwtacacs-hwtac] key authorization simple expert
[Switch-hwtacacs-hwtac] key accounting simple expert

# Exclude domain names from the usernames sent to the HWTACACS server.
[Switch-hwtacacs-hwtac] user-name-format without-domain
[Switch-hwtacacs-hwtac] quit

# Create an ISP domain named bbb and configure the domain to use the HWTACACS scheme for
authentication, authorization, and accounting of login users.
[Switch-isp-bbb] authentication login hwtacacs-scheme hwtac
[Switch-isp-bbb] authorization login hwtacacs-scheme hwtac
[Switch-isp-bbb] accounting login hwtacacs-scheme hwtac
[Switch-isp-bbb] quit

# Create local RSA and DSA key pairs.

[Switch] public-key local create rsa
[Switch] public-key local create dsa

# Enable the Stelnet service.

[Switch] ssh server enable

# Enable scheme authentication for user lines VTY 0 through VTY 63.

70
 [Switch] line vty 0 63
[Switch-line-vty0-63] authentication-mode scheme
[Switch-line-vty0-63] quit

# Enable the default user role feature to assign authenticated SSH users the default user role
network-operator.
[Switch] role default-role enable

Verifying the configuration

# Initiate an SSH connection to the switch, and enter the correct username and password. The user
logs in to the switch. (Details not shown.)
# Verify that the user can use the commands permitted by the network-operator user role. (Details
not shown.)

Example: Configuring local authentication, HWTACACS

authorization, and RADIUS accounting for SSH users
Network configuration
As shown in Figure 13, configure the switch to meet the following requirements:
• Perform local authentication for SSH users.
• Use the HWTACACS server and RADIUS server for SSH user authorization and accounting,
respectively.
• Exclude domain names from the usernames sent to the servers.
• Assign the default user role network-operator to SSH users after they pass authentication.
Configure an account named hello for the SSH user. Configure the shared keys to expert for secure
communication with the HWTACACS server and RADIUS server.
Figure 13 Network diagram

HWTACACS RADIUS
authorization server accounting server
10.1.1.2/24 10.1.1.1/24

Internet
SSH user Switch

Configuring the HWTACACS server

# Set the shared keys to expert for secure communication with the switch, add an account for the
SSH user, and specify the password. (Details not shown.)
Configuring the RADIUS server
# Set the shared keys to expert for secure communication with the switch, add an account for the
SSH user, and specify the password. (Details not shown.)
Configuring the switch
# Configure IP addresses for interfaces. (Details not shown.)
# Create local RSA and DSA key pairs.

71
 <Switch> system-view
[Switch] public-key local create rsa
[Switch] public-key local create dsa

# Enable the Stelnet service.

[Switch] ssh server enable

# Enable scheme authentication for user lines VTY 0 through VTY 63.
[Switch] line vty 0 63
[Switch-line-vty0-63] authentication-mode scheme
[Switch-line-vty0-63] quit

# Configure an HWTACACS scheme.

[Switch] hwtacacs scheme hwtac
[Switch-hwtacacs-hwtac] primary authorization 10.1.1.2 49
[Switch-hwtacacs-hwtac] key authorization simple expert
[Switch-hwtacacs-hwtac] user-name-format without-domain
[Switch-hwtacacs-hwtac] quit

# Configure a RADIUS scheme.

[Switch] radius scheme rd
[Switch-radius-rd] primary accounting 10.1.1.1 1813
[Switch-radius-rd] key accounting simple expert
[Switch-radius-rd] user-name-format without-domain
[Switch-radius-rd] quit

# Create a device management user.

[Switch] local-user hello class manage

# Assign the SSH service to the local user.

[Switch-luser-manage-hello] service-type ssh

# Set the password to 123456TESTplat&! in plaintext form for the local user. In FIPS mode, you
must set the password in interactive mode.
[Switch-luser-manage-hello] password simple 123456TESTplat&!
[Switch-luser-manage-hello] quit

# Create an ISP domain named bbb and configure the login users to use local authentication,
HWTACACS authorization, and RADIUS accounting.
[Switch] domain bbb
[Switch-isp-bbb] authentication login local
[Switch-isp-bbb] authorization login hwtacacs-scheme hwtac
[Switch-isp-bbb] accounting login radius-scheme rd
[Switch-isp-bbb] quit

# Enable the default user role feature to assign authenticated SSH users the default user role
network-operator.
[Switch] role default-role enable

Verifying the configuration

# Initiate an SSH connection to the switch, and enter username hello@bbb and the correct
password. The user logs in to the switch. (Details not shown.)
# Verify that the user can use the commands permitted by the network-operator user role. (Details
not shown.)

72
Example: Configuring authentication and authorization for
SSH users by a RADIUS server
Network configuration
As shown in Figure 14, configure the switch to meet the following requirements:
• Use the RADIUS server for SSH user authentication and authorization.
• Include domain names in the usernames sent to the RADIUS server.
• Assign the network-admin user role to SSH users after they pass authentication.
The RADIUS server runs IMC PLAT 7.3 (E0605) and IMC UAM 7.3 (E0512). Add an account with
username hello@bbb on the RADIUS server.
The RADIUS server and the switch use expert as the shared key for secure RADIUS communication.
The ports for authentication and accounting are 1812 and 1813, respectively.
Figure 14 Network diagram

RADIUS server
10.1.1.1/24

Vlan-int3
Vlan-int2 10.1.1.2/24
192.168.1.70/24
Internet
SSH user Switch

Configuring the RADIUS server

1. Add the switch to the IMC Platform as an access device:
Log in to IMC, click the User tab, and select User Access Policy > Access Device
Management > Access Device from the navigation tree. Then, click Add to configure an
access device as follows:
a. Set the ports for authentication and accounting to 1812 and 1813, respectively.
b. Select Device Management Service from the Service Type list.
c. Select HP (General) from the Access Device Type list.
d. Set the shared key to expert for secure RADIUS communication.
e. Select an access device from the device list or manually add an access device. In this
example, the device IP address is 10.1.1.2.
f. Use the default values for other parameters and click OK.
The IP address of the access device specified here must be the same as the source IP address
of the RADIUS packets sent from the switch. The source IP address is chosen in the following
order on the switch:
 IP address specified by using the nas-ip command.
 IP address specified by using the radius nas-ip command.
 IP address of the outbound interface (the default).

73
 Figure 15 Adding the switch as an access device

2. Add an account for device management:

Click the User tab, and select Device User > Device User from the navigation tree. Then, click
Add to configure a device management account as follows:
a. Enter account name hello@bbb and specify the password.
b. Select SSH from the Login Type list.
c. Enter user role network-admin.
d. Specify 10.1.1.0 to 10.1.1.255 as the IP address range of the hosts to be managed.
e. Click OK.

NOTE:
The IP address range must contain the IP address of the switch.

74
 Figure 16 Adding an account for device management

Configuring the switch

# Configure IP addresses for interfaces. (Details not shown.)
# Create local RSA and DSA key pairs.
<Switch> system-view
[Switch] public-key local create rsa
[Switch] public-key local create dsa

# Enable the Stelnet service.

[Switch] ssh server enable

# Enable scheme authentication for user lines VTY 0 through VTY 63.
[Switch] line vty 0 63
[Switch-line-vty0-63] authentication-mode scheme
[Switch-line-vty0-63] quit

# Create a RADIUS scheme.

[Switch] radius scheme rad

# Specify the primary authentication server.

[Switch-radius-rad] primary authentication 10.1.1.1 1812

# Set the shared key to expert in plaintext form for secure communication with the server.
[Switch-radius-rad] key authentication simple expert

75
 # Include domain names in the usernames sent to the RADIUS server.
[Switch-radius-rad] user-name-format with-domain
[Switch-radius-rad] quit

# Create an ISP domain named bbb and configure authentication, authorization, and accounting
methods for login users.
[Switch] domain bbb
[Switch-isp-bbb] authentication login radius-scheme rad
[Switch-isp-bbb] authorization login radius-scheme rad
[Switch-isp-bbb] accounting login none
[Switch-isp-bbb] quit

Verifying the configuration

# Initiate an SSH connection to the switch, and enter username hello@bbb and the correct
password. The user logs in to the switch. (Details not shown.)
# Verify that the user can use the commands permitted by the network-admin user role. (Details not
shown.)

Example: Configuring authentication for SSH users by an

LDAP server
Network configuration
As shown in Figure 17, the LDAP server uses domain ldap.com and runs Microsoft Windows 2003
Server Active Directory.
Configure the switch to meet the following requirements:
• Use the LDAP server to authenticate SSH users.
• Assign the level-0 user role to SSH users after they pass authentication.
On the LDAP server, set the administrator password to admin!123456, add a user named aaa, and
set the user's password to ldap!123456.
Figure 17 Network diagram
LDAP server
10.1.1.1/24

Vlan-int3
Vlan-int2 10.1.1.2/24
192.168.1.20/24
IP network

SSH user Switch

192.168.1.21/24

Configuring the LDAP server

1. Add a user named aaa and set the password to ldap!123456:
a. On the LDAP server, select Start > Control Panel > Administrative Tools.
b. Double-click Active Directory Users and Computers.
The Active Directory Users and Computers window is displayed.
c. From the navigation tree, click Users under the ldap.com node.

76
 d. Select Action > New > User from the menu to display the dialog box for adding a user.
e. Enter logon name aaa and click Next.
Figure 18 Adding user aaa

f. In the dialog box, enter password ldap!123456, select options as needed, and click Next.
Figure 19 Setting the user's password

g. Click OK.
2. Add user aaa to group Users:
a. From the navigation tree, click Users under the ldap.com node.
b. In the right pane, right-click user aaa and select Properties.
c. In the dialog box, click the Member Of tab and click Add.

77
 Figure 20 Modifying user properties

d. In the Select Groups dialog box, enter Users in the Enter the object names to select field,
and click OK.
User aaa is added to group Users.
Figure 21 Adding user aaa to group Users

3. Set the administrator password to admin!123456:

a. In the right pane, right-click user Administrator and select Set Password.
b. In the dialog box, enter the administrator password. (Details not shown.)
Configuring the switch
# Configure IP addresses for interfaces. (Details not shown.)

78
 # Create local RSA and DSA key pairs.
<Switch> system-view
[Switch] public-key local create rsa
[Switch] public-key local create dsa

# Enable the Stelnet service.

[Switch] ssh server enable

# Enable scheme authentication for user lines VTY 0 through VTY 63.
[Switch] line vty 0 63
[Switch-line-vty0-63] authentication-mode scheme
[Switch-line-vty0-63] quit

# Configure an LDAP server.

[Switch] ldap server ldap1

# Specify the IP address of the LDAP authentication server.

[Switch-ldap-server-ldap1] ip 10.1.1.1

# Specify the administrator DN.

[Switch-ldap-server-ldap1] login-dn cn=administrator,cn=users,dc=ldap,dc=com

# Specify the administrator password.

[Switch-ldap-server-ldap1] login-password simple admin!123456

# Configure the base DN for user search.

[Switch-ldap-server-ldap1] search-base-dn dc=ldap,dc=com
[Switch-ldap-server-ldap1] quit

# Create an LDAP scheme.

[Switch] ldap scheme ldap-shm1

# Specify the LDAP authentication server.

[Switch-ldap-ldap-shm1] authentication-server ldap1
[Switch-ldap-ldap-shm1] quit

# Create an ISP domain named bbb and configure authentication, authorization, and accounting
methods for login users.
[Switch] domain bbb
[Switch-isp-bbb] authentication login ldap-scheme ldap-shm1
[Switch-isp-bbb] authorization login none
[Switch-isp-bbb] accounting login none
[Switch-isp-bbb] quit

Verifying the configuration

# Initiate an SSH connection to the switch, and enter username aaa@bbb and password
ldap!123456. The user logs in to the switch. (Details not shown.)
# Verify that the user can use the commands permitted by the level-0 user role. (Details not shown.)

Example: Configuring AAA for 802.1X users by a RADIUS

server
Network configuration
As shown in Figure 22, configure the switch to meet the following requirements:
• Use the RADIUS server for authentication, authorization, and accounting of 802.1X users.

79
 • Use MAC-based access control on GigabitEthernet 1/0/1 to authenticate all 802.1X users on
the port separately.
• Include domain names in the usernames sent to the RADIUS server.
In this example, the RADIUS server runs IMC PLAT 7.1 (E0303), IMC UAM 7.1 (E0304), and IMC
CAMS 7.1 (E0301). On the RADIUS server, perform the following tasks:
• Add a service that charges 120 dollars for up to 120 hours per month and assigns authenticated
users to VLAN 4.
• Configure a user with name dot1x@bbb and assign the service to the user.
Set the shared keys to expert for secure RADIUS communication. Set the ports for authentication
and accounting to 1812 and 1813, respectively.
Figure 22 Network diagram

RADIUS server
10.1.1.1/24

Vlan-int3
10.1.1.2/24
Vlan-int2 Vlan-int4
Internet
GE1/0/1

Switch
802.1X user

Configuring the RADIUS server

1. Add the switch to the IMC Platform as an access device:
Log in to IMC, click the User tab, and select User Access Policy > Access Device
Management > Access Device from the navigation tree. Then, click Add to configure an
access device as follows:
a. Set the ports for authentication and accounting to 1812 and 1813, respectively.
b. Select LAN Access Service from the Service Type list.
c. Select HP(General) from the Access Device Type list.
d. Set the shared key to expert for secure authentication and accounting communication.
e. Select an access device from the device list or manually add an access device. In this
example, the device IP address is 10.1.1.2.
f. Use the default values for other parameters and click OK.
The IP address of the access device specified here must be the same as the source IP address
of the RADIUS packets sent from the switch. The source IP address is chosen in the following
order on the switch:
 IP address specified by using the nas-ip command.
 IP address specified by using the radius nas-ip command.
 IP address of the outbound interface (the default).

80
 Figure 23 Adding the switch as an access device

2. Add a charging plan:

Click the User tab, and select Accounting Manager > Charging Plans from the navigation
tree to enter the charging plan configuration page. Then, click Add to configure a charging plan
as follows:
a. Add a plan named UserAcct.
b. Select Flat rate from the Charging Template list.
c. Select time for Charge Based on, select Monthly for Billing Term, and enter 120 in the
Fixed Fee field.
d. Enter 120 in the Usage Threshold field and select hr (hours) for the in field. The
configuration allows the user to access the Internet for up to 120 hours per month.
e. Click OK.

81
 Figure 24 Adding a charging plan

3. Add an access policy:

Click the User tab, and select User Access Policy > Access Policy from the navigation tree.
Then, click Add to configure an access policy as follows:
a. Enter access policy name Dot1x auth.
b. Set the ID of the VLAN to be deployed to 4.
c. Configure other parameters as needed.
d. Click OK.

82
 Figure 25 Adding an access policy

4. Add an access service:

Click the User tab, and select User Access Policy > Access Service from the navigation tree.
Then, click Add to configure a service as follows:
a. Add a service named Dot1x Service, and set the service suffix to bbb, the authentication
domain for the 802.1X user. With the service suffix configured, you must configure the
access device to send usernames that include domain names to the RADIUS server.
b. Select UserAcct from the Charging Plan list.
c. Select Dot1x auth from the Default Access Policy list.
d. Configure other parameters as needed.
e. Click OK.

83
 Figure 26 Adding an access service

5. Add a user:
Click the User tab, and select All Access Users from the navigation tree to enter the All
Access Users page. Then, click Add to configure a user as follows:
a. Select the user or add a user named test.
b. Specify the account name as dot1x and configure the password.
c. Select Dot1x Service in the Access Service area.
d. Configure other parameters as needed and click OK.
Figure 27 Adding an access user account

Configuring the switch

1. Configure a RADIUS scheme:
# Create a RADIUS scheme named rad and enter RADIUS scheme view.
<Switch> system-view

84
 [Switch] radius scheme rad
# Specify the primary authentication server and primary accounting server, and configure the
keys for communication with the servers.
[Switch-radius-rad] primary authentication 10.1.1.1
[Switch-radius-rad] primary accounting 10.1.1.1
[Switch-radius-rad] key authentication simple expert
[Switch-radius-rad] key accounting simple expert
# Include domain names in the usernames sent to the RADIUS server.
[Switch-radius-rad] user-name-format with-domain
[Switch-radius-rad] quit
2. Configure an ISP domain:
# Create an ISP domain named bbb and enter ISP domain view.
[Switch] domain bbb
# Configure the ISP domain to use RADIUS scheme rad for authentication, authorization, and
accounting of LAN users.
[Switch-isp-bbb] authentication lan-access radius-scheme rad
[Switch-isp-bbb] authorization lan-access radius-scheme rad
[Switch-isp-bbb] accounting lan-access radius-scheme rad
[Switch-isp-bbb] quit
3. Configure 802.1X authentication:
# Enable 802.1X globally.
[Switch] dot1x
# Enable 802.1X for GigabitEthernet 1/0/1.
[Switch] interface gigabitethernet 1/0/1
[Switch-GigabitEthernet1/0/1] dot1x
# Configure the access control method. By default, an 802.1X-enabled port uses the
MAC-based access control.
[Switch-GigabitEthernet1/0/1] dot1x port-method macbased

Verifying the configuration

1. On the host, use account dot1x@bbb to pass 802.1X authentication:
# If the host runs the Windows XP 802.1X client, configure the network connection properties as
follows:
a. Click the Authentication tab of the properties window.
b. Select the Enable IEEE 802.1X authentication for this network option.
c. Select MD5 challenge as the EAP type.
d. Click OK.
The user passes authentication after entering the correct username and password on the
authentication page.
# If the host runs the iNode client, no advanced authentication options are required. The user
can pass authentication after entering username dot1x@bbb and the correct password on the
client property page.

IMPORTANT:
Make sure the client can update its IP address to access the resources in the authorized VLAN
after passing authentication.

2. On the switch, verify that the server assigns the port connecting the client to VLAN 4 after the
user passes authentication. (Details not shown.)

85
 3. Display 802.1X connection information on the switch.
[Switch] display dot1x connection

Example: Configuring authentication and authorization for

802.1X users by the device as a RADIUS server
Network configuration
As shown in Figure 28, Switch B acts as the RADIUS server for authentication and authorization of
802.1X users connected to the NAS (Switch A).
Configure the switches to meet the following requirements:
• Perform 802.1X user authentication on GigabitEthernet 1/0/1 of the NAS.
• The shared key is expert and the authentication port is 1812.
• Exclude domain names from the usernames sent to the RADIUS server.
• The user name for 802.1X authentication is dot1x.
• After the user passes authentication, the RADIUS server authorizes VLAN 4 to the NAS port
that the user is connecting to.
Figure 28 Network diagram
RADIUS server

Switch B
Vlan-int3
10.1.1.1/24

Vlan-int3
10.1.1.2/24
Vlan-int2 Vlan-int4
GE1/0/1
Internet
Switch A
NAS
802.1X user

Procedure
1. Configure the NAS:
a. Configure a RADIUS scheme:
# Configure a RADIUS scheme named rad and enter RADIUS scheme view.
<SwitchA> system-view
[SwitchA] radius scheme rad
# Specify the primary authentication server with IP address 10.1.1.1 and set the shared key
to expert in plaintext form.
[SwitchA-radius-rad] primary authentication 10.1.1.1 key simple expert
# Exclude domain names from the usernames sent to the RADIUS server.
[SwitchA-radius-rad] user-name-format without-domain
[SwitchA-radius-rad] quit
b. Configure an ISP domain:
# Create an ISP domain named bbb and enter ISP domain view.
[SwitchA] domain bbb
# Configure the ISP domain to use RADIUS scheme rad for authentication and
authorization of LAN users and not to perform accounting for LAN users.
[SwitchA-isp-bbb] authentication lan-access radius-scheme rad

86
 [SwitchA-isp-bbb] authorization lan-access radius-scheme rad
[SwitchA-isp-bbb] accounting lan-access none
[SwitchA-isp-bbb] quit
c. Configure 802.1X authentication:
# Enable 802.1X for GigabitEthernet 1/0/1.
[SwitchA] interface gigabitethernet 1/0/1
[SwitchA-GigabitEthernet1/0/1] dot1x
# Specify bbb as the mandatory authentication domain for 802.1X users on the interface.
[SwitchA-GigabitEthernet1/0/1] dot1x mandatory-domain bbb
[SwitchA-GigabitEthernet1/0/1] quit
# Enable 802.1X globally.
[SwitchA] dot1x
2. Configure the RADIUS server:
# Create a network access user named dot1x.
<SwitchB> system-view
[SwitchB] local-user dot1x class network
# Configure the password as 123456 in plaintext form.
[SwitchB-luser-network-dot1x] password simple 123456
# Configure VLAN 4 as the authorization VLAN.
[SwitchB-luser-network-dot1x] authorization-attribute vlan 4
[SwitchB-luser-network-dot1x] quit
# Configure the IP address of the RADIUS client as 10.1.1.2 and the shared key as expert in
plaintext form.
[SwitchB] radius-server client ip 10.1.1.2 key simple expert
# Activate the RADIUS server configuration.
[SwitchB] radius-server activate

Verifying the configuration

1. On the RADIUS server, display the activated RADIUS clients and users.
[SwitchB] display radius-server active-client
Total 1 RADIUS clients.
Client IP: 10.1.1.2
[SwitchB] display radius-server active-user dot1x
Total 1 RADIUS users matched.
Username: dot1x
Description: Not configured
Authorization attributes:
VLAN ID: 4
ACL number: Not configured
Validity period:
Expiration time: Not configured
2. On the host, use account dot1x for 802.1X authentication.
If the host runs the Windows built-in 802.1X client, configure the network connection properties
as follows:
a. Click the Authentication tab of the properties window.
b. Select the Enable IEEE 802.1X authentication for this network option.
c. Select MD5 challenge as the EAP type.
d. Click OK.

87
 If the host runs the iNode client, no advanced authentication options are required. The user
passes authentication after entering the correct user name and password on the authentication
page or the iNode client.

IMPORTANT:
Make sure the client can update its IP address to access the resources in the authorized VLAN
after passing authentication.

3. On the NAS, verify that the RADIUS server assigns the port to VLAN 4 after the user passes
authentication. (Details not shown.)
4. On the NAS, display online 802.1X user information.
[SwitchA] display dot1x connection

Troubleshooting AAA
RADIUS authentication failure
Symptom
User authentication always fails.
Analysis
Possible reasons include:
• A communication failure exists between the NAS and the RADIUS server.
• The username is not in the userid@isp-name format, or the ISP domain is not correctly
configured on the NAS.
• The user is not configured on the RADIUS server.
• The password entered by the user is incorrect.
• The RADIUS server and the NAS are configured with different shared keys.
Solution
To resolve the problem:
1. Verify the following items:
 The NAS and the RADIUS server can ping each other.
 The username is in the userid@isp-name format and the ISP domain is correctly configured
on the NAS.
 The user is configured on the RADIUS server.
 The correct password is entered.
 The same shared key is configured on both the RADIUS server and the NAS.
2. If the problem persists, contact Hewlett Packard Enterprise Support.

RADIUS packet delivery failure

Symptom
RADIUS packets cannot reach the RADIUS server.
Analysis
Possible reasons include:
• A communication failure exists between the NAS and the RADIUS server.

88
 • The NAS is not configured with the IP address of the RADIUS server.
• The authentication and accounting UDP ports configured on the NAS are incorrect.
• The RADIUS server's authentication and accounting port numbers are being used by other
applications.
Solution
To resolve the problem:
1. Verify the following items:
 The link between the NAS and the RADIUS server works well at both the physical and data
link layers.
 The IP address of the RADIUS server is correctly configured on the NAS.
 The authentication and accounting UDP port numbers configured on the NAS are the same
as those of the RADIUS server.
 The RADIUS server's authentication and accounting port numbers are available.
2. If the problem persists, contact Hewlett Packard Enterprise Support.

RADIUS accounting error

Symptom
A user is authenticated and authorized, but accounting for the user is not normal.
Analysis
The accounting server configuration on the NAS is not correct. Possible reasons include:
• The accounting port number configured on the NAS is incorrect.
• The accounting server IP address configured on the NAS is incorrect. For example, the NAS is
configured to use a single server to provide authentication, authorization, and accounting
services, but in fact the services are provided by different servers.
Solution
To resolve the problem:
1. Verify the following items:
 The accounting port number is correctly configured.
 The accounting server IP address is correctly configured on the NAS.
2. If the problem persists, contact Hewlett Packard Enterprise Support.

Troubleshooting HWTACACS
Similar to RADIUS troubleshooting. See "RADIUS authentication failure," "RADIUS packet delivery
failure," and "RADIUS accounting error."

LDAP authentication failure

Symptom
User authentication fails.
Analysis
Possible reasons include:
• A communication failure exists between the NAS and the LDAP server.

89
 • The LDAP server IP address or port number configured on the NAS is not correct.
• The username is not in the userid@isp-name format, or the ISP domain is not correctly
configured on the NAS.
• The user is not configured on the LDAP server.
• The password entered by the user is incorrect.
• The administrator DN or password is not configured.
• Some user attributes (for example, the username attribute) configured on the NAS are not
consistent with those configured on the server.
• No user search base DN is specified for the LDAP scheme.
Solution
To resolve the problem:
1. Verify the following items:
 The NAS and the LDAP server can ping each other.
 The IP address and port number of the LDAP server configured on the NAS match those of
the server.
 The username is in the correct format and the ISP domain for the user authentication is
correctly configured on the NAS.
 The user is configured on the LDAP server.
 The correct password is entered.
 The administrator DN and the administrator password are correctly configured.
 The user attributes (for example, the username attribute) configured on the NAS are
consistent with those configured on the LDAP server.
 The user search base DN for authentication is specified.
2. If the problem persists, contact Hewlett Packard Enterprise Support.

Appendixes
Appendix A Commonly used RADIUS attributes
Commonly used RADIUS attributes are defined in RFC 2865, RFC 2866, RFC 2867, and RFC 2868.
Table 4 Commonly used RADIUS attributes

No. Attribute No. Attribute

1 User-Name 45 Acct-Authentic
2 User-Password 46 Acct-Session-Time
3 CHAP-Password 47 Acct-Input-Packets
4 NAS-IP-Address 48 Acct-Output-Packets
5 NAS-Port 49 Acct-Terminate-Cause
6 Service-Type 50 Acct-Multi-Session-Id
7 Framed-Protocol 51 Acct-Link-Count
8 Framed-IP-Address 52 Acct-Input-Gigawords
9 Framed-IP-Netmask 53 Acct-Output-Gigawords
10 Framed-Routing 54 (unassigned)

90
No. Attribute No. Attribute
11 Filter-ID 55 Event-Timestamp
12 Framed-MTU 56-59 (unassigned)
13 Framed-Compression 60 CHAP-Challenge
14 Login-IP-Host 61 NAS-Port-Type
15 Login-Service 62 Port-Limit
16 Login-TCP-Port 63 Login-LAT-Port
17 (unassigned) 64 Tunnel-Type
18 Reply-Message 65 Tunnel-Medium-Type
19 Callback-Number 66 Tunnel-Client-Endpoint
20 Callback-ID 67 Tunnel-Server-Endpoint
21 (unassigned) 68 Acct-Tunnel-Connection
22 Framed-Route 69 Tunnel-Password
23 Framed-IPX-Network 70 ARAP-Password
24 State 71 ARAP-Features
25 Class 72 ARAP-Zone-Access
26 Vendor-Specific 73 ARAP-Security
27 Session-Timeout 74 ARAP-Security-Data
28 Idle-Timeout 75 Password-Retry
29 Termination-Action 76 Prompt
30 Called-Station-Id 77 Connect-Info
31 Calling-Station-Id 78 Configuration-Token
32 NAS-Identifier 79 EAP-Message
33 Proxy-State 80 Message-Authenticator
34 Login-LAT-Service 81 Tunnel-Private-Group-ID
35 Login-LAT-Node 82 Tunnel-Assignment-id
36 Login-LAT-Group 83 Tunnel-Preference
37 Framed-AppleTalk-Link 84 ARAP-Challenge-Response
38 Framed-AppleTalk-Network 85 Acct-Interim-Interval
39 Framed-AppleTalk-Zone 86 Acct-Tunnel-Packets-Lost
40 Acct-Status-Type 87 NAS-Port-Id
41 Acct-Delay-Time 88 Framed-Pool
42 Acct-Input-Octets 89 (unassigned)
43 Acct-Output-Octets 90 Tunnel-Client-Auth-id
44 Acct-Session-Id 91 Tunnel-Server-Auth-id

91
Appendix B Descriptions for commonly used standard
RADIUS attributes
No. Attribute Description
1 User-Name Name of the user to be authenticated.
User password for PAP authentication, only present in Access-Request
2 User-Password
packets when PAP authentication is used.

Digest of the user password for CHAP authentication, only present in

3 CHAP-Password
Access-Request packets when CHAP authentication is used.
IP address for the server to use to identify the client. Typically, a client
4 NAS-IP-Address is identified by the IP address of its access interface. This attribute is
only present in Access-Request packets.
5 NAS-Port Physical port of the NAS that the user accesses.
Type of service that the user has requested or type of service to be
6 Service-Type
provided.

7 Framed-Protocol Encapsulation protocol for framed access.

8 Framed-IP-Address IP address assigned to the user.
Name of the filter list.
11 Filter-ID If the name starts with a digit, it indicates an ACL number.
If the name does not start with a digit, it indicates a user profile name.
MTU for the data link between the user and NAS. For example, this
12 Framed-MTU attribute can be used to define the maximum size of EAP packets
allowed to be processed in 802.1X EAP authentication.
14 Login-IP-Host IP address of the NAS interface that the user accesses.
15 Login-Service Type of service that the user uses for login.
Text to be displayed to the user, which can be used by the server to
18 Reply-Message communicate information, for example, the cause of the authentication
failure.
Vendor-specific proprietary attribute. A packet can contain one or more
26 Vendor-Specific proprietary attributes, each of which can contain one or more
subattributes.
Maximum service duration for the user before termination of the
27 Session-Timeout
session.
Maximum idle time permitted for the user before termination of the
28 Idle-Timeout
session.
ID of the NAS sent to the server.
For wired users, this attribute is typically the MAC address of the user
30 Called-Station-Id access interface. (For PPP users, this attribute is the called number.)
For wireless users, this attribute is the information of the AP to which
the users are connecting.

User identification that the NAS sends to the server. For the LAN
31 Calling-Station-Id access service provided by an HPE device, this attribute includes the
MAC address of the user.
32 NAS-Identifier Identification that the NAS uses to identify itself to the RADIUS server.

92
No. Attribute Description
Type of the Accounting-Request packet. Possible values include:
• 1—Start.
• 2—Stop.
• 3—Interim-Update.
• 4—Reset-Charge.
40 Acct-Status-Type • 7—Accounting-On. (Defined in the 3rd Generation Partnership
Project.)
• 8—Accounting-Off. (Defined in the 3rd Generation Partnership
Project.)
• 9 to 14—Reserved for tunnel accounting.
• 15—Reserved for failed.

Authentication method used by the user. Possible values include:

• 1—RADIUS.
45 Acct-Authentic
• 2—Local.
• 3—Remote.

CHAP challenge generated by the NAS for MD5 calculation during

60 CHAP-Challenge
CHAP authentication.
Type of the physical port of the NAS that is authenticating the user.
Possible values include:
• 15—Ethernet.
• 16—Any type of ADSL.
• 17—Cable. (With cable for cable TV.)
61 NAS-Port-Type
• 19—WLAN-IEEE 802.11.
• 201—VLAN.
• 202—ATM.
If the port is an ATM or Ethernet one and VLANs are implemented on it,
the value of this attribute is 201.
Tunneling protocols used.
64 Tunnel-Type The value 13 represents VLAN. If the value is 13, the device interprets
the Tunnel-Type, Tunnel-Medium-Type, and Tunnel-Private-Group-ID
attributes as attributes to assign VLANs.
Transport medium type to use for creating a tunnel.
65 Tunnel-Medium-Type For VLAN assignment, the value must be 6 to indicate the 802 media
plus Ethernet.

Used to encapsulate EAP packets to allow RADIUS to support EAP

79 EAP-Message
authentication.
Used for authentication and verification of authentication packets to
80 Message-Authenticator prevent spoofing Access-Requests. This attribute is present when EAP
authentication is used.

Group ID for a tunnel session. To assign VLANs, the NAS conveys

81 Tunnel-Private-Group-ID
VLAN IDs by using this attribute.

87 NAS-Port-Id String for describing the port of the NAS that is authenticating the user.
Server-assigned IPv6 address for the NAS to assign to the host. The
168 Framed-IPv6-Address
address must be unique.

93
Appendix C RADIUS subattributes (vendor ID 25506)
Table 5 lists all RADIUS subattributes with a vendor ID of 25506. Support for these subattributes
depends on the device model.
Table 5 RADIUS subattributes (vendor ID 25506)

No. Subattribute Description

1 Input-Peak-Rate Peak rate in the direction from the user to the NAS, in bps.
2 Input-Average-Rate Average rate in the direction from the user to the NAS, in bps.
3 Input-Basic-Rate Basic rate in the direction from the user to the NAS, in bps.
4 Output-Peak-Rate Peak rate in the direction from the NAS to the user, in bps.
5 Output-Average-Rate Average rate in the direction from the NAS to the user, in bps.
6 Output-Basic-Rate Basic rate in the direction from the NAS to the user, in bps.
Total amount of data available for the connection, in different units
15 Remanent_Volume
for different server types.

17 ISP-ID ISP domain where the user obtains authorization information.

Operation for the session, used for session control. Possible
values include:
• 1—Trigger-Request.
20 Command • 2—Terminate-Request.
• 3—SetPolicy.
• 4—Result.
• 5—PortalClear.

Result of the Trigger-Request or SetPolicy operation, zero for

25 Result_Code
success and any other value for failure.
26 Connect_ID Index of the user connection.
27 PortalURL PADM redirect URL assigned to PPPoE users.
FTP, SFTP, or SCP user working directory.
28 Ftp_Directory When the RADIUS client acts as the FTP, SFTP, or SCP server,
this attribute is used to set the working directory for an FTP,
SFTP, or SCP user on the RADIUS client.
29 Exec_Privilege EXEC user priority.
Public IP address assigned to the user when the source IP
32 NAT-IP-Address
address and port are translated.
Start port number of the port range assigned to the user when the
33 NAT-Start-Port
source IP address and port are translated.
End port number of the port range assigned to the user when the
34 NAT-End-Port
source IP address and port are translated.
Startup time of the NAS in seconds, which is represented by the
59 NAS_Startup_Timestamp
time elapsed after 00:00:00 on Jan. 1, 1970 (UTC).
User IP address and MAC address included in authentication and
60 Ip_Host_Addr accounting requests, in the format A.B.C.D hh:hh:hh:hh:hh:hh. A
space is required between the IP address and the MAC address.
Information that must be sent from the server to the client
61 User_Notify
transparently.

94
No. Subattribute Description
Hash value assigned after an 802.1X user passes authentication,
which is a 32-byte string. This attribute is stored in the user list on
62 User_HeartBeat the NAS and verifies the handshake packets from the 802.1X
user. This attribute only exists in Access-Accept and
Accounting-Request packets.
IP address of the multicast group that the user's host joins as a
receiver. This subattribute can appear multiple times in a
98 Multicast_Receive_Group
multicast packet to indicate that the user belongs to multiple
multicast groups.
IPv6 address of the multicast group that the user's host joins as a
receiver. This subattribute can appear multiple times in a
100 IP6_Multicast_Receive_Group
multicast packet to indicate that the user belongs to multiple
multicast groups.
Maximum number of MLD multicast groups that the user can join
101 MLD-Access-Limit
concurrently.

102 local-name L2TP local tunnel name.

Maximum number of IGMP multicast groups that the user can join
103 IGMP-Access-Limit
concurrently.

104 VPN-Instance MPLS L3VPN instance to which a user belongs.

105 ANCP-Profile ANCP profile name.
135 Client-Primary-DNS IP address of the primary DNS server.
136 Client-Secondary-DNS IP address of the secondary DNS server.
User groups assigned after the user passes authentication.
140 User_Group
Typically, a user can belong to only one user group.
Bytes of IPv6 packets in the inbound direction. The measurement
144 Acct_IPv6_Input_Octets
unit depends on the configuration on the device.

Bytes of IPv6 packets in the outbound direction. The

145 Acct_IPv6_Output_Octets
measurement unit depends on the configuration on the device.

Number of IPv6 packets in the inbound direction. The

146 Acct_IPv6_Input_Packets
measurement unit depends on the configuration on the device.

Number of IPv6 packets in the outbound direction. The

147 Acct_IPv6_Output_Packets
measurement unit depends on the configuration on the device.

Bytes of IPv6 packets in the inbound direction. The measurement

148 Acct_IPv6_Input_Gigawords
unit is 4G bytes.

Bytes of IPv6 packets in the outbound direction. The

149 Acct_IPv6_Output_Gigawords
measurement unit is 4G bytes.

155 User-Roles List of space-separated user roles.

95
No. Subattribute Description
User-defined attribute pair. Available attribute pairs include:
• Server-assigned voice VLAN in the format of
device-traffic-class=voice.
• Server-assigned user role in the format of shell:role=xxx.
• Server-assigned ACL in the format of url-redirect-acl=xxx.
• Server-assigned Web redirect URL in the format of
url-redirect=xxx.
• Server-deployed command to reboot a port, in the format of
subscriber:command=bounce-host-port.
• Server-assigned port shutdown duration in the format of
bounce:seconds=xxx.
• Server-deployed command to shut down a port, in the format
of subscriber:command=disable-host-port.
• Server-assigned VSI in the format of vxlan:vsi-name=xxx.
• VSI-based ACL resource assignment capability in the format
of ACL:match-by-vsiindex=x. Value 1 of x indicates that this
feature is supported, and the other values of x are reserved.
• Server-assigned blackhole MAC address attribute in the
210 Av-Pair format of mac:block-mac=xxx.
• Server-assigned MAC authentication offline detect timer (in
seconds) in the format of mac-authentication:
offline-detect-time=xxx. Value 0 of xxx indicates that MAC
authentication offline detection is disabled.
• Server-assigned MAC authentication offline detection flag in
the format of mac-authentication: offline-detect-check=x. x
has the following values:
 0—The device does not search for the ARP snooping
entry or ND snooping entry of the MAC address.
 1—The device searches for the ARP snooping entry or
ND snooping entry of the MAC address.
• Server-assigned dynamic ACL. For more information about
the format of this attribute, see "Appendix D Format of
dynamic authorization ACLs." Support for this attribute in
802.1X authentication and MAC authentication depends on
the device model. If the server assigns a user both this
attribute and the Filter-ID attribute, the device will ignore this
attribute. The device does not support using CoA messages
to change the content assigned by this attribute or assign
another ACL to the user.
DHCP option information for the DHCP client. This attribute
includes the following fields:
• Type—Type of the option attribute. By default, the length of
this field is 1 byte. You can use the
include-attribute 218 vendor-id 25506
218 H3c-DHCP-Option dhcp-option command to change the length of this field
to 2 bytes to meet the requirement of HUAWEI servers.
• Length—Length of the Value field. The Length field is 1
byte.
• Value—Value of the option attribute. This field cannot
exceed 246 bytes.
230 NAS-Port-Name Interface through which the user is connected to the NAS.

96
 No. Subattribute Description
Accounting details. The server sends Access-Accept packets with
subattributes 246 and 250 in the following situations:
• 1—The subscriber charge is overdue. The subscriber is
allowed to access network resources in the whitelist. If the
subscriber accesses other network resources, the device
246 Auth_Detail_Result
redirects it to the URL specified by subattribute 250.
• 2—The broadband lease of the subscriber expires. The
device redirects the subscriber to the URL specified by
subattribute 250 when the subscriber requests to access
webpages for the first time.
Committed burst size from the user to the NAS, in bits. The total
length cannot exceed 4 bytes for this field.
247 Input-Committed-Burst-Size
This subattribute must be assigned together with the
Input-Average-Rate attribute.
Committed burst size from the NAS to the user, in bits. The total
length cannot exceed 4 bytes for this field.
248 Output-Committed-Burst-Size
This subattribute must be assigned together with the
Output-Average-Rate attribute.
Authentication type. The value can be:
• 1—Intranet access authentication.
249 authentication-type • 2—Internet access authentication.
If the packet does not contain this subattribute, common
authentication applies.
250 WEB-URL Redirect URL for users.
251 Subscriber-ID Family plan ID.
252 Subscriber-Profile QoS policy name for the family plan of the subscriber.
255 Product_ID Product name.

Appendix D Format of dynamic authorization ACLs

The server might assign a dynamic authorization ACL that contains multiple rules to a user in
different ways:
• Assign only one Av-Pair subattribute to the user. In this subattribute, the dynamic ACL contains
multiple rules separated by question marks (?).
• Assign multiple Av-Pair subattributes to the user. All the subattributes contain the same
dynamic ACL and a different rule. Support for this method depends on the server model.
The format of a dynamic ACL rule is as follows:
aclrule?same?acl-name?acl-type?ver-type?rule-id?protocol=protocol-type?counting?dst-ip=ip-addr
?src-ip=ip-addr?dst-port=port-value?src-port=port-value?action=action-type
The fields in the rule are described in Table 6. The following is an example of a dynamic ACL rule:
aclrule?same?test?1?1?1?protocol=3?counting?dst-ip=1.1.1.1/1.1.1.1?src-ip=1.1.1.1/0?dst-port=1
.2000?src-port=5.2000-3000?action=1
Table 6 Fields in a dynamic ACL rule

Field Description Remarks

Indicates that the following part is information about a dynamic ACL
aclrule Required
rule.

97
 Field Description Remarks
Indicates that the current user will inherit the dynamic ACL rules that
have been successfully assigned to another authenticated user.
same If the server assigns one user the same dynamic ACL as another user Required
but the rules are different for the two users, the device applies the
dynamic ACL rules of the user that comes online first to the other
user.
ACL name, a case-insensitive string of 1 to 63 characters. The ACL
acl-name name must begin with a letter and it cannot be all or the same as an Required
existing static ACL on the device.
ACL type. 1 indicates an advanced ACL. In the current software
acl-type Required
version, only advanced ACLs are supported.
IP protocol type:
ver-type • 1—IPv4. Required
• 2—IPv6.

rule-id ACL rule number, in the range of 0 to 65534. Required

Protocol type:
• 1—IP.
• 2—ICMP.
protocol-type • 3—TCP. Optional
• 4—UDP.
• 5—ICMPv6.
• 6—IPv6.

Indicates that rule match statistics is enabled. If a rule does not

counting Optional
include this field, rule match statistics is disabled for the rule.
IP address information. For example, 1.1.1.1/1.1.1.1, 1.1.1.1/0, or
ip-addr 3::3/128. Optional
If the value is any, the rule matches any IP address.
TCP or UDP port information, in the X.YYY format.
• X—Operator.
 1—Equal to.
 2—Greater than.
port-value  3—Smaller than. Optional
 4—Not equal to.
 5—In the range of.
• YYY—Port number information.
For example, 1.3000 and 5.2000-3000.
Action type:
action-type • 1—Deny. Optional
• 2—Permit.

The following restrictions apply to dynamic authorization ACLs:

• For the former six fields (aclrule?same?acl-name?acl-type?ver-type?rule-id) of a dynamic ACL
rule, their positions are fixed. The device cannot interpret a dynamic ACL rule if the positions of
the six fields are changed. For the other fields, position changes are allowed.
• The settings for all the fields in the rules must meet the configuration logic of ACL rules on the
device so the device can correctly interpret the rules.
• All dynamic ACL rules in one authorization must belong to the same ACL name.
• A dynamic ACL must have rules and the format of the rules must be valid.

98
802.1X overview
About the 802.1X protocol
802.1X is a port-based network access control protocol widely used on Ethernet networks. The
protocol controls network access by authenticating the devices connected to 802.1X-enabled LAN
ports.

802.1X architecture
802.1X operates in the client/server model. As shown in Figure 29, 802.1X authentication includes
the following entities:
• Client (supplicant)—A user terminal seeking access to the LAN. The terminal must have
802.1X software to authenticate to the access device.
• Access device (authenticator)—Authenticates the client to control access to the LAN. In a
typical 802.1X environment, the access device uses an authentication server to perform
authentication.
• Authentication server—Provides authentication 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 authentication results to the access device to make access
decisions. The authentication server is typically a RADIUS server. In a small LAN, you can use
the access device as the authentication server.
Figure 29 802.1X architecture

Device Authentication server

Client

Controlled/uncontrolled port and port authorization status

802.1X defines two logical ports for the network access port: controlled port and uncontrolled port.
Any packet arriving at the network access port is visible to both logical ports.
• Uncontrolled port—Is always open to receive and transmit authentication packets.
• Controlled port—Filters packets depending on the port state.
 Authorized state—The controlled port is in authorized state when the client has passed
authentication. The port allows traffic to pass through.
 Unauthorized state—The port is in unauthorized state when the client has failed
authentication. The port controls traffic by using one of the following methods:
− Performs bidirectional traffic control to deny traffic to and from the client.
− Performs unidirectional traffic control to deny traffic from the client. The device supports
only unidirectional traffic control.

99
 Figure 30 Authorization state of a controlled port

Authenticator system 1 Authenticator system 2

Controlled port Uncontrolled port Controlled port Uncontrolled port

Port unauthorized Port authorized

LAN LAN

Packet exchange methods

802.1X uses the Extensible Authentication Protocol (EAP) to transport authentication information for
the client, the access device, and the authentication server. EAP is an authentication framework that
uses the client/server model. The framework supports a variety of authentication methods, including
MD5-Challenge, EAP-Transport Layer Security (EAP-TLS), and Protected EAP (PEAP).
802.1X defines EAP over LAN (EAPOL) for passing EAP packets between the client and the access
device over a wired or wireless LAN. Between the access device and the authentication server,
802.1X delivers authentication information by either EAP relay or EAP termination.
EAP relay
EAP relay is defined in IEEE 802.1X. In this mode, the network device uses EAP over RADIUS
(EAPOR) packets to send authentication information to the RADIUS server, as shown in Figure 31.
Figure 31 EAP relay
Client RADIUS server
Device
EAP packets over LAN EAP packets over RADIUS

EAP authentication

In EAP relay mode, the client must use the same authentication method as the RADIUS server. On
the access device, you only need to use the dot1x authentication-method eap command
to enable EAP relay.
EAP termination
As shown in Figure 32, the access device performs the following operations in EAP termination
mode:
1. Terminates the EAP packets received from the client.
2. Encapsulates the client authentication information in standard RADIUS packets.
3. Uses PAP or CHAP to authenticate to the RADIUS server.

100
 Figure 32 EAP termination
Client RADIUS server
Device
EAP packets over LAN RADIUS

EAP authentication PAP/CHAP authentication

Comparing EAP relay and EAP termination

Packet exchange
Benefits Limitations
method
• Supports various EAP The RADIUS server must support the
authentication methods. EAP-Message and
EAP relay • The configuration and Message-Authenticator attributes, and
processing are simple on the the EAP authentication method used by
access device. the client.
• Supports only the following EAP
authentication methods:
 MD5-Challenge EAP
Works with any RADIUS server authentication.
EAP termination that supports PAP or CHAP  The username and password
authentication. EAP authentication initiated by
an iNode 802.1X client.
• The processing is complex on the
access device.

Packet formats
EAP packet format
Figure 33 shows the EAP packet format.
Figure 33 EAP packet format
0 7 15

Code Identifier 2
Length 4

Data
N

• Code—Type of the EAP packet. Options include Request (1), Response (2), Success (3), or
Failure (4).
• Identifier—Used for matching Responses with Requests.
• Length—Length (in bytes) of the EAP packet. The EAP packet length is the sum of the Code,
Identifier, Length, and Data fields.
• Data—Content of the EAP packet. This field appears only in a Request or Response EAP
packet. The Data field contains the request type (or the response type) and the type data. Type
1 (Identity) and type 4 (MD5-Challenge) are two examples for the type field.
EAPOL packet format
Figure 34 shows the EAPOL packet format.

101
 Figure 34 EAPOL packet format
0 7 15

PAE Ethernet type 2

Protocol version Type 4
Length 6

Packet body
N

• PAE Ethernet type—Protocol type. It takes the value 0x888E for EAPOL.
• Protocol version—The EAPOL protocol version used by the EAPOL packet sender.
• Type—Type of the EAPOL packet. Table 7 lists the types of EAPOL packets supported by the
802.1X implementation of the device.
Table 7 Types of EAPOL packets

Value Type Description

The client and the access device uses EAP-Packets to transport
0x00 EAP-Packet
authentication information.

The client sends an EAPOL-Start message to initiate 802.1X

0x01 EAPOL-Start
authentication to the access device.

The client sends an EAPOL-Logoff message to tell the access

0x02 EAPOL-Logoff
device that the client is logging off.

• Length—Data length in bytes, or length of the Packet body. If packet type is EAPOL-Start or
EAPOL-Logoff, this field is set to 0, and no Packet body field follows.
• Packet body—Content of the packet. When the EAPOL packet type is EAP-Packet, the Packet
body field contains an EAP packet.
EAP over RADIUS
RADIUS adds two attributes, EAP-Message and Message-Authenticator, for supporting EAP
authentication. For the RADIUS packet format, see "Configuring AAA."
• EAP-Message.
RADIUS encapsulates EAP packets in the EAP-Message attribute, as shown in Figure 35. The
Type field takes 79, and the Value field can be up to 253 bytes. If an EAP packet is longer than
253 bytes, RADIUS encapsulates it in multiple EAP-Message attributes.
Figure 35 EAP-Message attribute format
0 7 15 N

Type＝79 Length Value

EAP packets

• Message-Authenticator.
As shown in Figure 36, RADIUS includes the Message-Authenticator attribute in all packets that
have an EAP-Message attribute to check their integrity. The packet receiver drops the packet if
the calculated packet integrity checksum is different from the Message-Authenticator attribute
value. The Message-Authenticator prevents EAP authentication packets from being tampered
with during EAP authentication.

102
 Figure 36 Message-Authenticator attribute format
0 1 2 18 bytes

Type＝80 Length Value

802.1X authentication procedures

802.1X authentication has two methods: EAP relay and EAP termination. You choose either mode
depending on support of the RADIUS server for EAP packets and EAP authentication methods.
EAP relay
Figure 37 shows the basic 802.1X authentication procedure in EAP relay mode, assuming that
MD5-Challenge EAP authentication is used.
Figure 37 802.1X authentication procedure in EAP relay mode
Client Device Authentication server

EAPOL EAPOR

(1) EAPOL-Start

(2) EAP-Request/Identity

(3) EAP-Response/Identity (4) RADIUS Access-Request

(EAP-Response/Identity)
(5) RADIUS Access-Challenge
(EAP-Request/MD5-Challenge)
(6) EAP-Request/MD5-Challenge

(7) EAP-Response/MD5-Challenge (8) RADIUS Access-Request

(EAP-Response/MD5-Challenge)
(9) RADIUS Access-Accept
(EAP-Success)
(10) EAP-Success

Port authorized
(11) EAP-Request/Identity

(12) EAP-Response/Identity
...
(13) EAPOL-Logoff

Port unauthorized
(14) EAP-Failure

The following steps describe the 802.1X authentication procedure:

1. When a user launches the 802.1X client and enters a registered username and password, the
802.1X client sends an EAPOL-Start packet to the access device.
2. The access device responds with an EAP-Request/Identity packet to ask for the client
username.
3. In response to the EAP-Request/Identity packet, the client sends the username in an
EAP-Response/Identity packet to the access device.

103
 4. The access device relays the EAP-Response/Identity packet in a RADIUS Access-Request
packet to the authentication server.
5. The authentication server uses the identity information in the RADIUS Access-Request to
search its user database. If a matching entry is found, the server uses a randomly generated
challenge (EAP-Request/MD5-Challenge) to encrypt the password in the entry. Then, the
server sends the challenge in a RADIUS Access-Challenge packet to the access device.
6. The access device transmits the EAP-Request/MD5-Challenge packet to the client.
7. The client uses the received challenge to encrypt the password, and sends the encrypted
password in an EAP-Response/MD5-Challenge packet to the access device.
8. The access device relays the EAP-Response/MD5-Challenge packet in a RADIUS
Access-Request packet to the authentication server.
9. The authentication server compares the received encrypted password with the encrypted
password it generated at step 5. If the two passwords are identical, the server considers the
client valid and sends a RADIUS Access-Accept packet to the access device.
10. Upon receiving the RADIUS Access-Accept packet, the access device performs the following
operations:
a. Sends an EAP-Success packet to the client.
b. Sets the controlled port in authorized state.
The client can access the network.
11. After the client comes online, the access device periodically sends handshake requests to
check whether the client is still online. By default, if two consecutive handshake attempts fail,
the device logs off the client.
12. Upon receiving a handshake request, the client returns a response. If the client fails to return a
response after a number of consecutive handshake attempts (two by default), the access
device logs off the client. This handshake mechanism enables timely release of the network
resources used by 802.1X users that have abnormally gone offline.
13. The client can also send an EAPOL-Logoff packet to ask the access device for a logoff.
14. In response to the EAPOL-Logoff packet, the access device changes the status of the
controlled port from authorized to unauthorized. Then, the access device sends an EAP-Failure
packet to the client.
EAP termination
Figure 38 shows the basic 802.1X authentication procedure in EAP termination mode, assuming that
CHAP authentication is used.

104
 Figure 38 802.1X authentication procedure in EAP termination mode
Client Device Authentication server

EAPOL RADIUS

(1) EAPOL-Start

(2) EAP-Request/Identity

(3) EAP-Response/Identity

(4) EAP-Request/MD5-Challenge

(5) EAP-Response/MD5-Challenge
(6) RADIUS Access-Request
(CHAP-Response/MD5-Challenge)
(7) RADIUS Access-Accept
(CHAP-Success)

(8) EAP-Success

Port authorized
(9) EAP-Request/Identity

(10) EAP-Response/Identity
...

(11) EAPOL-Logoff

Port unauthorized
(12) EAP-Failure

In EAP termination mode, the access device rather than the authentication server generates an MD5
challenge for password encryption. The access device then sends the MD5 challenge together with
the username and encrypted password in a standard RADIUS packet to the RADIUS server.

802.1X authentication initiation

Both the 802.1X client and the access device can initiate 802.1X authentication.
802.1X client as the initiator
The client sends an EAPOL-Start packet to the access device to initiate 802.1X authentication. The
destination MAC address of the packet is the IEEE 802.1X specified multicast address
01-80-C2-00-00-03 or the broadcast MAC address. If any intermediate device between the client
and the authentication server does not support the multicast address, you must use an 802.1X client
that can send broadcast EAPOL-Start packets. For example, you can use the iNode 802.1X client.
Access device as the initiator
If the client cannot send EAPOL-Start packets, configure the access device to initiate authentication.
One example is the 802.1X client available with Windows XP.
The access device supports the following modes:
• Multicast trigger mode—The access device multicasts EAP-Request/Identity packets to
initiate 802.1X authentication at the identity request interval.

105
 • Unicast trigger mode—Upon receiving a frame from an unknown MAC address, the access
device sends an EAP-Request/Identity packet out of the receiving port to the MAC address.
The device retransmits the packet if no response has been received within the identity request
timeout interval. This process continues until the maximum number of request attempts set by
using the dot1x retry command is reached.
The username request timeout timer sets both the identity request interval for the multicast trigger
and the identity request timeout interval for the unicast trigger.

Access control methods

The device implements port-based access control as defined in the 802.1X protocol, and extends the
protocol to support MAC-based access control.
• Port-based access control—Once an 802.1X user passes authentication on a port, any
subsequent user 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 authenticated on a port. When a user
logs off, no other online users are affected.

802.1X VLAN manipulation

Authorization VLAN
The authorization VLAN controls the access of an 802.1X user to authorized network resources. The
device supports authorization VLANs assigned locally or by a remote server.

IMPORTANT:
Only remote servers can assign tagged authorization VLANs.

Remote VLAN authorization

In remote VLAN authorization, you must configure an authorization VLAN for a user on the remote
server. After the user authenticates to the server, the server assigns authorization VLAN information
to the device. Then, the device assigns the user access port to the authorization VLAN as a tagged
or untagged member.
The device supports assignment of the following authorization VLAN information by the remote
server:
• VLAN ID.
• VLAN name, which must be the same as the VLAN description on the access device.
• A string of VLAN IDs and VLAN names.
In the string, some VLANs are represented by their IDs, and some VLANs are represented by
their names.
• VLAN group name.
For more information about VLAN groups, see Layer 2—LAN Switching Configuration Guide.
• VLAN ID with a suffix of t or u.
The t and u suffixes require the device to assign the access port to the VLAN as a tagged or
untagged member, respectively. For example, 2u indicates assigning the port to VLAN 2 as an
untagged member.
If a VLAN name or VLAN group name is assigned, the device converts the information into a VLAN
ID before VLAN assignment.

106
 IMPORTANT:
For a VLAN represented by its VLAN name to be assigned successfully, you must make sure the
VLAN has been created on the device.
To assign VLAN IDs with suffixes, make sure the user access port is a hybrid or trunk port that
performs port-based access control.

To ensure a successful assignment, the authorization VLANs assigned by the remote server cannot
be any of the following types:
• Dynamically learned VLANs.
• Reserved VLANs.
• Super VLANs.
• Private VLANs.
If the server assigns a group of VLANs, the access device selects a VLAN as described in Table 8.
Table 8 Authorization VLAN selection from a group of VLANs

VLAN information Authorization VLAN selection

If the 802.1X-enabled port performs MAC-based access control, the
device selects an authorization VLAN from the VLAN group for a user
according to the following rules:
• On a hybrid port with MAC-based VLAN enabled:
 If the port does not have online users, the device selects the
VLAN with the lowest ID.
 If the port has online users, the device selects the VLAN that has
the fewest online users. If two VLANs have the same number of
VLANs by IDs online 802.1X users, the device selects the VLAN with the lower
ID.
VLANs by names
• On an access, trunk, or MAC-based VLAN disabled hybrid port:
VLAN group name  If the port does not have online users, the device selects the
VLAN with the lowest ID.
 If the port has online users, the device examines the VLAN
group for the VLAN of the online users. If the VLAN is found, the
VLAN is assigned to the user as the authorization VLAN. If the
VLAN is not found, VLAN authorization fails.
If the 802.1X-enabled port performs port-based access control, the
device selects the VLAN with the lowest ID from the VLAN group. All
subsequent 802.1X users are assigned to that VLAN.
1. The device selects the leftmost VLAN ID without a suffix, or the
leftmost VLAN ID suffixed by u as an untagged VLAN, whichever is
more leftmost.
2. The device assigns the untagged VLAN to the port as the PVID, and
it assigns the remaining as tagged VLANs. If no untagged VLAN is
VLAN IDs with suffixes assigned, the PVID of the port does not change. The port permits
traffic from these tagged and untagged VLANs to pass through.
For example, the authentication server sends the string 1u 2t 3 to the
access device for a user. The device assigns VLAN 1 as an untagged
VLAN and all remaining VLANs (including VLAN 3) as tagged VLANs.
VLAN 1 becomes the PVID.

Local VLAN authorization

To perform local VLAN authorization for a user, specify the VLAN ID in the authorization attribute list
of the local user account for that user. For each local user, you can specify only one authorization
VLAN ID. The user access port is assigned to the VLAN as an untagged member.

107
 IMPORTANT:
Local VLAN authorization does not support assignment of tagged VLANs.

For more information about local user configuration, see "Configuring AAA."
Authorization VLAN manipulation on an 802.1X-enabled port
Table 9 describes how the access device handles VLANs (except for the VLANs specified with
suffixes) on an 802.1X-enabled port.
Table 9 VLAN manipulation

Port access control

VLAN manipulation
method
The device assigns the port to the first authenticated user's authorization
VLAN. All subsequent 802.1X users can access the VLAN without
authentication.
If the authorization VLAN has the untagged attribute, the device assigns the
port to the authorization VLAN as an untagged member and sets the VLAN
Port-based as the PVID.
If the authorization VLAN has the tagged attribute, the device assigns the
port to the VLAN as a tagged member without changing the PVID.
NOTE:
The tagged attribute is supported only on trunk and hybrid ports.
On a hybrid port with MAC-based VLAN enabled, the device maps the MAC
address of each user to its own authorization VLAN. The PVID of the port
does not change.
On an access, trunk, or MAC-based VLAN disabled hybrid port:
MAC-based • The device assigns the port to the first authenticated user's
authorization VLAN and sets the VLAN as the PVID if that authorization
VLAN has the untagged attribute.
• If the authorization VLAN has the tagged attribute, the device assigns
the port to the authorization VLAN without changing its PVID.

IMPORTANT:
• If the users are attached to a port whose link type is access, make sure the authorization VLAN
assigned by the server has the untagged attribute. VLAN assignment will fail if the server issues
a VLAN that has the tagged attribute.
• When you assign VLANs to users attached to a trunk port or a MAC-based VLAN disabled hybrid
port, make sure there is only one untagged VLAN. If a different untagged VLAN is assigned to a
subsequent user, the user cannot pass authentication.
• As a best practice to enhance network security, do not use the port hybrid vlan command
to assign a hybrid port to an authorization VLAN as a tagged member.

The VLAN assigned by the server to a user as an authorization VLAN might have been configured on
the user access port but with a different tagging mode. For example, the server assigns an
authorization VLAN with a tagged attribute, but the same VLAN configured on the port has an
untagged attribute. In this situation, the VLAN settings that take effect on the user depend on the link
type of the port.
• If the link type of the port is access or trunk, the authorization VLAN settings assigned by the
server always take effect on the user as long as the user is online. After the user goes offline,
the VLAN settings on the port take effect.
• If the link type of the port is hybrid, the VLAN settings configured on the port take effect. For
example, the server assigns VLAN 30 with an untagged attribute to a user on the hybrid port.

108
 However, VLAN 30 has been configured on the port with a tagged attribute by using the port
hybrid vlan tagged command. Finally, the VLAN has a tagged attribute on the port.
For an 802.1X authenticated user to access the network on a hybrid port when no authorization
VLAN is configured for the user, perform one of the following tasks:
• If the port receives tagged authentication packets from the user in a VLAN, use the port
hybrid vlan command to configure the port as a tagged member in the VLAN.
• If the port receives untagged authentication packets from the user in a VLAN, use the port
hybrid vlan command to configure the port as an untagged member in the VLAN.
On a port with periodic online user reauthentication enabled, the MAC-based VLAN feature does not
take effect on a user that has been online since before this feature was enabled. The access device
creates a MAC-to-VLAN mapping for the user when the following requirements are met:
• The user passes reauthentication.
• The authorization VLAN for the user is changed.
For more information about VLAN configuration and MAC-based VLANs, see Layer 2—LAN
Switching Configuration Guide.

Guest VLAN
The 802.1X guest VLAN on a port accommodates users that have not performed 802.1X
authentication. Users in the guest VLAN can access a limited set of network resources, such as a
software server, to download antivirus software and system patches. Once a user in the guest 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.
Port-based access control

Authentication status VLAN manipulation

The device assigns the port to the 802.1X guest VLAN. All 802.1X users on
A user accesses the this port can access only resources in the guest VLAN.
802.1X-enabled port when
the port is in auto state. The guest VLAN assignment varies by port link mode. For more information,
see Table 9 in "Authorization VLAN."

If an 802.1X Auth-Fail VLAN is available, the device assigns the port to the
Auth-Fail VLAN. All users on this port can access only resources in the
A user in the 802.1X guest Auth-Fail VLAN.
VLAN fails 802.1X
If no Auth-Fail VLAN is configured, the port is still in the 802.1X guest VLAN.
authentication.
All users on the port are in the guest VLAN.
For information about the 802.1X Auth-Fail VLAN, see "Auth-Fail VLAN."

The device removes the port from the 802.1X guest VLAN and assigns the
port to the authorization VLAN of the user.
If the authentication server does not assign an authorization VLAN, the initial
A user in the 802.1X guest PVID of the port applies. The user and all subsequent 802.1X users are
VLAN passes 802.1X assigned to the initial port VLAN.
authentication. After the user logs off, the port is assigned to the guest VLAN again.
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.

109
 IMPORTANT:
When the port receives a packet with a VLAN tag, the packet will be forwarded within the tagged
VLAN if the VLAN is not the guest VLAN.

MAC-based access control

Authentication status VLAN manipulation

A user accesses the
802.1X-enabled port and The device creates a mapping between the MAC address of the user and the
has not performed 802.1X 802.1X guest VLAN. The user can access only resources in the guest VLAN.
authentication.

If an 802.1X Auth-Fail VLAN is available, the device remaps the MAC

A user in the 802.1X guest address of the user to the Auth-Fail VLAN. The user can access only
VLAN fails 802.1X resources in the Auth-Fail VLAN.
authentication. If no 802.1X Auth-Fail VLAN is configured, the user is removed from the
guest VLAN and added to the initial PVID.

A user in the 802.1X guest The device remaps the MAC address of the user to the authorization VLAN.
VLAN passes 802.1X If the authentication server does not assign an authorization VLAN, the
authentication. device remaps the MAC address of the user to the initial PVID on the port.

Auth-Fail VLAN
The 802.1X Auth-Fail VLAN on a port accommodates users that have failed 802.1X authentication
because of the failure to comply with the organization security strategy. For example, the VLAN
accommodates users that have entered a wrong password. Users in the Auth-Fail VLAN can access
a limited set of network resources, such as a software server, to download antivirus software and
system patches.
The access device handles VLANs on an 802.1X-enabled port based on its 802.1X access control
method.
Port-based access control

Authentication status VLAN manipulation

The device assigns the port to the Auth-Fail VLAN. All 802.1X users on this
A user accesses the port port can access only resources in the Auth-Fail VLAN.
and fails 802.1X
authentication. The Auth-Fail VLAN assignment varies by port link mode. For more
information, see Table 9 in "Authorization VLAN."

A user in the 802.1X

The port is still in the Auth-Fail VLAN, and all 802.1X users on this port are in
Auth-Fail VLAN fails 802.1X
this VLAN.
authentication.

The device assigns the port to the authorization VLAN of the user, and it
removes the port from the Auth-Fail VLAN.
A user in the 802.1X If the authentication server does not assign an authorization VLAN, the initial
Auth-Fail VLAN passes PVID of the port applies. The user and all subsequent 802.1X users are
802.1X authentication. assigned to the initial PVID.
After the user logs off, the port is assigned to the guest VLAN. If no guest
VLAN is configured, the port is assigned to the initial PVID of the port.

110
MAC-based access control

Authentication status VLAN manipulation

A user accesses the port
The device maps the MAC address of the user to the 802.1X Auth-Fail VLAN.
and fails 802.1X
The user can access only resources in the Auth-Fail VLAN.
authentication.

A user in the 802.1X

Auth-Fail VLAN fails 802.1X The user is still in the Auth-Fail VLAN.
authentication.

A user in the 802.1X The device remaps the MAC address of the user to the authorization VLAN.
Auth-Fail VLAN passes If the authentication server does not assign an authorization VLAN, the
802.1X authentication. device remaps the MAC address of the user to the initial PVID on the port.

Critical VLAN
The 802.1X critical VLAN on a port accommodates 802.1X users that have failed authentication
because none of the RADIUS servers in their ISP domain are reachable. Users in the critical VLAN
can access a limited set of network resources depending on the configuration.
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. For more information about the authentication methods, see
"Configuring AAA."
The access device handles VLANs on an 802.1X-enabled port based on its 802.1X access control
method.
Port-based access control

Authentication status VLAN manipulation

The device assigns the port to the critical VLAN. The 802.1X
A user accesses the port and fails 802.1X user and all subsequent 802.1X users on this port can access
authentication because all the RADIUS only resources in the 802.1X critical VLAN.
servers are unreachable. The critical VLAN assignment varies by port link mode. For
more information, see Table 9 in "Authorization VLAN."

A user in the 802.1X critical VLAN fails

authentication because all the RADIUS The port is still in the critical VLAN.
servers are unreachable.

A user in the 802.1X critical VLAN fails If an 802.1X Auth-Fail VLAN has been configured, the port is
authentication for any reason other than assigned to the Auth-Fail VLAN. If no 802.1X Auth-Fail VLAN is
unreachable servers. configured, the port is assigned to the initial PVID of the port.

The device assigns the port to the authorization VLAN of the

user, and it removes the port from the 802.1X critical VLAN.
If the authentication server does not assign an authorization
A user in the 802.1X critical VLAN passes VLAN, the initial PVID of the port applies. The user and all
802.1X authentication. subsequent 802.1X users are assigned to this port VLAN.
After the user logs off, the port is assigned to the guest VLAN. If
no 802.1X guest VLAN is configured, the initial PVID of the port
is restored.

111
 Authentication status VLAN manipulation
A user in the 802.1X guest VLAN fails
The device assigns the port to the 802.1X critical VLAN, and all
authentication because all the RADIUS
802.1X users on this port are in this VLAN.
servers are unreachable.
A user in the 802.1X Auth-Fail VLAN fails The port is still in the 802.1X Auth-Fail VLAN. All 802.1X users
authentication because all the RADIUS on this port can access only resources in the 802.1X Auth-Fail
servers are unreachable. VLAN.

A user that has passed authentication

fails reauthentication because all the
The device assigns the port to the 802.1X critical VLAN.
RADIUS servers are unreachable, and
the user is logged out of the device.

If the port is added to the critical VLAN because no RADIUS servers are reachable, the device
performs the following operations after it detects a reachable RADIUS server:
1. Removes the port from the critical VLAN.
2. Sends a multicast EAP-Request/Identity message out of the port to trigger authentication.
MAC-based access control

Authentication status VLAN manipulation

A user accesses the port and fails 802.1X The device maps the MAC address of the user to the 802.1X
authentication because all the RADIUS critical VLAN. The user can access only resources in the
servers are unreachable. 802.1X critical VLAN.

A user in the 802.1X critical VLAN fails

authentication because all the RADIUS The user is still in the critical VLAN.
servers are unreachable.

If an 802.1X Auth-Fail VLAN has been configured, the

device remaps the MAC address of the user to the Auth-Fail
A user in the 802.1X critical VLAN fails VLAN ID.
802.1X authentication for any reason other
than unreachable servers. If no 802.1X Auth-Fail VLAN has been configured, the
device remaps the MAC address of the user to the initial
PVID.

The device remaps the MAC address of the user to the

authorization VLAN.
A user in the 802.1X critical VLAN passes
802.1X authentication. If the authentication server does not assign an authorization
VLAN to the user, the device remaps the MAC address of
the user to the initial PVID on the port.

A user in the 802.1X guest VLAN fails The device remaps the MAC address of the user to the
authentication because all the RADIUS 802.1X critical VLAN. The user can access only resources in
servers are unreachable. the 802.1X critical VLAN.
A user in the 802.1X Auth-Fail VLAN fails
authentication because all the RADIUS The user remains in the 802.1X Auth-Fail VLAN.
servers are unreachable.

If a user is added to the critical VLAN because no RADIUS servers are reachable, the device
performs the following operations after it detects a reachable RADIUS server:
1. Removes the user from the critical VLAN.
2. Sends a unicast EAP-Request/Identity message out of the port to the user for reauthentication.

112
Critical voice VLAN
The 802.1X critical voice VLAN on a port accommodates 802.1X voice users that have failed
authentication because none of the RADIUS servers in their ISP domain are reachable.
The critical voice VLAN feature takes effect when 802.1X authentication is performed only through
RADIUS servers. If an 802.1X voice user fails local authentication after RADIUS authentication, the
voice user is not assigned to the critical voice VLAN. For more information about the authentication
methods, see "Configuring AAA."
When a reachable RADIUS server is detected, the device performs operations on a port based on its
802.1X access control method.
Port-based access control
When a reachable RADIUS server is detected, the device removes the port from the critical voice
VLAN. The port sends a multicast EAP-Request/Identity packet to all 802.1X voice users on the port
to trigger authentication.
MAC-based access control
When a reachable RADIUS server is detected, the device removes 802.1X voice users from the
critical voice VLAN. The port sends a unicast EAP-Request/Identity packet to each 802.1X voice
user that was assigned to the critical voice VLAN to trigger authentication.

802.1X VSI manipulation

IMPORTANT:
This feature is supported only on 802.1X-enabled ports that perform MAC-based access control.

802.1X support for VXLANs

As shown in Figure 39, when the device acts as both a VXLAN VTEP and a NAS, users' service
information cannot be identified by VLANs. To resolve this issue, you must configure the RADIUS
server to assign VSIs to authenticated 802.1X users. The NAS will map a user's traffic to the VXLAN
that is associated with the user's authorization VSI. The mapping criteria include the user's access
VLAN, access port, and MAC address. MAC address information is required only when the access
port performs MAC-based access control.
For information about VSIs and VXLANs, see VXLAN Configuration Guide.

113
 Figure 39 VXLAN network diagram for 802.1X authentication

Internet

RADIUS servers

VXLAN
NAS NAS
(VTEP) (VTEP)
Distribution layer

AC Access layer

802.1X-enabled port

Client Client Client AP Client

Authorization VSI
An authorization VSI is associated with a VXLAN that has network resources inaccessible to
unauthenticated users.
802.1X supports remote VSI authorization. When a user passes remote 802.1X authentication, the
remote server assigns the authorization VSI information of the user to the user's access port. Upon
receiving the authorization VSI information, the VTEP performs the following operations:
• Dynamically creates an Ethernet service instance based on the user's access port, VLAN, and
MAC address.
• Maps the Ethernet service instance to the authorization VSI.
The user then can access resources in the VXLAN associated with the authorization VSI.
If the VTEP does not receive authorization VSI information for the user from the remote server, the
user cannot access resources in any VXLAN after passing authentication.
For information about dynamic creation of Ethernet service instances, see VXLAN configuration
Guide.

Guest VSI
The 802.1X guest VSI on a port accommodates users that have not performed 802.1X
authentication. You can deploy a limited set of network resources in the VXLAN that is associated
with the guest VSI. For example, deploy a software server for users to download anti-virus software
and system patches. Once a user in the guest VSI passes 802.1X authentication, the user is
removed from the guest VSI and can access authorized network resources.
The access device handles VSIs on an 802.1X-enabled port, as shown in Table 10:

114
 Table 10 VSI manipulation when a guest VSI is configured

Authentication status VSI manipulation

A user accesses the port and The VTEP maps the user's MAC address and access VLAN to the 802.1X
has not performed 802.1X guest VSI on the port. The user can access only resources in the VXLAN
authentication. associated with the guest VSI.

If an 802.1X Auth-Fail VSI is available on the port, the VTEP remaps the
A user in the 802.1X guest user's MAC address and access VLAN to the Auth-Fail VSI. The user can
VSI fails 802.1X access only resources in the VXLAN associated with the Auth-Fail VSI.
authentication. If no 802.1X Auth-Fail VSI is configured on the port, the user is removed from
the 802.1X guest VSI.

A user in the 802.1X guest

The VTEP removes the user from the 802.1X guest VSI and remaps the
VSI passes 802.1X
user's MAC address and access VLAN to the authorization VSI.
authentication.

Auth-Fail VSI
The 802.1X Auth-Fail VSI on a port accommodates users that have failed 802.1X authentication
because of the failure to comply with the organization security strategy. For example, the VSI
accommodates users with wrong passwords entered. Users in the Auth-Fail VSI can access a
limited set of network resources in the VXLAN associated with this VSI. You can deploy a software
server in the Auth-Fail VSI for users to download antivirus software and system patches.
The access device handles VSIs on an 802.1X-enabled port, as shown in Table 11:
Table 11 VSI manipulation when an Auth-Fail VSI is configured

Authentication status VSI manipulation

A user accesses the port The VTEP maps the user's MAC address and access VLAN to the 802.1X
and fails 802.1X Auth-Fail VSI on the port. The user can access only resources in the VXLAN
authentication. associated with the Auth-Fail VSI.

A user in the 802.1X

Auth-Fail VSI fails 802.1X
authentication because of The user is still in the Auth-Fail VSI.
any reason other than
unreachable servers.

A user in the 802.1X

The VTEP removes the user from the 802.1X Auth-Fail VSI and remaps the
Auth-Fail VSI passes
user's MAC address and access VLAN to the authorization VSI.
802.1X authentication.

Critical VSI
The 802.1X critical VSI on a port accommodates 802.1X users that have failed authentication
because none of the RADIUS servers in their ISP domain are reachable. Users in the critical VSI can
access a limited set of network resources in the VXLAN associated with this VSI.
The critical VSI 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 VSI. For more information about the authentication methods, see
"Configuring AAA."

115
 The access device handles VSIs on an 802.1X-enabled port, as shown in Table 12:
Table 12 VSI manipulation when a critical VSI is configured

Authentication status VSI manipulation

A user accesses the port and fails 802.1X The VTEP maps the user's MAC address and access VLAN
authentication because all the RADIUS to the 802.1X critical VSI on the port. The user can access
servers are unreachable. only resources in the VXLAN associated with the critical VSI.

A user in the 802.1X critical VSI fails

authentication because all the RADIUS The user is still in the critical VSI.
servers are unreachable.

If an 802.1X Auth-Fail VSI has been configured on the port,

A user in the 802.1X critical VSI fails 802.1X the VTEP remaps the user's MAC address and access
authentication for any reason other than VLAN to the Auth-Fail VSI.
unreachable servers. If no 802.1X Auth-Fail VSI has been configured on the port,
the VTEP logs off the user.

A user in the 802.1X critical VSI passes The VTEP remaps the user's MAC address and access
802.1X authentication. VLAN to the authorization VSI.

A user in the 802.1X guest VSI fails The VTEP maps the user's MAC address and access VLAN
authentication because all the RADIUS to the 802.1X critical VSI on the port. The user can access
servers are unreachable. only resources in the VXLAN associated with the critical VSI.

A user in the 802.1X Auth-Fail VSI fails

authentication because all the RADIUS The user remains in the 802.1X Auth-Fail VSI.
servers are unreachable.

ACL assignment
You can specify an authorization ACL for an 802.1X user on a remote server or the access device to
control the user's access to network resources. After the user passes 802.1X authentication, the
server or access device assigns the authorization ACL to the user access port. Then, the port
permits or drops the matching traffic for the user depending on the rules in the ACL.
The device supports assignment of static and dynamic authorization ACLs.
• Assignment of static authorization ACLs—Static ACLs can be assigned by a RADIUS
server or the access device. When the server or access device assigns a static ACL to a user, it
assigns only the ACL number. You must manually create the ACL and configure its rules on the
access device.
To change the access permissions of a user, you can use one of the following methods:
 Modify ACL rules in the authorization ACL on the access device.
 Assign another ACL to the user as the authorization ACL from the RADIUS server or the
access device.
Static ACLs and their rules can be manually deleted from the access device.
• Assignment of dynamic authorization ACLs—Dynamic ACLs and their rules are
automatically deployed by a RADIUS server, which are not configurable on the access device.

116
 Dynamic ACLs can only be named ACLs. After the device receives a server-deployed dynamic
ACL and its rules, it automatically creates the ACL and configures its rules.
If the dynamic ACL assigned by the server to a user has the same name as a static ACL, the
dynamic ACL cannot be issued and the user cannot come online.
A dynamic ACL and its rules are automatically deleted from the access device after all its users
go offline.
Dynamic ACLs and their rules cannot be manually modified or deleted on the access device. To
display information about dynamic ACLs and their rules, use the display dot1x
connection or display acl command.

IMPORTANT:
The supported authorization ACLs include the following types:
• Basic ACLs, which are numbered in the range of 2000 to 2999.
• Advanced ACLs, which are numbered in the range of 3000 to 3999.
• Layer 2 ACLs, which are numbered in the range of 4000 to 4999.
For an authorization ACL to take effect, make sure the ACL exists with rules and none of the rules
contains the counting, established, fragment, source-mac, or logging keyword.
For more information about ACLs, see ACL and QoS Configuration Guide.

User profile assignment

You can specify a user profile for an 802.1X user on the authentication server to control the user's
access to network resources. After the user passes 802.1X authentication, the authentication server
assigns the user profile to the user for filtering traffic.
The authentication server can be the local access device or a RADIUS server. In either case, the
server only specifies the user profile name. You must configure the user profile on the access device.
To change the user's access permissions, you can use one of the following methods:
• Modify the user profile configuration on the access device.
• Specify another user profile for the user on the authentication server.
For more information about user profiles, see "Configuring user profiles."

Redirect URL assignment

The device supports the URL attribute assigned by a RADIUS server when the 802.1X-enabled port
performs MAC-based access control and the port authorization state is auto. During authentication,
the HTTP or HTTPS requests of an 802.1X user are redirected to the Web interface specified by the
server-assigned URL attribute. After the user passes the Web authentication, the RADIUS server
records the MAC address of the user and uses a DM (Disconnect Message) to log off the user. When
the user initiates 802.1X authentication again, it will pass the authentication and come online
successfully.
This feature is mutually exclusive with the EAD assistant feature.
By default, the device listens to port 6654 for HTTPS requests to be redirected. To change the
redirect listening port number, see configuring HTTP redirect in Layer 3—IP Services Configuration
Guide.

117
CAR attribute assignment
The device can use the CAR attributes assigned through RADIUS extended attributes to control the
access rates of authenticated online 802.1X users. For information about extended RADIUS
attributes, see "Configuring AAA."
The following CAR attributes are available:
• Input-Peak-Rate—Peak rate of inbound traffic in bps.
• Input-Average-Rate—Average rate of inbound traffic in bps.
• Output-Peak-Rate—Peak rate of outbound traffic in bps.
• Output-Average-Rate—Average rate of outbound traffic in bps.
If the server assigns CAR attributes for controlling both the peak and average rates, the device
implements double-rate traffic policing on user traffic. If the server does not assign the
Input-Peak-Rate or Output-Peak-Rate attribute, the device implements single-rate traffic policing on
user traffic. For more information about traffic policing, see QoS configuration in ACL and QoS
Configuration Guide.

Periodic 802.1X reauthentication

Periodic 802.1X reauthentication tracks the connection status of online users and updates the
authorization attributes (such as ACL and VLAN) assigned by the server.
The device reauthenticates online 802.1X users at the periodic reauthentication interval when the
periodic online user reauthentication feature is enabled. The interval is controlled by a timer and the
timer is user configurable. A change to the periodic reauthentication timer applies to online users
only after the old timer expires and the users pass authentication.
The server-assigned session timeout timer (Session-Timeout attribute) and termination action
(Termination-Action attribute) together can affect the periodic online user reauthentication feature. To
display the server-assigned Session-Timeout and Termination-Action attributes, use the display
dot1x connection command (see Security Command Reference).
• If the termination action is Default (logoff), periodic online user reauthentication on the device
takes effect only when the periodic reauthentication timer is shorter than the session timeout
timer.
• If the termination action is Radius-request, the periodic online user reauthentication settings
on the device do not take effect. The device reauthenticates the online 802.1X users after the
session timeout timer expires.
If no session timeout timer is assigned by the server, whether the device performs periodic 802.1X
reauthentication depends on the periodic reauthentication configuration on the device. Support for
the assignment of Session-Timeout and Termination-Action attributes depends on the server model.
With the RADIUS DAS feature enabled, the device immediately reauthenticates a user upon
receiving a CoA message that carries the reauthentication attribute from a RADIUS authentication
server. In this case, reauthentication will be performed regardless of whether 802.1X periodic
reauthentication is enabled on the device. For more information about RADIUS DAS configuration,
see "Configuring AAA."
By default, the device logs off online 802.1X users if no server is reachable for 802.1X
reauthentication. The keep-online feature keeps authenticated 802.1X users online when no server
is reachable for 802.1X reauthentication.
The VLANs assigned to an online user before and after reauthentication can be the same or
different.

118
EAD assistant
Endpoint Admission Defense (EAD) is an integrated endpoint access control solution to improve the
threat defensive capability of a network. The solution enables the security client, security policy
server, access device, and third-party server 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 the HTTP or HTTPS requests of a
user to a redirect URL for downloading and installing an EAD client. This feature eliminates the
administrative task to deploy EAD clients.
EAD assistant is implemented by the following functionality:
• Free IP.
A free IP is a freely accessible network segment, which has a limited set of network resources
such as software and DHCP servers. To ensure security strategy compliance, an
unauthenticated user can access only this segment to perform operations. For example, the
user can download EAD client from a software server or obtain a dynamic IP address from a
DHCP server.
• Redirect URL.
If an unauthenticated 802.1X user is using a Web browser to access the network, EAD
assistant redirects the network access requests of the user to a specific URL. For example, you
can use this feature to redirect the user to the EAD client software download page.
The EAD assistant feature creates an ACL-based EAD rule automatically to open access to the
redirect URL for each redirected user.
EAD rules are implemented by using ACL resources. When the EAD rule timer expires or the user
passes authentication, the rule is removed. If users fail to download EAD client or fail to pass
authentication before the timer expires, they must reconnect to the network to access the free IP.

119
Configuring 802.1X
Restrictions and guidelines: 802.1X configuration
You can configure the port security feature to perform 802.1X. Port security combines and extends
802.1X and MAC authentication. It applies to a network (a WLAN, for example) that requires different
authentication methods for different users on a port. For more information about the port security
feature, see "Configuring port security."
When you configure 802.1X settings on an interface, follow these restrictions and guidelines:
• 802.1X is supported only on Layer 2 Ethernet interfaces and Layer 2 aggregate interfaces.
• If you add a Layer 2 Ethernet interface to an aggregation group, the 802.1X settings configured
on it will not take effect until it is removed from the aggregation group.
• Do not delete a Layer 2 aggregate interface if the interface has online 802.1X users.
• Do not change the link type of a port when the 802.1X guest VLAN, Auth-Fail VLAN, or critical
VLAN on the port has users.
When you configure 802.1X VLANs or VSIs, follow these restrictions and guidelines:
• If the server assigns both an authorization VSI and authorization VLAN to a user, the device
uses only the authorization VLAN.
• On a port, the guest VLAN, Auth-Fail VLAN, and critical VLAN settings are mutually exclusive
with the guest VSI, Auth-Fail VSI, and critical VSI settings.
• To ensure a successful authentication, you must configure the authentication server to assign
authorization VLANs or VSIs to the 802.1X users attached to a port in the following situations:
 If the port is configured with the guest VLAN, Auth-Fail VLAN, or critical VLAN, you must
configure VLAN authorization for the 802.1X users.
 If the port is configured with the guest VSI, Auth-Fail VSI, or critical VSI, you must configure
VSI authorization for the 802.1X users.
 If both 802.1X and MAC authentication are configured on the port, be careful with the VSI
settings of the two authentication features.
− You must configure VSI authorization for the 802.1X users if the port has a guest or
critical VSI for MAC authentication.
− Likewise, you must configure VSI authorization for the MAC authentication users if the
port has an Auth-Fail, guest, or critical VSI for 802.1X authentication.

802.1X tasks at a glance

To configure 802.1X authentication, perform the following tasks:
1. Enabling 802.1X
2. Configuring basic 802.1X features
 Enabling EAP relay or EAP termination
 Setting the port authorization state
 Specifying an access control method
 (Optional.) Specifying a mandatory authentication domain on a port
 (Optional.) Setting the 802.1X authentication timeout timers
 (Optional.) Configuring 802.1X reauthentication
 (Optional.) Setting the quiet timer

120
 3. (Optional.) Configuring 802.1X VLAN assignment
 Configuring an 802.1X guest VLAN
 Enabling 802.1X guest VLAN assignment delay
 Configuring an 802.1X Auth-Fail VLAN
 Configuring an 802.1X critical VLAN
 Enabling the 802.1X critical voice VLAN feature
4. (Optional.) Configuring 802.1X VSI assignment
 Configuring an 802.1X guest VSI
 Enabling 802.1X guest VSI assignment delay
 Configuring an 802.1X Auth-Fail VSI
 Configuring an 802.1X critical VSI
5. (Optional.) Setting the upper limit for 802.1X parameters
 Setting the maximum number of concurrent 802.1X users on a port
 Setting the maximum number of authentication request attempts
 Setting the maximum number of 802.1X authentication attempts for MAC authenticated
users
6. (Optional.) Configuring other 802.1X features
 Configuring 802.1X unauthenticated user aging
 Sending EAP-Success packets on assignment of users to the 802.1X Auth-Fail VLAN or
VSI
 Sending EAP-Success packets on assignment of users to the 802.1X critical VLAN or VSI
 Enabling 802.1X online user synchronization
 Configuring the authentication trigger feature
Perform this task when 802.1X clients cannot initiate authentication.
 Discarding duplicate 802.1X EAPOL-Start requests
 Configuring online user handshake
 Specifying supported domain name delimiters
 Removing the VLAN tags of 802.1X protocol packets sent out of a port
 Enabling 802.1X user IP freezing
 Enabling generation of dynamic IPSG binding entries for 802.1X authenticated users
 Configuring 802.1X MAC address binding
 Configuring the EAD assistant feature
 Setting the maximum size of EAP-TLS fragments sent to the server
Use this feature to reduce the size of authentication packets sent to the server when the
device uses EAP-TLS authentication method in EAP relay mode.
 Logging off 802.1X users
 Enabling 802.1X user logging

Prerequisites for 802.1X

Before you configure 802.1X, complete the following tasks:
• Configure an ISP domain and AAA scheme (local or RADIUS authentication) for 802.1X users.
• If RADIUS authentication is used, create user accounts on the RADIUS server.
• If local authentication is used, create local user accounts on the access device and set the
service type to lan-access.

121
Enabling 802.1X
Restrictions and guidelines
For 802.1X to take effect on a port, you must enable it both globally and on the port.
If the PVID is a voice VLAN, the 802.1X feature cannot take effect on the port. For more information
about voice VLANs, see Layer 2—LAN Switching Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enable 802.1X globally.
dot1x
By default, 802.1X is disabled globally.
3. Enter interface view.
interface interface-type interface-number
4. Enable 802.1X on a port.
dot1x
By default, 802.1X is disabled on a port.

Enabling EAP relay or EAP termination

About this task
Consider the following factors to select a proper EAP mode:
• Support of the RADIUS server for EAP packets.
• Authentication methods supported by the 802.1X client and the RADIUS server.
Restrictions and guidelines
• If EAP relay mode is used, the user-name-format command configured in RADIUS
scheme view does not take effect. The access device sends the authentication data from the
client to the server without any modification. For more information about the
user-name-format command, see Security Command Reference.
• You can use both EAP termination and EAP relay in any of the following situations:
 The client is using only MD5-Challenge EAP authentication. If EAP termination is used, you
must enable CHAP authentication on the access device.
 The client is an iNode 802.1X client and initiates only the username and password EAP
authentication. If EAP termination is used, you can enable either PAP or CHAP
authentication on the access device. However, for the purpose of security, you must use
CHAP authentication on the access device.
• To use EAP-TLS, PEAP, or any other EAP authentication methods, you must use EAP relay.
When you make your decision, see "Comparing EAP relay and EAP termination" for help.
Procedure
1. Enter system view.
system-view
2. Configure EAP relay or EAP termination.
dot1x authentication-method { chap | eap | pap }

122
 By default, the access device performs EAP termination and uses CHAP to communicate with
the RADIUS server.

Setting the port authorization state

About this task
The port authorization state determines whether the client is granted access to the network. You can
control the following authorization states of a port:
• 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 EAPOL packets to pass. After
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.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Set the port authorization state.
dot1x port-control { authorized-force | auto | unauthorized-force }
By default, the auto state applies.

Specifying an access control method

About this task
The device supports port-based and MAC-based access control methods.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Specify an access control method.
dot1x port-method { macbased | portbased }
By default, MAC-based access control applies.

CAUTION:
If online 802.1X users are present on a port, changing its access control method will cause the
online users to go offline.

123
Specifying a mandatory authentication domain on
a port
About this task
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 account in any other domain to access
the network through the port. The implementation of a mandatory authentication domain enhances
the flexibility of 802.1X access control deployment.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Specify a mandatory 802.1X authentication domain on the port.
dot1x mandatory-domain domain-name
By default, no mandatory 802.1X authentication domain is specified.

Setting the 802.1X authentication timeout timers

About this task
The network device uses the following 802.1X authentication timeout timers:
• Client timeout timer—Starts when the access device sends an EAP-Request/MD5-Challenge
packet to a client. If no response is received when this timer expires, the access device
retransmits the request to the client.
• Server timeout timer—Starts when the access device sends a RADIUS Access-Request
packet to the authentication server. If no response is received when this timer expires, the
802.1X authentication fails.
Restrictions and guidelines
In most cases, the default settings are sufficient. You can edit the timers, depending on the network
conditions.
• In a low-speed network, increase the client timeout timer.
• In a network with authentication servers of different performance, adjust the server timeout
timer.
To avoid forced logoff before the server timeout timer expires, set the server timeout timer to a value
that is lower than or equal to the product of the following values:
• The maximum number of RADIUS packet transmission attempts set by using the retry
command in RADIUS scheme view.
• The RADIUS server response timeout timer set by using the timer response-timeout
command in RADIUS scheme view.
For information about setting the maximum number of RADIUS packet transmission attempts and
the RADIUS server response timeout timer, see "Configuring AAA."
Procedure
1. Enter system view.
system-view

124
 2. Set the client timeout timer.
dot1x timer supp-timeout supp-timeout-value
The default is 30 seconds.
3. Set the server timeout timer.
dot1x timer server-timeout server-timeout-value
The default is 100 seconds.

Configuring 802.1X reauthentication

Restrictions and guidelines
The device selects a periodic reauthentication timer for 802.1X reauthentication in the following
order:
1. Server-assigned reauthentication timer.
2. Port-specific reauthentication timer.
3. Global reauthentication timer.
4. Default reauthentication timer.
After you perform a manual reauthentication, the device reauthenticates all online 802.1X users on a
port regardless of the server-assigned reauthentication attribute and the periodic reauthentication
feature on the port.
Modification to the mandatory authentication domain or EAP message handling method setting does
not affect the reauthentication of online 802.1X users. The modified setting takes effect only on
802.1X users that come online after the modification.
If periodic reauthentication is triggered for a user while that user is waiting for online synchronization,
the system performs online synchronization and does not perform reauthentication for the user.
Procedure
1. Enter system view.
system-view
2. Set the periodic reauthentication timer.
 Set a global periodic reauthentication timer.
dot1x timer reauth-period reauth-period-value
The default setting is 3600 seconds.
 Execute the following commands in sequence to set a port-specific periodic
reauthentication timer:
interface interface-type interface-number
dot1x timer reauth-period reauth-period-value
quit
By default, no periodic reauthentication timer is set on a port. The port uses the global
802.1X periodic reauthentication timer.
3. Enter interface view.
interface interface-type interface-number
4. Enable periodic online user reauthentication.
dot1x re-authenticate
By default, the feature is disabled.
5. (Optional.) Manually reauthenticate all online 802.1X users on the port.
dot1x re-authenticate manual

125
 6. (Optional.) Enable the keep-online feature for 802.1X users.
dot1x re-authenticate server-unreachable keep-online
By default, this feature is disabled. The device logs off online 802.1X users if no authentication
server is reachable for 802.1X reauthentication.
Use the keep-online feature according to the actual network condition. In a fast-recovery
network, you can use the keep-online feature to prevent 802.1X users from coming online and
going offline frequently.

Setting the quiet timer

About this task
The quiet timer enables the access device to wait a period of time before it can process any
authentication request from a client that has failed an 802.1X authentication.
Restrictions and guidelines
You can edit the quiet timer, depending on the network conditions.
• In a vulnerable network, set the quiet timer to a high value.
• In a high-performance network with quick authentication response, set the quiet timer to a low
value.
Procedure
1. Enter system view.
system-view
2. Enable the quiet timer.
dot1x quiet-period
By default, the timer is disabled.
3. Set the quiet timer.
dot1x timer quiet-period quiet-period-value
The default is 60 seconds.

Configuring an 802.1X guest VLAN

Restrictions and guidelines
• You can configure only one 802.1X guest VLAN on a port. The 802.1X guest VLANs on different
ports can be different.
• Assign different IDs to the port VLAN, the voice VLAN, and the 802.1X guest VLAN on a port.
The assignment makes sure the port can correctly process incoming VLAN-tagged traffic.
• For the 802.1X guest VLAN feature to work correctly, do not configure this feature together with
EAD assistant.
• On a hybrid port, the guest VLAN can only be an untagged VLAN.
• If a voice VLAN and an 802.1X guest VLAN are both configured on a hybrid port, the voice
VLAN has higher priority than the 802.1X guest VLAN. A packet is forwarded out of the voice
VLAN if it matches the voice VLAN settings. If it does not match the voice VLAN settings, its
source MAC address might be added to the 802.1X guest VLAN.
• When you configure multiple security features on a port, follow the guidelines in Table 13.

126
 Table 13 Relationships of the 802.1X guest VLAN and other security features

Feature Relationship description Reference

See Layer 2—LAN
You cannot specify a VLAN as both a super
Super VLAN Switching Configuration
VLAN and an 802.1X guest VLAN.
Guide.

802.1X Auth-Fail VLAN

on a port that performs The 802.1X Auth-Fail VLAN has a higher See "802.1X VLAN
MAC-based access priority than the 802.1X guest VLAN. manipulation."
control

The 802.1X guest VLAN feature has higher

Port intrusion protection priority than the block MAC action.
actions on a port that See "Configuring port
performs MAC-based The 802.1X guest VLAN feature has lower security."
access control priority than the shutdown port action of the
port intrusion protection feature.

Prerequisites
Before you configure an 802.1X guest VLAN, complete the following tasks:
• Create the VLAN to be specified as the 802.1X guest VLAN.
• If the 802.1X-enabled port performs MAC-based access control, perform the following
operations for the port:
 Configure the port as a hybrid port.
 Enable MAC-based VLAN on the port. For more information about MAC-based VLANs, see
Layer 2—LAN Switching Configuration Guide.
• If the port type is hybrid, verify that the VLAN to be specified as the guest VLAN is not in the
tagged VLAN list on the port.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Configure the 802.1X guest VLAN on the port.
dot1x guest-vlan guest-vlan-id
By default, no 802.1X guest VLAN exists on a port.

Enabling 802.1X guest VLAN assignment delay

About this task
This feature delays assigning an 802.1X-enabled port to the 802.1X guest VLAN when 802.1X
authentication is triggered on the port.
This feature applies only to situations where 802.1X authentication is triggered by EAPOL-Start
packets from 802.1X clients or packets from unknown MAC addresses.
To use this feature, the 802.1X-enabled port must perform MAC-based access control. To use the
new MAC-triggered 802.1X guest VLAN assignment delay, you must also configure 802.1X unicast
trigger on the port.
When 802.1X authentication is triggered on a port, the device performs the following operations:

127
 1. Sends a unicast EAP-Request/Identity packet to the MAC address that triggers the
authentication.
2. Retransmits the packet if no response is received within the username request timeout interval
set by using the dot1x timer tx-period command.
3. Assigns the port to the 802.1X guest VLAN after the maximum number of request attempts set
by using the dot1x retry command is reached.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable 802.1X guest VLAN assignment delay on the port.
dot1x guest-vlan-delay { eapol | new-mac }
By default, 802.1X guest VLAN assignment delay is disabled on a port.

Configuring an 802.1X Auth-Fail VLAN

Restrictions and guidelines
• Assign different IDs to the port VLAN, the voice VLAN, and the 802.1X Auth-Fail VLAN on a port.
The assignment makes sure the port can correctly process VLAN-tagged incoming traffic.
• You can configure only one 802.1X Auth-Fail VLAN on a port. The 802.1X Auth-Fail VLANs on
different ports can be different.
• On a hybrid port, the Auth-Fail VLAN can only be an untagged VLAN.
• When you configure multiple security features on a port, follow the guidelines in Table 14.
Table 14 Relationships of the 802.1X Auth-Fail VLAN with other features

Feature Relationship description Reference

You cannot specify a VLAN as
See Layer 2—LAN Switching
Super VLAN both a super VLAN and an
Configuration Guide.
802.1X Auth-Fail VLAN.

MAC authentication guest VLAN

The 802.1X Auth-Fail VLAN has See "Configuring MAC
on a port that performs
a high priority. authentication."
MAC-based access control

The 802.1X Auth-Fail VLAN

feature has higher priority than
Port intrusion protection actions the block MAC action.
on a port that performs The 802.1X Auth-Fail VLAN See "Configuring port security."
MAC-based access control feature has lower priority than
the shutdown port action of the
port intrusion protection feature.

Prerequisites
Before you configure an 802.1X Auth-Fail VLAN, complete the following tasks:
• Create the VLAN to be specified as the 802.1X Auth-Fail VLAN.
• If the 802.1X-enabled port performs MAC-based access control, perform the following
operations for the port:

128
  Configure the port as a hybrid port.
 Enable MAC-based VLAN on the port. For more information about MAC-based VLANs, see
Layer 2—LAN Switching Configuration Guide.
• If the port type is hybrid, verify that the VLAN to be specified as the Auth-Fail VLAN is not in the
tagged VLAN list on the port.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Configure the 802.1X Auth-Fail VLAN on the port.
dot1x auth-fail vlan authfail-vlan-id
By default, no 802.1X Auth-Fail VLAN exists on a port.

Configuring an 802.1X critical VLAN

Restrictions and guidelines
• Assign different IDs to the PVID, the voice VLAN, and the 802.1X critical VLAN on a port. The
assignment makes sure the port can correctly process VLAN-tagged incoming traffic.
• You can configure only one 802.1X critical VLAN on a port. The 802.1X critical VLANs on
different ports can be different.
• You cannot specify a VLAN as both a super VLAN and an 802.1X critical VLAN. For information
about super VLANs, see Layer 2—LAN Switching Configuration Guide.
• On a hybrid port, the critical VLAN can only be an untagged VLAN.
Prerequisites
Before you configure an 802.1X critical VLAN, complete the following tasks:
• Create the VLAN to be specified as a critical VLAN.
• If the 802.1X-enabled port performs MAC-based access control, perform the following
operations for the port:
 Configure the port as a hybrid port.
 Enable MAC-based VLAN on the port. For more information about MAC-based VLANs, see
Layer 2—LAN Switching Configuration Guide.
• If the port type is hybrid, verify that the VLAN to be specified as the critical VLAN is not in the
tagged VLAN list on the port.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Configure the 802.1X critical VLAN on the port.
dot1x critical vlan critical-vlan-id
By default, no 802.1X critical VLAN exists on a port.

129
Enabling the 802.1X critical voice VLAN feature
Restrictions and guidelines
The feature does not take effect if the voice user has been in the 802.1X Auth-Fail VLAN.
Prerequisites
Before you enable the 802.1X critical voice VLAN feature on a port, complete the following tasks:
• Enable LLDP both globally and on the port.
The device uses LLDP to identify voice users. For information about LLDP, see Layer 2—LAN
Switching Configuration Guide.
• Enable voice VLAN on the port.
For information about voice VLANs, see Layer 2—LAN Switching Configuration Guide.
• Specify an 802.1X critical VLAN on the port. This setting ensures that a voice user is assigned
to the critical VLAN if it has failed authentication for unreachability of RADIUS servers before
the device recognizes it as a voice user. If an 802.1X critical VLAN is not available, the voice
user might be logged off instead.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable the 802.1X critical voice VLAN feature on a port.
dot1x critical-voice-vlan
By default, the 802.1X critical voice VLAN feature is disabled on a port.

Configuring an 802.1X guest VSI

Restrictions and guidelines
You can configure only one 802.1X guest VSI on a port. The 802.1X guest VSIs on different ports can
be different.
For the 802.1X guest VSI feature to work correctly, do not configure this feature together with EAD
assistant.
Prerequisites
Before you configure the 802.1X guest VSI on an 802.1X-enabled port, complete the following tasks:
• Enable L2VPN.
• Create the VSI to be specified as the 802.1X guest VSI, and create a VXLAN for the VSI.
• Configure the port to perform MAC-based access control and enable MAC-based traffic match
mode for dynamic Ethernet service instances on the port.
For more information, see VXLAN Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number

130
 3. Configure the 802.1X guest VSI on the port.
dot1x guest-vsi guest-vsi-name
By default, no 802.1X guest VSI exists on a port.

Enabling 802.1X guest VSI assignment delay

About this task
This feature delays assigning an 802.1X-enabled port to the 802.1X guest VSI when 802.1X
authentication is triggered on the port.
This feature applies only to situations where 802.1X authentication is triggered by EAPOL-Start
packets from 802.1X clients or packets from unknown MAC addresses.
To use this feature, the 802.1X-enabled port must perform MAC-based access control.
When 802.1X authentication is triggered on a port, the device performs the following operations:
1. Sends a unicast EAP-Request/Identity packet to the MAC address that triggers the
authentication.
2. Retransmits the packet if no response is received within the username request timeout interval
set by using the dot1x timer tx-period command.
3. Assigns the port to the 802.1X guest VSI after the maximum number of request attempts set by
using the dot1x retry command is reached.
This feature can work with the parallel processing of MAC authentication and 802.1X authentication
feature when a port performs a combination of 802.1X and MAC authentication. The collaboration
facilitates the port to perform MAC authentication before it is assigned to the 802.1X guest VSI. For
information about the parallel processing of MAC authentication and 802.1X authentication feature,
see "Configuring MAC authentication."
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable 802.1X guest VSI assignment delay on the port.
dot1x guest-vsi-delay { eapol | new-mac }
By default, 802.1X guest VSI assignment delay is disabled on a port.

Configuring an 802.1X Auth-Fail VSI

Restrictions and guidelines
You can configure only one 802.1X Auth-Fail VSI on a port. The 802.1X Auth-Fail VSIs on different
ports can be different.
Prerequisites
Before you configure the 802.1X Auth-Fail VSI on an 802.1X-enabled port, complete the following
tasks:
• Enable L2VPN.
• Create the VSI to be specified as the 802.1X Auth-Fail VSI, and create a VXLAN for the VSI.
• Configure the port to perform MAC-based access control and enable MAC-based traffic match
mode for dynamic Ethernet service instances on the port.

131
 For more information, see VXLAN Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Configure the 802.1X Auth-Fail VSI on the port.
dot1x auth-fail vsi authfail-vsi-name
By default, no 802.1X Auth-Fail VSI exists on a port.

Configuring an 802.1X critical VSI

Restrictions and guidelines
You can configure only one 802.1X critical VSI on a port. The 802.1X critical VSIs on different ports
can be different.
The 802.1X critical VSI on a port does not take effect on users already in the 802.1X Auth-Fail VSI.
Prerequisites
Before you configure the 802.1X critical VSI on an 802.1X-enabled port, complete the following
tasks:
• Enable L2VPN.
• Create the VSI to be specified as the 802.1X critical VSI, and create a VXLAN for the VSI.
• Configure the port to perform MAC-based access control and enable MAC-based traffic match
mode for dynamic Ethernet service instances on the port.
For more information, see VXLAN Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Configure the 802.1X critical VSI on the port.
dot1x critical vsi critical-vsi-name
By default, no 802.1X critical VSI exists on a port.

Configuring 802.1X unauthenticated user aging

About this task
802.1X unauthenticated user aging applies to users added to an 802.1X guest, critical, or Auth-Fail
VLAN or VSI because they have not been authenticated or have failed authentication.
When a user in one of those VLANs or VSIs ages out, the device removes the user from the VLAN or
VSI and deletes the MAC address entry for the user from the access port.
For users in one of those VLANs or VSIs on one port to be authenticated successfully and come
online on another port, enable this feature. In any other scenarios, disable this feature as a best
practice.

132
 The 802.1X user aging mechanism on a port depends on its access control mode.
• If the port uses port-based access control, a user aging timer starts when the port is assigned to
the critical or Auth-Fail VLAN. When the aging timer expires, the port is removed from the VLAN
and all MAC address entries for users in the VLAN are also removed.
• If the port uses MAC-based access control, a user aging timer starts for each 802.1X user when
they are assigned to the Auth-Fail, critical, or guest VLAN or VSI. When the aging timer for a
user expires, the device removes that user from the VLAN or VSI.
The removed users will be unable to access any network resources until after another authentication
is triggered.
Restrictions and guidelines
As a best practice, use this feature on a port only if you want to have its unauthenticated users to be
authenticated and come online on a different port.
Procedure
1. Enter system view.
system-view
2. Set the user aging timer for a type of 802.1X VLAN or VSI.
dot1x timer user-aging { auth-fail-vlan | auth-fail-vsi |
critical-vlan | critical-vsi | guest-vlan | guest-vsi }
aging-time-value
By default, the user aging timers for all applicable types of 802.1X VLANs and VSIs are 1000
seconds.
3. Enter interface view.
interface interface-type interface-number
4. Enable 802.1X unauthenticated user aging.
dot1x unauthenticated-user aging enable
By default, 802.1X unauthenticated user aging is enabled.

Sending EAP-Success packets on assignment of

users to the 802.1X Auth-Fail VLAN or VSI
About this task
By default, the device sends EAP-Failure packets to 802.1X clients when the client users are
assigned to the 802.1X Auth-Fail VLAN or VSI on a port. However, some 802.1X clients cannot send
DHCP requests for IP addresses after they receive EAP-Failure packets.
To have these clients obtain IP addresses and access resources after they are assigned to the
802.1X Auth-Fail VLAN or VSI, perform this task.
This task enables the device to send EAP-Success packets instead of EAP-Failure packets to
802.1X clients when the client users are assigned to the 802.1X Auth-Fail VLAN or VSI on the port.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable the device to send an EAP-Success packet to a client when the client user is assigned
to the 802.1X Auth-Fail VLAN or VSI on the port.

133
 dot1x auth-fail eapol
By default, the device sends an EAP-Failure packet to a client when the client user is assigned
to the 802.1X Auth-Fail VLAN or VSI.

Sending EAP-Success packets on assignment of

users to the 802.1X critical VLAN or VSI
About this task
By default, the device sends EAP-Failure packets to 802.1X clients when the client users are
assigned to the 802.1X critical VLAN or VSI. Some 802.1X clients, for example, Windows built-in
802.1X clients, cannot respond to the EAP-Request/Identity packet from the device for
reauthentication if they have received an EAP-Failure packet. As a result, reauthentication for these
clients will fail after the authentication server becomes reachable.
To avoid this situation, enable the device to send EAP-Success packets instead of EAP-Failure
packets to 802.1X clients when the client users are assigned to the 802.1X critical VLAN or VSI.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Configure the device to send an EAP-Success packet to an 802.1X client when its client user is
assigned to the critical VLAN or VSI on the port.
dot1x critical eapol
By default, the device sends an EAP-Failure packet to an 802.1X client when its client user is
assigned to the critical VLAN or VSI.

Enabling 802.1X online user synchronization

About this task

IMPORTANT:
This feature takes effect only when the device uses an IMC RADIUS server to authenticate 802.1X
users.

To ensure that the RADIUS server maintains the same online 802.1X user information as the device
after the server state changes from unreachable to reachable, use this feature.
This feature synchronizes online 802.1X user information between the device and the RADIUS
server when the RADIUS server state is detected having changed from unreachable to reachable.
When synchronizing online 802.1X user information on a port with the RADIUS server, the device
initiates 802.1X authentication in turn for each authenticated online 802.1X user to the RADIUS
server.
If synchronization fails for an online user, the device logs off that user unless the failure occurs
because the server has become unreachable again.
Restrictions and guidelines
The amount of time required to complete online user synchronization increases as the number of
online users grows. This might result in an increased delay for new 802.1X users and users in the
critical VLAN or VSI to authenticate or reauthenticate to the RADIUS server and come online.

134
 To have this feature take effect, you must use it in conjunction with the RADIUS server status
detection feature, which is configurable with the radius-server test-profile command.
When you configure this feature, make sure the detection interval is shorter than the RADIUS server
quiet timer configured by using the timer quiet command in RADIUS scheme view. The server
state changes to active on expiration of the quiet timer regardless of its actual reachability. Setting a
shorter detection interval than the quiet timer prevents the RADIUS server status detection feature
from falsely reporting the server reachability.
For more information about the RADIUS server status detection feature, see "Configuring AAA."
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable 802.1X online user synchronization.
dot1x server-recovery online-user-sync
By default, 802.1X online user synchronization is disabled.

Configuring the authentication trigger feature

About this task
The authentication trigger feature enables the access device to initiate 802.1X authentication when
802.1X clients cannot initiate authentication.
This feature provides the multicast trigger and unicast trigger (see 802.1X authentication initiation in
"802.1X overview").
Restrictions and guidelines
• Enable the multicast trigger on a port when the clients attached to the port cannot send
EAPOL-Start packets to initiate 802.1X authentication.
• As a best practice to conserve link bandwidth, disable the multicast trigger if a lot of VLANs are
configured on the port.
• Enable the unicast trigger on a port if only a few 802.1X clients are attached to the port and
these clients cannot initiate authentication.
• To avoid duplicate authentication packets, do not enable both triggers on a port.
• As a best practice, do not use the unicast trigger on a port that performs port-based access
control. If you do so, users on the port might fail to come online.
Procedure
1. Enter system view.
system-view
2. (Optional.) Set the username request timeout timer.
dot1x timer tx-period tx-period-value
The default is 30 seconds.
3. Enter interface view.
interface interface-type interface-number
4. Enable an authentication trigger.
dot1x { multicast-trigger | unicast-trigger }
By default, the multicast trigger is enabled, and the unicast trigger is disabled.

135
Setting the maximum number of concurrent
802.1X users on a port
About this task
Perform this task to prevent the system resources from being overused.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Set the maximum number of concurrent 802.1X users on a port.
dot1x max-user max-number
The default is 4294967295.

Setting the maximum number of authentication

request attempts
About this task
The access device retransmits an authentication request if it does not receive any responses to the
request from the client within a period of time. To set the time, use the dot1x timer tx-period
tx-period-value command or the dot1x timer supp-timeout supp-timeout-value
command. The access device stops retransmitting the request if it has made the maximum number
of request transmission attempts but still receives no response.
Procedure
1. Enter system view.
system-view
2. Set the maximum number of attempts for sending an authentication request.
dot1x retry retries
The default setting is 2.

Discarding duplicate 802.1X EAPOL-Start

requests
About this task
During 802.1X authentication, the device might receive duplicate EAPOL-Start requests from an
802.1X user. By default, the device delivers the duplicate EAPOL-Start requests to the
authentication server as long as they are legal. However, this mechanism might result in
authentication failure if the authentication server cannot respond to duplicate EAPOL-Start requests.
To resolve this issue, perform this task on the user access interface to discard duplicate
EAPOL-Start requests.

136
Restrictions and guidelines
As a best practice, perform this task only if the server cannot respond to duplicate EAPOL-Start
requests. Do not perform this task in other situations.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Discard duplicate EAPOL-Start requests on the interface.
dot1x duplicate-eapol-start discard
By default, the device does not discard duplicate EAPOL-Start requests on an interface if the
requests are legal.

Configuring online user handshake

About this task
The online user handshake feature checks the connectivity status of online 802.1X users. The
access device sends handshake requests (EAP-Request/Identity) to online users at the interval
specified by the dot1x timer handshake-period command. If the device does not receive any
EAP-Response/Identity packets from an online user after it has made the maximum handshake
attempts, the device sets the user to offline state. To set the maximum handshake attempts, use the
dot1x retry command.
Typically, the device does not reply to 802.1X clients' EAP-Response/Identity packets with
EAP-Success packets. Some 802.1X clients will go offline if they do not receive the EAP-Success
packets for handshake. To avoid this issue, enable the online user handshake reply feature.
If iNode clients are deployed, you can also enable the online user handshake security feature to
check authentication information in the handshake packets from clients. This feature can prevent
802.1X users that use illegal client software from bypassing iNode security check, such as dual
network interface cards (NICs) detection. If a user fails the handshake security checking, the device
sets the user to the offline state.
Restrictions and guidelines
• If the network has 802.1X clients that cannot exchange handshake packets with the access
device, disable the online user handshake feature. This operation prevents the 802.1X
connections from being incorrectly torn down.
• To use the online user handshake security feature, make sure the online user handshake
feature is enabled.
• The online user handshake security feature takes effect only on the network where the iNode
client and IMC server are used.
• Enable the online user handshake reply feature only if 802.1X clients will go offline without
receiving EAP-Success packets from the device.
• To ensure online user handshake and new user authentication when a large number of users
are present, set the following parameters to a large value:
 Handshake timer (set by using the dot1x timer handshake-period command).
 Maximum number of attempts to send an authentication request to a client (set by using the
dot1x retry command).
Procedure
1. Enter system view.

137
 system-view
2. (Optional.) Set the handshake timer.
dot1x timer handshake-period handshake-period-value
The default is 15 seconds.
3. Enter interface view.
interface interface-type interface-number
4. Enable the online user handshake feature.
dot1x handshake
By default, the feature is enabled.
5. (Optional.) Enable the online user handshake security feature.
dot1x handshake secure
By default, the feature is disabled.
6. (Optional.) Enable the 802.1X online user handshake reply feature.
dot1x handshake reply enable
By default, the device does not reply to 802.1X clients' EAP-Response/Identity packets during
the online handshake process.

Specifying supported domain name delimiters

About this task
By default, the access device supports the at sign (@) as the delimiter. You can also configure the
access device to accommodate 802.1X users that use other domain name delimiters. The
configurable delimiters include the at sign (@), backslash (\), dot (.), and forward slash (/).
Usernames that include domain names can use the format of username@domain-name,
domain-name\username, username.domain-name, or username/domain-name.
If an 802.1X username string contains multiple configured delimiters, the rightmost delimiter is the
domain name delimiter. For example, if you configure the backslash (\), dot (.), and forward slash (/)
as delimiters, the domain name delimiter for the username string 121.123/22\@abc is the backslash
(\). The username is @abc and the domain name is 121.123/22.
Restrictions and guidelines
If a username string contains none of the delimiters, the access device authenticates the user in the
mandatory or default ISP domain.
If you configure the access device to send usernames with domain names to the RADIUS server,
make sure the domain delimiter can be recognized by the RADIUS server. For username format
configuration, see the user-name-format command in Security Command Reference.
Procedure
1. Enter system view.
system-view
2. Specify a set of domain name delimiters for 802.1X users.
dot1x domain-delimiter string
By default, only the at sign (@) delimiter is supported.

138
Removing the VLAN tags of 802.1X protocol
packets sent out of a port
About this task
This feature operates on a hybrid port to have it send 802.1X protocol packets with their VLAN tags
removed, regardless of whether the port is a tagged or untagged member of a VLAN.
Use this feature if the 802.1X-enabled hybrid port is a tagged member of its PVID and the attached
802.1X clients cannot recognize VLAN-tagged 802.1X protocol packets.
Restrictions and guidelines
This feature removes the VLAN tags of all 802.1X protocol packets sent out of the port to 802.1X
clients. Do not use this feature if VLAN-aware 802.1X clients are attached to the port.
Prerequisites
Set the link type of the 802.1X-enabled port to hybrid. For more information, see VLAN configuration
in Layer 2 LAN Switching Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Remove the VLAN tags of all 802.1X protocol packets sent out of the port to 802.1X clients.
dot1x eapol untag
By default, whether the device removes the VLAN tags of all 802.1X protocol packets sent out
of a port to 802.1X clients depends on the configuration in the VLAN module.

Setting the maximum number of 802.1X

authentication attempts for MAC authenticated
users
About this task
When a port uses both 802.1X authentication and MAC authentication, the device accepts 802.1X
authentication requests from MAC authenticated users. If a MAC authenticated user passes 802.1X
authentication, the user will come online as an 802.1X user. If the user fails 802.1X authentication,
the user continues to make 802.1X authentication attempts depending on client configuration.
Perform this task to limit the number of 802.1X authentication attempts made by a MAC
authenticated user.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Set the maximum number of 802.1X authentication attempts for MAC authenticated users on
the port.

139
 dot1x after-mac-auth max-attempt max-attempts
By default, the number of 802.1X authentication attempts for MAC authenticated users is not
limited on a port.

Enabling 802.1X user IP freezing

About this task
This feature works with the IP source guard feature. 802.1X-based IP source guard requires that
802.1X clients support sending user IP addresses to the access device. The device uses information
such as user MAC addresses and IP addresses obtained through 802.1X to generate IPSG bindings
to filter out IPv4 packets from unauthenticated 802.1X users. For information about IP source guard,
see "Configuring IP source guard."
This feature prevents any authenticated 802.1X users on a port from changing their IP addresses.
After you enable this feature, the port does not update the IP addresses in dynamic IPSG bindings
for 802.1X users. If an 802.1X user uses an IP address different from the IP address in its IPSG
binding entry, the port denies the user access.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable 802.1X user IP freezing.
dot1x user-ip freeze
By default, 802.1X user IP freezing is disabled.

Enabling generation of dynamic IPSG binding

entries for 802.1X authenticated users
About this task

IMPORTANT:
This feature must operate in conjunction with the IP source guard (IPSG) feature.

By default, the device generates a dynamic IPv4SG or IPv6SG binding entry for an 802.1X
authenticated user after the user obtains a static or DHCP assigned IP address.
To allow only 802.1X users with DHCP assigned IP addresses to access the network, perform the
following operations:
• Enable IPSG.
• Disable generation of dynamic IPv4SG or IPv6SG binding entries for 802.1X authenticated
users.
• Enable DHCP snooping. The device will generate IPv4SG or IPv6SG binding entries for the
users based on DHCP snooping.
For more information about IPSG, see IP source guard in Security Configuration Guide.

140
Restrictions and guidelines
This feature takes effect only on 802.1X users that come online after the feature is enabled. If the IP
address of an online 802.1X user changes, the device will update the dynamic IPv4SG or IPv6SG
binding entry for the user.
Disabling this feature does not delete the existing dynamic IPv4SG or IPv6SG binding entries for
online 802.1X users. If the IP address of an online 802.1X user changes after the feature is disabled,
the device will delete the dynamic IPv4SG or IPv6SG binding entry for the user.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable generation of dynamic IPv4SG or IPv6SG binding entries for 802.1X authenticated
users.
dot1x { ip-verify-source | ipv6-verify-source } enable
By default, generation of dynamic IPv4SG or IPv6SG binding entries for 802.1X authenticated
users is enabled.

Configuring 802.1X MAC address binding

About this task
This feature can automatically bind MAC addresses of authenticated 802.1X users to the users'
access port and generate 802.1X MAC address binding entries. You can also use the dot1x
mac-binding mac-address command to manually add 802.1X MAC address binding entries.
802.1X MAC address binding entries never age out. They can survive a user logoff or a device
reboot. If users in the 802.1X MAC address binding entries perform 802.1X authentication on
another port, they cannot pass authentication.
Restrictions and guidelines
The 802.1X MAC address binding feature takes effect only when the port performs MAC-based
access control.
To delete an 802.1X MAC address binding entry, use the undo dot1x mac-binding
mac-address command. An 802.1X MAC address binding entry cannot be deleted when the user
in the entry is online.
After the number of 802.1X MAC address binding entries reaches the upper limit of concurrent
802.1X users (set by using the dot1x max-user command), the following restrictions exist:
• Users not in the binding entries will fail authentication even after users in the binding entries go
offline.
• New 802.1X MAC address binding entries are not allowed.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable the 802.1X MAC address binding feature.
dot1x mac-binding enable

141
 By default, the feature is disabled.
4. (Optional.) Manually add an 802.1X MAC address binding entry.
dot1x mac-binding mac-address
By default, no 802.1X MAC address binding entries exist on a port.

Configuring the EAD assistant feature

Restrictions and guidelines
• You must disable port security before you enable the EAD assistant feature.
• To make the EAD assistant feature take effect on an 802.1X-enabled port, you must set the port
authorization mode to auto.
• When port security is enabled, the free IP does not take effect.
• For the 802.1X guest VSI or guest VLAN feature to work correctly, do not enable EAD assistant
together with the 802.1X guest VSI or guest VLAN feature.
• If you use free IP and Auth-Fail VLAN features together, make sure the resources in the
Auth-Fail VLAN are on the free IP segments.
• The server that provides the redirect URL must be on the free IP accessible to unauthenticated
users.
You can use EAD assistant in conjunction with MAC authentication. When you use both EAD
assistant and MAC authentication on the device, follow these restrictions and guidelines:
• If both EAD assistant and MAC authentication are configured, the device does not mark the
MAC address of a user that has failed MAC authentication as a silent MAC address. If the user
has never passed MAC authentication, packets from the user can trigger authentication again
only after the user's EAD entry ages out.
• As a best practice, do not configure MAC authentication guest VSIs, guest VLANs, critical VSIs,
or critical VLANs. The VLANs or VSIs might fail to work correctly when both EAD assistant and
MAC authentication are configured on the device.
• As a best practice, do not configure the Web authentication feature. The feature might fail to
work correctly when both EAD assistant and MAC authentication are configured on the device.
• Configure a reasonable lease term for IP addresses assigned to users processed by EAD
assistant to ensure that the users can obtain new IP addresses as soon as possible after they
pass MAC authentication.
• If the MAC address of a user has been marked as a silent MAC address before you enable EAD
assistant, packets from the user can trigger EAD assistant only after the quiet timer expires.
Procedure
1. Enter system view.
system-view
2. Enable the EAD assistant feature.
dot1x ead-assistant enable
By default, this feature is disabled.
3. Configure a free IP.
dot1x ead-assistant free-ip ip-address { mask-length | mask-address }
Repeat this command to configure multiple free IPs.
4. (Optional.) Configure the redirect URL if users will use Web browsers to access the network.
dot1x ead-assistant url url-string
By default, no redirect URL exists.

142
 By default, the device listens to port 6654 for HTTPS requests to be redirected. To change the
redirect listening port number, see configuring HTTP redirect in Layer 3—IP Services
Configuration Guide.
5. (Optional.) Set the EAD rule timer.
dot1x timer ead-timeout ead-timeout-value
The default setting is 30 minutes.
To avoid using up ACL resources when a large number of EAD users exist, you can shorten the
EAD rule timer.

Setting the maximum size of EAP-TLS fragments

sent to the server
About this task
When the device uses EAP-TLS authentication method in EAP relay mode, the RADIUS packets
might exceed the maximum packet size supported by the RADIUS server. This situation typically
occurs when long EAP-TLS messages are encapsulated in the EAP-Message attribute of the
RADIUS packet sent to the RADIUS server.
To avoid authentication failures caused by oversized packets, fragment the EAP-TLS messages
depending on the maximum RADIUS packet size supported by the remote RADIUS server.
For example, the maximum packet length allowed by the server is 1200 bytes and the length of a
RADIUS packet (excluding the EAP-Message attribute) is 800 bytes. To make sure the maximum
length of a RADIUS packet does not exceed 1200 bytes, you must set the maximum length of an
EAP-TLS fragment to a value less than 400 bytes.
Restrictions and guidelines
802.1X EAP-TLS fragmentation takes effect only when EAP relay mode is used. For more
information about enabling EAP relay, see "Enabling EAP relay or EAP termination."
Procedure
1. Enter system view.
system-view
2. Enable 802.1X EAP-TLS fragmentation and set the maximum EAP-TLS fragment size.
dot1x eap-tls-fragment to-server eap-tls-max-length
By default, EAP-TLS messages are not fragmented.

Logging off 802.1X users

About this task
Perform this task to log off specified 802.1X users and clear information about these users from the
device. These users must perform 802.1X authentication to come online again.
Procedure
To log off 802.1X users, execute the following command in user view:
reset dot1x access-user [ interface interface-type interface-number | mac
mac-address | username username | vlan vlan-id | vsi vsi-name ]

143
Enabling 802.1X user logging
About this task
This feature enables the device to generate logs about 802.1X users and send the logs to the
information center. For the logs to be output correctly, you must also configure the information center
on the device. For more information about information center configuration, see Network
Management and Monitoring Configuration Guide.
Restrictions and guidelines
To prevent excessive 802.1X user log entries, use this feature only if you need to analyze abnormal
802.1X user logins or logouts.
Procedure
1. Enter system view.
system-view
2. Enable 802.1X user logging.
dot1x access-user log enable [ abnormal-logoff | failed-login |
normal-logoff | successful-login ] *
By default, 802.1X user logging is disabled.
If you do not specify any parameters, this command enables all types of 802.1X user logs.

Display and maintenance commands for 802.1X

Execute display commands in any view and reset commands in user view.

Task Command
Display 802.1X session information, display dot1x [ sessions | statistics ]
statistics, or configuration information of [ interface interface-type
specified or all ports. interface-number ]
display dot1x connection [ open ] [ interface
interface-type interface-number | slot
Display online 802.1X user information.
slot-number | user-mac mac-address |
user-name name-string ]
display dot1x mac-address { auth-fail-vlan |
auth-fail-vsi | critical-vlan |
Display the MAC addresses of 802.1X
critical-vsi | guest-vlan | guest-vsi }
users in a type of 802.1X VLAN or VSI.
[ interface interface-type
interface-number ]
reset dot1x guest-vlan interface
Remove users from the 802.1X guest
interface-type interface-number
VLAN on a port.
[ mac-address mac-address ]
reset dot1x guest-vsi interface
Remove users from the 802.1X guest
interface-type interface-number
VSI on a port.
[ mac-address mac-address ]
reset dot1x statistics [ interface
Clear 802.1X statistics.
interface-type interface-number ]

144
802.1X authentication configuration examples
Example: Configuring basic 802.1X authentication
Network configuration
As shown in Figure 40, the access device performs 802.1X authentication for users that connect to
GigabitEthernet 1/0/1. Implement MAC-based access control on the port, so the logoff of one user
does not affect other online 802.1X users.
Use RADIUS servers to perform authentication, authorization, and accounting for the 802.1X users.
If RADIUS authentication fails, perform local authentication on the access device.
Configure the RADIUS server at 10.1.1.1/24 as the primary authentication and accounting server,
and the RADIUS server at 10.1.1.2/24 as the secondary authentication and accounting server.
Assign all users to ISP domain bbb.
Set the shared key to name for packets between the access device and the authentication server.
Set the shared key to money for packets between the access device and the accounting server.
Figure 40 Network diagram

RADIUS server cluster

Primary: 10.1.1.1/24
Secondary: 10.1.1.2/24

GE1/0/2
Supplicant Authenticator 10.1.1.10/24
GE1/0/1
Vlan-int2
Internet
192.168.1.1/24
Host Device
192.168.1.2/24

Procedure
For information about the RADIUS commands used on the access device in this example, see
Security Command Reference.
1. Configure the RADIUS servers and add user accounts for the 802.1X users. Make sure the
RADIUS servers can provide authentication, authorization, and accounting services. (Details
not shown.)
2. Assign an IP address to each interface. (Details not shown.)
3. Configure user accounts for the 802.1X users on the access device:
# Add a local network access user with username localuser and password localpass in
plaintext. (Make sure the username and password are the same as those configured on the
RADIUS servers.)
<Device> system-view
[Device] local-user localuser class network
[Device-luser-network-localuser] password simple localpass
# Set the service type to lan-access.
[Device-luser-network-localuser] service-type lan-access
[Device-luser-network-localuser] quit
4. Configure a RADIUS scheme on the access device:
# Create a RADIUS scheme named radius1 and enter RADIUS scheme view.

145
 [Device] radius scheme radius1
# Specify the IP addresses of the primary authentication and accounting RADIUS servers.
[Device-radius-radius1] primary authentication 10.1.1.1
[Device-radius-radius1] primary accounting 10.1.1.1
# Configure the IP addresses of the secondary authentication and accounting RADIUS servers.
[Device-radius-radius1] secondary authentication 10.1.1.2
[Device-radius-radius1] secondary accounting 10.1.1.2
# Specify the shared key between the access device and the authentication server.
[Device-radius-radius1] key authentication simple name
# Specify the shared key between the access device and the accounting server.
[Device-radius-radius1] key accounting simple money
# Exclude the ISP domain names from the usernames sent to the RADIUS servers.
[Device-radius-radius1] user-name-format without-domain
[Device-radius-radius1] quit

NOTE:
The access device must use the same username format as the RADIUS server. If the RADIUS
server includes the ISP domain name in the username, so must the access device.

5. Configure an ISP domain on the access device:

# Create an ISP domain named bbb and enter ISP domain view.
[Device] domain bbb
# Apply RADIUS scheme radius1 to the ISP domain, and specify local authentication as the
secondary authentication method.
[Device-isp-bbb] authentication lan-access radius-scheme radius1 local
[Device-isp-bbb] authorization lan-access radius-scheme radius1 local
[Device-isp-bbb] accounting lan-access radius-scheme radius1 local
[Device-isp-bbb] quit
6. Configure 802.1X on the access device:
# Enable 802.1X on GigabitEthernet 1/0/1.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] dot1x
# Enable MAC-based access control on the port. By default, the port uses MAC-based access
control.
[Device-GigabitEthernet1/0/1] dot1x port-method macbased
# Specify ISP domain bbb as the mandatory domain.
[Device-GigabitEthernet1/0/1] dot1x mandatory-domain bbb
[Device-GigabitEthernet1/0/1] quit
# Enable 802.1X globally.
[Device] dot1x
7. Configure the 802.1X client. If an iNode client is used, do not select the Carry version info
option in the client configuration. (Details not shown.)
Verifying the configuration
# Verify the 802.1X configuration on GigabitEthernet 1/0/1.
[Device] display dot1x interface gigabitethernet 1/0/1

# Display the user connection information after an 802.1X user passes authentication.
[Device] display dot1x connection

146
Example: Configuring 802.1X guest VLAN and authorization
VLAN
Network configuration
As shown in Figure 41, use RADIUS servers to perform authentication, authorization, and
accounting for 802.1X users that connect to GigabitEthernet 1/0/2. Implement port-based access
control on the port.
Configure VLAN 10 as the 802.1X guest VLAN on GigabitEthernet 1/0/2. The host and the update
server are both in VLAN 10, and the host can access the update server and download the 802.1X
client software.
After the host passes 802.1X authentication, the access device assigns the host to VLAN 5 where
GigabitEthernet 1/0/3 is. The host can access the Internet.
Figure 41 Network diagram
Update server Authentication server

VLAN 10 VLAN 2
GE1/0/1 GE1/0/4

VLAN 1 VLAN 5
GE1/0/2 GE1/0/3
Device

Internet

Host
Port assigned to
guest VLAN

Update server Authentication server Update server Authentication server

VLAN 10 VLAN 2 VLAN 10 VLAN 2

GE1/0/1 GE1/0/4 GE1/0/1 GE1/0/4
User comes
online
VLAN 10 VLAN 5 VLAN 5 VLAN 5
GE1/0/2 GE1/0/3 GE1/0/2 GE1/0/3
Device Device

Internet Internet

Host Host

Procedure
For information about the RADIUS commands used on the access device in this example, see
Security Command Reference.
1. Configure the RADIUS server to provide authentication, authorization, and accounting services.
Configure user accounts and authorization VLAN (VLAN 5 in this example) for the users.
(Details not shown.)
2. Create VLANs, and assign ports to the VLANs on the access device.

NOTE:
By default, VLAN 1 exists and all ports belong to the VLAN. You do not need to create the VLAN
or assign GigabitEthernet 1/0/2 to the VLAN.

147
 <Device> system-view
[Device] vlan 10
[Device-vlan10] port gigabitethernet 1/0/1
[Device-vlan10] quit
[Device] vlan 2
[Device-vlan2] port gigabitethernet 1/0/4
[Device-vlan2] quit
[Device] vlan 5
[Device-vlan5] port gigabitethernet 1/0/3
[Device-vlan5] quit
3. Configure a RADIUS scheme on the access device:
# Create RADIUS scheme 2000 and enter RADIUS scheme view.
[Device] radius scheme 2000
# Specify the server at 10.11.1.1 as the primary authentication server, and set the
authentication port to 1812.
[Device-radius-2000] primary authentication 10.11.1.1 1812
# Specify the server at 10.11.1.1 as the primary accounting server, and set the accounting port
to 1813.
[Device-radius-2000] primary accounting 10.11.1.1 1813
# Set the shared key to abc in plain text for secure communication between the authentication
server and the device.
[Device-radius-2000] key authentication simple abc
# Set the shared key to abc in plain text for secure communication between the accounting
server and the device.
[Device-radius-2000] key accounting simple abc
# Exclude the ISP domain names from the usernames sent to the RADIUS server.
[Device-radius-2000] user-name-format without-domain
[Device-radius-2000] quit
4. Configure an ISP domain on the access device:
# Create ISP domain bbb and enter ISP domain view.
[Device] domain bbb
# Apply RADIUS scheme 2000 to the ISP domain for authentication, authorization, and
accounting.
[Device-isp-bbb] authentication lan-access radius-scheme 2000
[Device-isp-bbb] authorization lan-access radius-scheme 2000
[Device-isp-bbb] accounting lan-access radius-scheme 2000
[Device-isp-bbb] quit
5. Configure 802.1X on the access device:
# Enable 802.1X on GigabitEthernet 1/0/2.
[Device] interface gigabitethernet 1/0/2
[Device-GigabitEthernet1/0/2] dot1x
# Implement port-based access control on the port.
[Device-GigabitEthernet1/0/2] dot1x port-method portbased
# Set the port authorization mode to auto. By default, the port uses the auto mode.
[Device-GigabitEthernet1/0/2] dot1x port-control auto
# Specify VLAN 10 as the 802.1X guest VLAN on GigabitEthernet 1/0/2.
[Device-GigabitEthernet1/0/2] dot1x guest-vlan 10
[Device-GigabitEthernet1/0/2] quit

148
 # Enable 802.1X globally.
[Device] dot1x
6. Configure the 802.1X client. Make sure the 802.1X client can update its IP address after the
access port is assigned to the guest VLAN or an authorization VLAN. (Details not shown.)
Verifying the configuration
# Verify the 802.1X guest VLAN configuration on GigabitEthernet 1/0/2.
[Device] display dot1x interface gigabitethernet 1/0/2

# Verify that GigabitEthernet 1/0/2 is assigned to VLAN 10 before any user passes authentication on
the port.
[Device] display vlan 10

# After a user passes authentication, display information on GigabitEthernet 1/0/2. Verify that
GigabitEthernet 1/0/2 is assigned to VLAN 5.
[Device] display interface gigabitethernet 1/0/2

Example: Configuring 802.1X with ACL assignment

Network configuration
As shown in Figure 42, the host that connects to GigabitEthernet 1/0/1 must pass 802.1X
authentication to access the Internet.
Perform 802.1X authentication on GigabitEthernet 1/0/1. Use the RADIUS server at 10.1.1.1 as the
authentication and authorization server, and the RADIUS server at 10.1.1.2 as the accounting
server.
Configure ACL assignment on GigabitEthernet 1/0/1 to deny access of 802.1X users to the FTP
server from 8:00 to 18:00 on weekdays.
Figure 42 Network diagram

RADIUS server cluster

Auth: 10.1.1.1
Acct: 10.1.1.2

GE1/0/2

GE1/0/1 GE1/0/3
Vlan-int2
Internet
192.168.1.1/24
Host Device FTP server
192.168.1.10/24 10.0.0.1/24

Procedure
For information about the RADIUS commands used on the access device in this example, see
Security Command Reference.
1. Configure the RADIUS servers to provide authentication, authorization, and accounting
services. Add user accounts and specify the ACL (ACL 3000 in this example) for the users.
(Details not shown.)
2. Assign an IP address to each interface, as shown in Figure 42. (Details not shown.)
3. Configure a RADIUS scheme on the access device:
# Create RADIUS scheme 2000 and enter RADIUS scheme view.
<Device> system-view
[Device] radius scheme 2000

149
 # Specify the server at 10.1.1.1 as the primary authentication server, and set the authentication
port to 1812.
[Device-radius-2000] primary authentication 10.1.1.1 1812
# Specify the server at 10.1.1.2 as the primary accounting server, and set the accounting port to
1813.
[Device-radius-2000] primary accounting 10.1.1.2 1813
# Set the shared key to abc in plain text for secure communication between the authentication
server and the device.
[Device-radius-2000] key authentication simple abc
# Set the shared key to abc in plain text for secure communication between the accounting
server and the device.
[Device-radius-2000] key accounting simple abc
# Exclude the ISP domain names from the usernames sent to the RADIUS server.
[Device-radius-2000] user-name-format without-domain
[Device-radius-2000] quit
4. Configure an ISP domain on the access device:
# Create ISP domain bbb and enter ISP domain view.
[Device] domain bbb
# Apply RADIUS scheme 2000 to the ISP domain for authentication, authorization, and
accounting.
[Device-isp-bbb] authentication lan-access radius-scheme 2000
[Device-isp-bbb] authorization lan-access radius-scheme 2000
[Device-isp-bbb] accounting lan-access radius-scheme 2000
[Device-isp-bbb] quit
5. Configure a time range named ftp from 8:00 to 18:00 on weekdays on the access device.
[Device] time-range ftp 8:00 to 18:00 working-day
6. Configure ACL 3000 to deny packets destined for the FTP server at 10.0.0.1 during the
specified time range on the access device.
[Device] acl advanced 3000
[Device-acl-ipv4-adv-3000] rule 0 deny ip destination 10.0.0.1 0 time-range ftp
[Device-acl-ipv4-adv-3000] quit
7. Configure 802.1X on the access device:
# Enable 802.1X on GigabitEthernet 1/0/1.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] dot1x
[Device-GigabitEthernet1/0/1] quit
# Enable 802.1X globally.
[Device] dot1x
8. Configure the 802.1X client. Make sure the client is able to update its IP address after the
access port is assigned to the 802.1X guest VLAN or an authorization VLAN. (Details not
shown.)
Verifying the configuration
# Use the user account to pass authentication. (Details not shown.)
# Verify that the user cannot ping the FTP server at any time from 8:00 to 18:00 on any weekday.
C:\>ping 10.0.0.1

Pinging 10.0.0.1 with 32 bytes of data:

150
 Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 10.0.0.1:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

The output shows that ACL 3000 is active on the user, and the user cannot access the FTP server.

Example: Configuring 802.1X guest VSI and authorization

VSI
Network configuration
As shown in Figure 43:
• The device acts as both a VXLAN VTEP and a network access device. It uses the RADIUS
server to perform authentication, authorization, and accounting for 802.1X users that connect to
GigabitEthernet 1/0/2.
• GigabitEthernet 1/0/2 uses MAC-based access control and is configured with the 802.1X guest
VSI. VXLAN 10 is created on the guest VSI. Users in the guest VSI can access the update
server in VXLAN 10 and download the 802.1X client software.
• The RADIUS server assigns an authorization VSI to the host. The VSI is associated with
VXLAN 5 on the device. After passing authentication, the host can access the Internet.
Figure 43 Network diagram

Update server RADIUS server

VXLAN 10

VLAN 1
GE1/0/2 VXLAN 5
Device
(VTEP)
Internet

Host
GE1/0/2 is moved to VXLAN 10 on
the guest VSI

Update server RADIUS server Update server RADIUS server

VXLAN 10

VXLAN 10
User passes authentication

VLAN 1 VLAN 1 VXLAN 5

VXLAN 5
GE1/0/2 GE1/0/2
Device Device
(VTEP) (VTEP)
Internet Internet

Host Host

151
Procedure
For information about the RADIUS commands used on the access device in this example, see
Security Command Reference.
1. Configure the RADIUS server to provide authentication, authorization, and accounting services.
Configure user accounts and authorization VSI (VSI vpn5 in this example) for the users.
(Details not shown.)
If an ADCAM server is used for authentication and authorization, configure VSIs on the server.
The server will assign these VSIs to the device. You do not need to configure VSIs on the
device.
2. Enable L2VPN on the access device.
<Device> system-view
[Device] l2vpn enable
3. Create VSIs and the corresponding VXLANs on the access device.
[Device] vsi vpn10
[Device-vsi-vpn10] vxlan 10
[Device-vsi-vpn10-vxlan-10] quit
[Device-vsi-vpn10] quit
[Device] vsi vpn5
[Device-vsi-vpn5] vxlan 5
[Device-vsi-vpn5-vxlan-5] quit
[Device-vsi-vpn5] quit
4. Configure a RADIUS scheme on the access device:
# Create RADIUS scheme 2000 and enter RADIUS scheme view.
[Device] radius scheme 2000
# Specify the server at 10.11.1.1 as the primary authentication server, and set the
authentication port to 1812.
[Device-radius-2000] primary authentication 10.11.1.1 1812
# Specify the server at 10.11.1.1 as the primary accounting server, and set the accounting port
to 1813.
[Device-radius-2000] primary accounting 10.11.1.1 1813
# Set the shared key to abc in plain text for secure communication between the authentication
server and the device.
[Device-radius-2000] key authentication simple abc
# Set the shared key to abc in plain text for secure communication between the accounting
server and the device.
[Device-radius-2000] key accounting simple abc
# Exclude the ISP domain names from the usernames sent to the authentication and
accounting servers.
[Device-radius-2000] user-name-format without-domain
[Device-radius-2000] quit
5. Configure an ISP domain on the access device:
# Create ISP domain bbb and enter ISP domain view.
[Device] domain bbb
# Apply RADIUS scheme 2000 to the ISP domain for authentication, authorization, and
accounting.
[Device-isp-bbb] authentication lan-access radius-scheme 2000
[Device-isp-bbb] authorization lan-access radius-scheme 2000
[Device-isp-bbb] accounting lan-access radius-scheme 2000
[Device-isp-bbb] quit

152
 6. Configure 802.1X on the access device:
# Enable 802.1X on GigabitEthernet 1/0/2.
[Device] interface gigabitethernet 1/0/2
[Device-GigabitEthernet1/0/2] dot1x
# Set the port authorization mode to auto. By default, the port uses the auto mode.
[Device-GigabitEthernet1/0/2] dot1x port-control auto
# Enable MAC-based traffic matching for dynamic Ethernet service instances on
GigabitEthernet 1/0/2.
[Device-GigabitEthernet1/0/2] mac-based ac
# Enable 802.1X unicast trigger on GigabitEthernet 1/0/2.
[Device-GigabitEthernet1/0/2] dot1x unicast-trigger
# Specify VSI vpn10 as the 802.1X guest VSI on GigabitEthernet 1/0/2.
[Device-GigabitEthernet1/0/2] dot1x guest-vsi vpn10
[Device-GigabitEthernet1/0/2] quit
# Enable 802.1X globally.
[Device] dot1x
7. Configure the 802.1X client. Make sure the 802.1X client can update its IP address after the
access port is assigned to the guest VSI or an authorization VSI. (Details not shown.)
Verifying the configuration
# Verify that GigabitEthernet 1/0/2 is assigned to VSI vpn10 if no responses are received from the
client after 802.1X authentication is triggered.
[Device] display l2vpn forwarding ac verbose

# Verify that GigabitEthernet 1/0/2 is assigned to VSI vpn5 after a user passes authentication on the
port.
[Device] display l2vpn forwarding ac verbose

Example: Configuring 802.1X with EAD assistant (with DHCP

relay agent)
Network configuration
As shown in Figure 44:
• The intranet 192.168.1.0/24 is attached to GigabitEthernet 1/0/1 of the access device.
• The hosts use DHCP to obtain IP addresses.
• A DHCP server and a Web server are deployed on the 192.168.2.0/24 subnet for users to
obtain IP addresses and download client software.
Deploy an EAD solution for the intranet to meet the following requirements:
• Allow unauthenticated users and users that have failed 802.1X authentication to access
192.168.2.0/24. The users can obtain IP addresses and download software.
• If these users use a Web browser to access a network other than 192.168.2.0/24, redirect them
to the Web server for 802.1X client downloading.
• Allow authenticated 802.1X users to access the network.

153
 Figure 44 Network diagram

Internet

Free IP:
WEB server
192.168.2.3/24

Device GE1/0/3
192.168.1.0/24 GE1/0/1 192.168.2.1/24 192.168.2.0/24
Vlan-int 2
192.168.1.1/24 GE1/0/2
10.1.1.10/24

DHCP server
192.168.2.2/24

Authentication servers
10.1.1.1/10.1.1.2

Procedure
1. Make sure the DHCP server, the Web server, and the authentication servers have been
configured correctly. (Details not shown.)
2. Configure an IP address for each interface. (Details not shown.)
3. Configure DHCP relay:
# Enable DHCP.
<Device> system-view
[Device] dhcp enable
# Enable the DHCP relay agent on VLAN-interface 2.
[Device] interface vlan-interface 2
[Device-Vlan-interface2] dhcp select relay
# Specify the DHCP server 192.168.2.2 on the relay agent interface VLAN-interface 2.
[Device-Vlan-interface2] dhcp relay server-address 192.168.2.2
[Device-Vlan-interface2] quit
4. Configure a RADIUS scheme:
# Create RADIUS scheme 2000 and enter RADIUS scheme view.
[Device] radius scheme 2000
# Specify the server at 10.1.1.1 as the primary authentication server, and set the authentication
port to 1812.
[Device-radius-2000] primary authentication 10.1.1.1 1812
# Specify the server at 10.1.1.2 as the primary accounting server, and set the accounting port to
1813.
[Device-radius-2000] primary accounting 10.1.1.2 1813
# Set the shared key to abc in plain text for secure communication between the authentication
server and the device.
[Device-radius-2000] key authentication simple abc
# Set the shared key to abc in plain text for secure communication between the accounting
server and the device.
[Device-radius-2000] key accounting simple abc

154
 # Exclude the ISP domain names from the usernames sent to the RADIUS server.
[Device-radius-2000] user-name-format without-domain
[Device-radius-2000] quit
5. Configure an ISP domain:
# Create ISP domain bbb and enter ISP domain view.
[Device] domain bbb
# Apply RADIUS scheme 2000 to the ISP domain for authentication, authorization, and
accounting.
[Device-isp-bbb] authentication lan-access radius-scheme 2000
[Device-isp-bbb] authorization lan-access radius-scheme 2000
[Device-isp-bbb] accounting lan-access radius-scheme 2000
[Device-isp-bbb] quit
6. Configure 802.1X:
# Configure the free IP.
[Device] dot1x ead-assistant free-ip 192.168.2.0 24
# Configure the redirect URL for client software download.
[Device] dot1x ead-assistant url http://192.168.2.3
# Enable the EAD assistant feature.
[Device] dot1x ead-assistant enable
# Enable 802.1X on GigabitEthernet 1/0/1.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] dot1x
[Device-GigabitEthernet1/0/1] quit
# Enable 802.1X globally.
[Device] dot1x

Verifying the configuration

# Verify the 802.1X configuration.
[Device] display dot1x

# Verify that you can ping an IP address on the free IP subnet from a host.
C:\>ping 192.168.2.3

Pinging 192.168.2.3 with 32 bytes of data:

Reply from 192.168.2.3: bytes=32 time<1ms TTL=128

Reply from 192.168.2.3: bytes=32 time<1ms TTL=128
Reply from 192.168.2.3: bytes=32 time<1ms TTL=128
Reply from 192.168.2.3: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.2.3:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

The output shows that you can access the free IP subnet before passing 802.1X authentication.
# Verify that you are redirected to the Web server when you enter in your Web browser an IP address
not on the free IP. (Details not shown.)

155
Example: Configuring 802.1X with EAD assistant (with DHCP
server)
Network configuration
As shown in Figure 45:
• The intranet 192.168.1.0/24 is attached to GigabitEthernet 1/0/1 of the access device.
• The hosts use DHCP to obtain IP addresses.
• A Web server is deployed on the 192.168.2.0/24 subnet for users to download client software.
Deploy an EAD solution for the intranet to meet the following requirements:
• Allow unauthenticated users and users that have failed 802.1X authentication to access
192.168.2.0/24. The users can download software.
• If these users use a Web browser to access a network other than 192.168.2.0/24, redirect them
to the Web server for 802.1X client downloading.
• Allow authenticated 802.1X users to access the network.
Figure 45 Network diagram

Internet

Free IP:
WEB server
192.168.2.3/24

Device GE1/0/3
192.168.1.0/24 GE1/0/1 192.168.2.1/24 192.168.2.0/24
Vlan-int 2
192.168.1.1/24 DHCP server
GE1/0/2
10.1.1.10/24

Authentication servers
10.1.1.1/10.1.1.2

Procedure
1. Make sure the Web server and the authentication servers have been configured correctly.
(Details not shown.)
2. Configure an IP address for each interface. (Details not shown.)
3. Configure the DHCP server:
# Enable DHCP.
<Device> system-view
[Device] dhcp enable
# Enable the DHCP server on VLAN-interface 2.
[Device] interface vlan-interface 2
[Device-Vlan-interface2] dhcp select server
[Device-Vlan-interface2] quit
# Create DHCP address pool 0.

156
 [Device] dhcp server ip-pool 0
# Specify subnet 192.168.1.0/24 in DHCP address pool 0.
[Device-dhcp-pool-0] network 192.168.1.0 mask 255.255.255.0
# Specify the gateway address 192.168.1.1 in DHCP address pool 0.
[Device-dhcp-pool-0] gateway-list 192.168.1.1
[Device-dhcp-pool-0] quit
4. Configure a RADIUS scheme:
# Create RADIUS scheme 2000 and enter RADIUS scheme view.
[Device] radius scheme 2000
# Specify the server at 10.1.1.1 as the primary authentication server, and set the authentication
port to 1812.
[Device-radius-2000] primary authentication 10.1.1.1 1812
# Specify the server at 10.1.1.2 as the primary accounting server, and set the accounting port to
1813.
[Device-radius-2000] primary accounting 10.1.1.2 1813
# Set the shared key to abc in plain text for secure communication between the authentication
server and the device.
[Device-radius-2000] key authentication simple abc
# Set the shared key to abc in plain text for secure communication between the accounting
server and the device.
[Device-radius-2000] key accounting simple abc
# Exclude the ISP domain names from the usernames sent to the RADIUS server.
[Device-radius-2000] user-name-format without-domain
[Device-radius-2000] quit
5. Configure an ISP domain:
# Create ISP domain bbb and enter ISP domain view.
[Device] domain bbb
# Apply RADIUS scheme 2000 to the ISP domain for authentication, authorization, and
accounting.
[Device-isp-bbb] authentication lan-access radius-scheme 2000
[Device-isp-bbb] authorization lan-access radius-scheme 2000
[Device-isp-bbb] accounting lan-access radius-scheme 2000
[Device-isp-bbb] quit
6. Configure 802.1X:
# Configure the free IP.
[Device] dot1x ead-assistant free-ip 192.168.2.0 24
# Configure the redirect URL for client software download.
[Device] dot1x ead-assistant url http://192.168.2.3
# Enable the EAD assistant feature.
[Device] dot1x ead-assistant enable
# Enable 802.1X on GigabitEthernet 1/0/1.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] dot1x
[Device-GigabitEthernet1/0/1] quit
# Enable 802.1X globally.
[Device] dot1x

157
Verifying the configuration
# Verify the 802.1X configuration.
[Device] display dot1x

# Verify that you can ping an IP address on the free IP subnet from a host.
C:\>ping 192.168.2.3

Pinging 192.168.2.3 with 32 bytes of data:

Reply from 192.168.2.3: bytes=32 time<1ms TTL=128

Reply from 192.168.2.3: bytes=32 time<1ms TTL=128
Reply from 192.168.2.3: bytes=32 time<1ms TTL=128
Reply from 192.168.2.3: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.2.3:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

The output shows that you can access the free IP subnet before passing 802.1X authentication.
# Verify that you are redirected to the Web server when you enter in your Web browser an IP address
not on the free IP. (Details not shown.)

Troubleshooting 802.1X
EAD assistant URL redirection failure
Symptom
Unauthenticated users are not redirected to the specified redirect URL after they enter external
website addresses in their Web browsers.
Analysis
Redirection will not happen for one of the following reasons:
• The address is in the string format. The operating system of the host regards the string as a
website name and tries to resolve the string. If the resolution fails, the operating system sends
an ARP request, but the target address is not in the dotted decimal notation. The redirection
feature does redirect this kind of ARP request.
• The address is within a free IP segment. No redirection will take place, even if no host is present
with the address.
• The redirect URL is not in a free IP segment.
• No server is using the redirect URL, or the server with the URL does not provide Web services.
Solution
To resolve the issue:
1. Enter a dotted decimal IP address that is not in any free IP segments.
2. Verify that the access device and the server are configured correctly.
3. If the issue persists, contact Hewlett Packard Enterprise Support.

158
Configuring MAC authentication
About MAC authentication
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 a username and
password for network access. The device initiates a MAC authentication process when it detects an
unknown source MAC address on a MAC authentication-enabled port. If the MAC address passes
authentication, the user can access authorized network resources. If the authentication fails, the
device marks the MAC address as a silent MAC address, drops the packet, and starts a quiet timer.
The device drops all subsequent packets from the MAC address within the quiet time. The quiet
mechanism avoids repeated authentication during a short time.

User account policies

MAC authentication supports the following user account policies:
• Global user account policy, which can be either of the following options:
 MAC-based user account policy—One MAC-based user account for each user. As
shown in Figure 46, the access device uses the source MAC addresses in packets as the
usernames and passwords of users for MAC authentication. This policy is suitable for an
insecure environment.

NOTE:
MAC-based user account policy also supports configuring a password shared by all
MAC-based user accounts.

 Shared user account policy—One shared user account for all users. You specify one
username and password (which are not necessarily a MAC address) for all MAC
authentication users on the access device, as shown in Figure 47. This policy is suitable for
a secure environment.
• MAC range-specific user account policy—One shared user account for users in a specific
MAC address range. You specify one username and password (which are not necessarily a
MAC address) for users in a specific MAC address range on the access device, as shown in
Figure 48. For example, you can specify a username and password for users with a specific
OUI for MAC authentication.

IMPORTANT:
• You can use global and MAC range-specific user account policies together. For users in a MAC
address range, the MAC range-specific user account settings have higher priority than the global
user account settings.
• If a RADIUS server is used for MAC authentication, you must create the user accounts on the
RADIUS server based on the user account policy on the access device.

159
 Figure 46 MAC-based user account policy

Local user accounts

Device
1-1-1
2-2-2
User accounts ……
Host
MAC: 1-1-1 MAC-based accounts RADIUS user accounts
1-1-1
Username：MAC1 Username/Password 2-2-2
Password：MAC1
……
Username：MAC2 （1-1-1/1-1-1）
Password：MAC2 （2-2-2/2-2-2）
Host …… …… RADIUS server
MAC: 2-2-2

Figure 47 Shared user account policy (global)

Device
Local user account
abc
Host User account
MAC: 1-1-1
RADIUS user account
Fixed account
Username/Password abc
Username：abc
Password：123 （abc/123）

Host RADIUS server

MAC: 2-2-2

Figure 48 Shared user account policy (specific to MAC address ranges)

Local user accounts

Device aaa
bbb
MAC range accounts ……
Host
MAC: 1-1-1 Account 1 RADIUS user accounts
Username: aaa Username/Password aaa
Password: 123
MAC range: 1-1-1 to 1-1-3 (aaa/123) bbb
……
Account 2
Host Username: bbb Username/Password
Password: 456
RADIUS server
MAC: 2-2-1 (bbb/456)
MAC range: 2-2-1 to 2-2-3
...... …… ……

Authentication methods
You can perform MAC authentication on the access device (local authentication) or through a
RADIUS server.
For more information about configuring local authentication and RADIUS authentication, see
"Configuring AAA."
RADIUS authentication
If MAC-based accounts are used, the access device by default sends the source MAC address of a
packet as the username and password to the RADIUS server for authentication. If a password is

160
 configured for MAC-based accounts, the access device sends the configured password as the
password to the RADIUS server.
If a shared account is used, the access device sends the shared account username and password to
the RADIUS server for authentication.
The access device and the RADIUS server use Password Authentication Protocol (PAP) or
Challenge Handshake Authentication Protocol (CHAP) for communication.
Local authentication
If MAC-based accounts are used, the access device by default uses the source MAC address of a
packet as the username and password to search the local account database for a match. If a
password is configured for MAC-based accounts, the device uses the configured password to
search the local account database for a match.
If a shared account is used, the access device uses the shared account username and password to
search the local account database for a match.

VLAN assignment
Authorization VLAN
The authorization VLAN controls the access of a MAC authentication user to authorized network
resources. The device supports authorization VLANs assigned locally or by a remote server.

IMPORTANT:
Only remote servers can assign tagged authorization VLANs.

Remote VLAN authorization

In remote VLAN authorization, you must configure an authorization VLAN for a user on the remote
server. After the user authenticates to the server, the server assigns authorization VLAN information
to the device. Then, the device assigns the user access port to the authorization VLAN as a tagged
or untagged member.
The device supports assignment of the following authorization VLAN information by the remote
server:
• VLAN ID.
• VLAN name, which must be the same as the VLAN description on the access device.
• A string of VLAN IDs and VLAN names.
In the string, some VLANs are represented by their IDs, and some VLANs are represented by
their names.
• VLAN group name.
For more information about VLAN groups, see Layer 2—LAN Switching Configuration Guide.
• VLAN ID with a suffix of t or u.
The t and u suffixes require the device to assign the access port to the VLAN as a tagged or
untagged member, respectively. For example, 2u indicates assigning the port to VLAN 2 as an
untagged member.
If a VLAN name or VLAN group name is assigned, the device converts the information into a VLAN
ID before VLAN assignment.

IMPORTANT:
For a VLAN represented by its VLAN name to be assigned successfully, you must make sure the
VLAN has been created on the device.
To assign VLAN IDs with suffixes, make sure the user access port is a hybrid or trunk port.

161
 IMPORTANT:
To ensure a successful assignment, the authorization VLANs assigned by the remote server cannot
be any of the following types:
• Dynamically learned VLANs.
• Reserved VLANs.
• Super VLANs.
• Private VLANs.

If the server assigns a group of VLANs, the access device selects a VLAN as described in Table 15.
Table 15 Authorization VLAN selection from a group of VLANs

VLAN information Authorization VLAN selection

The device selects an authorization VLAN from the VLAN group for a
user according to the following rules:
• On a hybrid port with MAC-based VLAN enabled:
 If the port does not have online users, the device selects the
VLAN with the lowest ID.
 If the port has online users, the device selects the VLAN that has
VLANs by IDs the fewest online users. If two VLANs have the same number of
online MAC authentication users, the device selects the VLAN
VLANs by names
with the lower ID.
VLAN group name • On an access, trunk, or MAC-based VLAN disabled hybrid port:
 If the port does not have online users, the device selects the
VLAN with the lowest ID.
 If the port has online users, the device examines the VLAN
group for the VLAN of the online users. If the VLAN is found, the
VLAN is assigned to the user as the authorization VLAN. If the
VLAN is not found, VLAN authorization fails.
3. The device selects the leftmost VLAN ID without a suffix, or the
leftmost VLAN ID suffixed by u as an untagged VLAN, whichever is
more leftmost.
4. The device assigns the untagged VLAN to the port as the PVID, and
it assigns the remaining as tagged VLANs. If no untagged VLAN is
VLAN IDs with suffixes assigned, the PVID of the port does not change. The port permits
traffic from these tagged and untagged VLANs to pass through.
For example, the authentication server sends the string 1u 2t 3 to the
access device for a user. The device assigns VLAN 1 as an untagged
VLAN and all remaining VLANs (including VLAN 3) as tagged VLANs.
VLAN 1 becomes the PVID.

Local VLAN authorization

To perform local VLAN authorization for a user, specify the VLAN ID in the authorization attribute list
of the local user account for that user. For each local user, you can specify only one authorization
VLAN ID. The user access port is assigned to the VLAN as an untagged member.

IMPORTANT:
Local VLAN authorization does not support assignment of tagged VLANs.

For more information about local user configuration, see "Configuring AAA."
Authorization VLAN manipulation on a MAC authentication-enabled port
Table 16 describes the way the network access device handles authorization VLANs (except for the
VLANs specified with suffixes) for MAC authenticated users on a port.

162
 Table 16 VLAN manipulation

Port type VLAN manipulation

• The device assigns the port to the first authenticated user's
authorization VLAN and sets the VLAN as the PVID if that
• Access port authorization VLAN has the untagged attribute.
• Trunk port • If the authorization VLAN has the tagged attribute, the device
assigns the port to the authorization VLAN without changing its
• Hybrid port with MAC-based
PVID.
VLAN disabled
NOTE:
The tagged attribute is supported only on trunk and hybrid ports.
The device maps the MAC address of each user to its own
Hybrid port with MAC-based VLAN
authorization VLAN regardless of whether the port is a tagged
enabled
member. The PVID of the port does not change.

IMPORTANT:
• If the users are attached to a port whose link type is access, make sure the authorization VLAN
assigned by the server has the untagged attribute. VLAN assignment will fail if the server issues
a VLAN that has the tagged attribute.
• When you assign VLANs to users attached to a trunk port or a MAC-based VLAN disabled hybrid
port, make sure there is only one untagged VLAN. If a different untagged VLAN is assigned to a
subsequent user, the user cannot pass authentication.
• As a best practice to enhance network security, do not use the port hybrid vlan command
to assign a hybrid port to an authorization VLAN as a tagged member.

The VLAN assigned by the server to a user as an authorization VLAN might have been configured on
the user access port but with a different tagging mode. For example, the server assigns an
authorization VLAN with a tagged attribute, but the same VLAN configured on the port has an
untagged attribute. In this situation, the VLAN settings that take effect on the user depend on the link
type of the port.
• If the link type of the port is access or trunk, the authorization VLAN settings assigned by the
server always take effect on the user as long as the user is online. After the user goes offline,
the VLAN settings on the port take effect.
• If the link type of the port is hybrid, the VLAN settings configured on the port take effect. For
example, the server assigns VLAN 30 with an untagged attribute to a user on the hybrid port.
However, VLAN 30 has been configured on the port with a tagged attribute by using the port
hybrid vlan tagged command. Finally, the VLAN has a tagged attribute on the port.
For a MAC authenticated user to access the network on a hybrid port when no authorization VLAN is
configured for the user, perform one of the following tasks:
• If the port receives tagged authentication packets from the user in a VLAN, use the port
hybrid vlan command to configure the port as a tagged member in the VLAN.
• If the port receives untagged authentication packets from the user in a VLAN, use the port
hybrid vlan command to configure the port as an untagged member in the VLAN.
Guest VLAN
The MAC authentication guest VLAN on a port accommodates users that have failed MAC
authentication for any reason other than server unreachable. For example, the VLAN
accommodates users with invalid passwords entered.
You can deploy a limited set of network resources in the MAC authentication guest VLAN. For
example, a software server for downloading software and system patches.
A hybrid port is always assigned to a MAC authentication guest VLAN as an untagged member. After
the assignment, do not reconfigure the port as a tagged member in the VLAN.

163
 The device reauthenticates users in the MAC authentication guest VLAN at a specific interval. Table
17 shows the way that the network access device handles guest VLANs for MAC authentication
users.
Table 17 VLAN manipulation

Authentication status VLAN manipulation

A user in the MAC authentication
guest VLAN fails MAC The user is still in the MAC authentication guest VLAN.
authentication.

The device remaps the MAC address of the user to the authorization
A user in the MAC authentication VLAN assigned by the authentication server.
guest VLAN passes MAC If no authorization VLAN is configured for the user on the authentication
authentication. server, the device remaps the MAC address of the user to the PVID of
the port.

Critical VLAN
The MAC authentication critical VLAN on a port accommodates users that have failed MAC
authentication because no RADIUS authentication servers are reachable. Users in a MAC
authentication critical VLAN can access only network resources in the critical VLAN.
The critical VLAN feature takes effect when MAC authentication is performed only through RADIUS
servers. If a MAC authentication user fails local authentication after RADIUS authentication, the user
is not assigned to the critical VLAN. For more information about the authentication methods, see
"Configuring AAA."
Table 18 shows the way that the network access device handles critical VLANs for MAC
authentication users.
Table 18 VLAN manipulation

Authentication status VLAN manipulation

The device maps the MAC address of the user to the MAC
authentication critical VLAN.
The user is still in the MAC authentication critical VLAN if
A user fails MAC authentication because all the the user fails MAC reauthentication because all the
RADIUS servers are unreachable. RADIUS servers are unreachable.
If no MAC authentication critical VLAN is configured, the
device maps the MAC address of the user to the PVID of
the port.

A user in the MAC authentication guest VLAN

fails authentication because all the RADIUS The user remains in the MAC authentication guest VLAN.
servers are unreachable.

If a guest VLAN has been configured, the device maps the

A user in the MAC authentication critical VLAN MAC address of the user to the guest VLAN.
fails MAC authentication for any reason other
than server unreachable. If no guest VLAN is configured, the device maps the MAC
address of the user to the PVID of the port.

The device remaps the MAC address of the user to the

authorization VLAN assigned by the authentication server.
A user in the MAC authentication critical VLAN
passes MAC authentication. If no authorization VLAN is configured for the user on the
authentication server, the device remaps the MAC
address of the user to the PVID of the access port.

164
Critical voice VLAN
The MAC authentication critical voice VLAN on a port accommodates MAC authentication voice
users that have failed authentication because none of the RADIUS servers in their ISP domain are
reachable.
The critical voice VLAN feature takes effect when MAC authentication is performed only through
RADIUS servers. If a MAC authentication voice user fails local authentication after RADIUS
authentication, the user is not assigned to the critical voice VLAN. For more information about the
authentication methods, see "Configuring AAA."
Table 19 shows the way that the network access device handles critical voice VLANs for MAC
authentication voice users.
Table 19 VLAN manipulation

Authentication status VLAN manipulation

The device maps the MAC address of the voice user to the
MAC authentication critical voice VLAN.
The voice user is still in the MAC authentication critical
A voice user fails MAC authentication because voice VLAN if the voice user fails MAC reauthentication
all the RADIUS servers are unreachable. because all the RADIUS servers are unreachable.
If no MAC authentication critical voice VLAN is configured,
the device maps the MAC address of the voice user to the
PVID of the port.
If a guest VLAN has been configured, the device maps the
A voice user in the MAC authentication critical MAC address of the voice user to the guest VLAN.
voice VLAN fails MAC authentication for any
reason other than server unreachable. If no guest VLAN is configured, the device maps the MAC
address of the voice user to the PVID of the port.

The device remaps the MAC address of the voice user to

the authorization VLAN assigned by the authentication
A voice user in the MAC authentication critical server.
voice VLAN passes MAC authentication. If no authorization VLAN is configured for the voice user
on the authentication server, the device remaps the MAC
address of the voice user to the PVID of the access port.

VSI manipulation
MAC authentication support for VXLANs
As shown in Figure 49, when the device acts as both a VXLAN VTEP and a NAS, users' service
information cannot be identified by VLANs. To resolve this issue, you must configure the RADIUS
server to assign VSIs to MAC authenticated users. The NAS will map a user's traffic to the VXLAN
that is associated with the user's authorization VSI. The mapping criteria include the user's access
VLAN, access port, and MAC address.
For information about VSIs and VXLANs, see VXLAN Configuration Guide.

165
 Figure 49 VXLAN network diagram for MAC authentication

Internet

RADIUS server

VXLAN
NAS NAS
(VTEP) (VTEP)
Distribution layer

AC Access layer

MAC authentication-
enabled port
Client Client Client AP Client

Authorization VSI
An authorization VSI is associated with a VXLAN that has network resources inaccessible to
unauthenticated users.
MAC authentication supports remote VSI authorization. If the VTEP does not receive authorization
VSI information for a MAC authentication user from the remote server, the user cannot access
resources in any VXLAN after passing authentication. If the VTEP receives authorization VSI
information for the user from the remote server, it performs the following operations:
• Dynamically creates an Ethernet service instance according to the user's access port, VLAN,
and MAC address.
• Maps the Ethernet service instance to the authorization VSI.
The user then can access resources in the VXLAN associated with the authorization VSI.
For information about dynamic creation of Ethernet service instances, see VXLAN configuration
Guide.
Guest VSI
The MAC authentication guest VSI on a port accommodates users that have failed MAC
authentication for any reason other than server unreachable. For example, the VSI accommodates
users with invalid passwords entered.
You can deploy a limited set of network resources in the VXLAN that is associated with the MAC
authentication guest VSI. For example, a software server for downloading software and system
patches.
Table 20 shows the way that the VTEP handles guest VSIs for MAC authentication users.

166
 Table 20 VSI manipulation

Authentication status VSI manipulation

A user fails MAC authentication
The VTEP maps the user's MAC address and access VLAN to the MAC
for any reason other than server
authentication guest VSI.
unreachable.
A user in the MAC authentication
guest VSI fails MAC
The user is still in the MAC authentication guest VSI.
authentication for any reason
other than server unreachable.
A user in the MAC authentication
The VTEP remaps the user's MAC address and access VLAN to the
guest VSI passes MAC
authorization VSI assigned by the authentication server.
authentication.

Critical VSI
The MAC authentication critical VSI on a port accommodates users that have failed MAC
authentication because no RADIUS authentication servers are reachable. Users in a MAC
authentication critical VSI can access only network resources in the VXLAN associated with this VSI.
The critical VSI feature takes effect when MAC authentication is performed only through RADIUS
servers. If a MAC authentication user fails local authentication after RADIUS authentication, the user
is not assigned to the critical VSI. For more information about the authentication methods, see
"Configuring AAA."
Table 21 shows the way that the VTEP handles critical VSIs for MAC authentication users.
Table 21 VSI manipulation

Authentication status VSI manipulation

The VTEP maps the user's MAC address and access
VLAN to the MAC authentication critical VSI.
The user is still in the MAC authentication critical VSI if the
A user fails MAC authentication because all the
user fails MAC reauthentication because all the RADIUS
RADIUS servers are unreachable.
servers are unreachable.
If no MAC authentication critical VSI is configured, the
device logs off the user.

A user in the MAC authentication critical VSI If a guest VSI has been configured, the VTEP maps the
fails MAC authentication for any reason other user's MAC address and access VLAN to the guest VSI.
than server unreachable. If no guest VSI is configured, the VTEP logs off the user.

A user in the MAC authentication guest VSI

fails authentication because all the RADIUS The user remains in the MAC authentication guest VSI.
servers are unreachable.

The VTEP remaps the user's MAC address and access

A user in the MAC authentication critical VSI
VLAN to the authorization VSI assigned by the
passes MAC authentication.
authentication server.

ACL assignment
You can specify an authorization ACL for a MAC authentication user on a remote server or the
access device to control the user's access to network resources. After the user passes MAC

167
 authentication, the server or access device assigns the authorization ACL to the user access port.
Then, the port permits or drops the matching traffic for the user depending on the rules in the ACL.
The device supports assignment of static and dynamic authorization ACLs.
• Assignment of static authorization ACLs—Static ACLs can be assigned by a RADIUS
server or the access device. When the server or access device assigns a static ACL to a user, it
assigns only the ACL number. You must manually create the ACL and configure its rules on the
access device.
To change the access permissions of a user, use one of the following methods:
 Modify ACL rules in the authorization ACL on the access device.
 Assign another ACL to the user as the authorization ACL from the RADIUS server or the
access device.
Static ACLs and their rules can be manually deleted from the access device.
• Assignment of dynamic authorization ACLs—Dynamic ACLs and their rules are
automatically deployed by a RADIUS server, which are not configurable on the access device.
Dynamic ACLs can only be named ACLs. After the device receives a server-deployed dynamic
ACL and its rules, it automatically creates the ACL and configures its rules.
If a dynamic ACL assigned by the server to a user has the same name as a static ACL, the
dynamic ACL cannot be issued and the user cannot come online.
A dynamic ACL and its rules are automatically deleted from the access device after all its users
go offline.
Dynamic ACLs and their rules cannot be manually modified or deleted on the access device. To
display information about dynamic ACLs and their rules, use the display
mac-authentication connection or display acl command.

IMPORTANT:
The supported authorization ACLs include the following types:
• Basic ACLs, which are numbered in the range of 2000 to 2999.
• Advanced ACLs, which are numbered in the range of 3000 to 3999.
• Layer 2 ACLs, which are numbered in the range of 4000 to 4999.
For an authorization ACL to take effect, make sure the ACL exists with rules and none of the rules
contains the counting, established, fragment, source-mac, cos, dest-mac, lsap,
vxlan, or logging keyword.
For more information about ACLs, see ACL and QoS Configuration Guide.

User profile assignment

You can specify a user profile in the user account for a MAC authentication user on the
authentication server to control the user's access to network resources. After the user passes MAC
authentication, the authentication server assigns the user profile to the user to filter traffic for this
user.
The authentication server can be the local access device or a RADIUS server. In either case, the
server only specifies the user profile name. You must configure the user profile on the access device.
To change the user's access permissions, you can use one of the following methods:
• Modify the user profile configuration on the access device.
• Specify another user profile for the user on the authentication server.
For more information about user profiles, see "Configuring user profiles."

168
Redirect URL assignment
The device supports the URL attribute assigned by a RADIUS server. During MAC authentication,
the HTTP or HTTPS requests of a user are redirected to the Web interface specified by the
server-assigned URL attribute. After the user passes the Web authentication, the RADIUS server
records the MAC address of the user and uses a DM (Disconnect Message) to log off the user. When
the user initiates MAC authentication again, it will pass the authentication and come online
successfully.
By default, the device listens to port 6654 for HTTPS requests to be redirected. To change the
redirect listening port number, see configuring HTTP redirect in Layer 3—IP Services Configuration
Guide.

CAR attribute assignment

The device can use the CAR attributes assigned through RADIUS extended attributes to control the
access rates of online MAC authenticated users. For information about extended RADIUS attributes,
see "Configuring AAA."
The following CAR attributes are available:
• Input-Peak-Rate—Peak rate of inbound traffic in bps.
• Input-Average-Rate—Average rate of inbound traffic in bps.
• Output-Peak-Rate—Peak rate of outbound traffic in bps.
• Output-Average-Rate—Average rate of outbound traffic in bps.
If the server assigns CAR attributes for controlling both the peak and average rates, the device
implements double-rate traffic policing on user traffic. If the server does not assign the
Input-Peak-Rate or Output-Peak-Rate attribute, the device implements single-rate traffic policing on
user traffic. For more information about traffic policing, see QoS configuration in ACL and QoS
Configuration Guide.

Blackhole MAC attribute assignment

The device supports the blackhole MAC attribute assigned by the RADIUS authentication server
through CoA messages for users that have passed MAC authentication. Upon receiving a CoA
message that contains the blackhole MAC attribute for a user that has passed MAC authentication,
the device performs the following operations:
1. Logs off the user.
2. Marks the MAC address of the user as a silent MAC address and starts a quiet timer for the
MAC address.
The quiet timer is 10 minutes and is not user configurable. The device drops all packets from the
MAC address after the quiet timer starts, and it will not authenticate the MAC address until the quiet
timer expires.
To display silent MAC addresses, use the display mac-authentication command.

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 and VLAN.
The device reauthenticates online MAC authentication users at the periodic reauthentication interval
when the periodic MAC reauthentication feature is enabled. The interval is controlled by a timer and
the timer is user configurable. A change to the periodic reauthentication timer applies to online MAC

169
 authentication users only after the old timer expires and the MAC authentication users pass
authentication.
The server-assigned RADIUS Session-Timeout (attribute 27) and Termination-Action (attribute 29)
attributes together can affect the periodic MAC reauthentication feature. To display the
server-assigned Session-Timeout and Termination-Action attributes, use the display
mac-authentication connection command.
• If the termination action is to log off users, periodic MAC reauthentication takes effect only when
the periodic reauthentication timer is shorter than the session timeout timer. If the session
timeout timer is shorter, the device logs off online authenticated users when the session timeout
timer expires.
• If the termination action is to reauthenticate users, the periodic MAC reauthentication
configuration on the device cannot take effect. The device reauthenticates online MAC
authentication users after the server-assigned session timeout timer expires.
If no session timeout timer is assigned by the server, whether the device performs periodic MAC
reauthentication depends on the periodic MAC reauthentication configuration on the device. Support
for the assignment of Session-Timeout and Termination-Action attributes depends on the server
model.
With the RADIUS DAS feature enabled, the device immediately reauthenticates a user upon
receiving a CoA message that carries the reauthentication attribute from a RADIUS authentication
server. In this case, reauthentication will be performed regardless of whether periodic MAC
reauthentication is enabled on the device. For more information about RADIUS DAS configuration,
see "Configuring AAA."
By default, the device logs off online MAC authentication users if no server is reachable for MAC
reauthentication. The keep-online feature keeps authenticated MAC authentication users online
when no server is reachable for MAC reauthentication.
The VLANs assigned to an online user before and after reauthentication can be the same or
different.

RESTful server-assisted MAC authentication user recovery

Applicable scenario
After online dumb terminals such as printers go offline, they cannot reauthenticate to come online
until after they send a service packet. This might cause the dumb terminals to stay offline for a long
time after the device or their attached interface module reboots or after their attached interfaces fail.
To avoid this situation, you can configure the device to work with the authentication server and a
RESTful server to trigger MAC reauthentication for dumb terminals or retain their online state.

NOTE:
This feature is available only when you use IMC server as the authentication server and the RESTful
server.

Working mechanism
The following information describes how RESTful server-assisted MAC authentication user recovery
works:
1. The authentication server includes the shutdown-keep-online proprietary attribute in the
authorization attributes assigned to a dumb terminal after it passes authentication.
2. After receiving the authentication result from the authentication server, the device allows the
dumb terminal user to come online and marks it as a dumb terminal user.
3. When a device or interface issue occurs, the device handles the dumb terminal user as follows:

170
  If the interface is physical down, the device retains the online state of the dumb terminal
user.
 If the device or the interface module reboots or if the interface recovers from a failure, the
device obtains MAC authentication user information from the RESTful server to perform
MAC reauthentication.

Restrictions and guidelines: MAC authentication

configuration
When you configure MAC authentication on an interface, follow these restrictions and guidelines:
• MAC authentication is supported only on Layer 2 Ethernet interfaces and Layer 2 aggregate
interfaces.
• If you add a Layer 2 Ethernet interface to an aggregation group, the MAC authentication
settings configured on it will not take effect until it is removed from the aggregation group.
• Do not delete a Layer 2 aggregate interface if the interface has online MAC authentication
users.
• Do not change the link type of a port when the MAC authentication guest VLAN or critical VLAN
on the port has users.
When you configure MAC authentication VLANs or VSIs, follow these restrictions and guidelines:
• If the server assigns both an authorization VSI and authorization VLAN to a user, the device
uses only the authorization VLAN.
• On a port, the guest VLAN and critical VLAN settings are mutually exclusive with the guest VSI
and critical VSI settings.
• To ensure a successful authentication, you must configure the authentication server to assign
authorization VLANs or VSIs to the MAC authentication users attached to a port in the following
situations:
 If the MAC authentication-enabled port is configured with the guest VLAN or critical VLAN,
configure the authentication server to assign authorization VLANs to MAC authentication
users.
 If the MAC authentication-enabled port is configured with the guest VSI or critical VSI,
configure the authentication server to assign authorization VSIs to MAC authentication
users.
 If both 802.1X and MAC authentication are configured on the port, be careful with the VSI
settings of the two authentication features.
− You must configure VSI authorization for the MAC authentication users if the port has an
Auth-Fail, guest, or critical VSI for 802.1X authentication.
− Likewise, you must configure VSI authorization for the 802.1X users if the port has a
guest or critical VSI for MAC authentication.
If the MAC address that has failed authentication is a static MAC address or a MAC address that has
passed any security authentication, the device does not mark the MAC address as a silent address.

MAC authentication tasks at a glance

To configure MAC authentication, perform the following tasks:
1. Enabling MAC authentication
2. Configure basic MAC authentication features
 Specifying a MAC authentication method
 Specifying a MAC authentication domain

171
  Configuring user account policy
 (Optional.) Configuring MAC authentication timers
 (Optional.) Configuring periodic MAC reauthentication
3. (Optional.) Configuring MAC authentication VLAN assignment
 Configuring a MAC authentication guest VLAN
 Configuring a MAC authentication critical VLAN
 Enabling the MAC authentication critical voice VLAN feature
4. (Optional.) Configuring MAC authentication VSI assignment
 Configuring a MAC authentication guest VSI
 Configuring a MAC authentication critical VSI
5. (Optional.) Configuring other MAC authentication features
 Configuring unauthenticated MAC authentication user aging
 Configuring MAC authentication offline detection
 Enabling online user synchronization for MAC authentication
 Setting the maximum number of concurrent MAC authentication users on a port
 Enabling MAC authentication multi-VLAN mode on a port
Perform this task to not reauthenticate online users when VLAN changes occur on a port.
 Configuring MAC authentication delay
 Including user IP addresses in MAC authentication requests
 Enabling parallel MAC authentication and 802.1X authentication
 Configuring RESTful server-assisted MAC authentication user recovery
 Configuring Web proxy ports for URL redirection in MAC authentication
 Logging off MAC authentication users
 Enabling MAC authentication user logging

Prerequisites for MAC authentication

Before you configure MAC authentication, complete the following tasks:
1. Make sure the port security feature is disabled. For more information about port security, see
"Configuring port security."
2. Configure an ISP domain and specify an AAA method. For more information, see "Configuring
AAA."
 For local authentication, you must also create local user accounts (including usernames
and passwords) and specify the lan-access service for local users.
 For RADIUS authentication, make sure the device and the RADIUS server can reach each
other and create user accounts on the RADIUS server. If you are using MAC-based
accounts, make sure the username and password for each account are the same as the
MAC address of each MAC authentication user.

Enabling MAC authentication

Restrictions and guidelines
For MAC authentication to take effect on a port, you must enable this feature globally and on the port.
MAC authentication cannnot take effect on a port if the device has run out of ACL resources when
you perform either of the following operations:

172
 • Enable MAC authentication on the port while MAC authentication has been enabled globally.
• Enable MAC authentication globally in system while MAC authentication has been enabled on
the port.
Procedure
1. Enter system view.
system-view
2. Enable MAC authentication globally.
mac-authentication
By default, MAC authentication is disabled globally.
3. Enter interface view.
interface interface-type interface-number
4. Enable MAC authentication on the port.
mac-authentication
By default, MAC authentication is disabled on a port.

Specifying a MAC authentication method

About this task
RADIUS-based MAC authentication supports the following authentication methods:
• PAP—Transports usernames and passwords in plain text. The authentication method applies
to scenarios that do not require high security.
• CHAP—Transports usernames in plain text and passwords in encrypted form over the network.
CHAP is more secure than PAP.
Restrictions and guidelines
The device must use the same authentication method as the RADIUS server.
Procedure
1. Enter system view.
system-view
2. Specify an authentication method for MAC authentication.
mac-authentication authentication-method { chap | pap }
By default, the device uses PAP for MAC authentication.

Specifying a MAC authentication domain

About this task
By default, MAC authentication users are in the system default authentication domain. To implement
different access policies for users, you can use one of the following methods to specify
authentication domains for MAC authentication users:
• Specify a global authentication domain in system view. This domain setting applies to all ports
enabled with MAC authentication.
• Specify an authentication domain for an individual port in interface view.
MAC authentication chooses an authentication domain for users on a port in this order: the
port-specific domain, the global domain, and the default domain. For more information about
authentication domains, see "Configuring AAA."

173
Procedure
1. Enter system view.
system-view
2. Specify an authentication domain for MAC authentication users.
 In system view:
mac-authentication domain domain-name
 In interface view:
interface interface-type interface-number
mac-authentication domain domain-name
By default, the system default authentication domain is used for MAC authentication users.

Configuring user account policy

Restrictions and guidelines
For users in a MAC address range, the MAC address range-specific user account has higher priority
than the global user account settings.
You can configure a maximum of 16 MAC address ranges and must make sure the MAC address
ranges do not overlap.
If you configure user account settings multiple times for the same MAC address range, the most
recent configuration overwrites the previous configuration.
The MAC range-specific accounts apply only to unicast MAC addresses.
• If you specify a MAC address range that contains only multicast MAC addresses, execution of
this command will fail.
• If you specify a MAC address range that contains both unicast and multicast MAC addresses,
the command takes effect only on unicast MAC addresses.
The all-zero MAC address is invalid for MAC authentication. Users with the all-zero MAC address
cannot pass MAC authentication.
Procedure
1. Enter system view.
system-view
2. Configure the global MAC authentication user account policy.
 Use one MAC-based user account for each user.
mac-authentication user-name-format mac-address [ { with-hyphen |
without-hyphen } [ lowercase | uppercase ] ] [ password { cipher |
simple } string ]
 Use one shared user account for all users.
mac-authentication user-name-format fixed [ account name ]
[ password { cipher | simple } string ]
By default, the device uses the MAC address of each user as both the username and password
for MAC authentication. The MAC addresses are in hexadecimal notation without hyphens, and
letters are in lower case.
3. Specify one shared user account specific to a MAC address range.
mac-authentication mac-range-account mac-address mac-address mask
{ mask | mask-length } account name password { cipher | simple } string
By default, no username or password is configured specific to a MAC address range. The
global user account policy applies to the users.

174
Configuring MAC authentication timers
About this task
MAC authentication uses the following timers:
• Offline detect timer—Sets the interval that the device must wait for traffic from a user before
the device determines that the user is idle. If the device has not received traffic from a user
before the timer expires, the device logs off that user and requests the accounting server to stop
accounting for the user. This timer takes effect only when the MAC authentication offline
detection feature is enabled.
As a best practice, set the MAC address aging timer to the same value as the offline detect
timer. This operation prevents a MAC authenticated user from being logged off within the offline
detect interval because of MAC address entry expiration.
• Quiet timer—Sets the interval that the device must wait before the device can perform MAC
authentication for a user that has failed MAC authentication. All packets from the MAC address
are dropped during the quiet time. This quiet mechanism prevents repeated authentication from
affecting system performance.
• Server timeout timer—Sets the interval that the device waits for a response from a RADIUS
server before the device determines that the RADIUS server is unavailable. If the timer expires
during MAC authentication, the user fails MAC authentication.
• Aging timer for temporary MAC authentication users—Sets the aging timer for temporary
MAC authentication users. This timer starts when a user passes MAC authentication on a port
operating in macAddressAndUserLoginSecureExt mode. If the device has not received
802.1X protocol packets from the MAC authenticated user on that port before the timer expires,
the device determines that the user has failed authentication. Then, the device logs off the user.
For more information about the port security mode, see "Configuring port security."
Restrictions and guidelines
To avoid forced logoff before the server timeout timer expires, set the server timeout timer to a value
that is lower than or equal to the product of the following values:
• The maximum number of RADIUS packet transmission attempts set by using the retry
command in RADIUS scheme view.
• The RADIUS server response timeout timer set by using the timer response-timeout
command in RADIUS scheme view.
For information about setting the maximum number of RADIUS packet transmission attempts and
the RADIUS server response timeout timer, see "Configuring AAA."
Procedure
1. Enter system view.
system-view
2. Configure MAC authentication timers.
mac-authentication timer { offline-detect offline-detect-value |
quiet quiet-value | server-timeout server-timeout-value |
temporary-user-aging aging-time-value }
The default settings are as follows:
 The offline detect timer is 300 seconds.
 The quiet timer is 60 seconds.
 The server timeout timer is 100 seconds.
 The temporary user aging timer is 60 seconds.

175
Configuring periodic MAC reauthentication
Restrictions and guidelines
The device selects a periodic reauthentication timer for MAC reauthentication in the following order:
1. Server-assigned reauthentication timer.
2. Port-specific reauthentication timer.
3. Global reauthentication timer.
4. Default reauthentication timer.
Modification to the MAC authentication domain, MAC authentication method, or user account format
setting does not affect the reauthentication of online MAC authentication users. The modified setting
takes effect only on MAC authentication users that come online after the modification.
If periodic reauthentication is triggered for a user while that user is waiting for online synchronization,
the system performs online synchronization and does not perform reauthentication for the user.
Procedure
1. Enter system view.
system-view
2. Set the periodic MAC reauthentication timer.
 Set a global periodic reauthentication timer.
mac-authentication timer reauth-period reauth-period-value
The default setting is 3600 seconds.
 Execute the following commands in sequence to set a port-specific periodic
reauthentication timer:
interface interface-type interface-number
mac-authentication timer reauth-period reauth-period-value
quit
By default, no periodic MAC reauthentication timer is set on a port. The port uses the global
periodic MAC reauthentication timer.
3. Enter interface view.
interface interface-type interface-number
4. Enable periodic MAC reauthentication.
mac-authentication re-authenticate
By default, periodic MAC reauthentication is disabled on a port.
5. (Optional.) Enable the keep-online feature for MAC authenticated users on the port.
mac-authentication re-authenticate server-unreachable keep-online
By default, the keep-online feature is disabled. The device logs off online MAC authentication
users if no server is reachable for MAC reauthentication.
In a fast-recovery network, you can use the keep-online feature to prevent MAC authentication
users from coming online and going offline frequently.

176
Configuring a MAC authentication guest VLAN
Specifying a MAC authentication guest VLAN on a port
Restrictions and guidelines
When you configure the MAC authentication guest VLAN on a port, follow the guidelines in Table 22.
Table 22 Relationships of the MAC authentication guest VLAN with other security features

Feature Relationship description Reference

The MAC authentication guest VLAN feature
has higher priority.
Quiet feature of MAC When a user fails MAC authentication, the See "Configuring MAC
authentication user can access the resources in the guest authentication timers."
VLAN. The user's MAC address is not marked
as a silent MAC address.

You cannot specify a VLAN as both a super See Layer 2—LAN Switching
Super VLAN
VLAN and a MAC authentication guest VLAN. Configuration Guide.

The guest VLAN feature has higher priority

than the block MAC action but lower priority See "Configuring port
Port intrusion protection
than the shutdown port action of the port security."
intrusion protection feature.

Prerequisites
Before you configure the MAC authentication guest VLAN on a port, complete the following tasks:
• Create the VLAN to be specified as the MAC authentication guest VLAN.
• Configure the port as a hybrid port, and configure the VLAN as an untagged member on the
port.
• Enable MAC-based VLAN on the port.
For information about VLAN configuration, see Layer 2—LAN Switching Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Specify the MAC authentication guest VLAN on the port.
mac-authentication guest-vlan guest-vlan-id
By default, no MAC authentication guest VLAN is specified on a port.
You can configure only one MAC authentication guest VLAN on a port. The MAC authentication
guest VLANs on different ports can be different.

Enabling guest VLAN reauthentication in MAC authentication

About this task
The guest VLAN reauthentication feature of MAC authentication enables the device to
reauthenticate users in the MAC authentication guest VLAN on a port at reauthentication intervals.

177
 By default, this feature is enabled. You can disable it as needed to suppress excessive
authentication failure log messages, which might occur when a network issue results in a large
number of reauthentication failures.
If guest VLAN reauthentication is disabled on a port, the device does not reauthenticate users in the
MAC authentication guest VLAN on the port. The guest VLAN users will stay in the guest VLAN until
they age out. To control guest VLAN user aging functionality, use the mac-authentication
unauthenticated-user aging enable command. To configure the aging timer, use the
mac-authentication timer user-aging guest-vlan aging-time-value command.
Restrictions and guidelines
As a best practice, set the reauthentication interval to a value greater than 30 seconds if the number
of concurrent MAC authentication users on a port is likely to exceed 300.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable the guest VLAN reauthentication feature of MAC authentication on the port.
mac-authentication guest-vlan re-authenticate
By default, the guest VLAN reauthentication feature of MAC authentication is enabled on a port.
4. Set the authentication interval for users in the MAC authentication guest VLAN.
mac-authentication guest-vlan auth-period period-value
The default setting is 30 seconds.

Configuring a MAC authentication critical VLAN

Restrictions and guidelines
When you configure the MAC authentication critical VLAN on a port, follow the guidelines in Table
23.
Table 23 Relationships of the MAC authentication critical VLAN with other security features

Feature Relationship description Reference

The MAC authentication critical VLAN feature has
higher priority.
Quiet feature of MAC When a user fails MAC authentication because no See "Configuring MAC
authentication RADIUS authentication server is reachable, the authentication timers."
user can access the resources in the critical
VLAN. The user's MAC address is not marked as
a silent MAC address.

See Layer 2—LAN

You cannot specify a VLAN as both a super VLAN
Super VLAN Switching Configuration
and a MAC authentication critical VLAN.
Guide.

The critical VLAN feature has higher priority than

the block MAC action but lower priority than the See "Configuring port
Port intrusion protection
shutdown port action of the port intrusion security."
protection feature.

Prerequisites
Before you configure the MAC authentication critical VLAN on a port, complete the following tasks:

178
 • Create the VLAN to be specified as the MAC authentication critical VLAN.
• Configure the port as a hybrid port, and configure the VLAN as an untagged member on the
port.
• Enable MAC-based VLAN on the port.
For information about VLAN configuration, see Layer 2—LAN Switching Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Specify the MAC authentication critical VLAN on the port.
mac-authentication critical vlan critical-vlan-id
By default, no MAC authentication critical VLAN is specified on a port.
You can configure only one MAC authentication critical VLAN on a port. The MAC
authentication critical VLANs on different ports can be different.

Enabling the MAC authentication critical voice

VLAN feature
Prerequisites
Before you enable the MAC authentication critical voice VLAN feature on a port, complete the
following tasks:
• Enable LLDP both globally and on the port.
The device uses LLDP to identify voice users. For information about LLDP, see Layer 2—LAN
Switching Configuration Guide.
• Enable voice VLAN on the port.
For information about voice VLANs, see Layer 2—LAN Switching Configuration Guide.
• Specify a MAC authentication critical VLAN on the port. This setting ensures that a voice user is
assigned to the critical VLAN if it has failed authentication for unreachability of RADIUS servers
before the device recognizes it as a voice user. If a MAC authentication critical VLAN is not
available, the voice user might be logged off instead.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable the MAC authentication critical voice VLAN feature on a port.
mac-authentication critical-voice-vlan
By default, the MAC authentication critical voice VLAN feature is disabled on a port.

179
Configuring a MAC authentication guest VSI
Specifying a MAC authentication guest VSI on a port
Restrictions and guidelines
The MAC authentication guest VSI feature has higher priority than the quiet feature of MAC
authentication. When a user fails MAC authentication, the user can access the resources in the
guest VSI. The user's MAC address is not marked as a silent MAC address.
You can configure only one MAC authentication guest VSI on a port. The MAC authentication guest
VSIs on different ports can be different.
Prerequisites
Before you configure the MAC authentication guest VSI on a port, complete the following tasks:
• Enable L2VPN.
• Create the VSI to be specified as the MAC authentication guest VSI, and create a VXLAN for
the VSI.
• Enable MAC-based traffic match mode for dynamic Ethernet service instances on the port.
For more information, see VXLAN Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Specify the MAC authentication guest VSI on the port.
mac-authentication guest-vsi guest-vsi-name
By default, no MAC authentication guest VSI exists on a port.

Enabling guest VSI reauthentication in MAC authentication

About this task
The guest VSI reauthentication feature of MAC authentication enables the device to reauthenticate
users in the MAC authentication guest VSI on a port at reauthentication intervals.
You can enable guest VSI reauthentication by using the mac-authentication guest-vsi
re-authenticate command or disable the feature by using the undo form of the command.
Typically, you disable this feature to suppress excessive authentication failure log messages, which
might occur when a network issue results in a large number of reauthentication failures.
If guest VSI reauthentication is disabled on a port, the device does not reauthenticate users in the
MAC authentication guest VSI on the port. The guest VSI users will stay in the guest VSI until they
age out. To configure the aging timer, use the mac-authentication timer user-aging
guest-vsi aging-time-value command.
Restrictions and guidelines
As a best practice, set the reauthentication interval to a value greater than 30 seconds if the number
of concurrent MAC authentication users on a port is likely to exceed 300.
Procedure
1. Enter system view.

180
 system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable the guest VSI reauthentication feature of MAC authentication on the port.
mac-authentication guest-vsi re-authenticate
By default, the guest VSI reauthentication feature of MAC authentication is enabled on a port.
4. Set the authentication interval for users in the MAC authentication guest VSI.
mac-authentication guest-vsi auth-period period-value
The default setting is 30 seconds.

Configuring a MAC authentication critical VSI

Restrictions and guidelines
The MAC authentication critical VSI feature has higher priority than the quiet feature of MAC
authentication. When a user fails MAC authentication, the user can access the resources in the
critical VSI. The user's MAC address is not marked as a silent MAC address.
You can configure only one MAC authentication critical VSI on a port. The MAC authentication
critical VSIs on different ports can be different.
Prerequisites
Before you configure the MAC authentication critical VSI on a port, complete the following tasks:
• Enable L2VPN.
• Create the VSI to be specified as the MAC authentication critical VSI, and create a VXLAN for
the VSI.
• Enable MAC-based traffic match mode for dynamic Ethernet service instances on the port.
For more information, see VXLAN Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Specify the MAC authentication critical VSI on the port.
mac-authentication critical vsi critical-vsi-name
[ url-user-logoff ]
By default, no MAC authentication critical VSI exists on a port.
The url-user-logoff keyword enables the device to log off MAC authentication users that
have been assigned authorization URLs on the port when the first user is assigned to the critical
VSI.

181
Configuring unauthenticated MAC authentication
user aging
About this task
Unauthenticated MAC authentication user aging applies to users added to a MAC authentication
guest or critical VLAN or VSI because they have not been authenticated or have failed
authentication.
When a user in one of those VLANs or VSIs ages out, the device removes the user from the VLAN or
VSI and deletes the MAC address entry for the user from the access port.
For users in one of those VLANs or VSIs on one port to be authenticated successfully and come
online on another port, enable this feature. In any other scenarios, disable this feature as a best
practice.
Restrictions and guidelines
As a best practice, use this feature on a port only if you want to have its unauthenticated users to be
authenticated and come online on a different port.
Procedure
1. Enter system view.
system-view
2. Set the user aging timer for a type of MAC authentication VLAN or VSI.
mac-authentication timer user-aging { critical-vlan | critical-vsi
| guest-vlan | guest-vsi } aging-time-value
By default, the user aging timer is 1000 seconds for all applicable types of MAC authentication
VLANs and VSIs.
3. Enter interface view.
interface interface-type interface-number
4. Enable unauthenticated MAC authentication user aging.
mac-authentication unauthenticated-user aging enable
By default, unauthenticated MAC authentication user aging is enabled.

Configuring MAC authentication offline detection

About this task
Enable MAC authentication offline detection to detect idle users on a port. If the port has not received
traffic from a user when the offline detect timer expires, the device logs off that user and requests the
accounting server to stop accounting for the users. For information about setting the offline detect
timer in system view, see "Configuring MAC authentication timers."
Disabling this feature disables the device from inspecting the online user status.
In addition to port-based MAC authentication offline detection, you can configure offline detection
parameters on a per-user basis, as follows:
• Set an offline detect timer specific to a user and control whether to use the ARP snooping or ND
snooping table to determine the offline state of the user.
 If the ARP snooping or ND snooping table is used, the device searches the ARP snooping
or ND snooping table before it checks for traffic from the user within the detection interval. If
a matching ARP snooping or ND snooping entry is found, the device resets the offline detect
timer and the user stays online. If the offline detect timer expires because the device has not

182
 found a matching snooping entry for the user or received traffic from the user, the device
disconnects the user.
 If the ARP or ND snooping table is not used, the device disconnects the user if it has not
received traffic from that user before the offline detect timer expires.
When disconnecting the user, the device also notifies the RADIUS server (if any) to stop user
accounting.
• Skip offline detection for the user. You can choose this option if the user is a dumb terminal. A
dumb terminal might fail to come online again after it is logged off by the offline detection
feature.
The device uses the offline detection settings for a user in the following sequence:
1. User-specific offline detection settings.
2. Offline detection settings assigned to the user by the RADIUS server. The settings include the
offline detect timer, use of the ARP or ND snooping table in offline detection, and whether to
ignore offline detection.
3. Port-based offline detection settings.
Restrictions and guidelines
For the user-specific offline detection feature to take effect on a user, make sure the MAC
authentication offline detection feature is enabled on the user's access port.
The user-specific offline detection settings take effect on the online users immediately after they are
configured.
If you enable MAC authentication offline detection on a Layer 2 aggregate interface, delay exists for
the device to log off an idle user.
Procedure
1. Enter system view.
system-view
2. (Optional.) Configure MAC authentication offline detection for a user.
mac-authentication offline-detect mac-address mac-address { ignore
| timer offline-detect-value [ check-arp-or-nd-snooping ] }
By default, offline detection settings configured on access ports take effect and the offline
detect timer set in system view is used.
3. Enter interface view.
interface interface-type interface-number
4. Enable MAC authentication offline detection.
mac-authentication offline-detect enable
By default, MAC authentication offline detection is enabled on a port.

Enabling online user synchronization for MAC

authentication
About this task

IMPORTANT:
This feature takes effect only when the device uses an IMC RADIUS server to authenticate MAC
authentication users.

183
 To ensure that the RADIUS server maintains the same online MAC authentication user information
as the device after the server state changes from unreachable to reachable, use this feature.
This feature synchronizes online MAC authentication user information between the device and the
RADIUS server when the RADIUS server state is detected having changed from unreachable to
reachable.
When synchronizing online MAC authentication user information on a port with the RADIUS server,
the device initiates MAC authentication in turn for each authenticated online MAC authentication
user to the RADIUS server.
If synchronization fails for an online user, the device logs off that user unless the failure occurs
because the server has become unreachable again.
Restrictions and guidelines
The amount of time required to complete online user synchronization increases as the number of
online users grows. This might result in an increased delay for new MAC authentication users and
users in the critical VLAN or VSI to authenticate or reauthenticate to the RADIUS server and come
online.
To have this feature take effect, you must use it in conjunction with the RADIUS server status
detection feature, which is configurable with the radius-server test-profile command.
When you configure this feature, make sure the detection interval is shorter than the RADIUS server
quiet timer configured by using the timer quiet command in RADIUS scheme view. The server
state changes to active on expiration of the quiet timer regardless of its actual reachability. Setting a
shorter detection interval than the quiet timer prevents the RADIUS server status detection feature
from falsely reporting the server reachability.
For more information about the RADIUS server status detection feature, see "Configuring AAA."
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable online user synchronization for MAC authentication.
mac-authentication server-recovery online-user-sync
By default, online user synchronization for MAC authentication is disabled.

Setting the maximum number of concurrent MAC

authentication users on a port
About this task
Perform this task to prevent the system resources from being overused.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Set the maximum number of concurrent MAC authentication users on the port.
mac-authentication max-user max-number
The default setting is 4294967295.

184
Enabling MAC authentication multi-VLAN mode
on a port
About this task
By default, MAC authentication single-VLAN mode applies on a port. In this mode, traffic from an
online user cannot be sent in different VLANs on a port without service interruption. To accommodate
applications that are sensitive to delay or service interruption in a multi-VLAN environment, for
example, IP phones, enable MAC authentication multi-VLAN mode.
In multi-VLAN mode, the port forwards traffic from a user in different VLANs without reauthentication
if the user has been authenticated and come online in any VLAN on the port. Free of reauthentication,
traffic from an online user can be sent in different VLANs without delay or service interruption.
In single-VLAN mode, the port reauthenticates an online user when traffic received from that user
contains a VLAN tag different from the VLAN in which the user was authenticated. The
authentication process differs depending on the MAC move setting in port security and the
authorization VLAN assignment status, as follows:
• If no authorization VLAN has been assigned to the online user, the device first logs off the user
and then reauthenticates the user in the new VLAN.
• If the online user has been assigned an authorization VLAN, the device handles the user
depending on the MAC move setting in port security.
 If MAC move is disabled in port security, the user cannot pass authentication and come
online from the new VLAN until after it goes offline from the port.
 If MAC move is enabled in port security, the user can pass authentication on the new VLAN
and come online without having to first go offline from the port. After the user passes
authentication on the new VLAN, the original authentication session of the user is deleted
from the port.
To enable the port security MAC move feature, use the port-security mac-move
permit command.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable MAC authentication multi-VLAN mode.
mac-authentication host-mode multi-vlan
By default, MAC authentication operates in single-VLAN mode on a port.

Configuring MAC authentication delay

About this task
When both 802.1X authentication and MAC authentication are enabled on a port, you can delay
MAC authentication so that 802.1X authentication 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.
Restrictions and guidelines
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

185
 effect on a port in either of the two modes. For more information about port security modes, see
"Configuring port security."
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable MAC authentication delay and set the delay timer.
mac-authentication timer auth-delay time
By default, MAC authentication delay is disabled.

Including user IP addresses in MAC

authentication requests
About this task

IMPORTANT:
This feature can only operate in conjunction with an IMC server.

To avoid IP conflicts that result from changes to static IP addresses, use this feature on a port that
has MAC authentication users with static IP addresses.
This feature adds user IP addresses to the MAC authentication requests sent to the authentication
server. When MAC authentication is triggered for a user, the device checks the user's IP address for
invalidity.
• If the IP address is valid, the device sends a MAC authentication request with the IP address
included.
• If the IP address is not a valid host IP address or the triggering packet does not contain an IP
address, the device does not initiate MAC authentication.
• If the packet is a DHCP packet with a source IP address of 0.0.0.0, the device sends a MAC
authentication request without including the IP address. In this case, the IMC server does not
examine the user IP address when it performs authentication.
Upon receipt of the authentication request that includes a user's IP address, the IMC server
compares the user's IP and MAC addresses with its local IP-MAC mappings.
• If an exact match is found or if no match is found, the user passes MAC authentication. In the
latter case, the server creates an IP-MAC mapping for the user.
• If a mapping is found for the MAC address but the IP addresses do not match, the user fails the
MAC authentication.
Restrictions and guidelines
Do not use this feature in conjunction with the MAC authentication guest VLAN or guest VSI on a port.
The device cannot perform MAC authentication for a user once that user is added to the MAC
authentication guest VLAN or guest VSI.
You can specify an ACL to identify source IP addresses that can or cannot trigger MAC
authentication. When you configure the ACL, follow these guidelines:
• The specified ACL number represents an IPv4 ACL and an IPv6 ACL with the same number.
For example, if the ACL number is 2000, you specify both IPv4 ACL 2000 and IPv6 ACL 2000.
The IPv4 ACL and the IPv6 ACL will be used to process IPv4 packets and IPv6 packets,
respectively.

186
 • Use permit rules to identify source IP addresses that are valid for MAC authentication. Use
deny rules to identify source IP addresses that cannot trigger MAC authentication.
• In the rules, only the action keyword (permit or deny) and the source IP match criterion can take
effect.
• As a best practice, configure a deny rule to exclude the IPv6 IP addresses that start with fe80
from triggering MAC authentication.
• If you configure permit rules, add a deny all rule at the bottom of the ACL.

IMPORTANT:
If the user host is configured with IPv6, the device might receive packets that contain an IPv6
link-local address, which starts with fe80. MAC authentication failure or incorrect MAC-IP binding will
occur if this address is used in MAC authentication. To avoid these issues, configure a basic ACL to
exclude the IPv6 IP addresses that start with fe80.

Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Include user IP addresses in MAC authentication requests.
mac-authentication carry user-ip [ exclude-ip acl acl-number ]
By default, a MAC authentication request does not include the user IP address.

Enabling parallel MAC authentication and 802.1X

authentication
About this task
This feature enables a port to perform MAC authentication in parallel with 802.1X authentication
when it receives a packet from an unknown MAC address.
This feature applies to the following situation in which MAC authentication can be performed only
after 802.1X authentication is completed:
• The port is configured with both 802.1X authentication and MAC authentication and performs
MAC-based access control for 802.1X authentication.
• The port is enabled with the 802.1X unicast trigger.
With parallel authentication enabled, the port performs MAC authentication while sending a unicast
EAP-Request/Identity packet to trigger 802.1 authentication when it receives a packet from an
unknown MAC address.
If MAC authentication succeeds before 802.1X authentication is completed, the port is assigned to
the MAC authentication authorization VLAN or VSI. When 802.1X authentication completes, the
device manipulates VLAN assignment depending on the authentication result, as follows:
• If 802.1X authentication fails, the MAC authentication result takes effect.
• If 802.1X authentication succeeds, the device manipulates VLAN or VSI assignment based on
the 802.1X authentication result.
For the port to perform MAC authentication before it is assigned to the 802.1X guest VLAN or VSI,
you must also enable new MAC-triggered 802.1X guest VLAN or VSI assignment delay. For
information about new MAC-triggered 802.1X guest VLAN or VSI assignment delay, see
"Configuring 802.1X."

187
Restrictions and guidelines
To configure both 802.1X authentication and MAC authentication on a port, use one of the following
methods:
• Enable the 802.1X and MAC authentication features separately on the port.
• Enable port security on the port. The port security mode must be userlogin-secure-or-mac or
userlogin-secure-or-mac-ext.
For information about port security mode configuration, see "Configuring port security."
For the parallel authentication feature to work correctly, do not enable MAC authentication delay on
the port. This feature will delay MAC authentication after 802.1X authentication is triggered.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable parallel MAC authentication and 802.1X authentication on the port.
mac-authentication parallel-with-dot1x
By default, this feature is disabled.

Configuring RESTful server-assisted MAC

authentication user recovery
About this task
RESTful server-assisted MAC authentication user recovery supports the following methods:
• Automatic recovery—The device automatically obtains MAC authentication user information
and performs a reauthentication after the device or an interface module reboots or after an
interface recovers from a failure. This feature recovers the online state of MAC authenticated
users quickly without waiting for packets from the MAC authentication users to trigger a
reauthentication. It is helpful when the network has a large number of dumb terminals or the
operation of dumb terminals is important for services.
• Manual recovery—You trigger a recovery manually. Then, the device obtains MAC
authentication user information from the RESTful server and performs reauthentication. Use
this method to recover the online state of MAC authenticated users if automatic recovery fails to
recover the online state of all MAC authenticated users because of link flapping.
With this feature, you can configure a maximum of 16 profiles for MAC authentication user recovery.
Each profile contains a set of parameters for accessing a RESTful server and the URI from which
you obtain MAC authentication user information.
Restrictions and guidelines
To use this feature, you must use an IMC server to act as both authentication and RESTful servers.
This feature is mutually exclusive with the RADIUS accounting-on feature. Do not use the two
features together. For more information about the RADIUS accounting-on feature, see "Configuring
AAA."
To ensure that the MAC authentication user entries obtained from the RESTful server contain user IP
addresses, configure the device to include user IP addresses in the MAC authentication requests
sent to the authentication server. For more information about this feature, see "Including user IP
addresses in MAC authentication requests."

188
Procedure
1. Enter system view.
system-view
2. Configure a MAC authentication user-recovery profile:
a. Create a profile for MAC authentication user recovery and enter its view.
mac-authentication user-recovery-profile profile-name
b. Configure the IP address and port number of the RESTful server.
server-address { ip ipv4-address | ipv6 ipv6-address } [ port
port-number ] [ vpn-instance vpn-instance-name ]
By default, no RESTful servers are configured.
c. Configure the username and password for accessing the RESTful server.
login-name username [ password { cipher | simple } string ]
By default, no username or password is configured for accessing the RESTful server.
d. Configure the NAS IP address used by the device to communicate with the RESTful server.
nas-ip { ipv4-address | ipv6 ipv6-address }
By default, no NAS IP address is configured for the device to communicate with the RESTful
server.
The NAS IP address must be the same as that configured in the authentication RADIUS
scheme for the MAC authentication users.
e. Specify the URI for obtaining MAC authentication user information from the RESTful server.
uri uri-string
By default, no URIs are specified.
The URI can only be imcrs/uam/online/notAgingMuteTerminal. Other URIs cannot take
effect.
3. Return to system view.
quit
4. Enable automatic MAC authentication user recovery.
mac-authentication auto-recover-user profile profile-name
By default, automatic MAC authentication user recovery is disabled.
5. Return to user view.
quit
6. (Optional.) Manually recover MAC authentication users.
mac-authentication recover-user profile profile-name [ interface
interface-type interface-number

Configuring Web proxy ports for URL redirection

in MAC authentication
About this task
By default, the device redirects the HTTP or HTTPS requests from a MAC authenticated user to the
authorized URL only if the requests are sent from a browser with Web proxy disabled. The device
discards these requests if they are sent from a browser configured with a Web proxy.
To prevent the HTTP or HTTPS requests from being discarded, add the TCP port numbers of the
Web proxy for HTTP and HTTPS to the device. These TCP port numbers are called Web proxy ports
in this document.

189
Restrictions and guidelines
You can configure a maximum of 64 Web proxy ports for MAC authenticated users.
Specify different Web proxy port numbers for HTTP and HTTPS requests.
Adding or removing a Web proxy port will cause the device to log off all online MAC authenticated
users that have been assigned an authorization redirect URL.
Procedure
1. Enter system view.
system-view
2. Specify a Web proxy port used by MAC authentication users for HTTP or HTTPS.
mac-authentication web-proxy { http | https } port port-number
By default, no Web proxy ports are specified.

Logging off MAC authentication users

About this task
Perform this task to log off specified MAC authentication users and clear information about these
users from the device. These users must perform MAC authentication to come online again.
Procedure
To log off MAC authentication users, execute the following command in user view:
reset mac-authentication access-user [ interface interface-type
interface-number | mac mac-address | username username | vlan vlan-id |
vsi vsi-name ]

Enabling MAC authentication user logging

About this task
This feature enables the device to generate logs about MAC authentication users and send the logs
to the information center. For the logs to be output correctly, you must also configure the information
center on the device. For more information about information center configuration, see Network
Management and Monitoring Configuration Guide.
Restrictions and guidelines
To prevent excessive MAC authentication user log entries, use this feature only if you need to
analyze abnormal MAC authentication user logins or logouts.
Procedure
1. Enter system view.
system-view
2. Enable MAC authentication user logging.
mac-authentication access-user log enable [ failed-login | logoff |
successful-login ] *
By default, MAC authentication user logging is disabled.
If you do not specify any parameters, this command enables all types of MAC authentication
user logs.

190
Display and maintenance commands for MAC
authentication
Execute display commands in any view and reset commands in user view.

Task Command
display mac-authentication [ interface
Display MAC authentication information.
interface-type interface-number ]
display mac-authentication connection
[ open ] [ interface interface-type
Display MAC authentication connections. interface-number | slot slot-number |
user-mac mac-address | user-name
user-name ]
display mac-authentication
Display the MAC addresses of MAC mac-address { critical-vlan |
authentication users in a type of MAC critical-vsi | guest-vlan | guest-vsi }
authentication VLAN or VSI. [ interface interface-type
interface-number ]
reset mac-authentication statistics
Clear MAC authentication statistics. [ interface interface-type
interface-number ]
reset mac-authentication critical
Remove users from the MAC authentication vlan interface interface-type
critical VLAN on a port. interface-number [ mac-address
mac-address ]
reset mac-authentication
Remove users from the MAC authentication critical-voice-vlan interface
critical voice VLAN on a port. interface-type interface-number
[ mac-address mac-address ]
reset mac-authentication guest-vlan
Remove users from the MAC authentication interface interface-type
guest VLAN on a port. interface-number [ mac-address
mac-address ]
reset mac-authentication critical vsi
Remove users from the MAC authentication interface interface-type
critical VSI on a port. interface-number [ mac-address
mac-address ]
reset mac-authentication guest-vsi
Remove users from the MAC authentication interface interface-type
guest VSI on a port. interface-number [ mac-address
mac-address ]

191
MAC authentication configuration examples
Example: Configuring local MAC authentication
Network configuration
As shown in Figure 50, the device performs local MAC authentication on GigabitEthernet 1/0/1 to
control Internet access of users.
Configure the device to meet the following requirements:
• Detect whether a user has gone offline every 180 seconds.
• Deny a user for 180 seconds if the user fails MAC authentication.
• Authenticate all users in ISP domain bbb.
• Use the MAC address of each user as both the username and password for authentication. The
MAC addresses are in hexadecimal notation with hyphens, and letters are in lower case.
Figure 50 Network diagram

Host A
GE1/0/1
MAC: 08-00-27-12-34-56 IP network

Device
Host B

MAC: 08-00-27-11-11-11

Procedure
# Add a network access local user. In this example, configure both the username and password as
Host A's MAC address 08-00-27-12-34-56.
<Device> system-view
[Device] local-user 08-00-27-12-34-56 class network
[Device-luser-network-08-00-27-12-34-56] password simple 08-00-27-12-34-56

# Specify the LAN access service for the user.

[Device-luser-network-08-00-27-12-34-56] service-type lan-access
[Device-luser-network-08-00-27-12-34-56] quit

# Configure ISP domain bbb to perform local authentication for LAN users.
[Device] domain bbb
[Device-isp-bbb] authentication lan-access local
[Device-isp-bbb] quit

# Enable MAC authentication on GigabitEthernet 1/0/1.

[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] mac-authentication
[Device-GigabitEthernet1/0/1] quit

# Specify ISP domain bbb as the MAC authentication domain.

[Device] mac-authentication domain bbb

# Configure MAC authentication timers.

[Device] mac-authentication timer offline-detect 180
[Device] mac-authentication timer quiet 180

192
 # Use the MAC address of each user as both the username and password for MAC authentication.
The MAC addresses are in hexadecimal notation with hyphens, and letters are in lower case.
[Device] mac-authentication user-name-format mac-address with-hyphen lowercase

# Enable MAC authentication globally.

[Device] mac-authentication

Verifying the configuration

# Display MAC authentication settings and statistics to verify your configuration.
[Device] display mac-authentication
Global MAC authentication parameters:
MAC authentication : Enabled
Authentication method : PAP
User name format : MAC address in lowercase(xx-xx-xx-xx-xx-xx)
Username : mac
Password : Not configured
Offline detect period : 180 s
Quiet period : 180 s
Server timeout : 100 s
Reauth period : 3600 s
User aging period for critical VLAN : 1000 s
User aging period for critical VSI : 1000 s
User aging period for guest VLAN : 1000 s
User aging period for guest VSI : 1000 s
Authentication domain : bbb
HTTP proxy port list : Not configured
HTTPS proxy port list : Not configured
Online MAC-auth wired users : 1

Silent MAC users:

MAC address VLAN ID From port Port index
0800-2711-1111 8 GE1/0/1 1

GigabitEthernet1/0/1 is link-up
MAC authentication : Enabled
Carry User-IP : Disabled
Authentication domain : Not configured
Auth-delay timer : Disabled
Periodic reauth : Disabled
Re-auth server-unreachable : Logoff
Guest VLAN : Not configured
Guest VLAN reauthentication : Enabled
Guest VLAN auth-period : 30 s
Critical VLAN : Not configured
Critical voice VLAN : Disabled
Host mode : Single VLAN
Offline detection : Enabled
Authentication order : Default
User aging : Enabled
Server-recovery online-user-sync : Enabled

193
 Guest VSI : Not configured
Guest VSI reauthentication : Enabled
Guest VSI auth-period : 30 s
Critical VSI : Not configured
Auto-tag feature : Disabled
VLAN tag configuration ignoring : Disabled
Max online users : 4294967295
Authentication attempts : successful 1, failed 0
Current online users : 1
MAC address Auth state
0800-2712-3456 Authenticated

The output shows that Host A has passed MAC authentication and has come online. Host B failed
MAC authentication and its MAC address is marked as a silent MAC address.

Example: Configuring RADIUS-based MAC authentication

Network configuration
As shown in Figure 51, the device uses RADIUS servers to perform authentication, authorization,
and accounting for users. The RADIUS servers use the CHAP authentication method.
To control user access to the Internet by MAC authentication, perform the following tasks:
• Enable MAC authentication globally and on GigabitEthernet 1/0/1.
• Configure the device to use CHAP for MAC authentication.
• Configure the device to detect whether a user has gone offline every 180 seconds.
• Configure the device to deny a user for 180 seconds if the user fails MAC authentication.
• Configure all users to belong to ISP domain bbb.
• Use a shared user account for all users, with username aaa and password 123456.
Figure 51 Network diagram

RADIUS servers
Auth:10.1.1.1
Acct:10.1.1.2

GE1/0/1
IP network

Host Device

Procedure
Make sure the RADIUS servers and the access device can reach each other.
1. Configure the RADIUS servers to provide authentication, authorization, and accounting
services. Create a shared account with username aaa and password 123456 for MAC
authentication users. (Details not shown.)
2. Configure RADIUS-based MAC authentication on the device:
# Configure a RADIUS scheme.
<Device> system-view

194
 [Device] radius scheme 2000
[Device-radius-2000] primary authentication 10.1.1.1 1812
[Device-radius-2000] primary accounting 10.1.1.2 1813
[Device-radius-2000] key authentication simple abc
[Device-radius-2000] key accounting simple abc
[Device-radius-2000] user-name-format without-domain
[Device-radius-2000] quit
# Specify CHAP as the authentication method for MAC authentication.
[Device] mac-authentication authentication-method chap
# Apply the RADIUS scheme to ISP domain bbb for authentication, authorization, and
accounting.
[Device] domain bbb
[Device-isp-bbb] authentication default radius-scheme 2000
[Device-isp-bbb] authorization default radius-scheme 2000
[Device-isp-bbb] accounting default radius-scheme 2000
[Device-isp-bbb] quit
# Enable MAC authentication on GigabitEthernet 1/0/1.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] mac-authentication
[Device-GigabitEthernet1/0/1] quit
# Specify the MAC authentication domain as ISP domain bbb.
[Device] mac-authentication domain bbb
# Set MAC authentication timers.
[Device] mac-authentication timer offline-detect 180
[Device] mac-authentication timer quiet 180
# Specify username aaa and password 123456 in plain text for the account shared by MAC
authentication users.
[Device] mac-authentication user-name-format fixed account aaa password simple 123456
# Enable MAC authentication globally.
[Device] mac-authentication

Verifying the configuration

# Verify the MAC authentication configuration.
[Device] display mac-authentication
Global MAC authentication parameters:
MAC authentication : Enabled
Authentication method : CHAP
Username format : Fixed account
Username : aaa
Password : ******
Offline detect period : 180 s
Quiet period : 180 s
Server timeout : 100 s
Reauth period : 3600 s
User aging period for critical VLAN : 1000 s
User aging period for critical VSI : 1000 s
User aging period for guest VLAN : 1000 s
User aging period for guest VSI : 1000 s

195
 Authentication domain : bbb
HTTP proxy port list : Not configured
HTTPS proxy port list : Not configured
Online MAC-auth wired users : 1

Silent MAC users:

MAC address VLAN ID From port Port index

GigabitEthernet1/0/1 is link-up
MAC authentication : Enabled
Carry User-IP : Disabled
Authentication domain : Not configured
Auth-delay timer : Disabled
Periodic reauth : Disabled
Re-auth server-unreachable : Logoff
Guest VLAN : Not configured
Guest VLAN reauthentication : Enabled
Guest VLAN auth-period : 30 s
Critical VLAN : Not configured
Critical voice VLAN : Disabled
Host mode : Single VLAN
Offline detection : Enabled
Authentication order : Default
User aging : Enabled
Server-recovery online-user-sync : Enabled

Guest VSI : Not configured

Guest VSI reauthentication : Enabled
Guest VSI auth-period : 30 s
Critical VSI : Not configured
Auto-tag feature : Disabled
VLAN tag configuration ignoring : Disabled
Max online users : 4294967295
Authentication attempts : successful 1, failed 0
Current online users : 1
MAC address Auth state
0800-2712-3456 Authenticated

Example: Configuring ACL assignment for MAC

authentication
Network configuration
As shown in Figure 52, configure the device to meet the following requirements:
• Use RADIUS servers to perform authentication, authorization, and accounting for users.
• Perform MAC authentication on GigabitEthernet 1/0/1 to control Internet access.
• Use the MAC address of each user as both the username and password for MAC
authentication. The MAC addresses are in hexadecimal notation with hyphens, and letters are
in lower case.

196
 • Use an ACL to deny authenticated users to access the FTP server at 10.0.0.1.
Figure 52 Network diagram

RADIUS servers
Auth:10.1.1.1
Acct:10.1.1.2

GE1/0/1
Internet

Host Device FTP server

IP: 192.168.1.10/24 10.0.0.1/24
MAC: 08-00-27-12-34-56

Procedure
Make sure the RADIUS servers and the access device can reach each other.
1. Configure the RADIUS servers:
# Configure the RADIUS servers to provide authentication, authorization, and accounting
services. (Details not shown.)
# Add a user account with 08-00-27-12-34-56 as both the username and password on each
RADIUS server. (Details not shown.)
# Specify ACL 3000 as the authorization ACL for the user account. (Details not shown.)
2. Configure ACL 3000 to deny packets destined for 10.0.0.1 on the device.
<Device> system-view
[Device] acl advanced 3000
[Device-acl-ipv4-adv-3000] rule 0 deny ip destination 10.0.0.1 0
[Device-acl-ipv4-adv-3000] quit
3. Configure RADIUS-based MAC authentication on the device:
# Configure a RADIUS scheme.
[Device] radius scheme 2000
[Device-radius-2000] primary authentication 10.1.1.1 1812
[Device-radius-2000] primary accounting 10.1.1.2 1813
[Device-radius-2000] key authentication simple abc
[Device-radius-2000] key accounting simple abc
[Device-radius-2000] user-name-format without-domain
[Device-radius-2000] quit
# Apply the RADIUS scheme to an ISP domain for authentication, authorization, and
accounting.
[Device] domain bbb
[Device-isp-bbb] authentication default radius-scheme 2000
[Device-isp-bbb] authorization default radius-scheme 2000
[Device-isp-bbb] accounting default radius-scheme 2000
[Device-isp-bbb] quit
# Specify the ISP domain for MAC authentication.
[Device] mac-authentication domain bbb
# Use the MAC address of each user as both the username and password for MAC
authentication. The MAC addresses are in hexadecimal notation with hyphens, and letters are
in lower case.

197
 [Device] mac-authentication user-name-format mac-address with-hyphen lowercase
# Enable MAC authentication on GigabitEthernet 1/0/1.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] mac-authentication
[Device-GigabitEthernet1/0/1] quit
# Enable MAC authentication globally.
[Device] mac-authentication

Verifying the configuration

# Verify the MAC authentication configuration.
[Device] display mac-authentication
Global MAC authentication parameters:
MAC authentication : Enable
Authentication method : PAP
Username format : MAC address in lowercase(xx-xx-xx-xx-xx-xx)
Username : mac
Password : Not configured
Offline detect period : 300 s
Quiet period : 60 s
Server timeout : 100 s
Reauth period : 3600 s
User aging period for critical VLAN : 1000 s
User aging period for critical VSI : 1000 s
User aging period for guest VLAN : 1000 s
User aging period for guest VSI : 1000 s
Authentication domain : bbb
HTTP proxy port list : Not configured
HTTPS proxy port list : Not configured
Online MAC-auth wired users : 1

Silent MAC users:

MAC address VLAN ID From port Port index

GigabitEthernet1/0/1 is link-up
MAC authentication : Enabled
Carry User-IP : Disabled
Authentication domain : Not configured
Auth-delay timer : Disabled
Periodic reauth : Disabled
Re-auth server-unreachable : Logoff
Guest VLAN : Not configured
Guest VLAN reauthentication : Enabled
Guest VLAN auth-period : 30 s
Critical VLAN : Not configured
Critical voice VLAN : Disabled
Host mode : Single VLAN
Offline detection : Enabled
Authentication order : Default
User aging : Enabled

198
 Server-recovery online-user-sync : Enabled

Guest VSI : Not configured

Guest VSI reauthentication : Enabled
Guest VSI auth-period : 30 s
Critical VSI : Not configured
Auto-tag feature : Disabled
VLAN tag configuration ignoring : Disabled
Max online users : 4294967295
Authentication attempts : successful 1, failed 0
Current online users : 1
MAC address Auth state
0800-2712-3456 Authenticated

# Verify that you cannot ping the FTP server from the host.
C:\>ping 10.0.0.1

Pinging 10.0.0.1 with 32 bytes of data:

Request timed out.

Request timed out.
Request timed out.
Request timed out.

Ping statistics for 10.0.0.1:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

The output shows that ACL 3000 has been assigned to GigabitEthernet 1/0/1 to deny access to the
FTP server.

Example: Configuring MAC authentication authorization VSI

assignment
Network configuration
As shown in Figure 53, configure the device to meet the following requirements:
• Use RADIUS servers to perform authentication, authorization, and accounting for users.
• Perform MAC authentication on GigabitEthernet 1/0/1 to control Internet access.
• Configure the RADIUS server to assign VSI bbb to the host when the host passes MAC
authentication.
• Authenticate all users in ISP domain 2000.
• Use the MAC address of each user as both the username and password for MAC
authentication. The MAC addresses are in hexadecimal notation with hyphens, and letters are
in lower case.

199
 Figure 53 Network diagram

GE1/0/1
Internet

Device
Host VXLAN
(VTEP)

Procedure
Make sure the RADIUS servers and the access device can reach each other.
1. Configure the RADIUS servers:
# Configure the RADIUS servers to provide authentication, authorization, and accounting
services. (Details not shown.)
# Add a user account with d4-85-64-be-c6-3e as both the username and password on each
RADIUS server. (Details not shown.)
# Specify VSI bbb as the authorization VSI for the user account. (Details not shown.)

NOTE:
If an ADCAM server is used for authentication and authorization, configure VSIs on the server.
The server will assign these VSIs to the device. You do not need to configure VSIs on the
device.

2. Configure RADIUS-based MAC authentication on the device:

# Configure a RADIUS scheme.
<Device> system-view
[Device] radius scheme bbb
[Device-radius-bbb] primary authentication 10.1.1.1
[Device-radius-bbb] primary accounting 10.1.1.2
[Device-radius-bbb] key authentication simple bbb
[Device-radius-bbb] key accounting simple bbb
[Device-radius-bbb] user-name-format without-domain
[Device-radius-bbb] quit
# Apply the RADIUS scheme to ISP domain 2000 for authentication, authorization, and
accounting.
[Device] domain 2000
[Device-isp-2000] authentication lan-access radius-scheme bbb
[Device-isp-2000] authorization lan-access radius-scheme bbb
[Device-isp-2000] accounting lan-access radius-scheme bbb
[Device-isp-2000] quit
# Enable MAC authentication on GigabitEthernet 1/0/1.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] mac-authentication
# Enable the MAC match mode for dynamic Ethernet service instances on GigabitEthernet
1/0/1.

200
 [Device-GigabitEthernet1/0/1] mac-based ac
[Device-GigabitEthernet1/0/1] quit
# Enable L2VPN.
[Device] l2vpn enable
# Create a VSI named bbb and the associated VXLAN.
[Device] vsi bbb
[Device-vsi-bbb] vxlan 5
[Device-vsi-bbb-vxlan-5] quit
# Specify the ISP domain for MAC authentication.
[Device] mac-authentication domain 2000
# Use the MAC address of each user as both the username and password for MAC
authentication. The MAC addresses are in hexadecimal notation with hyphens, and letters are
in lower case.
[Device] mac-authentication user-name-format mac-address with-hyphen lowercase
# Enable MAC authentication globally.
[Device] mac-authentication

Verifying the configuration

# Verify that VSI bbb is assigned to the MAC authentication user after the user passes
authentication.
[Device] display mac-authentication connection
Total connections: 1
Slot ID: 1
User MAC address: d485-64be-c63e
Access interface: GigabitEthernet1/0/1
Username: d4-85-64-be-c6-3e
User access state: Successful
Authentication domain: 2000
IPv4 address: 192.168.1.1
IPv6 address: 2000:0:0:0:1:2345:6789:abcd
Initial VLAN: 1
Authorization untagged VLAN: N/A
Authorization tagged VLAN: N/A
Authorization VSI: bbb
Authorization ACL ID: N/A
Authorization user profile: N/A
Authorization CAR: N/A
Authorization URL: N/A
Termination action: N/A
Session timeout period: N/A
Offline detection: 300 sec (server-assigned)
Online from: 2016/06/13 09:06:37
Online duration: 0h 0m 35s

# Verify that a dynamic AC is created for MAC address d485-64be-c63e.

[Device] display l2vpn forwarding ac verbose
VSI Name: bbb
Interface: GE1/0/1 Service Instance: 1
Link ID : 0
Access Mode : VLAN

201
Encapsulation: untagged
Type : Dynamic (MAC-based)
MAC address : d485-64be-c63e

202
Configuring portal authentication
About portal authentication
Portal authentication controls user access to networks. Portal authenticates a user by the username
and password the user enters on a portal authentication page. Typically, portal authentication is
deployed on the access layer and vital data entries.
In a portal-enabled network, users can actively initiate portal authentication by visiting the
authentication website provided by the portal Web server. Or, they are redirected to the portal
authentication page for authentication when they visit other websites.
The device supports Portal 1.0, Portal 2.0, and Portal 3.0.

Advantages of portal authentication

Portal authentication has the following advantages:
• Allows users to perform authentication through a Web browser without installing client software.
• Provides ISPs with diversified management choices and extended functions. For example, the
ISPs can place advertisements, provide community services, and publish information on the
authentication page.
• Supports multiple authentication modes. For example, re-DHCP authentication implements a
flexible address assignment scheme and saves public IP addresses. Cross-subnet
authentication can authenticate users who reside in a different subnet than the access device.

Extended portal functions

By forcing patching and anti-virus policies, extended portal functions help hosts to defend against
viruses. Portal supports the following extended functions:
• Security check—Detects after authentication whether or not a user host installs anti-virus
software, virus definition file, unauthorized software, and operating system patches.
• Resource access restriction—Allows an authenticated user to access certain network
resources such as the virus server and the patch server. Users can access more network
resources after passing security check.
Security check must cooperate with the IMC security policy server and the iNode client.

Portal system
A typical portal system consists of these basic components: authentication client, access device,
portal authentication server, portal Web server, AAA server, and security policy server.

203
 Figure 54 Portal system

Portal authentication
server
Authentication client

Portal Web server

Authentication client Access device

AAA server

Authentication client

Security policy
server

Authentication client
An authentication client is a Web browser that runs HTTP/HTTPS or a user host that runs a portal
client. Security check for the user host is implemented through the interaction between the portal
client and the security policy server. Only the iNode client is supported.
Access device
An access device provides access services. It has the following functions:
• Redirects all HTTP or HTTPS requests of unauthenticated users to the portal Web server.
• Interacts with the portal authentication server and the AAA server to complete authentication,
authorization, and accounting.
• Allows users that pass portal authentication to access authorized network resources.
Portal server
A portal server collectively refers to a portal authentication server and portal Web server.
The portal Web server pushes the Web authentication page to authentication clients and forwards
user authentication information (username and password) to the portal authentication server. The
portal authentication server receives authentication requests from authentication clients and
interacts with the access device to authenticate users. The portal Web server is typically integrated
with the portal authentication server and it can also be an independent server.
AAA server
The AAA server interacts with the access device to implement authentication, authorization,
accounting for portal users. In a portal system, a RADIUS server can perform authentication,
authorization, accounting for portal users, and an LDAP server can perform authentication for portal
users.
Security policy server
The security policy server interacts with the portal client and the access device for security check and
authorization for users. Only hosts that run portal clients can interact with the security policy server.

Portal authentication using a remote portal server

The components of a portal system interact as follows:
1. An unauthenticated user initiates authentication by accessing an Internet website through a
Web browser. When receiving the HTTP or HTTPS request, the access device redirects it to the

204
 Web authentication page provided by the portal Web server. The user can also visit the
authentication website to log in. The user must log in through the iNode client for extended
portal functions.
2. The user enters the authentication information on the authentication page/dialog box and
submits the information. The portal Web server forwards the information to the portal
authentication server. The portal authentication server processes the information and forwards
it to the access device.
3. The access device interacts with the AAA server to implement authentication, authorization,
accounting for the user.
4. If security policies are not imposed on the user, the access device allows the authenticated user
to access networks.
If security policies are imposed on the user, the portal client, the access device, and the security
policy server interact to check the user host. If the user passes the security check, the security
policy server authorizes the user to access resources based on the check result.

Local portal service

System components
As shown in Figure 55, a local portal system consists of an authentication client, access device, and
AAA server. The access device acts as both the portal Web server and the portal authentication
server to provide the local portal Web service for the authentication client. The authentication client
can only be a Web browser, and it cannot be a user host that runs a portal client. Therefore,
extended portal functions are not supported and no security policy server is required.
Figure 55 System components

Authentication client Access device with embedded Authentication/accounting

portal server server

Portal page customization

The portal system pushes different authentication pages to portal users at different stages. The local
portal service supports portal page customization. You can customize one or more sets of
authentication pages, compress each set of authentication pages to a .zip file, and upload the
compressed files to the storage medium of the device.
For more information about authentication page customization, see "Customizing authentication
pages."

Portal authentication modes

Portal authentication has three modes: direct authentication, re-DHCP authentication, and
cross-subnet authentication. In direct authentication and re-DHCP authentication, no Layer 3
forwarding devices exist between the authentication client and the access device. In cross-subnet
authentication, Layer 3 forwarding devices can exist between the authentication client and the
access device.
Direct authentication
A user manually configures a public IP address or obtains a public IP address through DHCP. Before
authentication, the user can access only the portal Web server and predefined authentication-free
websites. After passing authentication, the user can access other network resources. The process of
direct authentication is simpler than that of re-DHCP authentication.

205
Re-DHCP authentication
Before a user passes authentication, DHCP allocates an IP address (a private IP address) to the
user. The user can access only the portal Web server and predefined authentication-free websites.
After the user passes authentication, DHCP reallocates an IP address (a public IP address) to the
user. The user then can access other network resources. No public IP address is allocated to users
who fail authentication. Re-DHCP authentication saves public IP addresses. For example, an ISP
can allocate public IP addresses to broadband users only when they access networks beyond the
residential community network.
Only the iNode client supports re-DHCP authentication. IPv6 portal authentication does not support
the re-DHCP authentication mode.
Cross-subnet authentication
Cross-subnet authentication is similar to direct authentication, except it allows Layer 3 forwarding
devices to exist between the authentication client and the access device.
In direct authentication, re-DHCP authentication, and cross-subnet authentication, a user's IP
address uniquely identifies the user. After a user passes authentication, the access device generates
an ACL for the user based on the user's IP address to control forwarding of the packets from the user.
Because no Layer 3 forwarding device exists between authentication clients and the access device
in direct authentication and re-DHCP authentication, the access device can learn the user MAC
addresses. The access device can enhance its capability of controlling packet forwarding by using
the learned MAC addresses.

Portal authentication process

Direct authentication and cross-subnet authentication share the same authentication process.
Re-DHCP authentication has a different process as it has two address allocation procedures.
Direct authentication/cross-subnet authentication process (with CHAP/PAP authentication)
Figure 56 Direct authentication/cross-subnet authentication process
Portal
Authentication Portal Web Access Security
authentication AAA server
client server device policy server
server
1) Initiate a connection
2) User information
3) CHAP authentication

4) Authentication request
5) RADIUS
authentication
Timer

6) Authentication reply

7) Notify login success 8) Authentication reply

acknowledgment

9) Security check

10) Authorization

The direct/cross-subnet authentication process is as follows:

1. A portal user access the Internet through HTTP or HTTPS, and the HTTP or HTTPS packet
arrives at the access device.
 If the packet matches a portal free rule, the access device allows the packet to pass.
 If the packet does not match any portal-free rule, the access device redirects the packet to
the portal Web server. The portal Web server pushes the Web authentication page to the
user for him to enter his username and password.

206
 2. The portal Web server submits the user authentication information to the portal authentication
server.
3. The portal authentication server and the access device exchange CHAP messages. This step
is skipped for PAP authentication. The portal authentication server decides the method (CHAP
or PAP) to use.
4. The portal authentication server adds the username and password into an authentication
request packet and sends it to the access device. Meanwhile, the portal authentication server
starts a timer to wait for an authentication reply packet.
5. The access device and the RADIUS server exchange RADIUS packets.
6. The access device sends an authentication reply packet to the portal authentication server to
notify authentication success or failure.
7. The portal authentication server sends an authentication success or failure packet to the client.
8. If the authentication is successful, the portal authentication server sends an authentication
reply acknowledgment packet to the access device.
If the client is an iNode client, the authentication process includes step 9 and step 10 for extended
portal functions. Otherwise the authentication process is complete.
9. The client and the security policy server exchange security check information. The security
policy server detects whether or not the user host installs anti-virus software, virus definition
files, unauthorized software, and operating system patches.
10. The security policy server authorizes the user to access certain network resources based on
the check result. The access device saves the authorization information and uses it to control
access of the user.
Re-DHCP authentication process (with CHAP/PAP authentication)
Figure 57 Re-DHCP authentication process
Portal Security
Authentication Portal Web Access
authentication AAA server
policy server
client server device
server
1) Initiate a connection
2) User information
3) CHAP authentication

4) Authentication request
5) RADIUS
authentication
Timer
6) Authentication reply

7) Authentication success

8) The user obtains a new IP address

9) Discover user IP change

10) Detect user IP change

11) Notify login success

12) IP change
acknowledgment

13) Security check

14) Authorization

The re-DHCP authentication process is as follows:

Step 1 through step 7 are the same as those in the direct authentication/cross-subnet authentication
process.

207
 8. After receiving the authentication success packet, the client obtains a public IP address through
DHCP. The client then notifies the portal authentication server that it has a public IP address.
9. The portal authentication server notifies the access device that the client has obtained a public
IP address.
10. The access device detects the IP change of the client through DHCP and then notifies the
portal authentication server that it has detected an IP change of the client IP.
11. After receiving the IP change notification packets sent by the client and the access device, the
portal authentication server notifies the client of login success.
12. The portal authentication server sends an IP change acknowledgment packet to the access
device.
Step 13 and step 14 are for extended portal functions.
13. The client and the security policy server exchanges security check information. The security
policy server detects whether or not the user host installs anti-virus software, virus definition
files, unauthorized software, and operating system patches.
14. The security policy server authorizes the user to access certain network resources based on
the check result. The access device saves the authorization information and uses it to control
access of the user.

Portal support for EAP

To use portal authentication that supports EAP, the portal authentication server and client must be
the IMC portal server and the iNode portal client. Local portal authentication does not support EAP
authentication.
Compared with username and password based authentication, digital certificate-based
authentication ensures higher security.
The Extensible Authentication Protocol (EAP) supports several digital certificate-based
authentication methods, for example, EAP-TLS. Working together with EAP, portal authentication
can implement digital certificate-based user authentication.
Figure 58 Portal support for EAP working flow diagram

Authentication EAP Portal Access RADIUS RADIUS server

Portal server
client (EAP-Message) device (EAP-Message) (EAP server)

As shown in Figure 58, the authentication client and the portal authentication server exchange EAP
authentication packets. The portal authentication server and the access device exchange portal
authentication packets that carry the EAP-Message attributes. The access device and the RADIUS
server exchange RADIUS packets that carry the EAP-Message attributes. The RADIUS server that
supports the EAP server function processes the EAP packets encapsulated in the EAP-Message
attributes, and provides the EAP authentication result.
The access device does not process but only transports EAP-Message attributes between the portal
authentication server and the RADIUS server. Therefore, the access device requires no additional
configuration to support EAP authentication.

Portal filtering rules

The access device uses portal filtering rules to control user traffic forwarding.
Based on the configuration and authentication status of portal users, the device generates the
following categories of portal filtering rules:
• Category 1—The rule permits user packets that are destined for the portal Web server and
packets that match the portal-free rules to pass through.

208
 • Category 2—For an authenticated user with no ACL authorized, the rule allows the user to
access any destination network resources. For an authenticated user with an ACL authorized,
the rule allows users to access resources permitted by the ACL. The device adds the rule when
a user comes online and deletes the rule when the user goes offline.
The device supports the following types of authorization ACLs:
 Basic ACLs (ACL 2000 to ACL 2999).
 Advanced ACLs (ACL 3000 to ACL 3999).
 Layer 2 ACLs (ACL 4000 to ACL 4999).
For an authorization ACL to take effect, make sure the ACL exists and has ACL rules excluding
rules configured with the counting, established, fragment, source-mac,
source-ip, or logging keyword. For more information about ACL rules, see ACL
commands in ACL and QoS Command Reference.
• Category 3—The rule redirects all HTTP or HTTPS requests from unauthenticated users to the
portal Web server.
• Category 4—For direct authentication and cross-subnet authentication, the rule forbids any
user packets to pass through. For re-DHCP authentication, the device forbids user packets with
private source addresses to pass.
After receiving a user packet, the device compares the packet against the filtering rules from
category 1 to category 4. Once the packet matches a rule, the matching process completes.

Restrictions and guidelines: Portal configuration

Portal authentication through Web does not support security check for users. To implement security
check, the client must be the iNode client.
Portal authentication supports NAT traversal whether it is initiated by a Web client or an iNode client.
NAT traversal must be configured when the portal client is on a private network and the portal server
is on a public network.

Portal authentication tasks at a glance

To configure portal authentication, perform the following tasks:
1. Configuring a remote portal service
Perform this task if the access device does not act as a portal authentication server or portal
Web server.
 Configuring a remote portal authentication server
 Configuring a portal Web server
2. Configuring a local portal service
Perform this task if the access device acts as a portal authentication server and portal Web
server.
 Configuring local portal service features
 Configuring a portal Web server
3. Enabling portal authentication and specifying a portal Web server
 Enabling portal authentication on an interface
 Specifying a portal Web server on an interface
 Enabling portal to support IPv4/IPv6 dual stack
Perform this task if dual-stack portal users exist on the network.
4. (Optional.) Specifying a preauthentication IP address pool

209
 5. (Optional.) Specifying a portal authentication domain
6. (Optional.) Controlling portal user access
 Configuring a portal-free rule
 Configuring an authentication source subnet
 Configuring an authentication destination subnet
 Configuring support of Web proxy for portal authentication
 Checking the issuing of category-2 portal filtering rules
 Setting the maximum number of portal users
 Enabling strict-checking on portal authorization information
 Allowing only users with DHCP-assigned IP addresses to pass portal authentication
 Enabling portal roaming
 Configuring the portal fail-permit feature
7. (Optional.) Configuring portal detection features
 Configuring online detection of portal users
 Configuring portal authentication server detection
 Configuring portal Web server detection
 Configuring portal user synchronization
8. (Optional.) Configuring attributes for portal packets and RADIUS packets
 Configuring portal packet attributes
You can configure the BAS-IP or BAS-IPv6 attribute for portal packets and specify the
device ID.
 Configuring attributes for RADIUS packets
You can configure the NAS-Port-Id and NAS-Port-Type attributes and apply a NAS-ID
profile to an interface.
9. (Optional.) Configuring online and offline related features for portal users
 Logging out online portal users
 Enabling portal user login/logout logging
10. (Optional.) Configuring extended portal authentication features
 Disabling the Rule ARP or ND entry feature for portal clients
 Configuring Web redirect

Prerequisites for portal authentication

The portal feature provides a solution for user identity authentication and security check. To
complete user identity authentication, portal must cooperate with RADIUS.
Before you configure portal, you must complete the following tasks:
• The portal authentication server, portal Web server, and RADIUS server have been installed
and configured correctly.
• To use the re-DHCP portal authentication mode, make sure the DHCP relay agent is enabled
on the access device, and the DHCP server is installed and configured correctly.
• The portal client, access device, and servers can reach each other.
• To use the remote RADIUS server, configure usernames and passwords on the RADIUS server,
and configure the RADIUS client on the access device. For information about RADIUS client
configuration, see "Configuring AAA."
• To implement extended portal functions, install and configure CAMS EAD or IMC EAD. Make
sure the ACLs configured on the access device correspond to the isolation ACL and the

210
 security ACL on the security policy server. For installation and configuration about the security
policy server, see CAMS EAD Security Policy Component User Manual or IMC EAD Security
Policy Help.

Configuring a remote portal authentication server

About this task
With portal authentication enabled, the device searches for a portal authentication server for a
received portal request packet according to the source IP address and VPN information of the
packet.
• If a matching portal authentication server is found, the device regards the packet valid and
sends an authentication response packet to the portal authentication server. After a user logs in
to the device, the user interacts with the portal authentication server as needed.
• If no matching portal authentication server is found, the device drops the packet.
Restrictions and guidelines
Do not delete a portal authentication server in use. Otherwise, users authenticated by that server
cannot log out correctly.
Procedure
1. Enter system view.
system-view
2. Create a portal authentication server and enter its view.
portal server server-name
You can create multiple portal authentication servers.
3. Specify the IP address of the portal authentication server.
IPv4:
ip ipv4-address [ vpn-instance vpn-instance-name ] [ key { cipher |
simple } string ]
IPv6:
ipv6 ipv6-address [ vpn-instance vpn-instance-name ] [ key { cipher |
simple } string ]
4. (Optional.) Set the destination UDP port number used by the device to send unsolicited portal
packets to the portal authentication server.
port port-number
By default, the UDP port number is 50100.
This port number must be the same as the listening port number specified on the portal
authentication server.
5. (Optional.) Specify the portal authentication server type.
server-type { cmcc | imc }
By default, the portal authentication server type is IMC.
The specified server type must be the same as the type of the portal authentication server
actually used.
6. (Optional.) Configure the device to periodically register with the portal authentication server.
server-register [ interval interval-value ]
By default, the device does not register with a portal authentication server.

211
Configuring a portal Web server
Portal Web server tasks at a glance
To configure a portal Web server, perform the following tasks:
1. Configure basic parameters for a portal Web server
2. (Optional.) Enabling the captive-bypass feature
3. (Optional.) Configuring a match rule for URL redirection

Configure basic parameters for a portal Web server

1. Enter system view.
system-view
2. Create a portal Web server and enter its view.
portal web-server server-name
You can create multiple portal Web servers.
3. Specify the VPN instance to which the portal Web server belongs.
vpn-instance vpn-instance-name
By default, the portal Web server belongs to the public network.
4. Specify the URL of the portal Web server.
url url-string
By default, no URL is specified for a portal Web server.
5. Configure the parameters to be carried in the URL when the device redirects it to users.
url-parameter param-name { original-url | source-address | source-mac
[ encryption { aes | des } key { cipher | simple } string ] | value
expression }
By default, no redirection URL parameters are configured.
6. (Optional.) Specify the portal Web server type.
server-type { cmcc | imc }
By default, the portal Web server type is IMC.
This configuration is applicable to only to the remote portal service.
The specified server type must be the same as the type of the portal Web server actually used.

Enabling the captive-bypass feature

About this task
By default, the device automatically pushes the portal authentication page to iOS devices and some
Android devices when they are connected to the network. The captive-bypass feature enables the
device to push the portal authentication page to iOS devices and some Android devices only when
they access the Internet by using browsers.
Procedure
1. Enter system view.
system-view
2. Enter portal Web server view.
portal web-server server-name

212
 3. Enable the captive-pass feature.
captive-bypass enable
By default, the captive-bypass feature is disabled.

Configuring a match rule for URL redirection

About this task
A URL redirection match rule matches HTTP or HTTPS requests by user-requested URL or
User-Agent information, and redirects the matching requests to the specified redirection URL.
Therefore, URL redirection match rules allow for more flexible URL redirection than the url
command. The url command is only used to redirect HTTP or HTTPS requests from
unauthenticated users to the portal Web server for authentication.
Restrictions and guidelines
For a user to successfully access a redirection URL, configure a portal-free rule to allow HTTP or
HTTPS requests destined for the redirection URL to pass. For information about configuring
portal-free rules, see the portal free-rule command.
If both the url and if-match commands are executed, the if-match command takes priority to
perform URL redirection.
Procedure
1. Enter system view.
system-view
2. Enter portal Web server view.
portal web-server server-name
3. Configure a match rule for URL redirection.
if-match { original-url url-string redirect-url url-string
[ url-param-encryption { aes | des } key { cipher | simple } string ] |
user-agent string redirect-url url-string }

Configuring local portal service features

About the local portal service
After a local portal service is configured, the device acts as the portal Web server and portal
authentication server to perform portal authentication on users. The portal authentication page file is
saved in the root directory of the device.

Restrictions and guidelines for configuring local portal service

features
For an interface to use the local portal service, the URL of the portal Web server specified for the
interface must meet the following requirements:
• The IP address in the URL must be the IP address of a Layer 3 interface (except 127.0.0.1) on
the device, and the IP address must be reachable to portal clients.
• The URL must be ended with /portal/. For example: http://1.1.1.1/portal/.

213
 The device provides a default authentication page file. To use customized authentication pages, you
must edit the authentication pages, compress them to a file, and then upload the file to the device.
On the device, specify the file as the default authentication page file.

Customizing authentication pages

About this task
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 customization rules when you edit the authentication page files.
File name rules
The names of the main authentication page files are fixed (see Table 24). You can define the names
of the files other than the main authentication page files. File names and directory names are case
insensitive.
Table 24 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
online.htm
Pushed after the user gets online for online notification
System busy page
busy.htm
Pushed when the system is busy or the user is in the logon process
Logoff success page logoffSuccess.htm

Page request rules

The local portal Web server supports only Get and Post requests.
• Get requests—Used to get the static files in the authentication pages and allow no recursion.
For example, if file Logon.htm includes contents that perform Get 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 when editing 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 cannot be sent to the access
device.

214
  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 the PtButton attribute.
2. Authentication pages logon.htm and logonFail.htm must 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:
1 -rw- 1405 Feb 28 2008 15:53:20 ssid1.zip
0 -rw- 1405 Feb 28 2008 15:53:31 ssid2.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:
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() to LogonSuccess.htm.
See the contents in gray:
<html>
<head>
<title>LogonSuccess</title>

215
 <script type="text/javascript" language="javascript"
src="pt_private.js"></script>
</head>
<body onload="pt_init();" onbeforeunload="return pt_unload();">
... ...
</body>
</html>

Configuring a local portal Web service

Prerequisites
Before you configure an HTTPS-based local portal Web service, you must complete the following
tasks:
• Configure a PKI policy, obtain the CA certificate, and request a local certificate. For more
information, see "Configuring PKI."
• Configure an SSL server policy, and specify the PKI domain configured in the PKI policy.
During SSL connection establishment, the user browser might display a message that it cannot
verify server identity by certificate. For users to perform portal authentication without checking
such a message, configure an SSL server policy to request a client-trusted certificate on the
device. The name of the policy must be https_redirect. For more information about SSL server
policy configuration, see "Configuring SSL."
Procedure
1. Enter system view.
system-view
2. Enable HTTP- or HTTPS-based local portal Web service and enter its view.
portal local-web-server { http | https ssl-server-policy policy-name
[ tcp-port port-number ] }
3. Specify the default authentication page file for the local portal Web service.
default-logon-page filename
By default, the default authentication page file for a local portal Web service is file
defaultfile.zip.
4. (Optional.) Configure the HTTP or HTTPS listening TCP port for the local portal Web service.
tcp-port port-number
By default, the HTTP service listening port number is 80 and the HTTPS service listening port
number is the TCP port number set by the portal local-web-server command.

Enabling portal authentication on an interface

Restrictions and guidelines
When you enable portal authentication on an interface, follow these restrictions and guidelines:
• Cross-subnet authentication mode (layer3) does not require Layer 3 forwarding devices
between the access device and the portal authentication clients. However, if a Layer 3
forwarding device exists between the authentication client and the access device, you must use
the cross-subnet portal authentication mode.
• You can enable both IPv4 portal authentication and IPv6 portal authentication on an interface.
When you configure re-DHCP portal authentication on an interface, follow these restrictions and
guidelines:

216
 • Make sure the interface has a valid IP address before you enable re-DHCP portal
authentication on the interface.
• With re-DHCP portal authentication, configure authorized ARP on the interface as a best
practice to make sure only valid users can access the network. With authorized ARP configured
on the interface, the interface learns ARP entries only from the users who have obtained a
public address from DHCP.
• For successful re-DHCP portal authentication, make sure the BAS-IP or BAS-IPv6 attribute
value is the same as the device IP address specified on the portal authentication server. To
configure the attribute, use the portal { bas-ip | bas-ipv6 } command.
• An IPv6 portal server does not support re-DHCP portal authentication.
Portal authentication supports both HTTP redirect and HTTPS redirect. The default HTTPS redirect
listening port number on the device is 6654. To change the HTTPS redirect listening port number,
see HTTP redirect configuration in Layer 3—IP Services Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enter Layer 3 interface view.
interface interface-type interface-number
3. Enable portal authentication.
IPv4:
portal enable method { direct | layer3 | redhcp }
IPv6:
portal ipv6 enable method { direct | layer3 }
By default, portal authentication is disabled.

Specifying a portal Web server on an interface

About this task
With a portal Web server specified on an interface, the device redirects the HTTP requests of portal
users on the interface to the portal Web server.
You can specify both an IPv4 portal Web server and an IPv6 portal Web server on an interface.
Procedure
1. Enter system view.
system-view
2. Enter Layer 3 interface view.
interface interface-type interface-number
3. Specify a portal Web server on the interface.
portal [ ipv6 ] apply web-server server-name [ fail-permit ]
By default, no portal Web servers are specified on an interface.

Enabling portal to support IPv4/IPv6 dual stack

About this task
When portal is enabled to support IPv4/IPv6 dual stack, dual-stack portal users can access both
IPv4 and IPv6 networks after passing one type (IPv4 or IPv6) of portal authentication.

217
 The following describes the mechanism of how portal supports IPv4/IPv6 dual stack:
1. A portal user passes portal authentication of one IP stack (the first stack, IPv4 or IPv6). The
user can access network resources of this IP stack.
2. The device records the user's MAC address and IP address in the portal user entry for the user.
3. Upon receiving a packet of the other IP stack (the second stack, IPv6 or IPv4) from the user, the
device compares the source MAC address with that in the portal user entry for the user.
 If the MAC addresses are the same, the device allows the user to access network resources
of the second stack without reauthentication.
 If the MAC addresses are different, the user needs to perform portal authentication of the
second stack.
Restrictions and guidelines
This configuration takes effect on an interface only when both direct IPv4 portal authentication and
direct IPv6 portal authentication are enabled on the interface.
Procedure
1. Enter system view.
system-view
2. Enter Layer 3 interface view.
interface interface-type interface-number
3. Enable portal to support IPv4/IPv6 dual stack.
portal dual-stack enable
By default, portal support for IPv4/IPv6 dual stack is disabled. Dual-stack portal users can
access only one type (IPv4 or IPv6) of network after passing that type of portal authentication.

Specifying a preauthentication IP address pool

About this task
You must specify a preauthentication IP address pool on a portal-enabled interface in the following
situation:
• Portal users access the network through a subinterface of the portal-enabled interface.
• The subinterface does not have an IP address.
• Portal users need to obtain IP addresses through DHCP.
After a user connects to a portal-enabled interface, the user uses an IP address for portal
authentication according to the following rules:
• If the interface is configured with a preauthentication IP address pool, the user uses the
following IP address:
 If the client is configured to obtain an IP address automatically through DHCP, the user
obtains an address from the specified IP address pool.
 If the client is configured with a static IP address, the user uses the static IP address.
• If the interface has an IP address but no preauthentication IP pool specified, the user uses the
static IP address or the IP address obtained from a DHCP server.
• If the interface has no IP address or preauthentication IP pool specified, the user cannot
perform portal authentication.
After the user passes portal authentication, the AAA server authorizes an IP address pool for
re-assigning an IP address to the user. If no authorized IP address pool is deployed, the user
continues using the previous IP address.

218
Restrictions and guidelines
This configuration takes effect only when the direct IPv4 portal authentication is enabled on the
interface.
Make sure the specified IP address pool exists and is complete. Otherwise, the user cannot obtain
the IP address and cannot perform portal authentication.
If the portal user does not perform authentication or fails to pass authentication, the assigned IP
address is still retained.
Procedure
1. Enter system view.
system-view
2. Enter Layer 3 interface view.
interface interface-type interface-number
3. Specify a preauthentication IP address pool on the interface.
portal [ ipv6 ] pre-auth ip-pool pool-name
By default, no preauthentication IP address pool is specified on an interface.

Specifying a portal authentication domain

About portal authentication domains
An authentication domain defines a set of authentication, authorization, and accounting policies.
Each portal user belongs to an authentication domain and is authenticated, authorized, and
accounted in the domain.
With an authentication domain specified on an interface, the device uses the authentication domain
for AAA of portal users. This allows for flexible portal access control.

Restrictions and guidelines for specifying a portal

authentication domain
The device selects the authentication domain for a portal user in this order:
1. ISP domain specified for the interface.
2. ISP domain carried in the username.
3. System default ISP domain.
If the chosen domain does not exist on the device, the device searches for the ISP domain
configured to accommodate users assigned to nonexistent domains. If no such ISP domain is
configured, user authentication fails. For information about ISP domains, see "Configuring AAA."
For the authorization ACL in the authentication domain, the following rules apply:
• If the user traffic matches a rule in the ACL, the device processes the traffic based on the permit
or deny statement of the rule.
• If the user traffic does not match any rule in the ACL, the device permits the traffic. To deny such
traffic, configure the last rule in the ACL to deny all packets by using the rule deny ip
command.
• If the ACL contains rules that specify a source address, users might not be able to get online.
Do not specify a source IPv4, IPv6, or MAC address when you configure a rule in the ACL.

219
Specifying a portal authentication domain on an interface
1. Enter system view.
system-view
2. Enter Layer 3 interface view.
interface interface-type interface-number
3. Specify an portal authentication domain on the interface.
portal [ ipv6 ] domain domain-name
By default, no portal authentication domain is specified on an interface.
You can specify both an IPv4 portal authentication domain and an IPv6 portal authentication
domain on an interface.

Controlling portal user access

Configuring a portal-free rule
About this task
A portal-free rule allows specified users to access specified external websites without portal
authentication.
The matching items for a portal-free rule include the host name, source/destination IP address,
TCP/UDP port number, source MAC address, access 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.
Restrictions and guidelines for configuring a portal-free rule
If you specify both a VLAN and an interface, the interface must belong to the VLAN. If the interface
does not belong to the VLAN, the portal-free rule does not take effect.
You cannot configure two or more portal-free rules with the same filtering criteria. Otherwise, the
system prompts that the rule already exists.
Regardless of whether portal authentication is enabled or not, you can only add or remove a
portal-free rule. You cannot modify it.
Configuring an IP-based portal-free rule
1. Enter system view.
system-view
2. Configure an IP-based portal-free rule.
IPv4:
portal free-rule rule-number { destination ip { ipv4-address
{ mask-length | mask } | any } [ tcp tcp-port-number | udp udp-port-number ]
| source ip { ipv4-address { mask-length | mask } | any } [ tcp
tcp-port-number | udp udp-port-number ] } * [ interface interface-type
interface-number ]
IPv6:
portal free-rule rule-number { destination ipv6 { ipv6-address
prefix-length | any } [ tcp tcp-port-number | udp udp-port-number ] |
source ipv6 { ipv6-address prefix-length | any } [ tcp tcp-port-number |
udp udp-port-number ] } * [ interface interface-type interface-number ]

220
Configuring a source-based portal-free rule
1. Enter system view.
system-view
2. Configure a source-based portal-free rule.
portal free-rule rule-number source { interface interface-type
interface-number | mac mac-address | vlan vlan-id } *
The vlan vlan-id option takes effect only on portal users that access the network through
VLAN interfaces.
Configuring a destination-based portal-free rule
1. Enter system view.
system-view
2. Configure a destination-based portal-free rule.
portal free-rule rule-number destination host-name
Before you configure destination-based portal-free rules, make sure a DNS server is
deployed on the network.

Configuring an authentication source subnet

About this task
By configuring authentication source subnets, you specify that only HTTP or HTTPS packets from
users on the authentication source subnets can trigger portal authentication. HTTP or HTTPS
packets from users not in authentication source subnets will be discarded if the packets do not match
any portal-free rules.
Restrictions and guidelines
Authentication source subnets are used only for cross-subnet authentication.
In direct or re-DHCP portal authentication mode, a portal user and its access interface
(portal-enabled) are on the same subnet. It is not necessary to specify the subnet as the
authentication source subnet.
• In direct mode, the access device regards the authentication source subnet as any source IP
address.
• In re-DHCP mode, the access device regards the authentication source subnet on an interface
as the subnet to which the private IP address of the interface belongs.
If both authentication source subnets and destination subnets are configured on an interface, only
the authentication destination subnets take effect.
You can configure multiple authentication source subnets. If the source subnets overlap, the subnet
with the largest address scope (with the smallest mask or prefix) takes effect.
Procedure
1. Enter system view.
system-view
2. Enter Layer 3 interface view.
interface interface-type interface-number
3. Configure a portal authentication source subnet.
IPv4:
portal layer3 source ipv4-network-address { mask-length | mask }
IPv6:

221
 portal ipv6 layer3 source ipv6-network-address prefix-length.
By default, no portal authentication source subnets are configured, and users from any subnets
can trigger portal authentication.

Configuring an authentication destination subnet

About this task
After authentication destination subnets are configured, the device performs portal authentication on
portal users only when they access the specified subnets (excluding the destination IP addresses
and subnets specified in portal-free rules). Users can access other subnets without portal
authentication.
Restrictions and guidelines
If both authentication source subnets and destination subnets are configured on an interface, only
the authentication destination subnets take effect.
You can configure multiple authentication destination subnets. If the destination subnets overlap, the
subnet with the largest address scope (with the smallest mask or prefix) takes effect.
Procedure
1. Enter system view.
system-view
2. Enter Layer 3 interface view.
interface interface-type interface-number
3. Configure a portal authentication destination subnet.
IPv4:
portal free-all except destination ipv4-network-address { mask-length
| mask }
IPv6:
portal ipv6 free-all except destination ipv6-network-address
prefix-length
By default, no authentication destination subnets are configured, and users accessing any
subnets must pass portal authentication.

Configuring support of Web proxy for portal authentication

About this task
To allow HTTP requests proxied by a Web proxy server to trigger portal authentication, specify the
port number of the Web proxy server on the device. If a Web proxy server port is not specified on the
device, HTTP requests proxied by the Web proxy server are dropped, and portal authentication
cannot be triggered.
Restrictions and guidelines
If a user's browser uses the Web Proxy Auto-Discovery (WPAD) protocol to discover Web proxy
servers, you must perform the following tasks on the device:
• Specify port numbers of the Web proxy servers.
• Configure portal-free rules to allow user packets destined for the WPAD server to pass without
authentication.
If portal users enable Web proxy in their browsers, the users must add the IP address of the portal
authentication server as a proxy exception in their browsers. Thus, HTTP packets that the users
send to the portal authentication server will not be sent to Web proxy servers.

222
 You cannot specify Web proxy server port 443 on the device.
You can execute this command multiple times to specify multiple port numbers of Web proxy servers.
Procedure
1. Enter system view.
system-view
2. Specify the port number of a Web proxy server.
portal web-proxy port port-number
By default, no port numbers of Web proxy servers are specified. Proxied HTTP requests are
dropped.

Checking the issuing of category-2 portal filtering rules

About this task
Category-2 portal filtering rules permit authenticated users to access authorized network resources.
By default, the device allows an authenticated user to come online as long as a member device has
issued a category-2 portal filtering rule for the user. Users coming online from global interfaces might
fail to access network resources because some member ports might not have category-2 rules for
the users. To resolve this issue, enable the device to check the issuing of category-2 portal filtering
rules. Then, the device allows users to come online only when all member devices have issued
category-2 portal filtering rules for the users.
As a best practice, perform this task when portal authentication is enabled on a global interface.
Procedure
1. Enter system view.
system-view
2. Enable the device to check the issuing of category-2 portal filtering rules.
portal user-rule assign-check enable
By default, the device does not check the issuing of category-2 portal filtering rules.

Setting the maximum number of portal users

About this task
Perform this task to control the total number of portal users in the system, and the maximum number
of IPv4 or IPv6 portal users on an interface.
Restrictions and guidelines for setting the maximum number of portal users
Make sure the maximum combined number of IPv4 and IPv6 portal users specified on all interfaces
does not exceed the global maximum number. Otherwise, the exceeding number of portal users will
not be able to log in to the device.
Make sure the sum of the maximum number of portal users for IPv4 and IPv6 on an interface does
not exceed the maximum number of all portal users set on the interface. Otherwise, the exceeding
number of portal users cannot come online from the interface.
You can set the maximum number of portal users in interface view or system view. The effective
value on an interface is as follows:
• If portal does not support IPv4/IPv6 dual stack on the interface, the maximum number of portal
users allowed on the interface is the smallest value among the following items:
 Maximum number of IPv4 or IPv6 portal users allowed on the interface.
 Maximum number of all portal users allowed on the interface.

223
  Global maximum number of portal users.
• If portal supports IPv4/IPv6 dual stack on the interface, the maximum number of portal users
allowed on the interface is the smallest value among the following items:
 Maximum number of all portal users allowed on the interface.
 Global maximum number of portal users.
Setting the global maximum number of portal users
1. Enter system view.
system-view
2. Set the global maximum number of portal users.
portal max-user max-number
By default, no limit is set on the global number of portal users.
If you set the global maximum number smaller than the number of current online portal users on
the device, this configuration still takes effect. The online users are not affected but the system
forbids new portal users to log in.
Setting the maximum number of portal users on an interface
1. Enter system view.
system-view
2. Enter Layer 3 interface view.
interface interface-type interface-number
3. Set the maximum number of portal users.
portal { ipv4-max-user | ipv6-max-user | max-user } max-number
By default, no limit is set on the number of portal users on an interface.
If you set the maximum number smaller than the current number of portal users on an interface,
this configuration still takes effect. The online users are not affected but the system forbids new
portal users to log in from the interface.

Enabling strict-checking on portal authorization information

About this task
The strict checking feature allows a portal user to stay online only when the authorization information
for the user is successfully deployed. The strict checking fails if the authorized ACL or user profile
does not exist on the device or the device fails to deploy the user profile.
You can enable strict checking on the authorized ACL, authorized user profile, or both. If you enable
both ACL checking and user profile checking, the user will be logged out if either checking fails.
Enabling strict checking on portal authentication information on an interface
1. Enter system view.
system-view
2. Enter Layer 3 interface view.
interface interface-type interface-number
3. Enable strict checking on portal authorization information.
portal authorization { acl | user-profile } strict-checking
By default, strict checking on portal authorization information is disabled on an interface. Portal
users stay online even when the authorized ACL or user profile does not exist or the device fails
to deploy the user profile.

224
Allowing only users with DHCP-assigned IP addresses to
pass portal authentication
About this task
This feature allows only users with DHCP-assigned IP addresses to pass portal authentication.
Users with static IP addresses cannot pass portal authentication to come online. Use this feature to
ensure that only users with valid IP addresses can access the network.
Restrictions and guidelines
This feature takes effect only when the device acts as both the access device and the DHCP server.
If this feature is configured, to ensure that IPv6 users can pass portal authentication, disable the
temporary IPv6 address feature on terminal devices. Otherwise, IPv6 users will use temporary IPv6
addresses to access the IPv6 network and will fail portal authentication.
Configuration of this feature does not affect the online portal users.
Allowing only users with DHCP-assigned IP addresses to pass portal authentication on an
interface
1. Enter system view.
system-view
2. Enter Layer 3 interface view.
interface interface-type interface-number
3. Allow only users with DHCP-assigned IP addresses to pass portal authentication.
portal [ ipv6 ] user-dhcp-only
By default, both users with IP addresses obtained through DHCP and users with static IP
addresses can pass authentication to come online.

Enabling portal roaming

About this task
If portal roaming is enabled on a VLAN interface, an online portal user can access resources from
any Layer 2 port in the VLAN without re-authentication.
If portal roaming is disabled, to access external network resources from a Layer 2 port different from
the current access port in the VLAN, the user must do the following:
1. Logs out from the current port.
2. Re-authenticates on the new Layer 2 port.
Restrictions and guidelines
Portal roaming takes effect only on portal users logging in from VLAN interfaces. It does not take
effect on portal users logging in from common Layer 3 interface.
You cannot enable portal roaming when online portal users exist on the device.
For portal roaming to take effect, you must disable the Rule ARP or ND entry feature by using the
undo portal refresh { arp | nd } enable command.
Procedure
1. Enter system view.
system-view
2. Enable portal roaming.
portal roaming enable

225
 By default, portal roaming is disabled.

Configuring the portal fail-permit feature

About this task
Perform this task to configure the portal fail-permit feature on an interface. When the access device
detects that the portal authentication server or portal Web server is unreachable, it allows users on
the interface to have network access without portal authentication.
If you enable fail-permit for both a portal authentication server and a portal Web server on an
interface, the interface does the following:
• 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.
Procedure
1. Enter system view.
system-view
2. Enter Layer 3 interface view.
interface interface-type interface-number
3. Enable portal fail-permit for a portal authentication server.
portal [ ipv6 ] fail-permit server server-name
By default, portal fail-permit is disabled for a portal authentication server.
4. Enable portal fail-permit for a portal Web server.
portal [ ipv6 ] apply web-server server-name [ fail-permit ]
By default, portal fail-permit is disabled for a portal Web server.

Configuring portal detection features

Configuring online detection of portal users
About this task
Use the online detection feature to quickly detect abnormal logouts of portal users. Configure ARP or
ICMP detection for IPv4 portal users. Configure ND or ICMPv6 detection for IPv6 portal users.
If the device receives no packets from a portal user within the idle time, the 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 considers
that the user is online and stops sending detection packets. Then the device resets the idle
timer and repeats the detection process when the timer expires.
 If the device receives no reply after the maximum number of detection attempts, the device
logs out the user.
• ARP or ND detection—Sends ARP or ND requests to the user and detects the ARP or ND
entry status of the user at configurable intervals.

226
  If the ARP or ND entry of the user is refreshed within the maximum number of detection
attempts, the device considers that the user is online and stops detection. Then the device
resets the idle timer and repeats the detection process when the timer expires.
 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.
Restrictions and guidelines
ARP detection and ND detection apply only to direct and re-DHCP portal authentication. ICMP
detection applies to all portal authentication modes.
Procedure
1. Enter system view.
system-view
2. Enter Layer 3 interface view.
interface interface-type interface-number
3. Configure online detection of portal users.
IPv4:
portal user-detect type { arp | icmp } [ retry retries ] [ interval
interval ] [ idle time ]
IPv6:
portal ipv6 user-detect type { icmpv6 | nd } [ retry retries ] [ interval
interval ] [ idle time ]
By default, online detection is disabled for portal users on an interface.

Configuring portal authentication server detection

About this task
During portal authentication, if the communication between the access device and portal
authentication server is broken, new portal users are not able to log in. Online portal users are not
able to log out normally.
To address this problem, the access device needs to be able to detect the reachability changes of the
portal server quickly and take corresponding actions to deal with the changes.
The portal authentication server detection feature enables the device to periodically detect portal
packets sent by a portal authentication server to determine the reachability of the server. If the device
receives a portal packet within a detection timeout (timeout timeout) and the portal packet is
valid, the device considers the portal authentication server to be reachable. Otherwise, the device
considers the portal authentication server to be unreachable.
Portal packets include user login packets, user logout packets, and heartbeat packets. Heartbeat
packets are periodically sent by a server. By detecting heartbeat packets, the device can detect the
server's actual status more quickly than by detecting other portal packets.
Restrictions and guidelines
The portal authentication server detection feature takes effect only when the device has a
portal-enabled interface.
Only the IMC portal authentication server supports sending heartbeat packets. To test server
reachability by detecting heartbeat packets, you must enable the server heartbeat feature on the
IMC portal authentication server.
You can configure the device to take one or more of the following actions when the server
reachability status changes:

227
 • Sending a log message, which contains the name, the current state, and the original state of the
portal authentication server.
• Enabling portal fail-permit. When the portal authentication server is unreachable, the portal
fail-permit feature on an interface allows users on the interface to have network access. When
the server recovers, it resumes portal authentication on the interface. For more information, see
"Configuring the portal fail-permit feature."
• Make sure the detection timeout configured on the device is greater than the server heartbeat
interval configured on the portal authentication server.
Procedure
1. Enter system view.
system-view
2. Enter portal authentication server view.
portal server server-name
3. Configure portal authentication server detection.
server-detect [ timeout timeout ] log
By default, portal authentication server detection is disabled.

Configuring portal Web server detection

About this task
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 feature, the access device simulates 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 detects the 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 server is unreachable.
You can configure the device to take one or more of the following actions when the server
reachability status changes:
• Sending a log message, which contains the name, the current state, and the original state of the
portal Web server.
• Enabling portal fail-permit. When the portal Web server is unreachable, the portal fail-permit
feature on an interface allows users on the interface to have network access. When the server
recovers, it resumes portal authentication on the interface. For more information, see
"Configuring the portal fail-permit feature."
Restrictions and guidelines
The portal Web server detection feature takes effect only when the URL of the portal Web server is
specified and the device has a portal-enabled interface.
Procedure
1. Enter system view.
system-view
2. Enter portal Web server view.

228
 portal web-server server-name
3. Configure portal Web server detection.
server-detect [ interval interval ] [ retry retries ] log
By default, portal Web server detection is disabled.

Configuring portal user synchronization

About this task
Once the access device loses communication with a portal authentication server, the portal user
information on the access device and that on the portal authentication server might be inconsistent
after the communication resumes. To address this problem, the device provides the portal user
synchronization feature. This feature is implemented by sending and detecting portal
synchronization packets, as follows:
1. The portal authentication server sends the online user information to the access device in a
synchronization packet at the user heartbeat interval.
The user heartbeat interval is set on the portal authentication server.
2. Upon receiving the synchronization packet, the access device compares the users carried in
the packet with its own user list and performs the 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. The access device starts the
synchronization detection timer (timeout timeout) immediately when a user logs in.
 If the user does not appear in any synchronization packet within a synchronization detection
interval, the access device considers the user does not exist on the portal authentication
server and logs the user out.
Restrictions and guidelines
Portal user synchronization requires a portal authentication server to support the portal user
heartbeat function. Only the IMC portal authentication server supports the portal user heartbeat
function. To implement the portal user synchronization feature, you also need to configure the user
heartbeat function on the portal authentication server. Make sure the user heartbeat interval
configured on the portal authentication server is not greater than the synchronization detection
timeout configured on the access device.
Deleting a portal authentication server on the access device also deletes the user synchronization
configuration for the portal authentication server.
Procedure
1. Enter system view.
system-view
2. Enter portal authentication server view.
portal server server-name
3. Configure portal user synchronization.
user-sync timeout timeout
By default, portal user synchronization is disabled.

229
Configuring portal packet attributes
Configuring the BAS-IP or BAS-IPv6 attribute
About this task
If the device runs Portal 2.0, the unsolicited packets sent to the portal authentication server must
carry the BAS-IP attribute. If the device runs Portal 3.0, the unsolicited packets sent to the portal
authentication server must carry the BAS-IP or BAS-IPv6 attribute.
After this attribute is configured, the source IP address for unsolicited notification portal packets the
device sends to the portal authentication server is the configured BAS-IP or BAS-IPv6 address. If the
attribute is not configured, the source IP address of the portal packets is the IP address of the packet
output interface.
Restrictions and guidelines
During a re-DHCP portal authentication or mandatory user logout process, the device sends portal
notification packets to the portal authentication server. For the authentication or logout process to
complete, make sure the BAS-IP/BAS-IPv6 attribute is the same as the device IP address specified
on the portal authentication server.
You must configure the BAS-IP or BAS-IPv6 attribute on a portal authentication-enabled interface if
the following conditions are met:
• The portal authentication server is an IMC server.
• The portal device IP address specified on the portal authentication server is not the IP address
of the portal packet output interface.
Configuring the BAS-IP or BAS-IPv6 attribute on an interface
1. Enter system view.
system-view
2. Enter Layer 3 interface view.
interface interface-type interface-number
3. Configure the BAS-IP or BAS-IPv6 attribute.
IPv4:
portal bas-ip ipv4-address
By default, the BAS-IP attribute of an IPv4 portal reply packet is the source IPv4 address of the
packet. The BAS-IP attribute of an IPv4 portal notification packet is the IPv4 address of the
packet's output interface.
IPv6:
portal bas-ipv6 ipv6-address
By default, the BAS-IPv6 attribute of an IPv6 portal reply packet is the source IPv6 address of
the packet. The BAS-IPv6 attribute of an IPv6 portal notification packet is the IPv6 address of
the packet's output interface.

Specifying the device ID

About this task
The portal authentication server uses device IDs to identify the devices that send protocol packets to
the portal server.

230
Restrictions and guidelines
Make sure the configured device ID is different than any other access devices communicating with
the same portal authentication server.
Procedure
1. Enter system view.
system-view
2. Specify the device ID.
portal device-id device-id
By default, a device is not configured with a device ID.

Configuring attributes for RADIUS packets

Specifying a format for the NAS-Port-Id attribute
About this task
RADIUS servers from different vendors might require different formats of the NAS-Port-Id attribute in
the RADIUS packets. You can specify the NAS-Port-Id attribute format as required.
The device supports predefined formats (format 1, 2, 3, and 4). For more information about the
formats, see portal commands in Security Command Reference.
Procedure
1. Enter system view.
system-view
2. Specify the format for the NAS-Port-Id attribute.
portal nas-port-id format { 1 | 2 | 3 | 4 }
By default, the format for the NAS-Port-Id attribute is format 2.

Configuring the NAS-Port-Type attribute

About this task
The NAS-Port-Type attribute in a RADIUS request represents the type of a user's access interface.
The access device might not be able to correctly obtain the type of users' access interfaces when
multiple network devices exist between the access device and the portal client. For the access
device to send the correct access interface type to the RADIUS server, perform this task to configure
the NAS-Port-Type attribute.
Restrictions and guidelines
This configuration takes effect only on portal users that newly come online.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Configure the NAS-Port-Type attribute carried in outgoing RADIUS requests on the interface.
portal nas-port-type { 802.11 | adsl-cap | adsl-dmt | async | cable
| ethernet | g.3-fax | hdlc | idsl | isdn-async-v110 | isdn-async-v120

231
 | isdn-sync | piafs | sdsl | sync | virtual | wireless-other | x.25
| x.75 | xdsl }
By default, the NAS-Port-Type carried in outgoing RADIUS requests is Ethernet (attribute value
15).

Applying a NAS-ID profile to an interface

About this task
By default, the device sends its device name in the NAS-Identifier attribute of all RADIUS requests.
A NAS-ID profile enables you to send different NAS-Identifier attribute strings in RADIUS requests
from different VLANs. The strings can be organization names, service names, or any user
categorization criteria, depending on the administrative requirements.
For example, map the NAS-ID companyA to all VLANs of company A. The device will send
companyA in the NAS-Identifier attribute for the RADIUS server to identify requests from any
Company A users.
Restrictions and guidelines
You can apply a NAS-ID profile to a portal-enabled interface. If no NAS-ID profile is specified on the
interface or no matching NAS-ID is found in the specified profile, the device uses the device name as
the interface NAS-ID.
Procedure
1. Enter system view.
system-view
2. Create a NAS-ID profile and enter NAS-ID profile view.
aaa nas-id profile profile-name
For more information about this command, see Security Command Reference.
3. Configure a NAS ID and VLAN binding in the profile.
nas-id nas-identifier bind vlan vlan-id
For more information about this command, see Security Command Reference. Portal access
matches only the inner VLAN ID of QinQ packets. For more information about QinQ, see Layer
2—LAN Switching Configuration Guide.
4. Specify the NAS-ID profile on the interface.
a. Return to system view.
quit
b. Enter Layer 3 interface view.
interface interface-type interface-number
c. Specify the NAS-ID profile on the interface.
portal nas-id-profile profile-name
By default, no NAS-ID profile is specified for an interface.

Logging out online portal users

About this task
This feature deletes users that have passed portal authentication and terminates ongoing portal
authentications.

232
Restrictions and guidelines
When the number of online users exceeds 2000, executing the portal delete-user command
takes a few minutes.
To ensure successful logout of online users, do not disable portal authentication or perform
master/subordinate device switchover on the portal-enabled interface during the command
execution.
Procedure
1. Enter system view.
system-view
2. Log out online portal users.
portal delete-user { ipv4-address | all | interface interface-type
interface-number | ipv6 ipv6-address | mac mac-address }

Enabling portal user login/logout logging

About this task
This feature logs information about user login and logout events. The information includes the
username, user IP address and MAC address, user access interface, VLAN, and login result. The
logs are sent to the information center of the device. For the logs to be output correctly, you must also
configure the information center on the device. For more information about information center
configuration, see Network Management and Monitoring Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enable portal user login/logout logging.
portal log enable
By default, portal user login/logout logging is disabled.

Disabling the Rule ARP or ND entry feature for

portal clients
About this task
When the Rule ARP or ND entry feature is enabled for portal clients, ARP or ND entries for portal
clients are Rule entries after the clients come online. The Rule entries will not age out and will be
deleted immediately after the portal clients go offline. If a portal client goes offline and then tries to
get online before the ARP or ND entry is relearned for the client, the client will fail the authentication.
To avoid such authentication failure, disable this feature. Then, ARP or ND entries for portal clients
are dynamic entries after the clients come online and are deleted only when they age out.
Restrictions and guidelines
Enabling or disabling of this feature does not affect existing Rule/dynamic ARP or ND entries.
Procedure
1. Enter system view.
system-view
2. Disable the Rule ARP or ND entry feature for portal clients.

233
 undo portal refresh { arp | nd } enable
By default, the Rule ARP or ND entry feature is enabled for portal clients.

Configuring Web redirect

About this task
Web redirect is a simplified portal feature. With Web redirect, a user does not perform portal
authentication but is directly redirected to the specified URL on the first Web access attempt in a
browser. After the specified redirect interval, the user is redirected from the visiting website to the
specified URL again.
Web redirect can provide ISPs with extended services. For example, the ISPs can place
advertisements and publish information on the redirected webpage.
Restrictions and guidelines
The Web redirect feature takes effect only on HTTP packets that use the default port number 80.
Web redirect does not work when both Web redirect and portal authentication are enabled.
Procedure
1. Enter system view.
system-view
2. Enter Layer 3 interface view.
interface interface-type interface-number
3. Configure Web redirect.
web-redirect [ ipv6 ] url url-string [ interval interval ]
By default, Web redirect is disabled.

Display and maintenance commands for portal

Execute display commands in any view and the reset command in user view.

Task Command
Display portal configuration and portal display portal interface interface-type
running state. interface-number
Display packet statistics for portal display portal packet statistics
authentication servers. [ server server-name ]
display portal rule { all | dynamic |
Display portal rules. static } interface interface-type
interface-number [ slot slot-number ]
Display portal authentication server
display portal server [ server-name ]
information.

display portal user { all | interface

interface-type interface-number | ip
Display portal user information.
ipv4-address | ipv6 ipv6-address | mac
mac-address } [ verbose ]
display portal web-server
Display portal Web server information.
[ server-name ]

234
 Task Command
display web-redirect rule interface
Display Web redirect rule information. interface-type interface-number [ slot
slot-number ]
Clear packet statistics for portal reset portal packet statistics [ server
authentication servers. server-name ]

Portal configuration examples

Example: Configuring direct portal authentication
Network configuration
As shown in Figure 59, the host is directly connected to the switch (the access device). The host is
assigned a public IP address either manually or through DHCP. An IMC server acts as both a portal
authentication server and a portal Web server. A RADIUS server acts as the authentication and
accounting server. In this example, the IMC server runs IMC 7.1 (E0303) and IMC UAM 7.1 (E0304).
Configure direct portal authentication, so the host can access only the portal server before passing
the authentication and access other network resources after passing the authentication.
Figure 59 Network diagram

Portal server
Vlan-int100 Vlan-int2 192.168.0.111/24
2.2.2.1/24 192.168.0.100/24

Host Switch
2.2.2.2/24
Gateway: 2.2.2.1/24

RADIUS server
192.168.0.112/24

Prerequisites
• Configure IP addresses for the host, switch, and servers as shown in Figure 59 and make sure
they can reach each other.
• Configure the RADIUS server correctly to provide authentication and accounting functions.
Configuring the portal server
1. Configure the portal server:
a. Log in to IMC and click the User tab.
b. Select User Access Policy > Portal Service > Server from the navigation tree to open the
portal server configuration page, as shown in Figure 60.
c. Configure the portal server parameters as needed.
This example uses the default settings.
d. Click OK.

235
 Figure 60 Portal server configuration

2. Configure the IP address group:

a. Select User Access Policy > Portal Service > IP Group from the navigation tree to open
the portal IP address group configuration page.
b. Click Add to open the page as shown in Figure 61.
c. Enter the IP group name.
d. Enter the start IP address and end IP address of the IP group.
Make sure the host IP address is in the IP group.
e. Select a service group.
This example uses the default group Ungrouped.
f. Select Normal from the Action list.
g. Click OK.

236
 Figure 61 Adding an IP address group

3. Add a portal device:

a. Select User Access Policy > Portal Service > Device from the navigation tree to open the
portal device configuration page.
b. Click Add to open the page as shown in Figure 62.
c. Enter device name NAS.
d. Enter the IP address of the switch's interface connected to the host.
e. Set whether to support the portal server heartbeat and user heartbeat functions.
In this example, select No for both Support Server Heartbeat and Support User
Heartbeat.
f. Enter the key, which must be the same as that configured on the switch.
g. Select Directly Connected from the Access Method list.
h. Use the default settings for other parameters.
i. Click OK.
Figure 62 Adding a portal device

4. Associate the portal device with the IP address group:

a. As shown in Figure 63, click the Port Group Information Management icon for device
NAS to open the port group configuration page.
b. Click Add to open the page as shown in Figure 64.

237
 c. Enter the port group name.
d. Select the configured IP address group.
The IP address used by the user to access the network must be within this IP address
group.
e. Use the default settings for other parameters.
f. Click OK.
Figure 63 Device list

Figure 64 Adding a port group

Configuring the switch

1. Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<Switch> system-view
[Switch] radius scheme rs1
# Specify the primary authentication server and primary accounting server, and configure the
keys for communication with the servers.
[Switch-radius-rs1] primary authentication 192.168.0.112
[Switch-radius-rs1] primary accounting 192.168.0.112
[Switch-radius-rs1] key authentication simple radius

238
 [Switch-radius-rs1] key accounting simple radius
# Exclude the ISP domain name from the username sent to the RADIUS server.
[Switch-radius-rs1] user-name-format without-domain
[Switch-radius-rs1] quit
# Enable RADIUS session control.
[Switch] radius session-control enable
2. Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[Switch] domain dm1
# Configure AAA methods for the ISP domain.
[Switch-isp-dm1] authentication portal radius-scheme rs1
[Switch-isp-dm1] authorization portal radius-scheme rs1
[Switch-isp-dm1] accounting portal radius-scheme rs1
[Switch-isp-dm1] quit
# Configure domain dm1 as the default ISP domain. If a user enters the username without the
ISP domain name at login, the authentication and accounting methods of the default domain
are used for the user.
[Switch] domain default enable dm1
3. Configure portal authentication:
# Configure a portal authentication server.
[Switch] portal server newpt
[Switch-portal-server-newpt] ip 192.168.0.111 key simple portal
[Switch-portal-server-newpt] port 50100
[Switch-portal-server-newpt] quit
# Configure a portal Web server.
[Switch] portal web-server newpt
[Switch-portal-websvr-newpt] url http://192.168.0.111:8080/portal
[Switch-portal-websvr-newpt] quit
# Enable direct portal authentication on VLAN-interface 100.
[Switch] interface vlan-interface 100
[Switch–Vlan-interface100] portal enable method direct
# Specify portal Web server newpt on VLAN-interface 100.
[Switch–Vlan-interface100] portal apply web-server newpt
# Configure the BAS-IP as 2.2.2.1 for portal packets sent from VLAN-interface 100 to the portal
authentication server.
[Switch–Vlan-interface100] portal bas-ip 2.2.2.1
[Switch–Vlan-interface100] quit

Verifying the configuration

# Verify that the portal configuration has taken effect.
[Switch] display portal interface vlan-interface 100
Portal information of Vlan-interface100
NAS-ID profile: Not configured
Authorization : Strict checking
ACL : Disabled
User profile : Disabled
Dual stack : Disabled
Max users : Not configured

239
 IPv4:
Portal status: Enabled
Portal authentication method: Direct
Portal web server: newpt
Portal mac-trigger-server: Not configured
Authentication domain: Not configured
User-dhcp-only: Disabled
Pre-auth IP pool: Not configured
Max users: Not configured
Bas-ip: 2.2.2.1
User detection: Not configured
Action for server detection:
Server type Server name Action
-- -- --
Layer3 source network:
IP address Mask

Destination authenticate subnet:

IP address Mask
IPv6:
Portal status: Disabled
Portal authentication method: Disabled
Portal web server: Not configured
Portal mac-trigger-server: Not configured
Authentication domain: Not configured
User-dhcp-only: Disabled
Pre-auth IP pool: Not configured
Max users: Not configured
Bas-ipv6: Not configured
User detection: Not configured
Action for server detection:
Server type Server name Action
-- -- --
Layer3 source network:
IP address Prefix length

Destination authenticate subnet:

IP address Prefix length

A user can perform portal authentication by using the iNode client or through a Web browser. Before
passing the authentication, the user can access only the authentication page
http://192.168.0.111:8080/portal. All Web requests from the user will be redirected to the
authentication page. After passing the authentication, the user can access other network resources.
# After the user passes authentication, use the following command to display information about the
portal user.
[Switch] display portal user interface vlan-interface 100
Total portal users: 1
Username: abc
Portal server: newpt
State: Online

240
 VPN instance: N/A
MAC IP VLAN Interface
0015-e9a6-7cfe 2.2.2.2 100 Vlan-interface100
Authorization information:
DHCP IP pool: N/A
User profile: N/A
Session group profile: N/A
ACL number: N/A
Inbound CAR: N/A
Outbound CAR: N/A

Example: Configuring re-DHCP portal authentication

Network configuration
As shown in Figure 65, the host is directly connected to the switch (the access device). The host
obtains an IP address through the DHCP server. A portal server acts as both a portal authentication
server and a portal Web server. A RADIUS server acts as the authentication and accounting server.
Configure re-DHCP portal authentication. Before passing the authentication, the host is assigned a
private IP address. After passing the authentication, the host gets a public IP address and can
access network resources.
Figure 65 Network diagram

Portal Server
192.168.0.111/24
Vlan-int100
20.20.20.1/24 Vlan-int2
10.0.0.1/24 sub 192.168.0.100/24

Host Switch DHCP server

automatically obtains 192.168.0.112/24
an IP address

RADIUS server
192.168.0.113/24

Restrictions and guidelines

• For re-DHCP portal authentication, configure a public address pool (20.20.20.0/24) and a
private address pool (10.0.0.0/24) on the DHCP server. (Details not shown.)
• For re-DHCP portal authentication:
 The switch must be configured as a DHCP relay agent.
 The portal-enabled interface must be configured with a primary IP address (a public IP
address) and a secondary IP address (a private IP address).
For information about DHCP relay agent configuration, see Layer 3—IP Services Configuration
Guide.
• Make sure the IP address of the portal device added on the portal server is the public IP
address (20.20.20.1) of the switch's interface connecting the host. The private IP address range
for the IP address group associated with the portal device is the private subnet 10.0.0.0/24
where the host resides. The public IP address range for the IP address group is the public
subnet 20.20.20.0/24.

241
Prerequisites
• Configure IP addresses for the switch and servers as shown in Figure 65 and make sure the
host, switch, and servers can reach each other.
• Configure the RADIUS server correctly to provide authentication and accounting functions.
Procedure
1. Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<Switch> system-view
[Switch] radius scheme rs1
# Specify the primary authentication server and primary accounting server, and configure the
keys for communication with the servers.
[Switch-radius-rs1] primary authentication 192.168.0.113
[Switch-radius-rs1] primary accounting 192.168.0.113
[Switch-radius-rs1] key authentication simple radius
[Switch-radius-rs1] key accounting simple radius
# Exclude the ISP domain name from the username sent to the RADIUS server.
[Switch-radius-rs1] user-name-format without-domain
[Switch-radius-rs1] quit
# Enable RADIUS session control.
[Switch] radius session-control enable
2. Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[Switch] domain dm1
# Configure AAA methods for the ISP domain.
[Switch-isp-dm1] authentication portal radius-scheme rs1
[Switch-isp-dm1] authorization portal radius-scheme rs1
[Switch-isp-dm1] accounting portal radius-scheme rs1
[Switch-isp-dm1] quit
# Configure domain dm1 as the default ISP domain. If a user enters the username without the
ISP domain name at login, the authentication and accounting methods of the default domain
are used for the user.
[Switch] domain default enable dm1
3. Configure DHCP relay and authorized ARP:
# Configure DHCP relay.
[Switch] dhcp enable
[Switch] dhcp relay client-information record
[Switch] interface vlan-interface 100
[Switch–Vlan-interface100] ip address 20.20.20.1 255.255.255.0
[Switch–Vlan-interface100] ip address 10.0.0.1 255.255.255.0 sub
[Switch-Vlan-interface100] dhcp select relay
[Switch-Vlan-interface100] dhcp relay server-address 192.168.0.112
# Enable authorized ARP.
[Switch-Vlan-interface100] arp authorized enable
[Switch-Vlan-interface100] quit
4. Configure portal authentication:
# Configure a portal authentication server.
[Switch] portal server newpt

242
 [Switch-portal-server-newpt] ip 192.168.0.111 key simple portal
[Switch-portal-server-newpt] port 50100
[Switch-portal-server-newpt] quit
# Configure a portal Web server.
[Switch] portal web-server newpt
[Switch-portal-websvr-newpt] url http://192.168.0.111:8080/portal
[Switch-portal-websvr-newpt] quit
# Enable re-DHCP portal authentication on VLAN-interface 100.
[Switch] interface vlan-interface 100
[Switch–Vlan-interface100] portal enable method redhcp
# Specify portal Web server newpt on VLAN-interface 100.
[Switch–Vlan-interface100] portal apply web-server newpt
# Configure the BAS-IP as 20.20.20.1 for portal packets sent from VLAN-interface 100 to the
portal authentication server.
[Switch–Vlan-interface100] portal bas-ip 20.20.20.1
[Switch–Vlan-interface100] quit

Verifying the configuration

# Verify that the portal configuration has taken effect.
[Switch] display portal interface vlan-interface 100
Portal information of Vlan-interface100
NAS-ID profile: Not configured
Authorization : Strict checking
ACL : Disabled
User profile : Disabled
Dual stack : Disabled
Max users : Not configured
IPv4:
Portal status: Enabled
Portal authentication method: Redhcp
Portal web server: newpt
Portal mac-trigger-server: Not configured
Authentication domain: Not configured
User-dhcp-only: Disabled
Pre-auth IP pool: Not configured
Max users: Not configured
Bas-ip: 20.20.20.1
User detection: Not configured
Action for server detection:
Server type Server name Action
-- -- --
Layer3 source network:
IP address Mask

Destination authenticate subnet:

IP address Mask
IPv6:
Portal status: Disabled
Portal authentication method: Disabled

243
 Portal web server: Not configured
Portal mac-trigger-server: Not configured
Authentication domain: Not configured
User-dhcp-only: Disabled
Pre-auth IP pool: Not configured
Max users: Not configured
Bas-ipv6: Not configured
User detection: Not configured
Action for server detection:
Server type Server name Action
-- -- --
Layer3 source network:
IP address Prefix length

Destination authenticate subnet:

IP address Prefix length

Before passing the authentication, a user that uses the iNode client can access only the
authentication page http://192.168.0.111:8080/portal. All Web requests from the user will be
redirected to the authentication page. After passing the authentication, the user can access other
network resources.
# After the user passes authentication, use the following command to display information about the
portal user.
[Switch] display portal user interface vlan-interface 100
Total portal users: 1
Username: abc
Portal server: newpt
State: Online
VPN instance: N/A
MAC IP VLAN Interface
0015-e9a6-7cfe 20.20.20.2 100 Vlan-interface100
Authorization information:
DHCP IP pool: N/A
User profile: N/A
Session group profile: N/A
ACL number: N/A
Inbound CAR: N/A
Outbound CAR: N/A

Example: Configuring cross-subnet portal authentication

Network configuration
As shown in Figure 66, Switch A supports portal authentication. The host accesses Switch A through
Switch B. A portal server acts as both a portal authentication server and a portal Web server. A
RADIUS server acts as the authentication and accounting server.
Configure Switch A for cross-subnet portal authentication. Before passing the authentication, the
host can access only the portal Web server. After passing the authentication, the user can access
other network resources.

244
 Figure 66 Network diagram

Switch A
Vlan-int2
192.168.0.100/24
Portal server
192.168.0.111/24
Vlan-int4
20.20.20.1/24
Vlan-int4
Vlan-int2 20.20.20.2/24
8.8.8.1/24

Host Switch B
8.8.8.2/24 RADIUS server
192.168.0.112/24

Restrictions and guidelines

Make sure the IP address of the portal device added on the portal authentication server is the IP
address (20.20.20.1) of the switch's interface connecting the host. The IP address group associated
with the portal device is the subnet of the host (8.8.8.0/24).
Prerequisites
• Configure IP addresses for the switch and servers as shown in Figure 66 and make sure the
host, switch, and servers can reach each other.
• Configure the RADIUS server correctly to provide authentication and accounting functions.
Procedure
1. Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<SwitchA> system-view
[SwitchA] radius scheme rs1
# Specify the primary authentication server and primary accounting server, and configure the
keys for communication with the servers.
[SwitchA-radius-rs1] primary authentication 192.168.0.112
[SwitchA-radius-rs1] primary accounting 192.168.0.112
[SwitchA-radius-rs1] key authentication simple radius
[SwitchA-radius-rs1] key accounting simple radius
# Exclude the ISP domain name from the username sent to the RADIUS server.
[SwitchA-radius-rs1] user-name-format without-domain
[SwitchA-radius-rs1] quit
# Enable RADIUS session control.
[SwitchA] radius session-control enable
2. Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[SwitchA] domain dm1
# Configure AAA methods for the ISP domain.
[SwitchA-isp-dm1] authentication portal radius-scheme rs1
[SwitchA-isp-dm1] authorization portal radius-scheme rs1
[SwitchA-isp-dm1] accounting portal radius-scheme rs1
[SwitchA-isp-dm1] quit

245
 # Configure domain dm1 as the default ISP domain. If a user enters the username without the
ISP domain name at login, the authentication and accounting methods of the default domain
are used for the user.
[SwitchA] domain default enable dm1
3. Configure portal authentication:
# Configure a portal authentication server.
[SwitchA] portal server newpt
[SwitchA-portal-server-newpt] ip 192.168.0.111 key simple portal
[SwitchA-portal-server-newpt] port 50100
[SwitchA-portal-server-newpt] quit
# Configure a portal Web server.
[SwitchA] portal web-server newpt
[SwitchA-portal-websvr-newpt] url http://192.168.0.111:8080/portal
[SwitchA-portal-websvr-newpt] quit
# Enable cross-subnet portal authentication on VLAN-interface 4.
[SwitchA] interface vlan-interface 4
[SwitchA–Vlan-interface4] portal enable method layer3
# Specify portal Web server newpt on VLAN-interface 4.
[SwitchA–Vlan-interface4] portal apply web-server newpt
# Configure the BAS-IP as 20.20.20.1 for portal packets sent from VLAN-interface 4 to the
portal authentication server.
[SwitchA–Vlan-interface4] portal bas-ip 20.20.20.1
[SwitchA–Vlan-interface4] quit

Verifying the configuration

# Verify that the portal configuration has taken effect.
[SwitchA] display portal interface vlan-interface 4
Portal information of Vlan-interface4
NAS-ID profile: Not configured
Authorization : Strict checking
ACL : Disabled
User profile : Disabled
Dual stack : Disabled
Max users : Not configured
IPv4:
Portal status: Enabled
Portal authentication method: Layer3
Portal web server: newpt
Portal mac-trigger-server: Not configured
Authentication domain: Not configured
User-dhcp-only: Disabled
Pre-auth IP pool: Not configured
Max users: Not configured
Bas-ip: 20.20.20.1
User detection: Not configured
Action for server detection:
Server type Server name Action
-- -- --
Layer3 source network:

246
 IP address Mask

Destination authenticate subnet:

IP address Mask
IPv6:
Portal status: Disabled
Portal authentication method: Disabled
Portal web server: Not configured
Portal mac-trigger-server: Not configured
Authentication domain: Not configured
User-dhcp-only: Disabled
Pre-auth IP pool: Not configured
Max users: Not configured
Bas-ipv6: Not configured
User detection: Not configured
Action for server detection:
Server type Server name Action
-- -- --
Layer3 source network:
IP address Prefix length

Destination authenticate subnet:

IP address Prefix length

A user can perform portal authentication by using the iNode client or through a Web browser. Before
passing the authentication, the user can access only the authentication page
http://192.168.0.111:8080/portal. All Web requests from the user will be redirected to the
authentication page. After passing the authentication, the user can access other network resources.
# After the user passes authentication, use the following command to display information about the
portal user.
[SwitchA] display portal user interface vlan-interface 4
Total portal users: 1
Username: abc
Portal server: newpt
State: Online
VPN instance: N/A
MAC IP VLAN Interface
0000-0000-0000 8.8.8.2 4 Vlan-interface4
Authorization information:
DHCP IP pool: N/A
User profile: N/A
Session group profile: N/A
ACL number: N/A
Inbound CAR: N/A
Outbound CAR: N/A

247
Example: Configuring extended direct portal authentication
Network configuration
As shown in Figure 67, the host is directly connected to the switch (the access device). The host is
assigned a public IP address either manually or through DHCP. A portal server acts as both a portal
authentication server and a portal Web server. A RADIUS server acts as the authentication and
accounting server.
Configure extended direct portal authentication. If the host fails security check after passing identity
authentication, it can access only subnet 192.168.0.0/24. After passing security check, the host can
access other network resources.
Figure 67 Network diagram

Portal server
192.168.0.111/24

Vlan-int100 Vlan-int2
2.2.2.1/24 192.168.0.100/24

Host Switch RADIUS server

2.2.2.2/24 192.168.0.112/24
Gateway: 2.2.2.1/24

Security policy server

192.168.0.113/24

Prerequisites
• Configure IP addresses for the host, switch, and servers as shown in Figure 67 and make sure
they can reach each other.
• Configure the RADIUS server correctly to provide authentication and accounting functions.
Procedure
1. Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<Switch> system-view
[Switch] radius scheme rs1
# Specify the primary authentication server and primary accounting server, and configure the
keys for communication with the servers.
[Switch-radius-rs1] primary authentication 192.168.0.112
[Switch-radius-rs1] primary accounting 192.168.0.112
[Switch-radius-rs1] key accounting simple radius
[Switch-radius-rs1] key authentication simple radius
[Switch-radius-rs1] user-name-format without-domain
# Enable RADIUS session control.
[Switch] radius session-control enable
# Specify a session-control client with IP address 192.168.0.112 and shared key 12345 in
plaintext form.
[Switch] radius session-control client ip 192.168.0.112 key simple 12345
2. Configure an authentication domain:

248
 # Create an ISP domain named dm1 and enter its view.
[Switch] domain dm1
# Configure AAA methods for the ISP domain.
[Switch-isp-dm1] authentication portal radius-scheme rs1
[Switch-isp-dm1] authorization portal radius-scheme rs1
[Switch-isp-dm1] accounting portal radius-scheme rs1
[Switch-isp-dm1] quit
# Configure domain dm1 as the default ISP domain. If a user enters the username without the
ISP domain name at login, the authentication and accounting methods of the default domain
are used for the user.
[Switch] domain default enable dm1
3. Configure ACL 3000 as the isolation ACL and ACL 3001 as the security ACL.
[Switch] acl advanced 3000
[Switch-acl-ipv4-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[Switch-acl-ipv4-adv-3000] rule deny ip
[Switch-acl-ipv4-adv-3000] quit
[Switch] acl advanced 3001
[Switch-acl-ipv4-adv-3001] rule permit ip
[Switch-acl-ipv4-adv-3001] quit

NOTE:
Make sure you specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL on the
security policy server.

4. Configure portal authentication:

# Configure a portal authentication server.
[Switch] portal server newpt
[Switch-portal-server-newpt] ip 192.168.0.111 key simple portal
[Switch-portal-server-newpt] port 50100
[Switch-portal-server-newpt] quit
# Configure a portal Web server.
[Switch] portal web-server newpt
[Switch-portal-websvr-newpt] url http://192.168.0.111:8080/portal
[Switch-portal-websvr-newpt] quit
# Enable direct portal authentication on VLAN-interface 100.
[Switch] interface vlan-interface 100
[Switch–Vlan-interface100] portal enable method direct
# Specify portal Web server newpt on VLAN-interface 100.
[Switch–Vlan-interface100] portal apply web-server newpt
# Configure the BAS-IP as 2.2.2.1 for portal packets sent from VLAN-interface 100 to the portal
authentication server.
[Switch–Vlan-interface100] portal bas-ip 2.2.2.1
[Switch–Vlan-interface100] quit

Verifying the configuration

# Verify that the portal configuration has taken effect.
[Switch] display portal interface vlan-interface 100
Portal information of Vlan-interface100
NAS-ID profile: Not configured

249
 Authorization : Strict checking
ACL : Disabled
User profile : Disabled
Dual stack : Disabled
Max users : Not configured
IPv4:
Portal status: Enabled
Portal authentication method: Direct
Portal web server: newpt
Portal mac-trigger-server: Not configured
Authentication domain: Not configured
User-dhcp-only: Disabled
Pre-auth IP pool: Not configured
Max users: Not configured
Bas-ip: 2.2.2.1
User detection: Not configured
Action for server detection:
Server type Server name Action
-- -- --
Layer3 source network:
IP address Mask

Destination authenticate subnet:

IP address Mask
IPv6:
Portal status: Disabled
Portal authentication method: Disabled
Portal web server: Not configured
Portal mac-trigger-server: Not configured
Authentication domain: Not configured
User-dhcp-only: Disabled
Pre-auth IP pool: Not configured
Max users: Not configured
Bas-ipv6: Not configured
User detection: Not configured
Action for server detection:
Server type Server name Action
-- -- --
Layer3 source network:
IP address Prefix length

Destination authenticate subnet:

IP address Prefix length

Before passing portal authentication, a user that uses the iNode client can access only the
authentication page http://192.168.0.111:8080/portal. All Web requests from the user will be
redirected to the authentication page.
• The user can access the resources permitted by ACL 3000 after passing only identity
authentication.

250
 • The user can access network resources permitted by ACL 3001 after passing both identity
authentication and security check.
# After the user passes identity authentication and security check, use the following command to
display information about the portal user.
[Switch] display portal user interface vlan-interface 100
Total portal users: 1
Username: abc
Portal server: newpt
State: Online
VPN instance: N/A
MAC IP VLAN Interface
0015-e9a6-7cfe 2.2.2.2 100 Vlan-interface100
Authorization information:
DHCP IP pool: N/A
User profile: N/A
Session group profile: N/A
ACL: 3001
Inbound CAR: N/A
Outbound CAR: N/A

Example: Configuring extended re-DHCP portal

authentication
Network configuration
As shown in Figure 68, the host is directly connected to the switch (the access device). The host
obtains an IP address through the DHCP server. A portal server acts as both a portal authentication
server and a portal Web server. A RADIUS server acts as the authentication and accounting server.
Configure extended re-DHCP portal authentication. Before passing portal authentication, the host is
assigned a private IP address. After passing portal identity authentication, the host obtains a public
IP address and accepts security check. If the host fails the security check, it can access only subnet
192.168.0.0/24. After passing the security check, the host can access other network resources.
Figure 68 Network diagram

Portal server
192.168.0.111/24

Vlan-int100
20.20.20.1/24 Vlan-int2
10.0.0.1/24 sub 192.168.0.100/24 DHCP server
192.168.0.112/24

Host Switch
automatically obtains
an IP address
RADIUS server
192.168.0.113/24

Security policy server

192.168.0.114/24

251
Restrictions and guidelines
• For re-DHCP portal authentication, configure a public address pool (20.20.20.0/24) and a
private address pool (10.0.0.0/24) on the DHCP server. (Details not shown.)
• For re-DHCP portal authentication:
 The switch must be configured as a DHCP relay agent.
 The portal-enabled interface must be configured with a primary IP address (a public IP
address) and a secondary IP address (a private IP address).
For information about DHCP relay agent configuration, see Layer 3—IP Services Configuration
Guide.
• Make sure the IP address of the portal device added on the portal server is the public IP
address (20.20.20.1) of the switch's interface connecting the host. The private IP address range
for the IP address group associated with the portal device is the private subnet 10.0.0.0/24
where the host resides. The public IP address range for the IP address group is the public
subnet 20.20.20.0/24.
Prerequisites
• Configure IP addresses for the switch and servers as shown in Figure 68 and make sure the
host, switch, and servers can reach each other.
• Configure the RADIUS server correctly to provide authentication and accounting functions.
Procedure
1. Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<Switch> system-view
[Switch] radius scheme rs1
# Specify the primary authentication server and primary accounting server, and configure the
keys for communication with the servers.
[Switch-radius-rs1] primary authentication 192.168.0.113
[Switch-radius-rs1] primary accounting 192.168.0.113
[Switch-radius-rs1] key accounting simple radius
[Switch-radius-rs1] key authentication simple radius
[Switch-radius-rs1] user-name-format without-domain
# Enable RADIUS session control.
[Switch] radius session-control enable
# Specify a session-control client with IP address 192.168.0.113 and shared key 12345 in
plaintext form.
[Switch] radius session-control client ip 192.168.0.113 key simple 12345
2. Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[Switch] domain dm1
# Configure AAA methods for the ISP domain.
[Switch-isp-dm1] authentication portal radius-scheme rs1
[Switch-isp-dm1] authorization portal radius-scheme rs1
[Switch-isp-dm1] accounting portal radius-scheme rs1
[Switch-isp-dm1] quit
# Configure domain dm1 as the default ISP domain. If a user enters the username without the
ISP domain name at login, the authentication and accounting methods of the default domain
are used for the user.
[Switch] domain default enable dm1

252
 3. Configure ACL 3000 as the isolation ACL and ACL 3001 as the security ACL.
[Switch] acl advanced 3000
[Switch-acl-ipv4-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[Switch-acl-ipv4-adv-3000] rule deny ip
[Switch-acl-ipv4-adv-3000] quit
[Switch] acl advanced 3001
[Switch-acl-ipv4-adv-3001] rule permit ip
[Switch-acl-ipv4-adv-3001] quit

NOTE:
Make sure you specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL on the
security policy server.

4. Configure DHCP relay and authorized ARP:

# Configure DHCP relay.
[Switch] dhcp enable
[Switch] dhcp relay client-information record
[Switch] interface vlan-interface 100
[Switch–Vlan-interface100] ip address 20.20.20.1 255.255.255.0
[Switch–Vlan-interface100] ip address 10.0.0.1 255.255.255.0 sub
[Switch-Vlan-interface100] dhcp select relay
[Switch-Vlan-interface100] dhcp relay server-address 192.168.0.112
# Enable authorized ARP.
[Switch-Vlan-interface100] arp authorized enable
[Switch-Vlan-interface100] quit
5. Configure portal authentication:
# Configure a portal authentication server.
[Switch] portal server newpt
[Switch-portal-server-newpt] ip 192.168.0.111 key simple portal
[Switch-portal-server-newpt] port 50100
[Switch-portal-server-newpt] quit
# Configure a portal Web server.
[Switch] portal web-server newpt
[Switch-portal-websvr-newpt] url http://192.168.0.111:8080/portal
[Switch-portal-websvr-newpt] quit
# Enable re-DHCP portal authentication on VLAN-interface 100.
[Switch] interface vlan-interface 100
[Switch–Vlan-interface100] portal enable method redhcp
# Specify portal Web server newpt on VLAN-interface 100.
[Switch–Vlan-interface100] portal apply web-server newpt
# Configure the BAS-IP as 20.20.20.1 for portal packets sent from VLAN-interface 100 to the
portal authentication server.
[Switch–Vlan-interface100] portal bas-ip 20.20.20.1
[Switch–Vlan-interface100] quit

Verifying the configuration

# Verify that the portal configuration has taken effect.
[Switch] display portal interface vlan-interface 100
Portal information of Vlan-interface100

253
 NAS-ID profile: Not configured
Authorization : Strict checking
ACL : Disabled
User profile : Disabled
Dual stack : Disabled
Max users : Not configured
IPv4:
Portal status: Enabled
Portal authentication method: Redhcp
Portal web server: newpt
Portal mac-trigger-server: Not configured
Authentication domain: Not configured
User-dhcp-only: Disabled
Pre-auth IP pool: Not configured
Max users: Not configured
Bas-ip: 20.20.20.1
User detection: Not configured
Action for server detection:
Server type Server name Action
-- -- --
Layer3 source network:
IP address Mask

Destination authenticate subnet:

IP address Mask
IPv6:
Portal status: Disabled
Portal authentication method: Disabled
Portal web server: Not configured
Portal mac-trigger-server: Not configured
Authentication domain: Not configured
User-dhcp-only: Disabled
Pre-auth IP pool: Not configured
Max users: Not configured
Bas-ipv6: Not configured
User detection: Not configured
Action for server detection:
Server type Server name Action
-- -- --
Layer3 source network:
IP address Prefix length

Destination authenticate subnet:

IP address Prefix length

Before passing portal authentication, a user that uses the iNode client can access only the
authentication page http://192.168.0.111:8080/portal. All Web requests from the user will be
redirected to the authentication page.
• The user can access the resources permitted by ACL 3000 after passing only identity
authentication.

254
 • The user can access network resources permitted by ACL 3001 after passing both identity
authentication and security check.
# After the user passes identity authentication and security check, use the following command to
display information about the portal user.
[Switch] display portal user interface vlan-interface 100
Total portal users: 1
Username: abc
Portal server: newpt
State: Online
VPN instance: N/A
MAC IP VLAN Interface
0015-e9a6-7cfe 20.20.20.2 100 Vlan-interface100
Authorization information:
DHCP IP pool: N/A
User profile: N/A
Session group profile: N/A
ACL number: 3001 (active)
Inbound CAR: N/A
Outbound CAR: N/A

Example: Configuring extended cross-subnet portal

authentication
Network configuration
As shown in Figure 69, Switch A supports portal authentication. The host accesses Switch A through
Switch B. A portal server acts as both a portal authentication server and a portal Web server. A
RADIUS server acts as the authentication and accounting server.
Configure Switch A for extended cross-subnet portal authentication. Before passing portal
authentication, the host can access only the portal server. After passing portal identity authentication,
the host accepts security check. If the host fails the security check it can access only the subnet
192.168.0.0/24. After passing the security check, the host can access other network resources.
Figure 69 Network diagram

Switch A
Vlan-int2 Portal server
192.168.0.100/24 192.168.0.111/24

Vlan-int4
20.20.20.1/24
Vlan-int4
Vlan-int2 20.20.20.2/24 RADIUS server
8.8.8.1/24 192.168.0.112/24

Host Switch B
8.8.8.2/24
Security policy server
192.168.0.113/24

255
Restrictions and guidelines
Make sure the IP address of the portal device added on the portal server is the IP address
(20.20.20.1) of the switch's interface connecting the host. The IP address group associated with the
portal device is the subnet of the host (8.8.8.0/24).
Prerequisites
• Configure IP addresses for the switch and servers as shown in Figure 69 and make sure the
host, switch, and servers can reach each other.
• Configure the RADIUS server correctly to provide authentication and accounting functions.
Procedure
1. Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<SwitchA> system-view
[SwitchA] radius scheme rs1
# Specify the primary authentication server and primary accounting server, and configure the
keys for communication with the servers.
[SwitchA-radius-rs1] primary authentication 192.168.0.112
[SwitchA-radius-rs1] primary accounting 192.168.0.112
[SwitchA-radius-rs1] key accounting simple radius
[SwitchA-radius-rs1] key authentication simple radius
[SwitchA-radius-rs1] user-name-format without-domain
# Enable RADIUS session control.
[SwitchA] radius session-control enable
# Specify a session-control client with IP address 192.168.0.112 and shared key 12345 in
plaintext form.
[SwitchA] radius session-control client ip 192.168.0.112 key simple 12345
2. Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[SwitchA] domain dm1
# Configure AAA methods for the ISP domain.
[SwitchA-isp-dm1] authentication portal radius-scheme rs1
[SwitchA-isp-dm1] authorization portal radius-scheme rs1
[SwitchA-isp-dm1] accounting portal radius-scheme rs1
[SwitchA-isp-dm1] quit
# Configure domain dm1 as the default ISP domain. If a user enters the username without the
ISP domain name at login, the authentication and accounting methods of the default domain
are used for the user.
[SwitchA] domain default enable dm1
3. Configure ACL 3000 as the isolation ACL and ACL 3001 as the security ACL.
[SwitchA] acl advanced 3000
[SwitchA-acl-ipv4-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[SwitchA-acl-ipv4-adv-3000] rule deny ip
[SwitchA-acl-ipv4-adv-3000] quit
[SwitchA] acl advanced 3001
[SwitchA-acl-ipv4-adv-3001] rule permit ip
[SwitchA-acl-ipv4-adv-3001] quit

256
 NOTE:
Make sure you specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL on the
security policy server.

4. Configure portal authentication:

# Configure a portal authentication server.
[SwitchA] portal server newpt
[SwitchA-portal-server-newpt] ip 192.168.0.111 key simple portal
[SwitchA-portal-server-newpt] port 50100
[SwitchA-portal-server-newpt] quit
# Configure a portal Web server.
[SwitchA] portal web-server newpt
[SwitchA-portal-websvr-newpt] url http://192.168.0.111:8080/portal
[SwitchA-portal-websvr-newpt] quit
# Enable cross-subnet portal authentication on VLAN-interface 4.
[SwitchA] interface vlan-interface 4
[SwitchA–Vlan-interface4] portal enable method layer3
# Specify portal Web server newpt on VLAN-interface 4.
[SwitchA–Vlan-interface4] portal apply web-server newpt
# Configure the BAS-IP as 20.20.20.1 for portal packets sent from VLAN-interface 4 to the
portal authentication server.
[SwitchA–Vlan-interface4] portal bas-ip 20.20.20.1
[SwitchA–Vlan-interface4] quit

Verifying the configuration

# Verify that the portal configuration has taken effect.
[SwitchA] display portal interface vlan-interface 4
Portal information of Vlan-interface4
NAS-ID profile: Not configured
Authorization : Strict checking
ACL : Disabled
User profile : Disabled
Dual stack : Disabled
Max users : Not configured
IPv4:
Portal status: Enabled
Portal authentication method: Layer3
Portal web server: newpt
Portal mac-trigger-server: Not configured
Authentication domain: Not configured
User-dhcp-only: Disabled
Pre-auth IP pool: Not configured
Max users: Not configured
Bas-ip: 20.20.20.1
User detection: Not configured
Action for server detection:
Server type Server name Action
-- -- --
Layer3 source network:

257
 IP address Mask

Destination authenticate subnet:

IP address Mask
IPv6:
Portal status: Disabled
Portal authentication method: Disabled
Portal web server: Not configured
Portal mac-trigger-server: Not configured
Authentication domain: Not configured
User-dhcp-only: Disabled
Pre-auth IP pool: Not configured
Max users: Not configured
Bas-ip: Not configured
User detection: Not configured
Action for server detection:
Server type Server name Action
-- -- --
Layer3 source network:
IP address Prefix length

Destination authenticate subnet:

IP address Prefix length

Before passing portal authentication, a user that uses the iNode client can access only the
authentication page http://192.168.0.111:8080/portal. All Web requests from the user will be
redirected to the authentication page.
• The user can access the resources permitted by ACL 3000 after passing only identity
authentication.
• The user can access network resources permitted by ACL 3001 after passing both identity
authentication and security check.
# After the user passes identity authentication and security check, use the following command to
display information about the portal user.
[SwitchA] display portal user interface vlan-interface 4
Total portal users: 1
Username: abc
Portal server: newpt
State: Online
VPN instance: N/A
MAC IP VLAN Interface
0015-e9a6-7cfe 8.8.8.2 4 Vlan-interface4
Authorization information:
DHCP IP pool: N/A
User profile: N/A
Session group profile: N/A
ACL number: 3001 (active)
Inbound CAR: N/A
Outbound CAR: N/A

258
Example: Configuring portal server detection and portal user
synchronization
Network configuration
As shown in Figure 70, the host is directly connected to the switch (the access device). The host is
assigned a public IP address either manually or through DHCP. An IMC server acts as both a portal
authentication server and a portal Web server. A RADIUS server acts as the authentication and
accounting server. In this example, the IMC server runs IMC 7.1 (E0303) and IMC UAM 7.1 (E0304).
• Configure direct portal authentication on the switch, so the host can access only the portal
server before passing the authentication and access other network resources after passing the
authentication.
• Configure the switch to detect the reachability state of the portal authentication server, send log
messages upon state changes, and disable portal authentication when the authentication
server is unreachable.
• Configure the switch to synchronize portal user information with the portal server periodically.
Figure 70 Network diagram

Portal server
Vlan-int100 Vlan-int2 192.168.0.111/24
2.2.2.1/24 192.168.0.100/24

Host Switch
2.2.2.2/24
Gateway: 2.2.2.1/24

RADIUS server
192.168.0.112/24

Prerequisites
• Configure IP addresses for the switch and servers as shown in Figure 70 and make sure the
host, switch, and servers can reach each other.
• Configure the RADIUS server correctly to provide authentication and accounting functions.
Configuring the portal server
1. Configure the portal server:
a. Log in to IMC and click the User tab.
b. Select User Access Policy > Portal Service > Server from the navigation tree to open the
portal server configuration page, as shown in Figure 71.
c. Configure the portal server parameters as needed.
This example uses the default settings.
d. Click OK.

259
 Figure 71 Portal server configuration

2. Configure the IP address group:

a. Select User Access Policy > Portal Service > IP Group from the navigation tree to open
the portal IP address group configuration page.
b. Click Add to open the page as shown in Figure 72.
c. Enter the IP group name.
d. Enter the start IP address and end IP address of the IP group.
Make sure the host IP address is in the IP group.
e. Select a service group.
This example uses the default group Ungrouped.
f. Select Normal from the Action list.
g. Click OK.

260
 Figure 72 Adding an IP address group

3. Add a portal device:

a. Select User Access Policy > Portal Service > Device from the navigation tree to open the
portal device configuration page.
b. Click Add to open the page as shown in Figure 73.
c. Enter device name NAS.
d. Enter the IP address of the switch's interface connected to the host.
e. Set whether to support the portal server heartbeat and user heartbeat functions.
In this example, select Yes for both Support Server Heartbeat and Support User
Heartbeat.
f. Enter the key, which must be the same as that configured on the switch.
g. Select Directly Connected from the Access Method list.
h. Use the default settings for other parameters.
i. Click OK.
Figure 73 Adding a portal device

4. Associate the portal device with the IP address group:

a. As shown in Figure 74, click the Port Group Information Management icon for device
NAS to open the port group configuration page.
b. Click Add to open the page as shown in Figure 75.
c. Enter the port group name.

261
 d. Select the configured IP address group.
The IP address used by the user to access the network must be within this IP address
group.
e. Use the default settings for other parameters.
f. Click OK.
Figure 74 Device list

Figure 75 Adding a port group

Configuring the switch

1. Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<Switch> system-view
[Switch] radius scheme rs1
# Specify the primary authentication server and primary accounting server, and configure the
keys for communication with the servers.
[Switch-radius-rs1] primary authentication 192.168.0.112
[Switch-radius-rs1] primary accounting 192.168.0.112
[Switch-radius-rs1] key authentication simple radius
[Switch-radius-rs1] key accounting simple radius

262
 # Exclude the ISP domain name from the username sent to the RADIUS server.
[Switch-radius-rs1] user-name-format without-domain
[Switch-radius-rs1] quit
# Enable RADIUS session control.
[Switch] radius session-control enable
2. Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[Switch] domain dm1
# Configure AAA methods for the ISP domain.
[Switch-isp-dm1] authentication portal radius-scheme rs1
[Switch-isp-dm1] authorization portal radius-scheme rs1
[Switch-isp-dm1] accounting portal radius-scheme rs1
[Switch-isp-dm1] quit
# Configure domain dm1 as the default ISP domain. If a user enters the username without the
ISP domain name at login, the authentication and accounting methods of the default domain
are used for the user.
[Switch] domain default enable dm1
3. Configure portal authentication:
# Configure a portal authentication server.
[Switch] portal server newpt
[Switch-portal-server-newpt] ip 192.168.0.111 key simple portal
[Switch-portal-server-newpt] port 50100
# Configure reachability detection of the portal authentication server: set the server detection
interval to 40 seconds, and send log messages upon reachability status changes.
[Switch-portal-server-newpt] server-detect timeout 40 log

NOTE:
The value of timeout must be greater than or equal to the portal server heartbeat interval.

# Configure portal user synchronization with the portal authentication server, and set the
synchronization detection interval to 600 seconds.
[Switch-portal-server-newpt] user-sync timeout 600
[Switch-portal-server-newpt] quit

NOTE:
The value of timeout must be greater than or equal to the portal user heartbeat interval.

# Configure a portal Web server.

[Switch] portal web-server newpt
[Switch-portal-websvr-newpt] url http://192.168.0.111:8080/portal
[Switch-portal-websvr-newpt] quit
# Enable direct portal authentication on VLAN-interface 100.
[Switch] interface vlan-interface 100
[Switch–Vlan-interface100] portal enable method direct
# Enable portal fail-permit for the portal authentication server newpt.
[Switch–Vlan-interface100] portal fail-permit server newpt
# Specify portal Web server newpt on VLAN-interface 100.
[Switch–Vlan-interface100] portal apply web-server newpt

263
 # Configure the BAS-IP as 2.2.2.1 for portal packets sent from VLAN-interface 100 to the portal
authentication server.
[Switch–Vlan-interface100] portal bas-ip 2.2.2.1
[Switch–Vlan-interface100] quit

Verifying the configuration

# Use the following command to display information about the portal authentication server.
[Switch] display portal server newpt
Portal server: newpt
Type : IMC
IP : 192.168.0.111
VPN instance : Not configured
Port : 50100
Server Detection : Timeout 40s Action: log
User synchronization : Timeout 600s
Status : Up

The Up status of the portal authentication server indicates that the portal authentication server is
reachable. If the access device detects that the portal authentication server is unreachable, the
Status field in the command output displays Down. The access device generates a server
unreachable log "Portal server newpt turns down from up." and disables portal authentication on the
access interface, so the host can access the external network without authentication.

Example: Configuring direct portal authentication using a

local portal Web service
Network configuration
As shown in Figure 76, the host is directly connected to the switch (the access device). The host is
assigned a public IP address either manually or through DHCP. The switch acts as both a portal
authentication server and a portal Web server. A RADIUS server acts as the authentication and
accounting server.
Configure direct portal authentication on the switch. Before a user passes portal authentication, the
user can access only the portal Web server. After passing portal authentication, the user can access
other network resources.
Figure 76 Network diagram
Vlan-int100 Vlan-int2
2.2.2.1/24 192.168.0.100/24

Host Switch
RADIUS server
2.2.2.2/24 192.168.0.112/24
Gateway: 2.2.2.1

Prerequisites
• Configure IP addresses for the host, switch, and server as shown in Figure 76 and make sure
they can reach each other.
• Configure the RADIUS server correctly to provide authentication and accounting functions.
Procedure
1. Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<Switch> system-view

264
 [Switch] radius scheme rs1
# Specify the primary authentication server and primary accounting server, and configure the
keys for communication with the servers.
[Switch-radius-rs1] primary authentication 192.168.0.112
[Switch-radius-rs1] primary accounting 192.168.0.112
[Switch-radius-rs1] key authentication simple radius
[Switch-radius-rs1] key accounting simple radius
# Exclude the ISP domain name from the username sent to the RADIUS server.
[Switch-radius-rs1] user-name-format without-domain
[Switch-radius-rs1] quit
# Enable RADIUS session control.
[Switch] radius session-control enable
2. Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[Switch] domain dm1
# Configure AAA methods for the ISP domain.
[Switch-isp-dm1] authentication portal radius-scheme rs1
[Switch-isp-dm1] authorization portal radius-scheme rs1
[Switch-isp-dm1] accounting portal radius-scheme rs1
[Switch-isp-dm1] quit
# Configure domain dm1 as the default ISP domain. If a user enters the username without the
ISP domain name at login, the authentication and accounting methods of the default domain
are used for the user.
[Switch] domain default enable dm1
3. Configure portal authentication:
# Configure a portal Web server named newpt and specify http://2.2.2.1:2331/portal as the
URL of the portal Web server. The IP address in the URL must be the IP address of a Layer 3
interface reachable to portal clients or a loopback interface (except 127.0.0.1) on the device.
[Switch] portal web-server newpt
[Switch-portal-websvr-newpt] url http://2.2.2.1:2331/portal
[Switch-portal-websvr-newpt] quit
# Enable direct portal authentication on VLAN-interface 100.
[Switch] interface vlan-interface 100
[Switch–Vlan-interface100] portal enable method direct
# Specify portal Web server newpt on VLAN-interface 100.
[Switch–Vlan-interface100] portal apply web-server newpt
[Switch–Vlan-interface100] quit
# Create an HTTP-based local portal Web service and enter its view.
[Switch] portal local-web-server http
# Specify file defaultfile.zip as the default authentication page file for the local portal Web
service. (Make sure the file exists under the root directory of the switch.)
[Switch–portal-local-websvr-http] default-logon-page defaultfile.zip
# Set the HTTP listening port number to 2331 for the local portal Web service.
[Switch–portal-local-webserver-http] tcp-port 2331
[Switch–portal-local-websvr-http] quit

Verifying the configuration

# Verify that the portal configuration has taken effect.

265
[Switch] display portal interface vlan-interface 100
Portal information of Vlan-interface 100
Authorization Strict checking
ACL Disabled
User profile Disabled
IPv4:
Portal status: Enabled
Portal authentication method: Direct
Portal web server: newpt
Portal mac-trigger-server: Not configured
Authentication domain: Not configured
User-dhcp-only: Disabled
Pre-auth IP pool: Not configured
Max users: Not configured
Bas-ip: Not configured
User detection: Not configured
Action for server detection:
Server type Server name Action
-- -- --
Layer3 source network:
IP address Mask

Destination authenticate subnet:

IP address Mask
IPv6:
Portal status: Disabled
Portal authentication method: Disabled
Portal web server: Not configured
Portal mac-trigger-server: Not configured
Authentication domain: Not configured
User-dhcp-only: Disabled
Pre-auth IP pool: Not configured
Max users: Not configured
Bas-ipv6: Not configured
User detection: Not configured
Action for server detection:
Server type Server name Action
-- -- --
Layer3 source network:
IP address Prefix length

Destination authenticate subnet:

IP address Prefix length

A user can perform portal authentication through a Web page. Before passing the authentication, the
user can access only the authentication page http://2.2.2.1:2331/portal and all Web requests will be
redirected to the authentication page. After passing the authentication, the user can access other
network resources.
# After the user passes authentication, use the following command to display information about the
portal user.

266
 [Switch] display portal user interface vlan-interface 100
Total portal users: 1
Username: abc
Portal server: newpt
State: Online
VPN instance: N/A
MAC IP VLAN Interface
0015-e9a6-7cfe 2.2.2.2 100 Vlan-interface100
Authorization information:
DHCP IP pool: N/A
User profile: N/A
Session group profile: N/A
ACL number: N/A
Inbound CAR: N/A
Outbound CAR: N/A

Troubleshooting portal
No portal authentication page is pushed for users
Symptom
When a user is redirected to the IMC portal authentication server, no portal authentication page or
error message is prompted for the user. The login page is blank.
Analysis
The key configured on the portal access device and that configured on the portal authentication
server are inconsistent. As a result, packet verification fails, and the portal authentication server
refuses to push the authentication page.
Solution
Use the display this command in portal authentication server view on the access device to
check whether a key is configured for the portal authentication server.
• If no key is configured, configure the right key.
• If a key is configured, use the ip or ipv6 command in the portal authentication server view to
correct the key, or correct the key configured for the access device on the portal authentication
server.

Cannot log out portal users on the access device

Symptom
You cannot use the portal delete-user command on the access device to log out a portal user,
but the portal user can log out by clicking the Disconnect button on the portal authentication client.
Analysis
When you execute the portal delete-user command on the access device to log out a user,
the access device sends an unsolicited logout notification message to the portal authentication
server. The destination port number in the logout notification is the listening port number of the portal
authentication server configured on the access device. If this listening port number is not the actual
listening port number configured on the server, the server cannot receive the notification. As a result,
the server does not log out the user.

267
 When a user uses the Disconnect button on the authentication client to log out, the portal
authentication server sends an unsolicited logout request message to the access device. The
access device uses the source port in the logout request as the destination port in the logout ACK
message. As a result, the portal authentication server can definitely receive the logout ACK message
and log out the user.
Solution
1. Use the display portal server command to display the listening port of the portal
authentication server configured on the access device.
2. Use the portal server command in system view to change the listening port number to the
actual listening port of the portal authentication server.

Cannot log out portal users on the RADIUS server

Symptom
The access device uses the IMC server as the RADIUS server to perform identity authentication for
portal users. You cannot log out the portal users on the RADIUS server.
Analysis
The IMC server uses session control packets to send disconnection requests to the access device.
On the access device, the listening UDP port for session control packets is disabled by default.
Therefore, the access device cannot receive the portal user logout requests from the RADIUS
server.
Solution
On the access device, execute the radius session-control enable command in system
view to enable the RADIUS session control function.

Users logged out by the access device still exist on the portal
authentication server
Symptom
After you log out a portal user on the access device, the user still exists on the portal authentication
server.
Analysis
When you execute the portal delete-user command on the access device to log out a user,
the access device sends an unsolicited logout notification to the portal authentication server. If the
BAS-IP or BAS-IPv6 address carried in the logout notification is different from the portal device IP
address specified on the portal authentication server, the portal authentication server discards the
logout notification. When sending of the logout notifications times out, the access device logs out the
user. However, the portal authentication server does not receive the logout notification successfully,
and therefore it regards the user is still online.
Solution
Configure the BAS-IP or BAS-IPv6 attribute on the interface enabled with portal authentication.
Make sure the attribute value is the same as the portal device IP address specified on the portal
authentication server.

268
Re-DHCP portal authenticated users cannot log in
successfully
Symptom
The device performs re-DHCP portal authentication for users. A user enters the correct username
and password, and the client successfully obtains the private and public IP addresses. However, the
authentication result for the user is failure.
Analysis
When the access device detects that the client IP address is changed, it sends an unsolicited portal
packet to notify of the IP change to the portal authentication server. The portal authentication server
notifies of the authentication success only after it receives the IP change notification from both the
access device and the client.
If the BAS-IP or BAS-IPv6 address carried in the portal notification packet is different from the portal
device IP address specified on the portal authentication server, the portal authentication server
discards the portal notification packet. As a result, the portal authentication server considers that the
user has failed the authentication.
Solution
Configure the BAS-IP or BAS-IPv6 attribute on the interface enabled with portal authentication.
Make sure the attribute value is the same as the portal device IP address specified on the portal
authentication server.

269
Configuring Web authentication
About Web authentication
Web authentication is deployed on Layer 2 Ethernet interfaces of the access device to control user
access to networks. The access device redirects unauthenticated users to the specified website. The
users can access the resources on the website without authentication. If the users want to access
other network resources, they must pass authentication.

Advantages of Web authentication

Web authentication has the following advantages:
• Allows users to perform authentication through webpages without installing client software.
• Provides ISPs with diversified management choices and extended functions. For example, the
ISPs can place advertisements, provide community services, and publish information on the
authentication page.

Web authentication system

A typical Web authentication system consists of four basic components: authentication client, access
device, local portal Web server, and AAA server.
Figure 77 Web authentication system using the local portal server

Authentication client Access device

AAA server
Local portal Web server

Authentication client
An authentication client is a Web browser that runs HTTP or HTTPS.
Access device
An access device has the following functions:
• Redirects all user HTTP or HTTPS requests that do not match authentication-free rules to the
Web authentication page before authentication.
• Interacts with the AAA server to complete authentication, authorization, and accounting. For
more information about AAA, see "Configuring AAA."
• Allows users that pass authentication to access authorized network resources.
Local portal Web server
The access device acts as the local portal Web server. The local portal Web server pushes the Web
authentication page to authentication clients and obtains user authentication information (username
and password).
AAA server
An AAA server interacts with the access device to implement user authentication, authorization, and
accounting. A RADIUS server can perform authentication, authorization, and accounting for Web
authentication users. An LDAP server can perform authentication for Web authentication users.

270
Web authentication process
Figure 78 Web authentication process
Authentication Authentication
Access device
client /accounting server

1) Initiate a connection

2) RADIUS authentication

3) Notify the user of

login success

The Web authentication process is as follows:

1. An unauthenticated user sends an HTTP or HTTPS request. When the access device receives
the HTTP or HTTPS request on a Layer 2 Ethernet interface enabled with Web authentication,
it redirects the request to the Web authentication page. The user enters the username and
password on the Web authentication page.
If the user requests the Web authentication page or free Web resources, the access device
permits the request. No Web authentication is performed.
2. The access device and the AAA server exchange RADIUS packets to authenticate the user.
3. If the user passes RADIUS authentication, the local portal Web server pushes a login success
page to the authentication client.
If the user fails RADIUS authentication, the local portal Web server pushes a login failure page
to the authentication client.

Web authentication support for VLAN assignment

Authorization VLAN
Web authentication uses VLANs authorized by the AAA server or the access device to control
network resource access of authenticated users.
After a user passes Web authentication, the AAA server or the access device authorizes the user to
access a VLAN. If the authorization VLAN does not exist, the access device first creates the VLAN
and then assigns the user access interface as an untagged member to the VLAN. If the authorization
VLAN already exists, the access device directly assigns the user access interface as an untagged
member to the VLAN. Then, the user can access resources in the authorization VLAN.
Table 25 describes the way the access device handles authorization VLANs for Web authenticated
users.
Table 25 VLAN manipulation

Port type VLAN manipulation

• Access port The device assigns the port to the first authenticated user's
• Trunk port authorization VLAN. The authorization VLAN becomes the PVID. All
Web authentication users on the port must be assigned the same
• Hybrid port with authorization VLAN. If a different authorization VLAN is assigned to a
MAC-based-VLAN disabled subsequent user, the user cannot pass Web authentication.

The device maps the MAC address of each user to its own
Hybrid port with MAC-based VLAN
authorization VLAN regardless of whether the port is a tagged
enabled
member. The PVID of the port does not change.

271
Auth-Fail VLAN
An Auth-Fail VLAN is a VLAN assigned to users who fail authentication. The Auth-Fail VLAN
provides network resources such as the patch server, virus definitions server, client software server,
and anti-virus software server to the users. The users can use these resources to upgrade their client
software or other programs.
Web authentication supports Auth-Fail VLAN on an interface that performs MAC-based access
control. If a user on the interface fails authentication, the access devices creates a MAC VLAN entry
based on the MAC address of the user and adds the user to the Auth-Fail VLAN. Then, the user can
access the portal-free IP resources in the Auth-Fail VLAN. All HTTP or HTTPS requests to
non-portal-free IP resources will be redirected to the authentication page. If the user still fails
authentication, the interface remains in the Auth-Fail VLAN. If the user passes authentication, the
access device removes the interface from the Auth-Fail VLAN and assigns the interface to a VLAN
as follows:
• If the authentication server assigns an authorization VLAN to the user, the access device
assigns the interface to the authorization VLAN.
• If the authentication server does not assign an authorization VLAN to the user, the access
device assigns the interface to the default VLAN.

Web authentication support for authorization ACLs

Web authentication uses ACLs authorized by the AAA server or the access device to control user
access to network resources and limit user access rights. When a user passes authentication, the
AAA server and the access device assigns an authorization ACL to the access interface of the user.
The access device filters traffic from the user on the access interface according to the authorized
ACL.
You must configure the authorization ACLs on the access device if you specify authorization ACLs
on the authentication server.
To change the access control criteria for the user, you can specify a different authorization ACL on
the authentication server or change rules in the authorization ACL on the access device.
The device supports the following types of authorization ACLs:
• Basic ACLs (ACL 2000 to ACL 2999).
• Advanced ACLs (ACL 3000 to ACL 3999).
• Layer 2 ACLs (ACL 4000 to ACL 4999).
For an authorization ACL to take effect, make sure the ACL exists and has ACL rules excluding rules
configured with the counting, established, fragment, source-mac, or logging keyword.
For more information about ACL rules, see ACL commands in ACL and QoS Command Reference.

Restrictions and guidelines: Web authentication

configuration
To access the resources in the authorization or Auth-Fail VLAN, a user must update the IP address
of the client after being assigned to the authorization or Auth-Fail VLAN.
As a best practice, perform Web authentication on users directly connected to the device. As shown
in Figure 79, if you enable Web authentication on Port B to authenticate non-directly connected
users (the hosts), you must follow these restrictions and guidelines:
• If the RADIUS server assigns an authorization VLAN to the users, make sure the following
conditions are met:
 The link between Device A and Device B is a trunk link.
 The PVIDs of Port A1 and Port B are the same as the authorization VLAN ID.

272
 • If the RADIUS server does not assign an authorization VLAN to the users, make sure the PVIDs
of Port A1 and Port B are the same.
Figure 79 Web authentication for non-directly connected users

RADIUS server

Host A

Port A1 Port A2 Port B

Host B Device A Device B

Host C

Web authentication task at a glance

To configure Web authentication, perform the following tasks:
1. Configuring a Web authentication server
2. Configuring a local portal service
3. Enabling Web authentication
4. (Optional.) Specifying a Web authentication domain
5. (Optional.) Setting the redirection wait time
6. (Optional.) Configuring a Web authentication-free subnet
7. (Optional.) Setting the maximum number of Web authentication users
8. (Optional.) Configuring online Web authentication user detection
9. (Optional.) Configuring an Auth-Fail VLAN
10. (Optional.) Configuring Web authentication to support Web proxy

Prerequisites for Web authentication

The device supports two methods for Web authentication, which are local authentication and
RADIUS authentication.
To use the RADIUS authentication method, you must complete the following tasks:
• Install a RADIUS server and configure the RADIUS server properly.
• Make sure the authentication client, the access device, and the RADIUS server can reach each
other.
• Configure user accounts on the RADIUS server and configure the RADIUS client information on
the access device.
To use the local authentication method, you must configure local users on the access device.
For more information about RADIUS clients and local users, see "Configuring AAA."

273
Configuring a Web authentication server
Restrictions and guidelines
Specify the IP address of a Layer 3 interface on the device that is routable to the Web client as the
listening IP address of the Web authentication server. As a best practice, use the IP address of a
loopback interface rather than that of a Layer 3 interface. A loopback interface has the following
advantages:
• The status of a loopback interface is stable. There will be no authentication page access
failures caused by interface failures.
• A loopback interface does not forward received packets to any networks, avoiding impact on
system performances when there are many network access requests.
Procedure
1. Enter system view.
system-view
2. Create a Web authentication server and enter its view.
web-auth server server-name
3. Specify the IP address and port number of the Web authentication server.
ip ipv4-address port port-number
The port number of the Web authentication server must be the same as the listening port of the
local portal Web service.
4. Specify the redirection URL for the Web authentication server.
url url-string
The IP address and port number in the specified redirection URL must be the same as those of
the Web authentication server.
5. (Optional.) Add parameters to the redirection URL of the Web authentication server.
url-parameter parameter-name { original-url | source-address |
source-mac | value expression }
By default, no parameters are added to the redirection URL of a Web authentication server.

Configuring a local portal service

For information about the local portal service configuration, see "Configuring portal authentication."

Enabling Web authentication

Restrictions and guidelines
For Web authentication to operate correctly, do not enable port security or configure the port security
mode on the Layer 2 Ethernet interface enabled with Web authentication. For more information
about port security, see "Configuring port security."
The default HTTPS redirect listening port number on the device is 6654. To change the HTTPS
redirect listening port number, see HTTP redirect configuration in Layer 3—IP Services Configuration
Guide.
Procedure
1. Enter system view.
system-view

274
 2. Enter interface view.
interface interface-type interface-number
3. Enable Web authentication and specify the Web authentication server.
web-auth enable apply server server-name
By default, Web authentication is disabled.

Specifying a Web authentication domain

About this task
You can specify different authentication domains for Web authentication users on different interfaces.
After you specify a Web authentication domain on an interface, the device uses the authentication
domain for AAA of all Web authentication users on the interface, ignoring the domain names carried
in the usernames.
The device selects the authentication domain for a Web authentication user on an interface in this
order:
1. The authentication domain specified for the interface.
2. The authentication domain carried in the username.
3. The system default authentication domain.
4. The ISP domain configured to accommodate users assigned to nonexistent domains.
If the selected domain does not exist on the device, user authentication fails. For information about
ISP domains, see "Configuring AAA."
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Specify an authentication domain for Web authentication users on the interface.
web-auth domain domain-name
By default, no authentication domain is specified for Web authentication users.

Setting the redirection wait time

About this task
The redirection wait time determines the length of time that the device waits to redirect a user to the
specified webpage after the user passes Web authentication.
You need to change the redirection wait time in some scenarios, for example, when a user needs to
update the client IP address after passing Web authentication. To ensure that the specified webpage
can be successfully opened, set the redirection wait time to be greater than the time that the user
takes to update the IP address of the client.
Procedure
1. Enter system view.
system-view
2. Enter Web authentication server view.
web-auth server server-name
3. Set the redirection wait time.

275
 redirect-wait-time period
By default, the redirection wait time for authenticated users is 5 seconds.

Configuring a Web authentication-free subnet

About this task
You can configure a Web authentication-free subnet so that users can freely access the network
resources in the subnet without being authenticated.
Restrictions and guidelines
As a best practice, do not configure the same address value for a Web authentication-free subnet
and a 802.1X free IP. Otherwise, when you cancel one of the configuration, the other configuration
does not take effect, either.
Procedure
1. Enter system view.
system-view
2. Configure a Web authentication-free subnet.
web-auth free-ip ip-address { mask-length | mask }

Setting the maximum number of Web

authentication users
Restrictions and guidelines
If the maximum number of online Web authentication users you set is less than that of the current
online Web authentication users, the limit can be set successfully and does not impact the online
Web authentication users. However, the system does not allow new Web authentication users to log
in until the number drops down below the limit.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Set the maximum number of Web authentication users on the interface.
web-auth max-user max-number
By default, the maximum number of Web authentication users is 1024.

Configuring online Web authentication user

detection
About this task
This feature enables the device to detect packets of an online user at the specified detection interval.
If no packet from the user is received within the interval, the device logs out the user and notifies the
RADIUS server to stop accounting for the user.

276
Restrictions and guidelines
To prevent the device from mistakenly logging out users, set the detection interval to be the same as
the aging time of MAC address entries.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable online Web authentication user detection.
web-auth offline-detect interval interval
By default, online Web authentication user detection is disabled.

Configuring an Auth-Fail VLAN

Restrictions and guidelines
To make the Auth-Fail VLAN take effect, you must also enable MAC-based VLAN on the interface,
and set the subnet of the Auth-Fail VLAN as the Web authentication-free subnet.
Because MAC-based VLAN takes effect only on Hybrid ports, Auth-Fail VLAN also takes effect only
on Hybrid ports.
If a VLAN is specified as the super VLAN, do not configure the VLAN as an Auth-Fail VLAN of an
interface. If a VLAN is specified as an Auth-Fail VLAN of an interface, do not configure the VLAN as
a super VLAN.
Do not delete the VLAN that has been configured as an Auth-Fail VLAN. To delete this VLAN, first
cancel the Auth-Fail VLAN configuration by using undo web-auth auth-fail vlan command.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Configure an Auth-Fail VLAN.
web-auth auth-fail vlan authfail-vlan-id
By default, no Auth-Fail VLAN is configured on an interface.

Configuring Web authentication to support Web

proxy
About this task
By default, proxied HTTP requests cannot trigger Web authentication but are silently dropped. To
allow such HTTP requests to trigger Web authentication, specify the port numbers of the Web proxy
servers on the device.
Restrictions and guidelines
If a user's browser uses the Web Proxy Auto-Discovery (WPAD) protocol to discover Web proxy
servers, you must perform the following tasks:

277
 • Add the port numbers of the Web proxy servers on the device.
• Configure authentication-free rules to allow user packets destined for the IP address of the
WPAD server to pass without authentication.
For Web authentication to support Web proxy:
• You must add the port numbers of the Web proxy servers on the device.
• Users must make sure their browsers that use a Web proxy server do not use the proxy server
for the listening IP address of the local portal Web server. Thus, HTTP packets that the Web
authentication user sends to the local portal Web server are not sent to the Web proxy server.
Procedure
1. Enter system view.
system-view
2. Add a Web proxy server port number.
web-auth proxy port port-number
You can execute this command multiple times to specify multiple port numbers of Web proxy
servers.

Display and maintenance commands for Web

authentication
Execute display commands in any view.

Task Command
Display Web authentication configuration display web-auth [ interface
information on interfaces. interface-type interface-number ]
Display Web authentication-free subnets. display web-auth free-ip
Display Web authentication server
display web-auth server [ server-name ]
information.

display web-auth user [ interface

Display Web authentication user
interface-type interface-number | slot
information.
slot-number ]

Web authentication configuration examples

Example: Configuring Web authentication by using the local
authentication method
Network configuration
As shown in Figure 80, the host is directly connected to the device through GigabitEthernet 1/0/1.
Configure Web authentication on GigabitEthernet 1/0/1, and use local authentication and
authorization for the users.
Configure the device to use HTTP to transfer the authentication data.

278
 Figure 80 Network diagram
Loop0
20.20.0.1/24

Vlan-int100
2.2.2.1/24
Internet
GE1/0/1
Host Device
2.2.2.2/24

Procedure
1. Assign IP addresses to the host and the device as shown in Figure 80, and make sure the host
and the device can reach each other. (Details not shown.)
2. Configure a local user:
# Create a local network access user named localuser.
<Device>system-view
[Device] local-user localuser class network
# Set the password to localpass in plaintext form for user localuser.
[Device-luser-network-localuser] password simple localpass
# Authorize the user to use LAN access services.
[Device-luser-network-localuser] service-type lan-access
[Device-luser-network-localuser] quit
3. Configure an ISP domain:
# Create an ISP domain named local.
[Device] domain local
# Configure the ISP domain to perform local authentication, authorization, and accounting for
LAN access users.
[Device-isp-local] authentication lan-access local
[Device-isp-local] authorization lan-access local
[Device-isp-local] accounting lan-access local
[Device-isp-local] quit
4. Configure a local portal Web service:
# Create an HTTP-based local portal Web service and enter its view.
[Device] portal local-web-server http
# Specify file defaultfile.zip as the default authentication page file for the local portal Web
service. (Make sure the authentication page file already exists in the root directory of the
storage medium on the device.)
[Device-portal-local-websvr-http] default-logon-page defaultfile.zip
# Specify the HTTP listening port number as 80 for the portal Web service.
[Device–portal-local-websvr-http] tcp-port 80
[Device-portal-local-websvr-http] quit
5. Configure Web authentication:
# Create a Web authentication server named user.
[Device] web-auth server user
# Configure the redirection URL for the Web authentication server as http://20.20.0.1/portal/.
[Device-web-auth-server-user] url http://20.20.0.1/portal/
# Specify 20.20.0.1 as the IP address and 80 as the port number for the Web authentication
server.
[Device-web-auth-server-user] ip 20.20.0.1 port 80

279
 [Device-web-auth-server-user] quit
# Specify ISP domain local as the Web authentication domain.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] web-auth domain local
# Enable Web authentication by using Web authentication server user.
[Device-GigabitEthernet1/0/1] web-auth enable apply server user
[Device-GigabitEthernet1/0/1] quit

Verifying the configuration

# Display online Web authentication user information after user localuser passes Web
authentication.
<Device> display web-auth user
Total online web-auth users: 1

User Name: localuser

MAC address: acf1-df6c-f9ad
Access interface: GigabitEthernet1/0/1
Initial VLAN: 100
Authorization VLAN: N/A
Authorization ACL ID: N/A
Authorization user profile: N/A

Example: Configuring Web authentication by using the

RADIUS authentication method
Network configuration
As shown in Figure 81, the host is directly connected to the device through GigabitEthernet 1/0/1.
Configure Web authentication on GigabitEthernet 1/0/1, and use a RADIUS server to perform
authentication and authorization for the users.
Configure the device to use HTTP to transfer the authentication data.
Figure 81 Network diagram
RADIUS server
192.168.0.112/24

Vlan-int2
192.168.0.100/24
Vlan-int100
2.2.2.1/24
Internet
GE1/0/1
Host Device
2.2.2.2/24
20.20.0.1/24
Loop0

280
Procedure
1. Configure the RADIUS server properly to provide authentication and accounting functions for
users. In this example, the username is configured as user1 on the RADIUS server. (Details not
shown.)
2. Create VLANs, assign IP addresses to the VLAN interfaces, and assign interfaces to the
VLANs. Make sure the host, the RADIUS server, and the device can reach each other. (Details
not shown.)
3. Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1.
<Device> system-view
[Device] radius scheme rs1
# Specify the primary authentication server and primary accounting server, and configure the
keys for communication with the servers.
[Device-radius-rs1] primary authentication 192.168.0.112
[Device-radius-rs1] primary accounting 192.168.0.112
[Device-radius-rs1] key authentication simple radius
[Device-radius-rs1] key accounting simple radius
# Exclude the ISP domain name from the username sent to the RADIUS server.
[Device-radius-rs1] user-name-format without-domain
[Device-radius-rs1] quit
4. Configure an authentication domain:
# Create an ISP domain named dm1.
[Device] domain dm1
# Configure AAA methods for the ISP domain
[Device-isp-dm1] authentication lan-access radius-scheme rs1
[Device-isp-dm1] authorization lan-access radius-scheme rs1
[Device-isp-dm1] accounting lan-access radius-scheme rs1
[Device-isp-dm1] quit
5. Configure a local portal Web service:
# Create an HTTP-based local portal Web service.
[Device] portal local-web-server http
# Specify the file defaultfile.zip as the default authentication page file for the local portal Web
service. (Make sure the authentication page file already exists in the root directory of the
storage medium on the device.)
[Device-portal-local-websvr-http] default-logon-page defaultfile.zip
# Specify 80 as the port number listened by the local portal Web service.
[Device–portal-local-websvr-http] tcp-port 80
[Device-portal-local-websvr-http] quit
6. Configure Web authentication:
# Create Web authentication server named user.
[Device] web-auth server user
# Specify http://20.20.0.1/portal/ as the redirection URL for the Web authentication server.
[Device-web-auth-server-user] url http://20.20.0.1/portal/
# Specify the IP address of the Web authentication server as 20.20.0.1 (the IP address of
Loopback 0) and the port number as 80.
[Device-web-auth-server-user] ip 20.20.0.1 port 80
[Device-web-auth-server-user] quit
# Specify domain dml as the Web authentication domain.

281
 [Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] web-auth domain dm1
# Enable Web authentication by using Web authentication server user.
[Device-GigabitEthernet1/0/1] web-auth enable apply server user
[Device-GigabitEthernet1/0/1] quit

Verifying the configuration

# Display Web authentication user information after user user1 passes Web authentication.
<Device> display web-auth user
Total online web-auth users: 1

User Name: user1

MAC address: acf1-df6c-f9ad
Access interface: GigabitEthernet1/0/1
Initial VLAN: 100
Authorization VLAN: N/A
Authorization ACL ID: N/A
Authorization user profile: N/A

Troubleshooting Web authentication

Failure to come online (local authentication interface using
the default ISP domain
Symptom
No authentication domain is specified for the local authentication interface. A user fails to pass Web
authentication to come online.
Analysis
If no Web authentication domain is specified, the system default ISP domain (domain system) is
used for Web authentication. The system default domain uses the local authentication method by
default. Using these default domain settings, the local authentication should have operated correctly.
The local authentication fails might because that the authentication method of the system default
domain is changed or the system default domain is changed.
Solution
To resolve the problem, perform the following tasks:
1. Use the display domain command to identify whether the AAA methods for Web users in
the system default domain are local.
2. If the AAA methods for Web users in the system default domain are not local, reconfigure the
AAA methods as local.

282
Configuring triple authentication
About triple authentication
Triple authentication enables an access port to perform Web, MAC, and 802.1X authentication. A
terminal can access the network if it passes one type of authentication. For more information about
802.1X authentication, MAC authentication, and Web authentication, see "Configuring 802.1X
authentication", "Configuring MAC authentication", and "Configuring Web authentication."

Typical network of triple authentication

Triple authentication is suitable for a LAN that comprises terminals that require different
authentication services, as shown in Figure 82. The triple authentication-enabled access port can
perform MAC authentication for the printer, 802.1X authentication for the PC installed with the
802.1X client, and Web authentication for the Web user.
Figure 82 Triple authentication network diagram

IP network AAA server

802.1X authentication Web authentication

MAC authentication

802.1X client Printer Web user

Triple authentication mechanism

The three types of authentication are triggered by different packets:
• The access port performs MAC authentication for a terminal when it receives an ARP or DHCP
broadcast packet from the terminal for the first time. If the terminal passes MAC authentication,
the terminal can access the network. If the MAC authentication fails, the access port performs
802.1X or Web authentication.
• The access port performs 802.1X authentication when it receives an EAP packet from an
802.1X client or a third-party client. If the unicast trigger feature of 802.1X is enabled on the
access port, any packet from the client can trigger an 802.1X authentication.
• The access port performs Web authentication when it receives an HTTP packet from a terminal.
If a terminal triggers different types of authentication, the authentications are processed at the same
time. The failure of one type of authentication does not affect the others. When a terminal passes
one type of authentication, the other types of authentication are processed as follows:
• If the terminal first passes MAC authentication, Web authentication is terminated immediately,
but 802.1X authentication will proceed. If the terminal also passes 802.1X authentication, the
802.1X authentication information will overwrite the MAC authentication information for the

283
 terminal. If the terminal fails 802.1X authentication, the user stays online as a MAC
authentication user, and only 802.1X authentication can be triggered again.
• If the terminal first passes 802.1X or Web authentication, the other types of authentication are
terminated immediately and cannot be triggered again.

Triple authentication support for VLAN assignment

Authorization VLAN
After a user passes authentication, the authentication server assigns an authorization VLAN to the
access port for the user. The user can then access the network resources in the authorized VLAN.
Authentication failure VLAN
The access port adds a user to an authentication failure VLAN configured on the port after the user
fails authentication.
• For an 802.1X authentication user—Adds the user to the Auth-Fail VLAN configured for 802.1X
authentication.
• For a Web authentication user—Adds the user to the Auth-Fail VLAN configured for Web
authentication.
• For a MAC authentication user—Adds the user to the guest VLAN configured for MAC
authentication.
The access port supports configuring all types of authentication failure VLANs at the same time. If a
user fails more than one type of authentication, the authentication failure VLAN of the user changes
as follows:
• If a user in the Web Auth-Fail VLAN fails MAC authentication, the user is moved to the MAC
authentication guest VLAN.
• If a user in the Web Auth-Fail VLAN or MAC authentication guest VLAN fails 802.1X
authentication, the user is moved to the 802.1X Auth-Fail VLAN.
• If a user in the 802.1X Auth-Fail VLAN fails MAC authentication or Web authentication, the user
is still in the 802.1X Auth-Fail VLAN.
Server-unreachable VLAN
If a user fails authentication due to the unreachable server, the access port adds the user to an
server-unreachable VLAN.
• For an 802.1X authentication user—Adds the user to the critical VLAN configured for 802.1X
authentication.
• For a Web authentication user—Adds the user to the Auth-Fail VLAN configured for Web
authentication.
• For a MAC authentication user—Adds the user to the critical VLAN configured for MAC
authentication.
The access port supports configuring all types of server-unreachable VLANs at the same time. A
user is added to the server-unreachable VLAN as follows:
• If the user does not undergo 802.1X authentication, the user is added to the server-unreachable
VLAN configured for the last authentication.
• If the user in the Web Auth-Fail VLAN or the MAC authentication critical VLAN also fails 802.1X
authentication, the user is added to the 802.1X authentication critical VLAN.

Triple authentication support for ACL authorization

After a user passes authentication, the authentication server assigns an authorization ACL to the
access port for the user. The access port uses the ACL to filter traffic for the user.

284
 To use ACL authorization, you must specify authorization ACLs on the authentication server and
configure the ACLs on the access device. You can change the user's access authorization by
changing the authorization ACL on the authentication server or changing rules of the authorization
ACL on the access device.

Triple authentication support for online user detection

You can configure the following features to detect the online status of users:
• Enable online user detection for Web authentication users.
• Enable the online user handshake or periodic online user reauthentication feature for 802.1X
users.
• Enable offline detection for MAC authentication users.

Restrictions and guidelines: Triple authentication

In triple authentication, 802.1X authentication must use the MAC-based access control method.
If Web authentication is enabled on a port, configure the subnets of the authentication failure VLANs
and server-unreachable VLANs of the port as Web authentication-free subnets. This ensures that an
authentication-failed user can access the authentication failure VLAN or server-unreachable VLAN.
Do not configure both Web authentication-free IPs and 802.1X free IPs. If you do so, only 802.1X
free IPs take effect.

Triple authentication tasks at a glance

Choose the following tasks as needed:
• Configure 802.1X authentication
For more information, see "Configuring 802.1X."
• Configure MAC authentication
For more information, see "Configuring MAC authentication."
• Configure Web authentication
For more information, see "Configuring Web authentication."

Triple authentication configuration examples

Example: Configuring basic triple authentication
Network configuration
As shown in Figure 83, the terminals are connected to the device to access the IP network.
Configure triple authentication on the device's Layer 2 interface that connects to the terminals. A
terminal passing one of the three authentication methods, 802.1X authentication, Web
authentication, and MAC authentication, can access the IP network.
• Assign IP addresses on subnet 192.168.1.0/24 to the terminals.
• Use the remote RADIUS server to perform authentication, authorization, and accounting.
Configure the device to send usernames carrying no ISP domain names to the RADIUS server.
• Configure the local Web authentication server on the device to use listening IP address 4.4.4.4.
Configure the device to send a default authentication page to the Web user and forward
authentication data by using HTTP.

285
 Figure 83 Network diagram

RADIUS server
1.1.1.2/24

192.168.1.2/24
802.1X client Vlan-int1
GE1/0/1 1.1.1.1/24
Vlan-int8
192.168.1.1/24
IP network
Vlan-int3
Device 3.3.3.1/24
192.168.1.3/24
Printer Loop0
4.4.4.4/32

192.168.1.4/24
Web user

Procedure
1. Make sure that the terminals, the server, and the device can reach each other. (Details not
shown.)
2. Configure the RADIUS server to provide normal authentication, authorization, and accounting
for users. In this example, configure the following on the RADIUS server:
 An 802.1X user with username userdot.
 A Web authentication user with username userpt.
 A MAC authentication user with a username and password both being the MAC address of
the printer f07d6870725f.
3. Configure Web authentication:
# Configure VLANs and IP addresses for the VLAN interfaces, and add ports to specific VLANs.
(Details not shown.)
# Create an HTTP-based local portal Web service, and specify file defaultfile.zip as the default
authentication page file of the local portal Web service. (Make sure the authentication page file
already exists in the root directory of the storage medium on the device.)
<Device> system-view
[Device] portal local-web-server http
[Device-portal-local-websvr-http] default-logon-page defaultfile.zip
[Device-portal-local-websvr-http] quit
# Assign IP address 4.4.4.4 to Loopback 0.
[Device] interface loopback 0
[Device-LoopBack0] ip address 4.4.4.4 32
[Device-LoopBack0] quit
# Create a Web authentication server named webserver and enter its view.
[Device] web-auth server webserver
# Configure the redirection URL for the Web authentication server as http://4.4.4.4/portal/.
[Device-web-auth-server-webserver] url http://4.4.4.4/portal/
# Specify 4.4.4.4 as the IP address and 80 as the port number of the Web authentication server.
[Device-web-auth-server-webserver] ip 4.4.4.4 port 80
[Device-web-auth-server-webserver] quit
# Enable Web authentication on GigabitEthernet 1/0/1 and specify Web authentication server
webserver on the interface.

286
 [Device] interface gigabitethernet 1/0/1
[Device–GigabitEthernet1/0/1] web-auth enable apply server webserver
[Device–GigabitEthernet1/0/1] quit
4. Configure 802.1X authentication:
# Enable 802.1X authentication globally.
[Device] dot1x
# Enable 802.1X authentication (MAC-based access control required) on GigabitEthernet
1/0/1.
[Device] interface gigabitethernet 1/0/1
[Device–GigabitEthernet1/0/1] dot1x port-method macbased
[Device–GigabitEthernet1/0/1] dot1x
[Device–GigabitEthernet1/0/1] quit
5. Configure MAC authentication:
# Enable MAC authentication globally.
[Device] mac-authentication
# Enable MAC authentication on GigabitEthernet 1/0/1.
[Device] interface gigabitethernet 1/0/1
[Device–GigabitEthernet1/0/1] mac-authentication
[Device–GigabitEthernet1/0/1] quit
6. Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1.
[Device] radius scheme rs1
# Specify the primary authentication and accounting servers and keys.
[Device-radius-rs1] primary authentication 1.1.1.2
[Device-radius-rs1] primary accounting 1.1.1.2
[Device-radius-rs1] key authentication simple radius
[Device-radius-rs1] key accounting simple radius
# Specify usernames sent to the RADIUS server to carry no domain names.
[Device-radius-rs1] user-name-format without-domain
[Device-radius-rs1] quit
7. Configure an ISP domain:
# Create an ISP domain named triple.
[Device] domain triple
# Configure the domain to use RADIUS scheme rs1 for authentication, authorization and
accounting of LAN access users.
[Device-isp-triple] authentication lan-access radius-scheme rs1
[Device-isp-triple] authorization lan-access radius-scheme rs1
[Device-isp-triple] accounting lan-access radius-scheme rs1
[Device-isp-triple] quit
# Configure domain triple as the default domain. If a username entered by a user includes no
ISP domain name, the AAA method of the default domain is used.
[Device] domain default enable triple

Verifying the configuration

1. Verify that the Web user can pass Web authentication.
# On the Web user terminal, use a Web browser to access an external network and then enter
the correct username and password on the authentication page
http://4.4.4.4/portal/logon.html. (Details not shown.)

287
 # Display information about online Web authentication users.
[Device] display web-auth user
Total online web-auth users: 1
User Name: localuser
MAC address: acf1-df6c-f9ad
Access interface: GigabitEthernet1/0/1
Initial VLAN: 8
Authorization VLAN: N/A
Authorization ACL ID: N/A
Authorization user profile: N/A
2. Verify that the printer can pass MAC authentication.
# Connect the printer to the network. (Details not shown.)
# Display information about online MAC authentication users.
[Device] display mac-authentication connection
Total connections: 1
Slot ID: 1
User MAC address: f07d-6870-725f
Access interface: GigabitEthernet1/0/1
Username: f07d6870725f
User access state: Successful
Authentication domain: triple
Initial VLAN: 8
Authorization untagged VLAN: N/A
Authorization tagged VLAN: N/A
Authorization VSI: N/A
Authorization ACL ID: N/A
Authorization user profile: N/A
Authorization CAR: N/A
Authorization URL: N/A
Termination action: Default
Session timeout period: N/A
Online from: 2015/01/04 18:01:43
Online duration: 0h 0m 2s
3. Verify that the 802.1X client can pass 802.1X authentication.
# On the 802.1X client, initiate 802.1X authentication and then enter the correct username and
password. (Details not shown.)
# Display information about online 802.1X users.
[Device] display dot1x connection
Total connections: 1
Slot ID: 1
User MAC address: 7446-a091-84fe
Access interface: GigabitEthernet1/0/1
Username: userdot
User access state: Successful
Authentication domain: triple
IPv4 address: 192.168.1.2
Authentication method: CHAP
Initial VLAN: 8

288
 Authorization untagged VLAN: N/A
Authorization tagged VLAN list: N/A
Authorization VSI: N/A
Authorization ACL ID: N/A
Authorization user profile: N/A
Authorization CAR: N/A
Authorization URL: N/A
Termination action: Default
Session timeout period: N/A
Online from: 2015/01/04 18:13:01
Online duration: 0h 0m 14s

Example: Configuring triple authentication to support

authorization VLAN and authentication failure VLAN
Network configuration
As shown in Figure 84, the terminals are connected to the device to access the IP network.
Configure triple authentication on the device's Layer 2 interface connected to the terminals. A
terminal passing one of the three authentication methods, 802.1X authentication, Web
authentication, and MAC authentication, can access the IP network.
• The Web authentication terminal uses DHCP to get an IP address in 192.168.1.0/24 before
authentication and in 3.3.3.0/24 after passing authentication. If the terminal fails authentication,
it requests IP addresses in 2.2.2.0/24 through DHCP.
You can use the access device or an attached device as the DHCP server. In this example, the
access device (the device) provides the DHCP service.
• The 802.1X terminal uses DHCP to get an IP address in 192.168.1.0/24 before authentication
and in 3.3.3.0/24 after passing authentication. If the terminal fails authentication, it requests IP
addresses in 2.2.2.0/24 through DHCP.
• After passing authentication, the printer obtains IP address 3.3.3.111/24 that is bound with its
MAC address through DHCP.
• Use the remote RADIUS server to perform authentication, authorization, and accounting.
Configure the device to remove the ISP domain names from usernames sent to the RADIUS
server.
• Configure the local Web authentication server on the device to use listening IP address 4.4.4.4.
Configure the device to forward authentication data by using HTTP.
• Configure VLAN 3 as the authorization VLAN. Users passing authentication are added to this
VLAN.
• Configure VLAN 2 as the authentication failure VLAN. Users failing authentication are added to
this VLAN.

289
 Figure 84 Network diagram

Loop0
4.4.4.4/32
802.1X client GE1/0/1
Vlan-int8 Vlan-int3
192.168.1.1/24 3.3.3.1/24
IP network
Vlan-int2 Device
2.2.2.1/24 Vlan-int1
Printer 1.1.1.1/24

Web user

Update server RADIUS server

2.2.2.2/24 1.1.1.2/24

Procedure
1. Make sure the terminals, the servers, and the device can reach each other. (Details not shown.)
2. Configure the RADIUS server to provide normal authentication, authorization, and accounting
for users. In this example, configure the following on the RADIUS server:
 An 802.1X user with username userdot.
 A Web authentication user with username userpt.
 A MAC authentication user with a username and password both being the MAC address of
the printer f07d6870725f.
 An authorization VLAN (VLAN 3).
3. Configure the IP address of the update server as an authentication-free IP address.
<Device> system-view
[Device] web-auth free-ip 2.2.2.2 24
4. Configure DHCP:
# Configure VLANs and IP addresses for the VLAN interfaces, and add ports to specific VLANs.
(Details not shown.)
# Enable DHCP.
[Device] dhcp enable
# Exclude the IP address of the update server from dynamic address assignment.
[Device] dhcp server forbidden-ip 2.2.2.2
# Configure DHCP address pool 1 to assign IP addresses and other configuration parameters
to clients on subnet 192.168.1.0.
[Device] dhcp server ip-pool 1
[Device-dhcp-pool-1] network 192.168.1.0 mask 255.255.255.0
[Device-dhcp-pool-1] expired day 0 hour 0 minute 1
[Device-dhcp-pool-1] gateway-list 192.168.1.1
[Device-dhcp-pool-1] quit
# Configure DHCP address pool 2 to assign IP address and other configuration parameters to
clients on subnet 2.2.2.0.
[Device] dhcp server ip-pool 2
[Device-dhcp-pool-2] network 2.2.2.0 mask 255.255.255.0
[Device-dhcp-pool-2] expired day 0 hour 0 minute 1
[Device-dhcp-pool-2] gateway-list 2.2.2.1
[Device-dhcp-pool-2] quit

290
 # Configure DHCP address pool 3 to assign IP address and other configuration parameters to
clients on subnet 3.3.3.0.
[Device] dhcp server ip-pool 3
[Device-dhcp-pool-3] network 3.3.3.0 mask 255.255.255.0
[Device-dhcp-pool-3] expired day 0 hour 0 minute 1
[Device-dhcp-pool-3] gateway-list 3.3.3.1
[Device-dhcp-pool-3] quit
# Configure DHCP address pool 4, and bind the printer's MAC address f07d-6870-725f to IP
address 3.3.3.111/24 in this address pool.
[Device] dhcp server ip-pool 4
[Device-dhcp-pool-4] static-bind ip-address 3.3.3.111 mask 255.255.255.0
client-identifier f07d-6870-725f
[Device-dhcp-pool-4] quit
5. Configure Web authentication:
# Create an HTTP-based local portal Web service, and specify file defaultfile.zip as the default
authentication page file of the local portal Web service. (Make sure the authentication page file
already exists in the root directory of the storage medium on the device.)
[Device] portal local-web-server http
[Device-portal-local-websvr-http] default-logon-page defaultfile.zip
[Device-portal-local-websvr-http] quit
# Assign IP address 4.4.4.4 to Loopback 0.
[Device] interface loopback 0
[Device-LoopBack0] ip address 4.4.4.4 32
[Device-LoopBack0] quit
# Create a Web authentication server named webserver.
[Device] web-auth server webserver
# Configure the redirection URL of the Web authentication server as http://4.4.4.4/portal/.
[Device-web-auth-server-webserver] url http://4.4.4.4/portal/
# Specify 4.4.4.4 as the IP address and 80 as the port number of the Web authentication server.
[Device-web-auth-server-webserver] ip 4.4.4.4 port 80
[Device-web-auth-server-webserver] quit
# Configure the IP address of the update server as an authentication-free IP address.
[Device] web-auth free-ip 2.2.2.2 24
# Enable Web authentication on GigabitEthernet 1/0/1 and specify VLAN 2 as the Auth-Fail
VLAN.
[Device] interface gigabitethernet 1/0/1
[Device–GigabitEthernet1/0/1] port link-type hybrid
[Device–GigabitEthernet1/0/1] mac-vlan enable
[Device–GigabitEthernet1/0/1] web-auth enable apply server webserver
[Device–GigabitEthernet1/0/1] web-auth auth-fail vlan 2
[Device–GigabitEthernet1/0/1] quit
6. Configure 802.1X authentication:
# Enable 802.1X authentication globally.
[Device] dot1x
# Enable 802.1X authentication (MAC-based access control required) on GigabitEthernet 1/0/1,
and specify VLAN 2 as the Auth-Fail VLAN.
[Device] interface gigabitethernet 1/0/1
[Device–GigabitEthernet1/0/1] dot1x port-method macbased

291
 [Device–GigabitEthernet1/0/1] dot1x
[Device–GigabitEthernet1/0/1] dot1x auth-fail vlan 2
[Device–GigabitEthernet1/0/1] quit
7. Configure MAC authentication:
# Enable MAC authentication globally.
[Device] mac-authentication
# Enable MAC authentication on GigabitEthernet 1/0/1, and specify VLAN 2 as the guest VLAN.
[Device] interface gigabitethernet 1/0/1
[Device–GigabitEthernet1/0/1] mac-authentication
[Device–GigabitEthernet1/0/1] mac-authentication guest-vlan 2
[Device–GigabitEthernet1/0/1] quit
8. Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1.
[Device] radius scheme rs1
# Specify the primary authentication and accounting servers and keys.
[Device-radius-rs1] primary authentication 1.1.1.2
[Device-radius-rs1] primary accounting 1.1.1.2
[Device-radius-rs1] key authentication simple radius
[Device-radius-rs1] key accounting simple radius
# Specify usernames sent to the RADIUS server to carry no domain names.
[Device-radius-rs1] user-name-format without-domain
[Device-radius-rs1] quit
9. Configure an ISP domain:
# Create an ISP domain named triple.
[Device] domain triple
# Configure the domain to use RADIUS scheme rs1 for authentication, authorization and
accounting of LAN access users.
[Device-isp-triple] authentication lan-access radius-scheme rs1
[Device-isp-triple] authorization lan-access radius-scheme rs1
[Device-isp-triple] accounting lan-access radius-scheme rs1
[Device-isp-triple] quit
# Configure domain triple as the default domain. If a username entered by a user includes no
ISP domain name, the AAA methods of the default domain is used.
[Device] domain default enable triple

Verifying the configuration

1. Verify that the Web user can pass Web authentication.
# On the Web user terminal, use a Web browser to access an external network and then enter
the correct username and password on the authentication page
http://4.4.4.4/portal/logon.html. (Details not shown.)
# Use the display web-auth user command to display information about online users.
[Device] display web-auth user
Total online web-auth users: 1

User Name: userpt

MAC address: 6805-ca17-4a0b
Access interface: GigabitEthernet1/0/1
Initial VLAN: 8

292
 Authorization VLAN: 3
Authorization ACL ID: N/A
Authorization user profile: N/A
2. Verify that the printer can pass MAC authentication.
# Connect the printer to the network. (Details not shown.)
# Display information about online MAC authentication users.
[Device] display mac-authentication connection
Total connections: 1
Slot ID: 1
User MAC address: f07d-6870-725f
Access interface: GigabitEthernet1/0/1
Username: f07d6870725f
User access state: Successful
Authentication domain: triple
Initial VLAN: 8
Authorization untagged VLAN: 3
Authorization tagged VLAN: N/A
Authorization VSI: N/A
Authorization ACL ID: N/A
Authorization user profile: N/A
Authorization CAR: N/A
Authorization URL: N/A
Termination action: Default
Session timeout period: N/A
Online from: 2015/01/04 18:01:43
Online duration: 0h 0m 2s
3. Verify that the 802.1X user can pass 802.1X authentication.
# On the 802.1X client, initiate 802.1X authentication and enter the correct username and
password. (Details not shown.)
# Display information about online 802.1X users.
[Device] display dot1x connection
Total connections: 1
Slot ID: 1
User MAC address: 7446-a091-84fe
Access interface: GigabitEthernet1/0/1
Username: userdot
User access state: Successful
Authentication domain: triple
IPv4 address: 3.3.3.3
Authentication method: CHAP
Initial VLAN: 8
Authorization untagged VLAN: 3
Authorization tagged VLAN list: N/A
Authorization VSI: N/A
Authorization ACL ID: N/A
Authorization user profile: N/A
Authorization CAR: N/A
Authorization URL: N/A

293
 Termination action: Default
Session timeout period: N/A
Online from: 2015/01/04 18:13:01
Online duration: 0h 0m 14s
4. Verify that users that pass authentication have been assigned authorization VLANs.
# Display MAC-VLAN entries of online users.
[Device] display mac-vlan all
The following MAC VLAN addresses exist:
S:Static D:Dynamic
MAC ADDR MASK VLAN ID PRIO STATE
--------------------------------------------------------
6805-ca17-4a0b ffff-ffff-ffff 3 0 D
f07d-6870-725f ffff-ffff-ffff 3 0 D
7446-a091-84fe ffff-ffff-ffff 3 0 D
Total MAC VLAN address count:3
5. Verify that online users have been assigned IP addresses.
[Device] display dhcp server ip-in-use
IP address Client-identifier/ Lease expiration Type
Hardware address
3.3.3.111 01f0-7d68-7072-5f Jan 4 18:14:17 2015 Auto:(C)
3.3.3.2 0168-05ca-174a-0b Jan 4 18:15:01 2015 Auto:(C)
3.3.3.3 0174-46a0-9184-fe Jan 4 18:15:03 2015 Auto:(C)
6. When a terminal fails authentication, it is added to VLAN 2. You can use the previous display
commands to display the MAC-VLAN entry and IP address of the terminal. (Details not shown.)

294
Configuring port security
About port security
Port security combines and extends 802.1X and MAC authentication to provide MAC-based network
access control. The feature applies to ports that use different authentication methods for users.

Major functions
Port security provides the following functions:
• Prevents unauthorized access to a network by checking the source MAC address of inbound
traffic.
• Prevents access to unauthorized devices or hosts by checking the destination MAC address of
outbound traffic.
• Controls MAC address learning and authentication on a port to make sure the port learns only
source trusted MAC addresses.

Port security features

NTK
The need to know (NTK) feature prevents traffic interception by checking the destination MAC
address in the outbound frames. The feature ensures that frames are sent only to the following
hosts:
• Hosts that have passed authentication.
• Hosts whose MAC addresses have been learned or configured on the access device.
Intrusion protection
The intrusion protection feature checks the source MAC address in inbound frames for illegal frames,
and takes a predefined action on each detected illegal frame. The action can be disabling the port
temporarily, disabling the port permanently, or blocking frames from the illegal MAC address for a
period set by the MAC block timer.
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.

Port security modes

Port security supports the following categories of security modes:
• MAC learning control—Includes two modes: autoLearn and secure. MAC address learning 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 MAC address table for 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, or sends SNMP notifications.
Outgoing frames are not restricted by port security's NTK action unless they trigger the NTK feature.
Table 26 describes the port security modes and the security features.

295
 Table 26 Port security modes

Features that
Purpose Security mode
can be triggered
noRestrictions (the default mode)
Turning off the port security
In this mode, port security is disabled on the port N/A
feature
and access to the port is not restricted.

Controlling MAC address autoLearn NTK/intrusion

learning secure protection

NTK (ntkauto
userLogin
mode)
Performing 802.1X userLoginSecure
authentication NTK/intrusion
userLoginSecureExt
protection
userLoginWithOUI
NTK/intrusion
Performing MAC authentication macAddressWithRadius
protection
macAddressOrUserLoginSecure
Or
macAddressOrUserLoginSecureExt
Performing a combination of
NTK/intrusion
MAC authentication and macAddressElseUserLoginSecure
Else protection
802.1X authentication
macAddressElseUserLoginSecureExt
And macAddressAndUserLoginSecureExt

The mode names are illustrated as follows:

• userLogin specifies 802.1X authentication and port-based access control. userLogin with
Secure specifies 802.1X authentication and MAC-based access control. Ext indicates allowing
multiple 802.1X users to be authenticated and serviced at the same time. A security mode
without Ext allows only one user to pass 802.1X authentication.
• macAddress specifies MAC authentication.
• Else specifies that the authentication method before Else is applied first. If the authentication
fails, whether to turn to the authentication method following Else depends on the protocol type
of the authentication request.
• Or specifies that the authentication method following Or is applied first. If the authentication
fails, the authentication method before Or is applied.
• And indicates that the authentication method before And is applied first. If the authentication
succeeds, the system turns to the authentication method that follows And upon receiving the
request of the authentication method.
Controlling 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 dynamic MAC address. Instead, these MAC addresses
are added to the secure MAC address table as secure MAC addresses. You can also configure
secure MAC addresses by using the port-security mac-address security
command.
A port in autoLearn mode allows frames sourced from the following MAC addresses to pass:
 Secure MAC addresses.
 MAC addresses configured by using the mac-address dynamic and mac-address
static commands.

296
 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. You configure MAC addresses by
using the mac-address static and mac-address dynamic commands. For more
information about configuring MAC address table entries, see Layer 2—LAN Switching
Configuration Guide.
A port in secure mode allows only frames sourced from the following MAC addresses to pass:
 Secure MAC addresses.
 MAC addresses configured by using the mac-address dynamic and mac-address
static commands.
Performing 802.1X authentication
• userLogin.
A port in this mode performs 802.1X authentication 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 authentication 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.
• 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 frames that pass OUI check or 802.1X authentication.

NOTE:
An OUI is a 24-bit number that uniquely identifies a vendor, manufacturer, or organization. In
MAC addresses, the first three octets are the OUI.

Performing MAC authentication

macAddressWithRadius: A port in this mode performs MAC authentication, and services multiple
users.
Performing a combination of MAC authentication and 802.1X authentication
• macAddressOrUserLoginSecure.
This mode is the combination of the macAddressWithRadius and userLoginSecure modes. The
mode allows one 802.1X authentication user and multiple MAC authentication users to log in.
In this mode, the port performs 802.1X authentication first. By default, if 802.1X authentication
fails, MAC authentication is performed.
However, the port in this mode processes authentication differently when the following
conditions exist:
 The port is enabled with parallel processing of MAC authentication and 802.1X
authentication.
 The port is enabled with the 802.1X unicast trigger.
 The port receives a packet from an unknown MAC address.

297
 Under such conditions, the port sends a unicast EAP-Request/Identity packet to the MAC
address to initiate 802.1X authentication. After that, the port immediately processes MAC
authentication without waiting for the 802.1X authentication result.
• 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 macAddressWithRadius and userLoginSecure modes, with
MAC authentication having a higher priority as the Else keyword implies. The mode allows one
802.1X authentication user and multiple MAC authentication users to log in.
In this mode, the port performs MAC authentication 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.
• macAddressAndUserLoginSecureExt.
In this mode, a user must pass both MAC authentication and 802.1X authentication to access
the authorized network resources.
The device uses the following process to handle an access user on a port operating in this
mode:
a. Performs MAC authentication for the user.
b. Marks the user as a temporary MAC authentication user when the user passes MAC
authentication. A temporary MAC authentication user can access only resources in the
802.1X guest VLAN or VSI.
c. After receiving 802.1X protocol packets from the user on the port, the device performs
802.1X authentication for the user.
d. After the user passes 802.1X authentication on the port, the device removes the temporary
MAC authentication user entry. Then, the user comes online as an 802.1X user.

Restrictions and guidelines: Port security

configuration
This feature applies to networks, such as a WLAN, that require different authentication methods for
different users on a port.
As a best practice, use the 802.1X authentication or MAC authentication feature rather than port
security for scenarios that require only 802.1X authentication or MAC authentication. For more
information about 802.1X and MAC authentication, see "Configuring 802.1X" and "Configuring MAC
authentication."
The secure and userlogin-withoui port security modes are not supported on Layer 2
aggregate interfaces. Other port security settings are supported on both Layer 2 Ethernet interfaces
and Layer 2 aggregate interfaces.
After a Layer 2 Ethernet interface is added to an aggregation group, port security settings on the
interface do not take effect.
Do not delete a Layer 2 aggregate interface if the interface has online 802.1X or MAC authentication
users.

298
Port security tasks at a glance
To configure port security, perform the following tasks:
1. Configuring basic features of port security
 Enabling port security
 Setting the port security mode
 (Optional.) Setting port security's limit on the number of secure MAC addresses on a port
 (Optional.) Configuring secure MAC addresses
 (Optional.) Configuring NTK
 (Optional.) Configuring intrusion protection
2. (Optional.) Configuring extended features of port security
 Ignoring authorization information from the server
 Configuring MAC move
 Enabling the authorization-fail-offline feature
 Setting port security's limit on the number of MAC addresses for specific VLANs on a port
 Enabling open authentication mode
 Configuring free VLANs for port security
 Applying a NAS-ID profile to port security
 Enabling the escape critical VSI feature for 802.1X and MAC authentication users
The extended port security features can also take effect when port security is disabled but
802.1X or MAC authentication is enabled.
3. (Optional.) Enabling SNMP notifications for port security
4. (Optional.) Enabling port security user logging

Enabling port security

Restrictions and guidelines
When you configure port security, follow these restrictions and guidelines:
• When port security is enabled, you cannot enable 802.1X or MAC authentication, or change the
access control mode or port authorization state. Port security automatically modifies these
settings in different security modes.
• You can use the undo port-security enable command to disable port security. Because
the command logs off online users, make sure no online users are present.
• Enabling or disabling port security resets the following security settings to the default:
 802.1X access control mode, which is MAC-based.
 Port authorization state, which is auto.
For more information about 802.1X authentication and MAC authentication configuration, see
"Configuring 802.1X" and "Configuring MAC authentication."
Prerequisites
Before you enable port security, disable 802.1X and MAC authentication globally.
Procedure
1. Enter system view.
system-view
2. Enable port security.

299
 port-security enable
By default, port security is disabled.

Setting the port security mode

Restrictions and guidelines
You can specify a port security mode when port security is disabled, but your configuration cannot
take effect.
Changing the port security mode of a port logs off the online users of the port.
Do not enable 802.1X authentication or MAC authentication on a port where port security is enabled.
After enabling port security, you can change the port security mode of a port only when the port is
operating in noRestrictions (the default) mode. To change the port security mode for a port in any
other mode, first use the undo port-security port-mode command to restore the default port
security mode.
The device supports the URL attribute assigned by a RADIUS server in the following port security
modes:
• mac-authentication.
• mac-else-userlogin-secure.
• mac-else-userlogin-secure-ext.
• userlogin-secure.
• userlogin-secure-ext.
• userlogin-secure-or-mac.
• userlogin-secure-or-mac-ext.
• userlogin-withoui.
During authentication, the HTTP or HTTPS requests of a user are redirected to the Web interface
specified by the server-assigned URL attribute. After the user passes the Web authentication, the
RADIUS server records the MAC address of the user and uses a DM (Disconnect Message) to log
off the user. When the user initiates 802.1X or MAC authentication again, it will pass the
authentication and come online successfully.
When the port security mode is macAddressAndUserLoginSecureExt on a port, follow these
restrictions and guidelines:
• To make sure the 802.1X clients attached to the port can initiate authentication, enable the
unicast trigger on the port by using the dot1x unicast-trigger command.
• The MAC authentication guest VLAN or VSI on the port does not take effect. For the temporary
MAC authentication users to access a limited set of resources, configure an 802.1X guest
VLAN or VSI on the port.
• If accounting is not required for the temporary MAC authentication users, configure different
ISP domains for MAC authentication users and 802.1X users. In the ISP domain for the MAC
authentication users, set the accounting method to none.
To redirect the HTTPS requests of port security users, specify the HTTPS redirect listening port on
the device. For more information, see HTTP redirect in Layer 3—IP Services Configuration Guide.
Prerequisites
Before you set a port security mode for a port, complete the following tasks:
• Disable 802.1X and MAC authentication.
• If you are configuring the autoLearn mode, set port security's limit on the number of secure
MAC addresses. You cannot change the setting when the port is operating in autoLearn mode.

300
Procedure
1. Enter system view.
system-view
2. Set an OUI value for user authentication.
port-security oui index index-value mac-address oui-value
By default, no OUI values are configured for user authentication.
This command is required only for the userlogin-withoui mode.
You can set multiple OUIs, but when the port security mode is userlogin-withoui, the port
allows one 802.1X user and only one user that matches one of the specified OUIs.
3. Enter interface view.
interface interface-type interface-number
4. Set the port security mode.
port-security port-mode { autolearn | mac-and-userlogin-secure-ext |
mac-authentication | mac-else-userlogin-secure |
mac-else-userlogin-secure-ext | secure | userlogin |
userlogin-secure | userlogin-secure-ext | userlogin-secure-or-mac |
userlogin-secure-or-mac-ext | userlogin-withoui }
By default, a port operates in noRestrictions mode.

Setting port security's limit on the number of

secure MAC addresses on a port
About this task
You can set the maximum number of secure MAC addresses that port security allows on a port for
the following purposes:
• Controlling 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.
• Controlling the number of secure MAC addresses on the port in autoLearn mode.
You can also set the maximum number of secure MAC addresses that port security allows for
specific VLANs or each VLAN on a port.
Port security's limit on the number of secure MAC addresses on a port is independent of the MAC
learning limit described in MAC address table configuration. For more information about MAC
address table configuration, see Layer 2—LAN Switching Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Set the maximum number of secure MAC addresses allowed on a port.
port-security max-mac-count max-count[ vlan [ vlan-id-list ] ]
By default, port security does not limit the number of secure MAC addresses on a port.

301
Configuring secure MAC addresses
About secure MAC addresses
Secure MAC addresses are configured or learned in autoLearn mode. If the secure MAC addresses
are saved, they can survive a device reboot. You can bind a secure MAC address only to one port in
a VLAN.
Secure MAC addresses include static, sticky, and dynamic secure MAC addresses.
Table 27 Comparison of static, sticky, and dynamic secure MAC addresses

Can be saved and

Type Address sources Aging mechanism survive a device
reboot?
Not available.
Manually added (by using The static secure MAC addresses
the port-security never age out unless you perform any
mac-address of the following tasks:
Static Yes.
security command • Manually remove these MAC
without the sticky addresses.
keyword). • Change the port security mode.
• Disable the port security feature.

By default, sticky MAC addresses do

• Manually added (by not age out. However, you can
using the configure an aging timer or use the
port-security aging timer together with the inactivity
mac-address aging feature to remove old sticky MAC
security command addresses.
with the sticky • If only the aging timer is Yes.
keyword). configured, the aging timer counts The secure MAC
Sticky
• Converted from up regardless of whether traffic aging timer restarts at
dynamic secure MAC data has been sent from the sticky a reboot.
addresses. MAC addresses.
• Automatically learned • If both the aging timer and the
when the dynamic inactivity aging feature are
secure MAC feature is configured, the aging timer restarts
disabled. once traffic data is detected from
the sticky MAC addresses.
• Converted from sticky
MAC addresses. No.
• Automatically learned All dynamic secure
Dynamic Same as sticky MAC addresses.
after the dynamic MAC addresses are
secure MAC feature is lost at reboot.
enabled.

When the maximum number of secure MAC address entries is reached, the port changes to secure
mode. In secure mode, the port cannot add or learn any more secure MAC addresses. The port
allows only frames sourced from secure MAC addresses or MAC addresses configured by using the
mac-address dynamic or mac-address static command to pass through.

Prerequisites
Before you configure secure MAC addresses, complete the following tasks:

302
 • Set port security's limit on the number of MAC addresses on the port. Perform this task before
you enable autoLearn mode.
• Set the port security mode to autoLearn.
• Configure the port to permit packets of the specified VLAN to pass or add the port to the VLAN.
Make sure the VLAN already exists.

Adding secure MAC addresses

1. Enter system view.
system-view
2. Set the secure MAC aging timer.
port-security timer autolearn aging [ second ] time-value
By default, secure MAC addresses do not age out.
3. Configure a secure MAC address.
 Configure a secure MAC address in system view.
port-security mac-address security [ sticky ] mac-address interface
interface-type interface-number vlan vlan-id
 Execute the following commands in sequence to configure a secure MAC address in
interface view:
interface interface-type interface-number
port-security mac-address security [ sticky ] mac-address vlan
vlan-id
By default, no manually configured secure MAC addresses exist.
In a VLAN, a MAC address cannot be specified as both a static secure MAC address and a
sticky MAC address.

Enabling inactivity aging for secure MAC addresses

1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable inactivity aging for secure MAC addresses.
port-security mac-address aging-type inactivity
By default, the inactivity aging feature is disabled for secure MAC addresses.

Enabling the dynamic secure MAC feature

1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable the dynamic secure MAC feature.
port-security mac-address dynamic
By default, the dynamic secure MAC feature is disabled. Sticky MAC addresses can be saved
to the configuration file. Once saved, they can survive a device reboot.

303
Configuring NTK
About this task
The NTK feature checks the destination MAC address in outbound frames to make sure frames are
forwarded only to trustworthy devices.
The NTK feature supports the following modes:
• ntkonly—Forwards only unicast frames with a known destination MAC address.
• ntk-withbroadcasts—Forwards only broadcast and unicast frames with a known destination
MAC address.
• ntk-withmulticasts—Forwards only broadcast, multicast, and unicast frames with a known
destination MAC address.
• ntkauto—Forwards only broadcast, multicast, and unicast frames with a known destination
MAC address, and only when the port has online users.
Restrictions and guidelines
The NTK feature drops any unicast frame with an unknown destination MAC address.
Not all port security modes support triggering the NTK feature. For more information, see Table 26.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Configure the NTK feature.
port-security ntk-mode { ntk-withbroadcasts | ntk-withmulticasts |
ntkauto | ntkonly }
By default, NTK is disabled on a port and all frames are allowed to be sent.

Configuring intrusion protection

About this task
Intrusion protection takes one of the following actions on a port in response to illegal frames:
• blockmac—Adds the source MAC addresses of illegal frames to the blocked MAC address list,
and then discards frames sourced from blocked MAC addresses for a period set by the block
timer. A blocked MAC address will be unblocked when the block timer expires.
• disableport—Disables the port until you bring it up manually.
• disableport-temporarily—Disables the port for a period of time. The period can be configured
with the port-security timer disableport command.
Restrictions and guidelines
On a port operating in either macAddressElseUserLoginSecure mode or
macAddressElseUserLoginSecureExt mode, intrusion protection is triggered only after both MAC
authentication and 802.1X authentication fail for the same frame.
Procedure
1. Enter system view.
system-view
2. Enter interface view.

304
 interface interface-type interface-number
3. Configure the intrusion protection feature.
port-security intrusion-mode { blockmac | disableport |
disableport-temporarily }
By default, intrusion protection is disabled.
4. Return to system view.
quit
5. (Optional.) Set the silence timeout period during which a port remains disabled.
port-security timer disableport time-value
By default, the port silence timeout period is 20 seconds.
6. (Optional.) Set the block timer for blocked MAC addresses.
port-security timer blockmac time-value
By default, the block timer is 180 seconds.

Ignoring authorization information from the server

About this task
You can configure a port to ignore the authorization information received from the server (local or
remote) after an 802.1X or MAC authentication user passes authentication.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Ignore the authorization information received from the authentication server.
port-security authorization ignore
By default, a port uses the authorization information received from the authentication server.

Configuring MAC move

About this task
Port security MAC move takes effect in the following scenarios:
• Inter-port move on a device—An online user authenticated through 802.1X or MAC
authentication moves between ports on the device. The user VLAN or authentication method
might change or stay unchanged after the move.
• Inter-VLAN move on a port—An online user authenticated through 802.1X or MAC
authentication moves between VLANs on a trunk or hybrid port. In addition, the packets that
trigger authentication have VLAN tags.
Port security MAC move allows an online user authenticated through 802.1X or MAC authentication
on one port or VLAN to be reauthenticated and come online on another port or VLAN without going
offline first. After the user passes authentication on the new port or VLAN, the system removes the
authentication session of the user on the original port or VLAN.

NOTE:
For MAC authentication, the MAC move feature applies only when MAC authentication single-VLAN
mode is used. The MAC move feature does not apply to MAC authentication users that move

305
 between VLANs on a port with MAC authentication multi-VLAN mode enabled.

If this feature is disabled, 802.1X or MAC authenticated users must go offline first before they can be
reauthenticated successfully on a new port or VLAN to come online.
Restrictions and guidelines
As a best practice to minimize security risks, enable MAC move only if user roaming between ports is
required.
802.1X or MAC authenticated users cannot move between ports on a device or between VLANs on
a port if the maximum number of online users on the authentication server has been reached.
MAC authentication multi-VLAN mode has higher priority than MAC move for users moving between
VLANs on a port. If MAC authentication multi-VLAN mode is enabled, these users can come online
in the new VLAN without being reauthenticated. To enable MAC authentication multi-VLAN mode,
use the mac-authentication host-mode multi-vlan command. For more information
about MAC authentication multi-VLAN mode, see "Configuring MAC authentication."
Procedure
1. Enter system view.
system-view
2. Enable MAC move.
port-security mac-move permit
By default, MAC move is disabled.

Enabling the authorization-fail-offline feature

About the authorization-fail-offline feature

IMPORTANT:
The authorization-fail-offline feature takes effect only on port security users that have failed ACL,
CAR, or user profile authorization.

The authorization-fail-offline feature logs off port security users that have failed authorization.
A user fails authorization in the following situations:
• The device or server fails to assign the specified authorization attribute to the user.
• The device or server assigns authorization information that does not exist on the device to the
user.
This feature does not apply to users that have failed VLAN authorization. The device logs off these
users directly.
You can also enable the quiet timer feature for 802.1X or MAC authentication users that are logged
off by the authorization-fail-offline feature. The device adds these users to the 802.1X or MAC
authentication quiet queue. Within the quiet timer, the device does not process packets from these
users or authenticate them. If you do not enable the quiet timer feature, the device immediately
authenticates these users upon receiving packets from them.
Prerequisites
For the quiet timer feature to take effect, complete the following tasks:
• For 802.1X users, use the dot1x quiet-period command to enable the quiet timer and
use the dot1x timer quiet-period command to set the timer.
• For MAC authentication users, use the mac-authentication timer quiet command to
set the quiet timer for MAC authentication.

306
Procedure
1. Enter system view.
system-view
2. Enable the authorization-fail-offline feature.
port-security authorization-fail offline [ quiet-period ]
By default, this feature is disabled, and the device does not log off users that have failed
authorization.

Setting port security's limit on the number of MAC

addresses for specific VLANs on a port
About this task
Typically, port security allows the access of the following types of MAC addresses on a port:
• MAC addresses that pass 802.1X or MAC authentication.
• MAC addresses in the MAC authentication guest VLAN or MAC authentication critical VLAN
and MAC addresses in the MAC authentication guest VSI or MAC authentication critical VSI.
• MAC addresses in the 802.1X guest VLAN, 802.1X Auth-Fail VLAN, or 802.1X critical VLAN
and MAC addresses in the 802.1X guest VSI, 802.1X Auth-Fail VSI, or 802.1X critical VSI.
This feature limits the number of MAC addresses that port security allows to access a port through
specific VLANs. Use this feature to prevent resource contentions among MAC addresses and
ensure reliable performance for each access user on the port. When the number of MAC addresses
in a VLAN on the port reaches the upper limit, the device denies any subsequent MAC addresses in
the VLAN on the port.
Restrictions and guidelines
On a port, the maximum number of MAC addresses in a VLAN cannot be smaller than the number of
existing MAC addresses in the VLAN. If the specified maximum number is smaller, the setting does
not take effect.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Set port security's limit on the number of MAC addresses for specific VLANs on the port.
port-security mac-limit max-number per-vlan vlan-id-list
The default setting is 2147483647.

Enabling open authentication mode

About this task
This feature enables access users (802.1X or MAC authentication users) of a port to come online
and access the network even if they use nonexistent usernames or incorrect passwords.
Access users that come online in open authentication mode are called open users. Authorization and
accounting are not available for open users. To display open user information, use the following
commands:
• display dot1x connection open.

307
 • display mac-authentication connection open.
This feature does not affect the access of users that use correct user information.
Restrictions and guidelines
When you configure open authentication mode, follow these restrictions and guidelines:
• If global open authentication mode is enabled, all ports are enabled with open authentication
mode regardless of the port-specific open authentication mode setting. If global open
authentication mode is disabled, whether a port is enabled with open authentication mode
depends on the port-specific open authentication mode setting.
• The open authentication mode setting has lower priority than the 802.1X Auth-Fail VLAN and
the MAC authentication guest VLAN. Open authentication mode does not take effect on a port if
the port is also configured with the 802.1X Auth-Fail VLAN or the MAC authentication guest
VLAN. For information about 802.1X authentication and MAC authentication, see "802.1X
overview," "Configuring 802.1X," and "Configuring MAC authentication."
• The open authentication mode setting has lower priority than the 802.1X Auth-Fail VSI and the
MAC authentication guest VSI. Open authentication mode does not take effect on a port if the
port is also configured with the 802.1X Auth-Fail VSI or the MAC authentication guest VSI. For
information about 802.1X authentication and MAC authentication, see "802.1X overview,"
"Configuring 802.1X," and "Configuring MAC authentication."
Procedure
1. Enter system view.
system-view
2. Enable global open authentication mode.
port-security authentication open global
By default, global open authentication mode is disabled.
3. Enter interface view.
interface interface-type interface-number
4. Enable open authentication mode on the port.
port-security authentication open
By default, open authentication mode is disabled on a port.

Configuring free VLANs for port security

About this task
This feature allows packets from the specified VLANs to not trigger 802.1X or MAC authentication on
a port configured with any of the following features:
• 802.1X authentication.
• MAC authentication.
• One of the following port security modes:
 userLogin.
 userLoginSecure.
 userLoginWithOUI.
 userLoginSecureExt.
 macAddressWithRadius.
 macAddressOrUserLoginSecure.
 macAddressElseUserLoginSecure.
 macAddressOrUserLoginSecureExt.

308
  macAddressElseUserLoginSecureExt.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Configure free VLANs for port security.
port-security free-vlan vlan-id-list
By default, no free VLANs for port security exist on a port.

Applying a NAS-ID profile to port security

About this task
By default, the device sends its device name in the NAS-Identifier attribute of all RADIUS requests.
A NAS-ID profile enables you to send different NAS-Identifier attribute strings in RADIUS requests
from different VLANs. The strings can be organization names, service names, or any user
categorization criteria, depending on the administrative requirements.
For example, map the NAS-ID companyA to all VLANs of company A. The device will send
companyA in the NAS-Identifier attribute for the RADIUS server to identify requests from any
Company A users.
Restrictions and guidelines
You can apply a NAS-ID profile to port security globally or on a port. On a port, the device selects a
NAS-ID profile in the following order:
1. The port-specific NAS-ID profile.
2. The NAS-ID profile applied globally.
If no NAS-ID profile is applied or no matching binding is found in the selected profile, the device uses
the device name as the NAS-ID.
For more information about the NAS-ID profile configuration, see "Configuring AAA."
Procedure
1. Enter system view.
system-view
2. Apply a NAS-ID profile.
 Apply a NAS-ID profile globally.
port-security nas-id-profile profile-name
 Execute the following commands in sequence to apply a NAS-ID profile to an interface:
interface interface-type interface-number
port-security nas-id-profile profile-name
By default, no NAS-ID profile is applied in system view or in interface view.

309
Enabling the escape critical VSI feature for
802.1X and MAC authentication users
About this task
The escape critical VSI feature operates on VXLAN networks. It enables 802.1X and MAC
authentication users to escape the authentication failure that occurs because the RADIUS server is
malfunctioning.
You can enable this feature temporarily to prevent 802.1X and MAC authentication service
interruption while you are troubleshooting a malfunctioning RADIUS server.
After the escape critical VSI feature is enabled on a port, the device performs the following
operations when 802.1X or MAC authentication is triggered for a user:
1. Dynamically creates an Ethernet service instance that matches the user's access VLAN and
MAC address on the access port.
2. Maps the Ethernet service instance to the 802.1X or MAC authentication critical VSI on the port.
The user can then come online without authentication and access resources in the VXLAN
associated with the critical VSI.
The escape critical VSI feature does not affect 802.1X or MAC authentication users that have been
online before this feature is enabled.
Restrictions and guidelines
For the escape critical VSI feature to work correctly on a port, make sure the port does not have the
following settings:
• Web authentication.
• Guest, Auth-Fail, or critical VLAN for 802.1X authentication.
• Guest or critical VLAN for MAC authentication.
You can enable or disable this feature globally on all ports or on a per-port basis.
If the mac-authentication critical vsi critical-vsi-name url-user-logoff
command is used in conjunction with this feature, MAC authentication users that have been
assigned authorization URLs on the port will be logged off. For more information, see "Configuring
MAC authentication."
When you disable the escape critical VSI both globally and on a port, the device logs off the users in
the critical VSIs for 802.1X and MAC authentication on that port. The users must perform
authentication to come online again on that port.
The escape critical VSI feature does not take effect on a new 802.1X or MAC authentication user if
any of the following conditions exists:
• The 802.1X client and the device use different EAP message handling methods.
• 802.1X MAC address binding is enabled on the user's access port, but the MAC address of the
802.1X user is not bound to that port.
• The user's MAC address is an all-zero, all-F, or multicast MAC address.
Prerequisites
Before you enable the escape critical VSI feature on a port, configure an 802.1X critical VSI and a
MAC authentication critical VSI on that port. For more information about critical VSI configuration,
see "Configuring 802.1X" and "Configuring MAC authentication."
Procedure
1. Enter system view.
system-view

310
 2. Enable the escape critical VSI feature.
 Enable the global escape critical VSI feature.
port-security global escape critical-vsi
 Execute the following commands in sequence to enable the escape critical VSI feature on a
port:
interface interface-type interface-number
port-security escape critical-vsi
By default, the escape critical VSI feature is disabled.

Enabling SNMP notifications for port security

About this task
Use this feature to report critical port security events to an NMS. For port security event notifications
to be sent correctly, you must also configure SNMP on the device. For more information about SNMP
configuration, see Network Management and Monitoring Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enable SNMP notifications for port security.
snmp-agent trap enable port-security [ address-learned |
dot1x-failure | dot1x-logoff | dot1x-logon | intrusion |
mac-auth-failure | mac-auth-logoff | mac-auth-logon ] *
By default, SNMP notifications are disabled for port security.

Enabling port security user logging

About this task
This feature enables the device to generate logs about port security users and send the logs to the
information center. For the logs to be output correctly, you must also configure the information center
on the device. For more information about information center configuration, see Network
Management and Monitoring Configuration Guide.
Restrictions and guidelines
To prevent excessive port security user log entries, use this feature only if you need to analyze
abnormal port security user events.
Procedure
1. Enter system view.
system-view
2. Enable port security user logging.
port-security access-user log enable [ failed-authorization |
mac-learning | violation | vlan-mac-limit ] *
By default, port security user logging is disabled.
If you do not specify any parameters, this command enables all types of port security user logs.

311
Display and maintenance commands for port
security
Execute display commands in any view:

Task Command
Display the port security configuration, display port-security [ interface
operation information, and statistics. interface-type interface-number ]
display port-security mac-address block
Display information about blocked MAC
[ interface interface-type
addresses.
interface-number ] [ vlan vlan-id ] [ count ]
display port-security mac-address security
Display information about secure MAC
[ interface interface-type
addresses.
interface-number ] [ vlan vlan-id ] [ count ]

Port security configuration examples

Example: Configuring port security in autoLearn mode
Network configuration
As shown in Figure 85, configure GigabitEthernet 1/0/1 on the device to meet the following
requirements:
• Accept up to 64 users without authentication.
• Be permitted to learn and add MAC addresses as sticky MAC addresses, and set the secure
MAC aging timer to 30 minutes.
• Stop learning MAC addresses after the number of secure MAC addresses reaches 64. If any
frame with an unknown MAC address arrives, intrusion protection starts, and the port shuts
down and stays silent for 30 seconds.
Figure 85 Network diagram

GE1/0/1
Internet
Device

Host

Procedure
# Enable port security.
<Device> system-view
[Device] port-security enable

# Set the secure MAC aging timer to 30 minutes.

[Device] port-security timer autolearn aging 30

# Set port security's limit on the number of secure MAC addresses to 64 on GigabitEthernet 1/0/1.

312
 [Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] port-security max-mac-count 64

# Set the port security mode to autoLearn.

[Device-GigabitEthernet1/0/1] port-security port-mode autolearn

# Configure the port to be silent for 30 seconds after the intrusion protection feature is triggered.
[Device-GigabitEthernet1/0/1] port-security intrusion-mode disableport-temporarily
[Device-GigabitEthernet1/0/1] quit
[Device] port-security timer disableport 30

Verifying the configuration

# Verify the port security configuration.
[Device] display port-security interface gigabitethernet 1/0/1
Global port security parameters:
Port security : Enabled
AutoLearn aging time : 30 min
Disableport timeout : 30 s
Blockmac timeout : 180 s
MAC move : Denied
Authorization fail : Online
NAS-ID profile : Not configured
Dot1x-failure trap : Disabled
Dot1x-logon trap : Disabled
Dot1x-logoff trap : Disabled
Intrusion trap : Disabled
Address-learned trap : Disabled
Mac-auth-failure trap : Disabled
Mac-auth-logon trap : Disabled
Mac-auth-logoff trap : Disabled
Open authentication : Disabled
OUI value list :
Index : 1 Value : 123401

GigabitEthernet1/0/1 is link-up
Port mode : autoLearn
NeedToKnow mode : Disabled
Intrusion protection mode : DisablePortTemporarily
Security MAC address attribute
Learning mode : Sticky
Aging type : Periodical
Max secure MAC addresses : 64
Current secure MAC addresses : 0
Authorization : Permitted
NAS-ID profile : Not configured
Free VLANs : Not configured
Open authentication : Disabled
MAC-move VLAN check bypass : Disabled

The port allows for MAC address learning, and you can view the number of learned MAC addresses
in the Current secure MAC addresses field.

313
 # Display additional information about the learned MAC addresses.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] display this
#
interface GigabitEthernet1/0/1
port-security max-mac-count 64
port-security port-mode autolearn
port-security mac-address security sticky 0002-0000-0015 vlan 1
port-security mac-address security sticky 0002-0000-0014 vlan 1
port-security mac-address security sticky 0002-0000-0013 vlan 1
port-security mac-address security sticky 0002-0000-0012 vlan 1
port-security mac-address security sticky 0002-0000-0011 vlan 1
#
[Device-GigabitEthernet1/0/1] quit

# Verify that the port security mode changes to secure after the number of MAC addresses learned
by the port reaches 64.
[Device] display port-security interface gigabitethernet 1/0/1

# Verify that the port will be disabled for 30 seconds after it receives a frame with an unknown MAC
address. (Details not shown.)
# After the port is re-enabled, delete several secure MAC addresses.
[Device] undo port-security mac-address security sticky 0002-0000-0015 vlan 1
[Device] undo port-security mac-address security sticky 0002-0000-0014 vlan 1
...

# Verify that the port security mode of the port changes to autoLearn, and the port can learn MAC
addresses again. (Details not shown.)

Example: Configuring port security in userLoginWithOUI

mode
Network configuration
As shown in Figure 86, a client is connected to the device through GigabitEthernet 1/0/1. The device
authenticates the client with a RADIUS server in ISP domain sun. If the authentication succeeds, the
client is authorized to access the Internet.
• The RADIUS server at 192.168.1.2 acts as the primary authentication server and the secondary
accounting server. The RADIUS server at 192.168.1.3 acts as the secondary authentication
server and the primary accounting server. The shared key for authentication is name, and the
shared key for accounting is money.
• All users use the authentication, authorization, and accounting methods of ISP domain sun.
• The RADIUS server response timeout time is 5 seconds. The maximum number of RADIUS
packet retransmission attempts is 5. The device sends real-time accounting packets to the
RADIUS server at 15-minute intervals, and sends usernames without domain names to the
RADIUS server.
Configure GigabitEthernet 1/0/1 to allow only one 802.1X user and a user that uses one of the
specified OUI values to be authenticated.

314
 Figure 86 Network diagram

Authentication servers
(192.168.1.2/24
192.168.1.3/24)

GE1/0/1
Internet

Host Device

Procedure
The following configuration steps cover some AAA/RADIUS configuration commands. For more
information about the commands, see Security Command Reference.
Make sure the host and the RADIUS server can reach each other.
1. Configure AAA:
# Configure a RADIUS scheme named radsun.
<Device> system-view
[Device] radius scheme radsun
[Device-radius-radsun] primary authentication 192.168.1.2
[Device-radius-radsun] primary accounting 192.168.1.3
[Device-radius-radsun] secondary authentication 192.168.1.3
[Device-radius-radsun] secondary accounting 192.168.1.2
[Device-radius-radsun] key authentication simple name
[Device-radius-radsun] key accounting simple money
[Device-radius-radsun] timer response-timeout 5
[Device-radius-radsun] retry 5
[Device-radius-radsun] timer realtime-accounting 15
[Device-radius-radsun] user-name-format without-domain
[Device-radius-radsun] quit
# Configure ISP domain sun.
[Device] domain sun
[Device-isp-sun] authentication lan-access radius-scheme radsun
[Device-isp-sun] authorization lan-access radius-scheme radsun
[Device-isp-sun] accounting lan-access radius-scheme radsun
[Device-isp-sun] quit
2. Configure 802.1X:
# Set the 802.1X authentication method to CHAP. By default, the authentication method for
802.1X is CHAP.
[Device] dot1x authentication-method chap
# Specify ISP domain sun as the mandatory authentication domain for 802.1X users on
GigabitEthernet 1/0/1.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] dot1x mandatory-domain sun
[Device-GigabitEthernet1/0/1] quit
3. Configure port security:
# Enable port security.
[Device] port-security enable

315
 # Add five OUI values. (You can add up to 16 OUI values. The port permits only one user
matching one of the OUIs to pass authentication.)
[Device] port-security oui index 1 mac-address 1234-0100-1111
[Device] port-security oui index 2 mac-address 1234-0200-1111
[Device] port-security oui index 3 mac-address 1234-0300-1111
[Device] port-security oui index 4 mac-address 1234-0400-1111
[Device] port-security oui index 5 mac-address 1234-0500-1111
# Set the port security mode to userLoginWithOUI.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] port-security port-mode userlogin-withoui
[Device-GigabitEthernet1/0/1] quit

Verifying the configuration

# Verify that GigabitEthernet 1/0/1 allows only one 802.1X user to be authenticated.
[Device] display port-security interface gigabitethernet 1/0/1
Global port security parameters:
Port security : Enabled
AutoLearn aging time : 30 min
Disableport timeout : 30 s
Blockmac timeout : 180 s
MAC move : Denied
Authorization fail : Online
NAS-ID profile : Not configured
Dot1x-failure trap : Disabled
Dot1x-logon trap : Disabled
Dot1x-logoff trap : Disabled
Intrusion trap : Disabled
Address-learned trap : Disabled
Mac-auth-failure trap : Disabled
Mac-auth-logon trap : Disabled
Mac-auth-logoff trap : Disabled
Open authentication : Disabled
OUI value list :
Index : 1 Value : 123401
Index : 2 Value : 123402
Index : 3 Value : 123403
Index : 4 Value : 123404
Index : 5 Value : 123405

GigabitEthernet1/0/1 is link-up
Port mode : userLoginWithOUI
NeedToKnow mode : Disabled
Intrusion protection mode : NoAction
Security MAC address attribute
Learning mode : Sticky
Aging type : Periodical
Max secure MAC addresses : Not configured
Current secure MAC addresses : 1
Authorization :Permitted

316
 NAS-ID profile : Not configured
Free VLANs : Not configured
Open authentication : Disabled
MAC-move VLAN check bypass : Disabled

# Display information about the online 802.1X user to verify 802.1X configuration.
[Device] display dot1x

# Verify that the port also allows one user whose MAC address has an OUI among the specified
OUIs to pass authentication.
[Device] display mac-address interface gigabitethernet 1/0/1
MAC Address VLAN ID State Port/NickName Aging
1234-0300-0011 1 Learned GE1/0/1 Y

Example: Configuring port security in

macAddressElseUserLoginSecure mode
Network configuration
As shown in Figure 87, a client is connected to the device through GigabitEthernet 1/0/1. The device
authenticates the client by a RADIUS server in ISP domain sun. If the authentication succeeds, the
client is authorized to access the Internet.
Configure GigabitEthernet 1/0/1 of the device to meet the following requirements:
• Allow more than one MAC authenticated user to log on.
• For 802.1X users, perform MAC authentication first and then, if MAC authentication fails,
802.1X authentication. Allow only one 802.1X user to log on.
• Use the MAC address of each user as both the username and password for MAC
authentication. The MAC addresses are in hexadecimal notation with hyphens, and letters are
in upper case.
• Set the total number of MAC authenticated users and 802.1X authenticated users to 64.
• Enable NTK (ntkonly mode) to prevent frames from being sent to unknown MAC addresses.
Figure 87 Network diagram

Authentication servers
(192.168.1.2/24
192.168.1.3/24)

GE1/0/1
Internet

Host Device

Procedure
Make sure the host and the RADIUS server can reach each other.
1. Configure RADIUS authentication/accounting and ISP domain settings. (See "Example:
Configuring port security in userLoginWithOUI mode.")
2. Configure port security:
# Enable port security.
<Device> system-view

317
 [Device] port-security enable
# Use the MAC address of each user as both the username and password for MAC
authentication. The MAC addresses are in hexadecimal notation with hyphens, and letters are
in upper case.
[Device] mac-authentication user-name-format mac-address with-hyphen uppercase
# Specify the MAC authentication domain.
[Device] mac-authentication domain sun
# Set the 802.1X authentication method to CHAP. By default, the authentication method for
802.1X is CHAP.
[Device] dot1x authentication-method chap
# Set port security's limit on the number of MAC addresses to 64 on the port.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] port-security max-mac-count 64
# Set the port security mode to macAddressElseUserLoginSecure.
[Device-GigabitEthernet1/0/1] port-security port-mode mac-else-userlogin-secure
# Specify ISP domain sun as the mandatory authentication domain for 802.1X users.
[Device-GigabitEthernet1/0/1] dot1x mandatory-domain sun
# Set the NTK mode of the port to ntkonly.
[Device-GigabitEthernet1/0/1] port-security ntk-mode ntkonly
[Device-GigabitEthernet1/0/1] quit

Verifying the configuration

# Verify the port security configuration.
[Device] display port-security interface gigabitethernet 1/0/1
Global port security parameters:
Port security : Enabled
AutoLearn aging time : 30 min
Disableport timeout : 30 s
Blockmac timeout : 180 s
MAC move : Denied
Authorization fail : Online
NAS-ID profile : Not configured
Dot1x-failure trap : Disabled
Dot1x-logon trap : Disabled
Dot1x-logoff trap : Disabled
Intrusion trap : Disabled
Address-learned trap : Disabled
Mac-auth-failure trap : Disabled
Mac-auth-logon trap : Disabled
Mac-auth-logoff trap : Disabled
Open authentication : Disabled
OUI value list

GigabitEthernet1/0/1 is link-up
Port mode : macAddressElseUserLoginSecure
NeedToKnow mode : NeedToKnowOnly
Intrusion protection mode : NoAction
Security MAC address attribute
Learning mode : Sticky

318
 Aging type : Periodical
Max secure MAC addresses : 64
Current secure MAC addresses : 0
Authorization : Permitted
NAS-ID profile : Not configured
Free VLANs : Not configured
Open authentication : Disabled
MAC-move VLAN check bypass : Disabled

# After users pass authentication, display MAC authentication information. Verify that
GigabitEthernet 1/0/1 allows multiple MAC authentication users to be authenticated.
[Device] display mac-authentication interface gigabitethernet 1/0/1
Global MAC authentication parameters:
MAC authentication : Enabled
Authentication method : PAP
User name format : MAC address in uppercase(XX-XX-XX-XX-XX-XX)
Username : mac
Password : Not configured
Offline detect period : 300 s
Quiet period : 180 s
Server timeout : 100 s
Reauth period : 3600 s
User aging period for critical VLAN : 1000 s
User aging period for critical VSI : 1000 s
User aging period for guest VLAN : 1000 s
User aging period for guest VSI : 1000 s
Authentication domain : sun
Online MAC-auth wired users : 3

Silent MAC users:

MAC address VLAN ID From port Port index

GigabitEthernet1/0/1 is link-up
MAC authentication : Enabled
Carry User-IP : Disabled
Authentication domain : Not configured
Auth-delay timer : Disabled
Periodic reauth : Disabled
Re-auth server-unreachable : Logoff
Guest VLAN : Not configured
Guest VLAN auth-period : 30 s
Critical VLAN : Not configured
Critical voice VLAN : Disabled
Host mode : Single VLAN
Offline detection : Enabled
Authentication order : Default
User aging : Enabled
Server-recovery online-user-sync : Enabled

319
 Guest VSI : Not configured
Guest VSI auth-period : 30 s
Critical VSI : Not configured
Max online users : 4294967295
Auto-tag feature : Disabled
VLAN tag configuration ignoring : Disabled
Authentication attempts : successful 3, failed 7
Current online users : 3
MAC address Auth state
1234-0300-0011 Authenticated
1234-0300-0012 Authenticated
1234-0300-0013 Authenticated

# Display 802.1X authentication information. Verify that GigabitEthernet 1/0/1 allows only one
802.1X user to be authenticated.
[Device] display dot1x interface gigabitethernet 1/0/1
Global 802.1X parameters:
802.1X authentication : Enabled
CHAP authentication : Enabled
Max-tx period : 30 s
Handshake period : 15 s
Quiet timer : Disabled
Quiet period : 60 s
Supp timeout : 30 s
Server timeout : 100 s
Reauth period : 3600 s
Max auth requests : 2
User aging period for Auth-Fail VLAN : 1000 s
User aging period for Auth-Fail VSI : 1000 s
User aging period for critical VLAN : 1000 s
User aging period for critical VSI : 1000 s
User aging period for guest VLAN : 1000 s
User aging period for guest VSI : 1000 s
EAD assistant function : Disabled
EAD timeout : 30 min
Domain delimiter : @
Online 802.1X wired users : 1

GigabitEthernet1/0/1 is link-up
802.1X authentication : Enabled
Handshake : Enabled
Handshake reply : Disabled
Handshake security : Disabled
Unicast trigger : Disabled
Periodic reauth : Disabled
Port role : Authenticator
Authorization mode : Auto
Port access control : MAC-based
Multicast trigger : Enabled

320
 Mandatory auth domain : sun
Guest VLAN : Not configured
Auth-Fail VLAN : Not configured
Critical VLAN : Not configured
Critical voice VLAN : Disabled
Add Guest VLAN delay : Disabled
Re-auth server-unreachable : Logoff
Max online users : 4294967295
User IP freezing : Disabled
Reauth period : 60 s
Send Packets Without Tag : Disabled
Max Attempts Fail Number : 0
Guest VSI : Not configured
Auth-Fail VSI : Not configured
Critical VSI : Not configured
Add Guest VSI delay : Disabled
User aging : Enabled
Server-recovery online-user-sync : Enabled

EAPOL packets: Tx 16331, Rx 102

Sent EAP Request/Identity packets : 16316
EAP Request/Challenge packets: 6
EAP Success packets: 4
EAP Failure packets: 5
Received EAPOL Start packets : 6
EAPOL LogOff packets: 2
EAP Response/Identity packets : 80
EAP Response/Challenge packets: 6
Error packets: 0
Online 802.1X users: 1
MAC address Auth state
0002-0000-0011 Authenticated

# Verify that frames with an unknown destination MAC address, multicast address, or broadcast
address are discarded. (Details not shown.)

Troubleshooting port security

Cannot set the port security mode
Symptom
Cannot set the port security mode for a port.
Analysis
For a port operating in a port security mode other than noRestrictions, you cannot change the port
security mode by using the port-security port-mode command.
Solution
To resolve the issue:

321
 1. Set the port security mode to noRestrictions.
[Device-GigabitEthernet1/0/1] undo port-security port-mode
2. Set a new port security mode for the port, for example, autoLearn.
[Device-GigabitEthernet1/0/1] port-security port-mode autolearn
3. If the issue persists, contact Hewlett Packard Enterprise Support.

Cannot configure secure MAC addresses

Symptom
Cannot configure secure MAC addresses.
Analysis
No secure MAC address can be configured on a port operating in a port security mode other than
autoLearn.
Solution
To resolve the issue:
1. Set the port security mode to autoLearn.
[Device-GigabitEthernet1/0/1] undo port-security port-mode
[Device-GigabitEthernet1/0/1] port-security max-mac-count 64
[Device-GigabitEthernet1/0/1] port-security port-mode autolearn
[Device-GigabitEthernet1/0/1] port-security mac-address security 1-1-2 vlan 1
2. If the issue persists, contact Hewlett Packard Enterprise Support.

322
Configuring user profiles
About user profiles
A user profile defines a set of parameters, such as a QoS policy, for a user or a class of users. A user
profile can be reused when a user connected to the network on a different interface.
The user profile application allows flexible traffic policing on a per-user basis. Each time a user
passes authentication, the server sends the device the name of the user profile specified for the user.
The device applies the parameters in the user profile to the user.
User profiles are typically used for resource allocation per user. For example, the interface-based
traffic policing limits the total amount of bandwidth available to a group of users. However,
user-profile-based traffic policing can limit the amount of bandwidth available to a single user.

Prerequisites for user profile

A user profile works with authentication methods. You must configure authentication for a user profile.
For information about supported authentication methods, see the configuration guides for the related
authentication modules.

Configuring a user profile Configuring a user

profile
1. Enter system view.
system-view
2. Create a user profile and enter user profile view.
user-profile profile-name
3. Configure the user profile. Choose the options to configure as needed:
 Apply an existing QoS policy to the user profile.
qos apply policy policy-name { inbound | outbound }
By default, no QoS policy is applied to a user profile.
 Configure a CAR policy for the user profile.
qos car { inbound | outbound } any cir committed-information-rate
[ cbs committed-burst-size [ ebs excess-burst-size ] ]
qos car { inbound | outbound } any cir committed-information-rate
[ cbs committed-burst-size ] pir peak-information-rate [ ebs
excess-burst-size ]
By default, no CAR policy is configured for a user profile.
For more information about QoS policies and CAR policies, see ACL and QoS Configuration
Guide.

Display and maintenance commands for user

profiles
Execute display commands in any view.

323
 Task Command
Display configuration and online display user-profile [ name profile-name ] [ slot
user information for the specified
user profile or all user profiles.
slot-number ]

User profile configuration examples

Example: Configuring user profiles and QoS policies
Network requirements
As shown in Figure 88, the device performs local 802.1X authentication on the users in domain user
for authentication and authorization efficiency.
Configure user profiles and QoS policies on the device to meet the following requirements:
• User A cannot access the Internet during 8: 30 and 12:00 every day even if User A passes
802.1X authentication.
• User B has an upload speed of 2 Mbps after passing 802.1X authentication.
• User C has a download speed of 4 Mbps after passing 802.1X authentication.
Figure 88 Network diagram

GE1/0/1
Internet

Device
User A User B

Domain: user
User C

Configuration procedure
1. Configure a QoS policy for User A:
# Create a periodic time range from 8:30 to 12:00 every day.
<Device> system-view
[Device] time-range for_usera 8:30 to 12:00 daily
# Create IPv4 basic ACL 2000, and configure a rule to match all packets during the time range
for_usera.
[Device] acl basic 2000
[Device-acl-basic-2000] rule permit time-range for_usera
[Device-acl-basic-2000] quit
# Create a traffic class named for_usera, and use ACL 2000 as the match criterion.
[Device] traffic classifier for_usera
[Device-classifier-for_usera] if-match acl 2000
[Device-classifier-for_usera] quit
# Create a traffic behavior named for_usera, and configure the deny action.
[Device] traffic behavior for_usera

324
 [Device-behavior-for_usera] filter deny
[Device-behavior-for_usera] quit
# Create a QoS policy named for_usera, and associate traffic class for_usera and traffic
behavior for_usera in the QoS policy.
[Device] qos policy for_usera
[Device-qospolicy-for_usera] classifier for_usera behavior for_usera
[Device-qospolicy-for_usera] quit
2. Create a user profile for User A and apply the QoS policy to the user profile:
# Create a user profile named usera.
[Device] user-profile usera
# Apply QoS policy for_usera to the inbound direction of user profile usera.
[[Device-user-profile-usera] qos apply policy for_usera inbound
[Device-user-profile-usera] quit
3. Configure a QoS policy for limiting the traffic rate for User B:
# Create a traffic class named class to match all packets.
[Device] traffic classifier class
[Device-classifier-class] if-match any
[Device-classifier-class] quit
# Create a traffic behavior named for_userb, and configure a traffic policing action (CIR 2000
kbps).
[Device] traffic behavior for_userb
[Device-behavior-for_userb] car cir 2000
[Device-behavior-for_userb] quit
# Create a QoS policy named for_userb, and associate traffic class class and traffic behavior
for_userb in the QoS policy.
[Device] qos policy for_userb
[Device-qospolicy-for_userb] classifier class behavior for_userb
[Device-qospolicy-for_userb] quit
4. Create a user profile for User B and apply the QoS policy to the user profile:
# Create a user profile named userb.
[Device] user-profile userb
# Apply QoS policy for_userb to the inbound direction of user profile userb.
[Device-user-profile-userb] qos apply policy for_userb inbound
[Device-user-profile-userb] quit
5. Configure a QoS policy for limiting the traffic rate for User C:
# Create a traffic behavior named for_userc, and configure a traffic policing action (CIR 4000
kbps).
[Device] traffic behavior for_userc
[Device-behavior-for_userc] car cir 4000
[Device-behavior-for_userc] quit
# Create a QoS policy named for_userc, and associate traffic class class and traffic behavior
for_userc in the QoS policy.
[Device] qos policy for_userc
[Device-qospolicy-for_userc] classifier class behavior for_userc
[Device-qospolicy-for_userc] quit
6. Create a user profile for User C and apply the QoS policy to the user profile:
# Create a user profile named userc.
[Device] user-profile userc

325
 # Apply QoS policy for_userc to the outbound direction of user profile userc.
[Device-user-profile-userc] qos apply policy for_userc outbound
[Device-user-profile-userc] quit
7. Configure local users:
# Create a local user named usera.
[Device] local-user usera class network
New local user added.
# Set the password to a12345 for user usera.
[Device-luser-network-usera] password simple a12345
# Authorize user usera to use the LAN access service.
[Device-luser-network-usera] service-type lan-access
# Specify user profile usera as the authorization user profile for user usera.
[Device-luser-network-usera] authorization-attribute user-profile usera
[Device-luser-network-usera] quit
# Create a local user named userb.
[Device] local-user userb class network
New local user added.
# Set the password to b12345 for user userb.
[Device-luser-network-userb] password simple b12345
# Authorize user userb to use the LAN access service.
[Device-luser-network-userb] service-type lan-access
# Specify user profile userb as the authorization user profile for user userb.
[Device-luser-network-userb] authorization-attribute user-profile userb
[Device-luser-network-userb] quit
# Create a local user named userc.
[Device] local-user userc class network
New local user added.
# Set the password to c12345 for user userc.
[Device-luser-network-userc] password simple c12345
# Authorize user userc to use the LAN access service.
[Device-luser-network-userc] service-type lan-access
# Specify user profile userc as the authorization user profile for user userc.
[Device-luser-network-userc] authorization-attribute user-profile userc
[Device-luser-network-userc] quit
8. Configure the authentication, authorization, and accounting methods for local users:
[Device] domain user
[Device-isp-user] authentication lan-access local
[Device-isp-user] authorization lan-access local
[Device-isp-user] accounting login none
[Device-isp-user] quit
9. Configure 802.1X:
# Enable 802.1X on GigabitEthernet 1/0/1.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] dot1x
# Enable MAC-based access control on the port. By default, a port uses MAC-based access
control.
[Device-GigabitEthernet1/0/1] dot1x port-method macbased

326
 [Device-GigabitEthernet1/0/1] quit
# Enable 802.1X globally.
[Device] dot1x

Verifying the configuration

# Verify that the three users can pass 802.1X authentication and that QoS policies take effect on
these users. (Details not shown.)
# Display user profile information.
<Device> display user-profile
User-Profile: usera
Inbound:
Policy: for_usera

slot 1:
User -:
Authentication type: 802.1X
Network attributes:
Interface : GigabitEthernet1/0/1
MAC address : 6805-ca06-557b
Service VLAN : 1

User-Profile: userb
Inbound:
Policy: for_userb

slot 1:
User -:
Authentication type: 802.1X
Network attributes:
Interface : GigabitEthernet1/0/1
MAC address : 80c1-6ee0-2664
Service VLAN : 1

User-Profile: userc
Outbound:
Policy: for_userc

slot 1:
User -:
Authentication type: 802.1X
Network attributes:
Interface : GigabitEthernet1/0/1
MAC address : 6805-ca05-3efa
Service VLAN : 1

327
Configuring password control
About password control
Password control allows you to implement the following features:
• Manage login and super password setup, expirations, and updates for local users.
• Control user login status based on predefined policies.
For more information about local users, see "Configuring AAA." For information about super
passwords, see RBAC in Fundamentals Configuration Guide.

Password setting
Minimum password length
You can define the minimum length of user passwords. The system rejects the setting of a password
that is shorter than the configured minimum length.
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 in Table 28. For more information about special characters, see CLI in
Fundamentals Configuration Guide.
Table 28 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 bracket ]

Right parenthesis ) Semi-colon ;

328
 Character name Symbol Character name Symbol
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 29.
Table 29 Password composition policy

Password combination Minimum number of Minimum number of characters

level character types for each type
Level 1 One One
Level 2 Two One
Level 3 Three One
Level 4 Four One

When a user sets or changes a password, the system checks if the password meets the combination
requirement. If it does not, the operation fails.
Password complexity checking policy
A less complicated password is more likely to be cracked, such as a password containing the
username or repeated characters. For higher security, you can configure a password complexity
checking policy to ensure that all user passwords are relatively complicated. When a user configures
a password, the system checks the complexity of the password. If the password is
complexity-incompliant, the configuration will 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 minimum of three identical consecutive characters is not allowed. For example, password
a111 is not complex enough.

Password updating and expiration

Password updating
This feature allows you to set the minimum interval at which users can change their passwords. A
user can only change the password once within the specified interval.
The minimum interval does not apply to the following situations:
• A user is prompted to change the password at first login.
• The 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.
The system displays an error message for a login attempt with an expired password. The user is
asked to provide a new password. 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. FTP users must have
their passwords changed by the administrator.

329
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. If 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 valid password, the system records the new password and the setup time.
• If the user does not or fails to change the password, the system allows the user to log in by
using the current password until the password expires.
Telnet users, SSH users, and console users can change their own passwords. FTP users must have
their passwords changed by the administrator.
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
This feature allows the system to store passwords that a user has used.
When a network access user changes the password, the system compares the new password with
the current password and those stored in the password history records. The new password must be
different from the current one and those stored in the history records by a minimum of four different
characters. Otherwise, the system will display an error message, and the new password is not
successfully set.
The local passwords and super passwords for device management users are stored in hash form
and cannot be converted to plain texts. When a device management user changes a local password
or super password, follow these rules:
• If the new password is set by using the hash method, the system will not compare the new
password with the current one and those stored in the history password records.
• If the new password in set in plain text, the system compares the new password with the current
password and those stored in the password history records. A new password must be different
from those stored in the history password records. If the current password is required, the new
password must also be different from the current one by a minimum of four different characters.
Otherwise, the system will display an error message, and the new password is not successfully
set.
You can set the maximum number of history password records for the system to maintain for each
user. When the number of history password records exceeds the setting, the most recent record
overwrites the earliest one.
Current login passwords are not stored in the password history for device management users.
Device management users have their passwords saved in cipher text, which cannot be recovered to
plaintext passwords.

User login control

First login
By default, if the global password control feature is enabled, users must change the password at first
login before they can access the system. In this situation, password changes are not subject to the
minimum password update interval. If it is not necessary for users to change the password at first
login, disable the password change at first login feature.
Password control blacklist
The password control blacklist prevents abnormal users from logging in by recording the login
failures and maintaining the status of blacklisted user accounts.

330
 If an FTP or VTY user fails to log in, the system adds the user account and the user's IP address to
the password control blacklist. If an AUX or USB user fails to log in, the system adds the user
account to the password control blacklist.
Login attempt limit
Limiting the number of consecutive login failures can effectively prevent password guessing.
When a user fails the maximum number of consecutive attempts, login attempt limit limits the user
and user account in any of the following ways:
• For an FTP, or VTY user, the system prohibits the user from using the user account to log in
through the user's IP address. For an AUX or USB user, the system prohitibs the user from
logging in through AUX or USB user line. The locked user can use their own account to log in to
the device only after the account is manually removed from the password control blacklist.
• Allows the user to continue using the user account. The user account is removed from the
password control blacklist when the user uses this account to successfully log in to the device.
• Locks the user account and the user's IP address for a period of time.
The user can use the account to log in when either of the following conditions exists:
 The locking timer expires.
 The account is manually removed from the password control blacklist before the locking
timer expires.

NOTE:
This account is locked only for the user at the locked IP address. A user from an unlocked IP
address can still use this account, and the user at the locked IP address can use other
unlocked user accounts.

Maximum account idle time

You can set the maximum account idle time for user accounts. When an account is idle for this period
of time since the last successful login, the account becomes invalid.
Login control with a weak password
The system checks for weak passwords for Telnet, SSH, HTTP, or HTTPS device management
users. A password is weak if it does not meet the following requirements:
• Password composition restriction.
• Minimum password length restriction.
• Password complexity checking policy.
By default, the system displays a message about a weak password but does not force the user to
change it. To improve the device security, you can enable the mandatory weak password change
feature, which forces the users to change the identified weak passwords. The users can log in to the
device only after their passwords meet the password requirements.

Password not displayed in any form

For security purposes, nothing is displayed when a user enters a password.

Logging
The system generates a log each time a user changes its password successfully or is added to the
password control blacklist because of login failures.

331
FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for
features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and
non-FIPS mode.

Restrictions and guidelines: Password control

configuration
IMPORTANT:
To successfully enable the global password control feature and allow device management users to
log in to the device, make sure the device have sufficient storage space.

The password control features can be configured in several different views, and different views
support different features. The settings configured in different views or for different objects have the
following application ranges:
• Settings for super passwords apply only to super passwords.
• Settings in local user view apply only to the password of the local user.
• Settings in user group view apply to the passwords of the local users in the user group if you do
not configure password policies for these users in local user view.
• Global settings in system view apply to the passwords of the local users in all user groups if you
do not configure password policies for these users in both local user view and user group view.
For local user passwords, the settings with a smaller application scope have higher priority.

Password control tasks at a glance

To configure password control, perform the following tasks:
1. Enabling password control
2. (Optional.) Setting global password control parameters
3. (Optional.) Setting user group password control parameters
4. (Optional.) Setting local user password control parameters
5. (Optional.) Setting super password control parameters

Enabling password control

About this task
Enabling global password control is a prerequisite for password expiration and password history
management to take effect. For the password expiration or password history management to take
effect, make sure you enable both the global password control feature and the specific password
restriction.
Restrictions and guidelines
After global password control is enabled, follow these restrictions and guidelines:
• You cannot display the password and super password configurations for device management
users by using the corresponding display commands.

332
 • You cannot display the password configuration for network access users by using the
corresponding display command.
• A password configured for local users must contain a minimum of four different characters.
• In FIPS mode, the global password control feature is enabled for device management users
and cannot be disabled for them.
• To ensure correct function of password control, configure the device to use NTP to obtain the
UTC time. After global password control is enabled, password control will record the UTC time
when the password is set. The recorded UTC time might not be consistent with the actual UTC
time due to power failure or device reboot. The inconsistency will cause the password
expiration feature to malfunction. For information about NTP, see Network Management and
Monitoring Configuration Guide.
• The device automatically generates a .dat file and saves the file to the storage media. The file is
used to record authentication and login information of the local users. Do not manually delete or
modify the file.
• The global password control feature enables the system to record history passwords. When the
number of history password records of a user reaches the maximum number, the newest
history record overwrites the earliest one. To delete the existing history password records, use
one of the following methods:
 Use the undo password-control enable command to disable the password control
feature globally.
 Use the reset password-control history-record command to clear the
passwords manually.
Procedure
1. Enter system view.
system-view
2. Enable the global password control feature.
In non-FIPS mode:
password-control enable [ network-class ]
By default, the global password control feature is disabled for device management and network
access users.
In FIPS mode:
password-control enable [ network-class ]
By default, the global password control feature is enabled for device management users and
cannot be disabled. The global password control feature is disabled for network access users.
3. (Optional.) Enable a password restriction feature.
password-control { aging | composition | history | length } enable
By default, all four password restriction features are enabled.

Setting global password control parameters

Restrictions and guidelines
The global password control parameters in system view apply to all device management and
network access local users.
You can configure all password control features for device management users. The password aging
time, minimum password length, password complexity policy, password composition policy, and user
login attempt limit can be configured in system view, user group view, and local user view.
You can configure only the following password control features for network access users:

333
 • Minimum password length.
• Password complexity policy.
• Password composition policy.
• Minimum password update interval.
• Maximum number of history password records for each user.
Where, the minimum password length, password complexity policy, and password composition
policy can be configured in system view, user group view, and local user view.
The password settings with a smaller application scope have higher priority. For local users,
password settings configured in local user view have the highest priority, and global settings in
system view have the lowest priority.
The password-control login-attempt command takes effect immediately and can affect
the users already in the password control blacklist. Other password control configurations do not
take effect on users that have been logged in or passwords that have been configured.
Procedure
1. Enter system view.
system-view
2. Configure password settings.
 Set the minimum password length.
In non-FIPS mode:
password-control length length
The default setting is 10 characters.
In FIPS mode:
password-control length length
The default length is 15 characters.
 Configure the password composition policy.
In non-FIPS mode:
password-control composition type-number type-number
[ type-length type-length ]
By default, a password must contain a minimum of two character types and a minimum of
one character for each type.
In FIPS mode:
password-control composition type-number type-number
[ type-length type-length ]
By default, a password must contain a minimum of four character types and a minimum of
one character for each type.
 Configure the password complexity checking policy.
password-control complexity { same-character | user-name } check
In non-FIPS mode:
By default, the username checking is enabled but repeated character checking is disabled.
In FIPS mode:
By default, the system does not perform password complexity checking.
 Set the maximum number of history password records for each user.
password-control history max-record-number
The default setting is 4.
3. Configure password updating and expiration.

334
  Set the minimum password update interval.
password-control update interval interval
The default setting is 24 hours.
 Set the password aging time.
password-control aging aging-time
The default setting is 90 days.
 Set the number of days during which a user is notified of the pending password expiration.
password-control alert-before-expire alert-time
The default setting is 7 days.
 Set the maximum number of days and maximum number of times that a user can log in after
the password expires.
password-control expired-user-login delay delay times times
By default, a user can log in three times within 30 days after the password expires.
4. Configure user login control.
 Enable the password control blacklist feature for all user line types.
password-control blacklist all-line
By default, the password control blacklist feature is disabled for all user line types. The
password control blacklist feature is enabled only for FTP and VTY users when you enable
the global password control feature.
 Configure the login attempt limit.
password-control login-attempt login-times [ exceed { lock |
lock-time time | unlock } ]
By default, the maximum number of login attempts is 3 and a user failing to log in after the
specified number of attempts must wait for 1 minute before trying again.
 Set the maximum account idle time.
password-control login idle-time idle-time
The default setting is 90 days.
If a user account is idle for this period of time, the account becomes invalid and can no
longer be used to log in to the device. To disable the account idle time restriction, set the idle
time value to 0.
 Set the user authentication timeout time.
password-control authentication-timeout timeout
The default setting is 600 seconds.
This command takes effect only on Telnet and terminal users.
 Disable password change at first login.
undo password-control change-password first-login enable
By default, the password change at first login feature is enabled.
In FIPS mode, the password change at first login feature cannot be disabled.
 Enable mandatory weak password change.
password-control change-password weak-password enable
By default, the mandatory weak password change feature is disabled.

Setting user group password control parameters

1. Enter system view.

335
 system-view
2. Create a user group and enter its view.
user-group group-name
For information about how to configure a user group, see "Configuring AAA."
3. Configure the password aging time for the user group.
password-control aging aging-time
By default, the password aging time of the user group equals the global password aging time.
4. Configure the minimum password length for the user group.
password-control length length
By default, the minimum password length of the user group equals the global minimum
password length.
5. Configure the password composition policy for the user group.
password-control composition type-number type-number [ type-length
type-length ]
By default, the password composition policy of the user group equals the global password
composition policy.
6. Configure the password complexity checking policy for the user group.
password-control complexity { same-character | user-name } check
By default, the password complexity checking policy of the user group equals the global
password complexity checking policy.
7. Configure the login attempt limit.
password-control login-attempt login-times [ exceed { lock | lock-time
time | unlock } ]
By default, the login-attempt policy of the user group equals the global login-attempt policy.

Setting local user password control parameters

1. Enter system view.
system-view
2. Create a device management or network access user and enter its view.
 Create a device management user and enter its view.
local-user user-name class manage
 Create a network access user and enter its view.
local-user user-name class network
For information about local user configuration, see "Configuring AAA."
3. Configure the password aging time for the local user.
password-control aging aging-time
By default, the setting equals that for the user group to which the local user belongs. If no aging
time is configured for the user group, the global setting applies to the local user.
This command is available only for device management users.
4. Configure the minimum password length for the local user.
password-control length length
By default, the setting equals that for the user group to which the local user belongs. If no
minimum password length is configured for the user group, the global setting applies to the
local user.
5. Configure the password composition policy for the local user.

336
 password-control composition type-number type-number [ type-length
type-length ]
By default, the settings equal those for the user group to which the local user belongs. If no
password composition policy is configured for the user group, the global settings apply to the
local user.
6. Configure the password complexity checking policy for the local user.
password-control complexity { same-character | user-name } check
By default, the settings equal those for the user group to which the local user belongs. If no
password complexity checking policy is configured for the user group, the global settings apply
to the local user.
7. Configure the login attempt limit.
password-control login-attempt login-times [ exceed { lock | lock-time
time | unlock } ]
By default, the settings equal those for the user group to which the local user belongs. If no
login-attempt policy is configured for the user group, the global settings apply to the local user.
This command is available only for device management users.

Setting super password control parameters

1. Enter system view.
system-view
2. Set the password aging time for super passwords.
password-control super aging aging-time
The default setting is 90 days.
3. Configure the minimum length for super passwords.
In non-FIPS mode:
password-control super length length
The default setting is 10 characters.
In FIPS mode:
password-control super length length
The default setting is 15 characters.
4. Configure the password composition policy for super passwords.
In non-FIPS mode:
password-control super composition type-number type-number
[ type-length type-length ]
By default, a super password must contain a minimum of two character types and a minimum of
one character for each type.
In FIPS mode:
password-control super composition type-number type-number
[ type-length type-length ]
By default, a super password must contain a minimum of four character types and a minimum of
one character for each type.

337
Display and maintenance commands for
password control
Execute display commands in any view and reset commands in user view.

Task Command
Display password control configuration. display password-control [ super ]
display password-control blacklist
Display information about users in the
[ user-name user-name | ip ipv4-address
password control blacklist.
| ipv6 ipv6-address]
Delete users from the password control reset password-control blacklist
blacklist. [ user-name user-name ]
reset password-control history-record
[ user-name user-name | super [ role
Clear history password records.
role-name ] | network-class [ user-name
user-name ] ]

Password control configuration examples

Example: Configuring password control
Network configuration
Configure a global password control policy to meet the following requirements:
• A password must contain a minimum of 16 characters.
• A password must contain a minimum of four character types and a minimum of four characters
for each type.
• An FTP or VTY user failing to provide the correct password in two successive login attempts is
permanently prohibited from logging in with the current IP address.
• A user can log in five times within 60 days after the password expires.
• A password expires after 30 days.
• The minimum password update interval is 36 hours.
• The maximum account idle time is 30 days.
• A password cannot contain the username or the reverse of the username.
• A minimum of three identical consecutive characters is not allowed in a password.
Configure a super password control policy for user role network-operator to meet the following
requirements:
• A super password must contain a minimum of 24 characters.
• A super password must contain a minimum of four character types and a minimum of five
characters for each type.
Configure a password control policy for local Telnet user test to meet the following requirements:
• The password must contain a minimum of 24 characters.
• The password must contain a minimum of four character types and a minimum of five
characters for each type.

338
 • The password for the local user expires after 20 days.
Procedure
# Enable the password control feature globally.
<Sysname> system-view
[Sysname] password-control enable

# Allow a maximum of two consecutive login failures on a user account, and lock the user account
and the user's IP address permanently if the limit is reached.
[Sysname] password-control login-attempt 2 exceed lock

# Set all passwords to expire after 30 days.

[Sysname] password-control aging 30

# Globally set the minimum password length to 16 characters.

[Sysname] password-control length 16

# Set the minimum password update interval to 36 hours.

[Sysname] password-control update-interval 36

# Specify that a user can log in five times within 60 days after the password expires.
[Sysname] password-control expired-user-login delay 60 times 5

# Set the maximum account idle time to 30 days.

[Sysname] password-control login idle-time 30

# Refuse any password that contains the username or the reverse of the username.
[Sysname] password-control complexity user-name check

# Refuse a password that contains a minimum of three identical consecutive characters.

[Sysname] password-control complexity same-character check

# Globally specify that all passwords must each contain a minimum of four character types and a
minimum of four characters for each type.
[Sysname] password-control composition type-number 4 type-length 4

# Set the minimum super password length to 24 characters.

[Sysname] password-control super length 24

# Specify that a super password must contain a minimum of four character types and a minimum of
five characters for each type.
[Sysname] password-control super composition type-number 4 type-length 5

# Configure a super password used for switching to user role network-operator as

123456789ABGFTweuix@#$%! in plain text.
[Sysname] super password role network-operator simple 123456789ABGFTweuix@#$%!

# Create a device management user named test.

[Sysname] local-user test class manage

# Set the service type of the user to Telnet.

[Sysname-luser-manage-test] service-type telnet

# Set the minimum password length to 24 for the local user.

[Sysname-luser-manage-test] password-control length 24

# Specify that the password of the local user must contain a minimum of four character types and a
minimum of five characters for each type.
[Sysname-luser-manage-test] password-control composition type-number 4 type-length 5

# Set the password for the local user to expire after 20 days.
[Sysname-luser-manage-test] password-control aging 20

339
 # Configure the password of the local user in interactive mode.
[Sysname-luser-manage-test] password
Password:
Confirm :
Updating user information. Please wait ... ...
[Sysname-luser-manage-test] quit

Verifying the configuration

# Display the global password control configuration.
<Sysname> display password-control
Global password control configurations:
Password control: Enabled(device management users)
Disabled (network access users)
Password aging: Enabled (30 days)
Password length: Enabled (16 characters)
Password composition: Enabled (4 types, 4 characters per type)
Password history: Enabled (max history record:4)
Early notice on password expiration: 7 days
User authentication timeout: 600 seconds
Maximum login attempts: 2
Action for exceeding login attempts: Lock
Minimum interval between two updates: 36 hours
User account idle time: 30 days
Logins with aged password: 5 times in 60 days
Password complexity: Enabled (username checking)
Enabled (repeated characters checking)
Password change: Enabled (first login)
Disabled (mandatory weak password change)
All line: Disabled (all line blacklist)

# Display the password control configuration for super passwords.

<Sysname> display password-control super
Super password control configurations:
Password aging: Enabled (90 days)
Password length: Enabled (24 characters)
Password composition: Enabled (4 types, 5 characters per type)

# Display the password control configuration for local user test.

<Sysname> display local-user user-name test class manage
Total 1 local users matched.

Device management user test:

State: Active
Service type: Telnet
User group: system
Bind attributes:
Authorization attributes:
Work directory: flash:
User role list: network-operator
Password control configurations:

340
Password aging: 20 days
Password length: 24 characters
Password composition: 4 types, 5 characters per type

341
Configuring keychains
About keychains
A keychain, a sequence of keys, provides dynamic authentication to ensure secure communication
by periodically changing the key and authentication algorithm without service interruption.
A keychain operates in absolute time mode. In this mode, each time point during a key's lifetime is
the UTC time and is not affected by the system's time zone or daylight saving time.
Each key in a keychain has a key string, authentication algorithm, sending lifetime, and receiving
lifetime. When the system time is within the lifetime of a key in a keychain, an application uses the
key to authenticate incoming and outgoing packets. The keys in the keychain take effect one by one
according to the sequence of the configured lifetimes. In this way, the authentication algorithms and
keys are dynamically changed to implement dynamic authentication.

Restrictions and guidelines: Keychain

configuration
To make sure only one key in a keychain is used at a time to authenticate packets to a peer, set
non-overlapping sending lifetimes for the keys in the keychain.
The keys used by the local device and the peer device must have the same authentication algorithm
and key string.

Configuring a keychain
1. Enter system view.
system-view
2. Create a keychain and enter keychain view.
keychain keychain-name mode absolute
3. (Optional.) Configure TCP authentication.
 Set the kind value in the TCP Enhanced Authentication Option.
tcp-kind kind-value
By default, the kind value is 254.
 Set an algorithm ID for a TCP authentication algorithm.
tcp-algorithm-id { hmac-md5 | md5 } algorithm-id
By default, the algorithm ID is 3 for the MD5 authentication algorithm and 5 for the
HMAC-MD5 authentication algorithm.
When the local device uses TCP to communicate with a peer device from another vendor, make
sure both devices have the same kind value and algorithm ID settings. If they do not, modify the
settings on the local device.
4. (Optional.) Set a tolerance time for accept keys in the keychain.
accept-tolerance { value | infinite }
By default, no tolerance time is configured for accept keys in a keychain.
If authentication information is changed, information mismatch occurs on the local and peer
devices, and the service might be interrupted. Use this command to ensure continuous packet
authentication.

342
 5. Create a key and enter key view.
key key-id
6. Configure the key.
 Specify an authentication algorithm for the key.
authentication-algorithm { hmac-md5 | hmac-sha-256 | md5 }
By default, no authentication algorithm is specified for a key.
 Configure a key string for the key.
key-string { cipher | plain } string
By default, no key string is configured.
 Set the sending lifetime in UTC mode for the key.
send-lifetime utc start-time start-date { duration { duration-value
| infinite } | to end-time end-date }
By default, the sending lifetime is not configured for a key.
 Set the receiving lifetime in UTC mode for the key.
accept-lifetime utc start-time start-date { duration
{ duration-value | infinite } | to end-time end-date }
By default, the receiving lifetime is not configured for a key.
 (Optional.) Specify the key as the default send key.
default-send-key
You can specify only one key as the default send key in a keychain.

Display and maintenance commands for keychain

Execute display commands in any view.

Task Command
display keychain [ name keychain-name [ key
Display keychain information.
key-id ] ]

Keychain configuration example

Example: Configuring keychains
Network configuration
As shown in Figure 89, establish an OSPF neighbor relationship between Switch A and Switch B,
and use a keychain to authenticate packets between the switches. Configure key 1 and key 2 for the
keychain and make sure key 2 is used immediately when key 1 expires.
Figure 89 Network diagram
Vlan-int100 Vlan-int100
192.1.1.1/24 192.1.1.2/24

Switch A Switch B

Procedure
1. Configure Switch A:

343
 # Configure IP addresses for interfaces. (Details not shown.)
# Configure OSPF.
<SwitchA> system-view
[SwitchA] ospf 1 router-id 1.1.1.1
[SwitchA-ospf-1] area 0
[SwitchA-ospf-1-area-0.0.0.0] network 192.1.1.0 0.0.0.255
[SwitchA-ospf-1-area-0.0.0.0] quit
[SwitchA-ospf-1] quit
# Create a keychain named abc, and specify the absolute time mode for it.
[SwitchA] keychain abc mode absolute
# Create key 1 for keychain abc, specify an authentication algorithm, and configure a key string
and the sending and receiving lifetimes for the key.
[SwitchA-keychain-abc] key 1
[SwitchA-keychain-abc-key-1] authentication-algorithm md5
[SwitchA-keychain-abc-key-1] key-string plain 123456
[SwitchA-keychain-abc-key-1] send-lifetime utc 10:00:00 2015/02/06 to 11:00:00
2015/02/06
[SwitchA-keychain-abc-key-1] accept-lifetime utc 10:00:00 2015/02/06 to 11:00:00
2015/02/06
[SwitchA-keychain-abc-key-1] quit
# Create key 2 for keychain abc, specify an authentication algorithm, and configure a key string
and the sending and receiving lifetimes for the key.
[SwitchA-keychain-abc] key 2
[SwitchA-keychain-abc-key-2] authentication-algorithm hmac-md5
[SwitchA-keychain-abc-key-2] key-string plain pwd123
[SwitchA-keychain-abc-key-2] send-lifetime utc 11:00:00 2015/02/06 to 12:00:00
2015/02/06
[SwitchA-keychain-abc-key-2] accept-lifetime utc 11:00:00 2015/02/06 to 12:00:00
2015/02/06
[SwitchA-keychain-abc-key-2] quit
[SwitchA-keychain-abc] quit
# Configure VLAN-interface 100 to use keychain abc for authentication.
[SwitchA] interface vlan-interface 100
[SwitchA-Vlan-interface100] ospf authentication-mode keychain abc
[SwitchA-Vlan-interface100] quit
2. Configure Switch B:
# Configure IP addresses for interfaces. (Details not shown.)
# Configure OSPF.
[SwitchB] ospf 1 router-id 2.2.2.2
[SwitchB-ospf-1] area 0
[SwitchB-ospf-1-area-0.0.0.0] network 192.1.1.0 0.0.0.255
[SwitchB-ospf-1-area-0.0.0.0] quit
[SwitchB-ospf-1] quit
# Create a keychain named abc, and specify the absolute time mode for it.
[SwitchB] keychain abc mode absolute
# Create key 1 for keychain abc, specify an authentication algorithm, and configure a key string
and the sending and receiving lifetimes for the key.
[SwitchB-keychain-abc] key 1
[SwitchB-keychain-abc-key-1] authentication-algorithm md5

344
 [SwitchB-keychain-abc-key-1] key-string plain 123456
[SwitchB-keychain-abc-key-1] send-lifetime utc 10:00:00 2015/02/06 to 11:00:00
2015/02/06
[SwitchB-keychain-abc-key-1] accept-lifetime utc 10:00:00 2015/02/06 to 11:00:00
2015/02/06
[SwitchB-keychain-abc-key-1] quit
# Create key 2 for keychain abc, specify an authentication algorithm, and configure a key string
and the sending and receiving lifetimes for the key.
[SwitchB-keychain-abc] key 2
[SwitchB-keychain-abc-key-2] authentication-algorithm hmac-md5
[SwitchB-keychain-abc-key-2] key-string plain pwd123
[SwitchB-keychain-abc-key-2] send-lifetime utc 11:00:00 2015/02/06 to 12:00:00
2015/02/06
[SwitchB-keychain-abc-key-2] accept-lifetime utc 11:00:00 2015/02/06 to 12:00:00
2015/02/06
[SwitchB-keychain-abc-key-2] quit
[SwitchB-keychain-abc] quit
# Configure VLAN-interface 100 to use keychain abc for authentication.
[SwitchB] interface vlan-interface 100
[SwitchB-Vlan-interface100] ospf authentication-mode keychain abc
[SwitchB-Vlan-interface100] quit

Verifying the configuration

1. When the system time is within the lifetime from 10:00:00 to 11:00:00 on the day 2015/02/06,
verify the status of the keys in keychain abc.
# Display keychain information on Switch A. The output shows that key 1 is the valid key.
[SwitchA] display keychain

Keychain name : abc

Mode : absolute
Accept tolerance : 0
TCP kind value : 254
TCP algorithm value
HMAC-MD5 : 5
MD5 : 3
Default send key ID : None
Active send key ID : 1
Active accept key IDs: 1

Key ID : 1
Key string : $c$3$dYTC8QeOKJkwFwP2k/rWL+1p6uMTw3MqNg==
Algorithm : md5
Send lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06
Send status : Active
Accept lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06
Accept status : Active

Key ID : 2
Key string : $c$3$7TSPbUxoP1ytOqkdcJ3K3x0BnXEWl4mOEw==

345
 Algorithm : hmac-md5
Send lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06
Send status : Inactive
Accept lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06
Accept status : Inactive
# Display keychain information on Switch B. The output shows that key 1 is the valid key.
[SwitchB]display keychain

Keychain name : abc

Mode : absolute
Accept tolerance : 0
TCP kind value : 254
TCP algorithm value
HMAC-MD5 : 5
MD5 : 3
Default send key ID : None
Active send key ID : 1
Active accept key IDs: 1

Key ID : 1
Key string : $c$3$/G/Shnh6heXWprlSQy/XDmftHa2JZJBSgg==
Algorithm : md5
Send lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06
Send status : Active
Accept lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06
Accept status : Active

Key ID : 2
Key string : $c$3$t4qHAw1hpZYN0JKIEpXPcMFMVT81u0hiOw==
Algorithm : hmac-md5
Send lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06
Send status : Inactive
Accept lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06
Accept status : Inactive
2. When the system time is within the lifetime from 11:00:00 to 12:00:00 on the day 2015/02/06,
verify the status of the keys in keychain abc.
# Display keychain information on Switch A. The output shows that key 2 becomes the valid
key.
[SwitchA]display keychain

Keychain name : abc

Mode : absolute
Accept tolerance : 0
TCP kind value : 254
TCP algorithm value
HMAC-MD5 : 5
MD5 : 3
Default send key ID : None

346
 Active send key ID : 2
Active accept key IDs: 2

Key ID : 1
Key string : $c$3$dYTC8QeOKJkwFwP2k/rWL+1p6uMTw3MqNg==
Algorithm : md5
Send lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06
Send status : Inactive
Accept lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06
Accept status : Inactive

Key ID : 2
Key string : $c$3$7TSPbUxoP1ytOqkdcJ3K3x0BnXEWl4mOEw==
Algorithm : hmac-md5
Send lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06
Send status : Active
Accept lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06
Accept status : Active
# Display keychain information on Switch B. The output shows that key 2 becomes the valid
key.
[SwitchB]display keychain

Keychain name : abc

Mode : absolute
Accept tolerance : 0
TCP kind value : 254
TCP algorithm value
HMAC-MD5 : 5
MD5 : 3
Default send key ID : None
Active send key ID : 1
Active accept key IDs: 1

Key ID : 1
Key string : $c$3$/G/Shnh6heXWprlSQy/XDmftHa2JZJBSgg==
Algorithm : md5
Send lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06
Send status : Inactive
Accept lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06
Accept status : Inactive

Key ID : 2
Key string : $c$3$t4qHAw1hpZYN0JKIEpXPcMFMVT81u0hiOw==
Algorithm : hmac-md5
Send lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06
Send status : Active
Accept lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06
Accept status : Active

347
348
Managing public keys
About public key management
This chapter describes public key management for the following asymmetric key algorithms:
• Revest-Shamir-Adleman Algorithm (RSA).
• Digital Signature Algorithm (DSA).
• Elliptic Curve Digital Signature Algorithm (ECDSA).

Asymmetric key algorithm overview

Asymmetric key algorithms are used by security applications to secure communications between
two parties, as shown in Figure 90. Asymmetric key algorithms use two separate keys (one public
and one private) for encryption and decryption. Symmetric key algorithms use only one key.
Figure 90 Encryption and decryption

Sender Key Key Receiver

Plain text Cipher text Plain text

Encryption Decryption

A key owner can distribute the public key in plain text on the network but must keep the private key in
privacy. It is mathematically infeasible to calculate the private key even if an attacker knows the
algorithm and the public key.

Usage of asymmetric key algorithms

Security applications (such as SSH, SSL, and PKI) use the asymmetric key algorithms for the
following purposes:
• Encryption and decryption—Any public key receiver can use the public key to encrypt
information, but only the private key owner can decrypt the information.
• Digital signature—The key owner uses the private key to digitally sign information to be sent.
The receiver decrypts the information with the sender's public key to verify information
authenticity.
RSA, DSA, and ECDSA can all perform digital signature, but only RSA can perform encryption and
decryption.

FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for
features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and
non-FIPS mode.

Public key management tasks at a glance

To manage public keys, perform the following tasks:

349
 1. Creating a local key pair
2. Distributing a local host public key
Choose one of the following tasks:
 Exporting a host public key
 Displaying a host public key
To enable the peer device to authenticate the local device, you must distribute the local device's
public key to the peer device.
3. Configuring a peer host public key
Choose one of the following tasks:
 Importing a peer host public key from a public key file
 Entering a peer host public key
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.
4. (Optional.) Destroying a local key pair

Creating a local key pair

Restrictions and guidelines
When you create a local key pair, follow these guidelines:
• The key algorithm must be the same as required by the security application.
• When you create an RSA or DSA key pair, enter an appropriate key modulus length at the
prompt. The longer the key modulus length, the higher the security, and the longer the key
generation time.
When you create an ECDSA key pair, choose the appropriate elliptic curve. The elliptic curve
determines the ECDSA key length. The longer the key length, the higher the security, and the
longer the key generation time.
See Table 30 for more information about key modulus lengths and key lengths.
• If you do not assign the key pair a name, the system assigns the default name to the key pair
and marks the key pair as default. You can also assign the default name to another key pair,
but the system does not mark the key pair as default. The key pair name must be unique
among all manually named key pairs that use the same key algorithm. If a name conflict occurs,
the system asks whether you want to overwrite the existing key pair.
• The key pairs are automatically saved and can survive system reboots.
Table 30 A comparison of different types of asymmetric key algorithms

Type Generated key pairs Modulus/key length

• In non-FIPS mode:
 One host key pair, if you specify a key RSA key modulus length:
pair name.
• In non-FIPS mode: 512 to 4096 bits,
 One server key pair and one host key 1024 bits by default.
pair, if you do not specify a key pair To ensure security, use a minimum
RSA name. of 768 bits.
Both key pairs use their default names.
• In FIPS mode: A multiple of 256 bits
• In FIPS mode: One host key pair. in the range of 2048 to 4096 bits,
NOTE: 2048 bits by default.
Only SSH 1.5 uses the RSA server key pair.

350
 Type Generated key pairs Modulus/key length
DSA key modulus length:
• In non-FIPS mode: 512 to 2048 bits,
1024 bits by default.
DSA One host key pair.
To ensure security, use a minimum
of 768 bits.
• In FIPS mode: 2048 bits.
ECDSA key length:
• In non-FIPS mode: 192, 256, 384, or
ECDSA One host key pair.
521 bits.
• In FIPS mode: 256, 384, or 521 bits.

Procedure
1. Enter system view.
system-view
2. Create a local key pair.
In non-FIPS mode:
public-key local create { dsa | ecdsa [ secp192r1 | secp256r1 | secp384r1
| secp521r1 ] | rsa } [ name key-name ]
In FIPS mode:
public-key local create { dsa | ecdsa [ secp256r1 | secp384r1 |
secp521r1 ] | rsa } [ name key-name ]

Distributing a local host public key

About distribution of local host public keys
You must distribute a local host public key to a peer device so the peer device can perform the
following operations:
• Use the public key to encrypt information sent to the local device.
• Authenticate the digital signature signed by the local device.
To distribute a local host public key, you must first export or display the key.
• Export a host public key:
 Export a host public key to a file.
 Export a host public key to the monitor screen, and then save it to a file.
After the key is exported to a file, transfer the file to the peer device. On the peer device, import
the key from the file.
• Display a host public key.
After the key is displayed, record the key, for example, copy it to an unformatted file. On the
peer device, you must literally enter the key.

Exporting a host public key

Restrictions and guidelines
When you export a host public key, follow these restrictions and guidelines:
• If you specify a file name in the command, the command exports the key to the specified file.

351
 • If you do not specify a file name, the command exports the key to the monitor screen. You must
manually save the exported key to a file.
Procedure
1. Enter system view.
system-view
2. Export a local host public key.
 Export an RSA host public key:
In non-FIPS mode:
public-key local export rsa [ name key-name ] { openssh | ssh1 | ssh2 }
[ filename ]
In FIPS mode:
public-key local export rsa [ name key-name ] { openssh | ssh2 }
[ filename ]
 Export an ECDSA host public key.
public-key local export ecdsa [ name key-name ] { openssh | ssh2 }
[ filename ]
 Export a DSA host public key.
public-key local export dsa [ name key-name ] { openssh | ssh2 }
[ filename ]

Displaying a host public key

Perform the following tasks in any view:
• Display local RSA public keys.
display public-key local rsa public [ name key-name ]
Do not distribute the RSA server public key serverkey (default) to a peer device.
• Display local ECDSA public keys.
display public-key local ecdsa public [ name key-name ]
• Display local DSA public keys.
display public-key local dsa public [ name key-name ]

Configuring a peer host public key

About peer host public key configuration
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 configure the peer host public key by using the following methods:
• Import the peer host public key from a public key file (recommended).
• Manually enter (type or copy) the peer host public key.
For information about how to obtain the host public key of a device, see "Distributing a local host
public key."

352
Restrictions and guidelines for peer host public key
configuration
When you configure a peer host public key, follow these restrictions and guidelines:
• When you manually enter the peer host public key, make sure the entered key is in the correct
format. To obtain the peer host public key in the correct format, use the display
public-key local public command to display the public key on the peer device and
record the key. The format of the public key displayed in any other way might be incorrect. If the
key is not in the correct format, the system discards the key and displays an error message.
• Always import rather than enter the peer host public key if you are not sure whether the device
supports the format of the recorded peer host public key.

Importing a peer host public key from a public key file

About this task
Before you perform this task, make sure you have exported the host public key to a file on the peer
device and obtained the file from the peer device. For information about exporting a host public key,
see "Exporting a host public key."
After you import the key, the system automatically converts the imported public key to a string in the
Public Key Cryptography Standards (PKCS) format.
Procedure
1. Enter system view.
system-view
2. Import a peer host public key from a public key file.
public-key peer keyname import sshkey filename
By default, no peer host public keys exist.

Entering a peer host public key

About this task
Before you perform this task, make sure you have displayed the key on the peer device and recorded
the key. For information about displaying a host public key, see "Displaying a host public key."
Procedure
1. Enter system view.
system-view
2. Specify a name for the peer host public key and enter public key view.
public-key peer keyname
3. Type or copy the key.
You can use spaces and carriage returns, but the system does not save them.
4. Exit public key view.
peer-public-key end
When you exit public key view, the system automatically saves the peer host public key.

353
Destroying a local key pair
About this task
To ensure security, destroy the local key pair and generate a new key pair in any of the following
situations:
• The local key has leaked. An intrusion event might occur.
• The storage media of the device is replaced.
• The local certificate has expired. For more information about local certificates, see "Configuring
PKI."
Procedure
1. Enter system view.
system-view
2. Destroy a local key pair.
public-key local destroy { dsa | ecdsa | rsa } [ name key-name ]

Display and maintenance commands for public

keys
Execute display commands in any view.

Task Command
display public-key local { dsa | ecdsa | rsa }
Display local public keys.
public [ name key-name ]
display public-key peer [ brief | name
Display peer host public keys.
publickey-name ]

Examples of public key management

Example: Entering a peer host public key
Network configuration
As shown in Figure 91, to prevent illegal access, Device B authenticates Device A through a digital
signature. Before configuring authentication parameters on Device B, use the following procedure to
configure the public key of Device A on Device B:
• Create RSA key pairs on Device A and display the public keys of the RSA key pairs.
• Manually specify the RSA host public key of Device A on Device B.
Figure 91 Network diagram

Device A Device B

354
Procedure
1. Configure Device A:
# Create local RSA key pairs with the default names on Device A, and use the default key
modulus length (1024 bits).
<DeviceA> system-view
[DeviceA] public-key local create rsa
The range of public key modulus is (512 ~ 4096).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
...
Create the key pair successfully.
# Display all local RSA public keys.
[DeviceA] display public-key local rsa public
=============================================
Key name: hostkey (default)
Key type: RSA
Time when key pair created: 16:48:31 2011/05/12
Key code:
30819F300D06092A864886F70D010101050003818D0030818902818100DA3B90F59237347B
8D41B58F8143512880139EC9111BFD31EB84B6B7C7A1470027AC8F04A827B30C2CAF79242E
45FDFF51A9C7E917DB818D54CB7AEF538AB261557524A7441D288EC54A5D31EFAE4F681257
6D7796490AF87A8C78F4A7E31F0793D8BA06FB95D54EBB9F94EB1F2D561BF66EA27DFD4788
CB47440AF6BB25ACA50203010001
=============================================
Key name: serverkey (default)
Key type: RSA
Time when key pair created: 16:48:31 2011/05/12
Key code:
307C300D06092A864886F70D0101010500036B003068026100C9451A80F7F0A9BA1A90C7BC
1C02522D194A2B19F19A75D9EF02219068BD7FD90FCC2AF3634EEB9FA060478DD0A1A49ACE
E1362A4371549ECD85BA04DEE4D6BB8BE53B6AED7F1401EE88733CA3C4CED391BAE633028A
AC41C80A15953FB22AA30203010001
2. Configure Device B:
# Enter the host public key of Device A in public key view. The key must be literally the same as
displayed on Device A.
<DeviceB> system-view
[DeviceB] public-key peer devicea
Enter public key view. Return to system view with "peer-public-key end" command.
[DeviceB-pkey-public-key-devicea]30819F300D06092A864886F70D010101050003818D003081
8902818100DA3B90F59237347B
[DeviceB-pkey-public-key-devicea]8D41B58F8143512880139EC9111BFD31EB84B6B7C7A14700
27AC8F04A827B30C2CAF79242E
[DeviceB-pkey-public-key-devicea]45FDFF51A9C7E917DB818D54CB7AEF538AB261557524A744
1D288EC54A5D31EFAE4F681257
[DeviceB-pkey-public-key-devicea]6D7796490AF87A8C78F4A7E31F0793D8BA06FB95D54EBB9F
94EB1F2D561BF66EA27DFD4788
[DeviceB-pkey-public-key-devicea]CB47440AF6BB25ACA50203010001

355
 # Save the public key and return to system view.
[DeviceB-pkey-public-key-devicea] peer-public-key end

Verifying the configuration

# Verify that the peer host public key configured on Device B is the same as the key displayed on
Device A.
[DeviceB] display public-key peer name devicea

=============================================
Key name: devicea
Key type: RSA
Key modulus: 1024
Key code:
30819F300D06092A864886F70D010101050003818D0030818902818100DA3B90F59237347B
8D41B58F8143512880139EC9111BFD31EB84B6B7C7A1470027AC8F04A827B30C2CAF79242E
45FDFF51A9C7E917DB818D54CB7AEF538AB261557524A7441D288EC54A5D31EFAE4F681257
6D7796490AF87A8C78F4A7E31F0793D8BA06FB95D54EBB9F94EB1F2D561BF66EA27DFD4788
CB47440AF6BB25ACA50203010001

Example: Importing a public key from a public key file

Network configuration
As shown in Figure 92, Device B authenticates Device A through a digital signature. Before
configuring authentication parameters on Device B, use the following procedure to configure the
public key of Device A on Device B:
• Create RSA key pairs on Device A and export the RSA host public key to a file.
• Import the RSA host public key of Device A from the public key file to Device B.
Figure 92 Network diagram
10.1.1.1/24 10.1.1.2/24

Device A Device B

Procedure
1. Configure Device A:
# Create local RSA key pairs with the default names on Device A, and use the default key
modulus length (1024 bits).
<DeviceA> system-view
[DeviceA] public-key local create rsa
The range of public key modulus is (512 ~ 4096).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
...
Create the key pair successfully.
# Display all local RSA public keys.
[DeviceA] display public-key local rsa public
=============================================

356
 Key name: hostkey (default)
Key type: RSA
Time when key pair created: 16:48:31 2011/05/12
Key code:
30819F300D06092A864886F70D010101050003818D0030818902818100DA3B90F59237347B
8D41B58F8143512880139EC9111BFD31EB84B6B7C7A1470027AC8F04A827B30C2CAF79242E
45FDFF51A9C7E917DB818D54CB7AEF538AB261557524A7441D288EC54A5D31EFAE4F681257
6D7796490AF87A8C78F4A7E31F0793D8BA06FB95D54EBB9F94EB1F2D561BF66EA27DFD4788
CB47440AF6BB25ACA50203010001
=============================================
Key name: serverkey (default)
Key type: RSA
Time when key pair created: 16:48:31 2011/05/12
Key code:
307C300D06092A864886F70D0101010500036B003068026100C9451A80F7F0A9BA1A90C7BC
1C02522D194A2B19F19A75D9EF02219068BD7FD90FCC2AF3634EEB9FA060478DD0A1A49ACE
E1362A4371549ECD85BA04DEE4D6BB8BE53B6AED7F1401EE88733CA3C4CED391BAE633028A
AC41C80A15953FB22AA30203010001
# Export the RSA host public key to file devicea.pub.
[DeviceA] public-key local export rsa ssh2 devicea.pub
# Enable the FTP server, create an FTP user with username ftp and password hello12345, and
configure the FTP user role as network-admin.
[DeviceA] ftp server enable
[DeviceA] local-user ftp
[DeviceA-luser-manage-ftp] password simple hello12345
[DeviceA-luser-manage-ftp] service-type ftp
[DeviceA-luser-manage-ftp] authorization-attribute user-role network-admin
[DeviceA-luser-manage-ftp] quit
2. Configure Device B:
# Use FTP in binary mode to get public key file devicea.pub from Device A.
<DeviceB> ftp 10.1.1.1
Connected to 10.1.1.1 (10.1.1.1).
220 FTP service ready.
User(10.1.1.1:(none)):ftp
331 Password required for ftp.
Password:
230 User logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> binary
200 TYPE is now 8-bit binary
ftp> get devicea.pub
227 Entering Passive Mode (10,1,1,1,118,252)
150 Accepted data connection
226 File successfully transferred
301 bytes received in 0.003 seconds (98.0 kbyte/s)
ftp> quit
221-Goodbye. You uploaded 0 and downloaded 1 kbytes.

357
 221 Logout.
# Import the host public key from key file devicea.pub.
<DeviceB> system-view
[DeviceB] public-key peer devicea import sshkey devicea.pub

Verifying the configuration

# Verify that the peer host public key configured on Device B is the same as the key displayed on
Device A.
[DeviceB] display public-key peer name devicea
=============================================
Key name: devicea
Key type: RSA
Key modulus: 1024
Key code:
30819F300D06092A864886F70D010101050003818D0030818902818100DA3B90F59237347B
8D41B58F8143512880139EC9111BFD31EB84B6B7C7A1470027AC8F04A827B30C2CAF79242E
45FDFF51A9C7E917DB818D54CB7AEF538AB261557524A7441D288EC54A5D31EFAE4F681257
6D7796490AF87A8C78F4A7E31F0793D8BA06FB95D54EBB9F94EB1F2D561BF66EA27DFD4788
CB47440AF6BB25ACA50203010001

358
Configuring PKI
About 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. For more information about public keys, see "Managing public
keys."

PKI terminology
Digital certificate
A digital certificate is an electronic document signed by a CA that binds a public key with the identity
of its owner.
A digital certificate includes the following information:
• Issuer name (name of the CA that issued the certificate).
• Subject name (name of the individual or group to which the certificate is issued).
• Identity information of the subject.
• Subject's public key.
• Signature of the CA.
• Validity period.
A digital certificate must comply with the international standards of ITU-T X.509, of which X.509 v3 is
the most commonly used.
This chapter 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 generates a self-signed certificate, and each lower level CA holds a
CA certificate issued by the CA immediately above it. The chain of these certificates forms a
chain of trust.
• Registration authority (RA) certificate—Certificate issued by a CA to an RA. RAs act as
proxies for CAs to process enrollment requests in a PKI system.
• Local certificate—Digital certificate issued by a CA to a local PKI entity, which contains the
entity's public key.
• Peer certificate—CA-signed digital certificate of a peer, which contains the peer's public key.
Fingerprint of root CA certificate
Each root CA certificate has a unique fingerprint, which is the hash value of the certificate content.
The fingerprint of a root CA certificate can be used to authenticate the validity of the root CA.
Certificate revocation list
A certificate revocation list (CRL) is a list of serial numbers for certificates that have been revoked. A
CRL is created and signed by the CA that originally issued the certificates.
The CA publishes CRLs periodically to revoke certificates. Entities that are associated with the
revoked certificates should not be trusted.
The CA must revoke a certificate when any of the following conditions occurs:

359
 • 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.
CA policy
A CA policy is a set of criteria that a CA follows to process certificate requests, to issue and revoke
certificates, and to publish CRLs. Typically, a CA advertises its policy in a certification practice
statement (CPS). You can obtain a CA policy through out-of-band means such as phone, disk, and
email. Make sure you understand the CA policy before you select a trusted CA for certificate request
because different CAs might use different policies.

PKI architecture
A PKI system consists of PKI entities, CAs, RAs and a certificate/CRL repository, as shown in Figure
93.
Figure 93 PKI architecture

te
a
c Entity
ifi
try
er
o
Cits
o
p
e
r PKI user
L
R
/C

PKI
management
authorities
RA
Issue a
certificate

CA
Issue a certificate/CRL

PKI entity
A PKI entity is 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 running on a computer. PKI entities use SCEP to
communicate with the CA or RA.
CA
Certification authority that grants 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 certificate enrollment requests. The RA
accepts certificate requests, verifies user identity, and determines whether to ask the CA to issue
certificates.
The RA is optional in a PKI system. In cases when there is security concern over exposing the CA to
direct network access, it is advisable to delegate some of the tasks to an RA. Then, the CA can
concentrate on its primary tasks of signing certificates and CRLs.
Certificate/CRL repository
A certificate distribution point that stores certificates and CRLs, and distributes these certificates 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.

360
Retrieval, usage, and maintenance of a digital certificate
The following workflow describes the retrieval, usage, and maintenance of a digital certificate. This
example uses a CA which has an RA to process certificate enrollment requests.
1. A PKI entity generates an asymmetric key pair and submits a certificate request to the RA.
The certificate request contains the public key and its identity information.
2. The RA verifies the identity of the entity and sends a digital signature containing the identity
information and the public key to the CA.
3. The CA verifies the digital signature, approves the request, and issues a certificate.
4. After receiving the certificate from the CA, the RA sends the certificate to the certificate
repository and notifies the PKI entity that the certificate has been issued.
5. The PKI entity obtains the certificate from the certificate repository.
6. To establish a secure connection for communication, two PKI entities exchange local
certificates to authenticate each other. The connection can be established only if both entities
verify that the peer's certificate is valid.
7. You can remove the local certificate of a PKI entity and request a new one when any of the
following conditions occur:
 The local certificate is about to expire.
 The certificate's private key is compromised.

PKI applications
The PKI technology can meet security requirements of online transactions. As an infrastructure, PKI
has a wide range of applications. HPE's PKI system can provide certificate management for IPsec
and SSL.
The following are some application examples.
VPN
A VPN is a private data communication network built on the public communication infrastructure. A
VPN can use network layer security protocols (for example, IPsec) in conjunction with PKI-based
encryption and digital signature technologies for confidentiality.
Secure emails
PKI can address the email requirements for confidentiality, integrity, authentication, and
non-repudiation. A common secure email protocol is Secure/Multipurpose Internet Mail Extensions
(S/MIME), which is based on PKI and allows for transfer of encrypted mails with signature.
Web security
PKI can be used in the SSL handshake phase to verify the identities of the communicating parties by
digital certificates.

FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for
features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and
non-FIPS mode.

PKI tasks at a glance

To configure PKI, perform the following tasks:

361
 1. Configuring a PKI entity
2. Configuring a PKI domain
3. (Optional.) Specifying the storage path for certificates and CRLs
4. Requesting a certificate
Choose one of the following tasks:
 Enabling the automatic online certificate request mode
 Manually submitting an online certificate request
 Manually submitting a certificate request in offline mode
5. (Optional.) Aborting a certificate request
6. (Optional.) Obtaining certificates
You can obtain the CA certificate, local certificates, and peer certificates related to a PKI
domain from a CA and save them locally for higher lookup efficiency.
7. (Optional.) Verifying PKI certificates
8. (Optional.) Exporting certificates
9. (Optional.) Removing a certificate
10. (Optional.) Configuring a certificate-based access control policy
Certificate-based access control policies allow you to authorize access to a device (for example,
an HTTPS server) based on the attributes of an authenticated client's certificate.

Configuring a PKI entity

About this task
A certificate applicant uses an entity to provide its identity information to a CA. A valid PKI entity must
include one or more of following identity categories:
• Distinguished name (DN) of the entity, which further includes the common name, country code,
locality, organization, unit in the organization, and state. If you configure the DN for an entity, a
common name is required.
• FQDN of the entity.
• IP address of the entity.
Restrictions and guidelines
Follow these restrictions and guidelines when you configure a PKI entity:
• Whether the identity categories are required or optional depends on the CA policy. Follow the
CA policy to configure the entity settings. For example, if the CA policy requires the entity DN,
but you configure only the IP address, the CA rejects the certificate request from the entity.
• The SCEP add-on on the Windows 2000 CA server has restrictions on the data length of a
certificate request. If a request from a PKI entity exceeds the data length limit, the CA server
does not respond to the certificate request. In this case, you can use an out-of-band means to
submit the request. Other types of CA servers, such as RSA servers and OpenCA servers, do
not have such restrictions.
Procedure
1. Enter system view.
system-view
2. Create a PKI entity and enter its view.
pki entity entity-name
3. Set a common name for the entity.
common-name common-name-sting

362
 By default, the common name is not set.
4. Set the country code of the entity.
country country-code-string
By default, the country code is not set.
5. Set the locality of the entity.
locality locality-name
By default, the locality is not set.
6. Set the organization of the entity.
organization org-name
By default, the organization is not set.
7. Set the unit of the entity in the organization.
organization-unit org-unit-name
By default, the unit is not set.
8. Set the state where the entity resides.
state state-name
By default, the state is not set.
9. Set the FQDN of the entity.
fqdn fqdn-name-string
By default, the FQDN is not set.
10. Configure the IP address of the entity.
ip { ip-address | interface interface-type interface-number }
By default, the IP address is not configured.

Configuring a PKI domain

About PKI domain
A PKI domain contains enrollment information for a PKI entity. It is locally significant and is intended
only for use by other applications like IKE and SSL.

PKI domain tasks at a glance

To configure a PKI domain, perform the following tasks:
1. Creating a PKI domain
2. Specifying the trusted CA
3. Specifying the PKI entity name
4. Specifying the certificate request reception authority
5. Specifying the certificate request URL
6. (Optional.) Setting the SCEP polling interval and maximum polling attempts
7. Specifying the LDAP server
This task is required when either of the following conditions is met:
 The device must obtain certificates from the CA by using the LDAP protocol.
 An LDAP URL which does not contain the host name of the LDAP server is specified as the
CRL repository URL.
8. Specifying the fingerprint for root CA certificate verification

363
 This step is required if the auto certificate request mode is configured in the PKI domain.
If the manual certificate request mode is configured, you can skip this step and manually verify
the fingerprint displayed during verification of the root CA certificate.
9. Specifying the key pair for certificate request
10. (Optional.) Specifying the intended purpose for the certificate
11. (Optional.) Specifying the source IP address for PKI protocol packets

Creating a PKI domain

1. Enter system view.
system-view
2. Create a PKI domain and enter its view.
pki domain domain-name

Specifying the trusted CA

About this task
The PKI domain must have a CA certificate before you can request a local certificate. To obtain a CA
certificate, the trusted CA name must be specified. The trusted CA name uniquely identifies the CA to
be used if multiple CAs exist on the CA server.
Procedure
1. Enter system view.
system-view
2. Enter PKI domain view.
pki domain domain-name
3. Specify the trusted CA name.
ca identifier name
By default, no trusted CA name is specified.

Specifying the PKI entity name

1. Enter system view.
system-view
2. Enter PKI domain view.
pki domain domain-name
3. Specify the PKI entity name.
certificate request entity entity-name
By default, no PKI entity name is specified.

Specifying the certificate request reception authority

1. Enter system view.
system-view
2. Enter PKI domain view.
pki domain domain-name

364
 3. Specify the certificate request reception authority.
certificate request from { ca | ra }
By default, no certificate request reception authority is specified.

Specifying the certificate request URL

1. Enter system view.
system-view
2. Enter PKI domain view.
pki domain domain-name
3. Specify the URL of the certificate request reception authority to which the device sends
certificate requests.
certificate request url url-string [ vpn-instance vpn-instance-name ]
By default, the certificate request URL is not specified.

Setting the SCEP polling interval and maximum polling

attempts
1. Enter system view.
system-view
2. Enter PKI domain view.
pki domain domain-name
3. Set the SCEP polling interval and maximum number of polling attempts.
certificate request polling { count count | interval interval }
By default, the device polls the CA server for the certificate request status every 20 minutes.
The maximum number of polling attempts is 50.

Specifying the LDAP server

1. Enter system view.
system-view
2. Enter PKI domain view.
pki domain domain-name
3. Specify the LDAP server.
ldap-server host hostname [ port port-number ] [ vpn-instance
vpn-instance-name ]
By default, no LDAP server is specified.

Specifying the fingerprint for root CA certificate verification

1. Enter system view.
system-view
2. Enter PKI domain view.
pki domain domain-name
3. Configure the fingerprint for verifying the root CA certificate.

365
 In non-FIPS mode:
root-certificate fingerprint { md5 | sha1 } string
In FIPS mode:
root-certificate fingerprint sha1 string
By default, no fingerprint is configured.

Specifying the key pair for certificate request

Restrictions and guidelines
You can specify a nonexistent key pair for certificate request. The PKI entity automatically creates
the key pair before submitting a certificate request.
Procedure
1. Enter system view.
system-view
2. Enter PKI domain view.
pki domain domain-name
3. Specify the key pair for certificate request.
 Specify an RSA key pair.
public-key rsa { { encryption name encryption-key-name [ length
key-length ] | signature name signature-key-name [ length
key-length ] } * | general name key-name [ length key-length ] }
 Specify an ECDSA key pair.
In non-FIPS mode:
public-key ecdsa name key-name [ secp192r1 | secp256r1 | secp384r1 |
secp521r1 ]
In FIPS mode:
public-key ecdsa name key-name [ secp256r1 | secp384r1 | secp521r1 ]
 Specify a DSA key pair.
public-key dsa name key-name [ length key-length ]
By default, no key pair is specified.

Specifying the intended purpose for the certificate

About this task
An issued certificate contains the extensions which restrict the usage of the certificate to specific
purposes. You can specify the intended purposes for a certificate, which will be included in the
certificate request sent to the CA. However, the actual extensions contained in an issued certificate
depend on the CA policy, and they might be different from those specified in the PKI domain.
Whether an application will use the certificate during authentication depends on the application's
policy.
Supported certificate extensions include:
• ike—Certificates carrying this extension can be used by IKE peers.
• ssl-client—Certificates carrying this extension can be used by SSL clients.
• ssl-server—Certificates carrying this extension can be used by SSL servers.

366
Procedure
1. Enter system view.
system-view
2. Enter PKI domain view.
pki domain domain-name
3. Specify the intended use for the certificate.
usage { ike | ssl-client | ssl-server } *
By default, the certificate can be used by all supported applications, including IKE, SSL client,
and SSL server.

Specifying the source IP address for PKI protocol packets

About this task
This task is required if the CA policy requires that the CA server accept certificate requests from a
specific IP address or subnet.
Procedure
1. Enter system view.
system-view
2. Enter PKI domain view.
pki domain domain-name
3. Specify a source IP address for the PKI protocol packets.
IPv4:
source ip { ip-address | interface interface-type interface-number }
IPv6:
source ipv6 { ipv6-address | interface interface-type
interface-number }
By default, the source IP address of PKI protocol packets is the IP address of their outgoing
interface.

Specifying the storage path for certificates and

CRLs
About this task
The device has a default storage path for certificates and CRLs. You can change the storage path
and specify different paths for the certificates and CRLs.
After you change the storage path for certificates or CRLs, the certificate files and CRL files in the
original path are moved to the new path. Certificate files use the .cer or .p12 file extension and CRL
files use the .crl file extension.
Restrictions and guidelines
If you change the storage path, save the configuration before you reboot or shut down the device to
avoid loss of certificates or CRLs.
Procedure
1. Enter system view.
system-view

367
 2. Specify the storage path for certificates and CRLs.
pki storage { certificates | crls } dir-path
By default, the device stores certificates and CRLs in the PKI directory on the storage media of
the device.

Requesting a certificate
About certificate request configuration
To request a certificate, a PKI entity must provide its identity information and public key to a CA.
A certificate request can be submitted to a CA in offline or online mode.
• Offline mode—A certificate request is submitted by using an out-of-band method, such as
phone, disk, or email.
• Online mode—A certificate request can be automatically or manually submitted to a CA
through the Simple Certificate Enrollment Protocol (SCEP).

Restrictions and guidelines for certificate request

configuration
When you request a local certificate in a PKI domain, follow these restrictions and guidelines:
• To prevent an existing local certificate from becoming invalid, do not perform the following
tasks:
 Create a key pair with the same name as the key pair contained in the certificate.
To create a key pair, use the public-key local create command.
 Destroy the key pair contained in the certificate.
To destroy a key pair, use the public-key local destroy command.
• To manually request a new certificate in a PKI domain that already has a local certificate, use
the following procedure:
a. Use the pki delete-certificate command to delete the existing local certificate.
b. Use the public-key local create command to generate a new key pair.
c. Manually submit a certificate request.
• A PKI domain can have local certificates using only one type of cryptographic algorithms (DSA,
ECDSA, or RSA). If DSA or ECDSA is used, a PKI domain can have only one local certificate. If
RSA is used, a PKI domain can have one local certificate for signature, and one local certificate
for encryption.

Prerequisites for certificate request configuration

Make sure the device is time synchronized with the CA server. If the device is not time synchronized
with the CA server, the certificate request might fail because the certificate might be considered to be
outside of the validity period. For information about configuring the system time, see Fundamentals
Configuration Guide.

368
Enabling the automatic online certificate request mode
About this task
In auto request mode, a PKI entity with no local certificates automatically submits a certificate
request to the CA when an application works with the PKI entity. For example, when IKE negotiation
uses a digital signature for identity authentication, but no local certificate is available, the entity
automatically submits a certificate request. It saves the certificate locally after obtaining the
certificate from the CA.
A CA certificate must be present before you request a local certificate. If no CA certificate exists in the
PKI domain, the PKI entity automatically obtains a CA certificate before sending a certificate request.
Restrictions and guidelines
In auto request mode, the device does not automatically request a new certificate if the current
certificate is about to expire or has expired, which might cause service interruptions.
Procedure
1. Enter system view.
system-view
2. Enter PKI domain view.
pki domain domain-name
3. Enable the automatic online certificate request mode.
certificate request mode auto [ password { cipher | simple } string ]
By default, the manual request mode applies.
If the CA policy requires a password for certificate revocation, specify the password in this
command.

Manually submitting an online certificate request

About this task
In manual request mode, you must execute the pki request-certificate domain command
to request a local certificate in a PKI domain. The certificate will be saved in the domain after it is
obtained from the CA.
Procedure
1. Enter system view.
system-view
2. Enter PKI domain view.
pki domain domain-name
3. Set the certificate request mode to manual.
certificate request mode manual
By default, the manual request mode applies.
4. Return to system view.
quit
5. Obtain a CA certificate.
See "Obtaining certificates."
This step is required if the PKI domain does not have a CA certificate. The CA certificate is used
to verify the authenticity and validity of the obtained local certificate.
6. Manually submit an SCEP certificate request.

369
 pki request-certificate domain domain-name [ password password ]
This command is not saved in the configuration file.
If the CA policy requires a password for certificate revocation, specify the password in this
command.

Manually submitting a certificate request in offline mode

About this task
Use this method if the CA does not support SCEP or if a network connection between the device and
CA is not possible.
Procedure
1. Enter system view.
system-view
2. Enter PKI domain view.
pki domain domain-name
3. Set the certificate request mode to manual.
certificate request mode manual
By default, the manual request mode applies.
4. Return to system view.
quit
5. Obtain the CA certificate.
See "Obtaining certificates."
This step is required if the PKI domain does not have a CA certificate. The CA certificate is used
to verify the authenticity and validity of the obtained local certificate.
6. Print the certificate request in PKCS10 format on the terminal or save the certificate request to
a PKCS10 file.
pki request-certificate domain domain-name pkcs10 [ filename
filename ]
This command is not saved in the configuration file.
7. Transfer certificate request information to the CA by using an out-of-band method.
8. Transfer the issued local certificate from the CA to the local device by using an out-of-band
method.
9. Import the local certificate to the PKI domain.
pki import domain domain-name { der local filename filename | p12 local
filename filename | pem local } [ filename filename ] }

Aborting a certificate request

About this task
Before the CA issues a certificate, you can abort a certificate request and change its parameters,
such as the common name, country code, or FQDN. You can use the display pki
certificate request-status command to display the status of a certificate request.
Alternatively, you also can remove a PKI domain to abort the associated certificate request.
Procedure
1. Enter system view.

370
 system-view
2. Abort a certificate request.
pki abort-certificate-request domain domain-name
This command is not saved in the configuration file.

Obtaining certificates
About this task
You can obtain the CA certificate, local certificates, and peer certificates related to a PKI domain from
a CA and save them locally for higher lookup efficiency. To do so, use either the offline mode or the
online mode:
• In offline mode, obtain the certificates by an out-of-band means like FTP, disk, or email, and
then import them locally. Use this mode when the CRL repository is not specified, the CA server
does not support SCEP, or the CA server generates the key pair for the certificates.
• In online mode, you can obtain the CA certificate through SCEP and obtain local certificates or
peer certificates through LDAP.
Restrictions and guidelines
Follow these restrictions and guidelines when obtain certificates from a CA
• If a CA certificate already exists locally, you cannot obtain it again in online mode. If you want to
obtain a new CA certificate, use the pki delete-certificate command to delete the
existing CA certificate and local certificates first.
• If local or peer certificates already exist, you can obtain new local or peer certificates to
overwrite the existing ones. If RSA is used, a PKI domain can have two local certificates, one for
signature and the other for encryption.
• If CRL checking is enabled, obtaining a certificate triggers CRL checking. If the certificate to be
obtained has been revoked, the certificate cannot be obtained.
• The device compares the validity period of a certificate with the local system time to determine
whether the certificate is valid. Make sure the system time of the device is synchronized with the
CA server.
Prerequisites
• Before you obtain local or peer certificates in online mode, make sure an LDAP server is
correctly configured in the PKI domain.
• Before you import certificates in offline mode, complete the following tasks:
 Use FTP or TFTP to upload the certificate files to the storage media of the device.
If FTP or TFTP is not available, display and copy the contents of a certificate to a file on the
device. Make sure the certificate is in PEM format because only certificates in PEM format
can be imported.
 Before you import a local certificate or peer certificate, obtain the CA certificate chain that
signs the certificate.
This step is required only if the CA certificate chain is neither available in the PKI domain nor
contained in the certificate to be imported.
 Before you import a local certificate that contains an encrypted key pair, contact the CA
administrator to obtain the password required for importing the certificate.
Procedure
1. Enter system view.
system-view
2. Obtain certificates.

371
  Import certificates in offline mode.
pki import domain domain-name { der { ca | local | peer } filename
filename | p12 local filename filename | pem { ca | local | peer }
[ filename filename ] }
 Obtain certificates in online mode.
pki retrieve-certificate domain domain-name { ca | local | peer
entity-name }
This command is not saved in the configuration file.

Verifying PKI certificates

About certification verification
A certificate is automatically verified when it is requested, obtained, or used by an application. If the
certificate expires, if it is not issued by a trusted CA, or if it is revoked, the certificate cannot be used
You can also manually verify a certificate.
You can enable or disable CRL checking in a PKI domain. CRL checking checks whether a certificate
is in the CRL. If it is, the certificate has been revoked and its home entity is not trusted.
To use CRL checking, a CRL must be obtained from a CRL repository. The device selects a CRL
repository in the following order:
1. CRL repository specified in the PKI domain by using the crl url command.
2. CRL repository in the certificate that is being verified.
3. CRL repository in the CA certificate or CRL repository in the upper-level CA certificate if the
certificate being verified is a CA certificate
If no CRL repository is found after the selection process, the device obtains the CRL through SCEP.
In this scenario, the CA certificate and the local certificates must have been obtained.
A certificate fails CRL checking in the following situations:
• A CRL cannot be obtained during CRL checking of the certificate.
• CRL checking verifies that the certificate has been revoked.

Restrictions and guidelines for certificate verification

When verifying the CA certificate of a PKI domain, the system needs to verify all the certificates in the
CA certificate chain. To ensure a successful certificate verification process, the device must have all
the PKI domains to which the CA certificates in the certificate chain belong.
The system verifies the CA certificates in the CA certificate chain as follows:
1. Identifies the parent certificate of the lowest-level certificate.
Each CA certificate contains an issuer field that identifies the parent CA that issued the
certificate.
2. Locates the PKI domain to which the parent certificate belongs.
3. Performs CRL checking in the PKI domain to check whether the parent certificate has been
revoked. If it has been revoked, the certificate cannot be used.
This step will not be performed when CRL checking is disabled in the PKI domain.
4. Repeats the previous steps for upper-level certificates in the CA certificate chain until the root
CA certificate is reached.
5. Verifies that each CA certificate in the certificate chain is issued by the named parent CA,
starting from the root CA.

372
Verifying certificates with CRL checking
1. Enter system view.
system-view
2. Enter PKI domain view.
pki domain domain-name
3. (Optional.) Specify the URL of the CRL repository.
crl url url-string [ vpn-instance vpn-instance-name ]
By default, the URL of the CRL repository is not specified.
4. Enable CRL checking.
crl check enable
By default, CRL checking is enabled.
5. Return to system view.
quit
6. Obtain the CA certificate.
See "Obtaining certificates."
The PKI domain must have a CA certificate before you can verify certificates in it.
7. (Optional.) Obtain the CRL and save it locally.
pki retrieve-crl domain domain-name
To verify a non-root CA certificate and local certificates, the device automatically retrieves the
CRL if the PKI domain has no CRL.
The newly obtained CRL overwrites the old one, if any.
The obtained CRL is issued by a CA in the CA certificate chain stored in the PKI domain.
8. Manually verify the validity of the certificates.
pki validate-certificate domain domain-name { ca | local }

Verifying certificates without CRL checking

1. Enter system view.
system-view
2. Enter PKI domain view.
pki domain domain-name
3. Disable CRL checking.
undo crl check enable
By default, CRL checking is enabled.
4. Return to system view.
quit
5. Obtain a CA certificate for the PKI domain.
See "Obtaining certificates."
The PKI domain must have a CA certificate before you can verify certificates in it.
6. Manually verify the certificate validity.
pki validate-certificate domain domain-name { ca | local }
This command is not saved in the configuration file.

373
Exporting certificates
About this task
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.
Restrictions and guidelines
To export all certificates in PKCS12 format, the PKI domain must have a minimum of one local
certificate. If the PKI domain does not have any local certificates, the certificates in the PKI domain
cannot be exported.
If you do not specify a file name when you export a certificate in PEM format, this command displays
the certificate content on the terminal.
When you export a local certificate with RSA key pairs to a file, the certificate file name might be
different from the file name specified in the command. The actual certificate file name depends on
the purpose of the key pair contained in the certificate. For more information about the file naming
rule, see the pki export command in Security Command Reference.
Procedure
1. Enter system view.
system-view
2. Export certificates.
 Export certificates in DER format.
pki export domain domain-name der { all | ca | local } filename
filename
 Export certificates in PKCS12 format.
pki export domain domain-name p12 { all | local } passphrase p12-key
filename filename
 Export certificates in PEM format.
pki export domain domain-name pem { { all | local } [ { 3des-cbc |
aes-128-cbc | aes-192-cbc | aes-256-cbc | des-cbc } pem-key ] | ca }
[ filename filename ]

Removing a certificate
About this task
You can remove certificates from a PKI domain in the following situations:
• Remove a CA certificate, local certificate, or peer certificate if the certificate has expired or is
about to expire.
• Remove a local certificate if the certificate's private key is compromised, or if you want to
request a new local certificate to replace the existing one.
Restrictions and guidelines
After you remove the CA certificate, the system automatically removes the local certificates, peer
certificates, and CRLs from the domain.
To remove a local certificate and request a new certificate, perform the following tasks:
1. Remove the local certificate.
2. Use the public-key local destroy command to destroy the existing local key pair.
3. Use the public-key local create command to generate a new key pair.

374
 4. Request a new certificate.
For more information about the public-key local destroy and public-key local
create commands, see Security Command Reference.
Procedure
1. Enter system view.
system-view
2. Remove a certificate.
pki delete-certificate domain domain-name { ca | local | peer [ serial
serial-num ] }
If you use the peer keyword without specifying a serial number, this command removes all
peer certificates.

Configuring a certificate-based access control

policy
About certificate-based access control policies
Certificate-based access control policies allow you to authorize access to a device based on the
attributes of an authenticated client's certificate.
Access control rules and certificate attribute groups
A certificate-based access control policy is a set of access control rules (permit or deny statements),
each associated with a certificate attribute group. A certificate 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.
Certificate matching mechanism
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 performs the access control action defined in the
access control rule.
The following conditions describe how a certificate-based access control policy verifies the validity of
a certificate:
• 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-based access control policy specified for a security application does not exist,
all certificates in the application pass the verification.

Procedure
1. Enter system view.
system-view
2. Create a certificate attribute group and enter its view.
pki certificate attribute-group group-name

375
 3. Configure an attribute rule for issuer name, subject name, or alternative subject name.
attribute id { alt-subject-name { fqdn | ip } | { issuer-name |
subject-name } { dn | fqdn | ip } } { ctn | equ | nctn | nequ}
attribute-value
By default, not attribute rules are configured.
4. Return to system view.
quit
5. Create a certificate-based access control policy and enter its view.
pki certificate access-control-policy policy-name
By default, no certificate-based access control policies exist.
6. Create a certificate access control rule.
rule [ id ] { deny | permit } group-name
By default, no certificate access control rules are configured, and all certificates can pass the
verification.
You can create multiple certificate access control rules for a certificate-based access control
policy.

Display and maintenance commands for PKI

Execute display commands in any view.

Task Command
Display certificate-based access control display pki certificate
policy information. access-control-policy [ policy-name ]
Display certificate attribute group display pki certificate attribute-group
information. [ group-name ]
display pki certificate domain domain-name
Display the contents of a certificate.
{ ca | local | peer [ serial serial-num ] }
display pki certificate request-status
Display certificate request status.
[ domain domain-name ]
Display locally stored CRLs in a PKI
display pki crl domain domain-name
domain.

PKI configuration examples

You can use different software applications, such as Windows server, RSA Keon, and OpenCA, to
act as the CA server.
If you use Windows server or OpenCA, you must install the SCEP add-on for Windows server or
enable SCEP for OpenCA. In either case, when you configure a PKI domain, you must use the
certificate request from ra command to specify the RA to accept certificate requests.
If you use RSA Keon, the SCEP add-on is not required. When you configure a PKI domain, you must
use the certificate request from ca command to specify the CA to accept certificate
requests.

376
Example: Requesting a certificate from an RSA Keon CA
server
Network configuration
Configure the PKI entity (the device) to request a local certificate from the CA server.
Figure 94 Network diagram

PKI entity

Host Internet

Device CA server

Configuring the RSA Keon CA server

1. Create a CA server named myca:
In this example, you must configure these basic attributes on the CA server:
 Nickname—Name of the trusted CA.
 Subject DN—DN attributes of the CA, including the common name (CN), organization unit
(OU), organization (O), and country (C).
You can use the default values for other attributes.
2. Configure extended attributes:
Configure parameters in the Jurisdiction Configuration section on the management page of
the CA server:
 Select the correct extension profiles.
 Enable the SCEP autovetting function to enable the CA server to automatically approve
certificate requests without manual intervention.
 Specify the IP address list for SCEP autovetting.
Configuring the device
1. Synchronize the system time of the device with the CA server for the device to correctly request
certificates or obtain CRLs. (Details not shown.)
2. Create an entity named aaa and set the common name to Device.
<Device> system-view
[Device] pki entity aaa
[Device-pki-entity-aaa] common-name Device
[Device-pki-entity-aaa] quit
3. Configure a PKI domain:
# Create a PKI domain named torsa and enter its view.
[Device] pki domain torsa
# Specify the name of the trusted CA. The setting must be the same as CA name configured on
the CA server. This example uses myca.
[Device-pki-domain-torsa] ca identifier myca
# Configure the URL of the CA server. The URL format is http://host:port/Issuing
Jurisdiction ID, where Issuing Jurisdiction ID is a hexadecimal string generated
on the CA server.
[Device-pki-domain-torsa] certificate request url
http://1.1.2.22:446/80f6214aa8865301d07929ae481c7ceed99f95bd
# Configure the device to send certificate requests to ca.

377
 [Device-pki-domain-torsa] certificate request from ca
# Set the PKI entity name to aaa.
[Device-pki-domain-torsa] certificate request entity aaa
# Specify the URL of the CRL repository.
[Device-pki-domain-torsa] crl url ldap://1.1.2.22:389/CN=myca
# Specify a 1024-bit general-purpose RSA key pair named abc for certificate request.
[Device-pki-domain-torsa] public-key rsa general name abc length 1024
[Device-pki-domain-torsa] quit
4. Generate the RSA key pair.
[Device] public-key local create rsa name abc
The range of public key modulus is (512 ~ 4096).
If the key modulus is greater than 512,it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
..........................++++++
.....................................++++++
Create the key pair successfully.
5. Request a local certificate:
# Obtain the CA certificate and save it locally.
[Device] pki retrieve-certificate domain torsa ca
The trusted CA's finger print is:
MD5 fingerprint:EDE9 0394 A273 B61A F1B3 0072 A0B1 F9AB
SHA1 fingerprint: 77F9 A077 2FB8 088C 550B A33C 2410 D354 23B2 73A8
Is the finger print correct?(Y/N):y
Retrieved the certificates successfully.
# Submit a certificate request manually and set the certificate revocation password to 1111.
The certificate revocation password is required when an RSA Keon CA server is used.
[Device] pki request-certificate domain torsa password 1111
Start to request general certificate ...
……
Request certificate of domain torsa successfully

Verifying the configuration

# Display information about the local certificate in PKI domain torsa.
[Device] display pki certificate domain torsa local
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
15:79:75:ec:d2:33:af:5e:46:35:83:bc:bd:6e:e3:b8
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=myca
Validity
Not Before: Jan 6 03:10:58 2013 GMT
Not After : Jan 6 03:10:58 2014 GMT
Subject: CN=Device
Subject Public Key Info:

378
 Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:ab:45:64:a8:6c:10:70:3b:b9:46:34:8d:eb:1a:
a1:b3:64:b2:37:27:37:9d:15:bd:1a:69:1d:22:0f:
3a:5a:64:0c:8f:93:e5:f0:70:67:dc:cd:c1:6f:7a:
0c:b1:57:48:55:81:35:d7:36:d5:3c:37:1f:ce:16:
7e:f8:18:30:f6:6b:00:d6:50:48:23:5c:8c:05:30:
6f:35:04:37:1a:95:56:96:21:95:85:53:6f:f2:5a:
dc:f8:ec:42:4a:6d:5c:c8:43:08:bb:f1:f7:46:d5:
f1:9c:22:be:f3:1b:37:73:44:f5:2d:2c:5e:8f:40:
3e:36:36:0d:c8:33:90:f3:9b
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 CRL Distribution Points:

Full Name:
DirName: CN = myca

Signature Algorithm: sha1WithRSAEncryption

b0:9d:d9:ac:a0:9b:83:99:bf:9d:0a:ca:12:99:58:60:d8:aa:
73:54:61:4b:a2:4c:09:bb:9f:f9:70:c7:f8:81:82:f5:6c:af:
25:64:a5:99:d1:f6:ec:4f:22:e8:6a:96:58:6c:c9:47:46:8c:
f1:ba:89:b8:af:fa:63:c6:c9:77:10:45:0d:8f:a6:7f:b9:e8:
25:90:4a:8e:c6:cc:b8:1a:f8:e0:bc:17:e0:6a:11:ae:e7:36:
87:c4:b0:49:83:1c:79:ce:e2:a3:4b:15:40:dd:fe:e0:35:52:
ed:6d:83:31:2c:c2:de:7c:e0:a7:92:61:bc:03:ab:40:bd:69:
1b:f5

To display detailed information about the CA certificate, use the display pki certificate
domain command.

Example: Requesting a certificate from a Windows Server

2003 CA server
Network configuration
Configure the PKI entity (the device) to request a local certificate from a Windows Server 2003 CA
server.
Figure 95 Network diagram

PKI entity

Host Internet

Device CA server

Configuring the Windows Server 2003 CA server

1. Install the certificate service component:
a. Select Control Panel > Add or Remove Programs from the start menu.

379
 b. Select Add/Remove Windows Components > Certificate Services.
c. Click Next to begin the installation.
d. Set the CA name. In this example, set the CA name to myca.
2. Install the SCEP add-on:
By default, Windows Server 2003 does not support SCEP. You must install the SCEP add-on
on the server for a PKI entity to register and obtain a certificate from the server. After the SCEP
add-on installation is complete, you will see a URL. Specify this URL as the certificate request
URL on the device.
3. Modify the certificate service attributes:
a. Select Control Panel > Administrative Tools > Certificate Authority from the start menu.
If the certificate service component and SCEP add-on have been installed successfully,
there should be two certificates issued by the CA to the RA.
b. Right-click the CA server in the navigation tree and select Properties > Policy Module.
c. Click Properties, and then select Follow the settings in the certificate template, if
applicable. Otherwise, automatically issue the certificate.
4. Modify the Internet information services attributes:
a. Select Control Panel > Administrative Tools > Internet Information Services (IIS)
Manager from the start menu.
b. Select Web Sites from the navigation tree.
c. Right-click Default Web Site and select Properties > Home Directory.
d. Specify the path for certificate service in the Local path field.
e. Specify a unique TCP port number for the default website to avoid conflict with existing
services. This example uses port 8080.
Configuring the device
1. Synchronize the device's system time with the CA server for the device to correctly request
certificates. (Details not shown.)
2. Create an entity named aaa and set the common name to test.
<Device> system-view
[Device] pki entity aaa
[Device-pki-entity-aaa] common-name test
[Device-pki-entity-aaa] quit
3. Configure a PKI domain:
# Create a PKI domain named winserver and enter its view.
[Device] pki domain winserver
# Set the name of the trusted CA to myca.
[Device-pki-domain-winserver] ca identifier myca
# Configure the certificate request URL. The URL format is
http://host:port/certsrv/mscep/mscep.dll, where host:port is the host IP address and port
number of the CA server.
[Device-pki-domain-winserver] certificate request url
http://4.4.4.1:8080/certsrv/mscep/mscep.dll
# Configure the device to send certificate requests to ra.
[Device-pki-domain-winserver] certificate request from ra
# Set the PKI entity name to aaa.
[Device-pki-domain-winserver] certificate request entity aaa
# Configure a 1024-bit general-purpose RSA key pair named abc for certificate request.
[Device-pki-domain-winserver] public-key rsa general name abc length 1024

380
 [Device-pki-domain-winserver] quit
4. Generate RSA key pair abc.
[Device] public-key local create rsa name abc
The range of public key modulus is (512 ~ 4096).
If the key modulus is greater than 512,it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
..........................++++++
.....................................++++++
Create the key pair successfully.
5. Request a local certificate:
# Obtain the CA certificate and save it locally.
[Device] pki retrieve-certificate domain winserver ca
The trusted CA's finger print is:
MD5 fingerprint:766C D2C8 9E46 845B 4DCE 439C 1C1F 83AB
SHA1 fingerprint:97E5 DDED AB39 3141 75FB DB5C E7F8 D7D7 7C9B 97B4
Is the finger print correct?(Y/N):y
Retrieved the certificates successfully.
# Submit a certificate request manually.
[Device] pki request-certificate domain winserver
Start to request general certificate ...
…
Request certificate of domain winserver successfully

Verifying the configuration

# Display information about the local certificate in PKI domain winserver.
[Device] display pki certificate domain winserver local
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
(Negative)01:03:99:ff:ff:ff:ff:fd:11
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=sec
Validity
Not Before: Dec 24 07:09:42 2012 GMT
Not After : Dec 24 07:19:42 2013 GMT
Subject: CN=test
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c3:b5:23:a0:2d:46:0b:68:2f:71:d2:14:e1:5a:
55:6e:c5:5e:26:86:c1:5a:d6:24:68:02:bf:29:ac:
dc:31:41:3f:5d:5b:36:9e:53:dc:3a:bc:0d:11:fb:
d6:7d:4f:94:3c:c1:90:4a:50:ce:db:54:e0:b3:27:
a9:6a:8e:97:fb:20:c7:44:70:8f:f0:b9:ca:5b:94:

381
 f0:56:a5:2b:87:ac:80:c5:cc:04:07:65:02:39:fc:
db:61:f7:07:c6:65:4c:e4:5c:57:30:35:b4:2e:ed:
9c:ca:0b:c1:5e:8d:2e:91:89:2f:11:e3:1e:12:8a:
f8:dd:f8:a7:2a:94:58:d9:c7:f8:1a:78:bd:f5:42:
51:3b:31:5d:ac:3e:c3:af:fa:33:2c:fc:c2:ed:b9:
ee:60:83:b3:d3:e5:8e:e5:02:cf:b0:c8:f0:3a:a4:
b7:ac:a0:2c:4d:47:5f:39:4b:2c:87:f2:ee:ea:d0:
c3:d0:8e:2c:80:83:6f:39:86:92:98:1f:d2:56:3b:
d7:94:d2:22:f4:df:e3:f8:d1:b8:92:27:9c:50:57:
f3:a1:18:8b:1c:41:ba:db:69:07:52:c1:9a:3d:b1:
2d:78:ab:e3:97:47:e2:70:14:30:88:af:f8:8e:cb:
68:f9:6f:07:6e:34:b6:38:6a:a2:a8:29:47:91:0e:
25:39
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
X509v3 Subject Key Identifier:
C9:BB:D5:8B:02:1D:20:5B:40:94:15:EC:9C:16:E8:9D:6D:FD:9F:34
X509v3 Authority Key Identifier:
keyid:32:F1:40:BA:9E:F1:09:81:BD:A8:49:66:FF:F8:AB:99:4A:30:21:9B

X509v3 CRL Distribution Points:

Full Name:
URI:file://\\g07904c\CertEnroll\sec.crl

Authority Information Access:

CA Issuers - URI:http://gc/CertEnroll/gc_sec.crt
CA Issuers - URI:file://\\gc\CertEnroll\gc_sec.crt

1.3.6.1.4.1.311.20.2:
.0.I.P.S.E.C.I.n.t.e.r.m.e.d.i.a.t.e.O.f.f.l.i.n.e
Signature Algorithm: sha1WithRSAEncryption
76:f0:6c:2c:4d:bc:22:59:a7:39:88:0b:5c:50:2e:7a:5c:9d:
6c:28:3c:c0:32:07:5a:9c:4c:b6:31:32:62:a9:45:51:d5:f5:
36:8f:47:3d:47:ae:74:6c:54:92:f2:54:9f:1a:80:8a:3f:b2:
14:47:fa:dc:1e:4d:03:d5:d3:f5:9d:ad:9b:8d:03:7f:be:1e:
29:28:87:f7:ad:88:1c:8f:98:41:9a:db:59:ba:0a:eb:33:ec:
cf:aa:9b:fc:0f:69:3a:70:f2:fa:73:ab:c1:3e:4d:12:fb:99:
31:51:ab:c2:84:c0:2f:e5:f6:a7:c3:20:3c:9a:b0:ce:5a:bc:
0f:d9:34:56:bc:1e:6f:ee:11:3f:7c:b2:52:f9:45:77:52:fb:
46:8a:ca:b7:9d:02:0d:4e:c3:19:8f:81:46:4e:03:1f:58:03:
bf:53:c6:c4:85:95:fb:32:70:e6:1b:f3:e4:10:ed:7f:93:27:
90:6b:30:e7:81:36:bb:e2:ec:f2:dd:2b:bb:b9:03:1c:54:0a:
00:3f:14:88:de:b8:92:63:1e:f5:b3:c2:cf:0a:d5:f4:80:47:
6f:fa:7e:2d:e3:a7:38:46:f6:9e:c7:57:9d:7f:82:c7:46:06:
7d:7c:39:c4:94:41:bd:9e:5c:97:86:c8:48:de:35:1e:80:14:

382
 02:09:ad:08

To display detailed information about the CA certificate, use the display pki certificate
domain command.

Example: Requesting a certificate from an OpenCA server

Network configuration
Configure the PKI entity (the device) to request a local certificate from the CA server.
Figure 96 Network diagram

PKI entity

Host Internet

Device CA server

Configuring the OpenCA server

Configure the OpenCA server as instructed in related manuals. (Details not shown.)
Make sure the version of the OpenCA server is later than version 0.9.2 because the earlier versions
do not support SCEP.
Configuring the device
1. Synchronize the device's system time with the CA server for the device to correctly request
certificates. (Details not shown.)
2. Create a PKI entity named aaa and configure the common name, country code, organization
name, and OU for the entity.
<Device> system-view
[Device] pki entity aaa
[Device-pki-entity-aaa] common-name rnd
[Device-pki-entity-aaa] country CN
[Device-pki-entity-aaa] organization test
[Device-pki-entity-aaa] organization-unit software
[Device-pki-entity-aaa] quit
3. Configure a PKI domain:
# Create a PKI domain named openca and enter its view.
[Device] pki domain openca
# Set the name of the trusted CA to myca.
[Device-pki-domain-openca] ca identifier myca
# Configure the certificate request URL. The URL is in the format http://host/cgi-bin/pki/scep,
where host is the host IP address of the OpenCA server.
[Device-pki-domain-openca] certificate request url
http://192.168.222.218/cgi-bin/pki/scep
# Configure the device to send certificate requests to the RA.
[Device-pki-domain-openca] certificate request from ra
# Specify PKI entity aaa for certificate request.
[Device-pki-domain-openca] certificate request entity aaa
# Configure a 1024-bit general-purpose RSA key pair named abc for certificate request.
[Device-pki-domain-openca] public-key rsa general name abc length 1024

383
 [Device-pki-domain-openca] quit
4. Generate RSA key pair abc.
[Device] public-key local create rsa name abc
The range of public key modulus is (512 ~ 4096).
If the key modulus is greater than 512,it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
..........................++++++
.....................................++++++
Create the key pair successfully.
5. Request a local certificate:
# Obtain the CA certificate and save it locally.
[Device] pki retrieve-certificate domain openca ca
The trusted CA's finger print is:
MD5 fingerprint:5AA3 DEFD 7B23 2A25 16A3 14F4 C81C C0FA
SHA1 fingerprint:9668 4E63 D742 4B09 90E0 4C78 E213 F15F DC8E 9122
Is the finger print correct?(Y/N):y
Retrieved the certificates successfully.
# Submit a certificate request manually.
[Device] pki request-certificate domain openca
Start to request general certificate ...
…
Request certificate of domain openca successfully

Verifying the configuration

# Display information about the local certificate in PKI domain openca.
[Device] display pki certificate domain openca local
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
21:1d:b8:d2:e4:a9:21:28:e4:de
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=CN, L=shangdi, ST=pukras, O=OpenCA Labs, OU=mysubUnit, CN=sub-ca,
DC=pki-subdomain, DC=mydomain-sub, DC=com
Validity
Not Before: Jun 30 09:09:09 2011 GMT
Not After : May 1 09:09:09 2012 GMT
Subject: CN=rnd, O=test, OU=software, C=CN
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:b8:7a:9a:b8:59:eb:fc:70:3e:bf:19:54:0c:7e:
c3:90:a5:d3:fd:ee:ff:c6:28:c6:32:fb:04:6e:9c:
d6:5a:4f:aa:bb:50:c4:10:5c:eb:97:1d:a7:9e:7d:
53:d5:31:ff:99:ab:b6:41:f7:6d:71:61:58:97:84:
37:98:c7:7c:79:02:ac:a6:85:f3:21:4d:3c:8e:63:

384
 8d:f8:71:7d:28:a1:15:23:99:ed:f9:a1:c3:be:74:
0d:f7:64:cf:0a:dd:39:49:d7:3f:25:35:18:f4:1c:
59:46:2b:ec:0d:21:1d:00:05:8a:bf:ee:ac:61:03:
6c:1f:35:b5:b4:cd:86:9f:45
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Client, S/MIME
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication, E-mail Protection, Microsoft
Smartcardlogin
Netscape Comment:
User Certificate of OpenCA Labs
X509v3 Subject Key Identifier:
24:71:C9:B8:AD:E1:FE:54:9A:EA:E9:14:1B:CD:D9:45:F4:B2:7A:1B
X509v3 Authority Key Identifier:
keyid:85:EB:D5:F7:C9:97:2F:4B:7A:6D:DD:1B:4D:DD:00:EE:53:CF:FD:5B

X509v3 Issuer Alternative Name:

DNS:[email protected], DNS:, IP Address:192.168.154.145, IP
Address:192.168.154.138
Authority Information Access:
CA Issuers - URI:http://192.168.222.218/pki/pub/cacert/cacert.crt
OCSP - URI:http://192.168.222.218:2560/
1.3.6.1.5.5.7.48.12 - URI:http://192.168.222.218:830/

X509v3 CRL Distribution Points:

Full Name:
URI:http://192.168.222.218/pki/pub/crl/cacrl.crl

Signature Algorithm: sha256WithRSAEncryption

5c:4c:ba:d0:a1:35:79:e6:e5:98:69:91:f6:66:2a:4f:7f:8b:
0e:80:de:79:45:b9:d9:12:5e:13:28:17:36:42:d5:ae:fc:4e:
ba:b9:61:f1:0a:76:42:e7:a6:34:43:3e:2d:02:5e:c7:32:f7:
6b:64:bb:2d:f5:10:6c:68:4d:e7:69:f7:47:25:f5:dc:97:af:
ae:33:40:44:f3:ab:e4:5a:a0:06:8f:af:22:a9:05:74:43:b6:
e4:96:a5:d4:52:32:c2:a8:53:37:58:c7:2f:75:cf:3e:8e:ed:
46:c9:5a:24:b1:f5:51:1d:0f:5a:07:e6:15:7a:02:31:05:8c:
03:72:52:7c:ff:28:37:1e:7e:14:97:80:0b:4e:b9:51:2d:50:
98:f2:e4:5a:60:be:25:06:f6:ea:7c:aa:df:7b:8d:59:79:57:
8f:d4:3e:4f:51:c1:34:e6:c1:1e:71:b5:0d:85:86:a5:ed:63:
1e:08:7f:d2:50:ac:a0:a3:9e:88:48:10:0b:4a:7d:ed:c1:03:
9f:87:97:a3:5e:7d:75:1d:ac:7b:6f:bb:43:4d:12:17:9a:76:
b0:bf:2f:6a:cc:4b:cd:3d:a1:dd:e0:dc:5a:f3:7c:fb:c3:29:

385
 b0:12:49:5c:12:4c:51:6e:62:43:8b:73:b9:26:2a:f9:3d:a4:
81:99:31:89

To display detailed information about the CA certificate, use the display pki certificate
domain command.

Example: Configuring IKE negotiation with RSA digital

signature from a Windows Server 2003 CA server
Network configuration
As shown in the network diagram, an IPsec tunnel is required to be established between Device A
and Device B. The IPsec tunnel protects the traffic between Host A on subnet 10.1.1.0/24 and Host B
on subnet 1.1.1.0/24.
Device A and Device B use IKE to set up SAs, and the IKE proposal uses RSA digital signature for
identity authentication.
Device A and Device B use the same CA.
Figure 97 Network diagram

PKI certificate system

CA 1
1.1.1.101/32

LDAP 1
RA 1 1.1.1.102/32
1.1.1.100/32

Device A Vlan-int1 Vlan-int1 Device B

2.2.2.1/24 3.3.3.1/24
Internet

Host A Host B
10.1.1.2/24 11.1.1.2/24

Configuring the Windows Server 2003 CA server

See "Example: Requesting a certificate from a Windows Server 2003 CA server."
Configuring Device A
# Configure a PKI entity.
<DeviceA> system-view
[DeviceA] pki entity en
[DeviceA-pki-entity-en] ip 2.2.2.1
[DeviceA-pki-entity-en] common-name devicea
[DeviceA-pki-entity-en] quit

386
 # Configure a PKI domain.
[DeviceA] pki domain 1
[DeviceA-pki-domain-1] ca identifier CA1
[DeviceA-pki-domain-1] certificate request url http://1.1.1.100/certsrv/mscep/mscep.dll
[DeviceA-pki-domain-1] certificate request entity en
[DeviceA-pki-domain-1] ldap-server host 1.1.1.102

# Configure the device to send certificate requests to ra.

[DeviceA-pki-domain-1] certificate request from ra

# Configure a 1024-bit general-purpose RSA key pair named abc for certificate request.
[DeviceA-pki-domain-1] public-key rsa general name abc length 1024
[DeviceA-pki-domain-1] quit

# Generate the RSA key pair.

[DeviceA] public-key local create rsa name abc
The range of public key modulus is (512 ~ 4096).
If the key modulus is greater than 512,it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
..........................++++++
.....................................++++++
Create the key pair successfully.

# Obtain the CA certificate and save it locally.

[DeviceA] pki retrieve-certificate domain 1 ca

# Submit a certificate request manually.

[DeviceA] pki request-certificate domain 1

# Create IKE proposal 1, and configure the authentication method as RSA digital signature.
[DeviceA] ike proposal 1
[DeviceA-ike-proposal-1] authentication-method rsa-signature
[DeviceA-ike-proposal-1] quit

# Specify the PKI domain used in IKE negotiation for IKE profile peer.
[DeviceA] ike profile peer
[DeviceA-ike-profile-peer] certificate domain 1

Configuring Device B
# Configure a PKI entity.
<DeviceB> system-view
[DeviceB] pki entity en
[DeviceB-pki-entity-en] ip 3.3.3.1
[DeviceB-pki-entity-en] common-name deviceb
[DeviceB-pki-entity-en] quit

# Configure a PKI domain.

[DeviceB] pki domain 1
[DeviceB-pki-domain-1] ca identifier CA1
[DeviceB-pki-domain-1] certificate request url http://1.1.1.100/certsrv/mscep/mscep.dll
[DeviceB-pki-domain-1] certificate request entity en
[DeviceB-pki-domain-1] ldap-server host 1.1.1.102

# Configure the device to send certificate requests to ra.

387
 [DeviceB-pki-domain-1] certificate request from ra

# Configure a 1024-bit general-purpose RSA key pair named abc for certificate request.
[DeviceB-pki-domain-1] public-key rsa general name abc length 1024
[DeviceB-pki-domain-1] quit

# Generate the RSA key pair.

[DeviceB] public-key local create rsa name abc
The range of public key modulus is (512 ~ 4096).
If the key modulus is greater than 512,it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
..........................++++++
.....................................++++++
Create the key pair successfully.

# Obtain the CA certificate and save it locally.

[DeviceB] pki retrieve-certificate domain 1 ca
The trusted CA's finger print is:
MD5 fingerprint:5C41 E657 A0D6 ECB4 6BD6 1823 7473 AABC
SHA1 fingerprint:1616 E7A5 D89A 2A99 9419 1C12 D696 8228 87BC C266
Is the finger print correct?(Y/N):y
Retrieved the certificates successfully.

# Submit a certificate request manually.

[DeviceB] pki request-certificate domain 1
Start to request general certificate ...
...
Certificate requested successfully.

# Create IKE proposal 1, and configure the authentication method as RSA digital signature.
[DeviceB] ike proposal 1
[DeviceB-ike-proposal-1] authentication-method rsa-signature
[DeviceB-ike-proposal-1] quit

# Specify the PKI domain used in IKE negotiation for IKE profile peer.
[DeviceB] ike profile peer
[DeviceB-ike-profile-peer] certificate domain 1

The configurations are for IKE negotiation with RSA digital signature. For information about how to
configure IPsec SAs to be set up, see "Configuring IPsec."

Example: Importing and exporting certificates

Network configuration
As shown in Figure 98, Device B will replace Device A in the network. PKI domain exportdomain on
Device A has two local certificates containing the private key and one CA certificate. To make sure
the certificates are still valid after Device B replaces Device A, copy the certificates on Device A to
Device B as follows:
1. Export the certificates in PKI domain exportdomain on Device A to .pem certificate files.
During the export, encrypt the private key in the local certificates using 3DES_CBC with the
password 11111.
2. Transfer the certificate files from Device A to Device B through the FTP host.

388
 3. Import the certificate files to PKI domain importdomain on Device B.
Figure 98 Network diagram
1) Export Device A

IP network

Host

2) Import Device B

IP network

Host

Procedure
1. Export the certificates on Device A:
# Export the CA certificate to a .pem file.
<DeviceA> system-view
[DeviceA] pki export domain exportdomain pem ca filename pkicachain.pem
# Export the local certificate to a file named pkilocal.pem in PEM format, and use 3DES_CBC
to encrypt the private key with the password 111111.
[DeviceA] pki export domain exportdomain pem local 3des-cbc 111111 filename
pkilocal.pem
Now, Device A has three certificate files in PEM format:
 A CA certificate file named pkicachain.pem.
 A local certificate file named pkilocal.pem-signature, which contains the private key for
signature.
 A local certificate file named pkilocal.pem-encryption, which contains the private key for
encryption.
# Display local certificate file pkilocal.pem-signature.
[DeviceA] quit
<DeviceA> more pkilocal.pem-signature
Bag Attributes
friendlyName:
localKeyID: 90 C6 DC 1D 20 49 4F 24 70 F5 17 17 20 2B 9E AC 20 F3 99 89
subject=/C=CN/O=OpenCA Labs/OU=Users/CN=subsign 11
issuer=/C=CN/L=shangdi/ST=pukras/O=OpenCA Labs/OU=docm/CN=subca1
-----BEGIN CERTIFICATE-----
MIIEgjCCA2qgAwIBAgILAJgsebpejZc5UwAwDQYJKoZIhvcNAQELBQAwZjELMAkG
…
-----END CERTIFICATE-----
Bag Attributes
friendlyName:
localKeyID: 90 C6 DC 1D 20 49 4F 24 70 F5 17 17 20 2B 9E AC 20 F3 99 89
Key Attributes: <No Attributes>
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIICxjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQIZtjSjfslJCoCAggA
…
-----END ENCRYPTED PRIVATE KEY-----

389
 # Display local certificate file pkilocal.pem-encryption.
<DeviceA> more pkilocal.pem-encryption
Bag Attributes
friendlyName:
localKeyID: D5 DF 29 28 C8 B9 D9 49 6C B5 44 4B C2 BC 66 75 FE D6 6C C8
subject=/C=CN/O=OpenCA Labs/OU=Users/CN=subencr 11
issuer=/C=CN/L=shangdi/ST=pukras/O=OpenCA Labs/OU=docm/CN=subca1
-----BEGIN CERTIFICATE-----
MIIEUDCCAzigAwIBAgIKCHxnAVyzWhIPLzANBgkqhkiG9w0BAQsFADBmMQswCQYD
…
-----END CERTIFICATE-----
Bag Attributes
friendlyName:
localKeyID: D5 DF 29 28 C8 B9 D9 49 6C B5 44 4B C2 BC 66 75 FE D6 6C C8
Key Attributes: <No Attributes>
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIICxjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQI7H0mb4O7/GACAggA
…
-----END ENCRYPTED PRIVATE KEY-----
2. Download certificate files pkicachain.pem, pkilocal.pem-signature, and
pkilocal.pem-encryption from Device A to the host through FTP. (Details not shown.)
3. Upload certificate files pkicachain.pem, pkilocal.pem-signature, and
pkilocal.pem-encryption from the host to Device B through FTP. (Details not shown.)
4. Import the certificate files to Device B:
# Disable CRL checking. (You can configure CRL checking as required. This example assumes
CRL checking is not required.)
<DeviceB> system-view
[DeviceB] pki domain importdomain
[DeviceB-pki-domain-importdomain] undo crl check enable
# Specify RSA key pair sign for signature and RSA key pair encr for encryption.
[DeviceB-pki-domain-importdomain] public-key rsa signature name sign encryption name
encr
[DeviceB-pki-domain-importdomain] quit
# Import CA certificate file pkicachain.pem in PEM format to the PKI domain.
[DeviceB] pki import domain importdomain pem ca filename pkicachain.pem
# Import local certificate file pkilocal.pem-signature in PEM format to the PKI domain. The
certificate file contains a key pair.
[DeviceB] pki import domain importdomain pem local filename pkilocal.pem-signature
Please input the password:******
# Import local certificate file pkilocal.pem-encryption in PEM format to the PKI domain. The
certificate file contains a key pair.
[DeviceB] pki import domain importdomain pem local filename pkilocal.pem-encryption
Please input the password:******
# Display the imported local certificate information on Device B.
[DeviceB] display pki certificate domain importdomain local
Certificate:
Data:
Version: 3 (0x2)
Serial Number:

390
 98:2c:79:ba:5e:8d:97:39:53:00
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=CN, L=shangdi, ST=pukras, O=OpenCA Labs, OU=docm, CN=subca1
Validity
Not Before: May 26 05:56:49 2011 GMT
Not After : Nov 22 05:56:49 2012 GMT
Subject: C=CN, O=OpenCA Labs, OU=Users, CN=subsign 11
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:9f:6e:2f:f6:cb:3d:08:19:9a:4a:ac:b4:ac:63:
ce:8d:6a:4c:3a:30:19:3c:14:ff:a9:50:04:f5:00:
ee:a3:aa:03:cb:b3:49:c4:f8:ae:55:ee:43:93:69:
6c:bf:0d:8c:f4:4e:ca:69:e5:3f:37:5c:83:ea:83:
ad:16:b8:99:37:cb:86:10:6b:a0:4d:03:95:06:42:
ef:ef:0d:4e:53:08:0a:c9:29:dd:94:28:02:6e:e2:
9b:87:c1:38:2d:a4:90:a2:13:5f:a4:e3:24:d3:2c:
bf:98:db:a7:c2:36:e2:86:90:55:c7:8c:c5:ea:12:
01:31:69:bf:e3:91:71:ec:21
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Client, S/MIME
X509v3 Key Usage:
Digital Signature, Non Repudiation
X509v3 Extended Key Usage:
TLS Web Client Authentication, E-mail Protection, Microsoft
Smartcardlogin
Netscape Comment:
User Certificate of OpenCA Labs
X509v3 Subject Key Identifier:
AA:45:54:29:5A:50:2B:89:AB:06:E5:BD:0D:07:8C:D9:79:35:B1:F5
X509v3 Authority Key Identifier:
keyid:70:54:40:61:71:31:02:06:8C:62:11:0A:CC:A5:DB:0E:7E:74:DE:DD

X509v3 Subject Alternative Name:

email:[email protected]
X509v3 Issuer Alternative Name:
DNS:[email protected], DNS:, IP Address:1.1.2.2, IP Address:2.2.1.1
Authority Information Access:
CA Issuers - URI:http://titan/pki/pub/cacert/cacert.crt
OCSP - URI:http://titan:2560/
1.3.6.1.5.5.7.48.12 - URI:http://titan:830/

X509v3 CRL Distribution Points:

391
 Full Name:
URI:http://192.168.40.130/pki/pub/crl/cacrl.crl

Signature Algorithm: sha256WithRSAEncryption

18:e7:39:9a:ad:84:64:7b:a3:85:62:49:e5:c9:12:56:a6:d2:
46:91:53:8e:84:ba:4a:0a:6f:28:b9:43:bc:e7:b0:ca:9e:d4:
1f:d2:6f:48:c4:b9:ba:c5:69:4d:90:f3:15:c4:4e:4b:1e:ef:
2b:1b:2d:cb:47:1e:60:a9:0f:81:dc:f2:65:6b:5f:7a:e2:36:
29:5d:d4:52:32:ef:87:50:7c:9f:30:4a:83:de:98:8b:6a:c9:
3e:9d:54:ee:61:a4:26:f3:9a:40:8f:a6:6b:2b:06:53:df:b6:
5f:67:5e:34:c8:c3:b5:9b:30:ee:01:b5:a9:51:f9:b1:29:37:
02:1a:05:02:e7:cc:1c:fe:73:d3:3e:fa:7e:91:63:da:1d:f1:
db:28:6b:6c:94:84:ad:fc:63:1b:ba:53:af:b3:5d:eb:08:b3:
5b:d7:22:3a:86:c3:97:ef:ac:25:eb:4a:60:f8:2b:a3:3b:da:
5d:6f:a5:cf:cb:5a:0b:c5:2b:45:b7:3e:6e:39:e9:d9:66:6d:
ef:d3:a0:f6:2a:2d:86:a3:01:c4:94:09:c0:99:ce:22:19:84:
2b:f0:db:3e:1e:18:fb:df:56:cb:6f:a2:56:35:0d:39:94:34:
6d:19:1d:46:d7:bf:1a:86:22:78:87:3e:67:fe:4b:ed:37:3d:
d6:0a:1c:0b

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
08:7c:67:01:5c:b3:5a:12:0f:2f
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=CN, L=shangdi, ST=pukras, O=OpenCA Labs, OU=docm, CN=subca1
Validity
Not Before: May 26 05:58:26 2011 GMT
Not After : Nov 22 05:58:26 2012 GMT
Subject: C=CN, O=OpenCA Labs, OU=Users, CN=subencr 11
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:db:26:13:d3:d1:a4:af:11:f3:6d:37:cf:d0:d4:
48:50:4e:0f:7d:54:76:ed:50:28:c6:71:d4:48:ae:
4d:e7:3d:23:78:70:63:18:33:f6:94:98:aa:fa:f6:
62:ed:8a:50:c6:fd:2e:f4:20:0c:14:f7:54:88:36:
2f:e6:e2:88:3f:c2:88:1d:bf:8d:9f:45:6c:5a:f5:
94:71:f3:10:e9:ec:81:00:28:60:a9:02:bb:35:8b:
bf:85:75:6f:24:ab:26:de:47:6c:ba:1d:ee:0d:35:
75:58:10:e5:e8:55:d1:43:ae:85:f8:ff:75:81:03:
8c:2e:00:d1:e9:a4:5b:18:39
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE

392
 Netscape Cert Type:
SSL Server
X509v3 Key Usage:
Key Encipherment, Data Encipherment
Netscape Comment:
VPN Server of OpenCA Labs
X509v3 Subject Key Identifier:
CC:96:03:2F:FC:74:74:45:61:38:1F:48:C0:E8:AA:18:24:F0:2B:AB
X509v3 Authority Key Identifier:
keyid:70:54:40:61:71:31:02:06:8C:62:11:0A:CC:A5:DB:0E:7E:74:DE:DD

X509v3 Subject Alternative Name:

email:[email protected]
X509v3 Issuer Alternative Name:
DNS:[email protected], DNS:, IP Address:1.1.2.2, IP Address:2.2.1.1
Authority Information Access:
CA Issuers - URI:http://titan/pki/pub/cacert/cacert.crt
OCSP - URI:http://titan:2560/
1.3.6.1.5.5.7.48.12 - URI:http://titan:830/

X509v3 CRL Distribution Points:

Full Name:
URI:http://192.168.40.130/pki/pub/crl/cacrl.crl

Signature Algorithm: sha256WithRSAEncryption

53:69:66:5f:93:f0:2f:8c:54:24:8f:a2:f2:f1:29:fa:15:16:
90:71:e2:98:e3:5c:c6:e3:d4:5f:7a:f6:a9:4f:a2:7f:ca:af:
c4:c8:c7:2c:c0:51:0a:45:d4:56:e2:81:30:41:be:9f:67:a1:
23:a6:09:50:99:a1:40:5f:44:6f:be:ff:00:67:9d:64:98:fb:
72:77:9e:fd:f2:4c:3a:b2:43:d8:50:5c:48:08:e7:77:df:fb:
25:9f:4a:ea:de:37:1e:fb:bc:42:12:0a:98:11:f2:d9:5b:60:
bc:59:72:04:48:59:cc:50:39:a5:40:12:ff:9d:d0:69:3a:5e:
3a:09:5a:79:e0:54:67:a0:32:df:bf:72:a0:74:63:f9:05:6f:
5e:28:d2:e8:65:49:e6:c7:b5:48:7d:95:47:46:c1:61:5a:29:
90:65:45:4a:88:96:e4:88:bd:59:25:44:3f:61:c6:b1:08:5b:
86:d2:4f:61:4c:20:38:1c:f4:a1:0b:ea:65:87:7d:1c:22:be:
b6:17:17:8a:5a:0f:35:4c:b8:b3:73:03:03:63:b1:fc:c4:f5:
e9:6e:7c:11:e8:17:5a:fb:39:e7:33:93:5b:2b:54:72:57:72:
5e:78:d6:97:ef:b8:d8:6d:0c:05:28:ea:81:3a:06:a0:2e:c3:
79:05:cd:c3

To display detailed information about the CA certificate, use the display pki certificate
domain command.

Troubleshooting PKI configuration

This section provides troubleshooting information for common problems with PKI.

393
Failed to obtain the CA certificate
Symptom
The CA certificate cannot be obtained.
Analysis
• The network connection is down, for example, because the network cable is damaged or the
connectors have bad contact.
• No trusted CA is specified.
• The certificate request URL is incorrect or not specified.
• The system time of the device is not synchronized with the CA server.
• The CA server does not accept the source IP address specified in the PKI domain, or no source
IP address is specified.
• The fingerprint of the root CA certificate is illegal.
Solution
1. Fix the network connection problems, if any.
2. Configure the trusted CA and all other required parameters in the PKI domain.
3. Use the ping command to verify that the CA server is reachable.
4. Synchronize the system time of the device with the CA server.
5. Specify the correct source IP address that the CA server can accept. For the correct settings,
contact the CA administrator.
6. Verify the fingerprint of the CA certificate on the CA server.
7. If the problem persists, contact Hewlett Packard Enterprise Support.

Failed to obtain local certificates

Symptom
The local certificates can be obtained.
Analysis
• The network connection is down.
• The PKI domain does not have a CA certificate before you submit the local certificate request.
• The LDAP server is not configured or is incorrectly configured.
• No key pair is specified for certificate request in the PKI domain, or the specified key pair does
not match the one contained in the local certificates to the obtained.
• No PKI entity is configured in the PKI domain, or the PKI entity configuration is incorrect.
• CRL checking is enabled, but the PKI domain does not have a CRL and cannot obtain one.
• The CA server does not accept the source IP address specified in the PKI domain, or no source
IP address is specified.
• The system time of the device is not synchronized with the CA server.
Solution
1. Fix the network connection problems, if any..
2. Obtain or import the CA certificate.
3. Configure the correct LDAP server parameters.

394
 4. Specify the key pair for certificate request, or remove the existing key pair, specify a new key
pair, and submit a local certificate request again.
5. Check the registration policy on the CA or RA, and make sure the attributes of the PKI entity
meet the policy requirements.
6. Obtain the CRL from the CRL repository.
7. Specify the correct source IP address that the CA server can accept. For the correct settings,
contact the CA administrator.
8. Synchronize the system time of the device with the CA server.
9. If the problem persists, contact Hewlett Packard Enterprise Support.

Failed to request local certificates

Symptom
Local certificate requests cannot be submitted.
Analysis
• The network connection is down, for example, because the network cable is damaged or the
connectors have bad contact.
• The PKI domain does not have a CA certificate before the local certificate request is submitted.
• The certificate request URL is incorrect or is not specified.
• The certificate request reception authority is incorrect or is not specified.
• Required PKI entity parameters are not configured or are incorrectly configured.
• No key pair is specified in the PKI domain for certificate request, or the key pair is changed
during a certificate request process.
• Exclusive certificate request applications are running in the PKI domain.
• The CA server does not accept the source IP address specified in the PKI domain, or no source
IP address is specified.
• The system time of the device is not synchronized with the CA server.
Solution
1. Fix the network connection problems, if any.
2. Obtain or import the CA certificate.
3. Use the ping command to verify that the registration server is reachable.
4. Use the certificate request from command to specify the correct certificate request
reception authority.
5. Configure the PKI entity parameters as required by the registration policy on the CA or RA.
6. Specify the key pair for certificate request, or remove the existing key pair, specify a new key
pair, and submit a local certificate request again.
7. Use the pki abort-certificate-request domain command to abort the certificate
request.
8. Specify the correct source IP address that the CA server can accept. For the correct settings,
contact the CA administrator.
9. Synchronize the system time of the device with the CA server.
10. If the problem persists, contact Hewlett Packard Enterprise Support.

395
Failed to obtain CRLs
Symptom
CRLs cannot be obtained.
Analysis
• The network connection is down, for example, because the network cable is damaged or the
connectors have bad contact.
• The PKI domain does not have a CA certificate before you try to obtain CRLs.
• The URL of the CRL repository is not configured and cannot be obtained from the CA certificate
or local certificates in the PKI domain.
• The specified URL of the CRL repository is incorrect.
• The device tries to obtain CRLs through SCEP, but it experiences the following problems:
 The PKI domain does not have local certificates.
 The key pairs in the certificates have been changed.
 The PKI domain has incorrect URL for certificate request.
• The CRL repository uses LDAP for CRL distribution. However, the IP address or host name of
the LDAP server is neither contained in the CRL repository URL nor configured in the PKI
domain.
• The CA does not issue CRLs.
• The CA server does not accept the source IP address specified in the PKI domain, or no source
IP address is specified.
Solution
1. Fix the network connection problems, if any.
2. Obtain or import the CA certificate.
3. If the URL of the CRL repository cannot be obtained, verify that the following conditions exist:
 The URL for certificate request is valid.
 A local certificate has been successfully obtained.
 The local certificate contains a public key that matches the locally stored key pair.
4. Make sure the LDAP server address is contained in the CRL repository URL, or is configured in
the PKI domain.
5. Make sure the CA server support publishing CRLs.
6. Specify a correct source IP address that the CA server can accept. For the correct settings,
contact the CA administrator.
7. If the problem persists, contact Hewlett Packard Enterprise Support.

Failed to import the CA certificate

Symptom
The CA certificate cannot be imported.
Analysis
• CRL checking is enabled, but the device does not have a CRL in the PKI domain and cannot
obtain one.
• The specified format in which the CA certificate file is to be imported does not match actual
certificate file format.

396
Solution
1. Use the undo crl check enable command to disable CRL checking in the PKI domain.
2. Make sure the format of the imported file is correct.
3. If the problem persists, contact Hewlett Packard Enterprise Support.

Failed to import the local certificate

Symptom
The local certificate cannot be imported.
Analysis
• The PKI domain does not have a CA certificate, and the local certificate file to be imported does
not contain the CA certificate chain.
• CRL checking is enabled, but the device does not have a CRL in the PKI domain and cannot
obtain one.
• The specified format in which the local certificate file is to be imported does not match actual
certificate file format.
• The device and the certificate do not have the local key pair.
• The certificate has been revoked.
• The certificate is out of the validity period.
• The system time is incorrect.
Solution
1. Obtain or import the CA certificate.
2. Use the undo crl check enable command to disable CRL checking, or obtain the correct
CRL before you import certificates.
3. Make sure the format of the file to be imported is correct.
4. Make sure the certificate file contains the private key.
5. Make sure the certificate is not revoked.
6. Make sure the certificate is valid.
7. Configure the correct system time for the device.
8. If the problem persists, contact Hewlett Packard Enterprise Support.

Failed to export certificates

Symptom
Certificates cannot be exported.
Analysis
• The PKI domain does not have local certificates when you export all certificates in PKCS12
format.
• The specified export path does not exist.
• The specified export path is illegal.
• The public key of the local certificate to be exported does not match the public key of the key
pair configured in the PKI domain.
• The storage space of the device is full.

397
Solution
1. Obtain or request local certificates first.
2. Use the mkdir command to create the required path.
3. Specify a correct export path.
4. Configure the correct key pair in the PKI domain.
5. Clear up the storage space of the device.
6. If the problem persists, contact Hewlett Packard Enterprise Support.

Failed to set the storage path

Symptom
The storage path for certificates or CRLs cannot be set.
Analysis
• The specified storage path does not exist.
• The specified storage path is illegal.
• The storage space of the device is full.
Solution
1. Use the mkdir command to create the path.
2. Specify a valid storage path for certificates or CRLs.
3. Clear up the storage space of the device.
4. If the problem persists, contact Hewlett Packard Enterprise Support.

398
Configuring IPsec
About IPsec
IP Security (IPsec) is defined by the IETF to provide interoperable, high-quality, cryptography-based
security for IP communications. It is a Layer 3 VPN technology that transmits data in a secure
channel established between two endpoints (such as two security gateways). Such a secure channel
is usually called an IPsec tunnel.

IPsec framework
IPsec is a security framework that has the following protocols and algorithms:
• Authentication Header (AH).
• Encapsulating Security Payload (ESP).
• Internet Key Exchange (IKE).
• Algorithms for authentication and encryption.
AH and ESP are security protocols that provide security services. IKE performs automatic key
exchange. For more information about IKE, see "Configuring IKE."

IPsec security services

IPsec provides the following security services for data packets in the IP layer:
• Confidentiality—The sender encrypts packets before transmitting them over the Internet,
protecting the packets from being eavesdropped en route.
• Data integrity—The receiver verifies the packets received from the sender to make sure they
are not tampered with during transmission.
• Data origin authentication—The receiver verifies the authenticity of the sender.
• Anti-replay—The receiver examines packets and drops outdated and duplicate packets.

Benefits of IPsec
IPsec delivers the following benefits:
• Reduced key negotiation overhead and simplified maintenance by supporting the IKE protocol.
IKE provides automatic key negotiation and automatic IPsec security association (SA) setup
and maintenance.
• Good compatibility. You can apply IPsec to all IP-based application systems and services
without modifying them.
• Encryption on a per-packet rather than per-flow basis. Per-packet encryption allows for
flexibility and greatly enhances IP security.

Security protocols
IPsec comes with two security protocols, AH and ESP. They define how to encapsulate IP packets
and the security services that they can provide.
• AH (protocol 51) defines the encapsulation of the AH header in an IP packet, as shown in
Figure 101. AH can provide data origin authentication, data integrity, and anti-replay services to

399
 prevent data tampering, but it cannot prevent eavesdropping. Therefore, it is suitable for
transmitting non-confidential data. The authentication algorithms supported by AH include
HMAC-MD5 and HMAC-SHA1. AH does not support NAT traversal.
• ESP (protocol 50) defines the encapsulation of the ESP header and trailer in an IP packet, as
shown in Figure 101. ESP can provide data encryption, data origin authentication, data integrity,
and anti-replay services. Unlike AH, ESP can guarantee data confidentiality because it can
encrypt the data before encapsulating the data to IP packets. ESP-supported encryption
algorithms include DES, 3DES, and AES, and authentication algorithms include HMAC-MD5
and HMAC-SHA1.
Both AH and ESP provide authentication services, but the authentication service provided by AH is
stronger. In practice, you can choose either or both security protocols. When both AH and ESP are
used, an IP packet is encapsulated first by ESP and then by AH.

Encapsulation modes
IPsec supports the following encapsulation modes: transport mode and tunnel mode.
Transport mode
The security protocols protect the upper layer data of an IP packet. Only the transport layer data is
used to calculate the security protocol headers. The calculated security protocol headers and the
encrypted data (only for ESP encapsulation) are placed after the original IP header. You can use the
transport mode when end-to-end security protection is required (the secured transmission start and
end points are the actual start and end points of the data). The transport mode is typically used for
protecting host-to-host communications, as shown in Figure 99.
Figure 99 IPsec protection in transport mode

IPsec tunnel

Host A Host B
Data flow

Tunnel mode
The security protocols protect the entire IP packet. The entire IP packet is used to calculate the
security protocol headers. The calculated security protocol headers and the encrypted data (only for
ESP encapsulation) are encapsulated in a new IP packet. In this mode, the encapsulated packet has
two IP headers. The inner IP header is the original IP header. The outer IP header is added by the
network device that provides the IPsec service. You must use the tunnel mode when the secured
transmission start and end points are not the actual start and end points of the data packets (for
example, when two gateways provide IPsec but the data start and end points are two hosts behind
the gateways). The tunnel mode is typically used for protecting gateway-to-gateway communications,
as shown in Figure 100.
Figure 100 IPsec protection in tunnel mode

IPsec tunnel

Host A Gateway A Gateway B Host B

Data flow

Figure 101 shows how the security protocols encapsulate an IP packet in different encapsulation
modes.

400
 Figure 101 Security protocol encapsulations in different modes

Mode
Transport Tunnel
Protocol

AH IP AH Data IP AH IP Data

ESP IP ESP Data ESP-T IP ESP IP Data ESP-T

AH-ESP IP AH ESP Data ESP-T IP AH ESP IP Data ESP-T

Security association
A security association (SA) is an agreement negotiated between two communicating parties called
IPsec peers. An SA includes the following parameters for data protection:
• Security protocols (AH, ESP, or both).
• Encapsulation mode (transport mode or tunnel mode).
• Authentication algorithm (HMAC-MD5 or HMAC-SHA1).
• Encryption algorithm (DES, 3DES, or AES).
• Shared keys and their lifetimes.
An SA is unidirectional. At least two SAs are needed to protect data flows in a bidirectional
communication. If two peers want to use both AH and ESP to protect data flows between them, they
construct an independent SA for each protocol in each direction.
An SA is uniquely identified by a triplet, which consists of the security parameter index (SPI),
destination IP address, and security protocol identifier. An SPI is a 32-bit number. It is transmitted in
the AH/ESP header.
An SA can be set up manually or through IKE.
• Manual mode—Configure all parameters for the SA through commands. This configuration
mode is complex and does not support some advanced features (such as periodic key update),
but it can implement IPsec without IKE. This mode is mainly used in small and static networks
or when the number of IPsec peers in the network is small.
• IKE negotiation mode—The peers negotiate and maintain the SA through IKE. This
configuration mode is simple and has good expansibility. As a best practice, set up SAs through
IKE negotiations in medium- and large-scale dynamic networks.
A manually configured SA never ages out. An IKE-created SA has a lifetime, which comes in two
types:
• Time-based lifetime—Defines how long the SA can be valid after it is created.
• Traffic-based lifetime—Defines the maximum traffic that the SA can process.
If both lifetime timers are configured for an SA, the SA becomes invalid when either of the lifetime
timers expires. Before the SA expires, IKE negotiates a new SA, which takes over immediately after
its creation.

Authentication and encryption

Authentication algorithms
IPsec uses hash algorithms to perform authentication. A hash algorithm produces a fixed-length
digest for an arbitrary-length message. IPsec peers respectively calculate message digests for each
packet. The receiver compares the local digest with that received from the sender. If the digests are

401
 identical, the receiver considers the packet intact and the sender's identity valid. IPsec uses the
Hash-based Message Authentication Code (HMAC) based authentication algorithms, including
HMAC-MD5 and HMAC-SHA1. Compared with HMAC-SHA1, HMAC-MD5 is faster but less secure.
Encryption algorithms
IPsec uses symmetric encryption algorithms, which encrypt and decrypt data by using the same
keys. The following encryption algorithms are available for IPsec on the device:
• DES—Encrypts a 64-bit plaintext block with a 56-bit key. DES is the least secure but the fastest
algorithm.
• 3DES—Encrypts plaintext data with three 56-bit DES keys. The key length totals up to 168 bits.
It provides moderate security strength and is slower than DES.
• AES—Encrypts plaintext data with a 128-bit, 192-bit, or 256-bit key. AES provides the highest
security strength and is slower than 3DES.

IPsec-protected traffic
IPsec tunnels can protect the following types of traffic:
• Packets that match specific ACLs.
• Packets routed to a tunnel interface.
• Packets of IPv6 routing protocols.
Two peers use security policies (IPsec policies or IPsec profiles) to protect packets between them. A
security policy defines the range of packets to be protected by IPsec and the security parameters
used for the protection. For more information about IPsec policies and IPsec profiles, see "IPsec
policy and IPsec profile."
The following information describes how IPsec protects packets:
• When an IPsec peer identifies the packets to be protected according to the security policy, it
sets up an IPsec tunnel and sends the packet to the remote peer through the tunnel. The IPsec
tunnel can be manually configured beforehand, or it can be set up through IKE negotiation
triggered by the packet. The IPsec tunnels are actually the IPsec SAs. The inbound packets are
protected by the inbound SA, and the outbound packets are protected by the outbound SA.
• When the remote IPsec peer receives the packet, it drops, de-encapsulates, or directly
forwards the packet according to the configured security policy.

ACL-based IPsec
To implement ACL-based IPsec, configure an ACL to define the data flows to be protected, specify
the ACL in an IPsec policy, and then apply the IPsec policy to an interface. You can apply an IPsec
policy to physical interfaces such as serial interfaces and Ethernet interfaces, or virtual interfaces
such as tunnel interfaces and virtual template interfaces.
ACL-based IPsec works as follows:
• When packets sent by the interface match a permit rule of the ACL, the packets are protected
by the outbound IPsec SA and encapsulated with IPsec.
• When the interface receives an IPsec packet destined for the local device, it searches for the
inbound IPsec SA according to the SPI in the IPsec packet header for de-encapsulation. If the
de-encapsulated packet matches a permit rule of the ACL, the device processes the packet. If
the de-encapsulated packet does not match any permit rule of the ACL, the device drops the
packet.
The device supports the following data flow protection modes:
• Standard mode—One IPsec tunnel protects one data flow. The data flow permitted by an ACL
rule is protected by one IPsec tunnel that is established solely for it.

402
 • Aggregation mode—One IPsec tunnel protects all data flows permitted by all the rules of an
ACL. This mode is only used to communicate with old-version devices.
• Per-host mode—One IPsec tunnel protects one host-to-host data flow. One host-to-host data
flow is identified by one ACL rule and protected by one IPsec tunnel established solely for it.
This mode consumes more system resources when multiple data flows exist between two
subnets to be protected.

IPv6 routing protocol-based IPsec

You can implement IPv6 routing protocol-based IPsec by binding an IPsec profile to an IPv6 routing
protocol. All packets of the protocol are encapsulated with IPsec. Supported IPv6 routing protocols
include OSPFv3, IPv6 BGP, and RIPng.
All packets of the applications that are not bound to IPsec and the IPsec packets that failed to be
de-encapsulated are dropped.
In one-to-many communication scenarios, you must configure the IPsec SAs for an IPv6 routing
protocol in manual mode because of the following reasons:
• The automatic key exchange mechanism protects communications between two points. In
one-to-many communication scenarios, automatic key exchange cannot be implemented.
• One-to-many communication scenarios require that all the devices use the same SA
parameters (SPI and key) to receive and send packets. IKE negotiated SAs cannot meet this
requirement.

IPsec policy and IPsec profile

IPsec policies and IPsec profiles define the parameters used to establish IPsec tunnels between two
peers and the range of packets to be protected.
IPsec policy
An IPsec policy is a set of IPsec policy entries that have the same name but different sequence
numbers.
An IPsec policy contains the following settings:
• An ACL that defines the range of data flows to be protected.
• An IPsec transform set that defines the security parameters used for IPsec protection.
• IPsec SA establishment mode.
IPsec SAs can be established through manual configuration or IKE negotiation.
• Local and remote IP addresses that define the start and end points of the IPsec tunnel.
In the same IPsec policy, an IPsec policy entry with a smaller sequence number has a higher priority.
When sending a packet, the interface applied with an IPsec policy looks through the IPsec policy's
entries in ascending order of sequence numbers. If the packet matches the ACL of an IPsec policy
entry, the interface encapsulates the packet according to the IPsec policy entry. If no match is found,
the interface sends the packet out without IPsec protection.
When the interface receives an IPsec packet destined for the local device, it searches for the
inbound IPsec SA according to the SPI in the IPsec packet header for de-encapsulation. If the
de-encapsulated packet matches a permit rule of the ACL, the device processes the packet. If the
de-encapsulated packet does not match a permit rule of the ACL, the device drops the packet.
IPsec profile
An IPsec profile has similar settings as an IPsec policy. It is uniquely identified by a name and does
not support ACL configuration.
IPsec profiles can be classified into the following types:

403
 • Manual IPsec profile—A manual IPsec profile is used to protect IPv6 routing protocols. It
specifies the IPsec transform set used for protecting data flows, and the SPIs and keys used by
the SAs.
• IKE-based IPsec profile—An IKE-based IPsec profile is applied to tunnel interfaces to protect
tunneled traffic. It specifies the IPsec transform sets used for protecting data flows, and the IKE
profile used for IKE negotiation.

IPsec RRI
IPsec Reverse Route Injection (RRI) enables an IPsec tunnel gateway to automatically add and
delete static routes destined for the protected private networks. It automatically adds the static routes
when the IPsec SAs are established and deletes the static routes when the IPsec SAs are deleted.
This greatly reduces the static route configuration work load on the gateway and increases the
scalability of the IPsec VPN.
IPsec RRI is applicable to gateways that must provide many IPsec tunnels (for example, a
headquarters gateway).
As shown in Figure 102, the traffic between the enterprise center and the branches are protected by
IPsec. The gateway at the enterprise center is configured with static routes to route traffic to the
IPsec-protected interfaces. It is difficult to add or modify static routes on the gateway at the
enterprise center if the IPsec VPN has a large number of branches or if the network structure
changes.
Figure 102 IPsec VPN
Branch A
ip route-static BranchA_network …
ip route-static BranchB_network …
ip route-static BranchC_network ...

Enterprise Center nel

c tun
IPse Branch B

Internet
IPsec tunnel
GW
IPse
c tun
nel
Branch C

After you can enable IPsec RRI on the gateway, the gateway automatically adds a static route to the
routing table each time an IPsec tunnel is established. The destination IP address is the protected
private network, and the next hop is the remote IP address of the IPsec tunnel. Traffic destined for
the peer end is routed to the IPsec tunnel interface and thereby protected by IPsec.
You can advertise the static routes created by IPsec RRI in the internal network, and the internal
network device can use them to forward traffic in the IPsec VPN.
You can set preferences for the static routes created by IPsec RRI to implement flexible route
management. For example, you can set the same preference for multiple routes to the same
destination to implement load sharing, or you can set different preferences to implement route
backup.
You can also set tags for the static routes created by IPsec RRI to implement flexible route control
through routing policies.

404
Protocols and standards
• RFC 2401, Security Architecture for the Internet Protocol
• RFC 2402, IP Authentication Header
• RFC 2406, IP Encapsulating Security Payload
• RFC 4552, Authentication/Confidentiality for OSPFv3

FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for
features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and
non-FIPS mode.

Restrictions and guidelines: IPsec configuration

Typically, IKE uses UDP port 500 for communication, and AH and ESP use the protocol numbers 51
and 50, respectively. Make sure traffic of these protocols is not denied on the interfaces with IKE or
IPsec configured.

Implementing ACL-based IPsec

ACLs for IPsec take effect only on traffic that is generated by the device and traffic that is destined for
the device. They do not take effect on traffic forwarded through the device. For example, an
ACL-based IPsec tunnel can protect log messages the device sends to a log server, but it does not
protect data flows and voice flows that are forwarded by the device.

ACL-based IPsec tasks at a glance

To configure ACL-based IPsec, perform the following tasks:
1. Configuring an ACL
2. Configuring an IPsec transform set
3. Configuring an IPsec policy
Choose one of the following tasks:
 Configuring a manual IPsec policy
 Configuring an IKE-based IPsec policy
4. Applying an IPsec policy to an interface
5. (Optional.) Configuring accessibility features for ACL-based IPsec
 Enabling ACL checking for de-encapsulated packets
 Configuring IPsec anti-replay
 Configuring IPsec anti-replay redundancy
 Binding a source interface to an IPsec policy
 Enabling QoS pre-classify
 Configuring the DF bit of IPsec packets
 Configuring IPsec RRI
 Configuring the global IPsec SA lifetime and idle timeout
 Configuring IPsec fragmentation

405
  Setting the maximum number of IPsec tunnels
6. (Optional.) Configuring logging and SNMP notification for IPsec.
 Enabling logging for IPsec packets
 Configuring SNMP notifications for IPsec

Configuring an ACL
IPsec uses ACLs to identify the traffic to be protected.
Keywords in ACL rules
An ACL is a collection of ACL rules. Each ACL rule is a deny or permit statement. A permit statement
identifies a data flow protected by IPsec, and a deny statement identifies a data flow that is not
protected by IPsec. IPsec compares a packet against the ACL rules and processes the packet
according to the first rule it matches.
• Each ACL rule matches both the outbound traffic and the returned inbound traffic. Suppose
there is a rule rule 0 permit ip source 1.1.1.0 0.0.0.255 destination 2.2.2.0 0.0.0.255. This
rule matches both traffic from 1.1.1.0 to 2.2.2.0 and traffic from 2.2.2.0 to 1.1.1.0.
• In the outbound direction, if a permit statement is matched, IPsec considers that the packet
requires protection and continues to process it. If a deny statement is matched or no match is
found, IPsec considers that the packet does not require protection and delivers it to the next
module.
• In the inbound direction:
 Non-IPsec packets that match a permit statement are dropped.
 IPsec packets destined for the device itself are de-encapsulated. By default, the
de-encapsulated packets are compared against the ACL rules. Only those that match a
permit statement are processed. Other packets are dropped. If ACL checking for
de-encapsulated IPsec packets is disabled, the de-encapsulated packets are not compared
against the ACL rules and are directly processed by other modules.
When defining ACL rules for IPsec, follow these guidelines:
• Permit only data flows that need to be protected and use the any keyword with caution. With
the any keyword specified in a permit statement, all outbound traffic matching the permit
statement will be protected by IPsec. All inbound IPsec packets matching the permit statement
will be received and processed, but all inbound non-IPsec packets will be dropped. This will
cause all the inbound traffic that does not need IPsec protection to be dropped.
• Avoid statement conflicts in the scope of IPsec policy entries. When creating a deny statement,
be careful with its match scope and match order relative to permit statements. The policy
entries in an IPsec policy have different match priorities. ACL rule conflicts between them are
prone to cause mistreatment of packets. For example, when configuring a permit statement for
an IPsec policy entry to protect an outbound traffic flow, you must avoid the situation that the
traffic flow matches a deny statement in a higher priority IPsec policy entry. Otherwise, the
packets will be sent out as normal packets. If they match a permit statement at the receiving
end, they will be dropped by IPsec.
The following example shows how an improper statement causes unexpected packet dropping. Only
the ACL-related configuration is presented.
Assume Router A is connected to subnet 1.1.2.0/24 and Router B is connected to subnet 3.3.3.0/24,
and the IPsec policy configuration on Router A and Router B is as follows:
• IPsec configuration on Router A:
acl advanced 3000
rule 0 permit ip source 1.1.1.0 0.0.0.255 destination 2.2.2.0 0.0.0.255
rule 1 deny ip
acl advanced 3001

406
 rule 0 permit ip source 1.1.2.0 0.0.0.255 destination 3.3.3.0 0.0.0.255
rule 1 deny ip
#
ipsec policy testa 1 isakmp <---IPsec policy entry with a higher priority
security acl 3000
ike-profile aa
transform-set 1
#
ipsec policy testa 2 isakmp <---IPsec policy entry with a lower priority
security acl 3001
ike-profile bb
transform-set 1
• IPsec configuration on Router B:
acl advanced 3001
rule 0 permit ip source 3.3.3.0 0.0.0.255 destination 1.1.2.0 0.0.0.255
rule 1 deny ip
#
ipsec policy testb 1 isakmp
security acl 3001
ike-profile aa
transform-set 1

On Router A, apply the IPsec policy testa to the outbound interface of Router A. The IPsec policy
contains two policy entries, testa 1 and testa 2. The ACLs used by the two policy entries each
contain a rule that matches traffic from 1.1.2.0/24 to 3.3.3.0/24. The one used in the policy entry
testa 1 is a deny statement and the one used in the policy entry testa 2 is a permit statement.
Because testa 1 is matched prior to testa 2, traffic from 1.1.2.0/24 to 3.3.3.0/24 will match the deny
statement and be sent as normal traffic. When the traffic arrives at Router B, the traffic matches rule
0 (a permit statement) in ACL 3001 used in the applied IPsec policy testb. Because non-IPsec traffic
that matches a permit statement must be dropped on the inbound interface, Router B drops the
traffic.
To make sure subnet 1.1.2.0/24 can access subnet 3.3.3.0/24, you can delete the deny rule in ACL
3000 on Router A.
Mirror image ACLs
To make sure SAs can be set up and the traffic protected by IPsec can be processed correctly
between two IPsec peers, create mirror image ACLs on the IPsec peers. As shown in Figure 103,
ACL rules on Router B are mirror images of the rules on Router A. In this way, SAs can be created
successfully for the traffic between Host A and Host C and for the traffic between Network 1 and
Network 2.

407
 Figure 103 Mirror image ACLs

ACL1: rule permit 1.1.1.1 -> 2.2.2.2

Host A ACL2: rule permit 1.1.1.0/24 -> 2.2.2.0/24 Host C
1.1.1.1 2.2.2.2

Network 1 IP network Network 2

1.1.1.0/24 2.2.2.0/24
Router A Router B
ACL1: rule permit 2.2.2.2 -> 1.1.1.1
ACL2: rule permit 2.2.2.0/24 -> 1.1.1.0/24

Host B Host D

If the ACL rules on IPsec peers do not form mirror images of each other, SAs can be set up only
when both of the following requirements are met:
• The range specified by an ACL rule on one peer is covered by its counterpart ACL rule on the
other peer. As shown in Figure 104, the range specified by the ACL rule configured on Router A
is covered by its counterpart on Router B.
• The peer with the narrower rule initiates SA negotiation. If a wider ACL rule is used by the SA
initiator, the negotiation request might be rejected because the matching traffic is beyond the
scope of the responder. As shown in Figure 104, the SA negotiation initiated by Host A to Host C
is accepted but the SA negotiations from Host C to Host A, from Host C to Host B, and from
Host D to Host A are rejected.
Figure 104 Non-mirror image ACLs

ACL3: rule permit 1.1.1.1 -> 2.2.2.2

Host A Host C
1.1.1.1 2.2.2.2

Network 1 IP network Network 2

1.1.1.0/24 2.2.2.0/24
Router A Router B
ACL3: rule permit 2.2.2.0/24 ->1.1.1.0/24

Host B Host D

Configuring an IPsec transform set

About this task
An IPsec transform set, part of an IPsec policy, defines the security parameters for IPsec SA
negotiation, including the security protocol, encryption algorithms, and authentication algorithms.
Restrictions and guidelines
Changes to an IPsec transform set affect only SAs negotiated after the changes. To apply the
changes to existing SAs, execute the reset ipsec sa command to clear the SAs so that they can be
set up by using the updated parameters.
In FIPS mode, you must specify both the ESP encryption algorithm and the ESP authentication
algorithm for an IPsec transform set that uses the ESP security protocol.

408
 When you set the packet encapsulation mode (tunnel or transport) for an IPsec transform set, follow
these guidelines:
• The transport mode applies only when the source and destination IP addresses of data flows
match those of the IPsec tunnel.
• IPsec for IPv6 routing protocols supports only the transport mode.
When you configure the Perfect Forward Secrecy (PFS) feature in an IPsec transform set, follow
these guidelines:
• In IKEv1, the security level of the DH group of the initiator must be higher than or equal to that of
the responder. This restriction does not apply to IKEv2.
• The end without the PFS feature performs SA negotiation according to the PFS requirements of
the peer end.
You can specify multiple authentication or encryption algorithms for the same security protocol. The
algorithm specified earlier has a higher priority.
Some algorithms are available only for IKEv2. See Table 31.
Table 31 Algorithms available only for IKEv2

Type Algorithms
aes-ctr-128
aes-ctr-192
aes-ctr-256
camellia-cbc-128
camellia-cbc-192
camellia-cbc-256
Encryption algorithm
gmac-128
gmac-192
gmac-256
gcm-128
gcm-192
gcm-256
Authentication algorithm aes-xcbc-mac
dh-group19
PFS algorithm
dh-group20

Procedure
1. Enter system view.
system-view
2. Create an IPsec transform set and enter its view.
ipsec transform-set transform-set-name
3. Specify the security protocol for the IPsec transform set.
protocol { ah | ah-esp | esp }
By default, the ESP security protocol is used.
4. Specify the encryption algorithms for ESP. Skip this step if the protocol ah command is
configured.
In non-FIPS mode:
esp encryption-algorithm { 3des-cbc | aes-cbc-128 | aes-cbc-192 |
aes-cbc-256 | aes-ctr-128 | aes-ctr-192 | aes-ctr-256 |

409
 camellia-cbc-128 | camellia-cbc-192 | camellia-cbc-256 | des-cbc |
gmac-128 | gmac-192 | gmac-256 | gcm-128 | gcm-192 | gcm-256 | null } *
By default, no encryption algorithm is specified for ESP.
In FIPS mode:
esp encryption-algorithm { aes-cbc-128 | aes-cbc-192 | aes-cbc-256 |
aes-ctr-128 | aes-ctr-192 | aes-ctr-256 | gmac-128 | gmac-192 | gmac-256
| gcm-128 | gcm-192 | gcm-256 } *
By default, no encryption algorithm is specified for ESP.
5. Specify the authentication algorithms for ESP. Skip this step if the protocol ah command is
configured.
In non-FIPS mode:
esp authentication-algorithm { aes-xcbc-mac | md5 | sha1 | sha256 |
sha384 | sha512 } *
By default, no authentication algorithm is specified for ESP.
The aes-xcbc-mac algorithm is available only for IKEv2.
In FIPS mode:
esp authentication-algorithm { sha1 | sha256 | sha384 | sha512 } *
By default, no authentication algorithm is specified for ESP.
6. Specify the authentication algorithms for AH. Skip this step if the protocol esp command is
configured.
In non-FIPS mode:
ah authentication-algorithm { aes-xcbc-mac | md5 | sha1 | sha256 |
sha384 | sha512 } *
By default, no authentication algorithm is specified for AH.
The aes-xcbc-mac algorithm is available only for IKEv2.
In FIPS mode:
ah authentication-algorithm { sha1 | sha256 | sha384 | sha512 } *
By default, no authentication algorithm is specified for AH.
7. Specify the packet encapsulation mode.
encapsulation-mode { transport | tunnel }
By default, the security protocol encapsulates IP packets in tunnel mode.
8. (Optional.) Enable the PFS feature.
In non-FIPS mode:
pfs { dh-group1 | dh-group2 | dh-group5 | dh-group14 | dh-group24 |
dh-group19 | dh-group20 }
In FIPS mode:
pfs { dh-group14 | dh-group19 | dh-group20 }
By default, the PFS feature is disabled.
For more information about PFS, see "Configuring IKE."
9. (Optional.) Enable the Extended Sequence Number (ESN) feature.
esn enable [ both ]
By default, the ESN feature is disabled.

410
Configuring a manual IPsec policy
In a manual IPsec policy, the parameters are configured manually, such as the keys, the SPIs, and
the IP addresses of the two ends in tunnel mode.
Restrictions and guidelines
When you configure a manual IPsec policy, make sure the IPsec configuration at both ends of the
IPsec tunnel meets the following requirements:
• The IPsec policies at the two ends must have IPsec transform sets that use the same security
protocols, security algorithms, and encapsulation mode.
• The remote IPv4 address configured on the local end must be the same as the primary IPv4
address of the interface applied with the IPsec policy at the remote end. The remote IPv6
address configured on the local end must be the same as the first IPv6 address of the interface
applied with the IPsec policy at the remote end.
• At each end, configure parameters for both the inbound SA and the outbound SA, and make
sure the SAs in each direction are unique: For an outbound SA, make sure its triplet (remote IP
address, security protocol, and SPI) is unique. For an inbound SA, make sure its SPI is unique.
• The local inbound SA must use the same SPI and keys as the remote outbound SA. The same
is true of the local outbound SA and remote inbound SA.
• The keys for the IPsec SAs at the two tunnel ends must be configured in the same format. For
example, if the local end uses a key in hexadecimal format, the remote end must also use a key
in hexadecimal format. If you configure a key in both the character and the hexadecimal formats,
only the most recent configuration takes effect.
• If you configure a key in character format for ESP, the device automatically generates an
authentication key and an encryption key for ESP.
Procedure
1. Enter system view.
system-view
2. Create a manual IPsec policy entry and enter its view.
ipsec { ipv6-policy | policy } policy-name seq-number manual
3. (Optional.) Configure a description for the IPsec policy.
description text
By default, no description is configured.
4. Specify an ACL for the IPsec policy.
security acl [ ipv6 ] { acl-number | name acl-name }
By default, no ACL is specified for an IPsec policy.
You can specify only one ACL for an IPsec policy.
5. Specify an IPsec transform set for the IPsec policy.
transform-set transform-set-name
By default, no IPsec transform set is specified for an IPsec policy.
You can specify only one IPsec transform set for a manual IPsec policy.
6. Specify the remote IP address of the IPsec tunnel.
remote-address { ipv4-address | ipv6 ipv6-address }
By default, the remote IP address of the IPsec tunnel is not specified.
7. Configure an SPI for the inbound IPsec SA.
sa spi inbound { ah | esp } spi-number
By default, no SPI is configured for the inbound IPsec SA.

411
 8. Configure an SPI for the outbound IPsec SA.
sa spi outbound { ah | esp } spi-number
By default, no SPI is configured for the outbound IPsec SA.
9. Configure keys for the IPsec SA.
 Configure an authentication key in hexadecimal format for AH.
sa hex-key authentication { inbound | outbound } ah { cipher | simple }
string
 Configure an authentication key in character format for AH.
sa string-key { inbound | outbound } ah { cipher | simple } string
 Configure a key in character format for ESP.
sa string-key { inbound | outbound } esp { cipher | simple } string
 Configure an authentication key in hexadecimal format for ESP.
sa hex-key authentication { inbound | outbound } esp { cipher |
simple }
 Configure an encryption key in hexadecimal format for ESP.
sa hex-key encryption { inbound | outbound } esp { cipher | simple }
string
By default, no keys are configured for the IPsec SA.
Configure keys correctly for the security protocol (AH, ESP, or both) you have specified in the
IPsec transform set used by the IPsec policy.

Configuring an IKE-based IPsec policy

About this task
In an IKE-based IPsec policy, the parameters are automatically negotiated through IKE.
To configure an IKE-based IPsec policy, use one of the following methods:
• Directly configure it by configuring the parameters in IPsec policy view.
• Configure it by using an existing IPsec policy template with the parameters to be negotiated
configured.
A device using an IPsec policy that is configured in this way cannot initiate an SA negotiation,
but it can respond to a negotiation request. The parameters not defined in the template are
determined by the initiator. For example, in an IPsec policy template, the ACL is optional. If you
do not specify an ACL, the IPsec protection range has no limit. So the device accepts all ACL
settings of the negotiation initiator.
When the remote end's information (such as the IP address) is unknown, this method allows the
remote end to initiate negotiations with the local end.
The configurable parameters for an IPsec policy template are the same as those when you directly
configure an IKE-based IPsec policy. The difference is that more parameters are optional for an
IPsec policy template. Except the IPsec transform sets and the IKE profile, all other parameters are
optional.
Restrictions and guidelines for IKE-based IPsec policy configuration
The IPsec policies at the two tunnel ends must have IPsec transform sets that use the same security
protocols, security algorithms, and encapsulation mode.
The IPsec policies at the two tunnel ends must have the same IKE profile parameters.
An IKE-based IPsec policy can use a maximum of six IPsec transform sets. During an IKE
negotiation, IKE searches for a fully matched IPsec transform set at the two ends of the IPsec tunnel.
If no match is found, no SA can be set up, and the packets expecting to be protected will be dropped.

412
 The remote IP address of the IPsec tunnel is required on an IKE negotiation initiator and is optional
on the responder. The remote IP address specified on the local end must be the same as the local IP
address specified on the remote end.
The IPsec SA uses the local lifetime settings or those proposed by the peer, whichever are smaller.
The IPsec SA can have both a time-based lifetime and a traffic-based lifetime. The IPsec SA expires
when either lifetime expires.
If you specify both an IKEv1 profile and an IKEv2 profile for an IPsec policy, the IKEv2 profile is used
preferentially. For more information about IKEv1 and IKEv2 profiles, see "Configuring IKE" and
"Configuring IKEv2."
Directly configuring an IKE-based IPsec policy
1. Enter system view.
system-view
2. Create an IKE-based IPsec policy entry and enter its view.
ipsec { ipv6-policy | policy } policy-name seq-number isakmp
3. (Optional.) Configure a description for the IPsec policy.
description text
By default, no description is configured.
4. Specify an ACL for the IPsec policy.
security acl [ ipv6 ] { acl-number | name acl-name } [ aggregation |
per-host ]
By default, no ACL is specified for an IPsec policy.
You can specify only one ACL for an IPsec policy.
5. Specify IPsec transform sets for the IPsec policy.
transform-set transform-set-name&<1-6>
By default, no IPsec transform sets are specified for an IPsec policy.
6. Specify an IKE profile or IKEv2 profile for the IPsec policy.
 Specify an IKE profile.
ike-profile profile-name
By default, no IKE profile is specified for an IPsec policy.
 Specify an IKEv2 profile.
ikev2-profile profile-name
By default, no IKEv2 profile is specified for an IPsec policy.
7. Specify the local IP address of the IPsec tunnel.
local-address { ipv4-address | ipv6 ipv6-address }
By default, the local IPv4 address of the IPsec tunnel is the primary IPv4 address of the
interface to which the IPsec policy is applied. The local IPv6 address of the IPsec tunnel is the
first IPv6 address of the interface to which the IPsec policy is applied.
The local IP address specified by this command must be the same as the IP address used as
the local IKE identity.
In a VRRP network, the local IP address must be the virtual IP address of the VRRP group to
which the IPsec-applied interface belongs.
8. Specify the remote IP address of the IPsec tunnel.
remote-address { [ ipv6 ] host-name | ipv4-address | ipv6 ipv6-address }
By default, the remote IP address of the IPsec tunnel is not specified.
9. (Optional.) Set the lifetime or idle timeout for the IPsec SA.

413
  Set the IPsec SA lifetime.
sa duration { time-based seconds | traffic-based kilobytes }
By default, the global SA lifetime is used.
 Set the IPsec SA idle timeout.
sa idle-time seconds
By default, the global IPsec SA idle timeout is used.
10. (Optional.) Enable the Traffic Flow Confidentiality (TFC) padding feature.
tfc enable
By default, the TFC padding feature is disabled.
This command is applicable only to IPsec SAs negotiated by IKEv2.
Configuring an IKE-based IPsec policy by using an IPsec policy template
1. Enter system view.
system-view
2. Create an IPsec policy template and enter its view.
ipsec { ipv6-policy-template | policy-template } template-name
seq-number
3. (Optional.) Configure a description for the IPsec policy template.
description text
By default, no description is configured.
4. (Optional.) Specify an ACL for the IPsec policy template.
security acl [ ipv6 ] { acl-number | name acl-name } [ aggregation |
per-host ]
By default, no ACL is specified for an IPsec policy template.
You can specify only one ACL for an IPsec policy template.
5. Specify IPsec transform sets for the IPsec policy template.
transform-set transform-set-name&<1-6>
By default, no IPsec transform sets are specified for an IPsec policy template.
6. Specify an IKE profile or IKEv2 profile for the IPsec policy template.
 Specify an IKE profile.
ike-profile profile-name
By default, no IKE profile is specified for an IPsec policy template.
Make sure the specified IKE profile is not used by another IPsec policy or IPsec policy
template.
 Specify an IKEv2 profile.
ikev2-profile profile-name
By default, no IKEv2 profile is specified for an IPsec policy template.
7. Specify the local IP address of the IPsec tunnel.
local-address { ipv4-address | ipv6 ipv6-address }
The default local IPv4 address and IPv6 address is the primary IPv4 address and first IPv6
address of the interface where the IPsec policy is applied.
The local IP address specified by this command must be the same as the IP address used as
the local IKE identity.
In a VRRP network, the local IP address must be the virtual IP address of the VRRP group to
which the IPsec-applied interface belongs.
8. Specify the remote IP address of the IPsec tunnel.

414
 remote-address { [ ipv6 ] host-name | ipv4-address | ipv6 ipv6-address }
By default, the remote IP address of the IPsec tunnel is not specified.
9. (Optional.) Set the lifetime and idle timeout for the IPsec SA.
 Set the IPsec SA lifetime.
sa duration { time-based seconds | traffic-based kilobytes }
By default, the global SA lifetime is used.
 Set the IPsec SA idle timeout.
sa idle-time seconds
By default, the global IPsec SA idle timeout is used.
10. (Optional.) Enable the Traffic Flow Confidentiality (TFC) padding feature.
tfc enable
By default, the TFC padding feature is disabled.
This command is applicable only to IPsec SAs negotiated by IKEv2.
11. Return to system view.
quit
12. Create an IPsec policy by using the IPsec policy template.
ipsec { ipv6-policy | policy } policy-name seq-number isakmp template
template-name

Applying an IPsec policy to an interface

Restrictions and guidelines
You can apply an IPsec policy to interfaces to protect data flows.
• An IKE-based IPsec policy can be applied to multiple interfaces. As a best practice, apply an
IKE-based IPsec policy to only one interface.
• A manual IPsec policy can be applied to only one interface.
To cancel the IPsec protection, remove the application of the IPsec policy.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Apply an IPsec policy to the interface.
ipsec apply { ipv6-policy | policy } policy-name
By default, no IPsec policy is applied to an interface.
On one interface, you can apply only one IPv4 IPsec policy and one IPv6 IPsec policy.
4. Specify a traffic processing slot for the interface.
service slot slot-number
By default, no traffic processing slot is specified for an interface. Traffic on an interface is
processed on the slot at which the traffic arrives.
This step is required when the following conditions are met:
 An IKE-based IPsec policy is applied to a global logical interface, such as VLAN interface.
 The IPsec anti-replay feature is globally enabled.

415
Enabling ACL checking for de-encapsulated packets
About this task
This feature compares the de-encapsulated incoming IPsec packets against the ACL in the IPsec
policy and discards those that do not match any permit rule of the ACL. This feature can protect
networks against attacks using forged IPsec packets.
This feature applies only to tunnel-mode IPsec.
Procedure
1. Enter system view.
system-view
2. Enable ACL checking for de-encapsulated packets.
ipsec decrypt-check enable
By default, ACL checking for de-encapsulated packets is enabled.

Configuring IPsec anti-replay

About this task
IPsec anti-replay protects networks against anti-replay attacks by using a sliding window mechanism
called anti-replay window. This feature checks the sequence number of each received IPsec packet
against the current IPsec packet sequence number range of the sliding window. If the sequence
number is not in the current sequence number range, the packet is considered a replayed packet
and is discarded.
IPsec packet de-encapsulation involves complicated calculation. De-encapsulation of replayed
packets is not required, and the de-encapsulation process consumes large amounts of resources
and degrades performance, resulting in DoS. IPsec anti-replay can check and discard replayed
packets before de-encapsulation.
In some situations, service data packets are received in a different order than their original order. The
IPsec anti-replay feature drops them as replayed packets, which impacts communications. If this
happens, disable IPsec anti-replay checking or adjust the size of the anti-replay window as required.
Restrictions and guidelines
IPsec anti-replay does not affect manually created IPsec SAs. According to the IPsec protocol, only
IKE-based IPsec SAs support anti-replay.
Set the anti-replay window size as small as possible to reduce the impact on system performance.
IPsec anti-replay requires that packets on the same interface be processed on the same slot. To
perform IPsec anti-replay on a multichassis IRF fabric for a global interface, use the service
command in interface view to specify a service processing slot for that interface. Global interfaces
(such as VLAN interfaces) are virtual interfaces that might have physical ports across the IRF
member devices. For more information about the service command, see VLAN commands in
Layer 2—LAN Switching Command Reference.
Failure to detect anti-replay attacks might result in denial of services. If you want to disable IPsec
anti-replay, make sure you understand the impact of the operation on network security.
Procedure
1. Enter system view.
system-view
2. Enable IPsec anti-replay.
ipsec anti-replay check

416
 By default, IPsec anti-replay is enabled.
3. Set the size of the IPsec anti-replay window.
ipsec anti-replay window width
The default size is 64.

Configuring IPsec anti-replay redundancy

About this task
This feature synchronizes the following information from the active device to the standby device at
configurable packet-based intervals:
• Lower bound values of the IPsec anti-replay window for inbound packets.
• IPsec anti-replay sequence numbers for outbound packets.
This feature, used together with IPsec redundancy, ensures uninterrupted IPsec traffic forwarding
and anti-replay protection when the active device fails.
Procedure
1. Enter system view.
system-view
2. Enable IPsec redundancy.
ipsec redundancy enable
By default, IPsec redundancy is disabled.
3. Enter IPsec policy view or IPsec policy template view.
 Enter IPsec policy view.
ipsec { ipv6-policy | policy } policy-name seq-number [ isakmp |
manual ]
 Enter IPsec policy template view.
ipsec { ipv6-policy-template | policy-template } template-name
seq-number
4. Set the anti-replay window synchronization interval for inbound packets and the sequence
number synchronization interval for outbound packets.
redundancy replay-interval inbound inbound-interval outbound
outbound-interval
By default, the active device synchronizes the anti-replay window every time it receives 1000
packets and synchronizes the sequence number every time it sends 100000 packets.

Binding a source interface to an IPsec policy

About this task
For high availability, a core device is usually connected to an ISP through two links, which operate in
backup or load sharing mode. The two interfaces negotiate with their peers to establish IPsec SAs
respectively. When one interface fails and a link failover occurs, the other interface needs to take
some time to renegotiate SAs, resulting in service interruption.
To solve these problems, bind a source interface to an IPsec policy and apply the policy to both
interfaces. This enables the two physical interfaces to use the same source interface to negotiate
IPsec SAs. As long as the source interface is up, the negotiated IPsec SAs will not be removed and
will keep working, regardless of link failover.

417
Restrictions and guidelines
Only the IKE-based IPsec policies can be bound to a source interface.
An IPsec policy can be bound to only one source interface.
A source interface can be bound to multiple IPsec policies.
If the source interface bound to an IPsec policy is removed, the IPsec policy becomes a common
IPsec policy.
If no local address is specified for an IPsec policy that has been bound to a source interface, the
IPsec policy uses the IP address of the bound source interface to perform IKE negotiation. If a local
address is specified, the IPsec policy uses the local address to perform IKE negotiation.
Procedure
1. Enter system view.
system-view
2. Bind a source interface to an IPsec policy.
ipsec { ipv6-policy | policy } policy-name local-address
interface-type interface-number
By default, no source interface is bound to an IPsec policy.

Enabling QoS pre-classify

About this task
When both an IPsec policy and a QoS policy are applied to an interface, QoS classifies packets by
using the new headers added by IPsec. If you want QoS to classify packets by using the headers of
the original IP packets, enable the QoS pre-classify feature.
Restrictions and guidelines
If you configure both IPsec and QoS on an interface, make sure the IPsec traffic classification rules
match the QoS traffic classification rules. If the rules do not match, QoS might classify the packets of
one IPsec SA to different queues, causing packets to be sent out of order. When IPsec anti-replay is
enabled, IPsec will drop the incoming packets that are out of the anti-replay window, resulting in
packet loss.
IPsec traffic classification rules are determined by the rules of the specified ACL. For more
information about QoS policy and classification, see ACL and QoS Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enter IPsec policy view or IPsec policy template view.
 Enter IPsec policy view.
ipsec { ipv6-policy | policy } policy-name seq-number [ isakmp |
manual ]
 Enter IPsec policy template view.
ipsec { ipv6-policy-template | policy-template } template-name
seq-number
3. Enable QoS pre-classify.
qos pre-classify
By default, QoS pre-classify is disabled.

418
Configuring the DF bit of IPsec packets
About this task
Perform this task to configure the Don't Fragment (DF) bit in the new IP header of IPsec packets in
one of the following ways:
• clear—Clears the DF bit in the new header.
• set—Sets the DF bit in the new header.
• copy—Copies the DF bit in the original IP header to the new IP header.
You can configure the DF bit in system view and interface view. The interface-view DF bit setting
takes precedence over the system-view DF bit setting. If the interface-view DF bit setting is not
configured, the interface uses the system-view DF bit setting.
Restrictions and guidelines for DF bit configuration for IPsec packets
The DF bit setting takes effect only in tunnel mode, and it changes the DF bit in the new IP header
rather than the original IP header.
Configure the same DF bit setting on the interfaces where the same IPsec policy bound to a source
interface is applied.
If the DF bit is set, the devices on the path cannot fragment the IPsec packets. To prevent IPsec
packets from being discarded, make sure the path MTU is larger than the IPsec packet size. As a
best practice, clear the DF bit if you cannot make sure the path MTU is larger than the IPsec packet
size.
Configuring the DF bit of IPsec packets on an interface
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Configure the DF bit of IPsec packets on the interface.
ipsec df-bit { clear | copy | set }
By default, the interface uses the global DF bit setting.
Configuring the DF bit of IPsec packets globally
1. Enter system view.
system-view
2. Configure the DF bit of IPsec packets globally.
ipsec global-df-bit { clear | copy | set }
By default, IPsec copies the DF bit in the original IP header to the new IP header.

Configuring IPsec RRI

Restrictions and guidelines
Enabling IPsec RRI for an IPsec policy deletes all existing IPsec SAs created by this IPsec policy.
IPsec RRI creates static routes according to new IPsec SAs.
Disabling IPsec RRI for an IPsec policy deletes all existing IPsec SAs created by this IPsec policy
and the associated static routes.
IPsec RRI is supported in both tunnel mode and transport mode.

419
 If you change the preference value or tag value for an IPsec policy, the device deletes all IPsec SAs
created by this IPsec policy, and the associated static routes. The change takes effect for future
IPsec RRI-created static routes.
IPsec RRI does not generate a static route to a destination address to be protected if the destination
address is not defined in the ACL used by an IPsec policy or an IPsec policy template. You must
manually configure a static route to the destination address.
Procedure
1. Enter system view.
system-view
2. Enter IPsec policy view or IPsec policy template view.
 Enter IPsec policy view.
ipsec { policy | ipv6-policy } policy-name seq-number isakmp
 Enter IPsec policy template view.
ipsec { ipv6-policy-template | policy-template } template-name
seq-number
3. Enable IPsec RRI.
reverse-route dynamic
By default, IPsec RRI is disabled.
4. (Optional.) Set the preference value for the static routes created by IPsec RRI.
reverse-route preference number
The default value is 60.
5. (Optional.) Set the tag value for the static routes created by IPsec RRI.
reverse-route tag tag-value
The default value is 0.

Configuring IPsec for IPv6 routing protocols

IPsec protection for IPv6 routing protocols tasks at a glance
To configure IPsec protection for IPv6 routing protocols, perform the following tasks:
1. Configuring an IPsec transform set
2. Configuring a manual IPsec profile
3. Applying the IPsec profile to an IPv6 routing protocol
4. (Optional.) Configuring IPsec fragmentation
5. (Optional.) Setting the maximum number of IPsec tunnels
6. (Optional.) Enabling logging for IPsec packets
7. (Optional.) Configuring SNMP notifications for IPsec

Configuring a manual IPsec profile

About this task
A manual IPsec profile specifies the IPsec transform set used for protecting data flows, and the SPIs
and keys used by the SAs.

420
Restrictions and guidelines
When you configure a manual IPsec profile, make sure the IPsec profile configuration at both tunnel
ends meets the following requirements:
• The IPsec transform set specified in the IPsec profile at the two tunnel ends must have the
same security protocol, encryption and authentication algorithms, and packet encapsulation
mode.
• The local inbound and outbound IPsec SAs must have the same SPI and key.
• The IPsec SAs on the devices in the same scope must have the same key. The scope is defined
by protocols. For OSPFv3, the scope consists of OSPFv3 neighbors or an OSPFv3 area. For
RIPng, the scope consists of directly-connected neighbors or a RIPng process. For BGP, the
scope consists of BGP peers or a BGP peer group.
• The keys for the IPsec SAs at the two tunnel ends must be configured in the same format. For
example, if the local end uses a key in hexadecimal format, the remote end must also use a key
in hexadecimal format. If you configure a key in both the character and the hexadecimal formats,
only the most recent configuration takes effect.
• If you configure a key in character format for ESP, the device automatically generates an
authentication key and an encryption key for ESP.
Procedure
1. Enter system view.
system-view
2. Create a manual IPsec profile and enter its view.
ipsec profile profile-name manual
The manual keyword is not needed if you enter the view of an existing IPsec profile.
3. (Optional.) Configure a description for the IPsec profile.
description text
By default, no description is configured.
4. Specify an IPsec transform set.
transform-set transform-set-name
By default, no IPsec transform set is specified in an IPsec profile.
The specified IPsec transform set must use the transport mode.
5. Configure an SPI for an SA.
sa spi { inbound | outbound } { ah | esp } spi-number
By default, no SPI is configured for an SA.
6. Configure keys for the IPsec SA.
 Configure an authentication key in hexadecimal format for AH.
sa hex-key authentication { inbound | outbound } ah { cipher | simple }
string
 Configure an authentication key in character format for AH.
sa string-key { inbound | outbound } ah { cipher | simple } string
 Configure a key in character format for ESP.
sa string-key { inbound | outbound } esp { cipher | simple } string
 Configure an authentication key in hexadecimal format for ESP.
sa hex-key authentication { inbound | outbound } esp { cipher |
simple }
 Configure an encryption key in hexadecimal format for ESP.

421
 sa hex-key encryption { inbound | outbound } esp { cipher | simple }
string
By default, no keys are configured for the IPsec SA.
Configure a key for the security protocol (AH, ESP, or both) you have specified.

Applying the IPsec profile to an IPv6 routing protocol

For information about the configuration procedure, see IPv6 BGP, OSPFv3, and RIPng configuration
in Layer 3—IP Routing Configuration Guide.

Configuring the global IPsec SA lifetime and idle

timeout
About this task
If the IPsec SA lifetime and idle timeout are not configured in an IPsec policy, IPsec policy template,
or IPsec profile, the global settings are used.
When IKE negotiates IPsec SAs, it uses the local lifetime settings or those proposed by the peer,
whichever are smaller.
An IPsec SA can have both a time-based lifetime and a traffic-based lifetime. The IPsec SA expires
when either lifetime expires.
Procedure
1. Enter system view.
system-view
2. Set the global IPsec SA lifetime or idle timeout.
 Set the global IPsec SA lifetime.
ipsec sa global-duration { time-based seconds | traffic-based
kilobytes }
By default, the time-based SA lifetime is 3600 seconds, and the traffic-based SA lifetime is
1843200 kilobytes.
 Set the global SA idle timeout.
ipsec sa idle-time seconds
By default, the global IPsec SA idle timeout feature is disabled.

Configuring IPsec fragmentation

About this task
Perform this task to configure the device to fragment packets before or after IPsec encapsulation.
If you configure the device to fragment packets before IPsec encapsulation, the device
predetermines the encapsulated packet size before the actual encapsulation. If the encapsulated
packet size exceeds the MTU of the output interface, the device fragments the packets before
encapsulation. If a packet's DF bit is set, the device drops the packet and sends an ICMP error
message.
If you configure the device to fragment packets after IPsec encapsulation, the device directly
encapsulates the packets and fragments the encapsulated packets in subsequent service modules.

422
Restrictions and guidelines
This feature takes effect on IPsec protected IPv4 packets.
Procedure
1. Enter system view.
system-view
2. Configure IPsec fragmentation.
ipsec fragmentation { after-encryption | before-encryption }
By default, the device fragments packets before IPsec encapsulation.

Setting the maximum number of IPsec tunnels

Restrictions and guidelines
To maximize concurrent performance of IPsec when memory is sufficient, increase the maximum
number of IPsec tunnels. To ensure service availability when memory is insufficient, decrease the
maximum number of IPsec tunnels.
Procedure
1. Enter system view.
system-view
2. Set the maximum number of IPsec tunnels.
ipsec limit max-tunnel tunnel-limit
The number of IPsec tunnels is not limited.

Enabling logging for IPsec packets

About this task
Perform this task to enable logging for IPsec packets that are discarded for reasons such as IPsec
SA lookup failure, AH-ESP authentication failure, and ESP encryption failure. The log information
includes the source and destination IP addresses, SPI value, and sequence number of a discarded
IPsec packet, and the reason for the discard.
Procedure
1. Enter system view.
system-view
2. Enable logging for IPsec packets.
ipsec logging packet enable
By default, logging for IPsec packets is disabled.

Configuring SNMP notifications for IPsec

About this task
After you enable SNMP notifications for IPsec, the IPsec module notifies the NMS of important
module events. The notifications are sent to the device's SNMP module. For the notifications to be
sent correctly, you must also configure SNMP on the device. For more information about SNMP
notifications, see Network Management and Monitoring Configuration Guide.

423
 To generate and output SNMP notifications for a specific IPsec failure or event type, perform the
following tasks:
1. Enable SNMP notifications for IPsec globally.
2. Enable SNMP notifications for the failure or event type.
Procedure
1. Enter system view.
system-view
2. Enable SNMP notifications for IPsec globally.
snmp-agent trap enable ipsec global
By default, SNMP notifications for IPsec are disabled.
3. Enable SNMP notifications for the specified failure or event types.
snmp-agent trap enable ipsec [ auth-failure | decrypt-failure |
encrypt-failure | invalid-sa-failure | no-sa-failure | policy-add |
policy-attach | policy-delete | policy-detach | tunnel-start |
tunnel-stop ] *
By default, SNMP notifications for all failure and event types are disabled.

Display and maintenance commands for IPsec

Execute display commands in any view and reset commands in user view.

Task Command
display ipsec { ipv6-policy | policy }
Display IPsec policy information.
[ policy-name [ seq-number ] ]
display ipsec { ipv6-policy-template |
Display IPsec policy template information. policy-template } [ template-name
[ seq-number ] ]
Display IPsec profile information. display ipsec profile [ profile-name ]
display ipsec sa [ brief | count |
interface interface-type
interface-number | { ipv6-policy |
Display IPsec SA information.
policy } policy-name [ seq-number ] |
profile profile-name | remote [ ipv6 ]
ip-address ]
display ipsec statistics [ tunnel-id
Display IPsec statistics.
tunnel-id ]
display ipsec transform-set
Display IPsec transform set information.
[ transform-set-name ]
display ipsec tunnel { brief | count |
Display IPsec tunnel information.
tunnel-id tunnel-id }
reset ipsec sa [ { ipv6-policy | policy }
policy-name [ seq-number ] | profile
policy-name | remote { ipv4-address |
Clear IPsec SAs.
ipv6 ipv6-address } | spi
{ ipv4-address | ipv6 ipv6-address }
{ ah | esp } spi-num ]

424
 Task Command
reset ipsec statistics [ tunnel-id
Clear IPsec statistics.
tunnel-id ]

IPsec configuration examples

Example: Configuring a manual mode IPsec tunnel for IPv4
packets
Network configuration
As shown in Figure 105, establish an IPsec tunnel between Switch A and Switch B to protect data
flows between the switches. Configure the tunnel as follows:
• Specify the encapsulation mode as tunnel, the security protocol as ESP, the encryption
algorithm as AES-CBC-192, and the authentication algorithm as HMAC-SHA1.
• Manually set up IPsec SAs.
Figure 105 Network diagram
Vlan-int1 Vlan-int1
2.2.2.1/24 2.2.3.1/24
Internet

Switch A Switch B

Procedure
1. Configure Switch A:
# Configure an IP address for VLAN-interface 1.
<SwitchA> system-view
[SwitchA] interface vlan-interface 1
[SwitchA-Vlan-interface1] ip address 2.2.2.1 255.255.255.0
[SwitchA-Vlan-interface1] quit
# Configure an IPv4 advanced ACL to identify the data flows between Switch A and Switch B.
[SwitchA] acl advanced 3101
[SwitchA-acl-ipv4-adv-3101] rule 0 permit ip source 2.2.2.1 0 destination 2.2.3.1 0
[SwitchA-acl-ipv4-adv-3101] quit
# Create an IPsec transform set named tran1.
[SwitchA] ipsec transform-set tran1
# Specify the encapsulation mode as tunnel.
[SwitchA-ipsec-transform-set-tran1] encapsulation-mode tunnel
# Specify the security protocol as ESP.
[RouterA-ipsec-transform-set-tran1] protocol esp
# Specify the ESP encryption and authentication algorithms.
[SwitchA-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-192
[SwitchA-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[SwitchA-ipsec-transform-set-tran1] quit
# Create a manual IPsec policy entry. Specify the policy name as map1 and set the sequence
number to 10.

425
 [SwitchA] ipsec policy map1 10 manual
# Specify ACL 3101.
[SwitchA-ipsec-policy-manual-map1-10] security acl 3101
# Specify IPsec transform set tran1.
[SwitchA-ipsec-policy-manual-map1-10] transform-set tran1
# Specify the remote IP address of the IPsec tunnel as 2.2.3.1.
[SwitchA-ipsec-policy-manual-map1-10] remote-address 2.2.3.1
# Configure inbound and outbound SPIs for ESP.
[SwitchA-ipsec-policy-manual-map1-10] sa spi outbound esp 12345
[SwitchA-ipsec-policy-manual-map1-10] sa spi inbound esp 54321
# Configure the inbound and outbound SA keys for ESP.
[SwitchA-ipsec-policy-manual-map1-10] sa string-key outbound esp simple abcdefg
[SwitchA-ipsec-policy-manual-map1-10] sa string-key inbound esp simple gfedcba
[SwitchA-ipsec-policy-manual-map1-10] quit
# Apply IPsec policy map1 to VLAN-interface 1.
[SwitchA] interface vlan-interface 1
[SwitchA-Vlan-interface1] ipsec apply policy map1
2. Configure Switch B:
# Configure an IP address for VLAN-interface 1.
<SwitchB> system-view
[SwitchB] interface vlan-interface 1
[SwitchB-Vlan-interface1] ip address 2.2.3.1 255.255.255.0
[SwitchB-Vlan-interface1] quit
# Configure an IPv4 advanced ACL to identify the data flows between Switch B and Switch A.
[SwitchB] acl advanced 3101
[SwitchB-acl-ipv4-adv-3101] rule 0 permit ip source 2.2.3.1 0 destination 2.2.2.1 0
[SwitchB-acl-ipv4-adv-3101] quit
# Create an IPsec transform set named tran1.
[SwitchB] ipsec transform-set tran1
# Specify the encapsulation mode as tunnel.
[SwitchB-ipsec-transform-set-tran1] encapsulation-mode tunnel
# Specify the security protocol as ESP.
[SwitchB-ipsec-transform-set-tran1] protocol esp
# Specify the ESP encryption and authentication algorithms.
[SwitchB-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-192
[SwitchB-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[SwitchB-ipsec-transform-set-tran1] quit
# Create a manual IPsec policy entry. Specify the policy name as use1 and set the sequence
number to 10.
[SwitchB] ipsec policy use1 10 manual
# Specify ACL 3101.
[SwitchB-ipsec-policy-manual-use1-10] security acl 3101
# Specify IPsec transform set tran1.
[SwitchB-ipsec-policy-manual-use1-10] transform-set tran1
# Specify the remote IP address of the IPsec tunnel as 2.2.2.1.
[SwitchB-ipsec-policy-manual-use1-10] remote-address 2.2.2.1
# Configure the inbound and outbound SPIs for ESP.

426
 [SwitchB-ipsec-policy-manual-use1-10] sa spi outbound esp 54321
[SwitchB-ipsec-policy-manual-use1-10] sa spi inbound esp 12345
# Configure the inbound and outbound SA keys for ESP.
[SwitchB-ipsec-policy-manual-use1-10] sa string-key outbound esp simple gfedcba
[SwitchB-ipsec-policy-manual-use1-10] sa string-key inbound esp simple abcdefg
[SwitchB-ipsec-policy-manual-use1-10] quit
# Apply IPsec policy use1 to VLAN-interface 1.
[SwitchB] interface vlan-interface 1
[SwitchB-Vlan-interface1] ipsec apply policy use1

Verifying the configuration

After the configuration is completed, an IPsec tunnel between Switch A and Switch B is established,
and the traffic between the switches is IPsec-protected. This example uses Switch A to verify the
configuration.
# Use the display ipsec sa command to display IPsec SAs on Switch A.
[SwitchA] display ipsec sa
-------------------------------
Interface: Vlan-interface 1
-------------------------------

-----------------------------
IPsec policy: map1
Sequence number: 10
Mode: manual
-----------------------------
Tunnel id: 549
Encapsulation mode: tunnel
Path MTU: 1443
Tunnel:
local address: 2.2.2.1
remote address: 2.2.3.1
Flow:
as defined in ACL 3101
[Inbound ESP SA]
SPI: 54321 (0x0000d431)
Transform set: ESP-ENCRYPT-AES-CBC-192 ESP-AUTH-SHA1
No duration limit for this SA
[Outbound ESP SA]
SPI: 12345 (0x00003039)
Transform set: ESP-ENCRYPT-AES-CBC-192 ESP-AUTH-SHA1
No duration limit for this SA

Example: Configuring an IKE-based IPsec tunnel for IPv4

packets
Network configuration
As shown in Figure 106, establish an IPsec tunnel between Switch A and Switch B to protect data
flows between them. Configure the IPsec tunnel as follows:

427
 • Specify the encapsulation mode as tunnel, the security protocol as ESP, the encryption
algorithm as AES-CBC-192, and the authentication algorithm as HMAC-SHA1.
• Set up SAs through IKE negotiation.
Figure 106 Network diagram
Vlan-int1 Vlan-int1
2.2.2.1/24 2.2.3.1/24
Internet

Switch A Switch B

Procedure
1. Configure Switch A:
# Configure an IP address for VLAN-interface 1.
<SwitchA> system-view
[SwitchA] interface vlan-interface 1
[SwitchA-Vlan-interface1] ip address 2.2.2.1 255.255.255.0
[SwitchA-Vlan-interface1] quit
# Configure an IPv4 advanced ACL to identify data flows from Switch A to Switch B.
[SwitchA] acl number 3101
[SwitchA-acl-adv-3101] rule 0 permit ip source 2.2.2.1 0 destination 2.2.3.1 0
[SwitchA-acl-adv-3101] quit
# Create an IPsec transform set named tran1.
[SwitchA] ipsec transform-set tran1
# Specify the encapsulation mode as tunnel.
[SwitchA-ipsec-transform-set-tran1] encapsulation-mode tunnel
# Specify the security protocol as ESP.
[SwitchA-ipsec-transform-set-tran1] protocol esp
# Specify the ESP encryption and authentication algorithms.
[SwitchA-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-192
[SwitchA-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[SwitchA-ipsec-transform-set-tran1] quit
# Create an IKE keychain named keychain1.
[SwitchA] ike keychain keychain1
# Specify 12345zxcvb!@#$%ZXCVB in plain text as the preshared key to be used with the
remote peer at 2.2.3.1.
[SwitchA-ike-keychain-keychain1] pre-shared-key address 2.2.3.1 255.255.255.0 key
simple 12345zxcvb!@#$%ZXCVB
[SwitchA-ike-keychain-keychain1] quit
# Create and configure the IKE profile named profile1.
[SwitchA] ike profile profile1
[SwitchA-ike-profile-profile1] keychain keychain1
[SwitchA-ike-profile-profile1] match remote identity address 2.2.3.1 255.255.255.0
[SwitchA-ike-profile-profile1] quit
# Create an IKE-based IPsec policy entry. Specify the policy name as map1 and set the
sequence number to 10.
[SwitchA] ipsec policy map1 10 isakmp
# Apply ACL 3101.
[SwitchA-ipsec-policy-isakmp-map1-10] security acl 3101

428
 # Apply IPsec transform set tran1.
[SwitchA-ipsec-policy-isakmp-map1-10] transform-set tran1
# Specify the local and remote IP addresses of the IPsec tunnel as 2.2.2.1 and 2.2.3.1.
[SwitchA-ipsec-policy-isakmp-map1-10] local-address 2.2.2.1
[SwitchA-ipsec-policy-isakmp-map1-10] remote-address 2.2.3.1
# Apply IKE profile profile1.
[SwitchA-ipsec-policy-isakmp-map1-10] ike-profile profile1
[SwitchA-ipsec-policy-isakmp-map1-10] quit
# Apply IPsec policy map1 to VLAN interface 1.
[SwitchA] interface vlan-interface 1
[SwitchA-Vlan-interface1] ipsec apply policy map1
2. Configure Switch B:
# Configure an IP address for VLAN-interface 1.
<SwitchB> system-view
[SwitchB] interface vlan-interface 1
[SwitchB-Vlan-interface1] ip address 2.2.3.1 255.255.255.0
[SwitchB-Vlan-interface1] quit
# Configure an IPv4 advanced ACL to identify data flows from Switch B to Switch A.
[SwitchB] acl number 3101
[SwitchB-acl-adv-3101] rule 0 permit ip source 2.2.3.1 0 destination 2.2.2.1 0
[SwitchB-acl-adv-3101] quit
# Create an IPsec transform set named tran1.
[SwitchB] ipsec transform-set tran1
# Specify the encapsulation mode as tunnel.
[SwitchB-ipsec-transform-set-tran1] encapsulation-mode tunnel
# Specify the security protocol as ESP.
[SwitchB-ipsec-transform-set-tran1] protocol esp
# Specify the ESP encryption and authentication algorithms.
[SwitchB-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-192
[SwitchB-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[SwitchB-ipsec-transform-set-tran1] quit
# Create an IKE keychain named keychain1.
[SwitchB] ike keychain keychain1
# Specify 12345zxcvb!@#$%ZXCVB in plain text as the preshared key to be used with the
remote peer at 2.2.2.1.
[SwitchB-ike-keychain-keychain1] pre-shared-key address 2.2.2.1 255.255.255.0 key
simple 12345zxcvb!@#$%ZXCVB
[SwitchB-ike-keychain-keychain1] quit
# Create and configure the IKE profile named profile1.
[SwitchB] ike profile profile1
[SwitchB-ike-profile-profile1] keychain keychain1
[SwitchB-ike-profile-profile1] match remote identity address 2.2.2.1 255.255.255.0
[SwitchB-ike-profile-profile1] quit
# Create an IKE-based IPsec policy entry. Specify the policy name as use1 and set the
sequence number to 10.
[SwitchB] ipsec policy use1 10 isakmp
# Apply ACL 3101.

429
 [SwitchB-ipsec-policy-isakmp-use1-10] security acl 3101
# Apply IPsec transform set tran1.
[SwitchB-ipsec-policy-isakmp-use1-10] transform-set tran1
# Specify the local and remote IP addresses of the IPsec tunnel as 2.2.3.1 and 2.2.2.1.
[SwitchB-ipsec-policy-isakmp-use1-10] local-address 2.2.3.1
[SwitchB-ipsec-policy-isakmp-use1-10] remote-address 2.2.2.1
# Apply IKE profile profile1.
[SwitchB-ipsec-policy-isakmp-use1-10] ike-profile profile1
[SwitchB-ipsec-policy-isakmp-use1-10] quit
# Apply IPsec policy use1 to VLAN-interface 1.
[SwitchB] interface vlan-interface 1
[SwitchB-Vlan-interface1] ipsec apply policy use1

Verifying the configuration

# Initiate a connection between Switch A and Switch B to trigger IKE negotiation. After IPsec SAs are
successfully negotiated by IKE, the traffic between the two switches is IPsec-protected.

Example: Configuring IPsec for RIPng

Network configuration
As shown in Figure 107, Switch A, Switch B, and Switch C learn IPv6 routes through RIPng.
Establish an IPsec tunnel between the switches to protect the RIPng packets transmitted in between.
Specify the security protocol as ESP, the encryption algorithm as 128-bit AES, and the authentication
algorithm as HMAC-SHA1 for the IPsec tunnel.
Figure 107 Network diagram
Vlan-int100 Vlan-int200
1::1/64 3::2/64
Vlan-int100 Vlan-int200
1::2/64 3::1/64
Switch A Switch B Switch C

Requirements analysis
To meet the network configuration requirements, perform the following tasks:
1. Configure basic RIPng.
For more information about RIPng configurations, see Layer 3—IP Routing Configuration
Guide.
2. Configure an IPsec profile.
 The IPsec profiles on all the switches must have IPsec transform sets that use the same
security protocol, authentication and encryption algorithms, and encapsulation mode.
 The SPI and key configured for the inbound SA and those for the outbound SA must be the
same on each switch.
 The SPI and key configured for the SAs on all the switches must be the same.
3. Apply the IPsec profile to a RIPng process or to an interface.
Procedure
1. Configure Switch A:
# Configure IPv6 addresses for interfaces. (Details not shown.)
# Configure basic RIPng.
<SwitchA> system-view

430
 [SwitchA] ripng 1
[SwitchA-ripng-1] quit
[SwitchA] interface vlan-interface 100
[SwitchA-Vlan-interface100] ripng 1 enable
[SwitchA-Vlan-interface100] quit
# Create and configure the IPsec transform set named tran1.
[SwitchA] ipsec transform-set tran1
[SwitchA-ipsec-transform-set-tran1] encapsulation-mode transport
[SwitchA-ipsec-transform-set-tran1] protocol esp
[SwitchA-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-128
[SwitchA-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[SwitchA-ipsec-transform-set-tran1] quit
# Create and configure the IPsec profile named profile001.
[SwitchA] ipsec profile profile001 manual
[SwitchA-ipsec-profile-manual-profile001] transform-set tran1
[SwitchA-ipsec-profile-manual-profile001] sa spi outbound esp 123456
[SwitchA-ipsec-profile-manual-profile001] sa spi inbound esp 123456
[SwitchA-ipsec-profile-manual-profile001] sa string-key outbound esp simple abcdefg
[SwitchA-ipsec-profile-manual-profile001] sa string-key inbound esp simple abcdefg
[SwitchA-ipsec-profile-manual-profile001] quit
# Apply the IPsec profile to RIPng process 1.
[SwitchA] ripng 1
[SwitchA-ripng-1] enable ipsec-profile profile001
[SwitchA-ripng-1] quit
2. Configure Switch B:
# Configure IPv6 addresses for interfaces. (Details not shown.)
# Configure basic RIPng.
<SwitchB> system-view
[SwitchB] ripng 1
[SwitchB-ripng-1] quit
[SwitchB] interface vlan-interface 200
[SwitchB-Vlan-interface200] ripng 1 enable
[SwitchB-Vlan-interface200] quit
[SwitchB] interface vlan-interface 100
[SwitchB-Vlan-interface100] ripng 1 enable
[SwitchB-Vlan-interface100] quit
# Create and configure the IPsec transform set named tran1.
[SwitchB] ipsec transform-set tran1
[SwitchB-ipsec-transform-set-tran1] encapsulation-mode transport
[SwitchB-ipsec-transform-set-tran1] protocol esp
[SwitchB-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-128
[SwitchB-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[SwitchB-ipsec-transform-set-tran1] quit
# Create and configure the IPsec profile named profile001.
[SwitchB] ipsec profile profile001 manual
[SwitchB-ipsec-profile-manual-profile001] transform-set tran1
[SwitchB-ipsec-profile-manual-profile001] sa spi outbound esp 123456
[SwitchB-ipsec-profile-manual-profile001] sa spi inbound esp 123456

431
 [SwitchB-ipsec-profile-manual-profile001] sa string-key outbound esp simple abcdefg
[SwitchB-ipsec-profile-manual-profile001] sa string-key inbound esp simple abcdefg
[SwitchB-ipsec-profile-manual-profile001] quit
# Apply the IPsec profile to RIPng process 1.
[SwitchB] ripng 1
[SwitchB-ripng-1] enable ipsec-profile profile001
[SwitchB-ripng-1] quit
3. Configure Switch C:
# Configure IPv6 addresses for interfaces. (Details not shown.)
# Configure basic RIPng.
<SwitchC> system-view
[SwitchC] ripng 1
[SwitchC-ripng-1] quit
[SwitchC] interface vlan-interface 200
[SwitchC-Vlan-interface200] ripng 1 enable
[SwitchC-Vlan-interface200] quit
# Create and configure the IPsec transform set named tran1.
[SwitchC] ipsec transform-set tran1
[SwitchC-ipsec-transform-set-tran1] encapsulation-mode transport
[SwitchC-ipsec-transform-set-tran1] protocol esp
[SwitchC-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-128
[SwitchC-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[SwitchC-ipsec-transform-set-tran1] quit
# Create and configure the IPsec profile named profile001.
[SwitchC] ipsec profile profile001 manual
[SwitchC-ipsec-profile-manual-profile001] transform-set tran1
[SwitchC-ipsec-profile-manual-profile001] sa spi outbound esp 123456
[SwitchC-ipsec-profile-manual-profile001] sa spi inbound esp 123456
[SwitchC-ipsec-profile-manual-profile001] sa string-key outbound esp simple abcdefg
[SwitchC-ipsec-profile-manual-profile001] sa string-key inbound esp simple abcdefg
[SwitchC-ipsec-profile-manual-profile001] quit
# Apply the IPsec profile to RIPng process 1.
[SwitchC] ripng 1
[SwitchC-ripng-1] enable ipsec-profile profile001
[SwitchC-ripng-1] quit

Verifying the configuration

After the configuration is completed, Switch A, Switch B, and Switch C learn IPv6 routing information
through RIPng. IPsec SAs are set up successfully on the switches to protect RIPng packets. This
example uses Switch A to verify the configuration.
# Display the RIPng configuration. The output shows that IPsec profile profile001 has been applied
to RIPng process 1.
[SwitchA] display ripng 1
RIPng process : 1
Preference : 100
Checkzero : Enabled
Default Cost : 0
Maximum number of load balanced routes : 8

432
 Update time : 30 secs Timeout time : 180 secs
Suppress time : 120 secs Garbage-Collect time : 120 secs
Update output delay: 20(ms) Output count: 3
Graceful-restart interval: 60 secs
Triggered Interval : 5 50 200
Number of periodic updates sent : 186
Number of triggered updates sent : 1
IPsec profile name: profile001

# Display the established IPsec SAs.

[SwitchA] display ipsec sa
-------------------------------
Global IPsec SA
-------------------------------

-----------------------------
IPsec profile: profile001
Mode: Manual
-----------------------------
Encapsulation mode: transport
[Inbound ESP SA]
SPI: 123456 (0x3039)
Connection ID: 90194313219
Transform set: ESP-ENCRYPT-AES-CBC-128 ESP-AUTH-SHA1
No duration limit for this SA
[Outbound ESP SA]
SPI: 123456 (0x3039)
Connection ID: 64424509441
Transform set: ESP-ENCRYPT-AES-CBC-128ESP-AUTH-SHA1
No duration limit for this SA

Example: Configuring IPsec RRI

Network configuration
As shown in Figure 108, branches access the enterprise center through an IPsec VPN.
Configure the IPsec VPN as follows:
• Configure an IPsec tunnel between Switch A and each branch gateway (Switch B, Switch C,
and Switch D) to protect traffic between subnets 4.4.4.0/24 and 5.5.5.0/24.
• Configure the tunnels to use security protocol ESP, encryption algorithm DES, and
authentication algorithm SHA1-HMAC-96. Use IKE for IPsec SA negotiation.
• Configure IKE proposal to use the preshared key authentication method, encryption algorithm
3DES, and authentication algorithm HMAC-SHA1.
• Configure IPsec RRI on Switch A to automatically create static routes to the branches based on
the established IPsec SAs.

433
 Figure 108 Network diagram
Branch
Vlan-int200
5.5.5.1/24
Vlan-int100
2.2.2.2/24
Switch B
Host B
Enterprise Center
Branch
Vlan-int200 Vlan-int100
4.4.4.1/24 1.1.1.1/24
Internet
Switch C
Switch A
Host A
Branch

Switch D

Procedure
1. Assign IPv4 addresses to the interfaces on the switches according to Figure 108. (Details not
shown.)
2. Configure Switch A:
# Create an IPsec transform set named tran1, and specify ESP as the security protocol, DES
as the encryption algorithm, and HMAC-SHA-1-96 as the authentication algorithm.
<SwitchA> system-view
[SwitchA] ipsec transform-set tran1
[SwitchA-ipsec-transform-set-tran1] encapsulation-mode tunnel
[SwitchA-ipsec-transform-set-tran1] protocol esp
[SwitchA-ipsec-transform-set-tran1] esp encryption-algorithm des
[SwitchA-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[SwitchA-ipsec-transform-set-tran1] quit
# Create and configure the IKE profile named profile1.
[SwitchA] ike profile profile1
[SwitchA-ike-profile-profile1] keychain key1
[SwitchA-ike-profile-profile1] match remote identity address 2.2.2.2 255.255.255.0
[SwitchA-ike-profile-profile1] quit
# Create an IPsec policy template named temp1. Specify IPsec transform set tran1 and IKE
profile profile1 for the IPsec policy template.
[SwitchA] ipsec policy-template temp1 1
[SwitchA-ipsec-policy-template-temp1-1] transform-set tran1
[SwitchA-ipsec-policy-template-temp1-1] ike-profile profile1
# Enable IPsec RRI, set the preference to 100 and the tag to 1000 for the static routes created
by IPsec RRI.
[SwitchA-ipsec-policy-template-temp1-1] reverse-route dynamic
[SwitchA-ipsec-policy-template-temp1-1] reverse-route preference 100
[SwitchA-ipsec-policy-template-temp1-1] reverse-route tag 1000
[SwitchA-ipsec-policy-template-temp1-1] quit
# Create an IKE-based IPsec policy entry by using IPsec policy template temp1. Specify the
policy name as map1 and set the sequence number to 10.
[SwitchA] ipsec policy map1 10 isakmp template temp1
# Create an IKE proposal named 1, and specify 3DES as the encryption algorithm,
HMAC-SHA1 as the authentication algorithm, and pre-share as the authentication method.

434
 [SwitchA] ike proposal 1
[SwitchA-ike-proposal-1] encryption-algorithm 3des-cbc
[SwitchA-ike-proposal-1] authentication-algorithm sha
[SwitchA-ike-proposal-1] authentication-method pre-share
[SwitchA-ike-proposal-1] quit
# Create an IKE keychain named key1 and specify 123 in plain text as the preshared key to be
used with the remote peer at 2.2.2.2.
[SwitchA] ike keychain key1
[SwitchA-ike-keychain-key1] pre-shared-key address 2.2.2.2 key simple 123
[SwitchA-ike-keychain-key1] quit
# Apply IPsec policy map1 to VLAN-interface 100.
[SwitchA] interface vlan-interface 100
[SwitchA-Vlan-interface100] ipsec apply policy map1
[SwitchA-Vlan-interface100] quit
3. Configure Switch B:
# Create an IPsec transform set named tran1, and specify ESP as the security protocol, DES
as the encryption algorithm, and HMAC-SHA-1-96 as the authentication algorithm.
[SwitchB] ipsec transform-set tran1
[SwitchB-ipsec-transform-set-tran1] encapsulation-mode tunnel
[SwitchB-ipsec-transform-set-tran1] protocol esp
[SwitchB-ipsec-transform-set-tran1] esp encryption-algorithm des
[SwitchB-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[SwitchB-ipsec-transform-set-tran1] quit
# Configure IPv4 advanced ACL 3000 to identify traffic from subnet 5.5.5.0/24 to subnet
4.4.4.0/24.
[SwitchB] acl advanced 3000
[SwitchB-acl-ipv4-adv-3000] rule permit ip source 5.5.5.0 0.0.0.255 destination
4.4.4.0 0.0.0.255
[SwitchB-acl-ipv4-adv-3000] quit
# Create and configure the IKE profile named profile1.
[SwitchB] ike profile profile1
[SwitchB-ike-profile-profile1] keychain key1
[SwitchB-ike-profile-profile1] match remote identity address 1.1.1.1 255.255.255.0
[SwitchB-ike-profile-profile1] quit
# Create an IKE-based IPsec policy entry named map1 and configure the following settings for
the policy entry:
 Set the sequence number to 10.
 Specify transform set tran1 and ACL 3000.
 Specify the remote IP address for the tunnel as 1.1.1.1.
 Specify IKE profile profile1.
[SwitchB] ipsec policy map1 10 isakmp
[SwitchB-ipsec-policy-isakmp-map1-10] transform-set tran1
[SwitchB-ipsec-policy-isakmp-map1-10] security acl 3000
[SwitchB-ipsec-policy-isakmp-map1-10] remote-address 1.1.1.1
[SwitchB-ipsec-policy-isakmp-map1-10] ike-profile profile1
[SwitchB-ipsec-policy-isakmp-map1-10] quit
# Create an IKE proposal named 1, and specify 3DES as the encryption algorithm,
HMAC-SHA1 as the authentication algorithm, and pre-share as the authentication method.

435
 [SwitchB] ike proposal 1
[SwitchB-ike-proposal-1] encryption-algorithm 3des-cbc
[SwitchB-ike-proposal-1] authentication-algorithm sha
[SwitchB-ike-proposal-1] authentication-method pre-share
[SwitchB-ike-proposal-1] quit
# Create an IKE keychain named key1 and specify 123 in plain text as the preshared key to be
used with the remote peer at 1.1.1.1.
[SwitchB] ike keychain key1
[SwitchB-ike-keychain-key1] pre-shared-key address 1.1.1.1 key simple 123
[SwitchB-ike-keychain-key1] quit
# Apply IPsec policy map1 to VLAN-interface 100.
[SwitchB] interface vlan-interface 100
[SwitchB-Vlan-interface100] ipsec apply policy map1
[SwitchB-Vlan-interface100] quit
Make sure Switch B has a route to the peer private network, with the outgoing interface as
VLAN-interface 100.
4. Configure Switch C and Switch D in the same way Switch B is configured.
Verifying the configuration
1. Verify that IPsec RRI can automatically create a static route from Switch A to Switch B:
# Initiate a connection from subnet 5.5.5.0/24 to subnet 4.4.4.0/24. IKE negotiation is triggered
to establish IPsec SAs between Switch A and Switch B. (Details not shown.)
# Verify that IPsec SAs are established on Switch A.
[SwitchA] display ipsec sa
-------------------------------
Interface: Vlan-interface100
-------------------------------

-----------------------------
IPsec policy: map1
Sequence number: 10
Mode: Template
-----------------------------
Tunnel id: 0
Encapsulation mode: tunnel
Perfect Forward Secrecy:
Inside VPN:
Extended Sequence Numbers enable: N
Traffic Flow Confidentiality enable: N
Path MTU: 1463
Tunnel:
local address: 1.1.1.1
remote address: 2.2.2.2
Flow:
sour addr: 4.4.4.0/255.255.255.0 port: 0 protocol: ip
dest addr: 5.5.5.0/255.255.255.0 port: 0 protocol: ip

[Inbound ESP SAs]

SPI: 1014286405 (0x3c74c845)

436
 Connection ID: 90194313219
Transform set: ESP-ENCRYPT-DES-CBC ESP-AUTH-SHA1
SA duration (kilobytes/sec): 1843200/3600
SA remaining duration (kilobytes/sec): 1843199/3590
Max received sequence-number: 4
Anti-replay check enable: Y
Anti-replay window size: 64
UDP encapsulation used for NAT traversal: N
Status: Active

[Outbound ESP SAs]

SPI: 4011716027 (0xef1dedbb)
Connection ID: 64424509441
Transform set: ESP-ENCRYPT-DES-CBC ESP-AUTH-SHA1
SA duration (kilobytes/sec): 1843200/3600
SA remaining duration (kilobytes/sec): 1843199/3590
Max sent sequence-number: 4
UDP encapsulation used for NAT traversal: N
Status: Active
# Verify that IPsec RRI has created a static route to reach Switch B.
[SwitchA] display ip routing-table verbose
2. Verify that Switch A can automatically create static routes to Switch C and Switch D in the same
way that you verify the IPsec RRI feature by using Switch A and Switch B. (Details not shown.)

437
Configuring IKE
Unless otherwise specified, the term "IKE" in this chapter refers to IKEv1.

About IKE
Built on a framework defined by ISAKMP, Internet Key Exchange (IKE) provides automatic key
negotiation and SA establishment services for IPsec.

Benefits of IKE
IKE provides the following benefits for IPsec:
• Automatically negotiates IPsec parameters.
• Performs DH exchanges to calculate shared keys, making sure each SA has a key that is
independent of other keys.
• Automatically negotiates SAs when the sequence number in the AH or ESP header overflows,
making sure IPsec can provide the anti-replay service by using the sequence number.

Relationship between IPsec and IKE

As shown in Figure 109, IKE negotiates SAs for IPsec and transfers the SAs to IPsec, and IPsec
uses the SAs to protect IP packets.
Figure 109 Relationship between IKE and IPsec

SA negotiation
IKE IKE

Device A Device B

SA SA
TCP/UDP TCP/UDP

IPsec IPsec
Protected IP packets

IKE negotiation process

IKE negotiates keys and SAs for IPsec in two phases:
1. Phase 1—The two peers establish an IKE SA, a secure, authenticated channel for
communication.
2. Phase 2—Using the IKE SA established in phase 1, the two peers negotiate to establish IPsec
SAs.
Phase 1 negotiation can use either main mode or aggressive mode.

438
IKE exchange process in main mode
As shown in Figure 110, the main mode of IKE negotiation in phase 1 involves three pairs of
messages:
• SA exchange—Used for negotiating the IKE security policy.
• Key exchange—Used for exchanging the DH public value and other values, such as the
random number. The two peers use the exchanged data to generate key data and use the
encryption key and authentication key to ensure the security of IP packets.
• ID and authentication data exchange—Used for identity authentication.
Figure 110 IKE exchange process in main mode
Peer 1 Peer 2
Algorithm
Initiator’s policy negotiation
Send local
IKE policy
Search for
Confirmed policy matched policy

Receive the
SA exchange
confirmed policy Initiator’s keying data Key generation

Receiver’s keying Generate the key

data

Key exchange Generate the key Identity

Initiator’s identity and authentication

authentication data
Perform ID/exchange
Receiver’s identity and authentication

ID and authentication Perform ID/exchange authentication data

data exchange authentication

IKE exchange process in aggressive mode

As shown in Figure 111, the process of phase 1 IKE negotiation in aggressive mode is as follows:
1. The initiator (peer 1) sends a message containing the local IKE information to peer 2. The
message includes parameters used for IKE SA establishment, keying data, and peer 1's
identity information.
2. Peer 2 chooses the IKE establishment parameters to use, generate the key, and authenticate
peer 1's identity. Then it sends the IKE data to peer 1.
3. Peer 1 generates the key, authenticates peer 2's identity, and sends the results to peer 1.
After the preceding process, an IKE SA is established between peer 1 and peer 2.
The aggressive mode is faster than the main mode but it does not provide identity information
protection. The main mode provides identity information protection but is slower. Choose the
appropriate negotiation mode according to your requirements.

439
 Figure 111 IKE exchange process in aggressive mode
Peer 1 Peer 2
Parameter negotiation
Initiator’s IKE Key generation
Send local IKE
information Identity authentication
information
Search for
Receiver’s IKE information matched IKE
settings
Generate the key
and authenticate
Initiator’s authentication results
peer 2
IKE SA
established

IKE security mechanism

IKE has a series of self-protection mechanisms and supports secure identity authentication, key
distribution, and IPsec SA establishment on insecure networks.
Identity authentication
The IKE identity authentication mechanism is used to authenticate the identity of the communicating
peers. The device supports the following identity authentication methods:
• Preshared key authentication—Two communicating peers use the pre-configured shared key
for identity authentication.
• RSA signature authentication and DSA signature authentication—Two communicating
peers use the digital certificates issued by the CA for identity authentication.
The preshared key authentication method does not require certificates and is easy to configure. It is
usually deployed in small networks.
The signature authentication methods provide higher security and are usually deployed in networks
with the headquarters and some branches. When deployed in a network with many branches, a
signature authentication method can simplify the configuration because only one PKI domain is
required. If you use the preshared key authentication method, you must configure a preshared key
for each branch on the Headquarters node.
DH algorithm
The DH algorithm is a public key algorithm. With this algorithm, two peers can exchange keying
material and then use the material to calculate the shared keys. Due to the decryption complexity, a
third party cannot decrypt the keys even after intercepting all keying materials.
PFS
The Perfect Forward Secrecy (PFS) feature is a security feature based on the DH algorithm. After
PFS is enabled, an additional DH exchange is performed in IKE phase 2 to make sure IPsec keys
have no derivative relations with IKE keys and a broken key brings no threats to other keys.

Protocols and standards

• RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)
• RFC 2409, The Internet Key Exchange (IKE)
• RFC 2412, The OAKLEY Key Determination Protocol
• Internet Draft, draft-ietf-ipsec-isakmp-xauth-06
• Internet Draft, draft-dukes-ike-mode-cfg-02

440
FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for
features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and
non-FIPS mode.

IKE tasks at a glance

To configure IKE, perform the following tasks:
1. (Optional.) Configuring an IKE profile
a. Creating an IKE profile
b. Configuring peer IDs for the IKE profile
c. Specifying the IKE keychain or PKI domain
d. Configuring the IKE phase 1 negotiation mode
e. Specifying IKE proposals for the IKE profile
f. Configuring the local ID for the IKE profile
g. Specifying an inside VPN instance for the IKE profile
h. Configuring optional features for the IKE profile
2. Configuring an IKE proposal
3. Configuring an IKE keychain
4. (Optional.)Configuring the global identity information
5. (Optional.)Configuring the IKE keepalive feature
6. (Optional.)Configuring the IKE NAT keepalive feature
7. (Optional.)Configuring global IKE DPD
8. (Optional.)Enabling invalid SPI recovery
9. (Optional.)Setting the maximum number of IKE SAs
10. (Optional.)Configuring SNMP notifications for IKE

Prerequisites for IKE configuration

Determine the following parameters prior to IKE configuration:
• The algorithms to be used during IKE negotiation, including the identity authentication method,
encryption algorithm, authentication algorithm, and DH group.
 Different algorithms provide different levels of protection. A stronger algorithm provides
more resistance to decryption but uses more resources.
 A DH group that uses more bits provides higher security but needs more time for
processing.
• The preshared key or PKI domain for IKE negotiation. For more information about PKI, see
"Configuring PKI."
• The IKE-based IPsec policies for the communicating peers. If you do not specify an IKE profile
in an IPsec policy, the device selects an IKE profile for the IPsec policy. If no IKE profile is
configured, the globally configured IKE settings are used. For more information about IPsec,
see "Configuring IPsec."

441
Configuring an IKE profile
Creating an IKE profile
About this task
Perform this task to create an IKE profile.
An IKE profile is intended to provide a set of parameters for IKE negotiation.
Procedure
1. Enter system view.
system-view
2. Create an IKE profile and enter its view.
ike profile profile-name

Configuring peer IDs for the IKE profile

About this task
Perform this task to configure the peer IDs for IKE profile matching. When the device needs to select
an IKE profile for IKE negotiation with a peer, it compares the received peer ID with the peer IDs of its
local IKE profiles. If a match is found, it uses the IKE profile with the matching peer ID for IKE
negotiation.
Restrictions and guidelines
For an IKE profile, you can configure multiple peer IDs. A peer ID configured earlier has a higher
priority.
Two IKE peers must both have or both not have peer IDs configured.
Procedure
1. Enter system view.
system-view
2. Enter IKE profile view.
ike profile profile-name
3. Configure a peer ID for the IKE profile.
match remote { certificate policy-name | identity { address
{ { ipv4-address [ mask | mask-length ] | range low-ipv4-address
high-ipv4-address } | ipv6 { ipv6-address [ prefix-length ] | range
low-ipv6-address high-ipv6-address } } [ vpn-instance
vpn-instance-name ] | fqdn fqdn-name | user-fqdn user-fqdn-name } }

Specifying the IKE keychain or PKI domain

Restrictions and guidelines
Configure the IKE keychain or PKI domain for the IKE proposals to use. To use digital signature
authentication, configure a PKI domain. To use preshared key authentication, configure an IKE
keychain.
Procedure
1. Enter system view.

442
 system-view
2. Enter IKE profile view.
ike profile profile-name
3. Specify the keychain for preshared key authentication or the PKI domain used to request a
certificate for digital signature authentication.
 Specify the keychain.
keychain keychain-name
 Specify the PKI domain.
certificate domain domain-name
By default, no IKE keychain or PKI domain is specified in an IKE profile.

Configuring the IKE phase 1 negotiation mode

Restrictions and guidelines
Specify the IKE phase 1 negotiation mode (main or aggressive) that the device uses as the initiator.
When the device acts as the responder, it uses the IKE negotiation mode of the initiator.
Procedure
1. Enter system view.
system-view
2. Enter IKE profile view.
ike profile profile-name
3. Specify the IKE negotiation mode for phase 1.
In non-FIPS mode:
exchange-mode { aggressive | main }
In FIPS mode:
exchange-mode main
By default, IKE negotiation in phase 1 uses the main mode.

Specifying IKE proposals for the IKE profile

Restrictions and guidelines
Specify the IKE proposals that the device can use as the initiator. An IKE proposal specified earlier
has a higher priority. When the device acts as the responder, it uses the IKE proposals configured in
system view to match the IKE proposals received from the initiator. If no matching proposal is found,
the negotiation fails.
Procedure
1. Enter system view.
system-view
2. Enter IKE profile view.
ike profile profile-name
3. Specify IKE proposals for the IKE profile.
proposal proposal-number&<1-6>
By default, no IKE proposals are specified for an IKE profile and the IKE proposals configured in
system view are used for IKE negotiation.

443
Configuring the local ID for the IKE profile
Restrictions and guidelines
For digital signature authentication, the device can use an ID of any type. If the local ID is an IP
address that is different from the IP address in the local certificate, the device uses the FQDN (the
device name configured by using the sysname command) instead.
For preshared key authentication, the device can use an ID of any type other than the DN.
Procedure
1. Enter system view.
system-view
2. Enter IKE profile view.
ike profile profile-name
3. Configure the local ID.
local-identity { address { ipv4-address | ipv6 ipv6-address } | dn |
fqdn [ fqdn-name ] | user-fqdn [ user-fqdn-name ] }
By default, no local ID is configured for an IKE profile, and an IKE profile uses the local ID
configured in system view. If the local ID is not configured in system view, the IKE profile uses
the IP address of the interface to which the IPsec policy or IPsec policy template is applied as
the local ID.

Specifying an inside VPN instance for the IKE profile

About this task
The inside MPLS L3VPN instance determines where the device should forward received IPsec
protected data. If you specify an inside VPN instance, the device looks for a route in the specified
VPN instance to forward the data. If you do not specify an inside VPN instance, the device looks for
a route in the VPN instance where the receiving interface resides to forward the data.
Restrictions and guidelines
The inside VPN instance specified in an IKE profile takes effect only on IPsec policies that use the
IKE profile. It does not take effect on IPsec profiles that use the IKE profile.
Procedure
1. Enter system view.
system-view
2. Enter IKE profile view.
ike profile profile-name
3. Specify an inside VPN instance.
inside-vpn vpn-instance vpn-instance-name
By default, no inside VPN instance is specified for an IKE profile, and the device forwards
protected data to the VPN instance where the interface receiving the data resides.

Configuring optional features for the IKE profile

1. Enter system view.
system-view
2. Enter IKE profile view.

444
 ike profile profile-name
3. Configure optional features as needed.
 Configure IKE DPD.
dpd interval interval [ retry seconds ] { on-demand | periodic }
By default, IKE DPD is not configured for an IKE profile and an IKE profile uses the DPD
settings configured in system view. If IKE DPD is not configured in system view either, the
device does not perform dead IKE peer detection.
The IKE DPD settings configured in the IKE profile view take precedence over those
configured in system view.
 Specify the local interface or IP address to which the IKE profile can be applied.
match local address { interface-type interface-number |
{ ipv4-address | ipv6 ipv6-address } [ vpn-instance
vpn-instance-name ] }
By default, an IKE profile can be applied to any local interface or IP address.
An IKE profile configured with this command has a higher priority over those not configured
with this command.
 Specify a priority for the IKE profile.
priority priority
By default, the priority of an IKE profile is 100.
The device selects a local IKE profile for IKE negotiation as follows:
− First, it selects an IKE profile with the match local address command configured.
− If a tie exists, it selects the IKE profile with a smaller priority number.
− If a tie still exists, it selects the IKE profile configured earlier.

Configuring an IKE proposal

About this task
An IKE proposal defines a set of attributes describing how IKE negotiation in phase 1 should take
place. You can create multiple IKE proposals with different priorities. The priority of an IKE proposal
is represented by its sequence number. The lower the sequence number, the higher the priority.
Two peers must have at least one matching IKE proposal for successful IKE negotiation. During IKE
negotiation:
• The initiator sends its IKE proposals to the peer.
 If the initiator is using an IPsec policy with an IKE profile, the initiator sends all IKE proposals
specified in the IKE profile to the peer. An IKE proposal specified earlier for the IKE profile
has a higher priority.
 If the initiator is using an IPsec policy with no IKE profile, the initiator sends all its IKE
proposals to the peer. An IKE proposal with a smaller number has a higher priority.
• The peer searches its own IKE proposals for a match. The search starts from the IKE proposal
with the highest priority and proceeds in descending order of priority until a match is found. The
matching IKE proposals are used to establish the IKE SA. If all user-defined IKE proposals are
found mismatching, the two peers use their default IKE proposals to establish the IKE SA.
Two matching IKE proposals have the same encryption algorithm, authentication method,
authentication algorithm, and DH group. The SA lifetime takes the smaller one of the two proposals'
SA lifetime settings.
Procedure
1. Enter system view.

445
 system-view
2. Create an IKE proposal and enter its view.
ike proposal proposal-number
By default, a default IKE proposal exists.
3. Configure a description for the IKE proposal.
description
By default, an IKE proposal does not have a description.
4. Specify an encryption algorithm for the IKE proposal.
In non-FIPS mode:
encryption-algorithm { 3des-cbc | aes-cbc-128 | aes-cbc-192 |
aes-cbc-256 | des-cbc }
By default, the 56-bit DES encryption algorithm in CBC mode is used .
In FIPS mode:
encryption-algorithm { aes-cbc-128 | aes-cbc-192 | aes-cbc-256 }
By default, the 128-bit AES encryption algorithm in CBC mode is used.
5. Specify an authentication method for the IKE proposal.
authentication-method{ dsa-signature | ecdsa-signature | pre-share |
rsa-signature }
By default, the preshared key authentication method is used.
6. Specify an authentication algorithm for the IKE proposal.
In non-FIPS mode:
authentication-algorithm { md5 | sha | sha256 | sha384 | sha512 }
By default, the HMAC-SHA1 authentication algorithm is used.
In FIPS mode:
authentication-algorithm { sha | sha256 | sha384 | sha512 }
By default, the HMAC-SHA256 authentication algorithm is used.
7. Specify a DH group for key negotiation in phase 1.
In non-FIPS mode:
dh{ group1 | group14 | group19 | group2 | group20 | group24 | group5 }
DH group 1 (the 768-bit DH group) is used by default.
In FIPS mode:
dh{ group14 | group19 | group20 | group24 }
DH group 14 (the 2048-bit DH group) is used by default.
8. (Optional.) Set the IKE SA lifetime for the IKE proposal.
sa duration seconds
By default, the IKE SA lifetime is 86400 seconds.

Configuring an IKE keychain

About this task
Perform this task when you configure the IKE to use the preshared key for authentication.
Follow these guidelines when you configure an IKE keychain:
• Two peers must be configured with the same preshared key to pass preshared key
authentication.

446
 • You can specify the local address configured in IPsec policy or IPsec policy template view
(using the local-address command) for the IKE keychain to be applied. If no local address
is configured, specify the IP address of the interface that uses the IPsec policy.
• The device determines the priority of an IKE keychain as follows:
a. The device examines the existence of the match local address command. An IKE
keychain with the match local address command configured has a higher priority.
b. If a tie exists, the device compares the priority numbers. An IKE keychain with a smaller
priority number has a higher priority.
c. If a tie still exists, the device prefers an IKE keychain configured earlier.
Procedure
1. Enter system view.
system-view
2. Create an IKE keychain and enter its view.
ike keychain keychain-name [ vpn-instance vpn-instance-name ]
3. Configure a preshared key.
In non-FIPS mode:
pre-shared-key { address { ipv4-address [ mask | mask-length ] | ipv6
ipv6-address [ prefix-length ] } | hostname host-name } key { cipher |
simple } string
In FIPS mode:
pre-shared-key { address { ipv4-address [ mask | mask-length ] | ipv6
ipv6-address [ prefix-length ] } | hostname host-name } key [ cipher
string ]
By default, no preshared key is configured.
4. (Optional.) Specify a local interface or IP address to which the IKE keychain can be applied.
match local address { interface-type interface-number | { ipv4-address
| ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] }
By default, an IKE keychain can be applied to any local interface or IP address.
5. (Optional.) Specify a priority for the IKE keychain.
priority priority
The default priority is 100.

Configuring the global identity information

Restrictions and guidelines
The global identity can be used by the device for all IKE SA negotiations, and the local identity (set by
the local-identity command) can be used only by the device that uses the IKE profile.
When signature authentication is used, you can set any type of the identity information.
When preshared key authentication is used, you cannot set the DN as the identity.
Procedure
1. Enter system view.
system-view
2. Configure the global identity to be used by the local end.
ike identity { address { ipv4-address | ipv6 ipv6-address }| dn | fqdn
[ fqdn-name ] | user-fqdn [ user-fqdn-name ] }

447
 By default, the IP address of the interface to which the IPsec policy or IPsec policy template is
applied is used as the IKE identity.
3. (Optional.) Configure the local device to always obtain the identity information from the local
certificate for signature authentication.
ike signature-identity from-certificate
By default, the local end uses the identity information specified by local-identity or ike
identity for signature authentication.
Configure this command when the aggressive mode and signature authentication are used and
the device interconnects with a Comware 5-based peer device. Comware 5 supports only DN
for signature authentication.

Configuring the IKE keepalive feature

About this task
IKE sends keepalive packets to query the liveness of the peer. If the peer is configured with the
keepalive timeout time, you must configure the keepalive interval on the local device. If the peer
receives no keepalive packets during the timeout time, the IKE SA is deleted along with the IPsec
SAs it negotiated.
Restrictions and guidelines
Configure IKE DPD instead of IKE keepalive unless IKE DPD is not supported on the peer. The IKE
keepalive feature sends keepalives at regular intervals, which consumes network bandwidth and
resources.
The keepalive timeout time configured on the local device must be longer than the keepalive interval
configured at the peer. Since it seldom occurs that more than three consecutive packets are lost on a
network, you can set the keepalive timeout three times as long as the keepalive interval.
Procedure
1. Enter system view.
system-view
2. Set the IKE SA keepalive interval.
ike keepalive interval interval
By default, no keepalives are sent to the peer.
3. Set the IKE SA keepalive timeout time.
ike keepalive timeout seconds
By default, IKE SA keepalive never times out.

Configuring the IKE NAT keepalive feature

About this task
If IPsec traffic passes through a NAT device, you must configure the NAT traversal feature. If no
packet travels across an IPsec tunnel in a period of time, the NAT sessions are aged and deleted,
disabling the tunnel from transmitting data to the intended end. To prevent NAT sessions from being
aged, configure the NAT keepalive feature on the IKE gateway behind the NAT device to send NAT
keepalive packets to its peer periodically to keep the NAT session alive.
Procedure
1. Enter system view.
system-view

448
 2. Set the IKE NAT keepalive interval.
ike nat-keepalive seconds
The default interval is 20 seconds.

Configuring global IKE DPD

About this task
DPD detects dead peers. It can operate in periodic mode or on-demand mode.
• Periodic DPD—Sends a DPD message at regular intervals. It features an earlier detection of
dead peers, but consumes more bandwidth and CPU.
• On-demand DPD—Sends a DPD message based on traffic. When the device has traffic to
send and is not aware of the liveness of the peer, it sends a DPD message to query the status of
the peer. If the device has no traffic to send, it never sends DPD messages. As a best practice,
use the on-demand mode.
The IKE DPD works as follows:
1. The local device sends a DPD message to the peer, and waits for a response from the peer.
2. If the peer does not respond within the retry interval specified by the retry seconds parameter,
the local device resends the message.
3. If still no response is received within the retry interval, the local end sends the DPD message
again. The system allows a maximum of two retries.
4. If the local device receives no response after two retries, the device considers the peer to be
dead, and deletes the IKE SA along with the IPsec SAs it negotiated.
5. If the local device receives a response from the peer during the detection process, the peer is
considered alive. The local device performs a DPD detection again when the triggering interval
is reached or it has traffic to send, depending on the DPD mode.
Restrictions and guidelines
When DPD settings are configured in both IKE profile view and system view, the DPD settings in IKE
profile view apply. If DPD is not configured in IKE profile view, the DPD settings in system view apply.
It is a good practice to set the triggering interval longer than the retry interval so that a DPD detection
is not triggered during a DPD retry.
Procedure
1. Enter system view.
system-view
2. Enable sending IKE DPD messages.
ike dpd interval interval [ retry seconds ] { on-demand | periodic }
By default, IKE DPD is disabled.

Enabling invalid SPI recovery

About this task
An IPsec "black hole" occurs when one IPsec peer fails (for example, a peer can fail if a reboot
occurs). One peer fails and loses its SAs with the other peer. When an IPsec peer receives a data
packet for which it cannot find an SA, an invalid SPI is encountered. The peer drops the data packet
and tries to send an SPI invalid notification to the data originator. This notification is sent by using the
IKE SA. Because no IKE SA is available, the notification is not sent. The originating peer continues
sending the data by using the IPsec SA that has the invalid SPI, and the receiving peer keeps
dropping the traffic.

449
 The invalid SPI recovery feature enables the receiving peer to set up an IKE SA with the originator so
that an SPI invalid notification can be sent. Upon receiving the notification, the originating peer
deletes the IPsec SA that has the invalid SPI. If the originator has data to send, new SAs will be set
up.
Restrictions and guidelines
Use caution when you enable the invalid SPI recovery feature because using this feature can result
in a DoS attack. Attackers can make a great number of invalid SPI notifications to the same peer.
Procedure
1. Enter system view.
system-view
2. Enable invalid SPI recovery.
ike invalid-spi-recovery enable
By default, the invalid SPI recovery is disabled.

Setting the maximum number of IKE SAs

About this task
You can set the maximum number of half-open IKE SAs and the maximum number of established
IKE SAs.
• The supported maximum number of half-open IKE SAs depends on the device's processing
capability. Adjust the maximum number of half-open IKE SAs to make full use of the device's
processing capability without affecting the IKE SA negotiation efficiency.
• The supported maximum number of established IKE SAs depends on the device's memory
space. Adjust the maximum number of established IKE SAs to make full use of the device's
memory space without affecting other applications in the system.
Procedure
1. Enter system view.
system-view
2. Set the maximum number of half-open IKE SAs and the maximum number of established IKE
SAs.
ike limit { max-negotiating-sa negotiation-limit | max-sa sa-limit }
By default, there is no limit to the maximum number of IKE SAs.

Configuring SNMP notifications for IKE

About this task
After you enable SNMP notifications for IKE, the IKE module notifies the NMS of important module
events. The notifications are sent to the device's SNMP module. For the notifications to be sent
correctly, you must also configure SNMP on the device. For more information about SNMP
notifications, see Network Management and Monitoring Configuration Guide.
To generate and output SNMP notifications for a specific IKE failure or event type, perform the
following tasks:
1. Enable SNMP notifications for IKE globally.
2. Enable SNMP notifications for the failure or event type.
Procedure
1. Enter system view

450
 system-view
2. Enable SNMP notifications for IKE globally.
snmp-agent trap enable ike global
By default, SNMP notifications for IKE are disabled.
3. Enable SNMP notifications for the specified failure or event types.
snmp-agent trap enable ike [ attr-not-support | auth-failure |
cert-type-unsupport | cert-unavailable | decrypt-failure |
encrypt-failure | invalid-cert-auth | invalid-cookie | invalid-id |
invalid-proposal | invalid-protocol | invalid-sign | no-sa-failure |
proposal-add | proposal–delete | tunnel-start | tunnel-stop |
unsupport-exch-type ] *
By default, SNMP notifications for all failure and event types are disabled.

Display and maintenance commands for IKE

Execute display commands in any view and reset commands in user view.

Task Command
Display configuration information about all IKE
display ike proposal
proposals.

display ike sa [ verbose

[ connection-id connection-id |
Display information about the current IKE SAs. remote-address [ ipv6 ]
remote-address [ vpn-instance
vpn-instance-name ] ] ]
Display IKE statistics. display ike statistics
reset ike sa [ connection-id
Delete IKE SAs.
connection-id ]
Clear IKE MIB statistics. reset ike statistics

IKE configuration examples

Example: Configuring main-mode IKE with preshared key
authentication
Network configuration
As shown in Figure 112, configure an IKE-based IPsec tunnel between Switch A and Switch B to
secure the communication between the switches.
• Configure the two switches to use the default IKE proposal for the IKE negotiation.
• Configure the two switches to use the preshared key authentication method for the IKE
negotiation.

451
 Figure 112 Network diagram
Vlan-int1 Vlan-int1
1.1.1.1/16 2.2.2.2/16
Internet

Switch A Switch B

Procedure
1. Make sure Switch A and Switch B can reach each other.
2. Configure Switch A:
# Configure an IP address for VLAN-interface 1.
<SwitchA> system-view
[SwitchA] interface vlan-interface 1
[SwitchA-vlan-interface1] ip address 1.1.1.1 255.255.0.0
[SwitchA-vlan-interface1] quit
# Configure IPv4 advanced ACL 3101 to identify the traffic from Switch A to Switch B.
[SwitchA] acl advanced 3101
[SwitchA-acl-ipv4-adv-3101] rule 0 permit ip source 1.1.1.1 0 destination 2.2.2.2 0
[SwitchA-acl-ipv4-adv-3101] quit
# Create an IPsec transform set named tran1.
[SwitchA] ipsec transform-set tran1
# Set the packet encapsulation mode to tunnel.
[SwitchA-ipsec-transform-set-tran1] encapsulation-mode tunnel
# Use the ESP protocol for the IPsec transform set.
[SwitchA-ipsec-transform-set-tran1] protocol esp
# Specify the encryption and authentication algorithms.
[SwitchA-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-192
[SwitchA-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[SwitchA-ipsec-transform-set-tran1] quit
# Create an IKE keychain named keychain1.
[SwitchA] ike keychain keychain1
# Specify 12345zxcvb!@#$%ZXCVB in plain text as the preshared key to be used with the
remote peer at 2.2.2.2.
[SwitchA-ike-keychain-keychain1] pre-shared-key address 2.2.2.2 255.255.0.0 key
simple 12345zxcvb!@#$%ZXCVB
[SwitchA-ike-keychain-keychain1] quit
# Create an IKE profile named profile1.
[SwitchA] ike profile profile1
# Specify IKE keychain keychain1.
[SwitchA-ike-profile-profile1] keychain keychain1
# Configure a peer ID with the identity type as IP address and the value as 2.2.2.2/16.
[SwitchA-ike-profile-profile1] match remote identity address 2.2.2.2 255.255.0.0
[SwitchA-ike-profile-profile1] quit
# Create an IKE-based IPsec policy entry. Specify the policy name as map1 and set the
sequence number to 10.
[SwitchA] ipsec policy map1 10 isakmp
# Specify the remote IP address 2.2.2.2 for the IPsec tunnel.
[SwitchA-ipsec-policy-isakmp-map1-10] remote-address 2.2.2.2

452
 # Specify ACL 3101 to identify the traffic to be protected.
[SwitchA-ipsec-policy-isakmp-map1-10] security acl 3101
# Specify IPsec transform set tran1 for the IPsec policy.
[SwitchA-ipsec-policy-isakmp-map1-10] transform-set tran1
# Specify IKE profile profile1 for the IPsec policy.
[SwitchA-ipsec-policy-isakmp-map1-10] ike-profile profile1
[SwitchA-ipsec-policy-isakmp-map1-10] quit
# Apply IPsec policy map1 to VLAN-interface 1.
[SwitchA] interface vlan-interface 1
[SwitchA-Vlan-interface1] ipsec apply policy map1
3. Configure Switch B:
# Configure an IP address for VLAN-interface 1.
<SwitchB> system-view
[SwitchB] interface Vlan-interface1
[SwitchB-Vlan-interface1] ip address 2.2.2.2 255.255.0.0
[SwitchB-Vlan-interface1] quit
# Configure IPv4 advanced ACL 3101 to identify the traffic from Switch B to Switch A.
[SwitchB] acl number 3101
[SwitchB-acl-adv-3101] rule 0 permit ip source 2.2.2.2 0 destination 1.1.1.1 0
[SwitchB-acl-adv-3101] quit
# Create an IPsec transform set named tran1.
[SwitchB] ipsec transform-set tran1
# Set the packet encapsulation mode to tunnel.
[SwitchB-ipsec-transform-set-tran1] encapsulation-mode tunnel
# Use the ESP protocol for the IPsec transform set.
[SwitchB-ipsec-transform-set-tran1] protocol esp
# Specify the encryption and authentication algorithms.
[SwitchB-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-192
[SwitchB-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[SwitchB-ipsec-transform-set-tran1] quit
# Create an IKE keychain named keychain1.
[SwitchB]ike keychain keychain1
# Specify 12345zxcvb!@#$%ZXCVB in plain text as the preshared key to be used with the
remote peer at 1.1.1.1.
[SwitchB-ike-keychain-keychain1] pre-shared-key address 1.1.1.1 255.255.0.0 key
simple 12345zxcvb!@#$%ZXCVB
[SwitchB-ike-keychain-keychain1] quit
# Create an IKE profile named profile1.
[SwitchB] ike profile profile1
# Specify IKE keychain keychain1
[SwitchB-ike-profile-profile1] keychain keychain1
# Configure a peer ID with the identity type as IP address and the value as 1.1.1.1/16.
[SwitchB-ike-profile-profile1] match remote identity address 1.1.1.1 255.255.0.0
[SwitchB-ike-profile-profile1] quit
# Create an IKE-based IPsec policy entry. Specify the policy name as use1 and set the
sequence number to 10.
[SwitchB] ipsec policy use1 10 isakmp

453
 # Specify the remote IP address 1.1.1.1 for the IPsec tunnel.
[SwitchB-ipsec-policy-isakmp-use1-10] remote-address 1.1.1.1
# Specify ACL 3101 to identify the traffic to be protected.
[SwitchB-ipsec-policy-isakmp-use1-10] security acl 3101
# Specify IPsec transform set tran1 for the IPsec policy.
[SwitchB-ipsec-policy-isakmp-use1-10] transform-set tran1
# Specify IKE profile profile1 for the IPsec policy.
[SwitchB-ipsec-policy-isakmp-use1-10] ike-profile profile1
[SwitchB-ipsec-policy-isakmp-use1-10] quit
# Apply IPsec policy use1 to VLAN-interface 1.
[SwitchB] interface vlan-interface 1
[SwitchB-Vlan-interface1] ipsec apply policy use1

Verifying the configuration

# Initiate a connection between Switch A and Switch B to trigger IKE negotiation. After IPsec SAs are
successfully negotiated by IKE, the traffic between the two switches is IPsec-protected.

Example: Configuring an IKE-based IPsec tunnel for IPv4

packets
Network configuration
As shown in Figure 113, establish an IPsec tunnel between Switch A and Switch B to protect data
flows between the switches. Configure the IPsec tunnel as follows:
• Specify the encapsulation mode as tunnel, the security protocol as ESP, the encryption
algorithm as AES-CBC-192, and the authentication algorithm as HMAC-SHA1.
• Set up SAs through IKE negotiation.
Figure 113 Network diagram
Vlan-int1 Vlan-int1
2.2.2.1/24 2.2.3.1/24
Internet

Switch A Switch B

Procedure
1. Configure Switch A:
# Configure an IP address for VLAN-interface 1.
<SwitchA> system-view
[SwitchA] interface vlan-interface 1
[SwitchA-Vlan-interface1] ip address 2.2.2.1 255.255.255.0
[SwitchA-Vlan-interface1] quit
# Configure an IPv4 advanced ACL to identify the data flows from Switch A to Switch B.
[SwitchA] acl advanced 3101
[SwitchA-acl-ipv4-adv-3101] rule 0 permit ip source 2.2.2.1 0 destination 2.2.3.1 0
[SwitchA-acl-ipv4-adv-3101] quit
# Create an IPsec transform set named tran1.
[SwitchA] ipsec transform-set tran1
# Specify the encapsulation mode as tunnel.
[SwitchA-ipsec-transform-set-tran1] encapsulation-mode tunnel

454
 # Specify the security protocol as ESP.
[SwitchA-ipsec-transform-set-tran1] protocol esp
# Specify the ESP encryption and authentication algorithms.
[SwitchA-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-192
[SwitchA-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[SwitchA-ipsec-transform-set-tran1] quit
# Create an IKE keychain named keychain1.
[SwitchA] ike keychain keychain1
# Specify 12345zxcvb!@#$%ZXCVB in plain text as the preshared key to be used with the
remote peer at 2.2.3.1.
[SwitchA-ike-keychain-keychain1] pre-shared-key address 2.2.3.1 255.255.255.0 key
simple 12345zxcvb!@#$%ZXCVB
[SwitchA-ike-keychain-keychain1] quit
# Create and configure an IKE profile named profile1.
[SwitchA] ike profile profile1
[SwitchA-ike-profile-profile1] keychain keychain1
[SwitchA-ike-profile-profile1] match remote identity address 2.2.3.1 255.255.255.0
[SwitchA-ike-profile-profile1] quit
# Create an IKE-based IPsec policy entry. Specify the policy name as map1 and set the
sequence number to 10.
[SwitchA] ipsec policy map1 10 isakmp
# Specify ACL 3101.
[SwitchA-ipsec-policy-isakmp-map1-10] security acl 3101
# Specify IPsec transform set tran1.
[SwitchA-ipsec-policy-isakmp-map1-10] transform-set tran1
# Specify the local and remote IP addresses of the IPsec tunnel as 2.2.2.1 and 2.2.3.1.
[SwitchA-ipsec-policy-isakmp-map1-10] local-address 2.2.2.1
[SwitchA-ipsec-policy-isakmp-map1-10] remote-address 2.2.3.1
# Specify IKE profile profile1.
[SwitchA-ipsec-policy-isakmp-map1-10] ike-profile profile1
[SwitchA-ipsec-policy-isakmp-map1-10] quit
# Apply IPsec policy map1 to VLAN-interface 1.
[SwitchA] interface vlan-interface 1
[SwitchA-Vlan-interface1] ipsec apply policy map1
2. Configure Switch B:
# Configure an IP address for VLAN-interface 1.
<SwitchB> system-view
[SwitchB] interface vlan-interface 1
[SwitchB-Vlan-interface1] ip address 2.2.3.1 255.255.255.0
[SwitchB-Vlan-interface1] quit
# Configure an IPv4 advanced ACL to identify the data flows from Switch B to Switch A.
[SwitchB] acl advanced 3101
[SwitchB-acl-ipv4-adv-3101] rule 0 permit ip source 2.2.3.1 0 destination 2.2.2.1 0
[SwitchB-acl-ipv4-adv-3101] quit
# Create an IPsec transform set named tran1.
[SwitchB] ipsec transform-set tran1
# Specify the encapsulation mode as tunnel.

455
 [SwitchB-ipsec-transform-set-tran1] encapsulation-mode tunnel
# Specify the security protocol as ESP.
[SwitchB-ipsec-transform-set-tran1] protocol esp
# Specify the ESP encryption and authentication algorithms.
[SwitchB-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-192
[SwitchB-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[SwitchB-ipsec-transform-set-tran1] quit
# Create an IKE keychain named keychain1.
[SwitchB] ike keychain keychain1
# Specify 12345zxcvb!@#$%ZXCVB in plain text as the preshared key to be used with the
remote peer at 2.2.2.1.
[SwitchB-ike-keychain-keychain1] pre-shared-key address 2.2.2.1 255.255.255.0 key
simple 12345zxcvb!@#$%ZXCVB
[SwitchB-ike-keychain-keychain1] quit
# Create and configure an IKE profile named profile1.
[SwitchB] ike profile profile1
[SwitchB-ike-profile-profile1] keychain keychain1
[SwitchB-ike-profile-profile1] match remote identity address 2.2.2.1 255.255.255.0
[SwitchB-ike-profile-profile1] quit
# Create an IKE-based IPsec policy entry. Specify the policy name as use1 and set the
sequence number to 10.
[SwitchB] ipsec policy use1 10 isakmp
# Specify ACL 3101.
[SwitchB-ipsec-policy-isakmp-use1-10] security acl 3101
# Specify IPsec transform set tran1.
[SwitchB-ipsec-policy-isakmp-use1-10] transform-set tran1
# Specify the local and remote IP addresses of the IPsec tunnel as 2.2.3.1 and 2.2.2.1.
[SwitchB-ipsec-policy-isakmp-use1-10] local-address 2.2.3.1
[SwitchB-ipsec-policy-isakmp-use1-10] remote-address 2.2.2.1
# Specify IKE profile profile1.
[SwitchB-ipsec-policy-isakmp-use1-10] ike-profile profile1
[SwitchB-ipsec-policy-isakmp-use1-10] quit
# Apply IPsec policy use1 to VLAN-interface 1.
[SwitchB] interface vlan-interface 1
[SwitchB-Vlan-interface1] ipsec apply policy use1

Verifying the configuration

# Initiate a connection between Switch A and Switch B to trigger IKE negotiation. After IPsec SAs are
successfully negotiated by IKE, the traffic between the two switches is IPsec-protected.

Troubleshooting IKE
IKE negotiation failed because no matching IKE proposals
were found
Symptom
1. The IKE SA is in Unknown state.

456
 <Sysname> display ike sa
Connection-ID Remote Flag DOI
------------------------------------------------------------------
1 192.168.222.5 Unknown IPsec
Flags:
RD--READY RL--REPLACED FD-FADING RK-REKEY
2. When IKE event debugging and packet debugging are enabled, the following messages
appear:
IKE event debugging message:
The attributes are unacceptable.
IKE packet debugging message:
Construct notification packet: NO_PROPOSAL_CHOSEN.

Analysis
Certain IKE proposal settings are incorrect.
Solution
1. Examine the IKE proposal configuration to see whether the two ends have matching IKE
proposals.
2. Modify the IKE proposal configuration to make sure the two ends have matching IKE proposals.

IKE negotiation failed because no IKE proposals or IKE

keychains are specified correctly
Symptom
1. The IKE SA is in Unknown state.
<Sysname> display ike sa
Connection-ID Remote Flag DOI
------------------------------------------------------------------
1 192.168.222.5 Unknown IPsec
Flags:
RD--READY RL--REPLACED FD-FADING RK-REKEY
2. The following IKE event debugging or packet debugging message appeared:
IKE event debugging message:
Notification PAYLOAD_MALFORMED is received.
IKE packet debugging message:
Construct notification packet: PAYLOAD_MALFORMED.

Analysis
• If the following debugging information appeared, the matched IKE profile is not using the
matched IKE proposal:
Failed to find proposal 1 in profile profile1.
• If the following debugging information appeared, the matched IKE profile is not using the
matched IKE keychain:
Failed to find keychain keychain1 in profile profile1.

Solution
• Verify that the matched IKE proposal (IKE proposal 1 in this debugging message example) is
specified for the IKE profile (IKE profile 1 in the example).

457
 • Verify that the matched IKE keychain (IKE keychain 1 in this debugging message example) is
specified for the IKE profile (IKE profile 1 in the example).

IPsec SA negotiation failed because no matching IPsec

transform sets were found
Symptom
1. The display ike sa command shows that the IKE SA negotiation succeeded and the IKE
SA is in RD state, but the display ipsec sa command shows that the expected IPsec SA
has not been negotiated yet.
2. The following IKE debugging message appeared:
The attributes are unacceptable.
Or:
Construct notification packet: NO_PROPOSAL_CHOSEN.

Analysis
Certain IPsec policy settings are incorrect.
Solution
1. Examine the IPsec configuration to see whether the two ends have matching IPsec transform
sets.
2. Modify the IPsec configuration to make sure the two ends have matching IPsec transform sets.

IPsec SA negotiation failed due to invalid identity information

Symptom
1. The display ike sa command shows that the IKE SA negotiation succeeded and the IKE
SA is in RD state, but the display ipsec sa command shows that the expected IPsec SA
has not been negotiated yet.
2. The following IKE debugging message appeared:
Notification INVALID_ID_INFORMATION is received.
Or:
Failed to get IPsec policy when renegotiating IPsec SA. Delete IPsec SA.
Construct notification packet: INVALID_ID_INFORMATION.

Analysis
Certain IPsec policy settings of the responder are incorrect. Verify the settings as follows:
1. Use the display ike sa verbose command to verify that matching IKE profiles were found
in IKE negotiation phase 1. If no matching IKE profiles were found and the IPsec policy is using
an IKE profile, the IPsec SA negotiation fails.
# Identify whether matching IKE profiles were found in IKE negotiation phase 1. The following
output shows that no matching IKE profile was found:
<Sysname> display ike sa verbose
-----------------------------------------------
Connection ID: 3
Outside VPN:
Inside VPN:
Profile:
Transmitting entity: Responder

458
 -----------------------------------------------
Local IP: 192.168.222.5
Local ID type: IPV4_ADDR
Local ID: 192.168.222.5

Remote IP: 192.168.222.71

Remote ID type: IPV4_ADDR
Remote ID: 192.168.222.71

Authentication-method: PRE-SHARED-KEY
Authentication-algorithm: MD5
Encryption-algorithm: 3DES-CBC

Life duration(sec): 86400

Remaining key duration(sec): 85847
Exchange-mode: Main
Diffie-Hellman group: Group 1
NAT traversal: Not detected
# Identify whether the IPsec policy is using an IKE profile. The following output shows that the
IPsec policy is using an IKE profile.
[Sysname] display ipsec policy
-------------------------------------------
IPsec Policy: policy1
Interface: GigabitEthernet1/0/1
-------------------------------------------

-----------------------------
Sequence number: 1
Mode: ISAKMP
-----------------------------
Description:
Security data flow: 3000
Selector mode: aggregation
Local address: 192.168.222.5
Remote address: 192.168.222.71
Transform set: transform1
IKE profile: profile1
SA duration(time based):
SA duration(traffic based):
SA idle time:
2. Verify that the ACL specified for the IPsec policy is correctly configured. If the flow range
defined by the responder's ACL is smaller than that defined by the initiator's ACL, IPsec
proposal matching will fail.
For example, if the initiator's ACL defines a flow from one network segment to another but the
responder's ACL defines a flow from one host to another host, IPsec proposal matching will fail.
# On the initiator:
[Sysname] display acl 3000
Advanced IPv4 ACL 3000, 1 rule,
ACL's step is 5

459
 rule 0 permit ip source 192.168.222.0 0.0.0.255 destination 192.168.222.0 0.0.0.255
# On the responder:
[Sysname] display acl 3000
Advanced IPv4 ACL 3000, 1 rule,
ACL's step is 5
rule 0 permit ip source 192.168.222.71 0 destination 192.168.222.5 0
3. Verify that the IPsec policy has a remote address and an IPsec transform set configured and
that the IPsec transform set has all necessary settings configured.
If, for example, the IPsec policy has no remote address configured, the IPsec SA negotiation
will fail:
[Sysname] display ipsec policy
-------------------------------------------
IPsec Policy: policy1
Interface: GigabitEthernet1/0/1
-------------------------------------------

-----------------------------
Sequence number: 1
Mode: ISAKMP
-----------------------------
Security data flow: 3000
Selector mode: aggregation
Local address: 192.168.222.5
Remote address:
Transform set: transform1
IKE profile: profile1
SA duration(time based):
SA duration(traffic based):
SA idle time:

Solution
1. If the IPsec policy specifies an IKE profile but no matching IKE profiles was found in IKE
negotiation, perform one of the following tasks on the responder:
 Remove the specified IKE profile from the IPsec policy.
 Modify the specified IKE profile to match the IKE profile of the initiator.
2. If the flow range defined by the responder's ACL is smaller than that defined by the initiator's
ACL, modify the responder's ACL so the ACL defines a flow range equal to or greater than that
of the initiator's ACL.
For example:
[Sysname] display acl 3000
Advanced IPv4 ACL 3000, 2 rules,
ACL's step is 5
rule 0 permit ip source 192.168.222.0 0.0.0.255 destination 192.168.222.0 0.0.0.255
3. Configure the missing settings (for example, the remote address).

460
Configuring IKEv2
About IKEv2
Internet Key Exchange version 2 (IKEv2) is an enhanced version of IKEv1. The same as IKEv1,
IKEv2 has a set of self-protection mechanisms and can be used on insecure networks for reliable
identity authentication, key distribution, and IPsec SA negotiation. IKEv2 provides stronger
protection against attacks and higher key exchange ability and needs fewer message exchanges
than IKEv1.

IKEv2 negotiation process

Compared with IKEv1, IKEv2 simplifies the negotiation process and is much more efficient.
IKEv2 defines three types of exchanges: initial exchanges, CREATE_CHILD_SA exchange, and
INFORMATIONAL exchange.
As shown in Figure 114, IKEv2 uses two exchanges during the initial exchange process:
IKE_SA_INIT and IKE_AUTH, each with two messages.
• IKE_SA_INIT exchange—Negotiates IKE SA parameters and exchanges keys.
• IKE_AUTH exchange—Authenticates the identity of the peer and establishes IPsec SAs.
After the four-message initial exchanges, IKEv2 sets up one IKE SA and one pair of IPsec SAs. For
IKEv1 to set up one IKE SA and one pair of IPsec SAs, it must go through two phases that use a
minimum of six messages.
To set up one more pair of IPsec SAs within the IKE SA, IKEv2 goes on to perform an additional
two-message exchange—the CREATE_CHILD_SA exchange. One CREATE_CHILD_SA exchange
creates one pair of IPsec SAs. IKEv2 also uses the CREATE_CHILD_SA exchange to rekey IKE
SAs and Child SAs.
IKEv2 uses the INFORMATIONAL exchange to convey control messages about errors and
notifications.
Figure 114 IKEv2 Initial exchange process

Peer 1 Peer 2

Send the local Negotiate algorithms

IKE policy and
Initiator's policy and key Generate the key
key info
information
Search for a
matched policy
SA exchange
Confirmed policy and and generate
Key exchange the key
key information

Receive the
policy and Initiator's identity, Authenticate the identity
generate the key authentication data, and
Negotiate IPsec SAs
IPsec transform sets

ID exchange and Responder's identity, Perform ID and exchange

authentication authentication data, and authentication and
IPsec SA setup IPsec transform sets negotiate IPsec SAs

Perform ID and exchange

authentication and
negotiate IPsec SAs

461
New features in IKEv2
DH guessing
In the IKE_SA_INIT exchange, the initiator guesses the DH group that the responder is most likely to
use and sends it in an IKE_SA_INIT request message. If the initiator's guess is correct, the
responder responds with an IKE_SA_INIT response message and the IKE_SA_INIT exchange is
finished. If the guess is wrong, the responder responds with an INVALID_KE_PAYLOAD message
that contains the DH group that it wants to use. The initiator then uses the DH group selected by the
responder to reinitiate the IKE_SA_INIT exchange. The DH guessing mechanism allows for more
flexible DH group configuration and enables the initiator to adapt to different responders.
Cookie challenging
Messages for the IKE_SA_INIT exchange are in plain text. An IKEv1 responder cannot confirm the
validity of the initiators and must maintain half-open IKE SAs, which makes the responder
susceptible to DoS attacks. An attacker can send a large number of IKE_SA_INIT requests with
forged source IP addresses to the responder, exhausting the responder's system resources.
IKEv2 introduces the cookie challenging mechanism to prevent such DoS attacks. When an IKEv2
responder maintains a threshold number of half-open IKE SAs, it starts the cookie challenging
mechanism. The responder generates a cookie and includes it in the response sent to the initiator. If
the initiator initiates a new IKE_SA_INIT request that carries the correct cookie, the responder
considers the initiator valid and proceeds with the negotiation. If the carried cookie is incorrect, the
responder terminates the negotiation.
The cookie challenging mechanism automatically stops working when the number of half-open IKE
SAs drops below the threshold.
IKEv2 SA rekeying
For security purposes, both IKE SAs and IPsec SAs have a lifetime and must be rekeyed when the
lifetime expires. An IKEv1 SA lifetime is negotiated. An IKEv2 SA lifetime, in contrast, is configured. If
two peers are configured with different lifetimes, the peer with the shorter lifetime always initiates the
SA rekeying. This mechanism reduces the possibility that two peers will simultaneously initiate a
rekeying. Simultaneous rekeying results in redundant SAs and SA status inconsistency on the two
peers.
IKEv2 message retransmission
Unlike IKEv1 messages, IKEv2 messages appear in request/response pairs. IKEv2 uses the
Message ID field in the message header to identify the request/response pair. If an initiator sends a
request but receives no response with the same Message ID value within a specific period of time,
the initiator retransmits the request.
It is always the IKEv2 initiator that initiates the retransmission, and the retransmitted message must
use the same Message ID value.

Protocols and standards

• RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)
• RFC 4306, Internet Key Exchange (IKEv2) Protocol
• RFC 4718, IKEv2 Clarifications and Implementation Guidelines
• RFC 2412, The OAKLEY Key Determination Protocol
• RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2)

IKEv2 tasks at a glance

To configure IKEv2, perform the following tasks:

462
 1. Configuring an IKEv2 profile
a. Creating an IKEv2 profile
b. Specifying the local and remote identity authentication methods
c. Configuring the IKEv2 keychain or PKI domain
d. Configuring the local ID for the IKEv2 profile
e. Configuring peer IDs for the IKEv2 profile
f. Specifying a VPN instance for the IKEv2 profile
g. Specifying an inside VPN instance for the IKEv2 profile
h. Configuring optional features for the IKEv2 profile
2. Configuring an IKEv2 policy
3. Configuring an IKEv2 proposal
If you specify an IKEv2 proposal in an IKEv2 policy, you must configure the IKEv2 proposal.
4. Configuring an IKEv2 keychain
This task is required when either end or both ends use the preshared key authentication
method.
5. (Optional.) Enabling the cookie challenging feature
The cookie challenging feature takes effect only on IKEv2 responders.
6. (Optional.) Configuring the IKEv2 DPD feature
7. (Optional.) Configuring the IKEv2 NAT keepalive feature

Prerequisites for IKEv2 configuration

Determine the following parameters prior to IKEv2 configuration:
• The strength of the algorithms for IKEv2 negotiation, including the encryption algorithms,
integrity protection algorithms, PRF algorithms, and DH groups. Different algorithms provide
different levels of protection. A stronger algorithm means better resistance to decryption of
protected data but requires more resources. Typically, the longer the key, the stronger the
algorithm.
• The local and remote identity authentication methods.
 To use the preshared key authentication method, you must determine the preshared key.
 To use the RSA digital signature authentication method, you must determine the PKI
domain for the local end to use. For information about PKI, see "Configuring PKI."

Configuring an IKEv2 profile

Creating an IKEv2 profile
About this task
An IKEv2 profile is intended to provide a set of parameters for IKEv2 negotiation.
Procedure
1. Enter system view.
system-view
2. Create an IKEv2 profile and enter its view.
ikev2 profile profile-name

463
Specifying the local and remote identity authentication
methods
Restrictions and guidelines
The local and remote identity authentication methods must both be specified and they can be
different. You can specify only one local identity authentication method and multiple remote identity
authentication methods.
Procedure
1. Enter system view.
system-view
2. Enter IKEv2 profile view.
ikev2 profile profile-name
3. Specify the local and remote identity authentication methods.
authentication-method { local | remote } { dsa-signature |
ecdsa-signature | pre-share | rsa-signature }
By default, no local or remote identity authentication method is configured.

Configuring the IKEv2 keychain or PKI domain

Restrictions and guidelines
Configure the IKEv2 keychain or PKI domain for the IKEv2 profile to use. To use digital signature
authentication, configure a PKI domain. To use preshared key authentication, configure an IKEv2
keychain.
Procedure
1. Enter system view.
system-view
2. Enter IKEv2 profile view.
ikev2 profile profile-name
3. Specify the keychain for preshared key authentication or the PKI domain used to request a
certificate for digital signature authentication.
 Specify the keychain.
keychain keychain-name
 Specify the PKI domain.
certificate domain domain-name [ sign | verify ]
By default, no IKEv2 keychain or PKI domain is specified for an IKEv2 profile.

Configuring the local ID for the IKEv2 profile

Restrictions and guidelines
For digital signature authentication, the device can use an ID of any type. If the local ID is an IP
address that is different from the IP address in the local certificate, the device uses the FQDN as the
local ID. The FQDN is the device name configured by using the sysname command.
For preshared key authentication, the device can use an ID of any type other than the DN.

464
Procedure
1. Enter system view.
system-view
2. Enter IKEv2 profile view.
ikev2 profile profile-name
3. Configure the local ID.
identity local { address { ipv4-address | ipv6 ipv6-address } | dn |
email email-string | fqdn fqdn-name | key-id key-id-string }
By default, no local ID is configured, and the device uses the IP address of the interface where
the IPsec policy applies as the local ID.

Configuring peer IDs for the IKEv2 profile

About this task
Perform this task to configure the peer ID for IKEv2 profile matching. When the device needs to
select an IKEv2 profile for IKEv2 negotiation with a peer, it compares the received peer ID with the
peer IDs of its local IKE profiles. If a match is found, it uses the IKEv2 profile with the matching peer
ID for negotiation. IKEv2 profiles will be compared in descending order of their priorities.
Procedure
1. Enter system view.
system-view
2. Enter IKEv2 profile view.
ikev2 profile profile-name
3. Configure a peer ID.
match remote { certificate policy-name | identity { address
{ { ipv4-address [ mask | mask-length ] | range low-ipv4-address
high-ipv4-address } | ipv6 { ipv6-address [ prefix-length ] | range
low-ipv6-address high-ipv6-address } } | fqdn fqdn-name | email
email-string | key-id key-id-string } }
You must configure a minimum of one peer ID on each of the two peers.

Specifying a VPN instance for the IKEv2 profile

About this task
After you specify a VPN instance for an IKEv2 profile, the IKEv2 profile can be used for IKEv2
negotiation only on the interfaces that belong to the VPN instance.
Procedure
1. Enter system view.
system-view
2. Enter IKEv2 profile view.
ikev2 profile profile-name
3. Specify a VPN instance for the IKEv2 profile.
match vrf { name vrf-name | any }
By default, an IKEv2 profile belongs to the public network.

465
Specifying an inside VPN instance for the IKEv2 profile
About this task
The inside VPN instance determines where the device should forward received IPsec packets after it
de-encapsulates the packets. If you specify an inside VPN instance, the device looks for a route in
the specified VPN instance to forward the packets. If you do not specify an inside VPN instance, the
internal and external networks are in the same VPN instance. The device looks for a route in this
VPN instance to forward the packets.
Restrictions and guidelines
The inside VPN instance specified in an IKEv2 profile takes effect only on IPsec policies that use the
IKEv2 profile. It does not take effect on IPsec profiles that use the IKEv2 profile.
Procedure
1. Enter system view.
system-view
2. Enter IKEv2 profile view.
ikev2 profile profile-name
3. Specify an inside VPN instance.
inside-vrf vrf-name
By default, no inside VPN instance is specified for an IKEv2 profile. The internal and external
networks are in the same VPN instance. The device forwards protected data to this VPN
instance.

Configuring optional features for the IKEv2 profile

1. Enter system view.
system-view
2. Enter IKEv2 profile view.
ikev2 profile profile-name
3. Configure optional features as needed.
 Configure IKEv2 DPD.
dpd interval interval [ retry seconds ] { on-demand | periodic }
By default, IKEv2 DPD is not configured for an IKEv2 profile and an IKEv2 profile uses the
DPD settings configured in system view. If IKEv2 DPD is not configured in system view
either, the device does not perform dead IKEv2 peer detection.
 Specify the local interface or IP address to which the IKEv2 profile can be applied.
match local address { interface-type interface-number |
ipv4-address | ipv6 ipv6-address }
By default, an IKEv2 profile can be applied to any local interface or local IP address.
Use this command to specify which address or interface can use the IKEv2 profile for IKEv2
negotiation. Specify the local address configured in IPsec policy or IPsec policy template
view (using the local-address command) for this command. If no local address is
configured, specify the IP address of the interface that uses the IPsec policy.
 Specify a priority for the IKEv2 profile.
priority priority
By default, the priority of an IKEv2 profile is 100.

466
 When the device needs to select an IKEv2 profile for IKEv2 negotiation with a peer, it
compares the received peer ID with the peer ID of its local IKEv2 profiles in descending
order of their priorities
 Set the IKEv2 SA lifetime for the IKEv2 profile.
sa duration seconds
By default, the IKEv2 SA lifetime is 86400 seconds.
The local and remote ends can use different IKEv2 SA lifetimes and they do not negotiate
the lifetime. The end with a smaller SA lifetime will initiate an SA negotiation when the
lifetime expires.
 Set the IKEv2 NAT keepalive interval.
nat-keepalive seconds
By default, the global IKEv2 NAT keepalive setting is used.
Configure this command when the device is behind a NAT gateway. The device sends NAT
keepalive packets regularly to its peer to prevent the NAT session from being aged because
of no matching traffic.
 Enable the configuration exchange feature.
config-exchange { request | set { accept | send } }
By default, all configuration exchange options are disabled.
This feature applies to scenarios where the headquarters and branches communicate
through virtual tunnels. It enables exchanges of IP address request and set messages
between the IPsec gateway at a branch and the IPsec gateway at the headquarters.
Table 32 Parameter descriptions

Parameter Description
Enables the IPsec gateway at a branch to submit IP address request messages to
request
the IPsec gateway at the headquarters.

set Enables the IPsec gateway at a branch to accept the IP addresses pushed by the
accept IPsec gateway at the headquarters.

Enables the IPsec gateway at the headquarters to push IP addresses to IPsec

set send
gateways at branches.

Configuring an IKEv2 policy

About this task
During the IKE_SA_INIT exchange, each end tries to find a matching IKEv2 policy, using the IP
address of the local security gateway as the matching criterion.
• If IKEv2 policies are configured, IKEv2 searches for an IKEv2 policy that uses the IP address of
the local security gateway. If no IKEv2 policy uses the IP address or the policy is using an
incomplete proposal, the IKE_SA_INIT exchange fails.
• If no IKEv2 policy is configured, IKEv2 uses the system default IKEv2 policy default.
The device matches IKEv2 policies in the descending order of their priorities. To determine the
priority of an IKEv2 policy:
1. First, the device examines the existence of the match local address command. An IKEv2
policy with the match local address command configured has a higher priority.
2. If a tie exists, the device compares the priority numbers. An IKEv2 policy with a smaller priority
number has a higher priority.
3. If a tie still exists, the device prefers an IKEv2 policy configured earlier.

467
Procedure
1. Enter system view.
system-view
2. Create an IKEv2 policy and enter its view.
ikev2 policy policy-name
By default, an IKEv2 policy named default exists.
3. Specify the local interface or address used for IKEv2 policy matching.
match local address { interface-type interface-number | ipv4-address |
ipv6 ipv6-address }
By default, no local interface or address is used for IKEv2 policy matching, and the policy
matches any local interface or address.
4. Specify a VPN instance for IKEv2 policy matching.
match vrf { name vrf-name | any }
By default, no VPN instance is specified for IKEv2 policy matching. The IKEv2 policy matches
all local addresses in the public network.
5. Specify an IKEv2 proposal for the IKEv2 policy.
proposal proposal-name
By default, no IKEv2 proposal is specified for an IKEv2 policy.
6. Specify a priority for the IKEv2 policy.
priority priority
By default, the priority of an IKEv2 policy is 100.

Configuring an IKEv2 proposal

About this task
An IKEv2 proposal contains security parameters used in IKE_SA_INIT exchanges, including the
encryption algorithms, integrity protection algorithms, PRF algorithms, and DH groups. An algorithm
specified earlier has a higher priority.
Restrictions and guidelines
A complete IKEv2 proposal must have at least one set of security parameters, including one
encryption algorithm, one integrity protection algorithm, one PRF algorithm, and one DH group.
You can specify multiple IKEv2 proposals for an IKEv2 policy. A proposal specified earlier has a
higher priority.
Procedure
1. Enter system view.
system-view
2. Create an IKEv2 proposal and enter its view.
ikev2 proposal proposal-name
By default, an IKEv2 proposal named default exists.
In non-FIPS mode, the default proposal uses the following settings:
 Encryption algorithms AES-CBC-128 and 3DES.
 Integrity protection algorithms HMAC-SHA1 and HMAC-MD5.
 PRF algorithms HMAC-SHA1 and HMAC-MD5.
 DH groups 2 and 5.

468
 In FIPS mode, the default proposal uses the following settings:
 Encryption algorithms AES-CBC-128 and AES-CTR-128.
 Integrity protection algorithms HMAC-SHA1 and HMAC-SHA256.
 PRF algorithms HMAC-SHA1 and HMAC-SHA256.
 DH groups 14 and 19.
3. Specify the encryption algorithms.
In non-FIPS mode:
encryption { 3des-cbc | aes-cbc-128 | aes-cbc-192 | aes-cbc-256 |
aes-ctr-128 | aes-ctr-192 | aes-ctr-256 | camellia-cbc-128 |
camellia-cbc-192 | camellia-cbc-256 | des-cbc } *
In FIPS mode:
encryption { aes-cbc-128 | aes-cbc-192 | aes-cbc-256 | aes-ctr-128 |
aes-ctr-192 | aes-ctr-256 } *
By default, an IKEv2 proposal does not have any encryption algorithms.
4. Specify the integrity protection algorithms.
In non-FIPS mode:
integrity { aes-xcbc-mac | md5 | sha1 | sha256 | sha384 | sha512 }
*
In FIPS mode:
integrity { sha1 | sha256 | sha384 | sha512 } *
By default, an IKEv2 proposal does not have any integrity protection algorithms.
5. Specify the DH groups.
In non-FIPS mode:
dh { group1 | group14 | group2 | group24 | group5 | group19 | group20 } *
In FIPS mode:
dh { group14 | group19 | group20 } *
By default, an IKEv2 proposal does not have any DH groups.
6. Specify the PRF algorithms.
In non-FIPS mode:
prf { aes-xcbc-mac | md5 | sha1 | sha256 | sha384 | sha512 } *
In FIPS mode:
prf { sha1 | sha256 | sha384 | sha512 } *
By default, an IKEv2 proposal uses the integrity protection algorithms as the PRF algorithms.

Configuring an IKEv2 keychain

About this task
An IKEv2 keychain specifies the preshared keys used for IKEv2 negotiation.
An IKEv2 keychain can have multiple IKEv2 peers. Each peer has a symmetric preshared key or an
asymmetric preshared key pair, and information for identifying the peer (such as the peer's host
name, IP address or address range, or ID).
An IKEv2 negotiation initiator uses the peer host name or IP address/address range as the matching
criterion to search for a peer. A responder uses the peer host IP address/address range or ID as the
matching criterion to search for a peer.

469
Procedure
1. Enter system view.
system-view
2. Create an IKEv2 keychain and enter its view.
ikev2 keychain keychain-name
3. Create an IKEv2 peer and enter its view.
peer name
4. Configure a host name for the peer:
hostname name
By default, no host name is configured for an IKEv2 peer.
5. Configure a host IP address or address range for the peer:
address { ipv4-address [ mask | mask-length ] | ipv6 ipv6-address
[ prefix-length ] }
By default, no host IP address or address range is configured for an IKEv2 peer.
You must configure different host IP addresses/address ranges for different peers.
6. Configure an ID for the peer:
identity { address { ipv4-address | ipv6 { ipv6-address } } | fqdn
fqdn-name | email email-string | key-id key-id-string }
By default, no identity information is configured for an IKEv2 peer.
7. Configure a preshared key for the peer.
pre-shared-key [ local | remote ] { ciphertext | plaintext } string
By default, an IKEv2 peer does not have a preshared key.

Configure global IKEv2 parameters

Enabling the cookie challenging feature
About this task
Enable cookie challenging on responders to protect them against DoS attacks that use a large
number of source IP addresses to forge IKE_SA_INIT requests.
Procedure
1. Enter system view.
system-view
2. Enable IKEv2 cookie challenging.
ikev2 cookie-challenge number
By default, IKEv2 cookie challenging is disabled.

Configuring the IKEv2 DPD feature

About this task
IKEv2 DPD detects dead IKEv2 peers in periodic or on-demand mode.
• Periodic IKEv2 DPD—Verifies the liveness of an IKEv2 peer by sending DPD messages at
regular intervals.

470
 • On-demand IKEv2 DPD—Verifies the liveness of an IKEv2 peer by sending DPD messages
before sending data.
 Before the device sends data, it identifies the time interval for which the last IPsec packet
has been received from the peer. If the time interval exceeds the DPD interval, it sends a
DPD message to the peer to detect its liveliness.
 If the device has no data to send, it never sends DPD messages.
Restrictions and guidelines
If you configure IKEv2 DPD in both IKEv2 profile view and system view, the IKEv2 DPD settings in
IKEv2 profile view apply. If you do not configure IKEv2 DPD in IKEv2 profile view, the IKEv2 DPD
settings in system view apply.
Procedure
1. Enter system view.
system-view
2. Configure global IKEv2 DPD.
ikev2 dpd interval interval [ retry seconds ] { on-demand | periodic }
By default, global DPD is disabled.

Configuring the IKEv2 NAT keepalive feature

About this task
Configure this feature on the IKEv2 gateway behind the NAT device. The gateway then sends NAT
keepalive packets regularly to its peer to keep the NAT session alive, so that the peer can access the
device.
The NAT keepalive interval must be shorter than the NAT session lifetime.
This feature takes effect after the device detects the NAT device.
Procedure
1. Enter system view.
system-view
2. Set the IKEv2 NAT keepalive interval.
ikev2 nat-keepalive seconds
By default, the IKEv2 NAT keepalive interval is 10 seconds.

Display and maintenance commands for IKEv2

Execute display commands in any view and reset commands in user view.

Task Command
display ikev2 policy [ policy-name |
Display the IKEv2 policy configuration.
default ]
display ikev2 profile
Display the IKEv2 profile configuration.
[ profile-name ]
display ikev2 proposal [ name |
Display the IKEv2 proposal configuration.
default ]

471
 Task Command
display ikev2 sa [ count | [ { local |
remote } { ipv4-address | ipv6
Display the IKEv2 SA information. ipv6-address } [ vpn-instance
vpn-instance-name ] ] [ verbose
[ tunnel tunnel-id ] ] ]
Display IKEv2 statistics. display ikev2 statistics
reset ikev2 sa [ [ { local | remote }
{ ipv4-address | ipv6
Delete IKEv2 SAs and the child SAs negotiated
ipv6-address } [ vpn-instance
through the IKEv2 SAs.
vpn-instance-name ] ] | tunnel
tunnel-id ] [ fast ]
Clear IKEv2 statistics. reset ikev2 statistics

Troubleshooting IKEv2
IKEv2 negotiation failed because no matching IKEv2
proposals were found
Symptom
The IKEv2 SA is in IN-NEGO status.
<Sysname> display ikev2 sa
Tunnel ID Local Remote Status
---------------------------------------------------------------------------
5 123.234.234.124/500 123.234.234.123/500 IN-NEGO
Status:
IN-NEGO: Negotiating, EST: Established, DEL:Deleting

Analysis
Certain IKEv2 proposal settings are incorrect.
Solution
1. Examine the IKEv2 proposal configuration to see whether the two ends have matching IKEv2
proposals.
2. Modify the IKEv2 proposal configuration to make sure the two ends have matching IKEv2
proposals.

IPsec SA negotiation failed because no matching IPsec

transform sets were found
Symptom
The display ikev2 sa command shows that the IKEv2 SA negotiation succeeded and the IKEv2
SA is in EST status. The display ipsec sa command shows that the expected IPsec SAs have
not been negotiated yet.
Analysis
Certain IPsec policy settings are incorrect.

472
Solution
1. Examine the IPsec configuration to see whether the two ends have matching IPsec transform
sets.
2. Modify the IPsec configuration to make sure the two ends have matching IPsec transform sets.

IPsec tunnel establishment failed

Symptom
The ACLs and IKEv2 proposals are correctly configured on both ends. The two ends cannot
establish an IPsec tunnel or cannot communicate through the established IPsec tunnel.
Analysis
The IKEv2 SA or IPsec SAs on either end are lost. The reason might be that the network is unstable
and the device reboots.
Solution
1. Use the display ikev2 sa command to examine whether an IKEv2 SA exists on both ends.
If the IKEv2 SA on one end is lost, delete the IKEv2 SA on the other end by using the reset
ikev2 sa command and trigger new negotiation. If an IKEv2 SA exists on both ends, go to the
next step.
2. Use the display ipsec sa command to examine whether IPsec SAs exist on both ends. If
the IPsec SAs on one end are lost, delete the IPsec SAs on the other end by using the reset
ipsec sa command and trigger new negotiation.

473
Configuring SSH
About SSH
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 establish 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.

SSH applications
The device supports the following SSH applications:
• Secure Telnet—Stelnet provides secure and reliable network terminal access services.
Through Stelnet, a user can securely log in to a remote server. Stelnet can protect devices
against attacks, such as IP spoofing 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. The device can act as an SFTP server, allowing a remote user to log in to
the SFTP server for secure file management and transfer. The device can also act as an SFTP
client, enabling a user to log in from the device to a remote device for secure file transfer.
• Secure Copy—Based on SSH2, SCP offers a secure method to copy files. The device can act
as an SCP server, allowing a user to log in to the device for file upload and download. The
device can also act as an SCP client, enabling a user to log in from the device to a remote
device for secure file transfer.
• NETCONF over SSH—Based on SSH2, it enables users to securely log in to the device
through SSH and perform NETCONF operations on the device through the
NETCONF-over-SSH connections. The device can act only as a NETCONF-over-SSH server.
For more information about NETCONF, see Network Management and Monitoring
Configuration Guide.
When acting as an SSH server or client, the device supports the following SSH versions:
• 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.
• When acting as an SSH client, the device supports only SSH2.
• When acting as a NETCONF-over-SSH server, the device supports only SSH2.

How SSH works

This section uses SSH2 as an example to describe the stages to establish an SSH session.
Table 33 Stages to establish an SSH session

Stages Description
The SSH server listens to connection requests on port 22. After a client
Connection establishment initiates a connection request, the server and the client establish a
TCP connection.

Version negotiation The two parties determine a version to use.

474
 Stages Description
SSH supports multiple algorithms. Based on the local algorithms, the
two parties negotiate the following algorithms:
• Key exchange algorithm for generating session keys.
Algorithm negotiation
• Encryption algorithm for encrypting data.
• Public key algorithm for the digital signature and authentication.
• HMAC algorithm for protecting data integrity.
The two parties use the DH exchange algorithm to dynamically
generate the session keys and session ID.
Key exchange • The session keys are used for protecting data transfer.
• The session ID is used for identifying the SSH connection.
In this stage, the client also authenticates the server.
The SSH server authenticates the client in response to the client's
Authentication
authentication request.
After passing the authentication, the client sends a session request to
Session request the server to request the establishment of a session (or request the
Stelnet, SFTP, SCP, or NETCONF service).

After the server grants the request, the client and the server start to
communicate with each other in the session.
In this stage, you can paste commands in text format and execute
them at the CLI. The text pasted at one time must be no more than
Interaction 2000 bytes. As a best practice to ensure the correct execution of
commands, paste commands that are in the same view.
To execute commands of more than 2000 bytes, save the commands
in a configuration file, upload the file to the server through SFTP, and
use it to restart the server.

SSH authentication methods

This section describes authentication methods that are supported by the device when it acts as an
SSH server.
Password authentication
The SSH server authenticates a client through the AAA mechanism. The password authentication
process is as follows:
1. The client sends the server an authentication request that includes the encrypted username
and password.
2. The server performs the following operations:
a. Decrypts the request to get the username and password in plain text.
b. Verifies the username and password locally or through remote AAA authentication.
c. Informs the client of the authentication result.
If the remote AAA server requires the user to enter a password for secondary authentication, it send
the SSH server an authentication response carrying a prompt. The prompt is transparently
transmitted to the client to notify the user to enter a specific password. When the user enters the
correct password, the AAA sever examines the password validity. If the password is valid, the SSH
server returns an authentication success message to the client.
SSH1 clients do not support secondary password authentication initiated by the AAA server.
For more information about AAA, see "Configuring AAA."

475
Keyboard-interactive authentication
In keyboard-interactive authentication, the remote authentication server and user exchanges
information for authentication as follows:
1. The remote authentication server sends a prompt to the SSH server in an authentication
response.
The prompt indicates the information required to be provided by the user.
2. The SSH server transparently transmits the prompt to the client terminal.
3. The user enters the required information as prompted.
This process repeats multiple times if the remote authentication server requires more interactive
information. The remote authentication server returns an authentication success message after the
user provides all required interactive information.
If the remote authentication server does not require interactive information, the keyboard-interactive
authentication process is the same as the password authentication.
Publickey authentication
The server authenticates a client by verifying the digital signature of the client. The publickey
authentication process is as follows:
1. The client sends the server a publickey authentication request that includes the username,
public key, and public key algorithm name.
If the digital certificate of the client is required in authentication, the client also encapsulates the
digital certificate in the authentication request. The digital certificate carries the public key
information of the client.
2. The server verifies the client's public key.
 If the public key is invalid, the server informs the client of the authentication failure.
 If the public key is valid, the server requests the digital signature of the client. After receiving
the signature, the server uses the public key to verify the signature and informs the client of
the authentication result.
When acting as an SSH server, the device supports using the public key algorithms DSA, ECDSA,
and RSA to verify digital signatures.
When acting as an SSH client, the device supports using the public key algorithms DSA, ECDSA,
and RSA to generate digital signatures.
For more information about public key configuration, see "Managing public keys."
Password-publickey authentication
The server requires SSH2 clients to pass both password authentication and publickey authentication.
However, an SSH1 client only needs to pass either authentication.
Any authentication
The server requires clients to pass keyboard-interactive authentication, password authentication, or
publickey authentication. Success with any one authentication method is sufficient to connect to the
server.

SSH support for Suite B

Suite B contains a set of encryption and authentication algorithms that meet high security
requirements. Table 34 lists all algorithms in Suite B.
The SSH server and client support using the X.509v3 certificate for identity authentication in
compliance with the algorithm, negotiation, and authentication specifications defined in RFC 6239.

476
 Table 34 Suite B algorithms

Security Key exchange Encryption algorithm

Public key algorithm
level algorithm and HMAC algorithm
128-bit ecdh-sha2-nistp256 AES128-GCM x509v3-ecdsa-sha2-nistp256
192-bit ecdh-sha2-nistp384 AES256-GCM x509v3-ecdsa-sha2-nistp384
ecdh-sha2-nistp256 AES128-GCM x509v3-ecdsa-sha2-nistp256
Both
ecdh-sha2-nistp384 AES256-GCM x509v3-ecdsa-sha2-nistp384

FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for
features, commands, and parameters might differ in FIPS mode and non-FIPS mode. For more
information about FIPS mode, see "Configuring FIPS."

Configuring the device as an SSH server

SSH server tasks at a glance
To configure an SSH server, perform the following tasks:
1. Generating local key pairs
2. (Optional.) Specifying the SSH service port
3. Enabling the SSH server
 Enabling the Stelnet server
 Enabling the SFTP server
 Enabling the SCP server
 Enabling NETCONF over SSH
4. Configuring the user lines for SSH login
Required only for Stelnet and NETCONF-over-SSH servers.
5. Configuring a client's host public key
Required for authentication method publickey, password-publickey, or any.
6. Configuring an SSH user
 Required for authentication method keyboard-interactive, publickey,
password-publickey, or any.
 Optional for the password authentication method.
7. (Optional.) Configuring the SSH management parameters
SSH management settings, such as authentication and connection control settings, help
improve security of SSH connections.
8. (Optional.) Specifying a PKI domain for the SSH server
9. (Optional.) Disconnecting SSH sessions

477
Generating local key pairs
About this task
The DSA, ECDSA, or RSA key pairs on the SSH server are required for generating the session keys
and session ID in the key exchange stage. They can also be used by a client to authenticate the
server. When a client authenticates the server, it compares the public key received from the server
with the server's public key that the client saved locally. If the keys are consistent, the client uses the
locally saved server's public key to decrypt the digital signature received from the server. If the
decryption succeeds, the server passes the authentication.
To support SSH clients that use different types of key pairs, generate DSA, ECDSA, and RSA key
pairs on the SSH server.
• RSA key pairs—The SSH server generates a server key pair and a host key pair for RSA. The
RSA server key pair is only used in SSH1 to encrypt the session key for secure transmission of
the session key. It is not used in SSH2, because no session key transmission is required in
SSH2.
• DSA key pair—The SSH server generates only one DSA host key pair. SSH1 does not support
the DSA algorithm.
• ECDSA key pair—The SSH server generates only one ECDSA host key pair.
Restrictions and guidelines
Local DSA, ECDSA, and RSA key pairs for SSH use default names. You cannot assign names to the
key pairs.
If the device does not have RSA key pairs with default names, it automatically generates one RSA
server key pair and one RSA host key pair when SSH starts. Both key pairs use their default names.
The SSH application starts when you execute an SSH server command on the device.
The key modulus length must be less than 2048 bits when you generate the DSA key pair on the
SSH server.
When you generate an ECDSA key pair, you can generate only a secp256r1 or secp384r1 ECDSA
key pair.
The SSH server operating in FIPS mode supports only ECDSA and RSA key pairs. Do not generate
a DSA key pair on the SSH server in FIPS mode.
Procedure
1. Enter system view.
system-view
2. Generate local key pairs.
public-key local create { dsa | ecdsa { secp256r1 | secp384r1 } | rsa }

Specifying the SSH service port

About this task
The default port of the SSH service is 22. You can specify another port for the SSH service to
improve security of SSH connections.
Restrictions and guidelines
If you modify the SSH port number when the SSH server is enabled, the SSH service is restarted and
all SSH connections are terminated after the modification. SSH users must reconnect to the SSH
server to access the server.
If you set the SSH port to a well-known port number, the service that uses the well-known port
number might fail to start. Well-known port numbers are in the range of 1 to 1024.

478
Procedure
1. Enter system view.
system-view
2. Specify the SSH service port.
ssh server port port-number
By default, the SSH service port is 22.

Enabling the Stelnet server

About this task
After you enable the Stelnet server on the device, a client can log in to the device through Stelnet.
Procedure
1. Enter system view.
system-view
2. Enable the Stelnet server.
ssh server enable
By default, the Stelnet server is disabled.

Enabling the SFTP server

About this task
After you enable the SFTP server on the device, a client can log in to the device through SFTP.
Restrictions and guidelines
When acting as an SFTP server, the device does not support SFTP connections initiated by SSH1
clients.
Procedure
1. Enter system view.
system-view
2. Enable the SFTP server.
sftp server enable
By default, the SFTP server is disabled.

Enabling the SCP server

About this task
After you enable the SCP server on the device, a client can log in to the device through SCP.
Restrictions and guidelines
When acting as an SCP server, the device does not support SCP connections initiated by SSH1
clients.
Procedure
1. Enter system view.
system-view
2. Enable the SCP server.

479
 scp server enable
By default, the SCP server is disabled.

Enabling NETCONF over SSH

About this task
After you enable NETCONF over SSH on the device, a client can perform NETCONF operations on
the device through a NETCONF-over-SSH connection.
Restrictions and guidelines
When acting as a server in the NETCONF-over-SSH connection, the device does not support
connection requests initiated by SSH1 clients.
Procedure
1. Enter system view.
system-view
2. Enable NETCONF over SSH.
netconf ssh server enable
By default, NETCONF over SSH is disabled.
For more information about NETCONF over SSH commands, see Network Management and
Monitoring Command Reference.

Configuring the user lines for SSH login

About this task
Depending on the SSH application, an SSH client can be an Stelnet client, SFTP client, SCP client,
or NETCONF-over-SSH client.
Only Stelnet and NETCONF-over-SSH clients require the user line configuration. The user line
configuration takes effect on the clients at the next login.
Procedure
1. Enter system view.
system-view
2. Enter VTY user line view.
line vty number [ ending-number ]
3. Set the login authentication mode to scheme.
authentication-mode scheme
By default, the authentication mode is password.
For more information about this command, see Fundamentals Command Reference.

Configuring a client's host public key

About this task
In publickey authentication, the server compares the SSH username and the client's host public key
received from the client with the locally saved SSH username and the client's host public key. If they
are the same, the server checks the digital signature that the client sends. The client generates the
digital signature by using the private key that is paired with the client's host public key.

480
 For publickey authentication, password-publickey authentication, or any authentication, you must
perform the following tasks:
1. Configure the client's DSA, ECDSA, or RSA host public key on the server.
2. Specify the associated host private key on the client to generate the digital signature.
If the device acts as an SSH client, specify the public key algorithm on the client. The algorithm
determines the associated host private key for generating the digital signature.
Client public key configuration methods
You can configure the client host public key by using the following methods:
• Manually enter the content of a client's host public key on the server.
a. Display the host public key on the client and record the key.
b. Type the client's host public key character by character on the server, or use the copy and
paste method.
The manually entered key must be in DER format without being converted. For the displayed
key to meet the requirement when the client is an HPE device, use the display
public-key local public command. The format of the public key displayed in any other
way (for example, by using the public-key local export command) might be incorrect.
If the key is not in correct format, the system discards the key.
• Import the client host public key from a public key file.
c. Save the client public key file to the server. For example, transfer the client public key file to
the server in binary mode through FTP or TFTP.
d. Import the client public key from the locally saved public key file.
During the import process, the server automatically converts the host public key to a string
in PKCS format.
Restrictions and guidelines
As a best practice, configure no more than 20 SSH client's host public keys on an SSH server.
Import the client's host public key as a best practice.
Entering a client's host public key
1. Enter system view.
system-view
2. Enter public key view.
public-key peer keyname
3. Configure a client's host public key.
Enter the content of the client's host public key character by character, or use the copy and
paste method.
When you enter the content of a client's host public key, you can use spaces and carriage
returns between characters but the system does not save them. For more information, see
"Managing public keys."
4. Exit public key view and save the key.
peer-public-key end
Importing a client's host public key from the public key file
1. Enter system view.
system-view
2. Import a client's public key from the public key file.
public-key peer keyname import sshkey filename

481
Configuring an SSH user
About this task
Configure an SSH user and a local user depending on the authentication method.
• If the authentication method is publickey, you must create an SSH user and a local user on the
SSH server. The two users must have the same username, so that the SSH user can be
assigned the correct working directory and user role.
• If the authentication method is password, you must perform one of the following tasks:
 For local authentication, configure a local user on the SSH server.
 For remote authentication, configure an SSH user on a remote authentication server, for
example, a RADIUS server.
You do not need to create an SSH user by using the ssh user command. However, if you
want to display all SSH users, including the password-only SSH users, for centralized
management, you can use this command to create them. If such an SSH user has been created,
make sure you have specified the correct service type and authentication method.
• If the authentication method is keyboard-interactive, password-publickey, or any, you must
create an SSH user on the SSH server and perform one of the following tasks:
 For local authentication, configure a local user on the SSH server.
 For remote authentication, configure an SSH user on a remote authentication server, for
example, a RADIUS server.
In either case, the local user or the SSH user configured on the remote authentication server
must have the same username as the SSH user.
For information about configuring local users and remote authentication, see "Configuring AAA."
Restrictions and guidelines
If you change the authentication parameters for a logged-in SSH user, the change takes effect on the
user at the next login.
When the device operates as an SSH server in FIPS mode, the device does not support
authentication method any or publickey.
For an SFTP or SCP user, the working directory depends on the authentication method.
• If the authentication method is publickey or password-publickey, the working folder is
specified by the authorization-attribute command in the associated local user view.
• If the authentication method is keyboard-interactive or password, the working directory is
authorized by AAA.
For an SSH user, the user role also depends on the authentication method.
• If the authentication method is publickey or password-publickey, the user role is specified by
the authorization-attribute command in the associated local user view.
• If the authentication method is keyboard-interactive or password, the user role is authorized
by AAA.
For all authentication methods except keyboard-interactive authentication and password
authentication, you must specify a client's host public key or digital certificate.
• For a client that sends the user's public key information directly to the server, specify the client's
host public key on the server. The specified public key must already exist. For more information
about public keys, see "Configuring a client's host public key." If you specify multiple client
public keys, the device verifies the user identity by using the public keys in the order they are
specified. The user is valid if the user passes one public key check.
• For a client that sends the user's public key information to the server through a digital certificate,
specify the PKI domain on the server. This PKI domain verifies the client's digital certificate. For
successful verification, the specified PKI domain must have the correct CA certificate. To

482
 specify the PKI domain, use the ssh user or ssh server pki-domain command. For
more information about configuring a PKI domain, see "Configuring PKI."
Procedure
1. Enter system view.
system-view
2. Create an SSH user, and specify the service type and authentication method.
In non-FIPS mode:
ssh user username service-type { all | netconf | scp | sftp | stelnet }
authentication-type { keyboard-interactive | password | { any |
password-publickey | publickey } [ assign { pki-domain domain-name |
publickey keyname&<1-6> } ] }
In FIPS mode:
ssh user username service-type { all | netconf | scp | sftp | stelnet }
authentication-type { keyboard-interactive | password |
password-publickey [ assign { pki-domain domain-name | publickey
keyname&<1-6> } ] }
An SSH server supports up to 1024 SSH users.

Configuring the SSH management parameters

Enabling the SSH server to support SSH1 clients
1. Enter system view.
system-view
2. Enable the SSH server to support SSH1 clients.
ssh server compatible-ssh1x enable
By default, the SSH server does not support SSH1 clients.
This command is not available in FIPS mode.
Enabling SSH algorithm renegotiation and key re-exchange
1. Enter system view.
system-view
2. Enable SSH algorithm renegotiation and key re-exchange.
ssh server key-re-exchange enable [ interval interval ]
By default, SSH algorithm renegotiation and key re-exchange are disabled.
This command is not available in FIPS mode.
The command takes effect only on new SSH connections that are established after the
command is configured, and it does not affect existing SSH connections.
Setting the minimum interval for updating the RSA server key pair
1. Enter system view.
system-view
2. Set the minimum interval for updating the RSA server key pair.
ssh server rekey-interval interval
By default, the device does not update the RSA server key pair.
This command is not available in FIPS mode.
This configuration takes effect only on SSH1 clients.

483
Setting the SSH user authentication timeout timer
1. Enter system view.
system-view
2. Set the SSH user authentication timeout timer.
ssh server authentication-timeout time-out-value
The default setting is 60 seconds.
Perform this task to prevent malicious occupation of TCP connections. If a user does not finish
the authentication when the timeout timer expires, the connection cannot be established.
Setting the maximum number of SSH authentication attempts
1. Enter system view.
system-view
2. Set the maximum number of SSH authentication attempts.
ssh server authentication-retries retries
The default setting is 3.
Perform this task to prevent malicious hacking of usernames and passwords. If the
authentication method is any, the total number of publickey authentication attempts and
password authentication attempts cannot exceed the upper limit.
Specifying an SSH login control ACL
1. Enter system view.
system-view
2. Specify an SSH login control ACL.
IPv4:
ssh server acl { advanced-acl-number | basic-acl-number | mac
mac-acl-number }
IPv6:
ssh server ipv6 acl { ipv6 { advanced-acl-number | basic-acl-number }
| mac mac-acl-number }
This feature uses an ACL to filter SSH clients that initiate SSH connections to the server. By
default, no ACLs are specified and all SSH users can initiate SSH connections to the server.
Enabling logging for SSH login attempts that are denied by the SSH login control ACL
1. Enter system view.
system-view
2. Enable logging for SSH login attempts that are denied by the SSH login control ACL.
ssh server acl-deny-log enable
By default, logging is disabled for login attempts that are denied by the SSH login control ACL.
This command enables SSH to generate log messages for SSH login attempts that are denied
by the SSH login control ACL and send the messages to the information center.
Setting the DSCP value in the packets that the SSH server sends to SSH clients
1. Enter system view.
system-view
2. Set the DSCP value in the packets that the SSH server sends to the SSH clients.
IPv4:
ssh server dscp dscp-value
IPv6:

484
 ssh server ipv6 dscp dscp-value
By default, the DSCP value of SSH packets is 48.
The DSCP value of a packet defines the priority of the packet and affects the transmission
priority of the packet. A bigger DSCP value represents a higher priority.
Setting the SFTP connection idle timeout timer
1. Enter system view.
system-view
2. Set the SFTP connection idle timeout timer.
sftp server idle-timeout time-out-value
By default, the SFTP connection idle timeout is 10 minutes.
When the SFTP connection idle timeout timer expires, the system automatically tears the
connection down and releases the connection resources.
Setting the maximum number of online SSH users
1. Enter system view.
system-view
2. Set the maximum number of online SSH users.
aaa session-limit ssh max-sessions
The default setting is 32.
When the number of online SSH users reaches the upper limit, the system denies new SSH
connection requests. Changing the upper limit does not affect online SSH users.
For more information about this command, see AAA commands in Security Command
Reference.

Specifying a PKI domain for the SSH server

About this task
The PKI domain specified for the SSH server has the following functions:
• The SSH server uses the PKI domain to send its certificate to the client in the key exchange
stage.
• The SSH server uses the PKI domain to authenticate the client's certificate if no PKI domain is
specified for the client authentication by using the ssh user command.
Procedure
1. Enter system view.
system-view
2. Specify a PKI domain for the SSH server.
ssh server pki-domain domain-name
By default, no PKI domain is specified for the SSH server.

Disconnecting SSH sessions

About this task
The device supports concurrent login sessions. To avoid an SSH login user interfering with your
configuration, you can disconnect that SSH login user.

485
Procedure
Execute the following command in user view to disconnect SSH sessions:
free ssh { user-ip { ip-address | ipv6 ipv6-address } [ port port-number ] |
user-pid pid-number | username username }

Configuring the device as an Stelnet client

Stelnet client tasks at a glance
To configure an Stelnet client, perform the following tasks:
1. Generating local key pairs
Only required for authentication method publickey, password-publickey, or any.
2. (Optional.) Specifying the source IP address for outgoing SSH packets
3. Establishing a connection to an Stelnet server
4. (Optional.) Deleting server public keys saved in the public key file on the Stelnet client
5. (Optional.) Establishing a connection to an Stelnet server based on Suite B

Generating local key pairs

About this task
You must generate local key pairs on Stelnet clients when the Stelnet server uses the publickey,
password-publickey, or any authentication method.
Restrictions and guidelines
Local DSA, ECDSA, and RSA key pairs for SSH use default names. You cannot assign names to the
key pairs.
The key modulus length must be less than 2048 bits when you generate a DSA key pair.
When you generate an ECDSA key pair, you can generate only a secp256r1 or secp384r1 ECDSA
key pair.
The Stelnet client operating in FIPS mode supports only ECDSA and RSA key pairs.
Procedure
1. Enter system view.
system-view
2. Generate local key pairs.
public-key local create { dsa | ecdsa { secp256r1 | secp384r1 } | rsa }

Specifying the source IP address for outgoing SSH packets

About this task
After you specify the source IP address for outgoing SSH packets on an Stelnet client, the client uses
the specified IP address to communicate with the Stelnet server.
Restrictions and guidelines
As a best practice, specify the IP address of a loopback interface as the source address of outgoing
SSH packets for the following purposes:
• Ensuring the communication between the Stelnet client and the Stelnet server.

486
 • Improving the manageability of Stelnet clients in authentication service.
Procedure
1. Enter system view.
system-view
2. Specify the source address for outgoing SSH packets.
IPv4:
ssh client source { interface interface-type interface-number | ip
ip-address }
By default, an IPv4 Stelnet client uses the primary IPv4 address of the output interface in the
matching route as the source address of the outgoing SSH packets.
IPv6:
ssh client ipv6 source { interface interface-type interface-number |
ipv6 ipv6-address }
By default, an IPv6 Stelnet client automatically selects a source IPv6 address for outgoing SSH
packets in compliance with RFC 3484.

Establishing a connection to an Stelnet server

About this task
Perform this task to enable the Stelnet client feature on the device and establish a connection to the
Stelnet server. You can specify the public key algorithm and the preferred encryption, HMAC, and
key exchange algorithms to be used during the connection.
To access the server, a client must use the server's host public key to authenticate the server. As a
best practice, configure the server's host public key on the device in an insecure network. If the
server's host public key is not configured on the client, the client will notify you to confirm whether to
continue with the access.
• If you choose to continue, the client accesses the server and downloads the server's host public
key. The downloaded public key will be used to authenticate the server in subsequent
accesses.
If the server public key is not specified the when you connect to the server, the device saves the
server public key to the public key file. It does not save the server public key to the configuration
file.
• If you choose to not continue, the connection cannot be established.
Restrictions and guidelines for establishing a connection to an Stelnet server
An Stelnet client cannot establish connections to both IPv4 and IPv6 Stelnet servers.
Establishing a connection to an IPv4 Stelnet server
Execute the following command in user view to establish a connection with an IPv4 Stelnet server:
In non-FIPS mode:
ssh2 server [ port-number ] [ vpn-instance vpn-instance-name ]
[ identity-key { dsa | ecdsa-sha2-nistp256 | ecdsa-sha2-nistp384 | rsa |
{ x509v3-ecdsa-sha2-nistp256 | x509v3-ecdsa-sha2-nistp384 } pki-domain
domain-name } | prefer-compress zlib | prefer-ctos-cipher { 3des-cbc |
aes128-cbc | aes128-ctr | aes128-gcm | aes192-ctr | aes256-cbc | aes256-ctr
| aes256-gcm | des-cbc } | prefer-ctos-hmac { md5 | md5-96 | sha1 | sha1-96 |
sha2-256 | sha2-512 } | prefer-kex { dh-group-exchange-sha1 |
dh-group1-sha1 | dh-group14-sha1 | ecdh-sha2-nistp256 |
ecdh-sha2-nistp384 } | prefer-stoc-cipher { 3des-cbc | aes128-cbc |
aes128-ctr | aes128-gcm | aes192-ctr | aes256-cbc | aes256-ctr | aes256-gcm

487
 | des-cbc } | prefer-stoc-hmac { md5 | md5-96 | sha1 | sha1-96 | sha2-256 |
sha2-512 } ] * [ dscp dscp-value | escape character | { public-key keyname |
server-pki-domain domain-name } | source { interface interface-type
interface-number | ip ip-address } ] *
In FIPS mode:
ssh2 server [ port-number ] [ vpn-instance vpn-instance-name ]
[ identity-key { ecdsa-sha2-nistp256 | ecdsa-sha2-nistp384 | rsa |
{ x509v3-ecdsa-sha2-nistp256 | x509v3-ecdsa-sha2-nistp384 } pki-domain
domain-name } | prefer-compress zlib | prefer-ctos-cipher { aes128-cbc |
aes128-ctr | aes128-gcm | aes192-ctr | aes256-cbc | aes256-ctr | aes256-gcm }
| prefer-ctos-hmac { sha1 | sha1-96 | sha2-256 | sha2-512 } | prefer-kex
{ dh-group14-sha1 | ecdh-sha2-nistp256 | ecdh-sha2-nistp384 } |
prefer-stoc-cipher { aes128-cbc | aes128-ctr | aes128-gcm | aes192-ctr |
aes256-cbc | aes256-ctr | aes256-gcm } | prefer-stoc-hmac { sha1 | sha1-96
| sha2-256 | sha2-512 } ] * [ escape character | { public-key keyname |
server-pki-domain domain-name } | source { interface interface-type
interface-number | ip ip-address } ] *
Establishing a connection to an IPv6 Stelnet server
Execute the following command in user view to establish a connection to an IPv6 Stelnet server:
In non-FIPS mode:
ssh2 ipv6 server [ port-number ] [ vpn-instance vpn-instance-name ] [ -i
interface-type interface-number ] [ identity-key { dsa |
ecdsa-sha2-nistp256 | ecdsa-sha2-nistp384 | rsa |
{ x509v3-ecdsa-sha2-nistp256 | x509v3-ecdsa-sha2-nistp384 } pki-domain
domain-name } | prefer-compress zlib | prefer-ctos-cipher { 3des-cbc |
aes128-cbc | aes128-ctr | aes128-gcm | aes192-ctr | aes256-cbc | aes256-ctr
| aes256-gcm | des-cbc } | prefer-ctos-hmac { md5 | md5-96 | sha1 | sha1-96 |
sha2-256 | sha2-512 } | prefer-kex { dh-group-exchange-sha1 |
dh-group1-sha1 | dh-group14-sha1 | ecdh-sha2-nistp256 |
ecdh-sha2-nistp384 } | prefer-stoc-cipher { 3des-cbc | aes128-cbc |
aes128-ctr | aes128-gcm | aes192-ctr | aes256-cbc | aes256-ctr | aes256-gcm
| des-cbc } | prefer-stoc-hmac { md5 | md5-96 | sha1 | sha1-96 | sha2-256 |
sha2-512 } ] * [ dscp dscp-value | escape character | { public-key keyname |
server-pki-domain domain-name } | source { interface interface-type
interface-number | ipv6 ipv6-address } ] *
In FIPS mode:
ssh2 ipv6 server [ port-number ] [ vpn-instance vpn-instance-name ] [ -i
interface-type interface-number ] [ identity-key { ecdsa-sha2-nistp256 |
ecdsa-sha2-nistp384 | rsa | { x509v3-ecdsa-sha2-nistp256 |
x509v3-ecdsa-sha2-nistp384 } pki-domain domain-name } | prefer-compress
zlib | prefer-ctos-cipher { aes128-cbc | aes128-ctr | aes128-gcm |
aes192-ctr | aes256-cbc | aes256-ctr | aes256-gcm } | prefer-ctos-hmac
{ sha1 | sha1-96 | sha2-256 | sha2-512 } | prefer-kex { dh-group14-sha1 |
ecdh-sha2-nistp256 | ecdh-sha2-nistp384 } | prefer-stoc-cipher
{ aes128-cbc | aes128-ctr | aes128-gcm | aes192-ctr | aes256-cbc |
aes256-ctr | aes256-gcm } | prefer-stoc-hmac { sha1 | sha1-96 | sha2-256 |
sha2-512 } ] * [ escape character | { public-key keyname | server-pki-domain
domain-name } | source { interface interface-type interface-number | ipv6
ipv6-address } ] *

488
Deleting server public keys saved in the public key file on the
Stelnet client
About this task
When the Stelnet client switches to FIPS mode but the locally saved server public key does not
comply with FIPS, the client cannot connect to the server. To connect to the server, delete the server
public key saved on the client and make sure a FIPS-compliant public key has been generated on
the server.
Procedure
1. Enter system view.
system-view
2. Delete server public keys saved in the public key file on the Stelnet client.
delete ssh client server-public-key [ server-ip ip-address ]

Establishing a connection to an Stelnet server based on Suite

B
Execute the following command in user view to establish a connection to an Stelnet server based on
Suite B:
IPv4:
ssh2 server [ port-number ] [ vpn-instance vpn-instance-name ] suite-b
[ 128-bit | 192-bit ] pki-domain domain-name [ server-pki-domain
domain-name ] [ prefer-compress zlib ] [ dscp dscp-value | escape character |
source { interface interface-type interface-number | ip ip-address } ] *
IPv6:
ssh2 ipv6 server [ port-number ] [ vpn-instance vpn-instance-name ] [ -i
interface-type interface-number ] suite-b [ 128-bit | 192-bit ] pki-domain
domain-name [ server-pki-domain domain-name ] [ prefer-compress zlib ]
[ dscp dscp-value | escape character | source { interface interface-type
interface-number | ipv6 ipv6-address } ] *

Configuring the device as an SFTP client

SFTP client tasks at a glance
To configure an SFTP client, perform the following tasks:
1. Generating local key pairs
Only required for authentication method publickey, password-publickey, or any.
2. (Optional.) Specifying the source IP address for outgoing SFTP packets
3. Establishing a connection to an SFTP server
4. (Optional.) Deleting server public keys saved in the public key file on the SFTP client
5. (Optional.) Establishing a connection to an SFTP server based on Suite B
6. (Optional.) Working with SFTP directories
7. (Optional.) Working with SFTP files
8. (Optional.) Displaying help information

489
 9. (Optional.) Terminating the connection with the SFTP server

Generating local key pairs

About this task
You must generate local key pairs on SFTP clients when the SFTP server uses the publickey,
password-publickey, or any authentication method.
Restrictions and guidelines
Local DSA, ECDSA, and RSA key pairs for SSH use default names. You cannot assign names to the
key pairs.
The key modulus length must be less than 2048 bits when you generate a DSA key pair.
When you generate an ECDSA key pair, you can generate only a secp256r1 or secp384r1
ECDSA key pair.
The SFTP client operating in FIPS mode supports only ECDSA and RSA key pairs.
Procedure
1. Enter system view.
system-view
2. Generate local key pairs.
public-key local create { dsa | ecdsa { secp256r1 | secp384r1 } | rsa }

Specifying the source IP address for outgoing SFTP packets

About this task
After you specify the source IP address for outgoing SFTP packets on an SFTP client, the client uses
the specified IP address to communicate with the SFTP server.
Restrictions and guidelines
As a best practice, specify the IP address of a loopback interface as the source address of outgoing
SFTP packets for the following purposes:
• Ensuring the communication between the SFTP client and the SFTP server.
• Improving the manageability of SFTP clients in authentication service.
Procedure
1. Enter system view.
system-view
2. Specify the source address for outgoing SFTP packets.
IPv4:
sftp client source { ip ip-address | interface interface-type
interface-number }
By default, an SFTP client uses the primary IPv4 address of the output interface in the matching
route as the source address of the outgoing SFTP packets.
IPv6:
sftp client ipv6 source { ipv6 ipv6-address | interface interface-type
interface-number }
By default, an IPv6 SFTP client automatically selects a source IPv6 address for the outgoing
SFTP packets in compliance with RFC 3484.

490
Establishing a connection to an SFTP server
About this task
Perform this task to enable the SFTP client feature on the device and establish a connection to the
SFTP server. You can specify the public key algorithm and the preferred encryption, HMAC, and key
exchange algorithms to be used during the connection.
To access the server, a client must use the server's host public key to authenticate the server. As a
best practice, configure the server's host public key on the device in an insecure network. If the
server's host public key is not configured on the client, the client will notify you to confirm whether to
continue with the access.
• If you choose to continue, the client accesses the server and downloads the server's host public
key. The downloaded public key will be used to authenticate the server in subsequent
accesses.
If the server public key is not specified when you connect to the server, the device saves the
server public key to the public key file. It does not save the server public key to the configuration
file.
• If you choose to not continue, the connection cannot be established.
Restrictions and guidelines for establishing a connection to an SFTP server
An SFTP client cannot establish connections to both IPv4 and IPv6 SFTP servers.
Establishing a connection to an IPv4 SFTP server
Execute the following command in user view to establish a connection to an IPv4 SFTP server:
In non-FIPS mode:
sftp server [ port-number ] [ vpn-instance vpn-instance-name ]
[ identity-key { dsa | ecdsa-sha2-nistp256 | ecdsa-sha2-nistp384 | rsa |
{ x509v3-ecdsa-sha2-nistp256 | x509v3-ecdsa-sha2-nistp384 } pki-domain
domain-name } | prefer-compress zlib | prefer-ctos-cipher { 3des-cbc |
aes128-cbc | aes128-ctr | aes128-gcm | aes192-ctr | aes256-cbc | aes256-ctr
| aes256-gcm | des-cbc } | prefer-ctos-hmac { md5 | md5-96 | sha1 | sha1-96 |
sha2-256 | sha2-512 } | prefer-kex { dh-group-exchange-sha1 |
dh-group1-sha1 | dh-group14-sha1 | ecdh-sha2-nistp256 |
ecdh-sha2-nistp384 } | prefer-stoc-cipher { 3des-cbc | aes128-cbc |
aes128-ctr | aes128-gcm | aes192-ctr | aes256-cbc | aes256-ctr | aes256-gcm
| des-cbc } | prefer-stoc-hmac { md5 | md5-96 | sha1 | sha1-96 | sha2-256 |
sha2-512 } ] * [ dscp dscp-value | { public-key keyname | server-pki-domain
domain-name } | source { interface interface-type interface-number | ip
ip-address } ] *
In FIPS mode:
sftp server [ port-number ] [ vpn-instance vpn-instance-name ]
[ identity-key { ecdsa-sha2-nistp256 | ecdsa-sha2-nistp384 | rsa |
{ x509v3-ecdsa-sha2-nistp256 | x509v3-ecdsa-sha2-nistp384 } pki-domain
domain-name } | prefer-compress zlib | prefer-ctos-cipher { aes128-cbc |
aes128-ctr | aes128-gcm | aes192-ctr | aes256-cbc | aes256-ctr | aes256-gcm }
| prefer-ctos-hmac { sha1 | sha1-96 | sha2-256 | sha2-512 } | prefer-kex
{ dh-group14-sha1 | ecdh-sha2-nistp256 | ecdh-sha2-nistp384 } |
prefer-stoc-cipher { aes128-cbc | aes128-ctr | aes128-gcm | aes192-ctr |
aes256-cbc | aes256-ctr | aes256-gcm } | prefer-stoc-hmac { sha1 | sha1-96
| sha2-256 | sha2-512 } ] * [ { public-key keyname | server-pki-domain
domain-name } | source { interface interface-type interface-number | ip
ip-address } ] *

491
Establishing a connection to an IPv6 SFTP server
Execute the following command in user view to establish a connection to an IPv6 SFTP server:
In non-FIPS mode:
sftp ipv6 server [ port-number ] [ vpn-instance vpn-instance-name ] [ -i
interface-type interface-number ] [ identity-key { dsa |
ecdsa-sha2-nistp256 | ecdsa-sha2-nistp384 | rsa |
{ x509v3-ecdsa-sha2-nistp256 | x509v3-ecdsa-sha2-nistp384 } pki-domain
domain-name } | prefer-compress zlib | prefer-ctos-cipher { 3des-cbc |
aes128-cbc | aes128-ctr | aes128-gcm | aes192-ctr | aes256-cbc | aes256-ctr
| aes256-gcm | des-cbc } | prefer-ctos-hmac { md5 | md5-96 | sha1 | sha1-96 |
sha2-256 | sha2-512 } | prefer-kex { dh-group-exchange-sha1 |
dh-group1-sha1 | dh-group14-sha1 | ecdh-sha2-nistp256 |
ecdh-sha2-nistp384 } | prefer-stoc-cipher { 3des-cbc | aes128-cbc |
aes128-ctr | aes128-gcm | aes192-ctr | aes256-cbc | aes256-ctr | aes256-gcm
| des-cbc } | prefer-stoc-hmac { md5 | md5-96 | sha1 | sha1-96 | sha2-256 |
sha2-512 } ] * [ dscp dscp-value | { public-key keyname | server-pki-domain
domain-name } | source { interface interface-type interface-number | ipv6
ipv6-address } ] *
In FIPS mode:
sftp ipv6 server [ port-number ] [ vpn-instance vpn-instance-name ] [ -i
interface-type interface-number ] [ identity-key { ecdsa-sha2-nistp256 |
ecdsa-sha2-nistp384 | rsa | { x509v3-ecdsa-sha2-nistp256 |
x509v3-ecdsa-sha2-nistp384 } pki-domain domain-name } | prefer-compress
zlib | prefer-ctos-cipher { aes128-cbc | aes128-ctr | aes128-gcm |
aes192-ctr | aes256-cbc | aes256-ctr | aes256-gcm } | prefer-ctos-hmac
{ sha1 | sha1-96 | sha2-256 | sha2-512 } | prefer-kex { dh-group14-sha1 |
ecdh-sha2-nistp256 | ecdh-sha2-nistp384 } | prefer-stoc-cipher
{ aes128-cbc | aes128-ctr | aes128-gcm | aes192-ctr | aes256-cbc |
aes256-ctr | aes256-gcm } | prefer-stoc-hmac { sha1 | sha1-96 | sha2-256 |
sha2-512 } ] * [ { public-key keyname | server-pki-domain domain-name } |
source { interface interface-type interface-number | ipv6 ipv6-address } ]
*

Deleting server public keys saved in the public key file on the
SFTP client
About this task
When the SFTP client switches to FIPS mode but the locally saved server public key does not
comply with FIPS, the client cannot connect to the server. To connect to the server, delete the server
public key saved on the client and make sure a FIPS-compliant public key has been generated on
the server.
Procedure
1. Enter system view.
system-view
2. Delete server public keys saved in the public key file on the SFTP client.
delete ssh client server-public-key [ server-ip ip-address ]

492
Establishing a connection to an SFTP server based on Suite
B
Execute the following command in user view to establish a connection to an SFTP server based on
Suite B:
IPv4:
sftp server [ port-number ] [ vpn-instance vpn-instance-name ] suite-b
[ 128-bit | 192-bit ] pki-domain domain-name [ server-pki-domain
domain-name ] [ prefer-compress zlib ] [ dscp dscp-value | source { interface
interface-type interface-number | ip ip-address } ] *
IPv6:
sftp ipv6 server [ port-number ] [ vpn-instance vpn-instance-name ] [ -i
interface-type interface-number ] suite-b [ 128-bit | 192-bit ] pki-domain
domain-name [ server-pki-domain domain-name ] [ prefer-compress zlib ]
[ dscp dscp-value | escape character | source { interface interface-type
interface-number | ipv6 ipv6-address } ] *

Working with SFTP directories

About this task
After you establish a connection to an SFTP server, you can operate directories of the SFTP server.
Changing the working directory on the SFTP server
1. Enter SFTP client view.
For more information, see "Establishing a connection to an SFTP server."
2. Change the working directory on the SFTP server.
cd [ remote-path ]
3. (Optional.) Return to the upper-level directory.
cdup
Displaying the current working directory on the SFTP server
1. Enter SFTP client view.
For more information, see "Establishing a connection to an SFTP server."
2. Display the current working directory on the SFTP server.
pwd
Displaying files under a directory
1. Enter SFTP client view.
For more information, see "Establishing a connection to an SFTP server."
2. Display files under a directory.
 dir [ -a | -l ] [ remote-path ]
 ls [ -a | -l ] [ remote-path ]
The dir command has the same function as the ls command.
Changing the name of a directory on the SFTP server
1. Enter SFTP client view.
For more information, see "Establishing a connection to an SFTP server."

493
 2. Change the name of a directory on the SFTP server.
rename oldname newname
Creating a new directory on the SFTP server
1. Enter SFTP client view.
For more information, see "Establishing a connection to an SFTP server."
2. Create a new directory on the SFTP server.
mkdir remote-path
Deleting directories on the SFTP server
1. Enter SFTP client view.
For more information, see "Establishing a connection to an SFTP server."
2. Delete one or more directories from the SFTP server.
rmdir remote-path

Working with SFTP files

About this task
After you establish a connection to an SFTP server, you can operate files on the SFTP server.
Changing the name of a file on the SFTP server
1. Enter SFTP client view.
For more information, see "Establishing a connection to an SFTP server."
2. Change the name of a file on the SFTP server.
rename old-name new-name
Downloading a file from the SFTP server and save it locally
1. Enter SFTP client view.
For more information, see "Establishing a connection to an SFTP server."
2. Download a file from the SFTP server and save it locally.
get remote-file [ local-file ]
Uploading a local file to the SFTP server
1. Enter SFTP client view.
For more information, see "Establishing a connection to an SFTP server."
2. Upload a local file to the SFTP server.
put local-file [ remote-file ]
Display files under a directory
1. Enter SFTP client view.
For more information, see "Establishing a connection to an SFTP server."
2. Display files under a directory.
 dir [ -a | -l ] [ remote-path ]
 ls [ -a | -l ] [ remote-path ]
The dir command has the same function as the ls command.
Deleting a file from the SFTP server
1. Enter SFTP client view.

494
 For more information, see "Establishing a connection to an SFTP server."
2. Delete a file from the SFTP server.
 delete remote-file
 remove remote-file
The delete command has the same function as the remove command.

Displaying help information

About this task
After you establish a connection to the SFTP server, you can display the help information of SFTP
client commands, including the command syntax and parameter configuration.
Procedure
1. Enter SFTP client view.
For more information, see "Establishing a connection to an SFTP server."
2. Display SFTP client command help information.
 help
 ?
The help command has the same function as the ? command.

Terminating the connection with the SFTP server

1. Enter SFTP client view.
For more information, see "Establishing a connection to an SFTP server."
2. Terminate the connection with the SFTP server and return to user view.
 bye
 exit
 quit
The three commands have the same function.

Configuring the device as an SCP client

SCP client tasks at a glance
To configure an SCP client, perform the following tasks:
1. Generating local key pairs
Only required for the publickey, password-publickey, or any authentication method.
2. (Optional.) Specifying the source IP address for outgoing SCP packets
3. Establishing a connection to an SCP server
4. (Optional.) Deleting server public keys saved in the public key file on the SCP client
5. (Optional.) Establishing a connection to an SCP server based on Suite B

495
Generating local key pairs
About this task
You must generate local key pairs on SCP clients when the SCP server uses the publickey,
password-publickey, or any authentication method.
Restrictions and guidelines
Local DSA, ECDSA, and RSA key pairs for SSH use default names. You cannot assign names to the
key pairs.
The key modulus length must be less than 2048 bits when you generate a DSA key pair.
When you generate an ECDSA key pair, you can generate only a secp256r1 or secp384r1
ECDSA key pair.
The SCP client operating in FIPS mode supports only ECDSA and RSA key pairs.
Procedure
1. Enter system view.
system-view
2. Generate local key pairs.
public-key local create { dsa | ecdsa { secp256r1 | secp384r1 } | rsa }

Specifying the source IP address for outgoing SCP packets

About this task
After you specify the source IP address for outgoing SCP packets on an SCP client, the client uses
the specified IP address to communicate with the SCP server.
Restrictions and guidelines
As a best practice, specify the IP address of a loopback interface as the source address of outgoing
SCP packets for the following purposes:
• Ensuring the communication between the SCP client and the SCP server.
• Improving the manageability of SCP clients in authentication service.
Procedure
1. Enter system view.
system-view
2. Specify the source address for outgoing SCP packets.
IPv4:
scp client source { interface interface-type interface-number | ip
ip-address }
By default, an SCP client uses the primary IPv4 address of the output interface in the matching
route as the source address of the outgoing SCP packets.
IPv6:
scp client ipv6 source { interface interface-type interface-number
| ipv6 ipv6-address }
By default, an SCP client automatically selects an IPv6 address as the source address of the
outgoing packets in compliance with RFC 3484.

496
Establishing a connection to an SCP server
About this task
Perform this task to enable the SCP client feature on the device, establish a connection to the SCP
server, and transfer files with the server. You can specify the public key algorithm and the preferred
encryption, HMAC, and key exchange algorithms to be used during the connection.
To access the server, a client must use the server's host public key to authenticate the server. As a
best practice, configure the server's host public key on the device in an insecure network. If the
server's host public key is not configured on the client, the client will notify you to confirm whether to
continue with the access.
• If you choose to continue, the client accesses the server and downloads the server's host public
key. The downloaded public key will be used to authenticate the server in subsequent
accesses.
If the server public key is not specified when you connect to the server, the device saves the
server public key to the public key file. It does not save the server public key to the configuration
file.
• If you choose to not continue, the connection cannot be established.
Restrictions and guidelines for establishing a connection to an SCP server
An SCP client cannot establish connections to both IPv4 and IPv6 SCP servers.
Establishing a connection to an IPv4 SCP server
Execute the following command in user view to connect to an IPv4 SCP server, and transfer files with
the server:
In non-FIPS mode:
scp server [ port-number ] [ vpn-instance vpn-instance-name ] { put | get }
source-file-name [ destination-file-name ] [ identity-key { dsa |
ecdsa-sha2-nistp256 | ecdsa-sha2-nistp384 | rsa |
{ x509v3-ecdsa-sha2-nistp256 | x509v3-ecdsa-sha2-nistp384 } pki-domain
domain-name } | prefer-compress zlib | prefer-ctos-cipher { 3des-cbc |
aes128-cbc | aes128-ctr | aes128-gcm | aes192-ctr | aes256-cbc | aes256-ctr
| aes256-gcm | des-cbc } | prefer-ctos-hmac { md5 | md5-96 | sha1 | sha1-96 |
sha2-256 | sha2-512 } | prefer-kex { dh-group-exchange-sha1 |
dh-group1-sha1 | dh-group14-sha1 | ecdh-sha2-nistp256 |
ecdh-sha2-nistp384 } | prefer-stoc-cipher { 3des-cbc | aes128-cbc |
aes128-ctr | aes128-gcm | aes192-ctr | aes256-cbc | aes256-ctr | aes256-gcm
| des-cbc } | prefer-stoc-hmac { md5 | md5-96 | sha1 | sha1-96 | sha2-256 |
sha2-512 } ] * [ { public-key keyname | server-pki-domain domain-name } |
source { interface interface-type interface-number | ip ip-address } ] *
[ user username [ password password [ no-more-input ] ] ]
In FIPS mode:
scp server [ port-number ] [ vpn-instance vpn-instance-name ] { put | get }
source-file-name [ destination-file-name ] [ identity-key
{ ecdsa-sha2-nistp256 | ecdsa-sha2-nistp384 | rsa |
{ x509v3-ecdsa-sha2-nistp256 | x509v3-ecdsa-sha2-nistp384 } pki-domain
domain-name } | prefer-compress zlib | prefer-ctos-cipher { aes128-cbc |
aes128-ctr | aes128-gcm | aes192-ctr | aes256-cbc | aes256-ctr | aes256-gcm }
| prefer-ctos-hmac { sha1 | sha1-96 | sha2-256 | sha2-512 } | prefer-kex
{ dh-group14-sha1 | ecdh-sha2-nistp256 | ecdh-sha2-nistp384 } |
prefer-stoc-cipher { aes128-cbc | aes128-ctr | aes128-gcm | aes192-ctr |
aes256-cbc | aes256-ctr | aes256-gcm } | prefer-stoc-hmac { sha1 | sha1-96
| sha2-256 | sha2-512 } ] * [ { public-key keyname | server-pki-domain

497
 domain-name } | source { interface interface-type interface-number | ip
ip-address } ] * [ user username [ password password [ no-more-input ] ] ]
Establishing a connection to an IPv6 SCP server
Execute the following command in user view to connect to an IPv6 SCP server, and transfer files with
the server.
In non-FIPS mode:
scp ipv6 server [ port-number ] [ vpn-instance vpn-instance-name ] [ -i
interface-type interface-number ] { put | get } source-file-name
[ destination-file-name ] [ identity-key { dsa | ecdsa-sha2-nistp256 |
ecdsa-sha2-nistp384 | rsa | { x509v3-ecdsa-sha2-nistp256 |
x509v3-ecdsa-sha2-nistp384 } pki-domain domain-name } | prefer-compress
zlib | prefer-ctos-cipher { 3des-cbc | aes128-cbc | aes128-ctr | aes128-gcm
| aes192-ctr | aes256-cbc | aes256-ctr | aes256-gcm | des-cbc } |
prefer-ctos-hmac { md5 | md5-96 | sha1 | sha1-96 | sha2-256 | sha2-512 } |
prefer-kex { dh-group-exchange-sha1 | dh-group1-sha1 | dh-group14-sha1 |
ecdh-sha2-nistp256 | ecdh-sha2-nistp384 } | prefer-stoc-cipher { 3des-cbc
| aes128-cbc | aes128-ctr | aes128-gcm | aes192-ctr | aes256-cbc |
aes256-ctr | aes256-gcm | des-cbc } | prefer-stoc-hmac { md5 | md5-96 | sha1
| sha1-96 | sha2-256 | sha2-512 } ] * [ { public-key keyname |
server-pki-domain domain-name } | source { interface interface-type
interface-number | ipv6 ipv6-address } ] * [ user username [ password
password [ no-more-input ] ] ]
In FIPS mode:
scp ipv6 server [ port-number ] [ vpn-instance vpn-instance-name ] [ -i
interface-type interface-number ] { put | get } source-file-name
[ destination-file-name ] [ identity-key { ecdsa-sha2-nistp256 |
ecdsa-sha2-nistp384 | rsa | { x509v3-ecdsa-sha2-nistp256 |
x509v3-ecdsa-sha2-nistp384 } pki-domain domain-name } | prefer-compress
zlib | prefer-ctos-cipher { aes128-cbc | aes128-ctr | aes128-gcm |
aes192-ctr | aes256-cbc | aes256-ctr | aes256-gcm } | prefer-ctos-hmac
{ sha1 | sha1-96 | sha2-256 | sha2-512 } | prefer-kex { dh-group14-sha1 |
ecdh-sha2-nistp256 | ecdh-sha2-nistp384 } | prefer-stoc-cipher
{ aes128-cbc | aes128-ctr | aes128-gcm | aes192-ctr | aes256-cbc |
aes256-ctr | aes256-gcm } | prefer-stoc-hmac { sha1 | sha1-96 | sha2-256 |
sha2-512 } ] * [ { public-key keyname | server-pki-domain domain-name } |
source { interface interface-type interface-number | ipv6 ipv6-address } ]
* [ user username [ password password [ no-more-input ] ] ]

Deleting server public keys saved in the public key file on the
SCP client
About this task
When the SCP client switches to FIPS mode but the locally saved server public key does not comply
with FIPS, the client cannot connect to the server. To connect to the server, delete the server public
key saved on the client and make sure a FIPS-compliant public key has been generated on the
server.
Procedure
1. Enter system view.
system-view
2. Delete server public keys saved in the public key file on the SCP client.

498
 delete ssh client server-public-key [ server-ip ip-address ]

Establishing a connection to an SCP server based on Suite B

Execute the following command in user view to establish a connection to an SCP server based on
Suite B:
IPv4:
scp server [ port-number ] [ vpn-instance vpn-instance-name ] { put | get }
source-file-name [ destination-file-name ] suite-b [ 128-bit | 192-bit ]
pki-domain domain-name [ server-pki-domain domain-name ] [ prefer-compress
zlib ] [ source { interface interface-type interface-number | ip
ip-address } ] * [ user username [ password password ] ]
IPv6:
scp ipv6 server [ port-number ] [ vpn-instance vpn-instance-name ] [ -i
interface-type interface-number ] { put | get } source-file-name
[ destination-file-name ] suite-b [ 128-bit | 192-bit ] pki-domain
domain-name [ server-pki-domain domain-name ] [ prefer-compress zlib ]
[ source { interface interface-type interface-number | ipv6 ipv6-address } ]
* [ user username [ password password ] ]

Specifying algorithms for SSH2

About algorithms for SSH2
The SSH2 client and server use the following types of algorithms for algorithm negotiation during the
Stelnet, SFTP, or SCP session establishment:
• Key exchange algorithms.
• Public key algorithms.
• Encryption algorithms.
• MAC algorithms.
If you specify algorithms, SSH2 uses only the specified algorithms for algorithm negotiation. The
client uses the specified algorithms to initiate the negotiation, and the server uses the matching
algorithms to negotiate with the client. If multiple algorithms of the same type are specified, the
algorithm specified earlier has a higher priority during negotiation.

Specifying key exchange algorithms for SSH2

1. Enter system view.
system-view
2. Specify key exchange algorithms for SSH2.
In non-FIPS mode:
ssh2 algorithm key-exchange { dh-group-exchange-sha1 | dh-group1-sha1
| dh-group14-sha1 | ecdh-sha2-nistp256 | ecdh-sha2-nistp384 } *
By default, SSH2 uses the ecdh-sha2-nistp256, ecdh-sha2-nistp384,
dh-group-exchange-sha1, dh-group14-sha1, and dh-group1-sha1 key exchange
algorithms in descending order of priority for algorithm negotiation.
In FIPS mode:

499
 ssh2 algorithm key-exchange { dh-group14-sha1 | ecdh-sha2-nistp256 |
ecdh-sha2-nistp384 } *
By default, SSH2 uses the ecdh-sha2-nistp256, ecdh-sha2-nistp384, and
dh-group14-sha1 key exchange algorithms in descending order of priority for algorithm
negotiation.

Specifying public key algorithms for SSH2

1. Enter system view.
system-view
2. Specify public key algorithms for SSH2.
In non-FIPS mode:
ssh2 algorithm public-key { dsa | ecdsa-sha2-nistp256 |
ecdsa-sha2-nistp384 | rsa | x509v3-ecdsa-sha2-nistp256 |
x509v3-ecdsa-sha2-nistp384 } *
By default, SSH2 uses the x509v3-ecdsa-sha2-nistp256,
x509v3-ecdsa-sha2-nistp384, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384,
rsa, and dsa public key algorithms in descending order of priority for algorithm negotiation.
In FIPS mode:
ssh2 algorithm public-key { ecdsa-sha2-nistp256 | ecdsa-sha2-nistp384
| rsa | x509v3-ecdsa-sha2-nistp256 | x509v3-ecdsa-sha2-nistp384 } *
By default, SSH2 uses the x509v3-ecdsa-sha2-nistp256,
x509v3-ecdsa-sha2-nistp384, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384,
and rsa public key algorithms in descending order of priority for algorithm negotiation.

Specifying encryption algorithms for SSH2

1. Enter system view.
system-view
2. Specify encryption algorithms for SSH2.
In non-FIPS mode:
ssh2 algorithm cipher { 3des-cbc | aes128-cbc | aes128-ctr | aes128-gcm
| aes192-ctr | aes256-cbc | aes256-ctr | aes256-gcm | des-cbc } *
By default, SSH2 uses the aes128-ctr, aes192-ctr, aes256-ctr, aes128-gcm,
aes256-gcm, aes128-cbc, 3des-cbc, aes256-cbc, and des-cbc encryption
algorithms in descending order of priority for algorithm negotiation.
In FIPS mode:
ssh2 algorithm cipher { aes128-cbc | aes128-ctr | aes128-gcm |
aes192-ctr | aes256-cbc | aes256-ctr | aes256-gcm } *
By default, SSH2 uses the aes128-ctr, aes192-ctr, aes256-ctr, aes128-gcm,
aes256-gcm, aes128-cbc, and aes256-cbc encryption algorithms in descending order of
priority for algorithm negotiation.

Specifying MAC algorithms for SSH2

1. Enter system view.
system-view
2. Specify MAC algorithms for SSH2.

500
 In non-FIPS mode:
ssh2 algorithm mac { md5 | md5-96 | sha1 | sha1-96 | sha2-256 | sha2-512 }
*
By default, SSH2 uses the sha2-256, sha2-512, sha1, md5, sha1-96, and md5-96
MAC algorithms in descending order of priority for algorithm negotiation.
In FIPS mode:
ssh2 algorithm mac { sha1 | sha1-96 | sha2-256 | sha2-512 } *
By default, SSH2 uses the sha2-256, sha2-512, sha1, and sha1-96 MAC algorithms in
descending order of priority for algorithm negotiation.

Display and maintenance commands for SSH

Execute display commands in any view.

Task Command
display public-key local { dsa | ecdsa |
Display the public keys of the local key pairs.
rsa } public [ name publickey-name ]
display public-key peer [ brief | name
Display information about peer public keys.
publickey-name ]
Display the source IP address configuration of
display scp client source
the SCP client.
Display the source IP address configuration of
display sftp client source
the SFTP client.

Display server public key information saved in display ssh client server-public-key
the public key file on the SSH client. [ server-ip ip-address ]
Display the source IP address configuration of
display ssh client source
the Stelnet client.

Display SSH server status or sessions. display ssh server { session | status }
Display SSH user information on the SSH display ssh user-information
server. [ username ]
Display algorithms used by SSH2 in the
display ssh2 algorithm
algorithm negotiation stage.

For more information about the display public-key local and display public-key
peer commands, see public key management commands in Security Command Reference.

Stelnet configuration examples

Unless otherwise noted, devices in the configuration examples operate in non-FIPS mode.
When the device acts as an Stelnet server operating in FIPS mode, only ECDSA and RSA key pairs
are supported. Do not generate a DSA key pair on the Stelnet server.

501
Example: Configuring the device as an Stelnet server
(password authentication)
Network configuration
As shown in Figure 115:
• The switch acts as the Stelnet server and uses password authentication to authenticate the
Stelnet client. The username and password of the client are saved on the switch.
• The host acts as the Stelnet client, using Stelnet client software (SSH2). After the user on the
host logs in to the switch through Stelnet, the user can configure and manage the switch as a
network administrator.
Figure 115 Network diagram
Stelnet client Stelnet server
Vlan-int2
192.168.1.56/24 192.168.1.40/24

Host Switch

Procedure
1. Configure the Stelnet server:
# Generate RSA key pairs.
<Switch> system-view
[Switch] public-key local create rsa
The range of public key modulus is (512 ~ 4096).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
........................++++++
...................++++++
..++++++++
............++++++++
Create the key pair successfully.
# Generate a DSA key pair.
[Switch] public-key local create dsa
The range of public key modulus is (512 ~ 2048).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
.++++++++++++++++++++++++++++++++++++++++++++++++++*
........+......+.....+......................................+
...+.................+..........+...+.
Create the key pair successfully.
# Generate an ECDSA key pair.
[Switch] public-key local create ecdsa secp256r1
Generating Keys...
.

502
 Create the key pair successfully.
# Enable the Stelnet server.
[Switch] ssh server enable
# Assign an IP address to VLAN-interface 2. The Stelnet client uses this address as the
destination for SSH connection.
[Switch] interface vlan-interface 2
[Switch-Vlan-interface2] ip address 192.168.1.40 255.255.255.0
[Switch-Vlan-interface2] quit
# Set the authentication mode to AAA for user lines.
[Switch] line vty 0 63
[Switch-line-vty0-63] authentication-mode scheme
[Switch-line-vty0-63] quit
# Create a local device management user named client001.
[Switch] local-user client001 class manage
# Set the password to hello12345 in plain text for local user client001.
[Switch-luser-manage-client001] password simple hello12345
# Authorize local user client001 to use the SSH service.
[Switch-luser-manage-client001] service-type ssh
# Assign the network-admin user role to local user client001.
[Switch-luser-manage-client001] authorization-attribute user-role network-admin
[Switch-luser-manage-client001] quit
# Create an SSH user named client001. Specify the service type as stelnet and the
authentication method as password for the user.
[Switch] ssh user client001 service-type stelnet authentication-type password
2. Establish a connection to the Stelnet server:
There are different types of Stelnet client software, such as PuTTY and OpenSSH. This
example uses an Stelnet client that runs PuTTY version 0.58.
To establish a connection to the Stelnet server:
a. Launch PuTTY.exe to enter the interface shown in Figure 116.
b. In the Host Name (or IP address) field, enter IP address 192.168.1.40 of the Stelnet
server.
c. Click Open.

503
 Figure 116 Specifying the host name (or IP address)

d. Enter username client001 and password hello12345 to log in to the Stelnet server.

Example: Configuring the device as an Stelnet server

(publickey authentication)
Network configuration
As shown in Figure 117:
• The switch acts as the Stelnet server, and it uses publickey authentication and the RSA public
key algorithm.
• The host acts as the Stelnet client, using Stelnet client software (SSH2). After the user on the
host logs in to the switch through Stelnet, the user can configure and manage the switch as a
network administrator.
Figure 117 Network diagram
Stelnet client Stelnet server
Vlan-int2
192.168.1.56/24 192.168.1.40/24

Host Switch

Procedure
In the server configuration, the client's host public key is required. Use the client software to generate
RSA key pairs on the client before configuring the Stelnet server.

504
There are different types of Stelnet client software, such as PuTTY and OpenSSH. This example
uses an Stelnet client that runs PuTTY version 0.58.
The configuration procedure is as follows:
1. Generate RSA key pairs on the Stelnet client:
a. Run PuTTYGen.exe on the client, select SSH-2 RSA and click Generate.
Figure 118 Generating a key pair on the client

b. Continue moving the mouse during the key generating process, but do not place the mouse
over the green progress bar shown in Figure 119. Otherwise, the progress bar stops moving
and the key pair generating progress stops.

505
 Figure 119 Generating process

c. After the key pair is generated, click Save public key to save the public key.
A file saving window appears.
Figure 120 Saving a key pair on the client

a. Enter a file name (key.pub in this example), and click Save.

506
 b. On the page shown in Figure 120, click Save private key to save the private key.
A confirmation dialog box appears.
c. Click Yes.
A file saving window appears.
d. Enter a file name (private.ppk in this example), and click Save.
e. Transmit the public key file to the server through FTP or TFTP. (Details not shown.)
2. Configure the Stelnet server:
# Generate RSA key pairs.
<Switch> system-view
[Switch] public-key local create rsa
The range of public key modulus is (512 ~ 4096).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
........................++++++
...................++++++
..++++++++
............++++++++
Create the key pair successfully.
# Generate a DSA key pair.
[Switch] public-key local create dsa
The range of public key modulus is (512 ~ 2048).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
.++++++++++++++++++++++++++++++++++++++++++++++++++*
........+......+.....+......................................+
...+.................+..........+...+
Create the key pair successfully.
# Generate an ECDSA key pair.
[Switch] public-key local create ecdsa secp256r1
Generating Keys...
.
Create the key pair successfully.
# Enable the Stelnet server.
[Switch] ssh server enable
# Assign an IP address to VLAN-interface 2. The Stelnet client uses this IP address as the
destination for SSH connection.
[Switch] interface vlan-interface 2
[Switch-Vlan-interface2] ip address 192.168.1.40 255.255.255.0
[Switch-Vlan-interface2] quit
# Set the authentication mode to AAA for user lines.
[Switch] line vty 0 63
[Switch-line-vty0-63] authentication-mode scheme
[Switch-line-vty0-63] quit

507
 # Import the client's public key from the public key file key.pub and name it switchkey.
[Switch] public-key peer switchkey import sshkey key.pub
# Create an SSH user named client002. Specify the authentication method as publickey for
the user, and assign the public key switchkey to the user.
[Switch] ssh user client002 service-type stelnet authentication-type publickey assign
publickey switchkey
# Create a local device management user named client002.
[Switch] local-user client002 class manage
# Authorize local user client002 to use the SSH service.
[Switch-luser-manage-client002] service-type ssh
# Assign the network-admin user role to local user client002.
[Switch-luser-manage-client002] authorization-attribute user-role network-admin
[Switch-luser-manage-client002] quit
3. Specify the private key file and establish a connection to the Stelnet server:
a. Launch PuTTY.exe on the Stelnet client to enter the interface shown in Figure 121.
b. In the Host Name (or IP address) field, enter IP address 192.168.1.40 of the Stelnet
server.
Figure 121 Specifying the host name (or IP address)

a. From the navigation tree, select Connection > SSH.

The window shown in Figure 122 appears.
b. Set Preferred SSH protocol version to 2.

508
 Figure 122 Setting the preferred SSH version

e. From the navigation tree, select Connection > SSH > Auth.
The window shown in Figure 123 appears.
f. Click Browse… to open the file selection window, and then select the private key file
(private.ppk in this example).
g. Click Open.

509
 Figure 123 Specifying the private key file

h. Entering username client002 to log in to the Stelnet server.

Example: Configuring the device as an Stelnet client

(password authentication)
Network configuration
As shown in Figure 124:
• Switch B acts as the Stelnet server and uses password authentication to authenticate the
Stelnet client. The username and password of the client are saved on Switch B.
• Switch A acts as the Stelnet client. After the user on Switch A logs in to Switch B through Stelnet,
the user can configure and manage Switch B as a network administrator.
Figure 124 Network diagram
Stelnet client Stelnet server
Vlan-int2 Vlan-int2
192.168.1.56/24 192.168.1.40/24

Switch A Switch B

Procedure
1. Configure the Stelnet server:
# Generate RSA key pairs.
<SwitchB> system-view
[SwitchB] public-key local create rsa
The range of public key modulus is (512 ~ 4096).

510
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
........................++++++
...................++++++
..++++++++
............++++++++
Create the key pair successfully.
# Generate a DSA key pair.
[SwitchB] public-key local create dsa
The range of public key modulus is (512 ~ 2048).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
.++++++++++++++++++++++++++++++++++++++++++++++++++*
........+......+.....+......................................+
...+.................+..........+...+
Create the key pair successfully.
# Generate an ECDSA key pair.
[SwitchB] public-key local create ecdsa secp256r1
Generating Keys...
.
Create the key pair successfully.
# Enable the Stelnet server.
[SwitchB] ssh server enable
# Assign an IP address to VLAN-interface 2. The Stelnet client uses this address as the
destination address of the SSH connection.
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ip address 192.168.1.40 255.255.255.0
[SwitchB-Vlan-interface2] quit
# Set the authentication mode to AAA for user lines.
[SwitchB] line vty 0 63
[SwitchB-line-vty0-63] authentication-mode scheme
[SwitchB-line-vty0-63] quit
# Create a local device management user named client001.
[SwitchB] local-user client001 class manage
# Set the password to hello12345 in plain text for local user client001.
[SwitchB-luser-manage-client001] password simple hello12345
# Authorize local user client001 to use the SSH service.
[SwitchB-luser-manage-client001] service-type ssh
# Assign the network-admin user role to local user client001.
[SwitchB-luser-manage-client001] authorization-attribute user-role network-admin
[SwitchB-luser-manage-client001] quit
# Create an SSH user named client001. Specify the service type as stelnet and the
authentication method as password for the user.
[SwitchB] ssh user client001 service-type stelnet authentication-type password

511
 # Specify public key algorithm dsa for SSH2.
[SwitchB] ssh2 algorithm public-key dsa
2. Establish a connection to the Stelnet server:
# Assign an IP address to VLAN-interface 2.
<SwitchA> system-view
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 192.168.1.56 255.255.255.0
[SwitchA-Vlan-interface2] quit
[SwitchA] quit
Before establishing a connection to the server, you can configure the server's host public key
on the client to authenticate the server.
 To configure the server's host public key on the client, perform the following tasks:
# Use the display public-key local dsa public command on the server to display the
server's host public key. (Details not shown.)
# Enter public key view of the client and copy the host public key of the server to the client.
[SwitchA] public-key peer key1
Enter public key view. Return to system view with "peer-public-key end" command.
[SwitchA-pkey-public-key-key1]308201B73082012C06072A8648CE3804013082011F028181
0
0D757262C4584C44C211F18BD96E5F0
[SwitchA-pkey-public-key-key1]61C4F0A423F7FE6B6B85B34CEF72CE14A0D3A5222FE08CEC
E
65BE6C265854889DC1EDBD13EC8B274
[SwitchA-pkey-public-key-key1]DA9F75BA26CCB987723602787E922BA84421F22C3C89CB9B
0
6FD60FE01941DDD77FE6B12893DA76E
[SwitchA-pkey-public-key-key1]EBC1D128D97F0678D7722B5341C8506F358214B16A2FAC4B
3
68950387811C7DA33021500C773218C
[SwitchA-pkey-public-key-key1]737EC8EE993B4F2DED30F48EDACE915F0281810082269009
E
14EC474BAF2932E69D3B1F18517AD95
[SwitchA-pkey-public-key-key1]94184CCDFCEAE96EC4D5EF93133E84B47093C52B20CD35D0
2
492B3959EC6499625BC4FA5082E22C5
[SwitchA-pkey-public-key-key1]B374E16DD00132CE71B020217091AC717B612391C76C1FB2
E
88317C1BD8171D41ECB83E210C03CC9
[SwitchA-pkey-public-key-key1]B32E810561C21621C73D6DAAC028F4B1585DA7F42519718C
C
9B09EEF0381840002818000AF995917
[SwitchA-pkey-public-key-key1]E1E570A3F6B1C2411948B3B4FFA256699B3BF871221CC9C5
D
F257523777D033BEE77FC378145F2AD
[SwitchA-pkey-public-key-key1]D716D7DB9FCABB4ADBF6FB4FDB0CA25C761B308EF53009F7
1
01F7C62621216D5A572C379A32AC290
[SwitchA-pkey-public-key-key1]E55B394A217DA38B65B77F0185C8DB8095522D1EF044B465
E
8716261214A5A3B493E866991113B2D

512
 [SwitchA-pkey-public-key-key1]485348
[SwitchA-pkey-public-key-key1] peer-public-key end
# Specify public key algorithm dsa for SSH2.
[SwitchA] ssh2 algorithm public-key dsa
[SwitchA] quit
# Establish an SSH connection to the server, and specify the host public key of the server.
<SwitchA> ssh2 192.168.1.40 public-key key1
Username: client001
Press CTRL+C to abort.
Connecting to 192.168.1.40 port 22.
[email protected]'s password:
Enter a character ~ and a dot to abort.

******************************************************************************
* Copyright (c) 2004-2017 Hewlett-Packard Enterprise Development L.P. *
* Without the owner's prior written consent, *
* no decompiling or reverse-engineering shall be allowed. *
******************************************************************************

<SwitchB>
After you enter username client001 and password hello12345, you can successfully log in
to Switch B.
 If the client does not have the server's host public key, enter username client001, and then
enter y to access the server and download the server's host public key.
<SwitchA> ssh2 192.168.1.40
Username: client001
Press CTRL+C to abort.
Connecting to 192.168.1.40 port 22.
The server is not authenticated. Continue? [Y/N]:y
Do you want to save the server public key? [Y/N]:y
[email protected]'s password:
Enter a character ~ and a dot to abort.

******************************************************************************
* Copyright (c) 2004-2017 Hewlett-Packard Enterprise Development L.P. *
* Without the owner's prior written consent, *
* no decompiling or reverse-engineering shall be allowed. *
******************************************************************************

<SwitchB>
After you enter password hello12345, you can access Switch B successfully. At the next
connection attempt, the client authenticates the server by using the saved server's host
public key on the client.

513
Example: Configuring the device as an Stelnet client
(publickey authentication)
Network configuration
As shown in Figure 125:
• Switch B acts as the Stelnet server, and it uses publickey authentication and the DSA public key
algorithm.
• Switch A acts as the Stelnet client. After the user on Switch A logs in to Switch B through Stelnet,
the user can configure and manage Switch B as a network administrator.
Figure 125 Network diagram
Stelnet client Stelnet server
Vlan-int2 Vlan-int2
192.168.1.56/24 192.168.1.40/24

Switch A Switch B

Procedure
In the server configuration, the client's host public key is required. Generate a DSA key pair on the
client before configuring the Stelnet server.
1. Configure the Stelnet client:
# Assign an IP address to VLAN-interface 2.
<SwitchA> system-view
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 192.168.1.56 255.255.255.0
[SwitchA-Vlan-interface2] quit
# Generate a DSA key pair.
[SwitchA] public-key local create dsa
The range of public key modulus is (512 ~ 2048).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
.++++++++++++++++++++++++++++++++++++++++++++++++++*
........+......+.....+......................................+
...+.................+..........+...+
Create the key pair successfully.
# Export the DSA host public key to a public key file named key.pub.
[SwitchA] public-key local export dsa ssh2 key.pub
[SwitchA] quit
# Transmit the public key file key.pub to the server through FTP or TFTP. (Details not shown.)
2. Configure the Stelnet server:
# Generate RSA key pairs.
<SwitchB> system-view
[SwitchB] public-key local create rsa
The range of public key modulus is (512 ~ 4096)
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.

514
 Input the modulus length [default = 1024]:
Generating Keys...
........................++++++
...................++++++
..++++++++
............++++++++
Create the key pair successfully.
# Generate a DSA key pair.
[SwitchB] public-key local create dsa
The range of public key modulus is (512 ~ 2048).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
.++++++++++++++++++++++++++++++++++++++++++++++++++*
........+......+.....+......................................+
...+.................+..........+...+
Create the key pair successfully.
# Generate an ECDSA key pair.
[SwitchB] public-key local create ecdsa secp256r1
Generating Keys...
.
Create the key pair successfully.
# Enable the Stelnet server.
[SwitchB] ssh server enable
# Assign an IP address to VLAN-interface 2. The Stelnet client uses this address as the
destination address for SSH connection.
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ip address 192.168.1.40 255.255.255.0
[SwitchB-Vlan-interface2] quit
# Set the authentication mode to AAA for user lines.
[SwitchB] line vty 0 63
[SwitchB-line-vty0-63] authentication-mode scheme
[SwitchB-line-vty0-63] quit
# Import the peer public key from the public key file key.pub, and name it switchkey.
[SwitchB] public-key peer switchkey import sshkey key.pub
# Create an SSH user named client002. Specify the authentication method as publickey for
the user. Assign the public key switchkey to the user.
[SwitchB] ssh user client002 service-type stelnet authentication-type publickey
assign publickey switchkey
# Create a local device management user named client002.
[SwitchB] local-user client002 class manage
# Authorize local user client002 to use the SSH service.
[SwitchB-luser-manage-client002] service-type ssh
# Assign the network-admin user role to local user client002.
[SwitchB-luser-manage-client002] authorization-attribute user-role network-admin
[SwitchB-luser-manage-client002] quit
3. Establish an SSH connection to the Stelnet server.

515
 <SwitchA> ssh2 192.168.1.40 identity-key dsa
Username: client002
Press CTRL+C to abort.
Connecting to 192.168.1.40 port 22.
The server is not authenticated. Continue? [Y/N]:y
Do you want to save the server public key? [Y/N]:n
Enter a character ~ and a dot to abort.

******************************************************************************
* Copyright (c) 2004-2017 Hewlett-Packard Enterprise Development L.P. *
* Without the owner's prior written consent, *
* no decompiling or reverse-engineering shall be allowed. *
******************************************************************************

<SwitchB>
After you enter username client002 and then enter y to continue accessing the server, you can
log in to the server successfully.

Example: Configuring Stelnet based on 128-bit Suite B

algorithms
Network configuration
As shown in Figure 126:
• Switch B acts as the Stelnet Suite B server (SSH2), and it uses publickey authentication to
authenticate the Stelnet client.
• Switch A acts as an Stelnet Suite B client (SSH2). After the user on Switch A logs in to Switch B
through the Stelnet Suite B client software, the user can configure and manage Switch B as an
administrator.
Figure 126 Network diagram
Stelnet client Stelnet server
Vlan-int2 Vlan-int2
192.168.1.56/24 192.168.1.40/24

Switch A Switch B

Procedure
1. Generate the client's certificate and the server's certificate. (Details not shown.)
You must first configure the certificates of the server and the client because they are required
for identity authentication between the two parties.
In this example, the server's certificate file is ssh-server-ecdsa256.p12 and the client's
certificate file is ssh-client-ecdsa256.p12.
2. Configure the Stelnet client:
You can modify the pkix version of the client software OpenSSH to support Suite B. This
example uses an HPE switch as an Stelnet client.
# Upload the server's certificate file ssh-server-ecdsa256.p12 and the client's certificate file
ssh-client-ecdsa256.p12 to the Stelnet client through FTP or TFTP. (Details not shown.)
# Create a PKI domain named server256 for verifying the server's certificate and enter its view.
<SwitchA> system-view

516
[SwitchA] pki domain server256
# Disable CRL checking.
[SwitchA-pki-domain-server256] undo crl check enable
[SwitchA-pki-domain-server256] quit
# Import local certificate file ssh-server-ecdsa256.p12 to PKI domain server256.
[SwitchA] pki import domain server256 p12 local filename ssh-server-ecdsa256.p12
The system is going to save the key pair. You must specify a key pair name, which is
a case-insensitive string of 1 to 64 characters. Valid characters include a to z, A
to Z, 0 to 9, and hyphens (-).
Please enter the key pair name[default name: server256]:
# Display information about local certificates in PKI domain server256.
[SwitchA] display pki certificate domain server256 local
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=CN, ST=Beijing, L=Beijing, O=HPE, OU=Software, CN=SuiteB CA
Validity
Not Before: Aug 21 08:39:51 2015 GMT
Not After : Aug 20 08:39:51 2016 GMT
Subject: C=CN, ST=Beijing, O=HPE, OU=Software, CN=SSH Server secp256
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:a2:b4:b4:66:1e:3b:d5:50:50:0e:55:19:8d:52:
6d:47:8c:3d:3d:96:75:88:2f:9a:ba:a2:a7:f9:ef:
0a:a9:20:b7:b6:6a:90:0e:f8:c6:de:15:a2:23:81:
3c:9e:a2:b7:83:87:b9:ad:28:c8:2a:5e:58:11:8e:
c7:61:4a:52:51
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
08:C1:F1:AA:97:45:19:6A:DA:4A:F2:87:A1:1A:E8:30:BD:31:30:D7
X509v3 Authority Key Identifier:
keyid:5A:BE:85:49:16:E5:EB:33:80:25:EB:D8:91:50:B4:E6:3E:4F:B8:22

Signature Algorithm: ecdsa-with-SHA256

30:65:02:31:00:a9:16:e9:c1:76:f0:32:fc:4b:f9:8f:b6:7f:
31:a0:9f:de:a7:cc:33:29:27:2c:71:2e:f9:0d:74:cb:25:c9:
00:d2:52:18:7f:58:3f:cc:7e:8b:d3:42:65:00:cb:63:f8:02:
30:01:a2:f6:a1:51:04:1c:61:78:f6:6b:7e:f9:f9:42:8d:7c:

517
 a7:bb:47:7c:2a:85:67:0d:81:12:0b:02:98:bc:06:1f:c1:3c:
9b:c2:1b:4c:44:38:5a:14:b2:48:63:02:2b
# Create a PKI domain named client256 for the client's certificate and enter its view.
[SwitchA] pki domain client256
# Disable CRL checking.
[SwitchA-pki-domain-client256] undo crl check enable
[SwitchA-pki-domain-client256] quit
# Import local certificate file ssh-client-ecdsa256.p12 to PKI domain client256.
[SwitchA] pki import domain client256 p12 local filename ssh-client-ecdsa256.p12
The system is going to save the key pair. You must specify a key pair name, which is
a case-insensitive string of 1 to 64 characters. Valid characters include a to z, A
to Z, 0 to 9, and hyphens (-).
Please enter the key pair name[default name: client256]:
# Display information about local certificates in PKI domain client256.
[SwitchA] display pki certificate domain client256 local
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4 (0x4)
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=CN, ST=Beijing, L=Beijing, O=HPE, OU=Software, CN=SuiteB CA
Validity
Not Before: Aug 21 08:41:09 2015 GMT
Not After : Aug 20 08:41:09 2016 GMT
Subject: C=CN, ST=Beijing, O=HPE, OU=Software, CN=SSH Client secp256
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:da:e2:26:45:87:7a:63:20:e7:ca:7f:82:19:f5:
96:88:3e:25:46:f8:2f:9a:4c:70:61:35:db:e4:39:
b8:38:c4:60:4a:65:28:49:14:32:3c:cc:6d:cd:34:
29:83:84:74:a7:2d:0e:75:1c:c2:52:58:1e:22:16:
12:d0:b4:8a:92
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
1A:61:60:4D:76:40:B8:BA:5D:A1:3C:60:BC:57:98:35:20:79:80:FC
X509v3 Authority Key Identifier:
keyid:5A:BE:85:49:16:E5:EB:33:80:25:EB:D8:91:50:B4:E6:3E:4F:B8:22

Signature Algorithm: ecdsa-with-SHA256

30:66:02:31:00:9a:6d:fd:7d:ab:ae:54:9a:81:71:e6:bb:ad:

518
 5a:2e:dc:1d:b3:8a:bf:ce:ee:71:4e:8f:d9:93:7f:a3:48:a1:
5c:17:cb:22:fa:8f:b3:e5:76:89:06:9f:96:47:dc:34:87:02:
31:00:e3:af:2a:8f:d6:8d:1f:3a:2b:ae:2f:97:b3:52:63:b6:
18:67:70:2c:93:2a:41:c0:e7:fa:93:20:09:4d:f4:bf:d0:11:
66:0f:48:56:01:1e:c3:be:37:4e:49:19:cf:c6
# Assign an IP address to VLAN-interface 2.
<SwitchA> system-view
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 192.168.1.56 255.255.255.0
[SwitchA-Vlan-interface2] quit
3. Configure the Stelnet server:
# Upload the server's certificate file ssh-server-ecdsa256.p12 and the client's certificate file
ssh-client-ecdsa256.p12 to the Stelnet server through FTP or TFTP. (Details not shown.)
# Create a PKI domain named client256 for verifying the client's certificate and import the file of
the client's certificate to this domain. (Details not shown.)
# Create a PKI domain named server256 for the server's certificate and import the file of the
server's certificate to this domain. (Details not shown.)
# Specify Suite B algorithms for algorithm negotiation.
<SwitchB> system-view
[SwitchB] ssh2 algorithm key-exchange ecdh-sha2-nistp256
[SwitchB] ssh2 algorithm cipher aes128-gcm
[SwitchB] ssh2 algorithm public-key x509v3-ecdsa-sha2-nistp256
x509v3-ecdsa-sha2-nistp384
# Specify server256 as the PKI domain of the server's certificate.
[SwitchB] ssh server pki-domain server256
# Enable the Stelnet server.
[SwitchB] ssh server enable
# Assign an IP address to VLAN-interface 2.
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ip address 192.168.1.40 255.255.255.0
[SwitchB-Vlan-interface2] quit
# Set the authentication mode to AAA for user lines.
[SwitchB] line vty 0 63
[SwitchB-line-vty0-63] authentication-mode scheme
[SwitchB-line-vty0-63] quit
# Create a local device management user named client001. Authorize the user to use the SSH
service and assign the network-admin user role to the user.
[SwitchB] local-user client001 class manage
[SwitchB-luser-manage-client001] service-type ssh
[SwitchB-luser-manage-client001] authorization-attribute user-role network-admin
[SwitchB-luser-manage-client001] quit
# Create an SSH user named client001. Specify the publickey authentication method for the
user and specify client256 as the PKI domain for verifying the client's certificate.
[SwitchB] ssh user client001 service-type stelnet authentication-type publickey
assign pki-domain client256
4. Establish an SSH connection to the Stelnet server based on the 128-bit Suite B algorithms:
# Establish an SSH connection to the server at 192.168.1.40.

519
 <SwitchA> ssh2 192.168.1.40 suite-b 128-bit pki-domain client256 server-pki-domain
server256
Username: client001
Press CTRL+C to abort.
Connecting to 192.168.1.40 port 22.
Enter a character ~ and a dot to abort.

******************************************************************************
* Copyright (c) 2004-2017 Hewlett-Packard Enterprise Development L.P. *
* Without the owner's prior written consent, *
* no decompiling or reverse-engineering shall be allowed. *
******************************************************************************

<SwitchB>

SFTP configuration examples

Unless otherwise noted, devices in the configuration examples operate in non-FIPS mode.
When the device acts as an SFTP server operating in FIPS mode, only ECDSA and RSA key pairs
are supported. Do not generate a DSA key pair on the SFTP server.

Example: Configuring the device as an SFTP server

(password authentication)
Network configuration
As shown in Figure 127:
• The switch acts as the SFTP server and uses password authentication to authenticate the
SFTP client. The username and password of the client are saved on the switch.
• The host acts as the SFTP client. After the user on the client logs in to the switch through SFTP,
the user can perform file management and transfer operations on the switch as a network
administrator.
Figure 127 Network diagram
SFTP client SFTP server
Vlan-int2
192.168.1.56/24 192.168.1.45/24

Host Switch

Procedure
1. Configure the SFTP server:
# Generate RSA key pairs.
<Switch> system-view
[Switch] public-key local create rsa
The range of public key modulus is (512 ~ 4096).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:

520
 Generating Keys...
........................++++++
...................++++++
..++++++++
............++++++++
Create the key pair successfully.
# Generate a DSA key pair.
[Switch] public-key local create dsa
The range of public key modulus is (512 ~ 2048).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
.++++++++++++++++++++++++++++++++++++++++++++++++++*
........+......+.....+......................................+
...+.................+..........+...+
Create the key pair successfully.
# Generate an ECDSA key pair.
[Switch] public-key local create ecdsa secp256r1
Generating Keys...
.
Create the key pair successfully.
# Enable the SFTP server.
[Switch] sftp server enable
# Assign an IP address to VLAN-interface 2. The client uses this address as the destination for
SSH connection.
[Switch] interface vlan-interface 2
[Switch-Vlan-interface2] ip address 192.168.1.45 255.255.255.0
[Switch-Vlan-interface2] quit
# Create a local device management user named client002.
[Switch] local-user client002 class manage
# Set the password to hello12345 in plain text for local user client002.
[Switch-luser-manage-client002] password simple hello12345
# Authorize local user client002 to use the SSH service.
[Switch-luser-manage-client002] service-type ssh
# Assign the network-admin user role and working directory flash:/ to local user client002.
[Switch-luser-manage-client002] authorization-attribute user-role network-admin
work-directory flash:/
[Switch-luser-manage-client002] quit
# Create an SSH user named client002. Specify the authentication method as password and
service type as sftp for the user.
[Switch] ssh user client002 service-type sftp authentication-type password
2. Establish a connection between the SFTP client and the SFTP server:
This example uses an SFTP client that runs PSFTP of PuTTy version 0.58. PSFTP supports
only password authentication.
To establish a connection to the SFTP server:
a. Run the psftp.exe to launch the client interface shown in Figure 128, and enter the following
command:

521
 open 192.168.1.45
b. Enter username client002 and password hello12345 to log in to the SFTP server.
Figure 128 SFTP client interface

Example: Configuring the device as an SFTP client

(publickey authentication)
Network configuration
As shown in Figure 129:
• Switch B acts as the SFTP server, and it uses publickey authentication and the RSA public key
algorithm.
• Switch A acts as the SFTP client. After the user on Switch A logs in to Switch B through SFTP,
the user can perform file management and transfer operations on Switch B as a network
administrator.
Figure 129 Network diagram
SFTP client SFTP server
Vlan-int2 Vlan-int2
192.168.0.2/24 192.168.0.1/24

Switch A Switch B

Procedure
In the server configuration, the client's host public key is required. Generate RSA key pairs on the
client before configuring the SFTP server.
1. Configure the SFTP client:
# Assign an IP address to VLAN-interface 2.
<SwitchA> system-view
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 192.168.0.2 255.255.255.0

522
 [SwitchA-Vlan-interface2] quit
# Generate RSA key pairs.
[SwitchA] public-key local create rsa
The range of public key size is (512 ~ 4096).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
........................++++++
...................++++++
..++++++++
............++++++++
Create the key pair successfully.
# Export the host public key to a public key file named pubkey.
[SwitchA] public-key local export rsa ssh2 pubkey
[SwitchA] quit
# Transmit the public key file pubkey to the server through FTP or TFTP. (Details not shown.)
2. Configure the SFTP server:
# Generate RSA key pairs.
<SwitchB> system-view
[SwitchB] public-key local create rsa
The range of public key size is (512 ~ 4096).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
........................++++++
...................++++++
..++++++++
............++++++++
Create the key pair successfully.
# Generate a DSA key pair.
[SwitchB] public-key local create dsa
The range of public key size is (512 ~ 2048).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
.++++++++++++++++++++++++++++++++++++++++++++++++++*
........+......+.....+......................................+
...+.................+..........+...+
Create the key pair successfully.
# Generate an ECDSA key pair.
[SwitchB] public-key local create ecdsa secp256r1
Generating Keys...
.
Create the key pair successfully.
# Enable the SFTP server.

523
 [SwitchB] sftp server enable
# Assign an IP address to VLAN-interface 2. The SSH client uses this address as the
destination for SSH connection.
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ip address 192.168.0.1 255.255.255.0
[SwitchB-Vlan-interface2] quit
# Import the peer public key from the public key file pubkey, and name it switchkey.
[SwitchB] public-key peer switchkey import sshkey pubkey
# Create an SSH user named client001. Specify the service type as sftp and the authentication
method as publickey for the user. Assign the public key switchkey to the user.
[SwitchB] ssh user client001 service-type sftp authentication-type publickey assign
publickey switchkey
# Create a local device management user named client001.
[SwitchB] local-user client001 class manage
# Authorize local user client001 to use the SSH service.
[SwitchB-luser-manage-client001] service-type ssh
# Assign the network-admin user role and working directory flash:/ to local user client001.
[SwitchB-luser-manage-client001] authorization-attribute user-role network-admin
work-directory flash:/
[SwitchB-luser-manage-client001] quit
3. Establish a connection to the SFTP server:
# Establish a connection to the SFTP server and enter SFTP client view.
<SwitchA> sftp 192.168.0.1 identity-key rsa
Username: client001
Press CTRL+C to abort.
Connecting to 192.168.0.1 port 22.
The server is not authenticated. Continue? [Y/N]:y
Do you want to save the server public key? [Y/N]:n
sftp>
# Display files under the current directory of the server, delete file z, and verify the result.
sftp> dir -l
-rwxrwxrwx 1 noone nogroup 1759 Aug 23 06:52 config.cfg
-rwxrwxrwx 1 noone nogroup 225 Aug 24 08:01 pubkey2
-rwxrwxrwx 1 noone nogroup 283 Aug 24 07:39 pubkey
drwxrwxrwx 1 noone nogroup 0 Sep 01 06:22 new
-rwxrwxrwx 1 noone nogroup 225 Sep 01 06:55 pub
-rwxrwxrwx 1 noone nogroup 0 Sep 01 08:00 z
sftp> delete z
Removing /z
sftp> dir -l
-rwxrwxrwx 1 noone nogroup 1759 Aug 23 06:52 config.cfg
-rwxrwxrwx 1 noone nogroup 225 Aug 24 08:01 pubkey2
-rwxrwxrwx 1 noone nogroup 283 Aug 24 07:39 pubkey
drwxrwxrwx 1 noone nogroup 0 Sep 01 06:22 new
-rwxrwxrwx 1 noone nogroup 225 Sep 01 06:55 pub
# Add a directory named new1 and verify the result.
sftp> mkdir new1
sftp> dir -l

524
 -rwxrwxrwx 1 noone nogroup 1759 Aug 23 06:52 config.cfg
-rwxrwxrwx 1 noone nogroup 225 Aug 24 08:01 pubkey2
-rwxrwxrwx 1 noone nogroup 283 Aug 24 07:39 pubkey
drwxrwxrwx 1 noone nogroup 0 Sep 01 06:22 new
-rwxrwxrwx 1 noone nogroup 225 Sep 01 06:55 pub
drwxrwxrwx 1 noone nogroup 0 Sep 02 06:30 new1
# Change the name of directory new1 to new2 and verify the result.
sftp> rename new1 new2
sftp> dir -l
-rwxrwxrwx 1 noone nogroup 1759 Aug 23 06:52 config.cfg
-rwxrwxrwx 1 noone nogroup 225 Aug 24 08:01 pubkey2
-rwxrwxrwx 1 noone nogroup 283 Aug 24 07:39 pubkey
drwxrwxrwx 1 noone nogroup 0 Sep 01 06:22 new
-rwxrwxrwx 1 noone nogroup 225 Sep 01 06:55 pub
drwxrwxrwx 1 noone nogroup 0 Sep 02 06:33 new2
# Download file pubkey2 from the server and save it as a local file named public.
sftp> get pubkey2 public
Fetching / pubkey2 to public
/pubkey2 100% 225 1.4KB/s 00:00
# Upload the local file pu to the server, save it as puk, and verify the result.
sftp> put pu puk
Uploading pu to / puk
sftp> dir -l
-rwxrwxrwx 1 noone nogroup 1759 Aug 23 06:52 config.cfg
-rwxrwxrwx 1 noone nogroup 225 Aug 24 08:01 pubkey2
-rwxrwxrwx 1 noone nogroup 283 Aug 24 07:39 pubkey
drwxrwxrwx 1 noone nogroup 0 Sep 01 06:22 new
drwxrwxrwx 1 noone nogroup 0 Sep 02 06:33 new2
-rwxrwxrwx 1 noone nogroup 283 Sep 02 06:35 pub
-rwxrwxrwx 1 noone nogroup 283 Sep 02 06:36 puk
sftp>
# Exit SFTP client view.
sftp> quit
<SwitchA>

Example: Configuring SFTP based on 192-bit Suite B

algorithms
Network configuration
As shown in Figure 130:
• Switch B acts as the SFTP Suite B server (SSH2), and it uses publickey authentication to
authenticate the SFTP client.
• Switch A acts as an SFTP Suite B client (SSH2). After the user on Switch A logs in to Switch B
based on the SFTP Suite B client software, the user can manage and transfer files on Switch B
as an administrator.

525
 Figure 130 Network diagram
SFTP client SFTP server
Vlan-int2 Vlan-int2
192.168.0.2/24 192.168.0.1/24

Switch A Switch B

Procedure
1. Generate the client's certificate and the server's certificate. (Details not shown.)
You must first configure the certificates of the server and the client because they are required
for identity authentication between the two parties.
In this example, the server's certificate file is ssh-server-ecdsa384.p12 and the client's
certificate file is ssh-client-ecdsa384.p12.
2. Configure the SFTP client:
You can modify the pkix version of the client software OpenSSH to support Suite B. This
example uses an HPE switch as an SFTP client.
# Upload the server's certificate file ssh-server-ecdsa384.p12 and the client's certificate file
ssh-client-ecdsa384.p12 to the SFTP client through FTP or TFTP. (Details not shown.)
# Create a PKI domain named server384 for verifying the server's certificate and enter its view.
<SwitchA> system-view
[SwitchA] pki domain server384
# Disable CRL checking.
[SwitchA-pki-domain-server384] undo crl check enable
[SwitchA-pki-domain-server384] quit
# Import local certificate file ssh-server-ecdsa384.p12 to PKI domain server384.
[SwitchA] pki import domain server384 p12 local filename ssh-server-ecdsa384.p12
The system is going to save the key pair. You must specify a key pair name, which is
a case-insensitive string of 1 to 64 characters. Valid characters include a to z, A
to Z, 0 to 9, and hyphens (-).
Please enter the key pair name[default name: server384]:
# Display information about local certificates in PKI domain server384.
[SwitchA] display pki certificate domain server384 local
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: ecdsa-with-SHA384
Issuer: C=CN, ST=Beijing, L=Beijing, O=HPE, OU=Software, CN=SuiteB CA
Validity
Not Before: Aug 20 10:08:41 2015 GMT
Not After : Aug 19 10:08:41 2016 GMT
Subject: C=CN, ST=Beijing, O=HPE, OU=Software, CN=ssh server
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:4a:33:e5:99:8d:49:45:a7:a3:24:7b:32:6a:ed:
b6:36:e1:4d:cc:8c:05:22:f4:3a:7c:5d:b7:be:d1:
e6:9e:f0:ce:95:39:ca:fd:a0:86:cd:54:ab:49:60:

526
 10:be:67:9f:90:3a:18:e2:7d:d9:5f:72:27:09:e7:
bf:7e:64:0a:59:bb:b3:7d:ae:88:14:94:45:b9:34:
d2:f3:93:e1:ba:b4:50:15:eb:e5:45:24:31:10:c7:
07:01:f9:dc:a5:6f:81
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
10:16:64:2C:DA:C1:D1:29:CD:C0:74:40:A9:70:BD:62:8A:BB:F4:D5
X509v3 Authority Key Identifier:
keyid:5A:BE:85:49:16:E5:EB:33:80:25:EB:D8:91:50:B4:E6:3E:4F:B8:22

Signature Algorithm: ecdsa-with-SHA384

30:65:02:31:00:80:50:7a:4f:c5:cd:6a:c3:57:13:7f:e9:da:
c1:72:7f:45:30:17:c2:a7:d3:ec:73:3d:5f:4d:e3:96:f6:a3:
33:fb:e4:b9:ff:47:f1:af:9d:e3:03:d2:24:53:40:09:5b:02:
30:45:d1:bf:51:fd:da:22:11:90:03:f9:d4:05:ec:d6:7c:41:
fc:9d:a1:fd:5b:8c:73:f8:b6:4c:c3:41:f7:c6:7f:2f:05:2d:
37:f8:52:52:26:99:28:97:ac:6e:f9:c7:01
# Create a PKI domain named client384 for the client's certificate and enter its view.
[SwitchA] pki domain client384
# Disable CRL checking.
[SwitchA-pki-domain-client384] undo crl check enable
[SwitchA-pki-domain-client384] quit
# Import local certificate file ssh-client-ecdsa384.p12 to PKI domain client384.
[SwitchA] pki import domain client384 p12 local filename ssh-client-ecdsa384.p12
The system is going to save the key pair. You must specify a key pair name, which is
a case-insensitive string of 1 to 64 characters. Valid characters include a to z, A
to Z, 0 to 9, and hyphens (-).
Please enter the key pair name[default name: client384]:
# Display information about local certificates in PKI domain client384.
[SwitchA]display pki certificate domain client384 local
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: ecdsa-with-SHA384
Issuer: C=CN, ST=Beijing, L=Beijing, O=HPE, OU=Software, CN=SuiteB CA
Validity
Not Before: Aug 20 10:10:59 2015 GMT
Not After : Aug 19 10:10:59 2016 GMT
Subject: C=CN, ST=Beijing, O=HPE, OU=Software, CN=ssh client
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey

527
 Public-Key: (384 bit)
pub:
04:85:7c:8b:f4:7a:36:bf:74:f6:7c:72:f9:08:69:
d0:b9:ac:89:98:17:c9:fc:89:94:43:da:9a:a6:89:
41:d3:72:24:9b:9a:29:a8:d1:ba:b4:e5:77:ba:fc:
df:ae:c6:dd:46:72:ab:bc:d1:7f:18:7d:54:88:f6:
b4:06:54:7e:e7:4d:49:b4:07:dc:30:54:4b:b6:5b:
01:10:51:6b:0c:6d:a3:b1:4b:c9:d9:6c:d6:be:13:
91:70:31:2a:92:00:76
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
BD:5F:8E:4F:7B:FE:74:03:5A:D1:94:DB:CA:A7:82:D6:F7:78:A1:B0
X509v3 Authority Key Identifier:
keyid:5A:BE:85:49:16:E5:EB:33:80:25:EB:D8:91:50:B4:E6:3E:4F:B8:22

Signature Algorithm: ecdsa-with-SHA384

30:66:02:31:00:d2:06:fa:2c:0b:0d:f0:81:90:01:c3:3d:bf:
97:b3:79:d8:25:a0:e2:0e:ed:00:c9:48:3e:c9:71:43:c9:b4:
2a:a6:0a:27:80:9e:d4:0f:f2:db:db:5b:40:b1:a9:0a:e4:02:
31:00:ee:00:e1:07:c0:2f:12:3f:88:ea:fe:19:05:ef:56:ca:
33:71:75:5e:11:c9:a6:51:4b:3e:7c:eb:2a:4d:87:2b:71:7c:
30:64:fe:14:ce:06:d5:0a:e2:cf:9a:69:19:ff
# Assign an IP address to VLAN-interface 2.
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 192.168.0.2 255.255.255.0
[SwitchA-Vlan-interface2] quit
[SwitchA] quit
3. Configure the SFTP server:
# Upload the server's certificate file ssh-server-ecdsa384.p12 and the client's certificate file
ssh-client-ecdsa384.p12 to the SFTP server through FTP or TFTP. (Details not shown.)
# Create a PKI domain named client384 for verifying the client's certificate and import the file of
the client's certificate to this domain. (Details not shown.)
# Create a PKI domain named server384 for the server's certificate and import the file of the
server's certificate to this domain. (Details not shown.)
# Specify Suite B algorithms for algorithm negotiation.
[SwitchB] ssh2 algorithm key-exchange ecdh-sha2-nistp384
[SwitchB] ssh2 algorithm cipher aes256-gcm
[SwitchB] ssh2 algorithm public-key x509v3-ecdsa-sha2-nistp384
# Specify server384 as the PKI domain of the server's certificate.
[SwitchB] ssh server pki-domain server384
# Enable the SFTP server.
[SwitchB] sftp server enable

528
 # Assign an IP address to VLAN-interface 2.
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ip address 192.168.0.1 255.255.255.0
[SwitchB-Vlan-interface2] quit
# Set the authentication mode to AAA for user lines.
[SwitchB] line vty 0 63
[SwitchB-line-vty0-63] authentication-mode scheme
[SwitchB-line-vty0-63] quit
# Create a local device management user named client001. Authorize the user to use the SSH
service and assign the network-admin user role to the user.
[SwitchB] local-user client001 class manage
[SwitchB-luser-manage-client001] service-type ssh
[SwitchB-luser-manage-client001] authorization-attribute user-role network-admin
[SwitchB-luser-manage-client001] quit
# Create an SSH user named client001. Specify the publickey authentication method for the
user and specify client384 as the PKI domain for verifying the client's certificate.
[SwitchB] ssh user client001 service-type sftp authentication-type publickey assign
pki-domain client384
4. Establish an SFTP connection to the SFTP server based on the 192-bit Suite B algorithms:
# Establish an SFTP connection to the server at 192.168.0.1.
<SwitchA> sftp 192.168.0.1 suite-b 192-bit pki-domain client384 server-pki-domain
server384
Username: client001
Press CTRL+C to abort.
Connecting to 192.168.0.1 port 22.
sftp>

SCP configuration examples

Unless otherwise noted, devices in the configuration examples operate in non-FIPS mode.
When the device acts as an SCP server operating in FIPS mode, only ECDSA and RSA key pairs are
supported. Do not generate a DSA key pair on the SCP server.

Example: Configuring SCP with password authentication

Network configuration
As shown in Figure 131:
• Switch B acts as the SCP server and uses password authentication to authenticate the SCP
client. The client's username and password are saved on Switch B.
• Switch A acts as the SCP client. After the user on Switch A logs in to Switch B through SCP, the
user can transfer files between switches as a network administrator.
Figure 131 Network diagram
SCP client SCP server
Vlan-int2 Vlan-int2
192.168.0.2/24 192.168.0.1/24

Switch A Switch B

529
Procedure
1. Configure the SCP server:
# Generate RSA key pairs.
<SwitchB> system-view
[SwitchB] public-key local create rsa
The range of public key modulus is (512 ~ 4096).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
........................++++++
...................++++++
..++++++++
............++++++++
Create the key pair successfully.
# Generate a DSA key pair.
[SwitchB] public-key local create dsa
The range of public key modulus is (512 ~ 2048).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
.++++++++++++++++++++++++++++++++++++++++++++++++++*
........+......+.....+......................................+
...+.................+..........+...+.
Create the key pair successfully.
# Generate an ECDSA key pair.
[SwitchB] public-key local create ecdsa secp256r1
Generating Keys...
.
Create the key pair successfully.
# Enable the SCP server.
[SwitchB] scp server enable
# Configure an IP address for VLAN-interface 2. The client uses this address as the destination
for SCP connection.
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ip address 192.168.0.1 255.255.255.0
[SwitchB-Vlan-interface2] quit
# Create a local device management user named client001.
[SwitchB] local-user client001 class manage
# Set the password to hello12345 in plain text for local user client001.
[SwitchB-luser-manage-client001] password simple hello12345
# Authorize local user client001 to use the SSH service.
[SwitchB-luser-manage-client001] service-type ssh
# Assign the network-admin user role to local user client001.
[SwitchB-luser-manage-client001] authorization-attribute user-role network-admin
[SwitchB-luser-manage-client001] quit

530
 # Create an SSH user named client001. Specify the service type as scp and the authentication
method as password for the user.
[SwitchB] ssh user client001 service-type scp authentication-type password
2. Configure an IP address for VLAN-interface 2 on the SCP client.
<SwitchA> system-view
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 192.168.0.2 255.255.255.0
[SwitchA-Vlan-interface2] quit
[SwitchA] quit
3. Connect to the SCP server, download file remote.bin from the server, and save it as a local file
named local.bin.
<SwitchA> scp 192.168.0.1 get remote.bin local.bin
Username: client001
Press CTRL+C to abort.
Connecting to 192.168.0.1 port 22.
The server is not authenticated. Continue? [Y/N]:y
Do you want to save the server public key? [Y/N]:n
[email protected]’s password:
remote.bin 100% 2875 2.8KB/s 00:00

Example: Configuring SCP file transfer with a Linux SCP

client
Network configuration
As shown in Figure 132, the switch acts as the SCP server and uses password authentication to
authenticate the SCP client. The client's username and password are saved on the switch.
The device acts as the SCP client. After the user on the device logs in to the switch through SCP, the
user can transfer files with the switch as a network administrator.
Figure 132 Network diagram
SCP client SCP server
Vlan-int2 Vlan-int2
192.168.0.2/24 192.168.0.1/24

Device Switch

Procedure
1. Configure the SCP server:
# Generate an RSA key pair.
<Switch> system-view
[Switch] public-key local create rsa
The range of public key modulus is (512 ~ 4096).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
........................++++++
...................++++++
..++++++++

531
 ............++++++++
Create the key pair successfully.
# Generate a DSA key pair.
[Switch] public-key local create dsa
The range of public key modulus is (512 ~ 2048).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
.++++++++++++++++++++++++++++++++++++++++++++++++++*
........+......+.....+......................................+
...+.................+..........+...+.
Create the key pair successfully.
# Generate an ECDSA key pair.
[Switch] public-key local create ecdsa secp256r1
Generating Keys...
.
Create the key pair successfully.
# Enable the SCP server.
[Switch] scp server enable
# Configure an IP address for VLAN interface 2. The SCP client uses this IP address as the
destination address of the SCP connection.
[Switch] interface vlan-interface 2
[Switch-Vlan-interface2] ip address 192.168.0.1 255.255.255.0
[Switch-Vlan-interface2] quit
# Create a local device management user named client001. Set a password for the user,
authorize the user to use the SSH service, assign the network-admin user role to the user, and
specify the working directory as flash:/.
[Switch] local-user client001 class manage
[Switch-luser-manage-client001] password simple 123456TESTplat&!
[Switch-luser-manage-client001] service-type ssh
[Switch-luser-manage-client001] authorization-attribute user-role network-admin
work-directory flash:/
[Switch-luser-manage-client001] quit
# Configure an SSH user named client001, specify the SCP service for the SSH user, and set
the authentication method as password. (This step is optional.)
[Switch] ssh user client001 service-type scp authentication-type password
2. Configure the SCP client:
The following uses the SCP client running on a Linux system as an example:
# Connect to the SCP server, download the remote.bin file from the server, and save it as a
local file named local.bin.
admin@device:~# scp [email protected]:remote.bin local.bin
[email protected]'s password:
remote.bin 100% 15
0.0KB/s 00:00

532
Example: Configuring SCP based on Suite B algorithms
Network configuration
As shown in Figure 133:
• Switch B acts as the SCP Suite B server (SSH2), and it uses publickey authentication to
authenticate the SCP client.
• Switch A acts as an SCP Suite B client (SSH2). After the user on Switch A logs in to Switch B
through the SCP Suite B client software, the user can transfer files between switches as a
network administrator.
Figure 133 Network diagram
SCP client SCP server
Vlan-int2 Vlan-int2
192.168.0.2/24 192.168.0.1/24

Switch A Switch B

Procedure
1. Generate the client's certificates and the server's certificates. (Details not shown.)
You must first configure the certificates of the server and the client because they are required
for identity authentication between the two parties.
In this example, the server's certificate files are ssh-server-ecdsa256.p12 and
ssh-server-ecdsa384.p12. The client's certificate files are ssh-client-ecdsa256.p12 and
ssh-client-ecdsa384.p12.
2. Configure the SCP client:
You can modify the pkix version of the client software OpenSSH to support Suite B. This
example uses an HPE switch as an SCP client.
# Upload the server's certificate files (ssh-server-ecdsa256.p12 and
ssh-server-ecdsa384.p12) and the client's certificate files (ssh-client-ecdsa256.p12 and
ssh-client-ecdsa384.p12) to the SCP client through FTP or TFTP. (Details not shown.)
# Create a PKI domain named server256 for verifying the server's certificate ecdsa256 and
enter its view.
<SwitchA> system-view
[SwitchA] pki domain server256
# Disable CRL checking.
[SwitchA-pki-domain-server256] undo crl check enable
[SwitchA-pki-domain-server256] quit
# Import local certificate file ssh-server-ecdsa256.p12 to PKI domain server256.
[SwitchA] pki import domain server256 p12 local filename ssh-server-ecdsa256.p12
The system is going to save the key pair. You must specify a key pair name, which is
a case-insensitive string of 1 to 64 characters. Valid characters include a to z, A
to Z, 0 to 9, and hyphens (-).
Please enter the key pair name[default name: server256]:
# Display information about local certificates in PKI domain server256.
[SwitchA] display pki certificate domain server256 local
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: ecdsa-with-SHA256

533
 Issuer: C=CN, ST=Beijing, L=Beijing, O=HPE, OU=Software, CN=SuiteB CA
Validity
Not Before: Aug 21 08:39:51 2015 GMT
Not After : Aug 20 08:39:51 2016 GMT
Subject: C=CN, ST=Beijing, O=HPE, OU=Software, CN=SSH Server secp256
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:a2:b4:b4:66:1e:3b:d5:50:50:0e:55:19:8d:52:
6d:47:8c:3d:3d:96:75:88:2f:9a:ba:a2:a7:f9:ef:
0a:a9:20:b7:b6:6a:90:0e:f8:c6:de:15:a2:23:81:
3c:9e:a2:b7:83:87:b9:ad:28:c8:2a:5e:58:11:8e:
c7:61:4a:52:51
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
08:C1:F1:AA:97:45:19:6A:DA:4A:F2:87:A1:1A:E8:30:BD:31:30:D7
X509v3 Authority Key Identifier:
keyid:5A:BE:85:49:16:E5:EB:33:80:25:EB:D8:91:50:B4:E6:3E:4F:B8:22

Signature Algorithm: ecdsa-with-SHA256

30:65:02:31:00:a9:16:e9:c1:76:f0:32:fc:4b:f9:8f:b6:7f:
31:a0:9f:de:a7:cc:33:29:27:2c:71:2e:f9:0d:74:cb:25:c9:
00:d2:52:18:7f:58:3f:cc:7e:8b:d3:42:65:00:cb:63:f8:02:
30:01:a2:f6:a1:51:04:1c:61:78:f6:6b:7e:f9:f9:42:8d:7c:
a7:bb:47:7c:2a:85:67:0d:81:12:0b:02:98:bc:06:1f:c1:3c:
9b:c2:1b:4c:44:38:5a:14:b2:48:63:02:2b
# Create a PKI domain named client256 for the client's certificate ecdsa256 and enter its view.
[SwitchA] pki domain client256
# Disable CRL checking.
[SwitchA-pki-domain-client256] undo crl check enable
[SwitchA-pki-domain-client256] quit
# Import local certificate file ssh-client-ecdsa256.p12 to PKI domain client256.
[SwitchA] pki import domain client256 p12 local filename ssh-client-ecdsa256.p12
The system is going to save the key pair. You must specify a key pair name, which is
a case-insensitive string of 1 to 64 characters. Valid characters include a to z, A
to Z, 0 to 9, and hyphens (-).
Please enter the key pair name[default name: client256]:
# Display information about local certificates in PKI domain client256.
[SwitchA] display pki certificate domain client256 local
Certificate:
Data:

534
 Version: 3 (0x2)
Serial Number: 4 (0x4)
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=CN, ST=Beijing, L=Beijing, O=HPE, OU=Software, CN=SuiteB CA
Validity
Not Before: Aug 21 08:41:09 2015 GMT
Not After : Aug 20 08:41:09 2016 GMT
Subject: C=CN, ST=Beijing, O=HPE, OU=Software, CN=SSH Client secp256
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:da:e2:26:45:87:7a:63:20:e7:ca:7f:82:19:f5:
96:88:3e:25:46:f8:2f:9a:4c:70:61:35:db:e4:39:
b8:38:c4:60:4a:65:28:49:14:32:3c:cc:6d:cd:34:
29:83:84:74:a7:2d:0e:75:1c:c2:52:58:1e:22:16:
12:d0:b4:8a:92
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
1A:61:60:4D:76:40:B8:BA:5D:A1:3C:60:BC:57:98:35:20:79:80:FC
X509v3 Authority Key Identifier:
keyid:5A:BE:85:49:16:E5:EB:33:80:25:EB:D8:91:50:B4:E6:3E:4F:B8:22

Signature Algorithm: ecdsa-with-SHA256

30:66:02:31:00:9a:6d:fd:7d:ab:ae:54:9a:81:71:e6:bb:ad:
5a:2e:dc:1d:b3:8a:bf:ce:ee:71:4e:8f:d9:93:7f:a3:48:a1:
5c:17:cb:22:fa:8f:b3:e5:76:89:06:9f:96:47:dc:34:87:02:
31:00:e3:af:2a:8f:d6:8d:1f:3a:2b:ae:2f:97:b3:52:63:b6:
18:67:70:2c:93:2a:41:c0:e7:fa:93:20:09:4d:f4:bf:d0:11:
66:0f:48:56:01:1e:c3:be:37:4e:49:19:cf:c6
# Create a PKI domain named server384 for verifying the server's certificate ecdsa384 and
enter its view.
[SwitchA] pki domain server384
# Disable CRL checking.
[SwitchA-pki-domain-server384] undo crl check enable
[SwitchA-pki-domain-server384] quit
# Import local certificate file ssh-server-ecdsa384.p12 to PKI domain server384.
[SwitchA] pki import domain server384 p12 local filename ssh-server-ecdsa384.p12
The system is going to save the key pair. You must specify a key pair name, which is
a case-insensitive string of 1 to 64 characters. Valid characters include a to z, A
to Z, 0 to 9, and hyphens (-).
Please enter the key pair name[default name: server384]:

535
# Display information about local certificates in PKI domain server384.
[SwitchA] display pki certificate domain server384 local
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: ecdsa-with-SHA384
Issuer: C=CN, ST=Beijing, L=Beijing, O=HPE, OU=Software, CN=SuiteB CA
Validity
Not Before: Aug 20 10:08:41 2015 GMT
Not After : Aug 19 10:08:41 2016 GMT
Subject: C=CN, ST=Beijing, O=HPE, OU=Software, CN=ssh server
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:4a:33:e5:99:8d:49:45:a7:a3:24:7b:32:6a:ed:
b6:36:e1:4d:cc:8c:05:22:f4:3a:7c:5d:b7:be:d1:
e6:9e:f0:ce:95:39:ca:fd:a0:86:cd:54:ab:49:60:
10:be:67:9f:90:3a:18:e2:7d:d9:5f:72:27:09:e7:
bf:7e:64:0a:59:bb:b3:7d:ae:88:14:94:45:b9:34:
d2:f3:93:e1:ba:b4:50:15:eb:e5:45:24:31:10:c7:
07:01:f9:dc:a5:6f:81
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
10:16:64:2C:DA:C1:D1:29:CD:C0:74:40:A9:70:BD:62:8A:BB:F4:D5
X509v3 Authority Key Identifier:
keyid:5A:BE:85:49:16:E5:EB:33:80:25:EB:D8:91:50:B4:E6:3E:4F:B8:22

Signature Algorithm: ecdsa-with-SHA384

30:65:02:31:00:80:50:7a:4f:c5:cd:6a:c3:57:13:7f:e9:da:
c1:72:7f:45:30:17:c2:a7:d3:ec:73:3d:5f:4d:e3:96:f6:a3:
33:fb:e4:b9:ff:47:f1:af:9d:e3:03:d2:24:53:40:09:5b:02:
30:45:d1:bf:51:fd:da:22:11:90:03:f9:d4:05:ec:d6:7c:41:
fc:9d:a1:fd:5b:8c:73:f8:b6:4c:c3:41:f7:c6:7f:2f:05:2d:
37:f8:52:52:26:99:28:97:ac:6e:f9:c7:01
# Create a PKI domain named client384 for the client's certificate ecdsa384 and enter its view.
[SwitchA] pki domain client384
# Disable CRL checking.
[SwitchA-pki-domain-client384] undo crl check enable
[SwitchA-pki-domain-client384] quit
# Import local certificate file ssh-client-ecdsa384.p12 to PKI domain client384.

536
[SwitchA] pki import domain client384 p12 local filename ssh-client-ecdsa384.p12
The system is going to save the key pair. You must specify a key pair name, which is
a case-insensitive string of 1 to 64 characters. Valid characters include a to z, A
to Z, 0 to 9, and hyphens (-).
Please enter the key pair name[default name: client384]:
# Display information about local certificates in PKI domain client384.
[SwitchA] display pki certificate domain client384 local
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: ecdsa-with-SHA384
Issuer: C=CN, ST=Beijing, L=Beijing, O=HPE, OU=Software, CN=SuiteB CA
Validity
Not Before: Aug 20 10:10:59 2015 GMT
Not After : Aug 19 10:10:59 2016 GMT
Subject: C=CN, ST=Beijing, O=HPE, OU=Software, CN=ssh client
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:85:7c:8b:f4:7a:36:bf:74:f6:7c:72:f9:08:69:
d0:b9:ac:89:98:17:c9:fc:89:94:43:da:9a:a6:89:
41:d3:72:24:9b:9a:29:a8:d1:ba:b4:e5:77:ba:fc:
df:ae:c6:dd:46:72:ab:bc:d1:7f:18:7d:54:88:f6:
b4:06:54:7e:e7:4d:49:b4:07:dc:30:54:4b:b6:5b:
01:10:51:6b:0c:6d:a3:b1:4b:c9:d9:6c:d6:be:13:
91:70:31:2a:92:00:76
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
BD:5F:8E:4F:7B:FE:74:03:5A:D1:94:DB:CA:A7:82:D6:F7:78:A1:B0
X509v3 Authority Key Identifier:
keyid:5A:BE:85:49:16:E5:EB:33:80:25:EB:D8:91:50:B4:E6:3E:4F:B8:22

Signature Algorithm: ecdsa-with-SHA384

30:66:02:31:00:d2:06:fa:2c:0b:0d:f0:81:90:01:c3:3d:bf:
97:b3:79:d8:25:a0:e2:0e:ed:00:c9:48:3e:c9:71:43:c9:b4:
2a:a6:0a:27:80:9e:d4:0f:f2:db:db:5b:40:b1:a9:0a:e4:02:
31:00:ee:00:e1:07:c0:2f:12:3f:88:ea:fe:19:05:ef:56:ca:
33:71:75:5e:11:c9:a6:51:4b:3e:7c:eb:2a:4d:87:2b:71:7c:
30:64:fe:14:ce:06:d5:0a:e2:cf:9a:69:19:ff
# Assign an IP address to VLAN-interface 2.
[SwitchA] interface vlan-interface 2

537
 [SwitchA-Vlan-interface2] ip address 192.168.0.2 255.255.255.0
[SwitchA-Vlan-interface2] quit
3. Configure the SCP server:
# Upload the server's certificate files (ssh-server-ecdsa256.p12 and
ssh-server-ecdsa384.p12) and the client's certificate files (ssh-client-ecdsa256.p12 and
ssh-client-ecdsa384.p12) to the SCP server through FTP or TFTP. (Details not shown.)
# Create a PKI domain named client256 for verifying the client's certificate ecdsa256 and
import the file of this certificate to this domain. Create a PKI domain named server256 for the
server's certificate ecdsa256 and import the file of this certificate to this domain. (Details not
shown.)
# Create a PKI domain named client384 for verifying the client's certificate ecdsa384 and
import the file of this certificate to this domain. Create a PKI domain named server384 for the
server's certificate ecdsa384 and import the file of this certificate to this domain. (Details not
shown.)
# Specify Suite B algorithms for algorithm negotiation.
<SwitchB> system-view
[SwitchB] ssh2 algorithm key-exchange ecdh-sha2-nistp256 ecdh-sha2-nistp384
[SwitchB] ssh2 algorithm cipher aes128-gcm aes256-gcm
[SwitchB] ssh2 algorithm public-key x509v3-ecdsa-sha2-nistp256
x509v3-ecdsa-sha2-nistp384
# Enable the SCP server.
[SwitchB] scp server enable
# Assign an IP address to VLAN-interface 2.
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ip address 192.168.0.1 255.255.255.0
[SwitchB-Vlan-interface2] quit
# Set the authentication mode to AAA for user lines.
[SwitchB] line vty 0 63
[SwitchB-line-vty0-63] authentication-mode scheme
[SwitchB-line-vty0-63] quit
# Create a local device management user named client001. Authorize the user to use the SSH
service and assign the network-admin user role to the user.
[SwitchB] local-user client001 class manage
[SwitchB-luser-manage-client001] service-type ssh
[SwitchB-luser-manage-client001] authorization-attribute user-role network-admin
[SwitchB-luser-manage-client001] quit
# Create a local device management user named client002. Authorize the user to use the SSH
service and assign the network-admin user role to the user.
[SwitchB] local-user client002 class manage
[SwitchB-luser-manage-client002] service-type ssh
[SwitchB-luser-manage-client002] authorization-attribute user-role network-admin
[SwitchB-luser-manage-client002] quit
4. Establish an SCP connection to the SCP server:
 Based on the 128-bit Suite B algorithms:
# Specify server256 as the PKI domain of the server's certificate.
[SwitchB]ssh server pki-domain server256
# Create an SSH user client001. Specify the publickey authentication method for the user
and specify client256 as the PKI domain for verifying the client's certificate.

538
 [SwitchB] ssh user client001 service-type scp authentication-type publickey assign
pki-domain client256
# Establish an SCP connection to the SCP server at 192.168.0.1 based on the 128-bit Suite
B algorithms.
<SwitchA> scp 192.168.0.1 get src.cfg suite-b 128-bit pki-domain client256
server-pki
-domain server256
Username: client001
Press CTRL+C to abort.
Connecting to 192.168.0.1 port 22.
src.cfg 100% 4814 4.7KB/s 00:00
<SwitchA>
 Based on the 192-bit Suite B algorithms:
# Specify server384 as the PKI domain of the server's certificate.
[SwitchB] ssh server pki-domain server384
# Create an SSH user client002. Specify the publickey authentication method for the user
and specify client384 as the PKI domain for verifying the client's certificate.
[Switch] ssh user client002 service-type scp authentication-type publickey assign
pki-domain client384
# Establish an SCP connection to the SCP server at 192.168.0.1 based on the 192-bit Suite
B algorithms.
<SwitchA> scp 192.168.0.1 get src.cfg suite-b 192-bit pki-domain client384
server-pki
-domain server384
Username: client002
Press CTRL+C to abort.
Connecting to 192.168.0.1 port 22.
src.cfg 100% 4814 4.7KB/s 00:00
<SwitchA>

NETCONF over SSH configuration examples

Unless otherwise noted, devices in the configuration examples are in non-FIPS mode.
When the device acts as a NETCONF-over-SSH server operating in FIPS mode, only ECDSA and
RSA key pairs are supported. Do not generate a DSA key pair on the NETCONF-over-SSH server.

Example: Configuring NETCONF over SSH with password

authentication
Network configuration
As shown in Figure 134:
• The switch acts as the NETCONF-over-SSH server and uses password authentication to
authenticate the client. The client's username and password are saved on the switch.
• The host acts as the NETCONF-over-SSH client, using SSH2 client software. After the user on
the host logs in to the switch through NETCONF over SSH, the user can perform NETCONF
operations on the switch as a network administrator.

539
 Figure 134 Network diagram
NETCONF-over-SSH NETCONF-over-SSH
client server
Vlan-int2
192.168.1.56/24 192.168.1.40/24

Host Switch

Procedure
# Generate RSA key pairs.
<Switch> system-view
[Switch] public-key local create rsa
The range of public key modulus is (512 ~ 4096).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
........................++++++
...................++++++
..++++++++
............++++++++
Create the key pair successfully.

# Generate a DSA key pair.

[Switch] public-key local create dsa
The range of public key modulus is (512 ~ 2048).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
.++++++++++++++++++++++++++++++++++++++++++++++++++*
........+......+.....+......................................+
...+.................+..........+...+.
Create the key pair successfully.

# Generate an ECDSA key pair.

[Switch] public-key local create ecdsa secp256r1
Generating Keys...
.
Create the key pair successfully.

# Enable NETCONF over SSH.

[Switch] netconf ssh server enable

# Configure an IP address for VLAN-interface 2. The client uses this address as the destination for
NETCONF-over-SSH connection.
[Switch] interface vlan-interface 2
[Switch-Vlan-interface2] ip address 192.168.1.40 255.255.255.0
[Switch-Vlan-interface2] quit

# Set the authentication mode to AAA for user lines.

[Switch] line vty 0 63
[Switch-line-vty0-63] authentication-mode scheme

540
 [Switch-line-vty0-63] quit

# Create a local device management user named client001.

[Switch] local-user client001 class manage

# Set the password to hello12345 in plain text for local user client001.
[Switch-luser-manage-client001] password simple hello12345

# Authorize local user client001 to use the SSH service.

[Switch-luser-manage-client001] service-type ssh

# Assign the network-admin user role to local user client001.

[Switch-luser-manage-client001] authorization-attribute user-role network-admin
[Switch-luser-manage-client001] quit

# Create an SSH user named client001. Specify the service type as NETCONF and the
authentication method as password for the user.
[Switch] ssh user client001 service-type netconf authentication-type password

Verifying the configuration

# Verify that you can perform NETCONF operations after logging in to the switch. (Details not
shown.)

541
Configuring SSL
About 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 security services

SSL provides the following security services:
• Privacy—SSL uses a symmetric encryption algorithm to encrypt data. It uses the asymmetric
key algorithm of RSA to encrypt the key used by the symmetric encryption algorithm. For more
information about RSA, see "Managing public keys."
• Authentication—SSL uses certificate-based digital signatures to authenticate the SSL server
and client. The SSL server and client obtain digital certificates through PKI. For more
information about PKI and digital certificates, see "Configuring PKI."
• Integrity—SSL uses the message authentication code (MAC) to verify message integrity. It
uses a MAC algorithm and a key to transform a message of any length to a fixed-length
message. Any change to the original message will result in a change to the calculated
fixed-length message. As shown in Figure 135, the message integrity verification process is as
follows:
a. The sender uses a MAC algorithm and a key to calculate a MAC value for a message. Then,
it appends the MAC value to the message and sends the message to the receiver.
b. The receiver uses the same key and MAC algorithm to calculate a MAC value for the
received message, and compares it with the MAC value appended to the message.
c. If the two MAC values match, the receiver considers the message intact. Otherwise, the
receiver considers that the message was tampered with and it discards the message.
Figure 135 MAC algorithm diagram

Sender Key Receiver

Send to
Message the
Message
receiver
Compute
MAC
Compute MAC Message the MAC
the MAC
MAC Compare
Key

SSL protocol stack

The SSL protocol stack includes the following protocols:
• SSL record protocol at the lower layer.
• SSL handshake protocol, SSL change cipher spec protocol, and SSL alert protocol at the upper
layer.

542
 Figure 136 SSL protocol stack

Application layer protocol (e.g. HTTP)

SSL handshake protocol SSL change cipher spec protocol SSL alert protocol

SSL record protocol

TCP

IP

The following describes the major functions of SSL protocols:

• SSL record protocol—Fragments data received from the upper layer, computes and adds
MAC to the data, and encrypts the data.
• SSL handshake protocol—Negotiates the cipher suite used for secure communication,
authenticates the server and client, and securely exchanges the keys between the server and
client. The cipher suite that needs to be negotiated includes the symmetric encryption algorithm,
key exchange algorithm, and MAC algorithm.
• SSL change cipher spec protocol—Notifies the receiver that subsequent packets are to be
protected based on the negotiated cipher suite and key.
• SSL alert protocol—Sends alert messages to the receiving party. An alert message contains
the alert severity level and a description.

SSL protocol versions

SSL protocol versions include SSL 2.0, SSL 3.0, TLS 1.0 (or SSL 3.1), TLS 1.1, and TLS 1.2.
Because SSL 3.0 is known to be insecure, you can disable SSL 3.0 for the SSL server to ensure
security.

FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for
features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and
non-FIPS mode.

Restrictions and guidelines: SSL configuration

By default, the SSL server can communicate with clients running all SSL protocol versions. When the
server receives an SSL 2.0 Client Hello message from a client, it notifies the client to use a later
version for communication.

SSL tasks at a glance

Configuring the SSL server
• Configuring an SSL server policy
• (Optional.) Disabling SSL protocol versions for the SSL server
• (Optional.) Disabling SSL session renegotiation

543
Configuring the SSL client
Configuring an SSL client policy

Configuring an SSL server policy

About this task
An SSL server policy is a set of SSL parameters used by the device when the device acts as the SSL
server. An SSL server policy takes effect only after it is associated with an application such as
HTTPS.
Procedure
1. Enter system view.
system-view
2. Create an SSL server policy and enter its view.
ssl server-policy policy-name
3. Specify a PKI domain for the SSL server policy.
pki-domain domain-name
By default, no PKI domain is specified for an SSL server policy.
If SSL server authentication is required, you must specify a PKI domain and request a local
certificate for the SSL server in the domain.
For information about configuring a PKI domain, see "Configuring PKI."
4. Specify the cipher suites that the SSL server policy supports.
In non-FIPS mode:
ciphersuite { dhe_rsa_aes_128_cbc_sha | dhe_rsa_aes_128_cbc_sha256 |
dhe_rsa_aes_256_cbc_sha | dhe_rsa_aes_256_cbc_sha256 |
ecdhe_ecdsa_aes_128_cbc_sha256 | ecdhe_ecdsa_aes_128_gcm_sha256 |
ecdhe_ecdsa_aes_256_cbc_sha384 | ecdhe_ecdsa_aes_256_gcm_sha384 |
ecdhe_rsa_aes_128_cbc_sha256 | ecdhe_rsa_aes_128_gcm_sha256 |
ecdhe_rsa_aes_256_cbc_sha384 | ecdhe_rsa_aes_256_gcm_sha384 |
exp_rsa_des_cbc_sha | exp_rsa_rc2_md5 | exp_rsa_rc4_md5 |
rsa_3des_ede_cbc_sha | rsa_aes_128_cbc_sha | rsa_aes_128_cbc_sha256 |
rsa_aes_256_cbc_sha | rsa_aes_256_cbc_sha256 | rsa_des_cbc_sha |
rsa_rc4_128_md5 | rsa_rc4_128_sha } *
In FIPS mode:
ciphersuite { ecdhe_ecdsa_aes_128_cbc_sha256 |
ecdhe_ecdsa_aes_256_cbc_sha384 | ecdhe_ecdsa_aes_128_gcm_sha256 |
ecdhe_ecdsa_aes_256_gcm_sha384 | ecdhe_rsa_aes_128_cbc_sha256 |
ecdhe_rsa_aes_128_gcm_sha256 | ecdhe_rsa_aes_256_cbc_sha384 |
ecdhe_rsa_aes_256_gcm_sha384 | rsa_aes_128_cbc_sha |
rsa_aes_128_cbc_sha256 | rsa_aes_256_cbc_sha |
rsa_aes_256_cbc_sha256 } *
By default, an SSL server policy supports all cipher suites.
5. (Optional.) Set the maximum number of sessions that the SSL server can cache and the
session cache timeout time.
session { cachesize size | timeout time } *
By default, the SSL server can cache a maximum of 500 sessions, and the session cache
timeout time is 3600 seconds.
6. Enable mandatory or optional SSL client authentication.

544
 client-verify { enable | optional }
By default, SSL client authentication is disabled. The SSL server does not perform digital
certificate-based authentication on SSL clients.
When authenticating a client by using the digital certificate, the SSL server verifies the
certificate chain presented by the client. It also verifies that the certificates in the certificate
chain (except the root CA certificate) are not revoked.
7. (Optional.) Enable the SSL server to send the complete certificate chain to the client during SSL
negotiation.
certificate-chain-sending enable
By default, the SSL server sends the server certificate rather than the complete certificate chain
to the client during negotiation.

Configuring an SSL client policy

About this task
An SSL client policy is a set of SSL parameters used by the device when the device acts as the SSL
client. The SSL client uses the settings in the client policy to establish a connection to the server. An
SSL client policy takes effect only after it is associated with an application such as DDNS. For
information about DDNS, see the DNS configuration in Layer 3—IP Services Configuration Guide.
Restrictions and guidelines
As a best practice to enhance system security, do not specify SSL 3.0 for the SSL client policy.
Procedure
1. Enter system view.
system-view
2. Create an SSL client policy and enter its view.
ssl client-policy policy-name
3. Specify a PKI domain for the SSL client policy.
pki-domain domain-name
By default, no PKI domain is specified for an SSL client policy.
If SSL client authentication is required, you must specify a PKI domain and request a local
certificate for the SSL client in the PKI domain.
For information about configuring a PKI domain, see "Configuring PKI."
4. Specify the preferred cipher suite for the SSL client policy.
In non-FIPS mode:
prefer-cipher { dhe_rsa_aes_128_cbc_sha | dhe_rsa_aes_128_cbc_sha256
| dhe_rsa_aes_256_cbc_sha | dhe_rsa_aes_256_cbc_sha256 |
ecdhe_ecdsa_aes_128_cbc_sha256 | ecdhe_ecdsa_aes_128_gcm_sha256 |
ecdhe_ecdsa_aes_256_cbc_sha384 | ecdhe_ecdsa_aes_256_gcm_sha384 |
ecdhe_rsa_aes_128_cbc_sha256 | ecdhe_rsa_aes_128_gcm_sha256 |
ecdhe_rsa_aes_256_cbc_sha384 | ecdhe_rsa_aes_256_gcm_sha384 |
exp_rsa_des_cbc_sha | exp_rsa_rc2_md5 | exp_rsa_rc4_md5 |
rsa_3des_ede_cbc_sha | rsa_aes_128_cbc_sha | rsa_aes_128_cbc_sha256
| rsa_aes_256_cbc_sha | rsa_aes_256_cbc_sha256 | rsa_des_cbc_sha |
rsa_rc4_128_md5 | rsa_rc4_128_sha }
The default preferred cipher suite in non-FIPS mode is rsa_rc4_128_md5.
In FIPS mode:
prefer-cipher { ecdhe_ecdsa_aes_128_cbc_sha256 |
ecdhe_ecdsa_aes_128_gcm_sha256 | ecdhe_ecdsa_aes_256_cbc_sha384 |

545
 ecdhe_ecdsa_aes_256_gcm_sha384 | ecdhe_rsa_aes_128_cbc_sha256 |
ecdhe_rsa_aes_128_gcm_sha256 | ecdhe_rsa_aes_256_cbc_sha384 |
ecdhe_rsa_aes_256_gcm_sha384 | rsa_aes_128_cbc_sha |
rsa_aes_128_cbc_sha256 | rsa_aes_256_cbc_sha |
rsa_aes_256_cbc_sha256 }
The default preferred cipher suite in FIPS mode is rsa_aes_128_cbc_sha.
5. Specify the SSL protocol version for the SSL client policy.
In non-FIPS mode:
version { ssl3.0 | tls1.0 | tls1.1 | tls1.2 }
In FIPS mode:
version { tls1.0 | tls1.1 | tls1.2 }
By default, an SSL client policy uses TLS 1.0.
6. Enable the SSL client to authenticate servers through digital certificates.
server-verify enable
By default, SSL server authentication is enabled.

Disabling SSL protocol versions for the SSL

server
About this task
To enhance system security, you can disable the SSL server from using specific SSL protocol
versions (SSL 3.0, TLS 1.0, and TLS 1.1) for session negotiation.
Restrictions and guidelines
Disabling an SSL protocol version does not affect the availability of earlier SSL protocol versions. For
example, if you execute the ssl version tls1.1 disable command, TLS 1.1 is disabled but
TLS 1.0 is still available for the SSL server.
Procedure
1. Enter system view.
system-view
2. Disable SSL protocol versions for the SSL server.
In non-FIPS mode:
ssl version { ssl3.0 | tls1.0 | tls1.1 } * disable
By default, the SSL server supports SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2.
In FIPS mode:
ssl version { tls1.0 | tls1.1 } * disable
By default, the SSL server supports TLS 1.0, TLS 1.1, and TLS 1.2.

Disabling SSL session renegotiation

About this task
The SSL session renegotiation feature enables the SSL client and server to reuse a previously
negotiated SSL session for an abbreviated handshake.
Disabling session renegotiation causes more computational overhead to the system but it can avoid
potential risks.

546
Restrictions and guidelines
Disable SSL session renegotiation only when explicitly required.
Procedure
1. Enter system view.
system-view
2. Disable SSL session renegotiation.
ssl renegotiation disable
By default, SSL session renegotiation is enabled.

Display and maintenance commands for SSL

Execute display commands in any view.

Task Command
display ssl client-policy
Display SSL client policy information.
[ policy-name ]
display ssl server-policy
Display SSL server policy information.
[ policy-name ]

547
Configuring attack detection and
prevention
Overview
Attack detection and prevention enables a device to detect attacks by inspecting arriving packets,
and to take prevention actions (such as packet dropping) to protect a private network.

Attacks that the device can prevent

This section describes the attacks that the device can detect and prevent.

TCP fragment attack

An attacker launches TCP fragment attacks by sending attack TCP fragments defined in RFC 1858:
• First fragments in which the TCP header is smaller than 20 bytes.
• Non-first fragments with a fragment offset of 8 bytes (FO=1).
Typically, packet filter detects the source and destination IP addresses, source and destination ports,
and transport layer protocol of the first fragment of a TCP packet. If the first fragment passes the
detection, all subsequent fragments of the TCP packet are allowed to pass through.
Because the first fragment of attack TCP packets does not hit any match in the packet filter, the
subsequent fragments can all pass through. After the receiving host reassembles the fragments, a
TCP fragment attack occurs.
To prevent TCP fragment attacks, enable TCP fragment attack prevention to drop attack TCP
fragments.

Login dictionary attack

The login dictionary attack is an automated process to attempt to log in by trying all possible
passwords from a pre-arranged list of values (the dictionary). Multiple login attempts can occur in a
short period of time.
You can configure the login delay feature to slow down the login dictionary attacks. This feature
enables the device to delay accepting another login request after detecting a failed login attempt for
a user.

Configuring TCP fragment attack prevention

The TCP fragment attack prevention feature detects the length and fragment offset of received TCP
fragments and drops attack TCP fragments. The device supports verifying only TCP fragments
forwarded through the CPU.
To configure TCP fragment attack prevention:
1. Enter system view.
system-view
2. Enable TCP fragment attack prevention.
attack-defense tcp fragment enable

548
 By default, TCP fragment attack prevention is enabled.

Enabling the login delay

The login delay feature delays the device from accepting a login request from a user after the user
fails a login attempt. This feature can slow down login dictionary attacks.
To enable the login delay:
1. Enter system view.
system-view
2. Enable the login delay feature.
attack-defense login reauthentication-delay seconds
By default, the login delay feature is disabled. The device does not delay accepting a login
request from a user who has failed a login attempt.

549
Configuring TCP attack prevention
About TCP attack prevention
TCP attack prevention can detect and prevent attacks that exploit the TCP connection establishment
process.

Configuring Naptha attack prevention

About this task
Naptha is a DDoS attack that targets operating systems. It exploits the resources consuming
vulnerability in TCP/IP stack and network application process. The attacker establishes a large
number of TCP connections in a short period of time and leaves them in certain states without
requesting any data. These TCP connections starve the victim of system resources, resulting in a
system breakdown.
After you enable Naptha attack prevention, the device periodically checks the number of TCP
connections in each state (CLOSING, ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, and
LAST_ACK). If the number of TCP connections in a state exceeds the limit, the device will accelerate
the aging of the TCP connections in that state to mitigate the Naptha attack.
Procedure
1. Enter system view.
system-view
2. Enable Naptha attack prevention.
tcp anti-naptha enable
By default, Naptha attack prevention is disabled.
3. (Optional.) Set the maximum number of TCP connections in a state.
tcp state { closing | established | fin-wait-1 | fin-wait-2 | last-ack }
connection-limit number
By default, the maximum number of TCP connections in each state (CLOSING, ESTABLISHED,
FIN_WAIT_1, FIN_WAIT_2, and LAST_ACK) is 50.
To disable the device from accelerating the aging of the TCP connections in a state, set the
value to 0.
4. (Optional.) Set the interval for checking the number of TCP connections in each state.
tcp check-state interval interval
By default, the interval for checking the number of TCP connections in each state is 30
seconds.

550
Configuring IP source guard
About IPSG
IP source guard (IPSG) prevents spoofing attacks by using an IPSG binding table to filter out
illegitimate packets. This feature is typically configured on user-side interfaces.

IPSG operating mechanism

The IPSG binding table contains bindings that bind IP address, MAC address, VLAN, or any
combinations. IPSG uses the bindings to match an incoming packet. If a match is found, the packet
is forwarded. If no match is found, the packet is discarded.
IPSG is a per-interface packet filter. Configuring this feature on one interface does not affect packet
forwarding on another interface.
IPSG bindings can be static or dynamic.
As shown in Figure 137, IPSG forwards only the packets that match an IPSG binding.
Figure 137 IPSG application

Valid host IPSG bindings

1.1.1.1
…
1.1.1.1

IP network

Configure the IP source guard

feature on the interface
Invalid host

Static IPSG bindings

Static IPSG bindings are configured manually. They are suitable for scenarios where few hosts exist
on a LAN and their IP addresses are manually configured. For example, you can configure a static
IPSG binding on an interface that connects to a server. This binding allows the interface to receive
packets only from the server.
Static IPSG bindings on an interface implement the following functions:
• Filter incoming IPv4 or IPv6 packets on the interface.
• Cooperate with ARP attack detection in IPv4 for user validity checking. For information about
ARP attack detection, see "Configuring ARP attack protection."
• Cooperate with ND attack detection in IPv6 for user validity checking. For information about ND
attack detection, see "Configuring ND attack defense."
Static IPSG bindings can be global or interface-specific.
• Global static binding—Binds the IP address and MAC address in system view. The binding
takes effect on all interfaces to filter packets for user spoofing attack prevention.
• Interface-specific static binding—Binds the IP address, MAC address, VLAN, or any
combination of the items in interface view. The binding takes effect only on the interface to
check the validity of users who are attempting to access the interface.

551
Dynamic IPSG bindings
IPSG automatically obtains user information from other modules to generate dynamic bindings. A
dynamic IPSG binding can contain MAC address, IPv4 or IPv6 address, VLAN tag, ingress interface,
and binding type. The binding type identifies the source module for the binding, such as DHCP
snooping, DHCPv6 snooping, DHCP relay agent, or DHCPv6 relay agent.
For example, DHCP-based IPSG bindings are suitable for scenarios where hosts on a LAN obtain IP
addresses through DHCP. IPSG is configured on the DHCP server, the DHCP snooping device, or
the DHCP relay agent. It generates dynamic bindings based on the client bindings on the DHCP
server, the DHCP snooping entries, or the DHCP relay entries. IPSG allows only packets from the
DHCP clients to pass through.
Dynamic IPv4SG
Dynamic bindings generated based on different source modules are for different usages:

Interface types Source modules Binding usage

DHCP snooping
Packet filtering.
802.1X
Layer 2 Ethernet interface
For cooperation with modules (such as the
ARP snooping
MFF module) to provide security services.

DHCP relay agent Packet filtering.

Layer 3 Ethernet interface
For cooperation with modules (such as the
VLAN interface DHCP server authorized ARP module) to provide security
services.

For more information about 802.1X, see "Configuring 802.1X." For information about ARP snooping,
DHCP snooping, DHCP relay, and DHCP server, see Layer 3—IP Services Configuration Guide.
Dynamic IPv6SG
Dynamic IPv6SG bindings generated based on different source modules are for different usages:

Interface types Source modules Binding usage

DHCPv6 snooping
Layer 2 Ethernet interface ND snooping Packet filtering.
802.1X
DHCPv6 relay agent
Packet filtering.
ND RA prefix entry recording
Layer 3 Ethernet interface
VLAN interface Reporting bindings to the controller to
DHCPv6 server provide online and offline user
information.

For more information about DHCPv6 snooping, see Layer 3—IP Services Configuration Guide. For
more information about ND snooping, see IPv6 basics configuration in Layer 3—IP Services
Configuration Guide. For more information about ND RA prefix entry recording, see IPv6 neighbor
discovery in Layer 3—IP Services Configuration Guide. For more information about DHCPv6 relay
agent, see Layer 3—IP Services Configuration Guide. For more information about DHCPv6 server,
see Layer 3—IP Services Configuration Guide.

552
IPSG bindings synchronized by routing protocols
In addition to static and dynamic IPSG bindings, the device also supports IPSG bindings
synchronized by routing protocols (such as BGP) from remote devices. These bindings are called
remote IPSG bindings. By default, the remote IPSG bindings do not have interface information and
cannot be used for packet filtering. When users roam from remote devices to the local device, the
device learns interface information for the remote IPSG bindings through ARP or ND entries of the
users. Then, the device converts the remote IPSG bindings into local IPSG bindings and uses these
bindings for packet filtering.
For more information about BGP, see BGP overview in Layer 3—IP Routing Configuration Guide.

IPSG tasks at a glance

To configure IPv4SG, perform the following tasks:
1. Enabling IPv4SG
2. (Optional.) Configuring a static IPv4SG binding
3. (Optional.) Excluding IPv4 packets from IPSG filtering
4. (Optional.) Enabling IPv4SG alarming
To configure IPv6SG, perform the following tasks:
5. Enabling IPv6SG
6. (Optional.) Configuring a static IPv6SG binding
7. (Optional.) Setting the maximum number of IPv6SG bindings on an interface
8. (Optional.) Enabling IPv6SG alarming

Configuring the IPv4SG feature

Enabling IPv4SG
About this task
When you enable IPSG on an interface, the static and dynamic IPSG are both enabled.
• Static IPv4SG uses static bindings configured by using the ip source binding command.
For more information, see "Configuring a static IPv4SG binding."
• Dynamic IPv4SG generates dynamic bindings from related source modules. IPv4SG uses the
bindings to filter incoming IPv4 packets based on the matching criteria specified in the ip
verify source command.
In a VLAN enabled with IPv4SG, you can configure an interface as an IPv4SG trusted port if you can
determine that no attack sources are connected to the interface. IPv4SG does not filter incoming
packets on that trusted interface.
Restrictions and guidelines
To implement dynamic IPv4SG, make sure 802.1X, ARP snooping, DHCP snooping, DHCP relay
agent, or DHCP server operates correctly on the network.
You can enable IPv4SG on an interface or in a VLAN. The interface-specific configuration applies to
this interface. The VLAN-specific configuration applies to all Layer 2 Ethernet interfaces that belong
to this VLAN.
Do not configure IPv4SG both in a VLAN and on an Ethernet interface that belongs to the VLAN.
Before you perform one of the configurations, make sure the other configuration does not exist.

553
Enabling IP4SG on an interface
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
The following interface types are supported:
 Layer 2 Ethernet interface.
 Layer 3 Ethernet interface.
 Layer 3 Ethernet subinterface.
 Layer 3 aggregate interface.
 Layer 3 aggregate subinterface.
 VLAN interface.
3. Enable the IPv4SG feature.
ip verify source { ip-address | ip-address mac-address | mac-address }
By default, the IPv4SG feature is disabled on an interface.
Enabling IPv4SG in a VLAN
1. Enter system view.
system-view
2. Enter VLAN view.
vlan vlan-id
3. Enable IPv4SG in the VLAN.
ip verify source { ip-address | ip-address mac-address | mac-address }
By default, IPv4SG is disabled in a VLAN.
4. (Optional.) Execute the following commands in sequence to configure an IPv4SG trusted port.
a. Return to system view.
quit
b. Enter the view of a Layer 2 Ethernet interface in the VLAN.
interface interface-type interface-number
c. Configure the interface as an IPv4SG trusted port.
ip verify source trust

Configuring a static IPv4SG binding

About this task
You can configure global static and interface-specific static IPv4SG bindings. Interface-specific static
and dynamic bindings take priority over global static bindings. An interface first uses the static and
dynamic bindings on the interface to match packets. If no match is found, the interface uses the
global bindings.
Restrictions and guidelines
Global static bindings take effect on all interfaces on the device.
To configure a static IPv4SG binding for the ARP attack detection feature, make sure the following
conditions are met:
• The ip-address ip-address option, the mac-address mac-address option, and the
vlan vlan-id option must be specified.

554
 • ARP attack detection must be enabled for the specified VLAN.
Configuring a global static IPv4SG binding
1. Enter system view.
system-view
2. Configure a global static IPv4SG binding.
ip source binding ip-address ip-address mac-address mac-address
Configuring a static IPv4SG binding on an interface
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
The following interface types are supported:
 Layer 2 Ethernet interface.
 Layer 3 Ethernet interface.
 Layer 3 Ethernet subinterface.
 Layer 3 aggregate interface.
 Layer 3 aggregate subinterface.
 VLAN interface.
3. Configure a static IPv4SG binding.
ip source binding { ip-address ip-address | ip-address ip-address
mac-address mac-address | mac-address mac-address } [ vlan vlan-id ]
You can configure the same static IPv4SG binding on different interfaces.

Excluding IPv4 packets from IPSG filtering

About this task
By default, IPv4SG processes all incoming IPv4 packets on an interface and discards the packets
that do not match IPSG bindings. To allow specific IPv4 packets that do not match any IPSG binding
to pass through the interface, you can specify source items of the packets for IPSG filtering
exemption. All IPv4 packets with the specified source items are forwarded without being processed
by IPSG.
Procedure
1. Enter system view.
system-view
2. Exclude IPv4 packets with the specified source items from IPSG filtering.
ip verify source exclude vlan start-vlan-id [ to end-vlan-id ]
By default, no excluded source items are configured.
You can execute this command multiple times to specify multiple excluded VLANs. The
specified excluded VLANs cannot overlap.

555
Enabling IPv4SG alarming
About this task
This feature monitors the number of packets dropped by IPv4SG per second. When the packet
dropping rate reaches or exceeds the alarm threshold, the device generates an alarm log. When the
packet dropping rate drops below the alarm threshold, the device generates an alarm-cleared log.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable IPv4SG alarming on the interface.
ip verify source alarm [ alarm-threshold ]
By default, IPv4SG alarming is disabled on an interface.

Configuring the IPv6SG feature

Enabling IPv6SG
About this task
When you enable IPv6SG on an interface, the static and dynamic IPv6SG are both enabled.
• Static IPv6SG uses static bindings configured by using the ipv6 source binding
command. For more information, see "Configuring a static IPv6SG binding."
• Dynamic IPv6SG generates dynamic bindings from related source modules. IPv6SG uses the
bindings to filter incoming IPv6 packets based on the matching criteria specified in the ipv6
verify source command.
In a VLAN enabled with IPv6SG, you can configure an interface as an IPv6SG trusted port if you can
determine that no attack sources are connect to the interface. IPv6SG does not filter incoming
packets on that trusted interface.
Restrictions and guidelines
To implement dynamic IPv6SG, make sure DHCPv6 snooping, DHCPv6 relay agent, or ND
snooping operates correctly on the network.
You can enable IPv6SG on an interface or in a VLAN. The interface-specific configuration applies to
this interface. The VLAN-specific configuration applies to all Layer 2 Ethernet interfaces that belong
to this VLAN.
Do not configure IPv6SG both in a VLAN and on an Ethernet interface that belongs to the VLAN.
Before you perform one of the configurations, make sure the other configuration does not exist.
Enabling IPv6SG on an interface
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
The following interface types are supported:
 Layer 2 Ethernet interface.

556
  Layer 3 Ethernet interface.
 Layer 3 Ethernet subinterface.
 Layer 3 aggregate interface.
 Layer 3 aggregate subinterface.
 VLAN interface.
3. Enable the IPv6SG feature.
ipv6 verify source { ip-address | ip-address mac-address |
mac-address }
By default, the IPv6SG feature is disabled on an interface.
Enabling IPv6SG in a VLAN
1. Enter system view.
system-view
2. Enter VLAN view.
vlan vlan-id
3. Enable IPv6SG in the VLAN.
ipv6 verify source { ip-address | ip-address mac-address |
mac-address }
By default, IPv6SG is disabled in a VLAN.
4. (Optional.) Execute the following commands in sequence to configure an IPv6SG trusted port.
a. Return to system view.
quit
b. Enter the view of a Layer 2 Ethernet interface in the VLAN.
interface interface-type interface-number
c. Configure the interface as an IPv6SG trusted port.
ipv6 verify source trust

Configuring a static IPv6SG binding

About this task
You can configure global static and interface-specific static IPv6SG bindings. Interface-specific static
and dynamic bindings take priority over global static bindings. An interface first uses the static and
dynamic bindings on the interface to match packets. If no match is found, the interface uses the
global bindings.
Restrictions and guidelines
Global static bindings take effect on all interfaces on the device.
To configure a static IPv6SG binding for the ND attack detection feature, the vlan vlan-id option
must be specified, and ND attack detection must be enabled for the specified VLAN.
Configuring a global static IPv6SG binding
1. Enter system view.
system-view
2. Configure a global static IPv6SG binding.
ipv6 source binding ip-address ipv6-address mac-address mac-address
Configuring a static IPv6SG binding on an interface
1. Enter system view.

557
 system-view
2. Enter interface view.
interface interface-type interface-number
The following interface types are supported:
 Layer 2 Ethernet interface.
 Layer 3 Ethernet interface.
 Layer 3 Ethernet subinterface.
 Layer 3 aggregate interface.
 Layer 3 aggregate subinterface.
 VLAN interface.
3. Configure a static IPv6SG binding.
ipv6 source binding { ip-address ipv6-address | ip-address ipv6-address
mac-address mac-address | mac-address mac-address } [ vlan vlan-id ]
You can configure the same static IPv6SG binding on different interfaces.

Setting the maximum number of IPv6SG bindings on an

interface
About this task
You can set the maximum number of IPv6SG bindings on an interface to limit the total number of
static and dynamic IPv6SG bindings on the interface. If the upper limit is reached, no more IPv6SG
bindings can be added on the interface.
Procedure
1. Enter system view.
system-view
2. Enter Layer 2 Ethernet interface view.
interface interface-type interface-number
3. Set the maximum number of IPv6SG bindings on the interface.
ipv6 verify source max-entries number
By default, the maximum number of IPv6SG bindings is not limited on an interface.

Enabling IPv6SG alarming

About this task
This feature enables the device to monitor the number of packets dropped by IPv6SG per second.
When the packet dropping rate reaches or exceeds the alarm threshold, the device generates an
alarm log. When the packet dropping rate drops below the alarm threshold, the device generates an
alarm-cleared log.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable IPv6SG alarming on the interface.

558
 ipv6 verify source alarm [ alarm-threshold ]
By default, IPv6SG alarming is disabled on an interface.

Display and maintenance commands for IPSG

Execute display commands in any view and reset commands in user view.

Task Command
display ip source binding [ static | [ vpn-instance
vpn-instance-name ] [ arp-snooping-vlan |
arp-snooping-vsi | dhcp-relay | dhcp-server |
Display IPv4SG bindings. dhcp-snooping | dot1x | remote ] ] [ ip-address
ip-address ] [ mac-address mac-address ] [ vlan
vlan-id ] [ interface interface-type
interface-number ] [ slot slot-number ]

Display local IPv4SG display ip source binding-local [ interface

bindings that can be interface-type interface-number ] [ dhcp-relay ]
synchronized by routing [ ip-address ip-address ] [ mac-address
protocols. mac-address ] [ vlan vlan-id ] [ slot slot-number ]
display ip source binding-remote [ router-id
Display remote IPv4SG router-id ] [ dhcp-relay ] [ ip-address ip-address ]
bindings synchronized by
routing protocols.
[ mac-address mac-address ] [ vlan vlan-id ] [ slot
slot-number ]
Display statistics about
local and remote IPv4SG
display ip source binding statistics
bindings that routing
protocols synchronize.

Display source items that

have been configured to display ip verify source excluded [ vlan
be excluded from IPSG start-vlan-id [ to end-vlan-id ] ] [ slot slot-number ]
filtering.

display ipv6 source binding [ static | [ vpn-instance

vpn-instance-name ] [ dhcpv6-relay | dhcpv6-server |
dhcpv6-snooping | dot1x | nd-snooping-vlan |
Display IPv6SG address
nd-snooping-vsi | remote ] ] [ ip-address
bindings.
ipv6-address ] [ mac-address mac-address ] [ vlan
vlan-id ] [ interface interface-type
interface-number ] [ slot slot-number ]
display ipv6 source binding-local [ interface
Display local IPv6SG interface-type interface-number ] [ dhcpv6-relay |
bindings that can be
nd-snooping-vlan ] [ ip-address ipv6-address ]
synchronized by routing
protocols. [ mac-address mac-address ] [ vlan vlan-id ] [ slot
slot-number ]
display ipv6 source binding-remote [ router-id
Display remote IPv6SG router-id ] [ dhcpv6-relay | nd-snooping-vlan]
bindings synchronized by
routing protocols.
[ ip-address ipv6-address ] [ mac-address
mac-address ] [ vlan vlan-id ] [ slot slot-number ]
display ipv6 source binding pd [ vpn-instance
Display IPv6SG prefix
bindings. vpn-instance-name ] [ prefix prefix/prefix-length ]
[ mac-address mac-address ] [ vlan vlan-id ]

559
 Task Command
[ interface interface-type interface-number ] [ slot
slot-number ]
Display statistics about
local and remote IPv6SG
display ipv6 source binding statistics
bindings that routing
protocols synchronize.

IPSG configuration examples

Example: Configuring static IPv4SG
Network configuration
As shown in Figure 138, all hosts use static IP addresses.
Configure static IPv4SG bindings on Device A and Device B to meet the following requirements:
• All interfaces of Device A allow IP packets from Host A to pass.
• GigabitEthernet 1/0/1 of Device A allows IP packets from Host B to pass.
Figure 138 Network diagram

GE1/0/2 GE1/0/1

Device A

Host A Host B
IP: 192.168.0.1/24 IP: 192.168.0.2/24
MAC: 0001-0203-0406 MAC: 0001-0203-0407

Procedure
# Configure IP addresses for the interfaces. (Details not shown.)
# Enable IPv4SG on GigabitEthernet 1/0/2.
<DeviceA> system-view
[DeviceA] interface gigabitethernet 1/0/2
[DeviceA-GigabitEthernet1/0/2] ip verify source ip-address mac-address
[DeviceA-GigabitEthernet1/0/2] quit

# Configure a static IPv4SG binding for Host A.

[DeviceA] ip source binding ip-address 192.168.0.1 mac-address 0001-0203-0406

# Enable IPv4SG on GigabitEthernet 1/0/1.

[DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] ip verify source ip-address mac-address

# On GigabitEthernet 1/0/1, configure a static IPv4SG binding for Host B.

[DeviceA-GigabitEthernet1/0/1] ip source binding mac-address 0001-0203-0407
[DeviceA-GigabitEthernet1/0/1] quit

Verifying the configuration

# Verify that the static IPv4SG bindings are configured successfully on Device A.

560
 <DeviceA> display ip source binding static
Total entries found: 2
IP Address MAC Address Interface VLAN Type
192.168.0.1 0001-0203-0406 N/A N/A Static
N/A 0001-0203-0407 GE1/0/1 N/A Static

Example: Configuring DHCP snooping-based dynamic

IPv4SG
Network configuration
As shown in Figure 139, the host (the DHCP client) obtains an IP address from the DHCP server.
Perform the following tasks:
• Enable DHCP snooping on the device to make sure the DHCP client obtains an IP address from
the authorized DHCP server. To generate a DHCP snooping entry for the DHCP client, enable
recording of client information in DHCP snooping entries.
• Enable dynamic IPv4SG on GigabitEthernet 1/0/1 to filter incoming packets by using the
IPv4SG bindings generated based on DHCP snooping entries. Only packets from the DHCP
client are allowed to pass.
Figure 139 Network diagram
DHCP client DHCP snooping DHCP server

GE1/0/1 GE1/0/2

Host Device
MAC: 0001-0203-0406

Procedure
1. Configure the DHCP server.
For information about DHCP server configuration, see Layer 3—IP Services Configuration
Guide.
2. Configure the device:
# Configure IP addresses for the interfaces. (Details not shown.)
# Enable DHCP snooping.
<Device> system-view
[Device] dhcp snooping enable
# Configure GigabitEthernet 1/0/2 as a trusted interface.
[Device] interface gigabitethernet 1/0/2
[Device-GigabitEthernet1/0/2] dhcp snooping trust
[Device-GigabitEthernet1/0/2] quit
# Enable IPv4SG on GigabitEthernet 1/0/1 and verify the source IP address and MAC address
for dynamic IPSG.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] ip verify source ip-address mac-address
# Enable recording of client information in DHCP snooping entries on GigabitEthernet 1/0/1.
[Device-GigabitEthernet1/0/1] dhcp snooping binding record
[Device-GigabitEthernet1/0/1] quit

561
Verifying the configuration
# Display dynamic IPv4SG bindings generated based on DHCP snooping entries.
[Device] display ip source binding dhcp-snooping
Total entries found: 1
IP Address MAC Address Interface VLAN Type
192.168.0.1 0001-0203-0406 GE1/0/1 1 DHCP snooping

GigabitEthernet 1/0/1 will filter packets based on the IPv4SG binding.

Example: Configuring DHCP relay agent-based dynamic

IPv4SG
Network configuration
As shown in Figure 140, DHCP relay agent is enabled on the switch. The host obtains an IP address
from the DHCP server through the DHCP relay agent.
Enable dynamic IPv4SG on VLAN-interface 100 to filter incoming packets by using the IPv4SG
bindings generated based on DHCP relay entries.
Figure 140 Network diagram
DHCP client DHCP relay agent DHCP server

Vlan-int100 Vlan-int200

Host Switch 10.1.1.1/24

MAC: 0001-0203-0406

Procedure
1. Configure dynamic IPv4SG:
# Configure IP addresses for the interfaces. (Details not shown.)
# Enable IPv4SG on VLAN-interface 100 and verify the source IP address and MAC address for
dynamic IPSG.
<Switch> system-view
[Switch] interface vlan-interface 100
[Switch-Vlan-interface100] ip verify source ip-address mac-address
[Switch-Vlan-interface100] quit
2. Configure the DHCP relay agent:
# Enable the DHCP service.
[Switch] dhcp enable
# Enable recording DHCP relay entries.
[Switch] dhcp relay client-information record
# Configure VLAN-interface 100 to operate in DHCP relay mode.
[Switch] interface vlan-interface 100
[Switch-Vlan-interface100] dhcp select relay
# Specify the IP address of the DHCP server.
[Switch-Vlan-interface100] dhcp relay server-address 10.1.1.1
[Switch-Vlan-interface100] quit

Verifying the configuration

# Display dynamic IPv4SG bindings generated based on DHCP relay entries.

562
 [Switch] display ip source binding dhcp-relay
Total entries found: 1
IP Address MAC Address Interface VLAN Type
192.168.0.1 0001-0203-0406 Vlan100 100 DHCP relay

VLAN-interface 100 will filter packets based on the IPv4SG binding.

Example: Configuring static IPv6SG

Network configuration
As shown in Figure 141, configure a static IPv6SG binding on GigabitEthernet 1/0/1 of the device to
allow only IPv6 packets from the host to pass.
Figure 141 Network diagram

GE1/0/1
Internet

Host Device
IP: 2001::1
MAC: 0001-0202-0202

Procedure
# Enable IPv6SG on GigabitEthernet 1/0/1.
<Device> system-view
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] ipv6 verify source ip-address mac-address

# On GigabitEthernet 1/0/1, configure a static IPv6SG binding for the host.

[Device-GigabitEthernet1/0/1] ipv6 source binding ip-address 2001::1 mac-address
0001-0202-0202
[Device-GigabitEthernet1/0/1] quit

Verifying the configuration

# Verify that the static IPv6SG binding is configured successfully on the device.
[Device] display ipv6 source binding static
Total entries found: 1
IPv6 Address MAC Address Interface VLAN Type
2001::1 0001-0202-0202 GE1/0/1 N/A Static

Example: Configuring DHCPv6 snooping-based dynamic

IPv6SG address bindings
Network configuration
As shown in Figure 142, the host (the DHCPv6 client) obtains an IP address from the DHCPv6 server.
Perform the following tasks:
• Enable DHCPv6 snooping on the device to make sure the DHCPv6 client obtains an IPv6
address from the authorized DHCPv6 server. To generate a DHCPv6 snooping entry for the
DHCPv6 client, enable recording of client information in DHCPv6 snooping entries.
• Enable dynamic IPv6SG on GigabitEthernet 1/0/1 to filter incoming packets by using the
IPv6SG bindings generated based on DHCPv6 snooping entries. Only packets from the
DHCPv6 client are allowed to pass.

563
 Figure 142 Network diagram
DHCPv6 client DHCPv6 snooping DHCPv6 server

GE1/0/1 GE1/0/2

Device
Host

Procedure
1. Configure DHCPv6 snooping:
# Enable DHCPv6 snooping globally.
<Device> system-view
[Device] ipv6 dhcp snooping enable
# Configure GigabitEthernet 1/0/2 as a trusted interface.
[Device] interface gigabitethernet 1/0/2
[Device-GigabitEthernet1/0/2] ipv6 dhcp snooping trust
[Device-GigabitEthernet1/0/2] quit
2. Enable IPv6SG:
# Enable IPv6SG on GigabitEthernet 1/0/1 and verify the source IP address and MAC address
for dynamic IPv6SG.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] ipv6 verify source ip-address mac-address
# Enable recording of client information in DHCPv6 snooping entries on GigabitEthernet 1/0/1.
[Device-GigabitEthernet1/0/1] ipv6 dhcp snooping binding record
[Device-GigabitEthernet1/0/1] quit

Verifying the configuration

# Display dynamic IPv6SG bindings generated based on DHCPv6 snooping entries.
[Device] display ipv6 source binding dhcpv6-snooping
Total entries found: 1
IPv6 Address MAC Address Interface VLAN Type
2001::1 040a-0000-0001 GE1/0/1 1 DHCPv6 snooping

GigabitEthernet 1/0/1 will filter packets based on the IPv6SG binding.

Example: Configuring DHCPv6 snooping-based dynamic

IPv6SG prefix bindings
Network configuration
As shown in Figure 143, the host (the DHCPv6 client) obtains an IPv6 prefix from the DHCPv6 server.
Perform the following tasks:
• Enable DHCPv6 snooping on the device to make sure the DHCPv6 client obtains an IPv6 prefix
from the authorized DHCPv6 server. To generate a DHCPv6 snooping prefix entry for the
DHCPv6 client, enable recording IPv6 prefix information in DHCPv6 snooping entries.
• Enable dynamic IPv6SG on GigabitEthernet 1/0/1 to filter incoming packets by using the
IPv6SG bindings generated based on DHCPv6 snooping prefix entries. Only packets from the
DHCPv6 client are allowed to pass.

564
 Figure 143 Network diagram
DHCPv6 client DHCPv6 snooping DHCPv6 server

GE1/0/1 GE1/0/2

Device
Host

Procedure
1. Configure DHCPv6 snooping.
# Enable DHCPv6 snooping globally.
<Device> system-view
[Device] ipv6 dhcp snooping enable
# Configure GigabitEthernet 1/0/2 as a trusted interface.
[Device] interface gigabitethernet 1/0/2
[Device-GigabitEthernet1/0/2] ipv6 dhcp snooping trust
[Device-GigabitEthernet1/0/2] quit
# Enable recording DHCPv6 snooping prefix entries on GigabitEthernet 1/0/1.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] ipv6 dhcp snooping pd binding record
2. Enable IPv6SG.
# Enable IPv6SG on GigabitEthernet 1/0/1 and verify the source IP address and MAC address
for dynamic IPv6SG.
[Device-GigabitEthernet1/0/1] ipv6 verify source ip-address mac-address
[Device-GigabitEthernet1/0/1] quit

Verifying the configuration

# Display dynamic IPv6SG bindings generated based on DHCPv6 snooping entries.
[Device] display ipv6 source binding pd
Total entries found: 1
IPv6 prefix MAC address Interface VLAN
2001:410:1::/48 0010-9400-0004 GE1/0/1 1

GigabitEthernet 1/0/1 will filter packets based on the IPv6SG binding.

Example: Configuring DHCPv6 relay agent-based dynamic

IPv6SG
Network configuration
As shown in Figure 144, DHCPv6 relay agent is enabled on the switch. The clients obtain IPv6
addresses from the DHCPv6 server through the DHCPv6 relay agent.
Enable dynamic IPv6SG on VLAN-interface 3 to filter incoming packets by using the IPv6SG
bindings generated based on DHCPv6 relay entries.

565
 Figure 144 Network diagram
DHCPv6 client DHCPv6 client

Vlan-int3 Vlan-int2
1::1/64 2::1/64

2::2/64
Switch DHCPv6 server
DHCPv6 relay agent

DHCPv6 client DHCPv6 client

Procedure
1. Configure the DHCPv6 relay agent:
# Create VLAN 2 and VLAN 3, assign interfaces to the VLANs, and specify IP addresses for
VLAN-interface 2 and VLAN-interface 3. (Details not shown.)
# Enable the DHCPv6 relay agent on VLAN-interface 3.
[Switch] interface vlan-interface 3
[Switch-Vlan-interface3] ipv6 dhcp select relay
# Enable recording of DHCPv6 relay entries on the interface.
[Switch-Vlan-interface3] ipv6 dhcp relay client-information record
# Specify the DHCPv6 server address 2::2 on the relay agent.
[Switch-Vlan-interface3] ipv6 dhcp relay server-address 2::2
[Switch-Vlan-interface3] quit
2. Enable IPv6SG on VLAN-interface 3 and verify the source IP address and MAC address for
dynamic IPv6SG.
<Switch> system-view
[Switch] interface vlan-interface 3
[Switch-Vlan-interface3] ipv6 verify source ip-address mac-address
[Switch-Vlan-interface3] quit

Verifying the configuration

# Display dynamic IPv6SG bindings generated based on DHCPv6 relay entries.
[Switch] display ipv6 source binding dhcpv6-relay
Total entries found: 1
IP Address MAC Address Interface VLAN Type
1::2 0001-0203-0406 Vlan3 3 DHCPv6 relay

VLAN-interface 3 will filter packets based on the IPv6SG binding.

566
Configuring ARP attack protection
About ARP attack protection
The device can provide multiple features to detect and prevent ARP attacks and viruses in the LAN.
An attacker can exploit ARP vulnerabilities to attack network devices in the following ways:
• Sends a large number of unresolvable IP packets to have the receiving device busy with
resolving IP addresses until its CPU is overloaded. Unresolvable IP packets refer to IP packets
for which ARP cannot find corresponding MAC addresses.
• Sends a large number of ARP packets to overload the CPU of the receiving device.
• Acts as a trusted user or gateway to send ARP packets so the receiving devices obtain
incorrect ARP entries.

ARP attack protection tasks at a glance

All ARP attack protection tasks are optional.
• Preventing flood attacks
 Configuring unresolvable IP attack protection
 Configuring ARP packet rate limit
 Configuring source MAC-based ARP attack detection
• Preventing user and gateway spoofing attacks
 Configuring ARP packet source MAC consistency check
 Configuring ARP active acknowledgement
 Configuring authorized ARP
 Example: Configuring authorized ARP on a DHCP relay agent
 Configuring ARP attack detection
 Configuring ARP packet validity check
 Configuring ARP restricted forwarding
 Ignoring ingress ports of ARP packets during user validity check
 Enabling ARP attack detection logging
 Configuring ARP scanning and fixed ARP
 Configuring ARP gateway protection
 Example: Configuring ARP gateway protection
 Configuring ARP filtering
 Configuring ARP sender IP address checking

Configuring unresolvable IP attack protection

About 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.

567
 • 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 from an IP address if the number of
unresolvable IP packets from the IP address exceeds the upper limit within 5 seconds. The
device continues ARP resolution when the interval elapses. This feature is applicable if the
attack packets have the same source addresses.
• ARP blackhole routing—Creates a blackhole route destined for an unresolved IP address.
The device drops all matching packets until the blackhole route is deleted. A blackhole route is
deleted when its aging timer is reached or the route becomes reachable.
After a blackhole route is created for an unresolved IP address, the device immediately starts
the first ARP blackhole route probe by sending an ARP request. If the resolution fails, the
device continues probing according to the probe settings. If the IP address resolution succeeds
in a probe, the device converts the blackhole route to a normal route. If an ARP blackhole route
ages out before the device finishes all probes, the device deletes the blackhole route and does
not perform the remaining probes.
This feature is applicable regardless of whether the attack packets have the same source
addresses.

Configuring ARP source suppression

1. Enter system view.
system-view
2. Enable ARP source suppression.
arp source-suppression enable
By default, ARP source suppression is disabled.
3. Set the maximum number of unresolvable packets that the device can process per source IP
address within 5 seconds.
arp source-suppression limit limit-value
By default, the maximum number is 10.

Configuring ARP blackhole routing

Restrictions and guidelines
Set the ARP blackhole route probe count to a big value, for example, 25. If the device fails to reach
the destination IP address temporarily and the probe count is too small, all probes might finish before
the problem is resolved. As a result, non-attack packets will be dropped. This setting can avoid such
situation.
Procedure
1. Enter system view.
system-view
2. Enable ARP blackhole routing.
arp resolving-route enable
By default, ARP blackhole routing is enabled.
3. (Optional.) Set the number of ARP blackhole route probes for each unresolved IP address.
arp resolving-route probe-count count
The default setting is three probes.
4. (Optional.) Set the interval at which the device probes ARP blackhole routes.

568
 arp resolving-route probe-interval interval
The default setting is 1 second.

Display and maintenance commands for unresolvable IP

attack protection
Execute display commands in any view.

Task Command
Display ARP source suppression configuration
display arp source-suppression
information.

Example: Configuring unresolvable IP attack protection

Network configuration
As shown in Figure 145, a LAN contains two areas: an R&D area in VLAN 10 and an office area in
VLAN 20. Each area connects to the gateway (Device) through an access switch.
A large number of ARP requests are detected in the office area and are considered an attack caused
by unresolvable IP packets. To prevent the attack, configure ARP source suppression or ARP
blackhole routing.
Figure 145 Network diagram

IP network

ARP attack protection

Gateway
Device

VLAN 10 VLAN 20

Host A Host B Host C Host D

R&D Office

Procedure
• If the attack packets have the same source address, configure ARP source suppression:
# Enable ARP source suppression.
<Device> system-view
[Device] arp source-suppression enable
# Configure the device to process a maximum of 100 unresolvable packets per source IP
address within 5 seconds.

569
 [Device] arp source-suppression limit 100
• If the attack packets have different source addresses, configure ARP blackhole routing:
# Enable ARP blackhole routing.
[Device] arp resolving-route enable

Configuring ARP packet rate limit

About this task
The ARP packet rate limit feature allows you to limit the rate of ARP packets delivered to the CPU.
An ARP attack 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 ARP packet rate limit. When the receiving rate of ARP packets on the
interface exceeds the rate limit, those packets are discarded.
You can enable sending notifications to the SNMP module or enable logging for ARP packet rate
limit.
• If notification sending is enabled, the device sends the highest threshold-crossed ARP packet
rate within the sending interval in a notification to the SNMP module. You must use the
snmp-agent target-host command to set the notification type and target host. For more
information about notifications, see Network Management and Monitoring Command
Reference.
• 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. For more information about
information center, see Network Management and Monitoring Configuration Guide.
Restrictions and guidelines
As a best practice, configure this feature when ARP attack detection, ARP snooping, or MFF is
enabled, or when ARP flood attacks are detected.
If excessive notifications and log messages are sent for ARP packet rate limit, you can increase
notification and log message sending interval.
If you enable notification sending and logging for ARP packet rate limit on a Layer 2 aggregate
interface, the features apply to all aggregation member ports.
This feature is mutually exclusive with the source MAC-based ARP packet rate limit feature
configured by using the arp rate-limit source-mac command.
Procedure
1. Enter system view.
system-view
2. (Optional.) Enable SNMP notifications for ARP packet rate limit.
snmp-agent trap enable arp [ rate-limit ]
By default, SNMP notifications for ARP packet rate limit are disabled.
3. (Optional.) Enable logging for ARP packet rate limit.
arp rate-limit log enable
By default, logging for ARP packet rate limit is disabled.
4. (Optional.) Set the notification and log message sending interval.
arp rate-limit log interval interval
By default, the device sends notifications and log messages every 60 seconds.
5. Enter interface view.

570
 interface interface-type interface-number
Supported interface types include Layer 2 Ethernet interface, Layer 3 Ethernet interface, Layer
3 aggregate interface, and Layer 2 aggregate interface.
6. Enable ARP packet rate limit.
arp rate-limit [ pps ]
By default, ARP packet rate limit is enabled.

Configuring source MAC-based ARP attack

detection
About this task
This feature checks the number of ARP packets delivered to the CPU. If the number of packets from
the same MAC address within 5 seconds exceeds a threshold, the device generates an ARP attack
entry for the MAC address. If logging is enabled for source MAC-based ARP attack detection, the
device handles the attack by using either of the following methods before the ARP attack entry ages
out:
• Monitor—Only generates log messages.
• Filter—Generates log messages and filters out subsequent ARP packets from the MAC
address and data packets destined to or originated from the MAC address.
To enable the ARP logging feature, use the arp source-mac log enable command. For
information about the ARP logging feature, see ARP in Layer 3—IP Services Configuration Guide.
When an ARP attack entry ages out, ARP packets sourced from the MAC address in the entry can be
processed correctly.
Restrictions and guidelines
When you change the handling method from monitor to filter, the configuration takes effect
immediately. When you change the handling method from filter to monitor, the device continues
filtering packets that match existing attack entries.
You 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.
Procedure
1. Enter system view.
system-view
2. Enable source MAC-based ARP attack detection and specify the handling method.
arp source-mac { filter | monitor }
By default, this feature is disabled.
3. Set the threshold.
arp source-mac threshold threshold-value
By default, the threshold is 30.
4. Set the aging timer for ARP attack entries.
arp source-mac aging-time time
By default, the lifetime is 300 seconds.
5. (Optional.) Exclude specific MAC addresses from this detection.
arp source-mac exclude-mac mac-address&<1-10>
By default, no MAC address is excluded.
6. Enable logging for source MAC-based ARP attack detection.

571
 arp source-mac log enable
By default, logging for source MAC-based ARP attack detection is disabled.

Display and maintenance commands for source MAC-based

ARP attack detection
Execute display commands in any view.

Task Command
display arp source-mac { interface
Display ARP attack entries detected by source
interface-type interface-number [ slot
MAC-based ARP attack detection.
slot-number ] | slot slot-number }

Example: Configuring source MAC-based ARP attack

detection
Network configuration
As shown in Figure 146, the hosts access the Internet through a gateway (Device). If malicious users
send a large number of ARP requests to the gateway, the gateway might crash and cannot process
requests from the clients. To solve this problem, configure source MAC-based ARP attack detection
on the gateway.
Figure 146 Network diagram

IP network

ARP attack protection

Gateway
Device
Server
0012-3f 86-e 94c

Host A Host B Host C Host D

Procedure
# Enable source MAC-based ARP attack detection, and specify the handling method as filter.
<Device> system-view
[Device] arp source-mac filter

572
 # Set the threshold to 30.
[Device] arp source-mac threshold 30

# Set the lifetime for ARP attack entries to 60 seconds.

[Device] arp source-mac aging-time 60

# Exclude MAC address 0012-3f86-e94c from this detection.

[Device] arp source-mac exclude-mac 0012-3f86-e94c

Configuring ARP packet source MAC consistency

check
About ARP packet source MAC consistency check
This feature enables a gateway to filter out ARP packets 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.

Procedure
1. Enter system view.
system-view
2. Enable ARP packet source MAC address consistency check.
arp valid-check enable
By default, ARP packet source MAC address consistency check is disabled.

Configuring ARP active acknowledgement

About this task
Use the ARP active acknowledgement feature on gateways to prevent user spoofing.
This feature enables the device to perform active acknowledgement before creating an ARP entry.
• Upon receiving an ARP request that requests the MAC address of the device, the device sends
an ARP reply. Then, it sends an ARP request for the sender IP address in the received ARP
request to determine whether to create an ARP entry for the sender IP address.
 If the device receives an ARP reply within the probe interval, it creates the ARP entry.
 If the device does not receive an ARP reply within the probe interval, it does not create the
ARP entry.
• Upon receiving an ARP reply, the device examines whether it was the reply to the request that
the device has sent.
 If it was, the device creates an ARP entry for the sender IP address in the ARP reply.
 If it was not, the device sends an ARP request for the sender IP address to determine
whether to create an ARP entry for the sender IP address.
− If the device receives an ARP reply within the probe interval, it creates the ARP entry.
− If the device does not receive an ARP reply within the probe interval, it does not create
the ARP entry.
To improve validity and reliability of ARP entries, you can enable ARP active acknowledgement in
strict mode. In this mode, the device creates ARP entries only for the IP addresses that the device
actively initiates the ARP resolution.

573
Procedure
1. Enter system view.
system-view
2. Enable ARP active acknowledgement.
arp active-ack [ strict ] enable
By default, ARP active acknowledgement is disabled.
For ARP active acknowledgement to take effect in strict mode, make sure ARP blackhole
routing is enabled.

Configuring authorized ARP

About 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. For more information about DHCP server
and DHCP relay agent, see Layer 3—IP Services Configuration Guide.
Use this feature to prevent user spoofing and to allow only authorized clients to access network
resources.

Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
Supported interface types include Layer 3 Ethernet interface, Layer 3 Ethernet subinterface,
Layer 3 aggregate interface, Layer 3 aggregate subinterface, and VLAN interface.
3. Enable authorized ARP on the interface.
arp authorized enable
By default, authorized ARP is disabled.

Example: Configuring authorized ARP on a DHCP server

Network configuration
As shown in Figure 147, configure authorized ARP on GigabitEthernet 1/0/1 of Device A (a DHCP
server) to ensure user validity.
Figure 147 Network diagram
DHCP server DHCP client
GE1/0/1
GE1/0/1
10.1.1.1/24
Device A Device B

Procedure
1. Configure Device A:
# Specify the IP address for GigabitEthernet 1/0/1.
<DeviceA> system-view

574
 [DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] ip address 10.1.1.1 24
[DeviceA-GigabitEthernet1/0/1] quit
# Configure DHCP.
[DeviceA] dhcp enable
[DeviceA] dhcp server ip-pool 1
[DeviceA-dhcp-pool-1] network 10.1.1.0 mask 255.255.255.0
[DeviceA-dhcp-pool-1] quit
# Enter Layer 3 Ethernet interface view.
[DeviceA] interface gigabitethernet 1/0/1
# Enable authorized ARP.
[DeviceA-GigabitEthernet1/0/1] arp authorized enable
[DeviceA-GigabitEthernet1/0/1] quit
2. Configure Device B:
<DeviceB> system-view
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] ip address dhcp-alloc
[DeviceB-GigabitEthernet1/0/1] quit

Verifying the configuration

# Display authorized ARP entry information on Device A.
[DeviceA] display arp all
Type: S-Static D-Dynamic O-Openflow R-Rule M-Multiport I-Invalid
IP address MAC address VLAN/VSI name Interface Aging Type
10.1.1.2 0012-3f86-e94c -- GE1/0/1 960 D

The output shows that IP address 10.1.1.2 has been assigned to Device B.
Device B must use the IP address and MAC address in the authorized ARP entry to communicate
with Device A. Otherwise, the communication fails. Thus user validity is ensured.

Example: Configuring authorized ARP on a DHCP relay

agent
Network configuration
As shown in Figure 148, configure authorized ARP on GigabitEthernet 1/0/2 of Device B (a DHCP
relay agent) to ensure user validity.
Figure 148 Network diagram
DHCP relay agent

GE1/0/1 GE1/0/2
10.1.1.2/24 10.10.1.1/24
Device B

DHCP server DHCP client

GE1/0/1 GE1/0/2
10.1.1.1/24

Device A Device C

575
Procedure
1. Configure Device A:
# Specify the IP address for GigabitEthernet 1/0/1.
<DeviceA> system-view
[DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] ip address 10.1.1.1 24
[DeviceA-GigabitEthernet1/0/1] quit
# Configure DHCP.
[DeviceA] dhcp enable
[DeviceA] dhcp server ip-pool 1
[DeviceA-dhcp-pool-1] network 10.10.1.0 mask 255.255.255.0
[DeviceA-dhcp-pool-1] gateway-list 10.10.1.1
[DeviceA-dhcp-pool-1] quit
[DeviceA] ip route-static 10.10.1.0 24 10.1.1.2
2. Configure Device B:
# Enable DHCP.
<DeviceB> system-view
[DeviceB] dhcp enable
# Specify the IP addresses of GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2.
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] ip address 10.1.1.2 24
[DeviceB-GigabitEthernet1/0/1] quit
[DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] ip address 10.10.1.1 24
# Enable DHCP relay agent on GigabitEthernet 1/0/2.
[DeviceB-GigabitEthernet1/0/2] dhcp select relay
# Add the DHCP server 10.1.1.1 to DHCP server group 1.
[DeviceB-GigabitEthernet1/0/2] dhcp relay server-address 10.1.1.1
# Enable authorized ARP.
[DeviceB-GigabitEthernet1/0/2] arp authorized enable
[DeviceB-GigabitEthernet1/0/2] quit
# Enable recording of relay entries on the relay agent.
[DeviceB] dhcp relay client-information record
3. Configure Device C:
<DeviceC> system-view
[DeviceC] ip route-static 10.1.1.0 24 10.10.1.1
[DeviceC] interface gigabitethernet 1/0/2
[DeviceC-GigabitEthernet1/0/2] ip address dhcp-alloc
[DeviceC-GigabitEthernet1/0/2] quit

Verifying the configuration

# Display authorized ARP information on Device B.
[DeviceB] display arp all
Type: S-Static D-Dynamic O-Openflow R-Rule M-Multiport I-Invalid
IP address MAC address VLAN/VSI name Interface Aging Type
10.10.1.2 0012-3f86-e94c -- GE1/0/2 960 D

The output shows that Device A assigned the IP address 10.10.1.2 to Device C.

576
 Device C must use the IP address and MAC address in the authorized ARP entry to communicate
with Device B. Otherwise, the communication fails. Thus the user validity is ensured.

Configuring ARP attack detection

About ARP attack detection
ARP attack detection enables access devices to block ARP packets from unauthorized clients to
prevent user spoofing and gateway spoofing attacks.
ARP attack detection provides the following features:
• User validity check.
• ARP packet validity check.
• ARP restricted forwarding.
• ARP packet ingress port ignoring during user validity check
• ARP attack detection for a VSI.
• ARP attack detection logging.
If both ARP packet validity check and user validity check are enabled, the former one applies first,
and then the latter applies.
Do not configure ARP attack detection together with ARP snooping. Otherwise, ARP snooping
entries cannot be generated.

Restrictions and guidelines: ARP attack detection

ARP attack detection is supported only on Layer 2 Ethernet interfaces and Layer 2 aggregate
interfaces.
A Layer 2 Ethernet interface is enabled with ARP attack detection after you enable ARP attack
detection on the interface or in the VLAN to which the interface belongs.
A Layer 2 Ethernet interface is disabled with ARP attack detection only after you disable ARP attack
detection both on the interface and in the VLAN to which the interface belongs.
If a Layer 2 Ethernet interface is both enabled with ARP attack detection and configured as an ARP
trusted port, the ARP trusted port configuration takes effect. The device does not perform ARP attack
detection on packets received on the interface.

Configuring user validity check

About this task
User validity check does not check ARP packets received on ARP trusted interfaces. This feature
compares the sender IP and sender MAC in the ARP packet received on an ARP untrusted interface
with the matching criteria in the following order:
1. User validity check rules.
 If a match is found, the device processes the ARP packet according to the rule.
 If no match is found or no user validity check rule is configured, proceeds to step 2.
2. Static IPSG bindings, 802.1X security entries, and DHCP snooping entries.
 If a match is found, the device determines that the ARP packet is valid and then forwards
the ARP packet.
− If the receiving interface is not the interface in the matching entry, the device performs
Layer 3 forwarding on the ARP packet based on the target IP address.

577
 − If the receiving interface is the interface in the matching entry, the device performs Layer
2 forwarding on the ARP packet.
 If no match is found, the device discards the ARP packet.
Static IP source guard bindings are created by using the ip source binding command. For more
information, see "Configuring IP source guard."
DHCP snooping entries are automatically generated by DHCP snooping. For more information, see
Layer 3—IP Services Configuration Guide.
802.1X security entries record the IP-to-MAC mappings for 802.1X clients. After a client passes
802.1X authentication and uploads its IP address to an ARP attack detection enabled device, the
device automatically generates an 802.1X security entry. The 802.1X client must be enabled to
upload its IP address to the device. For more information, see "Configuring 802.1X."
Restrictions and guidelines
When you configure user validity check, make sure one or more of the following items are
configured:
• User validity check rules.
• Static IP source guard bindings.
• DHCP snooping.
• 802.1X.
If none of the items is configured, the device does not perform user validity check and forwards all
incoming ARP packets on ARP untrusted interfaces.
Specify an IP address, a MAC address, and a VLAN where ARP attack detection is enabled for an IP
source guard binding. Otherwise, no ARP packets can match the IP source guard binding.
Configuring ueser validity check rules
1. Enter system view.
system-view
2. Configure a user validity check rule.
arp detection rule rule-id { deny | permit } ip { ip-address [ mask ] | any }
mac { mac-address [ mask ] | any } [ vlan vlan-id ]
By default, no user validity check rules are configured.
Enabling ARP attack detection in a VLAN
1. Enter system view.
system-view
2. Enter VLAN view.
vlan vlan-id
3. Enable ARP attack detection.
arp detection enable
By default, ARP attack detection is disabled. The device does not perform ARP user validity
check.
4. (Optional.) Configure an interface that does not require ARP user validity check as a trusted
interface.
a. Return to system view.
quit
b. Enter interface view.
interface interface-type interface-number

578
 Supported interface types include Layer 2 Ethernet interface and Layer 2 aggregate
interface.
c. Configure the interface as a trusted interface excluded from ARP attack detection.
arp detection trust
By default, an interface is untrusted.
Enabling ARP attack detection on a Layer 2 interface
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
Supported interfaces include Layer 2 Ethernet interfaces and Layer 2 aggregate interfaces.
3. Enable ARP attack detection.
arp detection enable
By default, ARP attack detection is disabled. The device does not perform user validity check

Configuring ARP packet validity check

About this task
ARP packet validity check does not check ARP packets received on ARP trusted interfaces. To
check ARP packets received on untrusted interfaces, you can specify the following objects to be
checked:
• src-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.
• dst-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.
Prerequisites
Before you configure ARP packet validity check, you must first configure user validity check. For
more information about user validity check configuration, see "Configuring user validity check."
Enabling ARP packet validity check
1. Enter system view.
system-view
2. Enable ARP packet validity check.
arp detection validate { dst-mac | ip | src-mac } *
By default, ARP packet validity check is disabled.
Enabling ARP attack detection in a VLAN
1. Enter system view.
system-view
2. Enter VLAN view.
vlan vlan-id
3. Enable ARP attack detection.

579
 arp detection enable
By default, ARP attack detection is disabled. The device does not perform ARP packet validity
check.
4. (Optional.) Configure the interface that does not require ARP packet validity check as a trusted
interface.
a. Return to system view.
quit
b. Enter interface view.
interface interface-type interface-number
Supported interface types include Layer 2 Ethernet interface and Layer 2 aggregate
interface.
c. Configure the interface as a trusted interface excluded from ARP attack detection.
arp detection trust
By default, an interface is untrusted.
Enabling ARP attack detection on a Layer 2 interface
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
Supported interfaces include Layer 2 Ethernet interfaces and Layer 2 aggregate interfaces.
3. Enable ARP attack detection.
arp detection enable
By default, ARP attack detection is disabled. The device does not perform ARP packet validity
check.

Configuring ARP restricted forwarding

About this task
ARP restricted forwarding does not take effect on ARP packets received on ARP trusted interfaces
and forwards the ARP packets correctly. This feature controls the forwarding of ARP packets that are
received on untrusted interfaces and have passed user validity 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 table, they are forwarded through the trusted interface.
Restrictions and guidelines
ARP restricted forwarding does not apply to ARP packets that use multiport destination MAC
addresses.
Prerequisites
Configure user validity check before you configure ARP restricted forwarding. For information about
user validity check configuration, see "Configuring user validity check."
Procedure
1. Enter system view.
system-view
2. Enter VLAN view.
vlan vlan-id

580
 3. Enable ARP restricted forwarding.
arp restricted-forwarding enable
By default, ARP restricted forwarding is disabled.

Ignoring ingress ports of ARP packets during user validity

check
About this task
ARP attack detection performs user validity check on ARP packets from ARP untrusted interfaces.
The sender IP and sender MAC in the received ARP packet are compared with the entries used for
user validity check. In addition, user validity check compares the ingress port of the ARP packet with
the port in the entries. If no matching port is found, the ARP packet is discarded. For more
information about user validity check, see "Configuring user validity check."
You can configure the device to ignore the ingress ports of ARP packets during user validity check. If
an ARP packet passes user validity check, the device directly performs Layer 2 forwarding on the
packet. It no longer searches for a matching static IPSG binding, 802.1X security entry, or DHCP
snooping entry by the target IP address of the ARP packet.
Procedure
1. Enter system view.
system-view
2. Ignore ingress ports of ARP packets during user validity check.
arp detection port-match-ignore
By default, ingress ports of ARP packets are checked during user invalidity.

Configuring ARP attack detection for a VSI

About this task
In VXLAN networks, you can configure a VTEP to perform ARP attack detection in a VSI. ARP attack
detection performs user validity check and ARP packet validity check on ARP packets from ARP
untrusted ACs. For information about ACs, see VXLAN Configuration Guide.
The user validity check and ARP packet validity check mechanisms for a VSI are the same as those
for a VLAN. For more information, see "Configuring user validity check" and "Configuring ARP
packet validity check."
Configuring user validity check for a VSI
1. Enter system view.
system-view
2. (Optional.) Configure a user validity check rule.
arp detection rule rule-id { deny | permit } ip { ip-address [ mask ] |
any } mac { mac-address [ mask ] | any } [ vlan vlan-id ]
By default, no user validity check rule is configured.
3. Enter VSI view.
vsi vsi-name
4. Enable ARP attack detection.
arp detection enable
By default, ARP attack detection is disabled.
5. (Optional.) Configure an AC as a trusted AC excluded from ARP attack detection.

581
 a. Return to system view.
quit
b. Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view.
interface interface-type interface-number
c. Enter Ethernet service instance view.
service-instance instance-id
d. Configure the AC as a trusted AC excluded from ARP attack detection
arp detection trust
By default, an AC is untrusted.
Configuring ARP packet validity check for a VSI
1. Enter system view.
system-view
2. Enter VSI view.
vsi vsi-name
3. Enable ARP attack detection.
arp detection enable
By default, ARP attack detection is disabled.
4. Return to system view.
quit
5. Enable ARP packet validity check and specify the objects to be checked.
arp detection validate { dst-mac | ip | src-mac } *
By default, ARP packet validity check is disabled.
6. (Optional.) Configure an AC as a trusted AC excluded from ARP attack detection
a. Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view.
interface interface-type interface-number
b. Enter Ethernet service instance view.
service-instance instance-id
c. Configure the AC as a trusted AC excluded from ARP attack detection.
arp detection trust
By default, an AC is untrusted.

Enabling ARP attack detection logging

About this task
The ARP attack detection logging feature enables a device to generate ARP attack detection log
messages when illegal ARP packets are detected. An ARP attack detection log message contains
the following information:
• Receiving interface of the ARP packets.
• Sender IP address.
• Total number of dropped ARP packets.
Procedure
1. Enter system view.
system-view

582
 2. Enable ARP attack detection logging.
arp detection log enable [ interval interval | number number | threshold
threshold-value ] *
By default, ARP attack detection logging is disabled.

Display and maintenance commands for ARP attack

detection
Execute display commands in any view and reset commands in user view.

Task Command
Display the VLANs, VSIs, and
interfaces enabled with ARP attack display arp detection
detection.

Display ARP attack source display arp detection statistics attack-source

statistics. slot slot-number
Display statistics for packets display arp detection statistics packet-drop
dropped by ARP attack detection. [ interface interface-type interface-number ]
reset arp detection statistics attack-source
Clear ARP attack source statistics.
[ slot slot-number ]
Clear statistics for packets reset arp detection statistics packet-drop
dropped by ARP attack detection. [ interface interface-type interface-number ]

Example: Configuring user validity check

Network configuration
As shown in Figure 149, configure Device B to perform user validity check based on 802.1X security
entries for connected hosts.
Figure 149 Network diagram
Gateway
Device A DHCP server

GE1/0/3
Vlan-int10
10.1.1.1/24

VLAN 10
GE1/0/3
Device B

GE1/0/1 GE1/0/2

Host A Host B

583
Procedure
1. Add all interfaces on Device B to VLAN 10, and specify the IP address of VLAN-interface 10 on
Device A. (Details not shown.)
2. Configure the DHCP server on Device A, and configure DHCP address pool 0.
<DeviceA> system-view
[DeviceA] dhcp enable
[DeviceA] dhcp server ip-pool 0
[DeviceA-dhcp-pool-0] network 10.1.1.0 mask 255.255.255.0
3. Configure Host A and Host B as 802.1X clients and configure them to upload IP addresses for
ARP attack detection. (Details not shown.)
4. Configure Device B:
# Enable 802.1X.
<DeviceB> system-view
[DeviceB] dot1x
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] dot1x
[DeviceB-GigabitEthernet1/0/1] quit
[DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] dot1x
[DeviceB-GigabitEthernet1/0/2] quit
# Add a local user test.
[DeviceB] local-user test class network
[DeviceB-luser-network-test] service-type lan-access
[DeviceB-luser-network-test] password simple test
[DeviceB-luser-network-test] quit
# Enable ARP attack detection for VLAN 10 to check user validity based on 802.1X entries.
[DeviceB] vlan 10
[DeviceB-vlan10] arp detection enable
# Configure the upstream interface as an ARP trusted interface. By default, an interface is an
untrusted interface.
[DeviceB-vlan10] interface gigabitethernet 1/0/3
[DeviceB-GigabitEthernet1/0/3] arp detection trust
[DeviceB-GigabitEthernet1/0/3] quit

Verifying the configuration

# Verify that ARP packets received on interfaces GigabitEthernet 1/0/1 and GigabitEthernet
1/0/2 are checked against 802.1X entries.

Example: Configuring user validity check and ARP packet

validity check
Network configuration
As shown in Figure 150, configure Device B to perform ARP packet validity check and user validity
check based on static IP source guard bindings and DHCP snooping entries for connected hosts.

584
 Figure 150 Network diagram
Gateway
Device A DHCP server

GE1/0/3
Vlan-int10
10.1.1.1/24

VLAN 10
DHCP snooping GE1/0/3
Device B

GE1/0/1 GE1/0/2

Host A Host B
DHCP client 10.1.1.6
0001-0203-0607

Procedure
1. Add all interfaces on Device B to VLAN 10, and specify the IP address of VLAN-interface 10 on
Device A. (Details not shown.)
2. Configure the DHCP server on Device A, and configure DHCP address pool 0.
<DeviceA> system-view
[DeviceA] dhcp enable
[DeviceA] dhcp server ip-pool 0
[DeviceA-dhcp-pool-0] network 10.1.1.0 mask 255.255.255.0
3. Configure Host A (DHCP client) and Host B. (Details not shown.)
4. Configure Device B:
# Enable DHCP snooping.
<DeviceB> system-view
[DeviceB] dhcp snooping enable
[DeviceB] interface gigabitethernet 1/0/3
[DeviceB-GigabitEthernet1/0/3] dhcp snooping trust
[DeviceB-GigabitEthernet1/0/3] quit
# Enable recording of client information in DHCP snooping entries on GigabitEthernet 1/0/1.
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] dhcp snooping binding record
[DeviceB-GigabitEthernet1/0/1] quit
# Enable ARP attack detection for VLAN 10.
[DeviceB] vlan 10
[DeviceB-vlan10] arp detection enable
# Configure the upstream interface as a trusted interface. By default, an interface is an
untrusted interface.
[DeviceB-vlan10] interface gigabitethernet 1/0/3
[DeviceB-GigabitEthernet1/0/3] arp detection trust
[DeviceB-GigabitEthernet1/0/3] quit
# Configure a static IP source guard binding entry on interface GigabitEthernet 1/0/2 for user
validity check.

585
 [DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] ip source binding ip-address 10.1.1.6 mac-address
0001-0203-0607 vlan 10
[DeviceB-GigabitEthernet1/0/2] quit
# Enable ARP packet validity check by checking the MAC addresses and IP addresses of ARP
packets.
[DeviceB] arp detection validate dst-mac ip src-mac

Verifying the configuration

# Verify that Device B first checks the validity of ARP packets received on GigabitEthernet 1/0/1
and GigabitEthernet 1/0/2. If the ARP packets are confirmed valid, Device B performs user
validity check by using the static IP source guard bindings and finally DHCP snooping entries.

Example: Configuring ARP restricted forwarding

Network configuration
As shown in Figure 151, configure ARP restricted forwarding on Device B where ARP attack
detection is configured. Port isolation configured on Device B can take effect for broadcast ARP
requests.
Figure 151 Network diagram
Gateway
Device A DHCP server

GE1/0/3
Vlan-int10
10.1.1.1/24

VLAN 10
DHCP snooping GE1/0/3
Device B

GE1/0/1 GE1/0/2

Host A Host B
DHCP client 10.1.1.6
0001-0203-0607

Procedure
1. Configure VLAN 10, add interfaces to VLAN 10, and specify the IP address of VLAN-interface
10 on Device A. (Details not shown.)
2. Configure the DHCP server on Device A, and configure DHCP address pool 0.
<DeviceA> system-view
[DeviceA] dhcp enable
[DeviceA] dhcp server ip-pool 0
[DeviceA-dhcp-pool-0] network 10.1.1.0 mask 255.255.255.0
3. Configure Host A (DHCP client) and Host B. (Details not shown.)
4. Configure Device B:
# Enable DHCP snooping, and configure GigabitEthernet 1/0/3 as a DHCP trusted interface.
<DeviceB> system-view

586
 [DeviceB] dhcp snooping enable
[DeviceB] interface gigabitethernet 1/0/3
[DeviceB-GigabitEthernet1/0/3] dhcp snooping trust
[DeviceB-GigabitEthernet1/0/3] quit
# Enable ARP attack detection for user validity check.
[DeviceB] vlan 10
[DeviceB-vlan10] arp detection enable
# Configure GigabitEthernet 1/0/3 as an ARP trusted interface.
[DeviceB-vlan10] interface gigabitethernet 1/0/3
[DeviceB-GigabitEthernet1/0/3] arp detection trust
[DeviceB-GigabitEthernet1/0/3] quit
# Configure a static IP source guard entry on interface GigabitEthernet 1/0/2.
[DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] ip source binding ip-address 10.1.1.6 mac-address
0001-0203-0607 vlan 10
[DeviceB-GigabitEthernet1/0/2] quit
# Enable ARP packet validity check by checking the MAC addresses and IP addresses of ARP
packets.
[DeviceB] arp detection validate dst-mac ip src-mac
# Configure port isolation.
[DeviceB] port-isolate group 1
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] port-isolate enable group 1
[DeviceB-GigabitEthernet1/0/1] quit
[DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] port-isolate enable group 1
[DeviceB-GigabitEthernet1/0/2] quit
After the configurations are completed, Device B first checks the validity of ARP packets
received on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2. If the ARP packets are confirmed
valid, Device B performs user validity check by using the static IP source guard bindings and
finally DHCP snooping entries. However, ARP broadcast requests sent from Host A can pass
the check on Device B and reach Host B. Port isolation fails.
# Enable ARP restricted forwarding.
[DeviceB] vlan 10
[DeviceB-vlan10] arp restricted-forwarding enable
[DeviceB-vlan10] quit

Verifying the configuration

# Verify that Device B forwards ARP broadcast requests from Host A to Device A through the
trusted interface GigabitEthernet 1/0/3. Host B cannot receive such packets. Port isolation
operates correctly.

Configuring ARP scanning and fixed ARP

About this task
ARP scanning is typically used together with the fixed ARP feature in small-scale and stable
networks.

587
 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 address range.
2. Obtains their MAC addresses through received ARP replies.
3. Creates dynamic ARP entries.
You can manually trigger ARP scanning or enable automatic ARP scanning. Automatic ARP
scanning periodically sends ARP requests for all IP addresses in the range at the specified rate.
Fixed ARP converts existing dynamic ARP entries (including those generated through ARP scanning)
to static ARP entries. These static ARP entries are of the same attributes as the ARP entries that are
manually configured. This feature prevents ARP entries from being modified by attackers.
You can set the ARP packet sending rate if the scanning range has a large number of IP addresses.
This setting can avoid high CPU usage and heavy network load caused by a burst of ARP traffic.

Restrictions and guidelines

IP addresses in existing ARP entries are not scanned.
ARP scanning will take some time. To stop an ongoing scan, press Ctrl + C. Dynamic ARP entries
are created based on ARP replies received before the scan is terminated.
Due to the limit on the total number of static ARP entries, some dynamic ARP entries might fail the
conversion.
If you trigger ARP scanning and enable automatic ARP scanning, both of them take effect. As a best
practice, use automatic ARP scanning only on networks where users come online and go offline
frequently.
The arp fixup command is a one-time operation. You can use this command again to convert the
dynamic ARP entries learned later to static.
To delete a static ARP entry converted from a dynamic one, use the undo arp ip-address
[ vpn-instance-name ] command. You can also use the reset arp all command to delete
all ARP entries or the reset arp static command to delete all static ARP entries.

Triggering an ARP scanning

1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Trigger an ARP scanning.
arp scan [ start-ip-address to end-ip-address ] [ send-rate { ppm ppm |
pps } ]

Configuring automatic ARP scanning

1. Enter system view.
system-view
2. Set the ARP packet sending rate for automatic ARP scanning.
arp scan auto send-rate { ppm ppm | pps pps }
By default, the device sends ARP packets at the rate of 48 pps during automatic ARP scanning.
3. Enter interface view.

588
 interface interface-type interface-number
4. Enable automatic ARP scanning.
arp scan auto enable [start-ip-address to end-ip-address]
By default, automatic ARP scanning is disabled.

Configuring fixed ARP

1. Enter system view.
system-view
2. Convert existing dynamic ARP entries to static ARP entries.
arp fixup

Configuring ARP gateway protection

About 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.

Restrictions and guidelines

You can enable ARP gateway protection for a maximum of eight gateways on an interface.
Do not configure both the arp filter source and arp filter binding commands on an
interface.
If ARP gateway protection works with ARP attack detection, MFF, and ARP snooping, ARP gateway
protection applies first.

Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
Supported interface types include Layer 2 Ethernet interface and Layer 2 aggregate interface.
3. Enable ARP gateway protection for the specified gateway.
arp filter source ip-address
By default, ARP gateway protection is disabled.

Example: Configuring ARP gateway protection

Network configuration
As shown in Figure 152, Host B launches gateway spoofing attacks to Device B. As a result, traffic
that Device B intends to send to Device A is sent to Host B.

589
 Configure Device B to block such attacks.
Figure 152 Network diagram

Gateway
Device A 10.1.1.1/24

GE1/0/3
Device B

GE1/0/1 GE1/0/2

Host A Host B

Procedure
# Configure ARP gateway protection on Device B.
<DeviceB> system-view
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] arp filter source 10.1.1.1
[DeviceB-GigabitEthernet1/0/1] quit
[DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] arp filter source 10.1.1.1

Verifying the configuration

# Verify that GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 discard the incoming ARP packets
whose sender IP address is the IP address of the gateway.

Configuring ARP filtering

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.

Restrictions and guidelines

You can configure a maximum of eight permitted entries on an interface.
Do not configure both the arp filter source and arp filter binding commands on an
interface.
If ARP filtering works with ARP attack detection, MFF, and ARP snooping, ARP filtering applies first.

590
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
Supported interface types include Ethernet interface and Layer 2 aggregate interface.
3. Enable ARP filtering and configure a permitted entry.
arp filter binding ip-address mac-address
By default, ARP filtering is disabled.

Example: Configuring ARP filtering

Network configuration
As shown in Figure 153, the IP and MAC addresses of Host A are 10.1.1.2 and 000f-e349-1233,
respectively. The IP and MAC addresses of Host B are 10.1.1.3 and 000f-e349-1234, respectively.
Configure ARP filtering on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 of Device B to permit
ARP packets from only Host A and Host B.
Figure 153 Network diagram

Device A

GE1/0/3
Device B

GE1/0/1 GE1/0/2

Host A Host B

Procedure
# Configure ARP filtering on Device B.
<DeviceB> system-view
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] arp filter binding 10.1.1.2 000f-e349-1233
[DeviceB-GigabitEthernet1/0/1] quit
[DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] arp filter binding 10.1.1.3 000f-e349-1234

Verifying the configuration

# Verify that GigabitEthernet 1/0/1 permits ARP packets from Host A and discards other ARP
packets.

591
 # Verify that GigabitEthernet 1/0/2 permits ARP packets from Host B and discards other ARP
packets.

Configuring ARP sender IP address checking

About ARP sender IP address checking
This feature allows a gateway to check the sender IP address of an ARP packet in a VLAN before
ARP learning. If the sender IP address is within the allowed IP address range, the gateway continues
ARP learning. If the sender IP address is out of the range, the gateway determines the ARP packet
as an attack packet and discards it.

Restrictions and guidelines

If the VLAN is a sub-VLAN and is associated with a super VLAN, configure this checking feature only
in the sub-VLAN.
If Layer 3 communication is configured between the secondary VLANs associated with a primary
VLAN, configure this feature in the primary VLAN. If Layer 3 communication is not configured
between the secondary VLANs associated with a primary VLAN, configure this feature in the
intended VLAN.

Procedure
1. Enter system view.
system-view
2. Enter VLAN view.
vlan vlan-id
3. Enable the ARP sender IP address checking feature and specify the IP address range.
arp sender-ip-range start-ip-address end-ip-address
By default, the ARP sender IP address checking feature is disabled.

Example: Configuring ARP sender IP address checking

Network configuration
As shown in Figure 154, perform the following tasks:
• Create a super VLAN and associate it with VLANs 2, 3, and 4. VLANs 2, 3, and 4 are isolated at
Layer 2 but interoperable at Layer 3. All hosts in VLANs 2, 3, and 4 use the gateway IP address
10.1.1.1/24 for Layer 3 communication.
• Configure the ARP sender IP address checking feature in VLAN 2 and specify the sender IP
address range 10.1.1.1 to 10.1.1.10.

592
 Figure 154 Network diagram

VLAN 2

Host

VLAN 3 GE1/0/1 GE1/0/2

GE1/0/3 Device
IP network
Vlan-int10
GE1/0/4 10.1.1.1/24
Host GE1/0/5 GE1/0/6

VLAN 4

Host

Procedure
# Create VLAN 10.
<Device> system-view
[Device] vlan 10
[Device-vlan10] quit

# Create VLAN-interface 10, and assign IP address 10.1.1.1/24 to it.

[Device] interface vlan-interface 10
[Device-Vlan-interface10] ip address 10.1.1.1 255.255.255.0
[Device] quit

# Create VLAN 2, and assign GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 to the VLAN.
[Device] vlan 2
[Device-vlan2] port gigabitethernet 1/0/1 gigabitethernet 1/0/2
[Device-vlan2] quit

# Create VLAN 3, and assign GigabitEthernet 1/0/3 and GigabitEthernet 1/0/4 to the VLAN.
[Device] vlan 3
[Device-vlan3] port gigabitethernet 1/0/3 gigabitethernet 1/0/4
[Device-vlan3] quit

# Create VLAN 4, and assign GigabitEthernet 1/0/5 and GigabitEthernet 1/0/6 to the VLAN.
[Device] vlan 4
[Device-vlan4] port gigabitethernet 1/0/5 gigabitethernet 1/0/6
[Device-vlan4] quit

# Configure VLAN 10 as a super VLAN, and associate sub-VLANs 2, 3, and 4 with the super VLAN.
[Device] vlan 10
[Device-vlan10] supervlan
[Device-vlan10] subvlan 2 3 4
[Device-vlan10] quit

# Enable the ARP sender IP address checking feature in VLAN 2 and specify the IP address range
10.1.1.1 to 10.1.1.10.
[Device] vlan 2
[Device-vlan2] arp sender-ip-range 10.1.1.1 10.1.1.10

593
Verifying the configuration
# Verify that the device accepts only ARP packets whose sender IP addresses are within the
specified address range 10.1.1.1 to 10.1.1.10. The device discards the ARP packets with the sender
IP addresses that are out of the range.

594
Configuring ND attack defense
About ND attack defense
IPv6 Neighbor Discovery (ND) attack defense is able to identify forged ND messages to prevent ND
attacks.
The IPv6 ND protocol does not provide any security mechanisms and is vulnerable to network
attacks. As shown in Figure 155, an attacker can send the following forged ICMPv6 messages to
perform ND attacks:
• Forged NS/NA/RS messages with an IPv6 address of a victim host. The gateway and other
hosts update the ND entry for the victim with incorrect address information. As a result, all
packets intended for the victim are sent to the attacking terminal.
• Forged RA messages with the IPv6 address of a victim gateway. As a result, all hosts attached
to the victim gateway maintain incorrect IPv6 configuration parameters and ND entries.
Figure 155 ND attack diagram
Device

Host A Host C
IP_C
MAC_C

Forged ND Forged ND
messages messages

Host B
IP_B
MAC_B

ND attack defense tasks at a glance

All ND attack defense tasks are optional.
• Enabling source MAC consistency check for ND messages
• Configuring ND attack detection
• Configuring RA guard

595
Enabling source MAC consistency check for ND
messages
About this task
The source MAC consistency check feature is typically configured on gateways to prevent ND
attacks.
This feature checks the source MAC address and the source link-layer address for consistency for
each arriving ND message.
• If the source MAC address and the source link-layer address are not the same, the device
drops the packet.
• If the addresses are the same, the device continues learning ND entries.
The ND logging feature logs source MAC inconsistency events, and it sends the log messages to the
information center. The information center can then output log messages from different source
modules to different destinations. For more information about the information center, see Network
Management and Monitoring Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enable source MAC consistency check for ND messages.
ipv6 nd mac-check enable
By default, source MAC consistency check is disabled for ND messages.
3. (Optional.) Enable the ND logging feature.
ipv6 nd check log enable
By default, the ND logging feature is disabled.
As a best practice, disable the ND logging feature to avoid excessive ND logs.

Configuring ND attack detection

About ND attack detection
ND attack detection checks incoming ND messages for user validity to prevent spoofing attacks. It is
typically configured on access devices.
ND attack detection is applicable to interfaces, VLANs, and VXLANs.
ND attack detection defines the following types of interfaces on a VLAN network or the following
types of ACs on a VXLAN network:
• ND trusted interface or ND trusted AC—Performs no user validity check on the received ND
messages.
• ND untrusted interface or ND untrusted AC—Discards incoming RA and redirect messages,
and performs the user validity check on other types of incoming ND messages.
An ND attack detection-enabled interface is an ND untrusted interface.
ND attack detection compares the source IPv6 address and the source MAC address in an incoming
ND message against security entries from other modules.
• If a match is found, the device verifies the user as legal, and it forwards the packet.
• If no match is found, the device verifies the user as illegal, and it discards the ND message.

596
 ND attack detection uses static IPv6 source guard binding entries, ND snooping entries, and
DHCPv6 snooping entries for user validity check.
• Static IPv6 source guard binding entries are created by using the ipv6 source binding
command. For information about IPv6 source guard, see "Configuring IP source guard."
• ND snooping entries are automatically generated by the ND snooping feature. For information
about ND snooping, see IPv6 neighbor discovery configuration in Layer 3–IP Services
Configuration Guide.
• DHCPv6 snooping entries are automatically generated by the DHCPv6 snooping feature. For
information about DHCPv6 snooping, see Layer 3–IP Services Configuration Guide.

Restrictions and guidelines for ND attack detection

configuration
When you configure ND attack detection, follow these restrictions and guidelines:
• To prevent ND untrusted interfaces from dropping all received ND messages, make sure one or
more of the these features are configured: IPv6 source guard static bindings, DHCPv6
snooping, and ND snooping.
• To make the IPv6 source guard static bindings effective for ND attack detection, you must
perform the following operations:
 Specify the vlan vlan-id option in the ipv6 source binding command.
 Enable ND attack detection for the same VLAN.
• ND attack detection is enabled on an interface when you enable this feature on the interface or
in the VLAN where the interface resides. To disable ND attack detection on an interface, disable
this feature both on the interface and in the VLAN to which the interface belongs.

Enabling ND attack detection on an interface

1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable ND attack detection.
ipv6 nd detection enable
By default, ND attack detection is disabled.

Configuring ND attack detection for a VLAN

1. Enter system view.
system-view
2. Enter VLAN view.
vlan vlan-id
3. Enable ND attack detection.
ipv6 nd detection enable
By default, ND attack detection is disabled.
4. (Optional.) Configure the interface as ND trusted interface:
a. Return to system view.
quit

597
 b. Enter Layer 2 Ethernet or aggregate interface view.
interface interface-type interface-number
c. Configure the interface as ND trusted interface.
ipv6 nd detection trust
By default, all interfaces are ND untrusted interfaces.

Configuring ND attack detection for a VSI

Restrictions and guidelines
Do not configure ND snooping in a VSI where ND attack detection is configured. If they are both
configured in one VSI, ND snooping cannot learn snooping entries.
Procedure
1. Enter system view.
system-view
2. Enter VSI view.
vsi vsi-name
3. Enable ND attack detection.
ipv6 nd detection enable
By default, ND attack detection is disabled.
4. (Optional.) Configure the ND trusted AC.
a. Return to system view.
quit
b. Enter interface view.
interface interface-type interface-number
c. Enter Ethernet service instance view.
service-instance instance-id
d. (Optional.) Configure the AC as ND trusted AC.
ipv6 nd detection trust
By default, all ACs are ND untrusted ACs.

Ignoring ingress ports of ND packets

About this task
With ND attack detection enabled, the device can perform security check on received packets based
on the local and remote IPSG bindings. Remote IPSG bindings do not contain port information. The
device drops ND packets that match remote IPSG bindings because it does not find matching
ingress ports for these packets. To prevent the device from dropping these packets, you can
configure the device to ignore ingress ports of ND packets. This feature does not examine the
ingress ports of ND packets, so that ND packets that match remote IPSG bindings will not be
dropped.
Procedure
1. Enter system view.
system-view
2. Ignore ingress ports of ND packets in ND attack detection.
ipv6 nd detection port-match-ignore

598
 By default, ingress ports of ND packets are examined in ND attack detection.

Enabling ND attack detection logging

About this task
This feature allows a device to generate logs when it detects invalid ND packets. The log information
helps administrators locate and solve problems. Each log records the following information:
• Victim port numbers in a VLAN.
• IDs of the victim Ethernet service instances in a VXLAN.
• Source IP address of the invalid ND packets.
• Source MAC address of the invalid ND packets.
• VLAN ID of the invalid ND packets.
• Total number of dropped ND packets.
Procedure
1. Enter system view.
system-view
2. Enable ND attack detection logging.
ipv6 nd detection log enable
By default, ND attack detection logging is disabled.

Display and maintenance commands for ND attack detection

Execute display commands in any view and reset commands in user view.

Task Command
display ipv6 nd detection statistics
Display statistics for ND messages [ interface interface-type
dropped by ND attack detection. interface-number [ service-instance
instance-id ] ]
reset ipv6 nd detection statistics
[ interface interface-type
Clear ND attack detection statistics.
interface-number [ service-instance
instance-id ] ]

Example: Configuring ND attack detection

Network configuration
As shown in Figure 156, configure ND attack detection on Device B to check user validity for ND
messages from Host A and Host B.

599
 Figure 156 Network diagram

Internet

Device A Gateway

GE1/0/3
Vlan-int10
10::1/64

VLAN 10
ND snooping
GE1/0/3
Device B

GE1/01 GE1/0/2

Host A Host B
10::5/64 10::6/64
0001-0203-0405 0001-0203-0607

Procedure
1. Configure Device A:
# Create VLAN 10.
<DeviceA> system-view
[DeviceA] vlan 10
[DeviceA-vlan10] quit
# Configure GigabitEthernet 1/0/3 to trunk VLAN 10.
[DeviceA] interface gigabitethernet 1/0/3
[DeviceA-GigabitEthernet1/0/3] port link-type trunk
[DeviceA-GigabitEthernet1/0/3] port trunk permit vlan 10
[DeviceA-GigabitEthernet1/0/3] quit
# Assign IPv6 address 10::1/64 to VLAN-interface 10.
[DeviceA] interface vlan-interface 10
[DeviceA-Vlan-interface10] ipv6 address 10::1/64
[DeviceA-Vlan-interface10] quit
2. Configure Device B:
# Create VLAN 10.
<DeviceB> system-view
[DeviceB] vlan 10
[DeviceB-vlan10] quit
# Configure GigabitEthernet 1/0/1, GigabitEthernet 1/0/2, and GigabitEthernet 1/0/3 to trunk
VLAN 10.
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] port link-type access
[DeviceB-GigabitEthernet1/0/1] port access vlan 10
[DeviceB-GigabitEthernet1/0/1] quit

600
 [DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] port link-type access
[DeviceB-GigabitEthernet1/0/2] port access vlan 10
[DeviceB-GigabitEthernet1/0/2] quit
[DeviceB] interface gigabitethernet 1/0/3
[DeviceB-GigabitEthernet1/0/3] port link-type trunk
[DeviceB-GigabitEthernet1/0/3] port trunk permit vlan 10
[DeviceB-GigabitEthernet1/0/3] quit
# Enable ND attack detection for VLAN 10.
[DeviceB] vlan 10
[DeviceB-vlan10] ipv6 nd detection enable
# Enable ND snooping for IPv6 global unicast addresses and ND snooping for IPv6 link-local
addresses in VLAN 10.
[DeviceB-vlan10] ipv6 nd snooping enable global
[DeviceB-vlan10] ipv6 nd snooping enable link-local
[DeviceB-vlan10] quit
# Configure GigabitEthernet 1/0/3 as ND trusted interface.
[DeviceB] interface gigabitethernet 1/0/3
[DeviceB-GigabitEthernet1/0/3] ipv6 nd detection trust

Verifying the configuration

Verify that Device B inspects all ND messages received by GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2 based on the ND snooping entries. (Details not shown.)

Configuring RA guard
About RA guard
RA guard allows Layer 2 access devices to analyze and block unwanted and forged RA messages.
Upon receiving an RA message, the device makes the forwarding or dropping decision based on the
role of the attached device or the RA guard policy.
1. If the role of the device attached to the receiving interface is router, the device forwards the RA
message. If the role is host, the device drops the RA message.
2. If no attached device role is set, the device uses the RA guard policy applied to the VLAN of the
receiving interface to match the RA message.
 If the policy does not contain match criteria, the policy will not take effect and the device
forwards the RA message.
 If the RA message content matches every criterion in the policy, the device forwards the
message. Otherwise, the device drops the message.

Specifying the role of the attached device

Restrictions and guidelines
Make sure your setting is consistent with the type of the attached device. If you are not aware of the
device type, do not specify a role for the device.
Procedure
1. Enter system view.
system-view

601
 2. Enter interface view.
 Enter Layer 2 Ethernet interface view.
interface interface-type interface-number
 Enter aggregate interface view.
interface bridge-aggregation interface-number
3. Specify the role of the device attached to the interface.
ipv6 nd raguard role { host | router }
By default, the role of the device attached to the interface is not specified.

Configuring and applying an RA guard policy

About this task
Configure an RA guard policy if you do not specify a role for the attached device or if you want to filter
the RA messages sent by a router.
Procedure
1. Enter system view.
system-view
2. Create an RA guard policy and enter its view.
ipv6 nd raguard policy policy-name
3. Configure the RA guard policy.
Choose the following tasks as needed:
 Specify an ACL match criterion.
if-match acl { ipv6-acl-number | name ipv6-acl-name }
 Specify a prefix match criterion.
if-match prefix acl { ipv6-acl-number | name ipv6-acl-name }
 Specify a source MAC address match criterion.
if-match mac-address acl { acl-number | name acl-name }
 Specify a router preference match criterion.
if-match router-preference maximum { high | low | medium }
 Specify an M flag match criterion.
if-match autoconfig managed-address-flag { off | on }
 Specify an O flag match criterion.
if-match autoconfig other-flag { off | on }
 Specify a maximum or minimum hop limit match criterion.
if-match hop-limit { maximum | minimum } limit
By default, the RA guard policy is not configured.
4. Quit RA guard policy view.
quit
5. Enter VLAN view.
vlan vlan-number
6. Apply an RA guard policy to the VLAN.
ipv6 nd raguard apply policy [ policy-name ]
By default, no RA guard policy is applied to the VLAN.

602
Enabling the RA guard logging feature
About this task
This feature allows a device to generate logs when it detects forged RA messages. The log
information helps administrators locate and solve problems. Each log records the following
information:
• Name of the interface that received the forged RA message.
• Source IP address of the forged RA message.
• Number of RA messages dropped on the interface.
The RA guard logging feature sends the log messages to the information center. The information
center can then output log messages from different source modules to different destinations. For
more information about the information center, see Network Management and Monitoring
Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enable the RA guard logging feature.
ipv6 nd raguard log enable
By default, the RA guard logging feature is disabled.

Display and maintenance commands for RA guard

Execute display commands in any view.

Task Command
display ipv6 nd raguard policy
Display the RA guard policy configuration.
[ policy-name ]
display ipv6 nd raguard statistics
Display RA guard statistics. [ interface interface-type
interface-number ]
reset ipv6 nd raguard statistics
Clear RA guard statistics. [ interface interface-type
interface-number ]

Example: Configuring RA guard

Network configuration
As shown in Figure 157, GigabitEthernet 1/0/1, GigabitEthernet 1/0/2, and GigabitEthernet 1/0/3 of
Device B are in VLAN 10.
Configure RA guard on Device B to filter forged and unwanted RA messages.
• Configure an RA policy in VLAN 10 for GigabitEthernet 1/0/2 to filter all RA messages received
from the unknown device.
• Specify host as the role of the host. All RA messages received on GigabitEthernet 1/0/1 are
dropped.

603
 • Specify router as the role of the Device A. All RA messages received on GigabitEthernet 1/0/3
are forwarded.
Figure 157 Network diagram
Device A

VLAN 10
GE1/0/3
Device B
GE1/0/1 GE1/0/2

Host Device C

Procedure
# Create an RA guard policy named policy1.
<DeviceB> system-view
[DeviceB] ipv6 nd raguard policy policy1

# Set the maximum router preference to high for the RA guard policy.
[DeviceB-raguard-policy-policy1] if-match router-preference maximum high

# Specify on as the M flag match criterion for the RA guard policy.

[DeviceB-raguard-policy-policy1] if-match autoconfig managed-address-flag on

# Specify on as the O flag match criterion for the RA guard policy.

[DeviceB-raguard-policy-policy1] if-match autoconfig other-flag on

# Set the maximum advertised hop limit to 120 for the RA guard policy.
[DeviceB-raguard-policy-policy1] if-match hop-limit maximum 120

# Set the minimum advertised hop limit to 100 for the RA guard policy.
[DeviceB-raguard-policy-policy1] if-match hop-limit minimum 100
[DeviceB-raguard-policy-policy1] quit

# Assign GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 to VLAN 10.

[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] port link-type access
[DeviceB-GigabitEthernet1/0/1] port access vlan 10
[DeviceB-GigabitEthernet1/0/1] quit
[DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] port link-type access
[DeviceB-GigabitEthernet1/0/2] port access vlan 10
[DeviceB-GigabitEthernet1/0/2] quit

# Configure GigabitEthernet 1/0/3 to trunk VLAN 10.

[DeviceB] interface gigabitethernet 1/0/3
[DeviceB-GigabitEthernet1/0/3] port link-type trunk
[DeviceB-GigabitEthernet1/0/3] port trunk permit vlan 10
[DeviceB-GigabitEthernet1/0/3] quit

# Apply the RA guard policy policy1 to VLAN 10.

[DeviceB] vlan 10

604
 [DeviceB-vlan10] ipv6 nd raguard apply policy policy1
[DeviceB-vlan10] quit

# Specify host as the role of the device attached to GigabitEthernet 1/0/1.

[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] ipv6 nd raguard role host
[DeviceB-GigabitEthernet1/0/1] quit

# Specify router as the role of the device attached to GigabitEthernet 1/0/3.

[DeviceB] interface gigabitethernet 1/0/3
[DeviceB-GigabitEthernet1/0/3] ipv6 nd raguard role router
[DeviceB-GigabitEthernet1/0/3] quit

Verifying the configuration

# Verify that the device forwards or drops RA messages received on GigabitEthernet 1/0/2 based on
the RA guard policy. (Details not shown.)
# Verify that the device drops RA messages received on GigabitEthernet 1/0/1. (Details not shown.)
# Verify that the device forwards RA messages received on GigabitEthernet 1/0/3 to other interfaces
in VLAN 10. (Details not shown.)

605
Configuring uRPF
About uRPF
Unicast Reverse Path Forwarding (uRPF) protects a network against source address spoofing
attacks, such as DoS and DDoS attacks.

uRPF application scenario

Attackers send packets with a forged source address to access a system that uses IPv4-based
authentication, in the name of authorized users or even the administrator. Even if the attackers or
other hosts cannot receive any response packets, the attacks are still disruptive to the attacked
target.
Figure 158 Source address spoofing attack

1.1.1.8 2.2.2.1
Source IP address: 2.2.2.1

Router A Router B Router C

As shown in Figure 158, an attacker on Router A sends the server (Router B) requests with a forged
source IP address 2.2.2.1 at a high rate. Router B sends response packets to IP address 2.2.2.1
(Router C). Consequently, both Router B and Router C are attacked. If the administrator disconnects
Router C by mistake, the network service is interrupted.
Attackers can also send packets with different forged source addresses or attack multiple servers
simultaneously to block connections or even break down the network.
uRPF can prevent these source address spoofing attacks. It checks whether an interface that
receives a packet is the output interface of the FIB entry that matches the source address of the
packet. If not, uRPF considers it a spoofing attack and discards the packet.

uRPF check modes

uRPF supports strict and loose modes.
Strict uRPF check
To pass strict uRPF check, the source address of a packet and the receiving interface must match
the destination address and output interface of a FIB entry. In some scenarios (for example,
asymmetrical routing), strict uRPF might discard valid packets.
Strict uRPF is often deployed between a PE and a CE.
Loose uRPF check
To pass loose uRPF check, the source address of a packet must match the destination address of a
FIB entry. Loose uRPF can avoid discarding valid packets, but might let go attack packets.
Loose uRPF is often deployed between ISPs, especially in asymmetrical routing.

Network application
As shown in Figure 159, strict uRPF check is configured between an ISP network and a customer
network. Loose uRPF check is configured between ISPs.

606
 Figure 159 Network diagram

ISP B

uRPF (loose)

ISP A
ISP C

uRPF (strict)

User

Enabling uRPF globally

Restrictions and guidelines
Global uRPF takes effect on all interfaces of the device.
Procedure
1. Enter system view.
system-view
2. Enable uRPF globally.
ip urpf { loose | strict }
By default, uRPF is disabled.

Display and maintenance commands for uRPF

Execute display commands in any view.

Task Command

Display uRPF configuration. display ip urpf [ slot slot-number ]

607
Configuring SAVI
About SAVI
Source Address Validation Improvement (SAVI) checks the validity of the source addresses of global
unicast IPv6 packets. It implements the validity check by using the ND snooping, DHCPv6 snooping,
ND attack detection, and IP source guard features. SAVI checks only global unicast addresses and
forwards the packets that pass the validity check. Packets sourced from an invalid address are
dropped.

SAVI application scenarios

DHCPv6-only
The hosts connected to the SAVI-enabled device obtain addresses only through DHCPv6. DHCPv6
messages, ND messages (RA and RR messages excluded), and IPv6 data packets are checked
based on DHCPv6 snooping entries and static IPv6 source guard binding entries.
SLAAC-only
The hosts connected to the SAVI-enabled device obtain addresses only through Stateless Address
Autoconfiguration (SLAAC). In this scenario, SAVI drops all DHCPv6 messages. Only ND messages
and IPv6 data packets are checked based on DHCPv6 snooping entries and static IPv6 source
guard binding entries.
DHCPv6+SLAAC
The hosts connected to the SAVI-enabled device obtain addresses through DHCPv6 and SLAAC. In
this scenario, SAVI checks all DHCPv6 messages, ND messages, and IPv6 data packets based on
DHCPv6 snooping entries, ND snooping entries, and static IPv6 source guard binding entries.

SAVI tasks at a glance

To configure SAVI, perform the following tasks:
1. Enabling SAVI
2. Configuring IPv6 source guard
3. Configuring DHCPv6 snooping
4. Configuring ND parameters
5. (Optional.) Setting the entry deletion delay
6. (Optional.) Enabling packet spoofing logging and filtering entry logging

Enabling SAVI
1. Enter system view.
system-view
2. Enable SAVI.
ipv6 savi strict
By default, SAVI is disabled.

608
Configuring IPv6 source guard
1. Enable IPv6 source guard on an interface.
2. (Optional.) Configure static IPv6SG bindings.
For more information about IPv6 source guard configuration, see "Configuring IP source guard."

Configuring DHCPv6 snooping

Restrictions and guidelines
Enable only DHCPv6 snooping for the SLAAC-only scenario.
Procedure
1. Enable DHCPv6 snooping.
2. Specify DHCPv6 snooping trusted ports.
3. Enable recording client information in DHCPv6 snooping entries.
For more information about DHCPv6 snooping configuration, see Layer 3—IP Services
Configuration Guide.

Configuring ND parameters
Restrictions and guidelines
Enable only ND attack detection for the DHCPv6-only scenario.
Procedure
1. Enable ND snooping for global unicast addresses.
For more information about ND snooping, see IPv6 basics in Layer 3—IP Services
Configuration Guide.
2. Enable ND attack detection.
For more information about ND attack detection, see "Configuring ND attack defense."
3. Specify ND trusted ports.
For more information about ND trusted ports, see "Configuring ND attack defense."

Setting the entry deletion delay

About this task
The entry deletion delay is the period of time that the device waits before deleting the DHCPv6
snooping entries and ND snooping entries for a down port.
Procedure
1. Enter system view.
system-view
2. Set the entry deletion delay.
ipv6 savi down-delay delay-time
By default, the entry deletion delay is 30 seconds.

609
Enabling packet spoofing logging and filtering
entry logging
About this task
Packet spoofing logging enables the device to generate log messages for the spoofed packets
detected by SAVI.
Filtering entries are effective bindings used for filtering IPv6 packets by the source IPv6 address.
Filtering entry logging enables the device to generate log messages for filtering entries. A log
message contains the IPv6 address, MAC address, VLAN, and interface of a filtering entry.
The device sends packet spoofing and filtering entry log messages to the information center. With
the information center, you can set log message filtering and output rules, including output
destinations. For more information about using the information center, see Network Management
and Monitoring Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enable packet spoofing logging.
ipv6 savi log enable spoofing-packet [ interval interval |
total-number number ] *
By default, packet spoofing logging is disabled.
3. Enable filtering entry logging.
ipv6 savi log enable filter-entry
By default, filtering entry logging is disabled.

SAVI configuration examples

Example: Configuring DHCPv6-only SAVI
Network configuration
As shown in Figure 160, configure SAVI on the switch to meet the following requirements:
• Clients obtain IPv6 addresses only through DHCPv6.
• SAVI checks the source addresses of DHCPv6 messages, ND messages (RA and RR
messages excluded), and IPv6 data packets on GigabitEthernet 1/0/2 and GigabitEthernet
1/0/3.

610
 Figure 160 Network diagram
DHCPv6 server

VLAN 2
GE1/0/1
DHCPv6 snooping

GE1/0/2 GE1/0/3
Switch

DHCPv6 client DHCPv6 client

Procedure
# Enable SAVI.
<Switch> system-view
[Switch] ipv6 savi strict

# Assign GigabitEthernet 1/0/1 through GigabitEthernet 1/0/3 to VLAN 2.

[Switch] vlan 2
[Switch-vlan2] port gigabitethernet 1/0/1 gigabitethernet 1/0/2 gigabitethernet 1/0/3
[Switch-vlan2] quit

# Enable DHCPv6 snooping.

[Switch] ipv6 dhcp snooping enable

# Configure GigabitEthernet 1/0/1 as a DHCPv6 snooping trusted port.

[Switch] interface gigabitethernet 1/0/1
[Switch-GigabitEthernet1/0/1] ipv6 dhcp snooping trust
[Switch-GigabitEthernet1/0/1] quit

# Enable recording DHCPv6 snooping entries on GigabitEthernet 1/0/2 and GigabitEthernet 1/0/3.
[Switch] interface gigabitethernet 1/0/2
[Switch-GigabitEthernet1/0/2] ipv6 dhcp snooping binding record
[Switch-GigabitEthernet1/0/2] quit
[Switch] interface gigabitethernet 1/0/3
[Switch-GigabitEthernet1/0/3] ipv6 dhcp snooping binding record
[Switch-GigabitEthernet1/0/3] quit

# Enable ND attack detection.

[Switch] vlan 2
[Switch-vlan2] ipv6 nd detection enable
[Switch-vlan2] quit

# Enable IPv6 source guard on GigabitEthernet 1/0/2 and GigabitEthernet 1/0/3.

[Switch] interface gigabitethernet 1/0/2
[Switch-GigabitEthernet1/0/2] ipv6 verify source ip-address mac-address
[Switch-GigabitEthernet1/0/2] quit
[Switch] interface gigabitethernet 1/0/3
[Switch-GigabitEthernet1/0/3] ipv6 verify source ip-address mac-address
[Switch-GigabitEthernet1/0/3] quit

611
Example: Configuring SLAAC-only SAVI
Network configuration
As shown in Figure 161, configure SAVI on Switch B to meet the following requirements:
• Hosts obtain IPv6 addresses only through SLAAC.
• DHCPv6 messages are dropped on GigabitEthernet 1/0/1 through GigabitEthernet 1/0/3 in
VLAN 2.
• SAVI checks the source addresses of ND messages and IPv6 data packets on GigabitEthernet
1/0/1 and GigabitEthernet 1/0/2.
Figure 161 Network diagram

Internet

Gateway
Switch A
GE1/0/3
Vlan-int2
10::1

VLAN 2
ND snooping GE1/0/3
Switch B

GE1/0/1 GE1/0/2

Host A Host B

Procedure
# Enable SAVI.
<SwitchB> system-view
[SwitchB] ipv6 savi strict

# Assign GigabitEthernet 1/0/1 through GigabitEthernet 1/0/3 to VLAN 2.

[SwitchB] vlan 2
[SwitchB-vlan2] port gigabitethernet 1/0/1 gigabitethernet 1/0/2 gigabitethernet 1/0/3
[SwitchB-vlan2] quit

# Enable ND snooping for global unicast addresses in VLAN 2.

[SwitchB] vlan 2
[SwitchB-vlan2] ipv6 nd snooping enable global

# Enable ND attack detection for VLAN 2.

[SwitchB-vlan2] ipv6 nd detection enable
[SwitchB-vlan2] quit

# Enable DHCPv6 snooping.

[SwitchB] ipv6 dhcp snooping enable

# Configure GigabitEthernet 1/0/3 as an ND trusted port.

612
 [SwitchB] interface gigabitethernet 1/0/3
[SwitchB-GigabitEthernet1/0/3] ipv6 nd detection trust
[SwitchB-GigabitEthernet1/0/3] quit

# Enable IPv6 source guard on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2.

[SwitchB] interface gigabitethernet 1/0/1
[SwitchB-GigabitEthernet1/0/1] ipv6 verify source ip-address mac-address
[SwitchB-GigabitEthernet1/0/1] quit
[SwitchB] interface gigabitethernet 1/0/2
[SwitchB-GigabitEthernet1/0/2] ipv6 verify source ip-address mac-address
[SwitchB-GigabitEthernet1/0/2] quit

Example: Configuring DHCPv6+SLAAC SAVI

Network configuration
As shown in Figure 162, configure SAVI on Switch B to meet the following requirements:
• Hosts obtain IP addresses through DHCPv6 or SLAAC.
• SAVI checks the source addresses of DHCPv6 messages, ND messages, and IPv6 data
packets on GigabitEthernet 1/0/3 through GigabitEthernet 1/0/5.
Figure 162 Network diagram
Switch A DHCPv6 server

Gateway

VLAN 2
GE1/0/2 GE1/0/1
ND snooping
DHCPv6 snooping Switch B
GE1/0/3
GE1/0/4 GE1/0/5

DHCPv6 Host A Host B

client

Procedure
# Enable SAVI.
<SwitchB> system-view
[SwitchB] ipv6 savi strict

# Assign GigabitEthernet 1/0/1 through GigabitEthernet 1/0/5 to VLAN 2.

[SwitchB] vlan 2
[SwitchB-vlan2] port gigabitethernet 1/0/1 gigabitethernet 1/0/2 gigabitethernet 1/0/3
gigabitethernet 1/0/4 gigabitethernet 1/0/5

# Enable DHCPv6 snooping.

[SwitchB] ipv6 dhcp snooping enable

# Enable recording DHCPv6 snooping entries on GigabitEthernet 1/0/3 through GigabitEthernet

1/0/5.

613
[SwitchB] interface gigabitethernet 1/0/3
[SwitchB-GigabitEthernet1/0/3] ipv6 dhcp snooping binding record
[SwitchB-GigabitEthernet1/0/3] quit
[SwitchB] interface gigabitethernet 1/0/4
[SwitchB-GigabitEthernet1/0/4] ipv6 dhcp snooping binding record
[SwitchB-GigabitEthernet1/0/4] quit
[SwitchB] interface gigabitethernet 1/0/5
[SwitchB-GigabitEthernet1/0/5] ipv6 dhcp snooping binding record
[SwitchB-GigabitEthernet1/0/5] quit

# Configure GigabitEthernet 1/0/1 as a DHCPv6 snooping trusted port.

[SwitchB] interface gigabitethernet 1/0/1
[SwitchB-GigabitEthernet1/0/1] ipv6 dhcp snooping trust
[SwitchB-GigabitEthernet1/0/1] quit

# Enable ND snooping for global unicast addresses in VLAN 2.

[SwitchB] vlan 2
[SwitchB-vlan2] ipv6 nd snooping enable global

# Enable ND attack detection for VLAN 2.

[SwitchB-vlan2] ipv6 nd detection enable
[SwitchB-vlan2] quit

# Configure GigabitEthernet 1/0/2 as an ND trusted port.

[SwitchB] interface gigabitethernet 1/0/2
[SwitchB-GigabitEthernet1/0/2] ipv6 nd detection trust
[SwitchB-GigabitEthernet1/0/2] quit

# Enable IPv6 source guard on GigabitEthernet 1/0/3 through GigabitEthernet 1/0/5.

[SwitchB] interface gigabitethernet 1/0/3
[SwitchB-GigabitEthernet1/0/3] ipv6 verify source ip-address mac-address
[SwitchB-GigabitEthernet1/0/3] quit
[SwitchB] interface gigabitethernet 1/0/4
[SwitchB-GigabitEthernet1/0/4] ipv6 verify source ip-address mac-address
[SwitchB-GigabitEthernet1/0/4] quit
[SwitchB] interface gigabitethernet 1/0/5
[SwitchB-GigabitEthernet1/0/5] ipv6 verify source ip-address mac-address

614
Configuring MFF
About MFF
MAC-forced forwarding (MFF) implements Layer 2 isolation and Layer 3 communication between
hosts in the same broadcast domain.
An MFF-enabled device intercepts ARP requests and returns the MAC address of a gateway (or
server) to the senders. In this way, the senders are forced to send packets to the gateway for traffic
monitoring and attack prevention.

MFF network model

As shown in Figure 163, hosts are connected to Switch C through Switch A and Switch B, which are
called Ethernet access nodes (EANs). The MFF-enabled EANs forward packets from hosts to the
gateway for further forwarding. The hosts are isolated at Layer 2, but they can communicate at Layer
3.
Figure 163 Network diagram for MFF
Switch A Switch C
(EAN) (Aggregation node)
User-port Network-port
IP network
User-port Gateway
Host A

Host B

User-port Network-port
Server

Switch B
Host C
(EAN)

MFF works with any of the following features to implement traffic filtering and Layer 2 isolation on the
EANs:
• ARP snooping (see Layer 3—IP Services Configuration Guide).
• IP source guard (see "Configuring IP source guard").
• ARP detection (see "Configuring ARP attack protection").
• VLAN mapping (see Layer 2—LAN Switching Configuration Guide).

Port roles
Two types of ports, user port and network port, exist in an MFF-enabled VLAN.
User port
An MFF user port is directly connected to a host and processes the following packets differently:
• Allows multicast packets to pass.
• Delivers ARP packets to the CPU.

615
 • Processes unicast packets as follows:
 If gateways' MAC addresses have been learned, the user port allows only the unicast
packets with the gateways' MAC addresses as the destination MAC addresses to pass.
 If no gateways' MAC addresses have been learned, the user port discards all received
unicast packets.
Network port
An MFF network port is connected to any of the following networking devices:
• An access switch.
• A distribution switch.
• A gateway.
• A server.
A network port processes the following packets differently:
• Allows multicast packets to pass.
• Delivers ARP packets to the CPU.
• Denies broadcast packets other than DHCP and ARP packets.

Processing of ARP packets in MFF

An MFF-enabled device implements Layer 3 communication between hosts by intercepting ARP
requests from the hosts and replies with the MAC address of a gateway. This mechanism helps
reduce the number of broadcast messages.
The MFF device processes ARP packets as follows:
• After receiving an ARP request from a host, the MFF device sends the MAC address of the
corresponding gateway to the host. In this way, hosts in the network have to communicate at
Layer 3 through a gateway.
• After receiving an ARP request from a gateway, the MFF device sends the requested host's
MAC address to the gateway if the corresponding entry is available. If the entry is not available,
the MFF device forwards the ARP request.
• The MFF device forwards ARP replies between hosts and gateways.
• If the source MAC addresses of ARP requests from gateways are different from those recorded,
the MFF device updates and broadcasts the IP and MAC addresses of the gateways.

MFF default gateway

MFF applies to only networks where the hosts' IP addresses are manually configured. Because the
hosts cannot obtain the gateway information through DHCP, the default gateway must be specified
by the mac-forced-forwarding default-gateway command. MFF maintains only one
default gateway for each VLAN. MFF updates the MAC address of the default gateway upon
receiving an ARP packet with a different sender MAC address from the default gateway.

Protocols and standards

RFC 4562, MAC-Forced Forwarding

MFF tasks at a glance

To configure MFF, perform the following tasks:

616
 1. Enabling MFF
2. Configuring a network port
3. (Optional.) Enabling periodic gateway probe
4. Specifying the IP addresses of servers
If servers exist in the network, you must perform this task to ensure communication between the
servers and hosts.

Enabling MFF
Restrictions and guidelines
• An MFF-enabled device and a host cannot ping each other.
• When MFF works with static IP source guard bindings, you must configure VLAN IDs in the
static bindings. Otherwise, IP packets allowed by IP source guard are permitted even if their
destination MAC addresses are not the MAC address of the gateway.
• MFF is not supported in a network where VRRP load balancing mode is configured.
Prerequisites
For MFF to take effect, make sure ARP snooping is enabled on the VLAN where MFF is enabled.
Procedure
1. Enter system view.
system-view
2. Enter VLAN view.
vlan vlan-id
3. Enable MFF.
mac-forced-forwarding default-gateway gateway-ip
By default, MFF is disabled.

Configuring a network port

Restrictions and guidelines
In a VLAN with MFF enabled, you need to configure the following ports as network ports:
• Upstream ports connected to the gateway.
• Ports connected to other MFF devices.
Link aggregation is supported by network ports in an MFF-enabled VLAN, but it is not supported by
user ports in the VLAN. You can add the network ports to link aggregation groups, but cannot add the
user ports to link aggregation groups. For more information about link aggregation, see Layer
2—LAN Switching Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Configure the port as a network port.
mac-forced-forwarding network-port
By default, the port is a user port.

617
Enabling periodic gateway probe
About this task
You can configure the MFF device to detect gateways every 30 seconds for the change of MAC
addresses by sending forged ARP packets. The ARP packets use 0.0.0.0 as the sender IP address
and bridge MAC address as the sender MAC address.
Procedure
1. Enter system view.
system-view
2. Enter VLAN view.
vlan vlan-id
3. Enable periodic gateway probe.
mac-forced-forwarding gateway probe
By default, this feature is disabled.

Specifying the IP addresses of servers

About this task
Server IP addresses can be those of the interfaces on a router in a VRRP group and those of the
servers collaborating with MFF, such as a RADIUS server.
When the MFF device receives an ARP request from a server, the device searches IP-to-MAC
address entries it has stored. Then the device replies with the requested MAC address to the server.
As a result, packets from a host to a server are forwarded by the gateway. However, packets from a
server to a host are not forwarded by the gateway.
MFF does not check whether the IP address of a server is on the same network segment as that of a
gateway. Instead, it checks whether the IP address of a server is all-zero or all-one. An all-zero or
all-one server IP address is invalid.
Restrictions and guidelines
If the server's interface connecting to the MFF device uses secondary IP addresses to send ARP
packets, include all these IP addresses in the server IP address list.
Procedure
1. Enter system view.
system-view
2. Enter VLAN view.
vlan vlan-id
3. Specify the IP addresses of servers.
mac-forced-forwarding server server-ip&<1-10>
By default, no server IP address is specified.

Display and maintenance commands for MFF

Execute display commands in any view.

618
 Task Command
display mac-forced-forwarding
Display MFF port configuration.
interface
display mac-forced-forwarding vlan
Display the MFF configuration for a VLAN.
vlan-id

MFF configuration examples

Example: Configuring MFF in a tree network
Network configuration
As shown in Figure 164, all the devices are in VLAN 100. Hosts A, B, and C are assigned IP
addresses manually.
Configure MFF to isolate the hosts at Layer 2 and allow them to communicate with each other
through the gateway at Layer 3.
Figure 164 Network diagram
Switch A Switch C Gateway
GE1/0/2 GE1/0/1 GE1/0/2 GE1/0/1

10.1.1.100/24
Host A GE1/0/3 GE1/0/3
10.1.1.1/24

Host B
10.1.1.2/24

GE1/0/1 GE1/0/2

Host C Switch B Server

10.1.1.3/24 10.1.1.200/24

Procedure
1. Configure the IP addresses of the hosts and the gateway, as shown in Figure 164.
2. Configure Switch A:
# Configure MFF on VLAN 100.
[SwitchA] vlan 100
[SwitchA-vlan100] mac-forced-forwarding default-gateway 10.1.1.100
# Specify the IP address of the server.
[SwitchA-vlan100] mac-forced-forwarding server 10.1.1.200
# Enable ARP snooping on VLAN 100.
[SwitchA-vlan100] arp snooping enable
[SwitchA-vlan100] quit
# Configure GigabitEthernet 1/0/1 as a network port.
[SwitchA] interface gigabitethernet 1/0/1
[SwitchA-GigabitEthernet1/0/1] mac-forced-forwarding network-port
3. Configure Switch B:

619
 # Configure MFF on VLAN 100.
[SwitchB] vlan 100
[SwitchB-vlan100] mac-forced-forwarding default-gateway 10.1.1.100
# Specify the IP address of the server.
[SwitchB-vlan100] mac-forced-forwarding server 10.1.1.200
# Enable ARP snooping on VLAN 100.
[SwitchB-vlan100] arp snooping enable
[SwitchB-vlan100] quit
# Configure GigabitEthernet 1/0/2 as a network port.
[SwitchB] interface gigabitethernet 1/0/2 1/0/6
[SwitchB-GigabitEthernet1/0/2] mac-forced-forwarding network-port

Example: Configuring MFF in a ring network

Network configuration
As shown in Figure 165, all the devices are in VLAN 100, and the switches form a ring. Hosts A, B,
and C are assigned IP addresses manually.
Configure MFF to isolate the hosts at Layer 2 and allow them to communicate with each other
through the gateway at Layer 3.
Figure 165 Network diagram
Switch A Switch C Gateway
GE1/0/1 GE1/0/2 GE1/0/1 GE1/0/2

10.1.1.100/24
Host A GE1/0/3 GE1/0/3
10.1.1.1/24

GE1/0/1
GE1/0/3

GE1/0/2
Switch B
Host B GE1/0/4
10.1.1.2/24

Server
Host C 10.1.1.200/24
10.1.1.3/24

Procedure
1. Configure the IP addresses of the hosts and the gateway, as in shown in Figure 165.
2. Configure Switch A:
# Enable STP globally to make sure STP is enabled on interfaces.
[SwitchA] stp global enable
# Configure MFF on VLAN 100.
[SwitchA] vlan 100
[SwitchA-vlan100] mac-forced-forwarding default-gateway 10.1.1.100
# Specify the IP address of the server.
[SwitchA-vlan100] mac-forced-forwarding server 10.1.1.200
# Enable ARP snooping on VLAN 100.
[SwitchA-vlan100] arp snooping enable

620
 [SwitchA-vlan100] quit
# Configure GigabitEthernet 1/0/2 and GigabitEthernet 1/0/3 as network ports.
[SwitchA] interface gigabitethernet 1/0/2
[SwitchA-GigabitEthernet1/0/2] mac-forced-forwarding network-port
[SwitchA-GigabitEthernet1/0/2] quit
[SwitchA] interface gigabitethernet 1/0/3
[SwitchA-GigabitEthernet1/0/3] mac-forced-forwarding network-port
3. Configure Switch B:
# Enable STP globally to make sure STP is enabled on interfaces.
[SwitchB] stp global enable
# Configure MFF on VLAN 100.
[SwitchB] vlan 100
[SwitchB-vlan100] mac-forced-forwarding default-gateway 10.1.1.100
# Specify the IP address of the server.
[SwitchB-vlan100] mac-forced-forwarding server 10.1.1.200
# Enable ARP snooping on VLAN 100.
[SwitchB-vlan100] arp snooping enable
[SwitchB-vlan100] quit
# Configure GigabitEthernet 1/0/1 and GigabitEthernet 1/0/3 as network ports.
[SwitchB] interface gigabitethernet 1/0/1
[SwitchB-GigabitEthernet1/0/1] mac-forced-forwarding network-port
[SwitchB-GigabitEthernet1/0/1] quit
[SwitchB] interface gigabitethernet 1/0/3
[SwitchB-GigabitEthernet1/0/3] mac-forced-forwarding network-port
4. Enable STP on Switch C globally to make sure STP is enabled on interfaces.
<SwitchC> system-view
[SwitchC] stp global enable

621
Configuring FIPS
About FIPS
Federal Information Processing Standards (FIPS) was developed by the National Institute of
Standards and Technology (NIST) of the United States. FIPS specifies the requirements for
cryptographic modules.

FIPS security levels

FIPS 140-2 defines four levels of security, named Level 1 to Level 4, from low to high. The device
supports Level 2.
Unless otherwise noted, the term "FIPS" refers to Level-2 FIPS 140-2 in this document.

FIPS functionality
In FIPS mode, the device has strict security requirements. It performs self-tests on cryptography
modules to verify that the modules are operating correctly.
A FIPS device also meets the functionality requirements defined in Network Device Protection Profile
(NDPP) of Common Criteria (CC).

FIPS self-tests
To ensure correct operation of cryptography modules, FIPS provides self-test mechanisms, including
power-up self-tests and conditional self-tests.
If a power-up self-test fails, the device where the self-test process exists reboots. If a conditional
self-test fails, the system outputs a self-test failure message.

NOTE:
If a self-test fails, contact Hewlett Packard Enterprise Support.

Power-up self-tests
The power-up self-test examines the availability of FIPS-allowed cryptographic algorithms.
The device supports the following types of power-up self-tests:
• Known-answer test (KAT)
A cryptographic algorithm is run on data for which the correct output is already known. The
calculated output is compared with the known answer. If they are not identical, the KAT test
fails.
• Pairwise conditional test (PWCT)
 Signature and authentication test—The test is run when a DSA, RSA, or ECDSA
asymmetrical key pair is generated. The system uses the private key to sign the specific
data, and then uses the public key to authenticate the signed data. If the authentication is
successful, the test succeeds.
 Encryption and decryption test—The test is run when an RSA asymmetrical key pair is
generated. The system uses the public key to encrypt a plain text string, and then uses the
private key to decrypt the encrypted text. If the decryption result is the same as the original
plain text string, the test succeeds.

622
 The power-up self-test examines the cryptographic algorithms listed in Table 35.
Table 35 Power-up self-tests list

Type Operations
Tests the following algorithms:
• SHA1, SHA224, SHA256, SHA384, and SHA512.
• HMAC-SHA1, HMAC-SHA224, HMAC-SHA256, HMAC-SHA384,
and HMAC-SHA512.
• AES.
KAT
• RSA (signature and authentication).
• ECDH.
• DRBG.
• GCM.
• GMAC.
Tests the following algorithms:
• RSA (signature and authentication).
PWCT • RSA (encryption and decryption).
• DSA (signature and authentication).
• ECDSA (signature and authentication).

Conditional self-tests
A conditional self-test runs when an asymmetrical cryptographic module or a random number
generator module is invoked. Conditional self-tests include the following types:
• PWCT signature and authentication—This test is run when a DSA or RSA asymmetrical key
pair is generated. The system uses the private key to sign the specific data, and then uses the
public key to authenticate the signed data. If the authentication is successful, the test succeeds.
• Continuous random number generator test—Runs when a random number is generated.
The system compares the generated random number with the previously generated random
number. If the two numbers are the same, the test fails. This test also runs when a DSA or RSA
asymmetrical key pair is generated.

Restrictions and guidelines: FIPS

Requirements for key pairs and passwords
Before you reboot the device to enter FIPS mode, the system automatically removes all key pairs
configured in non-FIPS mode and all FIPS-incompliant digital certificates. FIPS-incompliant digital
certificates are MD5-based certificates with a key modulus length less than 2048 bits. You cannot log
in to the device through SSH after the device enters FIPS mode. To log in to the device in FIPS mode
through SSH, log in to the device through a console port and create a key pair for the SSH server.
The password for entering the device in FIPS mode must comply with the password control policies,
such as password length, complexity, and aging policy. When the aging timer for a password expires,
the system prompts you to change the password. If you adjust the system time after the device
enters FIPS mode, the login password might expire before the next login, because the original
system time is typically much earlier than the actual time.
Configuration rollback guidelines
Configuration rollback is supported in FIPS mode and also during a switch between FIPS mode and
non-FIPS mode. After a configuration rollback between FIPS mode and non-FIPS mode, perform the
following tasks:
1. Delete the local user and configure a new local user. Local user attributes include password,
user role, and service type.

623
 2. Save the current configuration file.
3. Specify the current configuration file as the startup configuration file.
4. Reboot the device. The new configuration takes effect after the reboot. During this process, do
not exit the system or perform other operations.
If a device enters FIPS or non-FIPS mode through automatic reboot, configuration rollback fails. To
support configuration rollback, you must execute the save command after the device enters FIPS or
non-FIPS mode.
IRF compatibility
All devices in an IRF fabric must be operating in the same mode, whether in FIPS mode or non-FIPS
mode.
To enable FIPS mode for an IRF fabric, you must reboot the entire IRF fabric.
Feature changes in FIPS mode
After the system enters FIPS mode, the following feature changes occur:
• The user login authentication mode can only be scheme.
• The FTP/TFTP server and client are disabled.
• The Telnet server and client are disabled.
• The HTTP server is disabled.
• SNMPv1 and SNMPv2c are disabled. Only SNMPv3 is available.
• The SSL server supports only TLS1.0, TLS1.1, and TLS1.2.
• The SSH server does not support SSHv1 clients or DSA key pairs.
• The generated RSA and DSA key pairs must have a modulus length of 2048 bits.
When the device acts as a server to authenticate a client through the public key, the key pair for
the client must also have a modulus length of 2048 bits.
• The generated ECDSA key pairs must have a modulus length of more than 256 bits.
When the device acts as a server to authenticate a client through the public key, the key pair for
the client must also have a modulus length of more than 256 bits.
• SSH, SNMPv3, IPsec, and SSL do not support DES, 3DES, RC4, or MD5.
• The password control feature cannot be disabled globally. The undo password-control
enable command does not take effect.
• An AAA shared key, IKE pre-shared key, or SNMPv3 authentication key must have at least 15
characters and must contain uppercase and lowercase letters, digits, and special characters.
• The password for a device management local user and password for switching user roles must
comply with the password control policies. By default, the password must have at least 15
characters and must contain uppercase and lowercase letters, digits, and special characters.

Entering FIPS mode

About entering FIPS mode
For the device to enter FIPS mode, you can use one of the following methods:
• Automatic reboot—The system automatically performs the following operations:
a. Prompts you to specify the username and password for the next login.
b. Creates a default FIPS configuration file named fips-startup.cfg.
c. Specifies the default FIPS configuration file as the startup configuration file.
d. Reboots and loads the default FIPS configuration file to enter the FIPS mode.

624
 • Manual reboot—You must complete the required configuration tasks and reboot the device
manually.

Restrictions and guidelines

After you execute the fips mode enable command, the system prompts you to choose a reboot
method.
• If you do not make a choice within 30 seconds or press Ctrl+C, the system enables FIPS mode
and waits for you to manually complete the FIPS mode configuration tasks. You must complete
the tasks or execute the undo fips mode enable command before saving the running
configuration and rebooting the device. If you fail to do so, the device enters FIPS mode after
startup and you cannot log in to the device.
• If you select the automatic reboot method, you can press Ctrl+C to abort both the interactive
FIPS mode configuration process and the fips mode enable command.

Using the automatic reboot method to enter FIPS mode

Prerequisites
To ensure login password effectiveness under the password control policies, set the correct system
time.
Procedure
1. Enter system view.
system-view
2. Enable FIPS mode.
fips mode enable
By default, the FIPS mode is disabled.
3. After the reboot method choice prompt appears, enter Y within 30 minutes.
The system starts the interactive FIPS mode configuration process.
4. Enter the login username and password as prompted.
The password must have a minimum of 15 characters and must contain uppercase and
lowercase letters, digits, and special characters. After you enter the username and password,
the device performs the following operations:
 Creates a device management local user that uses the entered username and password.
 Assigns the user the terminal service and the network-admin user role.
 Saves the running configuration and specifies the configuration file as the startup
configuration file.
 Reboots, loads the startup configuration file, and enters FIPS mode.
To log in to the device, you must enter the configured username and password. After login, you are
identified as the FIPS mode crypto officer.

Using the manual reboot method to enter FIPS mode

Prerequisites
1. To ensure login password effectiveness under the password control policies, set the correct
system time.
2. Configure the password control feature.
a. Enable the password control feature globally.

625
 b. Configure password control policies.
− Set the number of character types a password must contain to 4.
− Set the minimum number of characters for each type to one character.
− Set the minimum length for a user password to 15 characters.
For more information about the password control feature, see password control in Security
Configuration Guide.
3. Configure a local user.
 Create a device management local user.
 Specify a password that complies with the password control policies.
 Assign the terminal service to the user.
 Assign the network-admin user role to the user.
Procedure
1. Enter system view.
system-view
2. Enable FIPS mode.
fips mode enable
By default, the FIPS mode is disabled.
3. After the reboot method choice prompt appears, enter N.
The system enables FIPS mode and waits for you to complete the FIPS mode configuration
tasks. Before rebooting the device to enter FIPS mode, do not execute any commands except
for save and commands used to prepare for entering FIPS mode. If you execute any other
commands, the commands might not take effect.
4. Save the running configuration and specify the configuration file as the startup configuration
file.
5. Delete the .mdb startup configuration file.
When loading a .mdb configuration file, the device loads all settings in the file. The settings that
are not supported in FIPS mode might affect device operation.
6. Reboot the device.
The device reboots, loads the startup configuration file, and enters FIPS mode. To log in to the
device, you must enter the configured username and password. After login, you are identified
as the FIPS mode crypto officer.

Manually triggering self-tests

About this task
You can manually trigger FIPS self-tests to verify operation of cryptography modules anytime as
required. The triggered self-tests are the same as the power-up self-tests. If the self-tests fail, the
device where the self-test process exists reboots.
Procedure
1. Enter system view.
system-view
2. Trigger self-tests.
fips self-test

626
Exiting FIPS mode
About this task
After you disable FIPS mode and reboot the device, the device operates in non-FIPS mode.
For the device to exit FIPS mode, you can use one of the following reboot methods:
• Automatic reboot—The system automatically creates a default non-FIPS configuration file
named non-fips-startup.cfg, specifies the file as the startup configuration file, and reboots to
enter non-FIPS mode. You can log in to the device without providing username or password.
• Manual reboot—You must manually complete the configuration tasks for entering non-FIPS
mode, and then reboot the device. To log in to the device after the reboot, you must enter user
information as required by the authentication mode settings.
The following are the default authentication mode settings:
 VTY line—Password authentication.
 AUX line—Authentication is disabled.
You can modify the authentication settings as needed.
Using the automatic reboot method to exit FIPS mode
1. Enter system view.
system-view
2. Disable FIPS mode.
undo fips mode enable
By default, the FIPS mode is disabled.
3. Select the automatic reboot method.
Using the manual reboot method to exit FIPS mode
1. Enter system view.
system-view
2. Disable FIPS mode.
undo fips mode enable
By default, the FIPS mode is disabled.
3. Select the manual reboot method.
4. Configure login authentication settings.
 If you logged in to the device through SSH, perform the following tasks without
disconnecting the current user line:
− Set the authentication mode to scheme for VTY lines.
− Specify the username and password. If you do not specify the username or password,
the device uses the current username and password.
 If you logged in to the device through a console port, configure login authentication settings
for the current type of user lines as described in the following table:

Current login
Login authentication requirements
method
Set the authentication to scheme and specify the username and
Scheme password. If you do not specify the username or password, the device
uses the current username and password.
Set the authentication to password and specify the password. If you do
Password
not specify the password, the device uses the current password.

627
 Current login
Login authentication requirements
method
None Set the authentication to none.

5. Save the running configuration and specify the file as the startup configuration file.
6. Delete the .mdb startup configuration file.
7. Reboot the device.

Display and maintenance commands for FIPS

Execute display commands in any view.

Task Command
Display the version number of the device algorithm
display crypto version
base.

Display the FIPS mode state. display fips status

FIPS configuration examples

Example: Entering FIPS mode through automatic reboot
Network configuration
Use the automatic reboot method to enter FIPS mode, and use a console port to log in to the device
in FIPS mode.
Procedure
# If you want to save the current configuration, execute the save command before you enable FIPS
mode.
# Enable FIPS mode and choose the automatic reboot method to enter FIPS mode. Set the
username to root and the password to 12345zxcvb!@#$%ZXCVB.
<Sysname> system-view
[Sysname] fips mode enable
FIPS mode change requires a device reboot. Continue? [Y/N]:y
Reboot the device automatically? [Y/N]:y
The system will create a new startup configuration file for FIPS mode. After you set the
login username and password for FIPS mode, the device will reboot automatically.
Enter username(1-55 characters):root
Enter password(15-63 characters):
Confirm password:
Waiting for reboot... After reboot, the device will enter FIPS mode.

Verifying the configuration

After the device reboots, enter a username of root and a password of 12345zxcvb!@#$%ZXCVB.
The system prompts you to configure a new password. After you configure the new password, the
device enters FIPS mode. The new password must be different from the previous password. It must
include at least 15 characters, and contain uppercase and lowercase letters, digits, and special
characters. For more information about the requirements for the password, see the system output.

628
 Press ENTER to get started.
login: root
Password:
First login or password reset. For security reason, you need to change your password. Please
enter your password.
old password:
new password:
confirm:
Updating user information. Please wait ... ...
…
<Sysname>

# Display the FIPS mode state.

<Sysname> display fips status
FIPS mode is enabled.

# Display the default configuration file.

<Sysname> more fips-startup.cfg
#
password-control enable
#
local-user root class manage
service-type terminal
authorization-attribute user-role network-admin
#
fips mode enable
#
return

<Sysname>

Example: Entering FIPS mode through manual reboot

Network configuration
Use the manual reboot method to enter FIPS mode, and use a console port to log in to the device in
FIPS mode.
Procedure
# Enable the password control feature globally.
<Sysname> system-view
[Sysname] password-control enable

# Set the number of character types a password must contain to 4, and set the minimum number of
characters for each type to one character.
[Sysname] password-control composition type-number 4 type-length 1

# Set the minimum length of user passwords to 15 characters.

[Sysname] password-control length 15

# Add a local user account for device management, including a username of test, a password of
12345zxcvb!@#$%ZXCVB, a user role of network-admin, and a service type of terminal.
[Sysname] local-user test class manage
[Sysname-luser-manage-test] password simple 12345zxcvb!@#$%ZXCVB

629
 [Sysname-luser-manage-test] authorization-attribute user-role network-admin
[Sysname-luser-manage-test] service-type terminal
[Sysname-luser-manage-test] quit

# Enable FIPS mode, and choose the manual reboot method to enter FIPS mode.
[Sysname] fips mode enable
FIPS mode change requires a device reboot. Continue? [Y/N]:y
Reboot the device automatically? [Y/N]:n
Change the configuration to meet FIPS mode requirements, save the configuration to the
next-startup configuration file, and then reboot to enter FIPS mode.

# Save the current configuration to the root directory of the storage medium, and specify it as the
startup configuration file.
[Sysname] save
The current configuration will be written to the device. Are you sure? [Y/N]:y
Please input the file name(*.cfg)[flash:/startup.cfg]
(To leave the existing filename unchanged, press the enter key):
flash:/startup.cfg exists, overwrite? [Y/N]:y
Validating file. Please wait...
Saved the current configuration to mainboard device successfully.
[Sysname] quit

# Delete the startup configuration file in binary format.

<Sysname> delete flash:/startup.mdb
Delete flash:/startup.mdb?[Y/N]:y
Deleting file flash:/startup.mdb...Done.

# Reboot the device.

<Sysname> reboot

Verifying the configuration

After the device reboots, enter a username of test and a password of 12345zxcvb!@#$%ZXCVB.
The system prompts you to configure a new password. After you configure the new password, the
device enters FIPS mode. The new password must be different from the previous password. It must
include at least 15 characters, and contain uppercase and lowercase letters, digits, and special
characters. For more information about the requirements for the password, see the system output.
Press ENTER to get started.
login: test
Password:
First login or password reset. For security reason, you need to change your pass
word. Please enter your password.
old password:
new password:
confirm:
Updating user information. Please wait ... ...
…
<Sysname>

# Display the FIPS mode state.

<Sysname> display fips status
FIPS mode is enabled.

630
Example: Exiting FIPS mode through automatic reboot
Network configuration
After logging in to the device in FIPS mode through a console port, use the automatic reboot method
to exit FIPS mode.
Procedure
# Disable FIPS mode.
[Sysname] undo fips mode enable
FIPS mode change requires a device reboot. Continue? [Y/N]:y
The system will create a new startup configuration file for non-FIPS mode and then reboot
automatically. Continue? [Y/N]:y
Waiting for reboot... After reboot, the device will enter non-FIPS mode.

Verifying the configuration

After the device reboots, you can enter the system.
<Sysname>

# Display the FIPS mode state.

<Sysname> display fips status
FIPS mode is disabled.

Example: Exiting FIPS mode through manual reboot

Network configuration
After logging in to the device in FIPS mode through the console port with username test and
password 12345zxcvb!@#$%ZXCVB, use the manual reboot method to exit FIPS mode.
Procedure
# Disable FIPS mode.
[Sysname] undo fips mode enable
FIPS mode change requires a device reboot. Continue? [Y/N]:y
The system will create a new startup configuration file for non-FIPS mode, and then reboot
automatically. Continue? [Y/N]:n
Change the configuration to meet non-FIPS mode requirements, save the configuration to
the next-startup configuration file, and then reboot to enter non-FIPS mode.

# Save the current configuration to the root directory of the storage medium, and specify it as the
startup configuration file.
[Sysname] save
The current configuration will be written to the device. Are you sure? [Y/N]:y
Please input the file name(*.cfg)[flash:/startup.cfg]
(To leave the existing filename unchanged, press the enter key):
flash:/startup.cfg exists, overwrite? [Y/N]:y
Validating file. Please wait...
Saved the current configuration to mainboard device successfully.
[Sysname] quit

# Delete the startup configuration file in binary format.

<Sysname> delete flash:/startup.mdb
Delete flash:/startup.mdb?[Y/N]:y
Deleting file flash:/startup.mdb...Done.

631
 # Reboot the device.
<Sysname> reboot

Verifying the configuration

After the device reboots, authentication is disabled for console login by default. You can press Enter
to enter non-FIPS mode without authentication.
Press ENTER to get started.
login: test
Password:
Last successfully login time:…
…
<Sysname>

# Display the FIPS mode state.

<Sysname> display fips status
FIPS mode is disabled.

632
Configuring crypto engines
About crypto engines
Crypto engines encrypt and decrypt data for service modules.
The device supports only one software crypto engine, which is a set of software encryption
algorithms. The software crypto engine is always enabled.
When a service module requires data encryption/decryption, it sends the desired data to the crypto
engine. After the crypto engine completes data encryption/decryption, it sends the data back to the
service module.

Display and maintenance commands for crypto

engines
Execute display commands in any view and reset commands in user view.

Task Command
Display crypto engine information. display crypto-engine
display crypto-engine statistics
Display crypto engine statistics. [ engine-id engine-id slot
slot-number ]
reset crypto-engine statistics
Clear crypto engine statistics. [ engine-id engine-id slot
slot-number ]

633
Configuring MACsec
About MACsec
Media Access Control Security (MACsec) secures data communication on IEEE 802 LANs. MACsec
provides services such as data encryption, frame integrity check, and data origin validation for
frames on the MAC sublayer of the Data Link Layer. MACsec usually cooperates with 802.1X
authentication to use the keys generated from MACsec Key Agreement (MKA) negotiation for
authenticated users' data encryption and integrity check. This collaboration can prevent ports from
processing packets from unauthenticated users or tampered packets.

Basic concepts
CA
Connectivity association (CA) is a group of participants that use the same key and key algorithm.
The encryption key used by the CA participants is called a connectivity association key (CAK). The
following types of CAKs are available:
• Pairwise CAK—Used by CAs that have two participants.
• Group CAK—Used by CAs that have more than two participants.
The pairwise CAK is used most often because MACsec is typically applied to point-to-point
networks.
A CAK can be an encryption key generated during 802.1X authentication or a user-configured
preshared key. The user-configured preshared key takes precedence over the 802.1X-generated
key.
SA
Secure association (SA) is an agreement negotiated by CA participants. The agreement includes a
cipher suite and keys for integrity check.
A secure channel can contain more than one SA. Each SA uses a unique secure association key
(SAK). The SAK is generated from the CAK, and MACsec uses the SAK to encrypt data transmitted
along the secure channel.
MACsec Key Agreement (MKA) limits the number of packets that can be encrypted by an SAK.
When the limit is exceeded, the SAK will be refreshed. For example, when packets with the minimum
size are sent on a 10-Gbps link, an SAK rekey occurs about every 300 seconds.
MKA life time
The participants at each end of a secure session exchange MKA protocol packets to keep the
session alive.
MKA life time sets the session keepalive timer for participants. The timer starts on a participant when
the participant receives the first MKA protocol packet from its peer. If the participant does not receive
any subsequent MKA protocol packets from that peer before the timer expires, the participant
determines that the session is insecure and then removes the session.
In client-oriented mode, the MKA life time is 6 seconds and is not user configurable.
In device-oriented mode, the MKA life time is user configurable. By default, the MKA life time is 6
seconds.

634
MACsec services
Data encryption
MACsec enables a port to encrypt outbound frames and decrypt MACsec-encrypted inbound frames.
The keys for encryption and decryption are negotiated by MKA.
Integrity check
MACsec performs integrity check when the device receives a MACsec-encrypted frame. The
integrity check uses the following process:
• Uses a key negotiated by MKA to calculate an integrity check value (ICV) for the frame.
• Compares the calculated ICV with the ICV in the frame trailer.
 If the ICVs are the same, the device verifies the frame as legal.
 If the ICVs are different, the device determines whether to drop the frame based on the
validation mode. The device supports the following validation modes:
− check—Performs validation only, and does not drop illegal frames.
− disabled—Does not perform validation.
− strict—Performs validation, and drops illegal frames.
Replay protection
When MACsec frames are transmitted over the network, frame disorder might occur. MACsec replay
protection allows the device to accept the out-of-order packets within the replay protection window
size and drop other out-of-order packets.

MACsec application modes

MACsec supports client-oriented and device-oriented modes.
Client-oriented mode
As shown in Figure 166, MACsec secures data transmission between the client and the access
device. In this mode, MACsec must operate with 802.1X authentication.
Client-oriented MACsec includes the following entities:
• Client (supplicant)—A user terminal seeking access to the LAN. The terminal must have
802.1X software to authenticate to the access device. The terminal also performs CAK
negotiation and packet encryption.
• Access device (authenticator)—Authenticates the client to control access to the LAN and
performs CAK negotiation and packet encryption.
• Authentication server—Provides AAA services for the access device. The authentication
server is typically a RADIUS server. After the client passes authentication, the authentication
server generates and distributes the CAK to the client and the access device.
Figure 166 Client-oriented mode

Client Device Authentication server

NOTE:
In client-oriented mode, an MKA-enabled port on the access device must perform port-based
802.1X access control. The authentication method must be EAP relay.

635
Device-oriented mode
As shown in Figure 167, MACsec secures data transmission between devices. In this mode, the
same preshared key must be configured on the MACsec ports that connect the devices. The devices
use the configured preshared key as the CAK.
Figure 167 Device-oriented mode

Device A Device B

MACsec operating mechanism

Operating mechanism for client-oriented mode
Figure 168 illustrates how MACsec operates in client-oriented mode.
Figure 168 MACsec interactive process in client-oriented mode
Client Device Authentication server

EAPOL RADIUS

EAPOL-Start

EAP-Request / Identity
2
0
EAP-Response / Identity 8
Identity .1
RADIUS Access-Request X
authentication

RADIUS Access-Accept

EAP-Success

EAPOL-MKA: key server

EAPOL-MKA: MACsec capable A

K
M
.......

Session
negotiation
EAPOL-MKA: key name, SAK

EAPOL-MKA: SAK installed c

e
s
C
A
M
Secured frames
Secure
communication

The following shows the MACsec process:

1. After the client passes 802.1X authentication, the RADIUS server distributes the generated
CAK to the client and the access device.
2. After receiving the CAK, the client and the access device exchange EAPOL-MKA packets.

636
 The client and the access device exchange the MACsec capability and required parameters for
session establishment. The parameters include MKA key server priority and MACsec desire.
During the negotiation process, the access device automatically becomes the key server. The
key server generates an SAK from the CAK for packet encryption, and it distributes the SAK to
the client.
3. The client and the access device use the SAK to encrypt packets, and they send and receive
the encrypted packets in secure channels.
4. When the access device receives a logoff request from the client, it immediately removes the
associated secure session from the port. The remove operation prevents an unauthorized client
from using the secure session established by the previous authorized client to access the
network.
Operating mechanism for device-oriented mode
As shown in Figure 169, the devices use the configured preshared key to start session negotiation.
Figure 169 MACsec interactive process in device-oriented mode
Device A Device B
EAPOL

EAPOL-MKA: key server

EAPOL-MKA: MACsec capable A

K
M
.......

Session
negotiation
EAPOL-MKA: key name, SAK

EAPOL-MKA: SAK installed c

e
s
C
A
M
Secured frames
Secure
communication

The following shows the MACsec process:

1. The devices use the configured preshared key as the CAK to exchange EAPOL-MKA packets.
They exchange the MACsec capability and required parameters for session establishment. The
parameters include MKA key server priority and MACsec desire.
During the negotiation process, the port with higher MKA key server priority becomes the key
server. The key server generates and distributes an SAK.
2. The devices use the SAK to encrypt packets, and they send and receive the encrypted packets
in secure channels.
3. When a device receives a logoff request from the peer, it immediately deletes the associated
secure session.

Protocols and standards

IEEE 802.1X-2010, Port-Based Network Access Control
IEEE 802.1AE-2006, Media Access Control (MAC) Security

637
Restrictions: Hardware compatibility with MACsec
MACsec is supported on the following ports:
• The highest numbered eight GE ports on the front panel. Combo interfaces among the eight
ports also support MACsec.
• Ports on the, HPE 5130/5510 10GbE SFP+ 2-port Module (JH157A), and HPE 5130/5510
10GBASE-T 2-port Module (JH156A) modules.
An interface module is not hot swappable if it has MACsec-capable ports with MACsec enabled.
You cannot enable MKA on a MACsec-incapable port.

MACsec tasks at a glance

To configure MACsec, perform the following tasks:
1. Enabling MKA
2. Enabling MACsec desire
3. Configuring a preshared key
This task is required in device-oriented mode. Do not perform this task in client-oriented mode.
4. (Optional.) Configuring the MKA key server priority
5. (Optional.) Setting the MKA life time
This task is applicable only in device-oriented mode.
6. (Optional.) Configuring MACsec protection parameters
Choose one of the following tasks:
 Configuring MACsec protection parameters in interface view
 Configuring MACsec protection parameters by MKA policy
7. (Optional.) Enabling MKA session logging

Enabling MKA
About this task
MKA establishes and manages MACsec secure channels on a port. It also negotiates keys used by
MACsec.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable MKA.
mka enable
By default, MKA is disabled on the port.

638
Enabling MACsec desire
About this task
The MACsec desire feature expects MACsec protection for outbound frames. The key server
determines whether MACsec protects the outbound frames.
MACsec protects the outbound frames of a port when the following requirements are met:
• The key server is MACsec capable.
• Both the local participant and its peer are MACsec capable.
• A minimum of one participant is enabled with MACsec desire.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable MACsec desire.
macsec desire
By default, the port does not expect MACsec protection for outbound frames.

Configuring a preshared key

Restrictions and guidelines
In device-oriented mode, configure a preshared key as the CAK. To successfully establish an MKA
session between two devices, make sure the following requirements are met:
• The connected MACsec ports are configured with the same CAK name (CKN) and CAK.
• Only the ports are configured with the same CKN in the network.
A user-configured preshared key has higher priority than the 802.1X-generated CAK. To ensure a
successful MKA session establishment, do not configure a preshared key in client-oriented mode.
The GCM-AES-128 cipher suite requires that the CKN and CAK each must be 32 characters long. If
the configured CKN or CAK is not 32 characters long, the system performs the following operations
when it runs the cipher suite:
• Automatically increases the length of the CKN or CAK by zeros padding if the CKN or CAK
contains fewer than 32 characters.
• Uses only the first 32 characters if the CKN or CAK contains more than 32 characters.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Set a preshared key.
mka psk ckn name cak { cipher | simple } string
By default, no MKA preshared key exists.

639
Configuring the MKA key server priority
Restrictions and guidelines
When you configure the MKA key server priority, follow these restrictions and guidelines:
• In client-oriented mode, the access device port automatically becomes the key server. You do
not have to configure the MKA key server priority.
• In device-oriented mode, the port that has higher priority becomes the key server. The lower the
priority value, the higher the priority. If a port and its peers have the same priority, MACsec
compares the secure channel identifier (SCI) values on the ports. The port with the lowest SCI
value (a combination of MAC address and port ID) becomes the key server.
• A port with priority 255 cannot become the key server. For a successful key server selection,
make sure a minimum of one participant's key server priority is not 255.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Set the MKA key server priority.
mka priority priority-value
The default setting is 0.

Setting the MKA life time

Restrictions and guidelines
This task is applicable only in device-oriented mode.
Make sure the participants at each end of a secure session have the same MKA life time.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Set the MKA life time.
mka timer mka-life seconds
By default, the MKA life time is 6 seconds.

Configuring MACsec protection parameters

About MACsec protection parameters
You can set the following MACsec protection parameters:
• MACsec confidentiality offset—Specifies the number of bytes starting from the frame header.
MACsec encrypts only the bytes after the offset in a frame. The offset value can be 0, 30, or 50.
• MACsec replay protection—Allows a MACsec port to accept a number of out-of-order or
repeated inbound frames.

640
 • MACsec validation—Allows a port to perform integrity check based on the validation modes.

Restrictions and guidelines for MACsec protection parameter

configuration
You can configure MACsec protection parameters either in interface view or through MKA policies.
The use of MKA policies provides a centralized method to configure MACsec protection parameters.
When you need to configure the same settings for MACsec protection parameters on multiple ports,
you can configure them in an MKA policy and apply the policy to the ports.
If you configure a protection parameter in interface view after applying an MKA policy, the
configuration in interface view overwrites the configuration of that parameter in the MKA policy. The
other protection parameters in the MKA policy still take effect.
If you apply an MKA policy to a port after configuring protection parameters on the port, the settings
in the policy overwrite all protection parameter settings in interface view. The protection parameters
not configured in the policy are restored to the default.

Configuring MACsec protection parameters in interface view

1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Set the MACsec confidentiality offset.
macsec confidentiality-offset offset-value
The default setting is 0, and the entire frame needs to be encrypted.
MACsec uses the confidentiality offset propagated by the key server.
4. Configure MACsec replay protection:
a. Enable MACsec replay protection.
macsec replay-protection enable
By default, MACsec replay protection is enabled on the port.
b. Set the MACsec replay protection window size.
macsec replay-protection window-size size-value
The default setting is 0. The device accepts only frames that arrive in the correct order.
Out-of-order or duplicated frames will be dropped.
The configured replay protection window size takes effect only when MACsec replay
protection is enabled.
5. Set a MACsec validation mode.
macsec validation mode { check | strict }
The default setting is check.
To avoid data loss, use the display macsec command to verify that MKA negotiation with
the peer device has succeeded before you change the mode to strict.

Parameter Description
check Verifies incoming frames but does not drop illegal frames.

disabled Disables MACsec validation for incoming frames.

641
 Parameter Description
strict Verifies incoming frames and drops illegal frames.

Configuring MACsec protection parameters by MKA policy

Restrictions and guidelines
An MKA policy can be applied to a port or multiple ports. When you apply an MKA policy to a port,
follow these restrictions and guidelines:
• The settings in the MKA policy overwrite all protection parameter settings configured in
interface view. The protection parameters not configured in the policy are restored to the
default.
• Any modifications to the MKA policy take effect immediately.
• When you remove an MKA policy application from the port, the MACsec parameter settings on
the port restore to the default.
• When you apply a nonexistent MKA policy to the port, the port automatically uses the
system-defined MKA policy named default-policy. If you create the policy, the policy will be
automatically applied to the port.
Procedure
1. Enter system view.
system-view
2. Create an MKA policy and enter its view.
mka policy policy-name
By default, a system-defined MKA policy exists. The policy name is default-policy.
The settings for parameters in the system-defined policy are the same as the default settings for
the parameters on a port.
You cannot delete or modify the system-defined MKA policy.
You can create multiple MKA policies.
3. Set the MACsec confidentiality offset.
confidentiality-offset offset-value
The default setting is 0, and the entire frame needs to be encrypted.
MACsec uses the confidentiality offset propagated by the key server.
4. Configure MACsec replay protection:
a. Enable MACsec replay protection.
replay-protection enable
By default, MACsec replay protection is enabled.
b. Set the replay protection window size.
replay-protection window-size size-value
The default replay protection window size is 0. The device accepts only frames that arrive in
the correct order. Out-of-order or duplicated frames will be dropped.
5. Set a MACsec validation mode.
validation mode { check | strict }
The default setting is check.

642
 Parameter Description
check Verifies incoming frames but does not drop illegal frames.

disabled Disables MACsec validation for incoming frames.

strict Verifies incoming frames and drops illegal frames.

6. Apply an MKA policy:

a. Return to system view.
quit
b. Enter interface view.
interface interface-type interface-number
c. Apply the MKA policy to the port.
mka apply policy policy-name
By default, no MKA policy is applied to a port.

Enabling MKA session logging

About this task
This feature enables the device to generate logs for MKA session changes, such as peer aging and
SAK updates. The logs are sent to the information center of the device. For the logs to be output
correctly, you must also configure the information center on the device. For more information about
information center configuration, see Network Management and Monitoring Configuration Guide.
Restrictions and guidelines
As a best practice, disable this feature to prevent excessive MKA session log output.
Procedure
1. Enter system view.
system-view
2. Enable MKA session logging.
macsec mka-session log enable
By default, MKA session logging is disabled.

Display and maintenance commands for MACsec

Execute display commands in any view and reset commands in user view.

Task Command
display macsec [ interface
Display MACsec information on ports. interface-type interface-number ]
[ verbose ]
display mka { default-policy | policy
Display MKA policy information.
[ name policy-name ] }
display mka session [ interface
Display MKA session information. interface-type interface-number |
local-sci sci-id ] [ verbose ]

643
 Task Command
display mka statistics [ interface
Display MKA statistics on ports.
interface-type interface-number ]
reset mka session [ interface
Reset MKA sessions on ports.
interface-type interface-number ]
reset mka statistics [ interface
Clear MKA statistics on ports.
interface-type interface-number ]

MACsec configuration examples

Example: Configuring client-oriented MACsec
Network configuration
As shown in Figure 170, the host accesses the network through Ten-GigabitEthernet 1/1/1. The
device performs RADIUS-based 802.1X authentication for the host to control user access to the
Internet.
To ensure secure communication between the host and device, perform the following tasks on the
device:
• Enable MACsec desire, and configure MKA to negotiate SAKs for packet encryption.
• Set the MACsec confidentiality offset to 30 bytes.
• Enable MACsec replay protection, and set the replay protection window size to 100.
• Set the MACsec validation mode to strict.
Figure 170 Network diagram

RADIUS server
10.1.1.1/24

XGE1/1/2
10.1.1.10/24
XGE1/1/1
192.168.1.1/24
Internet

Host Device
192.168.1.2/24

Procedure
1. Configure IP addresses for the Ethernet ports. (Details not shown.)
2. Configure the RADIUS server to provide authentication, authorization, and accounting services.
Add a user account for the host. (Details not shown.)
3. Configure AAA:
# Enter system view.
<Device> system-view
# Configure RADIUS scheme radius1.
[Device] radius scheme radius1
[Device-radius-radius1] primary authentication 10.1.1.1

644
 [Device-radius-radius1] primary accounting 10.1.1.1
[Device-radius-radius1] key authentication simple name
[Device-radius-radius1] key accounting simple name
[Device-radius-radius1] user-name-format without-domain
[Device-radius-radius1] quit
# Configure authentication domain bbb for 802.1X users.
[Device] domain bbb
[Device-isp-bbb] authentication lan-access radius-scheme radius1
[Device-isp-bbb] authorization lan-access radius-scheme radius1
[Device-isp-bbb] accounting lan-access radius-scheme radius1
[Device-isp-bbb] quit
4. Configure 802.1X:
# Enable 802.1X on Ten-GigabitEthernet 1/1/1.
[Device] interface ten-gigabitethernet 1/1/1
[Device-Ten-GigabitEthernet1/1/1] dot1x
# Implement port-based access control on Ten-GigabitEthernet 1/1/1.
[Device-Ten-GigabitEthernet1/1/1] dot1x port-method portbased
# Specify bbb as the mandatory authentication domain for 802.1X users on
Ten-GigabitEthernet 1/1/1.
[Device-Ten-GigabitEthernet1/1/1] dot1x mandatory-domain bbb
[Device-Ten-GigabitEthernet1/1/1] quit
# Enable 802.1X globally, and sets the device to relay EAP packets.
[Device] dot1x
[Device] dot1x authentication-method eap
5. Configure MACsec:
# Create an MKA policy named pls.
[Device] mka policy pls
# Set the MACsec confidentiality offset to 30 bytes.
[Device-mka-policy-pls] confidentiality-offset 30
# Enable MACsec replay protection.
[Device-mka-policy-pls] replay-protection enable
# Set the MACsec replay protection window size to 100.
[Device-mka-policy-pls] replay-protection window-size 100
# Set the MACsec validation mode to strict.
[Device-mka-policy-pls] validation mode strict
[Device-mka-policy-pls] quit
# Apply the MKA policy to Ten-GigabitEthernet 1/1/1.
[Device] interface ten-gigabitethernet 1/1/1
[Device-Ten-GigabitEthernet1/1/1] mka apply policy pls
# Configure MACsec desire and enable MKA on Ten-GigabitEthernet 1/1/1.
[Device-Ten-GigabitEthernet1/1/1] macsec desire
[Device-Ten-GigabitEthernet1/1/1] mka enable
[Device-Ten-GigabitEthernet1/1/1] quit

Verifying the configuration

# Display MACsec information on Ten-GigabitEthernet 1/1/1.
[Device] display macsec interface ten-gigabitethernet 1/1/1 verbose
Interface Ten-GigabitEthernet1/1/1

645
 Protect frames : Yes
Active MKA policy : pls
Replay protection : Enabled
Replay window size : 100 frames
Confidentiality offset : 30 bytes
Validation mode : Strict
Included SCI : No
SCI conflict : No
Cipher suite : GCM-AES-128
MKA life time : 6 seconds
Transmit secure channel:
SCI : 00E00100000A0006
Elapsed time: 00h:02m:07s
Current SA : AN 0 PN 1
Receive secure channels:
SCI : 00E0020000000106
Elapsed time: 00h:02m:03s
Current SA : AN 0 LPN 1
Previous SA : AN N/A LPN N/A

# Display MKA session information on Ten-GigabitEthernet 1/1/1 after a user logs in.
[Device] display mka session interface ten-gigabitethernet 1/1/1 verbose
Interface Ten-GigabitEthernet1/1/1
Tx-SCI : 00E00100000A0006
Priority : 0
Capability: 3
CKN for participant: 1234
Key server : Yes
MI (MN) : A1E0D2897596817209CD2307 (2509)
Live peers : 1
Potential peers : 0
Principal actor : Yes
MKA session status : Secured
Confidentiality offset: 30 bytes
Current SAK status : Rx & Tx
Current SAK AN : 0
Current SAK KI (KN) : A1E0D2897596817209CD230700000002 (2)
Previous SAK status : N/A
Previous SAK AN : N/A
Previous SAK KI (KN) : N/A
Live peer list:
MI MN Priority Capability Rx-SCI
B2CAF896C9BFE2ABFB135E63 2512 0 3 00E0020000000106

Example: Configuring device-oriented MACsec

Network configuration
As shown in Figure 171, Device A is the MACsec key server.

646
 To secure data transmission between the two devices by MACsec, perform the following tasks on
Device A and Device B, respectively:
• Set the MACsec confidentiality offset to 30 bytes.
• Enable MACsec replay protection, and set the replay protection window size to 100.
• Set the MACsec validation mode to strict.
• Configure the CAK name (CKN) and the CAK as E9AC and 09DB3EF1, respectively.
Figure 171 Network diagram
XGE1/1/1 XGE1/1/1

Device A Device B

Procedure
1. Configure Device A:
# Enter system view.
<DeviceA> system-view
# Enter Ten-GigabitEthernet 1/1/1 interface view.
[DeviceA] interface ten-gigabitethernet 1/1/1
# Enable MACsec desire on Ten-GigabitEthernet 1/1/1.
[DeviceA-Ten-GigabitEthernet1/1/1] macsec desire
# Set the MKA key server priority to 5.
[DeviceA-Ten-GigabitEthernet1/1/1] mka priority 5
# Configure the CKN as E9AC and the CAK as 09DB3EF1 in plain text.
[DeviceA-Ten-GigabitEthernet1/1/1] mka psk ckn E9AC cak simple 09DB3EF1
# Set the MACsec confidentiality offset to 30 bytes.
[DeviceA-Ten-GigabitEthernet1/1/1] macsec confidentiality-offset 30
# Enable MACsec replay protection.
[DeviceA-Ten-GigabitEthernet1/1/1] macsec replay-protection enable
# Set the MACsec replay protection window size to 100.
[DeviceA-Ten-GigabitEthernet1/1/1] macsec replay-protection window-size 100
# Set the MACsec validation mode to strict.
[DeviceA-Ten-GigabitEthernet1/1/1] macsec validation mode strict
# Enable MKA on Ten-GigabitEthernet 1/1/1.
[DeviceA-Ten-GigabitEthernet1/1/1] mka enable
[DeviceA-Ten-GigabitEthernet1/1/1] quit
2. Configure Device B:
# Enter system view.
<DeviceB> system-view
# Enter Ten-GigabitEthernet 1/1/1 interface view.
[DeviceB] interface ten-gigabitethernet 1/1/1
# Enable MACsec desire on Ten-GigabitEthernet 1/1/1.
[DeviceB-Ten-GigabitEthernet1/1/1] macsec desire
# Set the MKA key server priority to 10.
[DeviceB-Ten-GigabitEthernet1/1/1] mka priority 10
# Configure the CKN as E9AC and the CAK as 09DB3EF1 in plain text.
[DeviceB-Ten-GigabitEthernet1/1/1] mka psk ckn E9AC cak simple 09DB3EF1

647
 # Set the MACsec confidentiality offset to 30 bytes.
[DeviceB-Ten-GigabitEthernet1/1/1] macsec confidentiality-offset 30
# Enable MACsec replay protection.
[DeviceB-Ten-GigabitEthernet1/1/1] macsec replay-protection enable
# Set the MACsec replay protection window size to 100.
[DeviceB-Ten-GigabitEthernet1/1/1] macsec replay-protection window-size 100
# Set the MACsec validation mode to strict.
[DeviceB-Ten-GigabitEthernet1/1/1] macsec validation mode strict
# Enable MKA on Ten-GigabitEthernet 1/1/1.
[DeviceB-Ten-GigabitEthernet1/1/1] mka enable
[DeviceB-Ten-GigabitEthernet1/1/1] quit

Verifying the configuration

# Display MACsec information on Ten-GigabitEthernet 1/1/1 of Device A.
[DeviceA] display macsec interface ten-gigabitethernet 1/1/1 verbose
Interface Ten-GigabitEthernet1/1/1
Protect frames : Yes
Replay protection : Enabled
Replay window size : 100 frames
Confidentiality offset : 30 bytes
Validation mode : Strict
Included SCI : No
SCI conflict : No
Cipher suite : GCM-AES-128
MKA life time : 6 seconds
Transmit secure channel:
SCI : 00E00100000A0006
Elapsed time: 00h:05m:00s
Current SA : AN 0 PN 1
Receive secure channels:
SCI : 00E0020000000106
Elapsed time: 00h:03m:18s
Current SA : AN 0 LPN 1
Previous SA : AN N/A LPN N/A

# Display MKA session information on Ten-GigabitEthernet 1/1/1 of Device A.

[DeviceA] display mka session interface ten-gigabitethernet 1/1/1 verbose
Interface Ten-GigabitEthernet1/1/1
Tx-SCI : 00E00100000A0006
Priority : 5
Capability: 3
CKN for participant: E9AC
Key server : Yes
MI (MN) : 85E004AF49934720AC5131D3 (182)
Live peers : 1
Potential peers : 0
Principal actor : Yes
MKA session status : Secured
Confidentiality offset: 30 bytes

648
 Current SAK status : Rx & Tx
Current SAK AN : 0
Current SAK KI (KN) : 85E004AF49934720AC5131D300000003 (3)
Previous SAK status : N/A
Previous SAK AN : N/A
Previous SAK KI (KN) : N/A
Live peer list:
MI MN Priority Capability Rx-SCI
12A1677D59DD211AE86A0128 182 10 3 00E0020000000106

# Display MACsec information on Ten-GigabitEthernet 1/1/1 of Device B.

[DeviceB] display macsec interface ten-gigabitethernet 1/1/1 verbose
Interface Ten-GigabitEthernet1/1/1
Protect frames : Yes
Replay protection : Enabled
Replay window size : 100 frames
Confidentiality offset : 30 bytes
Validation mode : Strict
Included SCI : No
SCI conflict : No
Cipher suite : GCM-AES-128
MKA life time : 6 seconds
Transmit secure channel:
SCI : 00E0020000000106
Elapsed time: 00h:05m:36s
Current SA : AN 0 PN 1
Receive secure channels:
SCI : 00E00100000A0006
Elapsed time: 00h:03m:21s
Current SA : AN 0 LPN 1
Previous SA : AN N/A LPN N/A

# Display MKA session information on Ten-GigabitEthernet 1/1/1 of Device B.

[DeviceB] display mka session interface ten-gigabitethernet 1/1/1 verbose
Interface Ten-GigabitEthernet1/1/1
Tx-SCI : 00E0020000000106
Priority : 10
Capability: 3
CKN for participant: E9AC
Key server : No
MI (MN) : 12A1677D59DD211AE86A0128 (1219)
Live peers : 1
Potential peers : 0
Principal actor : Yes
MKA session status : Secured
Confidentiality offset: 30 bytes
Current SAK status : Rx & Tx
Current SAK AN : 0
Current SAK KI (KN) : 85E004AF49934720AC5131D300000003 (3)
Previous SAK status : N/A

649
 Previous SAK AN : N/A
Previous SAK KI (KN) : N/A
Live peer list:
MI MN Priority Capability Rx-SCI
85E004AF49934720AC5131D3 1216 5 3 00E00100000A0006

Troubleshooting MACsec
Cannot establish MKA sessions between MACsec devices
Symptom
The devices cannot establish MKA sessions when the following conditions exist:
• The link connecting the devices is up.
• The ports at the ends of the link are MACsec capable.
Analysis
The symptom might occur for the following reasons:
• The ports at the link are not enabled with MKA.
• A port at the link is not configured with a preshared key or configured with a preshared key
different from the peer.
Solution
To resolve the issue:
1. Enter interface view.
2. Use the display this command to check the MACsec configuration:
 If MKA is not enabled on the port, execute the mka enable command.
 If a preshared key is not configured or the preshared key is different from the peer, use the
mka psk command to configure a preshared key. Make sure the preshared key is the same
as the preshared key on the peer.
3. If the issue persists, contact Hewlett Packard Enterprise Support.

650
Configuring an 802.1X client
About 802.1X clients
As shown in Figure 172, the 802.1X client feature allows the access device to act as the supplicant in
the 802.1X architecture. For information about the 802.1X architecture, see "802.1X overview."
Figure 172 802.1X client network diagram
Authentication server

Supplicant Authenticator

Internet

Access device Device

802.1X client tasks at a glance

To configure an 802.1X client, perform the following tasks:
1. Enabling the 802.1X client feature
2. Configuring an 802.1X client username and password
3. Specifying an 802.1X client EAP authentication method
4. (Optional.) Configuring an 802.1X client MAC address
5. (Optional.) Specifying an 802.1X client mode for sending EAP-Response and EAPOL-Logoff
packets
6. (Optional.) Configuring an 802.1X client anonymous identifier
7. Specifying an SSL client policy
This task is required when you specify PEAP-MSCHAPv2, PEAP-GTC, TTLS-MSCHAPv2, or
TTLS-GTC authentication as the 802.1X client EAP authentication method.

Enabling the 802.1X client feature

1. Enter system view.
system-view
2. Enter Ethernet interface view.
interface interface-type interface-number
3. Enable the 802.1X client feature.
dot1x supplicant enable
By default, the 802.1X client feature is disabled.

651
Configuring an 802.1X client username and
password
Restrictions and guidelines
To ensure successful authentication, make sure the username and password configured on the
802.1X client is consistent with the username and password configured on the authentication server.
Procedure
1. Enter system view.
system-view
2. Enter Ethernet interface view.
interface interface-type interface-number
3. Configure an 802.1X client username.
dot1x supplicant username username
By default, no 802.1X client username is configured.
4. Set an 802.1X client password.
dot1x supplicant password { cipher | simple } string
By default, no 802.1X client password is configured.

Specifying an 802.1X client EAP authentication

method
About this task
The following EAP authentication methods are available for the 802.1X client feature:
• MD5-Challenge.
• PEAP-MSCHAPv2.
• PEAP-GTC.
• TTLS-MSCHAPv2.
• TTLS-GTC.
Restrictions and guidelines
The following matrix shows the restrictions for the selection of authentication methods on the 802.1X
client and the authenticator:

Authentication method specified on the Packet exchange method specified on the

802.1X client authenticator

• EAP relay
MD5-Challenge
• EAP termination
• PEAP-MSCHAPv2
• PEAP-GTC
EAP relay
• TTLS-MSCHAPv2
• TTLS-GTC

652
 For information about 802.1X packet exchange methods, see "Configuring 802.1X."
Make sure the specified 802.1X client EAP authentication method is supported by the authentication
server.
Procedure
1. Enter system view.
system-view
2. Enter Ethernet interface view.
interface interface-type interface-number
3. Specify an 802.1X client EAP authentication method.
dot1x supplicant eap-method { md5 | peap-gtc | peap-mschapv2 |
ttls-gtc | ttls-mschapv2 }
By default, the 802.1X client EAP authentication method is MD5-Challenge.

Configuring an 802.1X client MAC address

About this task
The authenticator adds the MAC address of an authenticated 802.1X client to the MAC address table
and then assigns access rights to the client.
If the device has multiple Ethernet interfaces that act as 802.1X clients to seek MACsec protection,
configure a unique MAC address for each interface to ensure successful 802.1X client authentication.
For information about MACsec, see "Configuring MACsec."
You can use either of the following methods to configure a unique MAC address for each interface:
• Execute the mac-address command in Ethernet interface view. For information about this
command, see Layer 2—LAN Switching Command Reference.
• Configure an 802.1X client MAC address.
Procedure
1. Enter system view.
system-view
2. Enter Ethernet interface view.
interface interface-type interface-number
3. Configure an 802.1X client MAC address.
dot1x supplicant mac-address mac-address
By default, an Ethernet interface uses the interface's MAC address for 802.1X client
authentication. If the interface's MAC address is unavailable, the interface uses the device's
MAC address for 802.1X client authentication.

Specifying an 802.1X client mode for sending

EAP-Response and EAPOL-Logoff packets
About this task
802.1X client authentication supports unicast and multicast modes to send EAP-Response and
EAPOL-Logoff packets. As a best practice, use multicast mode to avoid 802.1X client authentication
failures if the NAS device in the network does not support receiving unicast EAP-Response or
EAPOL-Logoff packets.

653
Procedure
1. Enter system view.
system-view
2. Enter Ethernet interface view.
interface interface-type interface-number
3. Specify a mode for 802.1X client authentication to send EAP-Response and EAPOL-Logoff
packets.
dot1x supplicant transmit-mode { multicast | unicast }
By default, 802.1X client authentication uses unicast mode to send EAP-Response and
EAPOL-Logoff packets.

Configuring an 802.1X client anonymous identifier

About this task
At the first authentication phase, packets sent to the authenticator are not encrypted. The use of an
802.1X client anonymous identifier prevents the 802.1X client username from being disclosed at the
first phase. The 802.1X client sends the anonymous identifier to the authenticator instead of the
802.1X client username. The 802.1X client username will be sent to the authenticator in encrypted
packets at the second phase.
If no 802.1X client anonymous identifier is configured, the 802.1X client sends the 802.1X client
username at the first authentication phase.
The configured 802.1X client anonymous identifier takes effect only if one of the following EAP
authentication methods is used:
• PEAP-MSCHAPv2.
• PEAP-GTC.
• TTLS-MSCHAPv2.
• TTLS-GTC.
If the MD5-Challenge EAP authentication is used, the configured 802.1X client anonymous identifier
does not take effect. The 802.1X client uses the 802.1X client username at the first authentication
phase.
Restrictions and guidelines
Do not configure the 802.1X client anonymous identifier if the vendor-specific authentication server
cannot identify anonymous identifiers.
Procedure
1. Enter system view.
system-view
2. Enter Ethernet interface view.
interface interface-type interface-number
3. Configure an 802.1X client anonymous identifier.
dot1x supplicant anonymous identify identifier
By default, no 802.1X client anonymous identifier is configured.

654
Specifying an SSL client policy
About this task
If the PEAP-MSCHAPv2, PEAP-GTC, TTLS-MSCHAPv2, or TTLS-GTC authentication is used, the
802.1X client authentication process is as follows:
• The first phase—The 802.1X client acts as an SSL client to negotiate with the SSL server.
The SSL client uses the SSL parameters defined in the specified SSL client policy to establish a
connection with the SSL server for negotiation. The SSL parameters include a PKI domain,
supported cipher suites, and the SSL version. For information about SSL client policy
configuration, see "Configuring SSL."
• The second phase—The 802.1X client uses the negotiated result to encrypt and transmit the
interchanged authentication packets.
If the MD5-Challenge authentication is used, the 802.1X client does not use an SSL client policy
during the authentication process.
Procedure
1. Enter system view.
system-view
2. Enter Ethernet interface view.
interface interface-type interface-number
3. Specify an SSL client policy.
dot1x supplicant ssl-client-policy policy-name
By default, the default SSL client policy is used.

Display and maintenance commands for 802.1X

client
Execute display commands in any view.

Task Command
display dot1x supplicant [ interface
Display 802.1X client information.
interface-type interface-number ]

655
Configuring SAVA
About SAVA
Source Address Validation Architecture (SAVA) checks the validity of the source IPv6 address of
packets based on routing information to prevent source IPv6 address spoofing attacks.
A SAVA-enabled interface creates SAVA entries based on routes that use the interface as the
outgoing interface. Upon receiving an IPv6 packet on the interface, the device searches for a SAVA
entry that contains the source IPv6 address and the receiving interface. If a match is found, the
device forwards the packet. If no match is found, the device discards the packet.
SAVA is typically deployed on the border devices of the backbone network connecting to an access
network.

Benefits
As shown in Figure 173, asymmetric routing might occur in an IPv6 multiple-access network. The
outgoing interface for a return packet might be different from the incoming interface of the original
packet. You can enable strict uRPF check on interface 1 of Device B to prevent attacks with spoofed
source IPv6 addresses. However, strict uRPF check might determine that a valid packet from the
LAN as an attack packet based on local routing information, which causes unexpected packet drop.
Compared with uRPF, SAVA can not only prevent source IPv6 address spoofing attacks but also
avoid mistaken packet drop caused by asymmetric routing. When SAVA is enabled on interface 1 of
both Device A and Device B, the devices can create SAVA entries based on local routes and remote
routes synchronized from other routing protocols. In this way, both the devices have consistent SAVA
entries. This ensures that packets of valid users will not be mistakenly dropped on either a
asymmetric network or a symmetric network with asymmetric routing.
Figure 173 SAVA-enabled network
Device A

Interface 1
User network Core network
Interface 1
Device C
SAVA-enabled interface
Device B Route for packets from Device B to the LAN
Route for packets from the LAN to Device B

Mechanism
The mechanism of SAVA includes obtaining prefixes of valid users, creating SAVA entries based on
the prefixes, and using SAVA entries to filter IPv6 packets.
Obtaining prefixes of valid users
On an IPv6 multiple access network, each border device on the backbone network obtains prefix
information of all users in the LAN based on the following types of routes:
Local routes—Each border device obtains prefix information of users in the LAN from local routes,
including direct routes, static routes, and dynamic routes for the interfaces connecting to the LAN.

656
 Remote routes synchronized from other routing protocols—Each border device adds the same
tag to the local routes for the LAN and redistributes the routes to other border devices through a
routing protocol. All the border devices import the remote routes with the specified tag and then
obtain prefix information from these routes. In this way, all border devices have consistent prefix
information of valid users.
Creating SAVA entries
Each border device creates SAVA entries for the SAVA-enabled interfaces based on prefix
information of valid users. A SAVA entry includes a prefix, prefix length, and binding interface.
Filtering user packets based on SAVA entries
When a SAVA-enabled interface receives an IPv6 packet from the LAN, SAVA validates the source
IPv6 address of the packet. It searches for a SAVA entry that includes the interface by the source
IPv6 address. If a match is found, SAVA permits the packet. If no match is found, SAVA drops the
packet.

Application scenarios
Deployed on intra-AS border devices directedly connected to the LAN
As shown in Figure 174, users in the LAN connect to the backbone network through Device B and
Device C. Device B is configured with two gateways addresses (2000::1/64 and 2001::1/64). Device
C is configured with the gateway address (2000::2/64).
You can configure SAVA on interface 1 of both Device B and Device C. When Device C receives an
IPv6 route with prefix 2001::/64 from Device B, it creates an SAVA entry with this prefix. Then, upon
receiving an IPv6 packet from a user at 2001::/64, Device C will permit the packet because a
matching SAVA entry exists.
Figure 174 SAVA deployed on border devices directly connected to the LAN
Device B

Interface 1

200 1::1/64
200 0::1/64
User network Core network
200 0::2/64
Device A
200 0::/64
200 1::/64 Interface 1
SAVA-enabled interface
Device C

Deployed on intra-AS border devices indirectedly connected to the LAN

As shown in Figure 175, asymmetric traffic exists between Device D and the LAN after route
convergence. Traffic from Device D to the LAN will traverse Device E, Device C, Device B, and
Device A. Traffic from the LAN to Device D will traverse only Device A.
You can configure SAVA on interface 1 of both Device B and Device D. Device B and Device D
synchronize routes with each other, obtain prefix information of the LAN based on the synchronized
remote routes, and then create SAVA entries. Upon receiving a packet from a user in the LAN,
Device C will permit the packet because a matching SAVA entry exists.

657
 Figure 175 SAVA deployed on intra-AS border devices indirectly connected to the LAN
Device B Device C

Interface 1
2000::2/64
User network Core network
2001::2/64
Interface 1
2000::/64 Device A
2001::/64

SAVA-enabled interface Device D Device E

Route for packets from Device B to the LAN
Route for packets from the LAN to Device B

Delpoyed on inter-AS border devices indirectedly connected to the LAN

As shown in Figure 176, asymmetric traffic exists between Device D and the LAN after route
convergence. Traffic from Device D to the LAN will traverse Device E, Device C, Device B, and
Device A. Traffic from the LAN to Device D will traverse only Device A.
You can configure SAVA on interface 1 of both Device B and Device D. Device B and Device C in AS
100 as well as Device D and Device E in AS 200 synchronize local routes with each other through an
IGP protocol (OSPFv3, for example). Then, Device C in AS 100 and Device E in AS 200 synchronize
routes with each other through BGP. Upon receiving a packet from a user in the LAN, Device C will
permit the packet because a matching SAVA entry exists.
Figure 176 SAVA deployed on inter-AS border devices indirectly connected to the LAN

Restrictions: Hardware compatibility with SAVA

Only the S5560X-EI switch series that runs Release 6522 (or later) supports SAVA.

SAVA tasks at a glance

To configure SAVA, perform the following tasks:
1. Enabling SAVA
2. Enabling SAVA entry creation based on synchronized remote routes
Perform this task if the LAN connects to the backbone network through multiple border devices
and interfaces on the border devices do not have prefix information of all user in the LAN.

658
 3. Adding an interface to a SAVA access group
Perform this task if a border device has multiple interfaces connected to the same LAN.
4. Configuring SAVA logging

Enabling SAVA
Restrictions and guidelines
SAVA is mutually exclusive with uPRF and microsegmentation. Do not configure SAVA together with
uRPF or microsegmentation.
If the device has a large number of routing entries, it might take a long time for the device to complete
SAVA entry creation. Before SAVA entry creation completes, valid IPv6 packets might be dropped.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Enable SAVA on the interface.
ipv6 sava enable
By default, SAVA is disabled.

Enabling SAVA entry creation based on

synchronized remote routes
About this task
Perform this task to ensure that the border devices through which users in a LAN connects to the
backbone network have the same SAVA entries to avoid mistaken packet drop.
Each border device adds a route tag to local routes based on which SAVA entries are created and
then advertises the tagged local routes to the other border devices through a routing protocol. Then,
other border devices will create SAVA entries upon receiving the tagged routes advertised by other
border devices. In this way, the border devices maintain consistent SAVA entries.
Prerequisites
Before you enable SAVA entry creation based on synchronized remote routes, you must complete
one of the following tasks:
• Configure OSPFv3 link tag inheritance
Perform this task if OSPFv3 runs on the network. For more information about OSPFv3 link tag
inheritance, see OSPFv3 configuration in Layer 3—IP Routing Configuration Guide.
• Configure IPv6 IS-IS link tag inheritance
Perform this task if IPv6 IS-IS runs on the network. For more information about IPv6 IS-IS link
tag inheritance, see IS-IS configuration in Layer 3—IP Routing Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number

659
 3. Enable the device to create SAVA entries based on synchronized remote routes with the
specified route tag.
ipv6 sava import remote-route-tag tag
By default, the device does not create SAVA entries based on synchronized remote routes.

Adding an interface to a SAVA access group

About this task
If the device has multiple interfaces connected to the same LAN, each interface creates SAVA
entries only based on its local routes. When an interface receives a packet from the LAN for which
the interface has no matching SAVA entry, the packet will be discarded.
To resolve this issue, you can add the interfaces to a SAVA access group. The interfaces in the same
SAVA access group will synchronize SAVA entries created based on local routes with each other.
This avoids unexpected packet drop caused by asymmetric routing.
Restrictions and guidelines
All interfaces in a SAVA access group must belong to the public network or the same VPN instance.
You can add a maximum of eight interfaces to a SAVA access group.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Add the interface to a SAVA access group.
ipv6 sava access-group group-name
By default, an interface does not belong to a SAVA access group.

Configuring SAVA logging

About this task
To identify and troubleshoot issues, enable SAVA logging.
This feature enables the device to generate SAVA logs when SAVA detects spoofing packets.
With the information center, you can configure log destinations and output rules. For more
information about the information center, see Network Management and Monitoring Configuration
Guide.
Procedure
1. Enter system view.
system-view
2. Configure SAVA logging.
ipv6 sava log enable spoofing-packet [ interval interval | number
number ]*
By default, SAVA logging is disabled.

660
Display and maintenance commands for SAVA
Execute display commands in any view and reset commands in user view.

Task Command
display ipv6 sava [ interface interface-type
Display SAVA entries.
interface-number ] [ slot slot-number ]
Display SAVA packet drop display ipv6 sava packet-drop statistics
statistics. [ interface interface-type interface-number ]
reset ipv6 sava packet-drop statistics
Clear SAVA packet drop statistics.
[ interface interface-type interface-number ]

SAVA configuration examples

Example: Configuring SAVA on border devices directly
connected the LAN
Network configuration
As shown in Figure 177, legal users in the LAN use prefixes 2000::/64 and 2001::/64. Configure
SAVA on VLAN-interface 10 of Device B and Device C to meet the following requirements:
Device C creates a SAVA entry upon receiving an IPv6 route with prefix 2001::/64.
The LAN-side interface on Device C filters packets from users in the LAN based on SAVA entries.
Figure 177 Network diagram
Device B
0
-int1
Vlan 1/64 Vlan
-int2
0 1 : : 0
20
Vlan
-int2
User network OSPFv3 area 0 Core network
Vlan
-in
2000 t10 0 30
::2/6 nt3 n-int Device A
4 n-i
2000::/64 Vla Vla
2001::/64

Device C

Table 36 Interface and IP address assignment

Device Interface IP address Device Interface IP address

Device A Vlan-int20 192:168::12:1/120 Device B Vlan-int10 2001::1/64
Device A Vlan-int30 192:168::22:1/120 Device B Vlan-int20 192:168::22:2/120
Device C Vlan-int10 2000::2/64 — — —
Device C Vlan-int30 192:168::12:2/120 — — —

Prerequisites
1. Assign IPv6 addresses to interfaces on the devices.

661
 2. Configure OSPFv3 on the backbone network. For more information, see OSPFv3 configuration
in Layer 3—IP Routing Configuration Guide.
Procedure
1. Configure Device B:
# Enable SAVA on VLAN-interface 10 (the LAN-side interface).
<DeviceB> system-view
[DeviceB] interface vlan-interface 10
[DeviceB-Vlan-interface10] ipv6 sava enable
# Configure routing policy named ttt, configure node 10 in permit mode to permit routes with the
output interface VLAN-interface 10 and to set a tag of 100 for IGP routes.
[DeviceB] route-policy ttt permit node 10
[DeviceB-route-policy-ttt-10] if-match interface vlan-interface 10
[DeviceB-route-policy-ttt-10] apply tag 100
[DeviceB-route-policy-ttt-10] quit
# Configure OSPFv3 process 1 to redistribute direct routes permitted by routing policy ttt.
[DeviceB] ospfv3 100
[DeviceB-ospfv3-100] import-route direct route-policy ttt
[DeviceB-ospfv3-100] quit
2. Configure Device C:
# Enable SAVA on VLAN-interface 10 (the LAN-side interface).
<DeviceC> system-view
[DeviceC] interface vlan-interface 10
[DeviceC-Vlan-interface10] ipv6 sava enable
# Configure VLAN-interface 10 to redistribute remote routes with route tag 100.
[DeviceC-Vlan-interface10] ipv6 sava import remote-tag 100
[DeviceC-Vlan-interface10] quit

Verifying the configuration

# Display SAVA entries on Device C.
[DeviceC] display ipv6 sava
IPv6 SAVA entry count: 2
Destination: 2000:: Prefix length: 64
Interface: Vlan-int10 Flags: L

Destination: 2001:: Prefix length: 64

Interface: Vlan-int10 Flags: R

The output shows that Device C created a SAVA entry with prefix 2001::. When Device C receives an
IPv6 packet with prefix 2001:: on VLAN-interface 10, it will forward the packet.

Example: Configuring SAVA on border devices indirectly

connected the LAN (OSPFv3)
Network configuration
As shown in Figure 178, OSPFv3 runs on the core network. Configure the devices to meet the
following requirements:
Enable SAVA on VLAN-interface 30 of Device B and VLAN-interface 40 on Device D to filter packets
based on SAVA entries.

662
 On Device C, configure a static route to the LAN with next-hop device Device A. Enable OSPFv3 link
tag inheritance to statically tag routes to the LAN.
Configure OSPFv3 on Device B and Device A to synchronize routes to the LAN. Enable OSPFv3 link
tag inheritance and set the OSPFv3 link tag to dynamically tag routes to the LAN.
Figure 178 Network diagram

Device B Device C
Vlan-int20
Vlan-int20
0
t30 nt3
-in n-i Vlan-int10
Vla
n Vla
Vlan-int10 Core network
User network Vlan
-int4
Vlan-int20 0
Vlan-int10
2000::1/64 Device A Vlan
-int4 Vlan-int20
0
2001::1/64 Vlan-int20

Device D Device E

Table 37 Interface and IP address assignment

Device Interface IP address Device Interface IP address

Device A Vlan-int10 2001::2/64 Device B Vlan-int30 192:168::12:2/120
Device A Vlan-int20 2000::2/64 Device B Vlan-int20 192:168::34:3/120
Device A Vlan-int30 192:168::12:1/120 — — —
Device A Vlan-int40 192:168::22:1/120 — — —
Device C Vlan-int20 192:168::34:4/120 Device D Vlan-int40 192:168::22:2/120
Device C Vlan-int10 192:168::46:4/120 Device D Vlan-int20 192:168::56:5/120
Device E Vlan-int20 192:168::56:6/120 — — —
Device E Vlan-int10 192:168::46:6/120 — — —

Prerequisites
Assign IPv6 addresses to interfaces on the devices.
Procedure
1. Configure Device A:
# Configure OSPFv3.
<DeviceA> system-view
[DeviceA] ospfv3 1
[DeviceA-ospfv3-1] router-id 1.1.1.1
[DeviceA-ospfv3-1] quit
[DeviceA] interface vlan-interface 10
[DeviceA-Vlan-interface10] ospfv3 1 area 0.0.0.0
[DeviceA-Vlan-interface10] quit
[DeviceA] interface vlan-interface 30
[DeviceA-Vlan-interface30] ospfv3 1 area 0.0.0.0
[DeviceA-Vlan-interface130] quit
2. Configure Device B:
# Configure OSPFv3.

663
 <DeviceB> system-view
[DeviceB] ospfv3 1
[DeviceB-ospfv3-1] router-id 2.2.2.2
[DeviceB-ospfv3-1] quit
[DeviceB] interface vlan-interface 30
[DeviceB-Vlan-interface30] ospfv3 1 area 0.0.0.0
[DeviceB-Vlan-interface30] quit
[DeviceB] interface vlan-interface 20
[DeviceB- Vlan-interface20] ospfv3 1 area 0.0.0.0
[DeviceB- Vlan-interface20] quit
# Enable OSPFv3 link tag inheritance.
[DeviceB] ospfv3 1
[DeviceB-ospfv3-1] link-tag inherit enable
[DeviceB-ospfv3-1] quit
# Set the OSPFv3 link tag for VLAN-interface 30 to 100.
[DeviceB] interface vlan-interface 30
[DeviceB-Vlan-interface30] ospfv3 link-tag 100
# Enable SAVA on VLAN-interface 30.
[DeviceB-Vlan-interface30] ipv6 sava enable
# Configure VLAN-interface 30 to redistribute remote routes with route tag 100.
[DeviceB-Vlan-interface30] ipv6 sava import remote-route-tag 100
[DeviceB-Vlan-interface30] quit
3. Configure Device D:
# Configure a static route, whose destination address is 2000:: /64, next hop address is FE80::1
(a link-local IPv6 address on Device A), and tag value is 100.
<DeviceD> system-view
[DeviceD] ipv6 route-static 2000:: 64 vlan-interface 40 FE80::1 tag 100
# Configure routing policy named sava, configure node 10 in permit mode to permit routes with
the output interface VLAN-interface 40.
[DeviceD] route-policy sava permit node 10
[DeviceD-route-policy-sava-10] if-match interface vlan-interface 40
[DeviceD-route-policy-sava-10] quit
# Configure OSPFv3.
[DeviceD] ospfv3 1
[DeviceD-ospfv3-1] device-id 4.4.4.4
[DeviceD-ospfv3-1] quit
[DeviceD] interface vlan-interface 20
[DeviceD-Vlan-interface20] ospfv3 1 area 0.0.0.0
[DeviceD- Vlan-interface20] quit
# Configure OSPFv3 process 1 to redistribute direct routes permitted by routing policy sava.
[DeviceD] ospfv3 1
[DeviceD-ospfv3-1] import-route static route-policy sava
# Enable OSPFv3 link tag inheritance.
[DeviceD-ospfv3-1] link-tag inherit enable
[DeviceD-ospfv3-1] quit
# Enable SAVA on VLAN-interface 40.
[DeviceD] interface vlan-interface 40
[DeviceD-Vlan-interface40] ipv6 sava enable

664
 # Configure VLAN-interface 40 to redistribute remote routes with route tag 100.
[DeviceD-Vlan-interface40] ipv6 sava import remote-route-tag 100
[DeviceD-Vlan-interface40] quit
4. Configure Device C:
# Configure OSPFv3.
<DeviceC> system-view
[DeviceC] ospfv3 1
[DeviceC-ospfv3-1] device-id 3.3.3.3
[DeviceC-ospfv3-1] quit
[DeviceC] interface vlan-interface 40
[DeviceC-Vlan-interface40] ospfv3 1 area 0.0.0.0
[DeviceC-Vlan-interface40] quit
[DeviceC] interface vlan-interface 10
[DeviceC-Vlan-interface10] ospfv3 1 area 0.0.0.0
[DeviceC-Vlan-interface10] quit
5. Configure Device E:
# Configure OSPFv3.
<DeviceE> system-view
[DeviceE] ospfv3 1
[DeviceE-ospfv3-1] router-id 5.5.5.5
[DeviceE-ospfv3-1] quit
[DeviceE] interface vlan-interface 20
[DeviceE-Vlan-interface20] ospfv3 1 area 0.0.0.0
[DeviceE-Vlan-interface20] quit
[DeviceE] interface vlan-interface 10
[DeviceE-Vlan-interface10] ospfv3 1 area 0.0.0.0
[DeviceE-Vlan-interface10] quit

Verifying the configuration

# Display SAVA entries on Device D.
[DeviceD] display ipv6 sava
IPv6 SAVA entry count: 4
Destination:192:168::12:0 Prefix length: 120
Interface: Vlan-int40 Flags: R

Destination:192:168::22:0 Prefix length: 120

Interface: Vlan-int40 Flags: L

Destination: 2000:: Prefix length: 64

Interface: Vlan-int40 Flags: L

Destination: 2001:: Prefix length: 64

Interface: Vlan-int40 Flags: R

The output shows that Device D created SAVA entries with prefix 2000:: and 2001::. When Device D
receives an IPv6 packet with prefix 2000:: or 2001:: on VLAN-interface 40, it will forward the packet.
# Display SAVA entries on Device B.
[DeviceB] display ipv6 sava
IPv6 SAVA entry count: 3

665
 Destination:192:168::12:0 Prefix length: 120
Interface: Vlan-int30 Flags: L

Destination: 2000:: Prefix length: 64

Interface: Vlan-int30 Flags: R

Destination: 2001:: Prefix length: 64

Interface: Vlan-int30 Flags: L

The output shows that Device B created SAVA entries with prefix 2000:: and 2001::. When Device B
receives an IPv6 packet with prefix 2000:: or 2001:: on VLAN-interface 30, it will forward the packet.

Example: Configuring SAVA on border devices indirectly

connected the LAN (IPv6 IS-IS)
Network configuration
As shown in Figure 179, IPv6 IS-IS runs on the core network. Configure the devices to meet the
following requirements:
Enable SAVA on VLAN-interface 30 of Device B and VLAN-interface 40 of Dervice D to filter packets
based on SAVA entries.
On Device C, configure a static route to the LAN with next-hop device Device A. Enable IPv6 IS-IS
link tag inheritance to statically tag routes to the LAN.
Configure IPv6 IS-IS on Device B and Device A to synchronize routes to the LAN. Enable IPv6 IS-IS
link tag inheritance and set the IPv6 IS-IS link tag to dynamically tag routes to the LAN.
Figure 179 Network diagram

Device B Device C
Vlan-int20
Vlan-int20
0 t30
-int3 n -in Vlan-int10
Vlan Vla
Vlan-int10 Core network
User network Vlan
-int4
Vlan-int20 0
Vlan-int10
2000::1/64 Device A Vlan
-int4 Vlan-int20
0
2001::1/64 Vlan-int20

Device D Device E

Table 38 Interface and IP address assignment

Device Interface IP address Device Interface IP address

Device A Vlan-int10 2001::2/64 Device B Vlan-int30 192:168::12:2/120
Device A Vlan-int20 2000::2/64 Device B Vlan-int20 192:168::34:3/120
Device A Vlan-int30 192:168::12:1/120 — — —
Device A Vlan-int40 192:168::22:1/120 — — —
Device C Vlan-int20 192:168::34:4/120 Device D Vlan-int40 192:168::22:2/120
Device C Vlan-int10 192:168::46:4/120 Device D Vlan-int20 192:168::56:5/120
Device E Vlan-int20 192:168::56:6/120 — — —

666
 Device Interface IP address Device Interface IP address
Device E Vlan-int10 192:168::46:6/120 — — —

Prerequisites
Assign IPv6 addresses to interfaces on the devices.
Procedure
1. Configure Device A:
# Configure IPv6 IS-IS.
<DeviceA> system-view
[DeviceA] isis 1
[DeviceA-isis-1] is-level level-2
[DeviceA-isis-1] network-entity 10.0000.0000.0001.00
[DeviceA-isis-1] cost-style wide
[DeviceA-isis-1] address-family ipv6
[DeviceA-isis-1-ipv6] quit
[DeviceA-isis-1] quit
[DeviceA] interface vlan-interface 10
[DeviceA-Vlan-interface10] isis ipv6 enable 1
[DeviceA-Vlan-interface10] quit
[DeviceA] interface vlan-interface 30
[DeviceA-Vlan-interface30] isis ipv6 enable 1
[DeviceA-Vlan-interface30] quit
2. Configure Device B:
# Configure IPv6 IS-IS.
<DeviceB> system-view
[DeviceB] isis 1
[DeviceB-isis-1] is-level level-2
[DeviceB-isis-1] network-entity 10.0000.0000.0002.00
[DeviceB-isis-1] cost-style wide
[DeviceB-isis-1] address-family ipv6
[DeviceB-isis-1-ipv6] quit
[DeviceB-isis-1] quit
[DeviceB] interface vlan-interface 30
[DeviceB-Vlan-interface30] isis ipv6 enable 1
[DeviceB-Vlan-interface30] quit
[DeviceB] interface vlan-interface 20
[DeviceB-Vlan-interface20] isis ipv6 enable 1
[DeviceB-Vlan-interface20] quit
# Enable IPv6 IS-IS link tag inheritance.
[DeviceB] isis 1
[DeviceB-isis-1] address-family ipv6
[DeviceB-isis-1-ipv6] link-tag inherit enable
[DeviceB-isis-1-ipv6] quit
[DeviceB-isis-1] quit
# Set the IPv6 IS-IS link tag for VLAN-interface 30 to 100.
[DeviceB] interface vlan-interface 30

667
 [DeviceB-Vlan-interface30] isis ipv6 link-tag 100
# Enable SAVA on VLAN-interface 30.
[DeviceB-Vlan-interface30] ipv6 sava enable
# Configure VLAN-interface 30 to redistribute remote routes with route tag 100.
[DeviceB-Vlan-interface30] ipv6 sava import remote-route-tag 100
[DeviceB-Vlan-interface30] quit
3. Configure Device D:
# Configure a static route, whose destination address is 2000:: /64, next hop address is FE80::1
(a link-local IPv6 address on Device A), and tag value is 100.
<DeviceD> system-view
[DeviceD] ipv6 route-static 2000:: 64 vlan-interface 40 FE80::1 tag 100
# Configure routing policy named sava, configure node 10 in permit mode to permit routes with
the output interface VLAN-interface 40.
[DeviceD] route-policy sava permit node 10
[DeviceD-route-policy-sava-10] if-match interface vlan-interface 40
[DeviceD-route-policy-sava-10] quit
# Configure IPv6 IS-IS.
[DeviceD] isis 1
[DeviceD-isis-1] is-level level-2
[DeviceD-isis-1] network-entity 10.0000.0000.0004.00
[DeviceD-isis-1] cost-style wide
[DeviceD-isis-1] address-family ipv6
[DeviceD-isis-1-ipv6] quit
[DeviceD-isis-1] quit
[DeviceD] interface vlan-interface 20
[DeviceD-Vlan-interface20] isis ipv6 enable 1
[DeviceD-Vlan-interface20] quit
# Configure IS-IS process 1 to redistribute direct routes permitted by routing policy sava.
[DeviceD] isis 1
[DeviceD-isis-1] address-family ipv6
[DeviceD-isis-1-ipv6] import-route static route-policy sava level-2
# Enable IPv6 IS-IS link tag inheritance.
[DeviceD-isis-1-ipv6] link-tag inherit enable
[DeviceD-isis-1-ipv6] quit
[DeviceD-isis-1] quit
# Enable SAVA on VLAN-interface 40.
[DeviceD] interface vlan-interface 40
[DeviceD-Vlan-interface40] ipv6 sava enable
# Configure VLAN-interface 40 to redistribute remote routes with route tag 100.
[DeviceD-Vlan-interface40] ipv6 sava import remote-route-tag 100
[DeviceD-Vlan-interface40] quit
4. Configure Device C:
# Configure IPv6 IS-IS.
<DeviceC> system-view
[DeviceC] isis 1
[DeviceC-isis-1] is-level level-2
[DeviceC-isis-1] network-entity 10.0000.0000.0003.00
[DeviceC-isis-1] cost-style wide

668
 [DeviceC-isis-1] address-family ipv6
[DeviceC-isis-1-ipv6] quit
[DeviceC-isis-1] quit
[DeviceC] interface vlan-interface 40
[DeviceC-Vlan-interface40] isis ipv6 enable 1
[DeviceC-Vlan-interface40] quit
[DeviceC] interface vlan-interface 10
[DeviceC-Vlan-interface10] isis ipv6 enable 1
[DeviceC-Vlan-interface10] quit
5. Configure Device E:
# Configure IPv6 IS-IS.
<DeviceE> system-view
[DeviceE] isis 1
[DeviceE-isis-1] is-level level-2
[DeviceE-isis-1] network-entity 10.0000.0000.0005.00
[DeviceE-isis-1] cost-style wide
[DeviceE-isis-1] address-family ipv6
[DeviceE-isis-1-ipv6] quit
[DeviceE-isis-1] quit
[DeviceE] interface vlan-interface 20
[DeviceE-Vlan-interface20] isis ipv6 enable 1
[DeviceE-Vlan-interface20] quit
[DeviceE] interface vlan-interface 10
[DeviceE-Vlan-interface10] isis ipv6 enable 1
[DeviceE-Vlan-interface10] quit

Verifying the configuration

# Display SAVA entries on Device D.
[DeviceD] display ipv6 sava
IPv6 SAVA entry count: 3
Destination:192:168::22:0 Prefix length: 120
Interface: Vlan-int40 Flags: L

Destination: 2000:: Prefix length: 64

Interface: Vlan-int40 Flags: L

Destination: 2001:: Prefix length: 64

Interface: Vlan-int40 Flags: R

The output shows that Device D created SAVA entries with prefix 2000:: and 2001::. When Device D
receives an IPv6 packet with prefix 2000:: or 2001:: on VLAN-interface 40, it will forward the packet.
# Display SAVA entries on Device B.
[DeviceB] display ipv6 sava
IPv6 SAVA entry count: 3
Destination:192:168::12:0 Prefix length: 120
Interface: Vlan-int30 Flags: L

Destination: 2000:: Prefix length: 64

Interface: Vlan-int30 Flags: R

669
 Destination: 2001:: Prefix length: 64
Interface: Vlan-int30 Flags: L

The output shows that Device B created SAVA entries with prefix 2000:: and 2001::. When Device D
receives an IPv6 packet with prefix 2000:: or 2001:: on VLAN-interface 30, it will forward the packet.

Example: Configuring SAVA on inter-AS border devices

indirectly connected the LAN
Network configuration
As shown in Figure 180, configure the devices to meet the following requirements:
Configure SAVA VLAN-interface 30 of Device B and VLAN-interface 40 of Dervice D to filter packets
based on SAVA entries.
Configure remote route tagging. Device B and Device C in AS 100 and Device D and Device E in AS
200 exchange routes through IGP (for example, OSPFv3). Device C and Device E in different ASs
exchange routes through BGP. The devices create SAVA entries based on the synchronized remote
routes.
Figure 180 Network diagram

Device B Device C
Vlan-int20
Vlan-int20
0
t30 nt3
-in n-i Vlan-int10
Vla
n Vla AS 100
Vlan-int10
User network Vlan
-int4
Vlan-int20 0
Vlan-int10
2000::1/64 Device A Vlan
-int4 Vlan-int20
0
2001::1/64 Vlan-int20
AS 300
Device D Device E
AS 200
Core network

Table 39 Interface and IP address assignment

Device Interface IP address Device Interface IP address

Device A Vlan-int10 2001::2/64 Device B Vlan-int30 192:168::12:2/120
Device A Vlan-int20 2000::2/64 Device B Vlan-int20 192:168::23:2/120
Device A Vlan-int30 192:168::12:1/120 — — —
Device A Vlan-int40 192:168::22:1/120 — — —
Device C Vlan-int20 192:168::23:3/120 Device D Vlan-int40 192:168::22:2/120
Device C Vlan-int10 192:168::34:3/120 Device D Vlan-int20 192:168::45:4/120
Device E Vlan-int20 192:168::45:5/120 — — —
Device E Vlan-int10 192:168::34:4/120 — — —

670
Prerequisites
Assign IPv6 addresses to interfaces on the devices.
Procedure
1. Configure Device B:
# Configure a static route, whose destination address is 2001:: 64, next hop address is FE80::1
(a link-local IPv6 address on Device A), and tag value is 100.
<DeviceB> system-view
[DeviceB] ipv6 route-static 2001:: 64 vlan-interface 30 FE80::1 tag 100
# Configure routing policy sava and configure node 10 in permit mode for the routing policy to
permit routes with the output interface VLAN-interface 30.
[DeviceB] route-policy sava permit node 10
[DeviceB-route-policy-sava-10] if-match interface vlan-interface 30
[DeviceB-route-policy-sava-10] quit
# Configure OSPFv3.
[DeviceB] ospfv3 1
[DeviceB-ospfv3-1] router-id 2.2.2.2
[DeviceB-ospfv3-1] quit
[DeviceB] interface vlan-interface 20
[DeviceB-Vlan-interface20] ospfv3 1 area 0.0.0.0
[DeviceB-Vlan-interface20] quit
# Configure GigabitEthernet1/0/1 to redistribute remote routes with route tag 100.
[DeviceB] ospfv3 1
[DeviceB-ospfv3-1] import-route static route-policy sava
[DeviceB-ospfv3-1] quit
# Enable SAVA on VLAN-interface 30.
[DeviceB] interface vlan-interface 30
[DeviceB-Vlan-interface30] ipv6 sava enable
# Configure VLAN-interface 30 to redistribute remote routes with route tag 100.
[DeviceB-Vlan-interface30] ipv6 sava import remote-route-tag 100
[DeviceB-Vlan-interface30] quit
2. Configure Device D:
# Configure a static route, whose destination address is 2000:: 64, next hop address is FE80::1
(a link-local IPv6 address on Device A), and tag value is 100.
<DeviceD> system-view
[DeviceD] ipv6 route-static 2000:: 64 vlan-interface 40 FE80::1 tag 100
# Configure routing policy named sava, configure node 10 in permit mode to permit routes with
the output interface VLAN-interface 40.
[DeviceD] route-policy sava permit node 10
[DeviceD-route-policy-sava-10] if-match interface vlan-interface 40
[DeviceD-route-policy-sava-10] quit
# Configure OSPFv3.
[DeviceD] ospfv3 1
[DeviceD-ospfv3-1] device-id 4.4.4.4
[DeviceD-ospfv3-1] quit
[DeviceD] interface vlan-interface 20
[DeviceD-Vlan-interface20] ospfv3 1 area 0.0.0.0
[DeviceD-Vlan-interface20] quit

671
 # Configure OSPFv3 process 1 to redistribute remote routes permitted by routing policy sava.
[DeviceD] ospfv3 1
[DeviceD-ospfv3-1] import-route static route-policy sava
[DeviceD-ospfv3-1] quit
# Enable SAVA on VLAN-interface 40.
[DeviceD] interface vlan-interface 40
[DeviceD-Vlan-interface40] ipv6 sava enable
# Configure VLAN-interface 40 to redistribute remote routes with route tag 100.
[DeviceD-Vlan-interface40] ipv6 sava import remote-route-tag 100
[DeviceD-Vlan-interface40] quit
3. Configure Device C:
# Configure routing policy named sava-exp, configure node 0 in permit mode to permit routes
with tag 100 and to set the 10:10 community attribute for BGP.
[DeviceC] route-policy sava-exp permit node 0
[DeviceC-route-policy-sava-exp-0] if-match tag 100
[DeviceC-route-policy-sava-exp-0] apply community 10:10
[DeviceC-route-policy-sava-exp-0] quit
# Enable BGP to exchange routing information for IPv6 address family with peer 192:168::34:4
in AS 200.
[DeviceC] bgp 100
[DeviceC-bgp-default] router-id 3.3.3.3
[DeviceC-bgp-default] peer 192:168::34:4 as 200
[DeviceC-bgp-default] address-family ipv6
[DeviceC-bgp-default-ipv6] peer 192:168::34:4 enable
[DeviceC-bgp-default-ipv6] peer 192:168::34:4 advertise-community
# Configure BGP to redistribute routes from OSPFv3 process 1, and apply routing policy
sava-exp to routes outgoing to peer 192:168::34:4.
[DeviceC-bgp-default-ipv6] import-route ospfv3 1
[DeviceC-bgp-default-ipv6] peer 192:168::34:4 route-policy sava-exp export
[DeviceC-bgp-default-ipv6] quit
[DeviceC-bgp-default] quit
# Configure basic community list 1 to permit routes with the 10:10 community attribute.
[DeviceC] ip community-list 1 permit 10:10
# Configure a routing policy named sava-imp, and configure node 10 in permit mode for the
routing policy to use community list 1 to match BGP routes and to set the tag to 100.
[DeviceC] route-policy sava-imp permit node 0
[DeviceC-route-policy-sava-imp-0] if-match community 1
[DeviceC-route-policy-sava-imp-0] apply tag 100
[DeviceC-route-policy-sava-imp-0] quit
# Apply routing policy sava-imp to routes incoming from peer 192:168::34:4.
[DeviceC] bgp 100
[DeviceC-bgp-default] address-family ipv6
[DeviceC-bgp-default-ipv6] peer 192:168::34:4 route-policy sava-imp import
[DeviceC-bgp-default-ipv6] quit
[DeviceC-bgp-default] quit
# Configure OSPFv3.
[DeviceC] ospfv3 1
[DeviceC-ospfv3-1] device-id 3.3.3.3

672
 [DeviceC-ospfv3-1] quit
[DeviceC] interface gigabitethernet 1/0/1
[DeviceC-GigabitEthernet1/0/1] ospfv3 1 area 0.0.0.0
[DeviceC-GigabitEthernet1/0/1] quit
# Configure OSPFv3 process 1 to redistribute routes from IPv6 BGP.
[DeviceC] ospfv3 1
[DeviceC-ospfv3-1] import-route bgp4+
[DeviceC-ospfv3-1] quit
4. Configure Device E:
# Configure routing policy named sava-exp, configure node 0 in permit mode to permit routes
with tag 100 and to set the 10:10 community attribute for BGP.
[DeviceE] route-policy sava-exp permit node 0
[DeviceE-route-policy-sava-exp-0] if-match tag 100
[DeviceE-route-policy-sava-exp-0] apply community 10:10
[DeviceE-route-policy-sava-exp-0] quit
# Enable BGP to exchange routing information for IPv6 address family with peer 192:168::34:3
in AS 100.
[DeviceE] bgp 200
[DeviceE-bgp- efault] device-id 5.5.5.5
[DeviceE-bgp-default] peer 192:168::34:3 as 100
[DeviceE-bgp-default] address-family ipv6
[DeviceE-bgp-default-ipv6] peer 192:168::34:3 enable
[DeviceE-bgp-default-ipv6] peer 192:168::34:3 advertise-community
# Configure BGP to redistribute routes from OSPFv3 process 1, and apply routing policy
sava-exp to routes outgoing to peer 192:168::34:3.
[DeviceE-bgp-default-ipv6] import-route ospfv3
[DeviceE-bgp-default-ipv6] peer 192:168::34:3 route-policy sava-exp export
[DeviceE-bgp-default-ipv6] quit
[DeviceE-bgp-default] quit
# Configure basic community list 1 to permit routes with the 10:10 community attribute.
[DeviceE] ip community-list 1 permit 10:10
# Configure a routing policy named sava-imp, and configure node 10 in permit mode for the
routing policy to use community list 1 to match BGP routes and to set the tag to 100.
[DeviceE] route-policy sava-imp permit node 0
[DeviceE-route-policy-sava-imp-0] if-match community 1
[DeviceE-route-policy-sava-imp-0] apply tag 100
[DeviceE-route-policy-sava-imp-0] quit
# Apply routing policy sava-imp to routes incoming from peer 192:168::34:4.
[DeviceE] bgp 200
[DeviceE-bgp-default] address-family ipv6
[DeviceE-bgp-default-ipv6] peer 192:168::34:3 route-policy sava-imp import
[DeviceE-bgp-default-ipv6] quit
[DeviceE-bgp-default] quit
# Configure OSPFv3.
[DeviceE] ospfv3 1
[DeviceE-ospfv3-1] device-id 5.5.5.5
[DeviceE-ospfv3-1] quit
[DeviceE] interface vlan-interface 20

673
 [DeviceE-Vlan-interface20] ospfv3 1 area 0.0.0.0
[DeviceE- Vlan-interface20] quit
# Configure OSPFv3 process 1 to redistribute routes from IPv6 BGP.
[DeviceE] ospfv3 1
[DeviceE-ospfv3-1] import-route bgp4+
[DeviceE-ospfv3-1] quit

Verifying the configuration

# Display SAVA entries on Device D.
[DeviceD] display ipv6 sava
IPv6 SAVA entry count: 3
Destination:192:168::22:0 Prefix length: 120
Interface: Vlan-int40 Flags: L

Destination: 2000:: Prefix length: 64

Interface: Vlan-int40 Flags: L

Destination: 2001:: Prefix length: 64

Interface: Vlan-int40 Flags: R

The output shows that Device D created SAVA entries with prefix 2000:: and 2001::. When Device D
receives an IPv6 packet with prefix 2000:: or 2001:: on VLAN-interface 40, it will forward the packet.
# Display SAVA entries on Device B.
[DeviceB] display ipv6 sava
IPv6 SAVA entry count: 3
Destination:192:168::12:0 Prefix length: 120
Interface: Vlan-int30 Flags: L

Destination: 2000:: Prefix length: 64

Interface: Vlan-int30 Flags: R

Destination: 2001:: Prefix length: 64

Interface: Vlan-int30 Flags: L

The output shows that Device B created SAVA entries with prefix 2000:: and 2001::. When Device B
receives an IPv6 packet with prefix 2000:: or 2001:: on VLAN-interface 30, it will forward the packet.

674
Document conventions and icons
Conventions
This section describes the conventions used in the documentation.
Command conventions

Convention Description
Boldface Bold text represents commands and keywords that you enter literally as shown.
Italic Italic text represents arguments that you replace with actual values.

[] Square brackets enclose syntax choices (keywords or arguments) that are optional.
Braces enclose a set of required syntax choices separated by vertical bars, from which
{ x | y | ... }
you select one.

Square brackets enclose a set of optional syntax choices separated by vertical bars,
[ x | y | ... ]
from which you select one or none.

Asterisk marked braces enclose a set of required syntax choices separated by vertical
{ x | y | ... } *
bars, from which you select at least one.

Asterisk marked square brackets enclose optional syntax choices separated by vertical
[ x | y | ... ] *
bars, from which you select one choice, multiple choices, or none.

The argument or keyword and argument combination before the ampersand (&) sign
&<1-n>
can be entered 1 to n times.

# A line that starts with a pound (#) sign is comments.

GUI conventions

Convention Description
Window names, button names, field names, and menu items are in Boldface. For
Boldface
example, the New User window opens; click OK.
Multi-level menus are separated by angle brackets. For example, File > Create >
>
Folder.

Symbols

Convention Description
An alert that calls attention to important information that if not understood or followed
WARNING! can result in personal injury.
An alert that calls attention to important information that if not understood or followed
CAUTION: can result in data loss, data corruption, or damage to hardware or software.

IMPORTANT: An alert that calls attention to essential information.

NOTE: An alert that contains additional or supplementary information.

TIP: An alert that provides helpful information.

675
Network topology icons
Convention Description

Represents a generic network device, such as a router, switch, or firewall.

Represents a routing-capable device, such as a router or Layer 3 switch.

Represents a generic switch, such as a Layer 2 or Layer 3 switch, or a router that

supports Layer 2 forwarding and other Layer 2 features.

Represents an access controller, a unified wired-WLAN module, or the access

controller engine on a unified wired-WLAN switch.

Represents an access point.

T Represents a wireless terminator unit.

T Represents a wireless terminator.

Represents a mesh access point.

Represents omnidirectional signals.

Represents directional signals.

Represents a security product, such as a firewall, UTM, multiservice security

gateway, or load balancing device.

Represents a security module, such as a firewall, load balancing, NetStream, SSL

VPN, IPS, or ACG module.

Examples provided in this document

Examples in this document might use devices that differ from your device in hardware model,
configuration, or software version. It is normal that the port numbers, sample output, screenshots,
and other information in the examples differ from what you have on your device.

676
Support and other resources
Accessing Hewlett Packard Enterprise Support
• For live assistance, go to the Contact Hewlett Packard Enterprise Worldwide website:
www.hpe.com/assistance
• To access documentation and support services, go to the Hewlett Packard Enterprise Support
Center website:
www.hpe.com/support/hpesc
Information to collect
• Technical support registration number (if applicable)
• Product name, model or version, and serial number
• Operating system name and version
• Firmware version
• Error messages
• Product-specific reports and logs
• Add-on products or components
• Third-party products or components

Accessing updates
• Some software products provide a mechanism for accessing software updates through the
product interface. Review your product documentation to identify the recommended software
update method.
• To download product updates, go to either of the following:
 Hewlett Packard Enterprise Support Center Get connected with updates page:
www.hpe.com/support/e-updates
 Software Depot website:
www.hpe.com/support/softwaredepot
• To view and update your entitlements, and to link your contracts, Care Packs, and warranties
with your profile, go to the Hewlett Packard Enterprise Support Center More Information on
Access to Support Materials page:
www.hpe.com/support/AccessToSupportMaterials

IMPORTANT:
Access to some updates might require product entitlement when accessed through the Hewlett
Packard Enterprise Support Center. You must have an HP Passport set up with relevant
entitlements.

677
Websites
Website Link
Networking websites

Hewlett Packard Enterprise Information Library for

www.hpe.com/networking/resourcefinder
Networking
Hewlett Packard Enterprise Networking website www.hpe.com/info/networking
Hewlett Packard Enterprise My Networking website www.hpe.com/networking/support
Hewlett Packard Enterprise My Networking Portal www.hpe.com/networking/mynetworking
Hewlett Packard Enterprise Networking Warranty www.hpe.com/networking/warranty
General websites

Hewlett Packard Enterprise Information Library www.hpe.com/info/enterprise/docs

Hewlett Packard Enterprise Support Center www.hpe.com/support/hpesc
Hewlett Packard Enterprise Support Services Central ssc.hpe.com/portal/site/ssc/
Contact Hewlett Packard Enterprise Worldwide www.hpe.com/assistance
Subscription Service/Support Alerts www.hpe.com/support/e-updates
Software Depot www.hpe.com/support/softwaredepot
Customer Self Repair (not applicable to all devices) www.hpe.com/support/selfrepair
Insight Remote Support (not applicable to all devices) www.hpe.com/info/insightremotesupport/docs

Customer self repair

Hewlett Packard Enterprise customer self repair (CSR) programs allow you to repair your product. If
a CSR part needs to be replaced, it will be shipped directly to you so that you can install it at your
convenience. Some parts do not qualify for CSR. Your Hewlett Packard Enterprise authorized
service provider will determine whether a repair can be accomplished by CSR.
For more information about CSR, contact your local service provider or go to the CSR website:
www.hpe.com/support/selfrepair

Remote support
Remote support is available with supported devices as part of your warranty, Care Pack Service, or
contractual support agreement. It provides intelligent event diagnosis, and automatic, secure
submission of hardware event notifications to Hewlett Packard Enterprise, which will initiate a fast
and accurate resolution based on your product’s service level. Hewlett Packard Enterprise strongly
recommends that you register your device for remote support.
For more information and device support details, go to the following website:
www.hpe.com/info/insightremotesupport/docs

Documentation feedback
Hewlett Packard Enterprise is committed to providing documentation that meets your needs. To help
us improve the documentation, send any errors, suggestions, or comments to Documentation
Feedback ([email protected]). When submitting your feedback, include the document title,

678
part number, edition, and publication date located on the front cover of the document. For online help
content, include the product name, product version, help edition, and publication date located on the
legal notices page.

679
Index
Numerics Auth-Fail VSI configuration restrictions, 131
3DES authorization VLAN, 106
IPsec encryption algorithm, 402 authorization VLAN configuration, 147
802 authorization VLAN port manipulation, 108
MACsec configuration, 634, 638, 644 authorization VSI, 114
802.1X, 99, See also under 802 basic configuration, 145
AAA RADIUS server 802.1X user, 79 client anonymous identifier configuration, 654
AAA RADIUS server 802.1X user client anonymous identifier configuration
authentication+authorization, 86 restrictions, 654
access control method, 123 client display, 655
architecture, 99 client EAP authentication method, 652
authenticated user dynamic IPSG binding client EAP authentication method configuration
entry generation enable, 140 restrictions, 652
authentication, 103 client EAP-Response and EAPOL-Logoff packet
sending mode, 653
authentication (access device initiated), 105
client enable, 651
authentication (client initiated), 105
client MAC address configuration, 653
authentication configuration, 145
client SSL client policy, 655
authentication guest VSI+authorization VSI
configuration (MAC-based), 151 client username+password configuration, 652
authentication initiation, 105 client username+password configuration
restrictions, 652
authentication request attempts max, 136
concurrent port users max, 136
authentication timeout timer, 124
configuration, 120, 120
authentication timeout timer restrictions, 124
configuration restrictions, 120
authentication trigger, 135
controlled/uncontrolled port, 99
authentication trigger configuration
restrictions, 135 critical VLAN, 111
authentication+ACL assignment, 116 critical VLAN (MAC-based access control), 112
authentication+ACL assignment configuration, critical VLAN (port-based access control), 111
149 critical VLAN configuration, 129
authentication+CAR attribute assignment, 118 critical VLAN configuration restrictions, 129
authentication+EAD assistant configuration critical VLAN/VSI user EAP-Success packet, 134
(DHCP relay agent), 153 critical voice VLAN, 113
authentication+EAD assistant configuration critical voice VLAN (MAC-based access control),
(DHCP server), 156 113
authentication+EAD assistant feature, 119 critical voice VLAN (port-based access control),
authentication+redirect URL assignment, 117 113
authentication+user profile assignment, 117 critical voice VLAN enable, 130
Auth-Fail VLAN, 110 critical voice VLAN enable restrictions, 130
Auth-Fail VLAN (MAC-based access control), critical VSI, 115
111 critical VSI configuration, 132
Auth-Fail VLAN (port-based access control), critical VSI configuration restrictions, 132
110 display, 144
Auth-Fail VLAN configuration, 128 duplicate EAPOL-Start request discarding, 136
Auth-Fail VLAN configuration restrictions, 128 EAD assistant configuration, 142
Auth-Fail VLAN/VSI user EAP-Success EAD assistant configuration restrictions, 142
packet, 133 EAP over RADIUS, 102
Auth-Fail VSI, 115 EAP packet format, 101
Auth-Fail VSI configuration, 131

680
EAP relay, 100 quiet timer, 126
EAP relay authentication, 103 quiet timer restrictions, 126
EAP relay enable, 122 reauthentication, 125
EAP relay enable restrictions, 122 reauthentication restrictions, 125
EAP relay/termination, 101 remote VLAN authorization, 106
EAP termination, 100 server-side EAP-TLS fragment maximum size,
EAP termination enable, 122 143
EAP termination enable restrictions, 122 supported domain name delimiter, 138
EAP termination mode authentication, 104 supported domain name delimiter restrictions,
EAPOL packet format, 101 138
enable, 122 triple authentication configuration, 283, 285, 285
enable restrictions, 122 troubleshooting, 158
guest VLAN, 109 troubleshooting EAD assistant URL redirection
failure, 158
guest VLAN (MAC-based access control), 110
unauthenticated user aging, 132
guest VLAN (port-based access control), 109
user IP freezing enable, 140
guest VLAN assignment delay, 127
user logging configuration restrictions, 144
guest VLAN configuration, 126, 147
user logging enable, 144
guest VLAN configuration restrictions, 126
user profile configuration, 324
guest VSI, 114
user profile+QoS policy configuration, 324
guest VSI assignment delay, 131
VLAN manipulation, 106
guest VSI configuration, 130
VSI manipulation, 113
guest VSI configuration restrictions, 130
VXLAN support, 113
local VLAN authorization, 107
802.1X authentication
logging off user, 143
periodic reauthentication, 118
MAC address binding, 141
port security client
MAC address binding configuration
macAddressElseUserLoginSecure configuration,
restrictions, 141
317
MAC authentication delay, 185
port security client userLoginWithOUI
MAC user authentication attempts max, 139 configuration, 314
MAC-based access control, 106 port security configuration, 295, 299, 312
maintain, 144 port security free VLAN, 308
mandatory port authentication domain, 124 port security MAC address autoLearn, 312
online user handshake, 137 port security MAC move, 305
online user handshake configuration port security open authentication, 307
restrictions, 137
802.1X client
online user synchronization enable, 134
configuration, 651, 651
overview, 99
packet exchange method, 100 A
packet format, 101 AAA
parallel MAC authentication+802.1X AAA test, 67
authentication, 187 Appendix A, RADIUS commonly used attributes,
port authorization state, 123 90
port authorization status, 99 Appendix C, RADIUS subattributes (vendor ID
port security authentication control mode, 295 25506), 94
port security MAC+802.1X authentication, 297 Appendix D, RADIUS dynamic authorization ACL,
port security mode, 300 97
port-based access control, 106 concurrent login user max, 62
prerequisites, 121 configuration, 1, 15, 69
protocol packet VLAN tag removal, 139 connection recording policy, 66
protocol packet VLAN tag removal restrictions, connection recording policy configuration, 66
139 default ISP domain specifying, 57

681
device ID configuration, 63 LDAP server creation, 51
device management user attribute, 17 LDAP server IP address, 51
displaying local users/user groups, 21 LDAP server SSH user authentication, 76
EAP profile, 22 LDAP user attribute, 53
FIPS compliance, 15 LDAP versions, 52
HWTACACS, 43 local user auto-delete, 21
HWTACACS accounting server, 45 local user configuration, 16
HWTACACS authentication server, 44 methods, 11
HWTACACS authorization server, 45 NAS-ID configuration, 63
HWTACACS display, 50 network access user attribute, 18
HWTACACS implementation, 5 password change prompt logging enabling, 64
HWTACACS maintain, 50 protocols and standards, 14
HWTACACS outgoing packet source IP RADIUS accounting server, 25
address, 48 RADIUS accounting-on configuration, 39
HWTACACS scheme creation, 44 RADIUS attribute translation, 36
HWTACACS scheme VPN instance, 47 RADIUS authentication server, 24
HWTACACS server SSH user, 69 RADIUS client configuration, 65
HWTACACS shared keys, 46 RADIUS configuration, 21
HWTACACS stop-accounting packet buffering, RADIUS DAE server (DAS), 41
50 RADIUS device server feature, 13
HWTACACS timer set, 47 RADIUS display, 43
HWTACACS traffic statistics units, 49 RADIUS implementation, 2
HWTACACS username format, 49 RADIUS maintain, 43
HWTACACS/RADIUS differences, 5 RADIUS packet DSCP priority, 32
ISP domain accounting method, 61 RADIUS real-time accounting attempts max, 31
ISP domain accounting method configuration RADIUS request transmission attempts max, 31
restrictions, 61
RADIUS scheme creation, 24
ISP domain attribute configuration, 57
RADIUS scheme VPN instance, 26
ISP domain authentication method, 59
RADIUS server 802.1X user, 79
ISP domain authentication method
RADIUS server 802.1X user
configuration restrictions, 59
authentication+authorization, 86
ISP domain authorization method, 60
RADIUS server configuration, 64, 65
ISP domain authorization method
RADIUS server SSH user
configuration restrictions, 60
authentication+authorization, 73
ISP domain configuration restrictions, 56
RADIUS server status, 27
ISP domain creation, 56, 56
RADIUS service disable, 42
ISP domain display, 62
RADIUS session-control, 40
ISP domain idle timeout period include in user
RADIUS session-control configuration restrictions,
online duration, 58
40
ISP domain method, 59
RADIUS shared keys, 26
ISP domain specifying for users that are
RADIUS SNMP notification, 41
assigned to nonexistent domains, 57
RADIUS stop-accounting packet buffering, 37
LDAP, 51
RADIUS stop-accounting packet forcibly sending,
LDAP administrator attribute, 52
38
LDAP attribute map, 54
RADIUS timer configuration restrictions, 28
LDAP attribute map for authorization, 55
RADIUS timer set, 28
LDAP authentication server, 55
RADIUS traffic statistics units, 30
LDAP authorization server, 55
RADIUS user+client display, 66
LDAP display, 55
RADIUS username format, 30
LDAP implementation, 8
SSH user local authentication+HWTACACS
LDAP scheme creation, 54 authorization+RADIUS accounting, 71

682
 troubleshoot AAA, 88 ACL
troubleshoot HWTACACS, 89 802.1X authentication guest VSI+authorization
troubleshoot LDAP authentication failure, 89 VSI configuration (MAC-based), 151
troubleshoot RADIUS accounting error, 89 802.1X authentication+ACL assignment, 116
troubleshoot RADIUS authentication failure, 802.1X authentication+ACL assignment
88 configuration, 149
troubleshoot RADIUS packet delivery failure, IPsec ACL, 406
88 IPsec ACL de-encapsulated packet check, 416
troubleshooting, 88 IPsec ACL rule keywords, 406
user group attribute, 20 IPsec ACL-based implementation, 402
user management by ISP domains, 11 IPsec implementation (ACL-based), 405
user management by user access types, 11 IPsec mirror image ACLs, 407
user profile configuration, 324 IPsec non-mirror image ACLs, 407
VPN implementation, 13 MAC authentication ACL assignment, 167, 196
Web authentication AAA server, 270 MAC authentication authorization VSI assignment,
access control 199
cross-subnet portal authentication SSH login control ACL attempts denied logging,
configuration, 244 484
direct portal authentication configuration, 235 SSH management parameters, 483
direct portal authentication configuration (local SSH user connection control ACL, 484
portal Web service), 264 activating
extended cross-subnet portal authentication AAA RADIUS server configuration, 65
configuration, 255 active
extended direct portal authentication ARP active acknowledgement, 573
configuration, 248 adding
extended re-DHCP portal authentication port security secure MAC address, 303
configuration, 251
address
portal authentication configuration, 203, 209,
Address Resolution Protocol. Use ARP
235
uRPF configuration, 606
portal authentication server detection+user
synchronization configuration, 259 address pool
re-DHCP portal authentication configuration, portal user preauthentication IP address pool, 218
241 AES
Web authentication configuration, 270, 273, IPsec encryption algorithm, 402
278 aging
Web authentication configuration (local 802.1X unauthenticated user aging, 132
authentication server), 278 MAC authentication unauthenticated user aging,
Web authentication configuration (RADIUS 182
authentication server), 280 port security secure MAC address inactivity aging,
accessing 303
portal authentication device access, 204 AH
account idle time (password control), 331 IPsec security protocol 51, 399
accounting alert protocol (SSL), 542
AAA configuration, 1, 15, 69 algorithm
AAA connection recording policy configuration, IPsec authentication, 401
66 IPsec encryption (3DES), 402
AAA device ID configuration, 63 IPsec encryption (AES), 402
AAA ISP domain accounting method, 61 IPsec encryption (DES), 402
AAA RADIUS accounting server, 25 IPsec IKE DH algorithm, 440
AAA RADIUS accounting-on, 39 keychain configuration, 342, 342, 343, 343
AAA SSH user local SSH algorithm renegotiation+key re-exchange,
authentication+HWTACACS 483
authorization+RADIUS accounting, 71

683
 SSH negotiation, 475 ARP attack detection maintain, 583
SSH SCP configuration (Suite B algorithm), authorized ARP configuration, 574
533 authorized ARP configuration (DHCP relay agent),
SSH Secure Telnet configuration (128-bit 575
Suite B algorithm), 516 authorized ARP configuration (DHCP server), 574
SSH SFTP configuration (192-bit Suite B configuration, 567
algorithm), 525 configuration (user+packet validity check), 584
SSH2, 499 detection configuration, 577
SSH2 encryption, 500 detection configuration (VSI), 581
SSH2 key exchange, 499 detection logging enable, 582
SSH2 MAC, 500 filtering configuration, 590, 591
SSH2 public key, 500 filtering configuration restrictions, 590
allowing gateway protection, 589, 589
only DHCP users to pass portal authorization, gateway protection restrictions, 589
225
packet rate limit configuration, 570
only DHCP users to pass portal authorization
packet rate limit configuration restrictions, 570
(interface), 225
packet source MAC consistency check, 573
anonymous identifier (802.1X client), 654
packet validity check configuration, 579
anti-replay
packet validity check configuration (VSI), 582
IPsec anti-replay redundancy, 417
restricted forwarding, 580
IPsec configuration, 416
restricted forwarding configuration, 586
any authentication (SSH), 475
restricted forwarding restrictions, 580
Appendix A
scanning+fixed ARP configuration, 587
AAA RADIUS commonly used attributes, 90
scanning+fixed ARP configuration restrictions,
Appendix C
588
AAA RADIUS subattributes (vendor ID 25506),
sender IP address checking configuration, 592,
94
592
Appendix D
sender IP address checking restrictions, 592
AAA dynamic authorization ACL, 97
source MAC-based attack detection, 571, 572
application
source MAC-based attack detection restrictions,
uRPF network, 606 571
applying source MAC-based detection display, 572
IPsec policy to interface, 415 unresolvable IP attack, 567, 569
IPv6 ND attack defense RA guard policy, 602 unresolvable IP attack blackhole routing, 568
port security NAS-ID profile, 309 unresolvable IP attack blackhole routing
portal authentication interface NAS ID profile, restrictions, 568
232 unresolvable IP attack protection display, 569
architecture unresolvable IP attack source suppression, 568
802.1X, 99 user validity check, 577
PKI, 360 user validity check (VSI), 581
ARP user validity check configuration, 583
attack protection. See ARP attack protection user validity check configuration restrictions, 578
MFF configuration, 615, 616, 619 user validity check ingress port, 581
MFF configuration (in ring network), 620 assigning
MFF configuration (in tree network), 619 802.1X authentication+ACL assignment, 116
MFFARP packet processing, 616 802.1X authentication+user profile assignment,
portal authentication client Rule ARP entry 117
feature, 233 802.1X guest VSI assignment delay, 131
ARP attack protection MAC authentication ACL, 196
active acknowledgement, 573 MAC authentication authorization VSI, 199
ARP attack detection display, 583 associating

684
 IPsec SA, 401 MAC authentication blackhole attribute
MACsec connectivity association (CA), 634 assignment, 169
MACsec connectivity association key (CAK), MAC authentication CAR attribute assignment,
634 169
MACsec secure association (SA), 634 portal authentication NAS-Port-Id attribute format,
MACsec secure association key (SAK), 634 231
attack portal packet attributes configuration, 230
ARP attack protection configuration, 567 RADIUS NAS-Port-Type, 231
TCP attack prevention configuration, 550 RADIUS packet attributes configuration, 231
attack D&P authenticating
configuration, 548 802.1X access device initiated authentication,
105
device-preventable attacks, 548
802.1X authentication, 103
login delay, 549
802.1X authentication request attempts max, 136
login dictionary attack, 548
802.1X authentication trigger, 135
TCP fragment attack, 548
802.1X client EAP authentication method, 652
TCP fragment attack prevention configuration,
548 802.1X client-initiated, 105
attack detection and prevention. See attack D&P 802.1X duplicate EAPOL-Start request discarding,
136
attacking
802.1X EAP over RADIUS, 102
detection and prevention. See attack D&P
802.1X EAP relay authentication, 103
attribute
802.1X EAP relay enable, 122
AAA device management user attribute, 17
802.1X EAP termination enable, 122
AAA HWTACACS, 43
802.1X EAP termination mode authentication,
AAA ISP domain attribute, 57
104
AAA ISP domain authorization attribute, 57
802.1X initiation, 105
AAA ISP domain idle timeout period include in
802.1X MAC user authentication attempts max,
user online duration, 58
139
AAA LDAP, 51
802.1X mandatory port authentication domain,
AAA LDAP administrator attribute, 52 124
AAA LDAP attribute map, 54 802.1X overview, 99
AAA LDAP attribute map for authorization, 55 802.1X reauthentication, 125
AAA LDAP user attribute, 53 802.1X timeout timer, 124
AAA local user, 16 802.1X unauthenticated user aging, 132
AAA network access user attribute, 18 802.1X VLAN manipulation, 106
AAA RADIUS attribute translation, 36 802.1X VSI manipulation, 113
AAA RADIUS attribute translation (DAS), 37 AAA configuration, 1, 15, 69
AAA RADIUS attribute translation (single AAA ISP domain authentication method, 59
scheme), 36
AAA LDAP authentication, 8
AAA RADIUS Called-Station-Id attribute
AAA LDAP process, 9
format, 33
AAA LDAP server SSH user authentication, 76
AAA RADIUS Called-Station-Id attribute MAC
address format, 34 AAA RADIUS server 802.1X user
authentication+authorization, 86
AAA RADIUS Calling-Station-Id attribute MAC
address format, 34 AAA RADIUS server configuration, 64
AAA RADIUS common standard attributes, 92 AAA RADIUS server SSH user
authentication+authorization, 73
AAA RADIUS configuration, 21
AAA RADIUS user authentication methods, 3
AAA RADIUS extended attributes, 5
AAA SSH user local authentication+HWTACACS
AAA RADIUS Login-Service attribute check
authorization+RADIUS accounting, 71
method, 32
IKE-based IPsec tunnel for IPv4 packets, 427
AAA RADIUS Remanent_Volume attribute
data measurement unit, 35 IPsec, 401
AAA user group attribute, 20 IPsec authentication algorithms, 401

685
IPsec Authentication Header. Use AH SSH Secure Telnet client configuration (publickey
IPsec configuration, 399, 425 authentication), 514
IPsec Encapsulating Security Payload. Use SSH Secure Telnet server configuration
ESP (password authentication), 502
IPsec IKE configuration (main SSH Secure Telnet server configuration
mode+preshared key authentication), 451 (publickey authentication), 504
IPsec IKE DSA signature authentication, 440 SSH server configuration, 477
IPsec IKE preshared key authentication, 440 SSH SFTP client configuration (publickey
IPsec IKE RSA signature authentication, 440 authentication), 522
IPsec RIPng configuration, 430 SSH SFTP server configuration (password
authentication), 520
IPsec RRI configuration, 419, 433
SSH user authentication timeout timer, 484
IPsec tunnel configuration for IPv4 packets
(IKE-based), 454 SSL services, 542
IPsec tunnel for IPv4 packets (manual), 425 user profile configuration, 323, 323, 324
keychain configuration, 342, 342, 343, 343 user profile+QoS policy configuration, 324
MAC authentication, 159, 171, 192 authentication failure VLAN
MAC authentication (local), 192 triple authentication configuration (authorization
VLAN+Auth-Fail VLAN), 289
MAC authentication (RADIUS-based), 194
Authentication, Authorization, and Accounting. Use
MAC authentication guest VLAN
AAA
reauthentication, 177
Auth-Fail VLAN
MAC authentication guest VSI
reauthentication, 180 802.1X authentication, 110
MAC authentication unauthenticated user 802.1X authentication (MAC-based access
aging, 182 control), 111
MAC authentication VLAN assignment, 161 802.1X authentication (port-based access
control), 110
MAC local authentication method, 160
802.1X Auth-Fail VLAN user EAP-Success
MAC RADIUS authentication method, 160
packet, 133
password control configuration, 328, 332, 338
802.1X configuration, 128
periodic 802.1X reauthentication, 118
triple authentication, 284
periodic MAC reauthentication, 169, 176
Web authentication Auth-Fail VLAN, 272, 277
port security authentication modes, 295
Auth-Fail VSI
port security client
802.1X authentication, 115
macAddressElseUserLoginSecure
configuration, 317 802.1X Auth-Fail VSI user EAP-Success packet,
133
port security client userLoginWithOUI
configuration, 314 802.1X configuration, 131
port security configuration, 295, 299, 312 authorization VLAN
port security escape critical VSI, 310 802.1X configuration, 147
port security MAC address autoLearn MAC authentication, 161
configuration, 312 MAC authentication port manipulation, 162
port security open authentication mode, 307 port manipulation, 108
portal authentication client, 204 triple authentication, 284
portal server, 204 triple authentication configuration (authorization
RESTful server-assisted MAC authentication VLAN+Auth-Fail VLAN), 289
user recovery, 170 Web authentication authorization VLAN, 271
SSH authentication attempt max number, 484 authorization VSI
SSH configuration, 474 802.1X authentication guest VSI+authorization
SSH methods, 475 VSI configuration (MAC-based), 151
SSH SCP+password authentication, 529 MAC authentication, 166
SSH Secure Telnet client configuration authorized ARP
(password authentication), 510 configuration, 574
configuration (DHCP relay agent), 575

686
 configuration (DHCP server), 574 IPSG static binding (wired network), 551
authorizing IPv4SG static binding configuration (wired
802.1X authorization VLAN, 106 network), 554
802.1X authorization VSI, 114 IPv6 source guard (IPv6SG) binding max
802.1X port authorization state, 123 (interface), 558
802.1X port authorization status, 99 IPv6SG static binding configuration (wired
network), 557
802.1X port authorized-force state, 123
blackhole
802.1X port auto state, 123
ARP attack protection blackhole routing
802.1X port unauthorized-force state, 123
(unresolvable IP attack), 568
AAA configuration, 1, 15, 69
MAC authentication blackhole attribute
AAA ISP domain authorization method, 60 assignment, 169
AAA LDAP authorization, 8 broadcast
AAA LDAP process, 10 port security NTK configuration, 304
AAA RADIUS server 802.1X user buffering
authentication+authorization, 86
AAA HWTACACS stop-accounting packet
AAA RADIUS server SSH user buffering, 50
authentication+authorization, 73
AAA RADIUS stop-accounting packet buffering,
AAA RADIUS session-control, 40 37
AAA SSH user local
authentication+HWTACACS C
authorization+RADIUS accounting, 71 CA
MAC authentication authorization VLAN, 161 PKI architecture, 360
MAC authentication authorization VLAN port PKI CA policy, 360
manipulation, 162 PKI certificate, 359
MAC authentication authorization VSI, 166 PKI certificate export, 374
MAC authentication local VLAN authorization, PKI certificate obtain, 371
162
PKI certificate removal, 374
MAC authentication remote VLAN
PKI certificate request, 368
authorization, 161
PKI certificate request abort, 370
port security authorization-fail-offline feature,
306 PKI certificate verification, 372
port security server authorization information PKI CRL, 359
ignore, 305 PKI domain configuration, 363
portal authorization strict-checking mode, 224 PKI entity configuration, 362
auto PKI online certificate request (manual), 369
FIPS mode (automatic reboot), 624 PKI online certificate request mode (automatic),
FIPS mode entry (automatic reboot), 628 369
FIPS mode exit (automatic reboot), 627, 631 PKI OpenCA server certificate request, 383
PKI online certificate request mode PKI RSA Keon CA server certificate request, 377
(automatic), 369 PKI storage path, 367
port security MAC address autoLearn PKI Windows 2003 CA server certificate request,
configuration, 312 379
PKI Windows 2003 CA server IKE
B
negotiation+RSA digital signature, 386
BAS-IP troubleshooting PKI CA certificate import failure,
portal authentication BAS-IP, 230 396
benefit troubleshooting PKI CA certificate obtain failure,
IKE, 438 394
IPsec, 399 CAR
binding 802.1X authentication+CAR attribute assignment,
IPsec source interface to policy, 417 118
IPSG dynamic binding (wired network), 552 AAA RADIUS class attribute as CAR parameter,
33

687
 MAC authentication CAR attribute assignment, 802.1X authentication+EAD assistant
169 configuration (DHCP relay agent), 153
certificate 802.1X authentication+EAD assistant
authority. Use CA configuration (DHCP server), 156
PKI certificate verification (CRL checking), 802.1X authorization VLAN configuration, 147
373 802.1X basic configuration, 145
PKI certificate verification (w/o CRL checking), 802.1X client anonymous identifier configuration,
373 654
revocation list. Use CRL 802.1X client configuration, 651, 651
challenging 802.1X client MAC address configuration, 653
IPsec IKEv2 cookie challenge, 470 802.1X client SSL client policy, 655
changing 802.1X client username+password configuration,
SFTP directory name, 493 652
SFTP file name, 494 802.1X configuration, 120, 120
SFTP working directory, 493 802.1X guest VLAN configuration, 147
SSL change cipher spec protocol, 542 AAA RADIUS configuration, 65
CHAP MACsec (client-oriented), 644
MAC authentication method, 173 MACsec operation (client-oriented), 636
CHAP/PAP authentication portal authentication, 204
direct/cross-subnet portal authentication portal authentication system, 203
process, 206 SSL client policy configuration, 545
re-DHCP portal authentication process, 207 Web authentication, 270
checking Web authentication system components, 270
ARP sender IP address checking, 592, 592 command
category-2 portal filtering rule issuing, 223 AAA command accounting method, 11
IPsec ACL de-encapsulated packet check, AAA command authorization method, 11
416 comparing
MACsec integrity check, 635, 635 802.1X EAP relay/termination, 101
PKI certificate verification (CRL checking), complexity checking (password control), 329
373 composition checking (password control), 328
PKI certificate verification (w/o CRL checking), conditional self-test, 623
373
configuration rollback guidelines, 623
portal authorization strict-checking mode, 224
configuring
uRPF loose check mode, 606
802.1X, 120, 120
uRPF strict check mode, 606
802.1X authentication, 145
class
802.1X authentication guest VSI+authorization
AAA RADIUS class attribute as CAR VSI (MAC-based), 151
parameter, 33
802.1X authentication trigger, 135
classifying
802.1X authentication+ACL assignment, 149
IPsec QoS pre-classify enable, 418
802.1X authentication+EAD assistant (DHCP
clearing relay agent), 153
IPsec packet DF bit clear, 419 802.1X authentication+EAD assistant (DHCP
client server), 156
802.1X authentication, 103 802.1X Auth-Fail VLAN, 110, 128
802.1X authentication (access device 802.1X Auth-Fail VSI, 131
initiated), 105 802.1X authorization VLAN, 147
802.1X authentication (client-initiated), 105 802.1X basics, 145
802.1X authentication client timeout timer, 124 802.1X client, 651, 651
802.1X authentication configuration, 145 802.1X client anonymous identifier, 654
802.1X authentication initiation, 105 802.1X client anonymous identifier (Ethernet
802.1X authentication+ACL assignment interface view), 654
configuration, 149

688
802.1X client MAC address, 653 AAA RADIUS DAE server (DAS), 41
802.1X client username+password, 652 AAA RADIUS Login-Service attribute check
802.1X client username+password (Ethernet method, 32
interface view), 652 AAA RADIUS server, 64
802.1X critical VLAN, 111, 129 AAA RADIUS server 802.1X user, 79
802.1X critical VSI, 132 AAA RADIUS server 802.1X user
802.1X EAD assistant, 142 authentication+authorization, 86
802.1X guest VLAN, 109, 126, 147 AAA RADIUS server SSH user
802.1X guest VSI, 130 authentication+authorization, 73
802.1X MAC address binding, 141 AAA RADIUS server status detection test profile,
23
802.1X online user handshake, 137
AAA RADIUS session-control, 40
802.1X reauthentication, 125
AAA RADIUS stop-accounting packet buffering,
802.1X unauthenticated user aging, 132
37
AAA, 1, 15, 69
AAA SSH user local authentication+HWTACACS
AAA connection recording policy, 66 authorization+RADIUS accounting, 71
AAA device ID, 63 AAA test, 67
AAA device management user attributes, 17 AAA user group attributes, 20
AAA EAP profile, 22 ARP active acknowledgement, 573
AAA HWTACACS, 43 ARP attack detection, 577
AAA HWTACACS server SSH user, 69 ARP attack detection (source MAC-based), 571,
AAA HWTACACS stop-accounting packet 572
buffering, 50 ARP attack detection (VSI), 581
AAA ISP domain accounting method, 61 ARP attack detection packet validity check, 579
AAA ISP domain attribute, 57 ARP attack detection packet validity check (VSI),
AAA ISP domain authentication method, 59 582
AAA ISP domain authorization attribute, 57 ARP attack detection restricted forwarding, 580
AAA ISP domain authorization method, 60 ARP attack detection user validity check, 577
AAA ISP domain method, 59 ARP attack detection user validity check (VSI),
AAA LDAP, 51 581
AAA LDAP administrator attributes, 52 ARP attack protection, 567
AAA LDAP attribute map, 54 ARP attack protection (unresolvable IP attack),
AAA LDAP server IP address, 51 567, 569
AAA LDAP server SSH user authentication, ARP attack protection (user+packet validity
76 check), 584
AAA LDAP user attributes, 53 ARP attack protection blackhole routing
AAA local user, 16 (unresolvable IP attack), 568
AAA local user auto-delete, 21 ARP attack protection restricted forwarding, 586
AAA NAS-ID, 63 ARP attack protection source suppression
(unresolvable IP attack), 568
AAA network access user attributes, 18
ARP attack protection user validity check, 583
AAA RADIUS, 21
ARP filtering, 590, 591
AAA RADIUS accounting-on, 39
ARP gateway protection, 589, 589
AAA RADIUS attribute Called-Station-Id
format, 33 ARP packet rate limit, 570
AAA RADIUS attribute translation, 36 ARP packet source MAC consistency check, 573
AAA RADIUS attribute translation (DAS), 37 ARP scanning+fixed ARP, 587
AAA RADIUS attribute translation (single ARP sender IP address checking, 592, 592
scheme), 36 attack D&P, 548
AAA RADIUS Called-Station-Id attribute MAC attack D&P TCP fragment attack prevention, 548
address format, 34 authorized ARP, 574
AAA RADIUS Calling-Station-Id attribute MAC authorized ARP (DHCP relay agent), 575
address format, 34 authorized ARP (DHCP server), 574

689
cross-subnet portal authentication, 244 IPsec IKEv2 policy, 467
crypto engine, 633 IPsec IKEv2 profile, 463
destination-based portal-free rule, 221 IPsec IKEv2 profile local ID, 464
DHCP relay agent-based dynamic IPv4SG, IPsec IKEv2 profile peer ID, 465
562 IPsec IKEv2 proposal, 468
DHCP snooping-based dynamic IPv4SG IPsec IPv6 routing protocol profile (manual), 420
(wired network), 561 IPsec packet DF bit, 419
DHCPv6 relay agent-based dynamic IPv6SG, IPsec policy (IKE-based), 412
565
IPsec policy (IKE-based/direct), 413
DHCPv6 snooping-based dynamic IPv6SG
IPsec policy (IKE-based/template), 414
address bindings (wired network), 563
IPsec policy (manual), 411
DHCPv6 snooping-based dynamic IPv6SG
prefix bindings (wired network), 564 IPsec RIPng, 430
direct portal authentication, 235 IPsec RRI, 419, 433
direct portal authentication (local portal Web IPsec SNMP notification, 423
service), 264 IPsec transform set, 408
extended cross-subnet portal authentication, IPsec tunnel for IPv4 packets (IKE-based), 454
255 IPsec tunnel for IPv4 packets (manual), 425
extended direct portal authentication, 248 IPSG (wired network), 551, 553, 560
extended re-DHCP portal authentication, 251 IPv4SG (wired network), 553
FIPS, 622, 628 IPv4SG static binding (global)(wired network),
global IPsec IKE DPD, 449 555
global IPsec SA lifetime and idle timeout, 422 IPv4SG static binding (on interface)(wired
IKE phase 1 negotiation mode, 443 network), 555
IKE profile optional features, 444 IPv4SG static binding (wired network), 554
IKE-based IPsec tunnel for IPv4 packets, 427 IPv6 ND attack defense, 595
IKEv2 profile optional features, 466 IPv6 ND attack defense RA guard, 601, 603
IP-based portal-free rule, 220 IPv6 ND attack defense RA guard policy, 602
IPsec, 399, 425 IPv6 ND attack detection, 596, 599
IPsec ACL, 406 IPv6SG (wired network), 556
IPsec anti-replay, 416 IPv6SG static binding (global)(wired network),
557
IPsec anti-replay redundancy, 417
IPv6SG static binding (on interface)(wired
IPsec for IPv6 routing protocols, 420
network), 557
IPsec fragmentation, 422
IPv6SG static binding (wired network), 557
IPsec IKE, 438, 451
keychain, 342, 342, 343, 343
IPsec IKE (main mode+preshared key
local portal authentication service, 213
authentication), 451
local portal service, 274
IPsec IKE global identity information, 447
MAC authentication, 159, 171, 192
IPsec IKE keepalive, 448
MAC authentication (local), 192
IPsec IKE keychain, 446
MAC authentication (RADIUS-based), 194
IPsec IKE NAT keepalive, 448
MAC authentication ACL assignment, 196
IPsec IKE profile, 442
MAC authentication authorization VSI assignment,
IPsec IKE profile local ID, 444
199
IPsec IKE profile peer ID, 442
MAC authentication critical VLAN, 178
IPsec IKE proposal, 445
MAC authentication critical VSI, 181
IPsec IKE SNMP notification, 450
MAC authentication delay, 185
IPsec IKEv2, 461
MAC authentication guest VLAN, 177
IPsec IKEv2 DPD, 470
MAC authentication guest VSI, 180
IPsec IKEv2 global parameters, 470
MAC authentication offline detection, 182
IPsec IKEv2 keychain, 469
MAC authentication timer, 175
IPsec IKEv2 NAT keepalive, 471

690
MAC authentication unauthenticated user port security secure MAC addresses, 302
aging, 182 portal authentication, 203, 209, 235
MAC authentication user account policy, 174 portal authentication destination subnet, 222
MAC authentication Web proxy port URL portal authentication detection features, 226
redirection, 189 portal authentication fail-permit, 226
MACsec, 634, 638, 644 portal authentication local portal Web service
MACsec (client-oriented), 644 parameter, 216
MACsec (device-oriented), 646 portal authentication portal-free rule, 220
MACsec MKA key server priority, 640 portal authentication server BAS-IP, 230
MACsec preshared key, 639 portal authentication server BAS-IP (interface),
MACsec protection parameters, 640 230
MACsec protection parameters (interface portal authentication server detection, 227
view), 641 portal authentication server detection+user
MACsec protection parameters (MKA policy), synchronization, 259
642 portal authentication source subnet, 221
MFF, 615, 616, 619 portal authentication user online detection, 226
MFF (in ring network), 620 portal authentication user synchronization, 229
MFF (in tree network), 619 portal authentication Web proxy support, 222
MFF network port, 617 portal authentication Web redirect, 234
NAS-Port-Type attribute, 231 portal authentication Web server detection, 228
ND attack detection (VLAN), 597 portal packet attributes, 230
ND attack detection (VSI), 598 portal Web server basic parameters, 212
NETCONF-over-SSH, 539 RADIUS packet attributes, 231
NETCONF-over-SSH client user line, 480 re-DHCP portal authentication, 241
NETCONF-over-SSH+password remote portal authentication server, 211
authentication, 539 remote portal authentication Web server, 212
password control, 328, 332, 338 RESTful server-assisted MAC authentication user
peer host public key, 352 recovery, 188
periodic MAC reauthentication, 176 SAVA, 656, 658
PKI, 359, 361, 376 SAVA access group, 660
PKI certificate import/export, 388 SAVA logging, 660
PKI certificate request abort, 370 SAVA on border devices directly connected the
PKI certificate-based access control policy, LAN (on switch), 661
375 SAVA on border devices indirectly connected the
PKI domain, 363 LAN (IPv6 IS-IS)(on switch), 666
PKI entity, 362 SAVA on border devices indirectly connected the
PKI online certificate request (manual), 369 LAN (OSPFv3)(on switch), 662
PKI OpenCA server certificate request, 383 SAVA on inter-AS border devices directly
PKI RSA Keon CA server certificate request, connected the LAN (on switch), 670
377 SAVI, 608, 608, 610
PKI Windows 2003 CA server certificate SAVI (DHCPv6+SLAAC), 613
request, 379 SAVI (DHCPv6-only), 610
PKI Windows 2003 CA server IKE SAVI (SLAAC-only), 612
negotiation+RSA digital signature, 386 SAVI DHCPv6 snooping, 609
port security, 295, 299, 312 SAVI IP source guard, 609
port security client SAVI ND parameters, 609
macAddressElseUserLoginSecure, 317 Secure Telnet client user line, 480
port security client userLoginWithOUI, 314 source-based portal-free rule, 221
port security free VLAN, 308 SSH, 474
port security intrusion protection, 304 SSH client host public key, 480
port security MAC address autoLearn, 312 SSH device as Secure Telnet client, 486
port security NTK feature, 304

691
SSH device as server, 477 Web authentication proxy support, 277
SSH device as SFTP client, 489 Web authentication server, 274
SSH management parameters, 483 Web authentication user online detection, 276
SSH SCP, 529 Web authentication-free subnet, 276
SSH SCP (Suite B algorithm), 533 connecting
SSH SCP client device, 495 MACsec connectivity association (CA), 634
SSH SCP+Linux client, 531 MACsec connectivity association key (CAK), 634
SSH SCP+password authentication, 529 SSH session disconnect, 485
SSH Secure Telnet, 501 connectivity association (CA)
SSH Secure Telnet (128-bit Suite B algorithm), MACsec, 634
516 connectivity association key (CAK)
SSH Secure Telnet client (password MACsec, 634
authentication), 510 consistency check (ARP attack protection), 573
SSH Secure Telnet client (publickey controlling
authentication), 514
802.1X controlled/uncontrolled port, 99
SSH Secure Telnet server (password
AAA RADIUS session-control, 40
authentication), 502
port security MAC address learning, 296
SSH Secure Telnet server (publickey
authentication), 504 portal authentication user access, 220
SSH SFTP, 520 cookie
SSH SFTP (192-bit Suite B algorithm), 525 IPsec IKEv2 cookie challenge, 462, 470
SSH SFTP client (publickey authentication), copying
522 IPsec packet DF bit copy, 419
SSH SFTP server (password authentication), creating
520 AAA HWTACACS scheme, 44
SSH user, 482 AAA ISP domain, 56, 56
SSH2 algorithms (encryption), 500 AAA LDAP scheme, 54
SSH2 algorithms (key exchange), 499 AAA RADIUS scheme, 24
SSH2 algorithms (MAC), 500 IPsec IKE profile, 442
SSH2 algorithms (public key), 500 IPsec IKEv2 profile, 463
SSL, 542, 543 local key pair, 350
SSL client, 544 PKI domain, 364
SSL client policy, 545 security LDAP server, 51
SSL server, 543 SFTP new directory, 494
SSL server policy, 544 critical VLAN
static IPv4SG (wired network), 560 802.1X authentication, 111
static IPv6SG (wired network), 563 802.1X authentication (MAC-based access
TCP attack prevention, 550 control), 112
TCP attack prevention (Naptha attack), 550 802.1X authentication (port-based access
triple authentication, 283, 285, 285 control), 111
triple authentication (authorization 802.1X configuration, 129
VLAN+Auth-Fail VLAN), 289 802.1X critical VLAN user EAP-Success packet,
triple authentication basics, 285 134
uRPF, 606 MAC authentication, 164
user profile, 323, 323, 324 MAC authentication configuration, 178
user profile+QoS policy, 324 critical voice VLAN
Web authentication, 270, 273, 278 802.1X authentication, 113
Web authentication (local authentication 802.1X authentication (MAC-based access
server), 278 control), 113
Web authentication (RADIUS authentication 802.1X authentication (port-based access
server), 280 control), 113
Web authentication Auth-Fail VLAN, 277 802.1X enable, 130

692
 MAC authentication, 165 SAVI deletion delay, 609
MAC authentication enable, 179 SFTP directory, 494
critical VSI SFTP file, 494
802.1X authentication, 115 SSH SCP server public key, 498
802.1X configuration, 132 SSH Secure Telnet server public key, 489
802.1X critical VSI user EAP-Success packet, SSH SFTP server public key, 492
134 delimiter (802.1X domain name), 138
MAC authentication, 167 DES
MAC authentication configuration, 181 IPsec encryption algorithm, 402
CRL desire
PKI, 359 MACsec enable, 639
PKI architecture, 360 destination
PKI CA policy, 360 portal authentication destination subnet, 222
PKI certificate export, 374 portal authentication portal-free rule, 220
PKI certificate removal, 374 destroying
PKI certificate-based access control policy, local key pair, 354
375 detecting
PKI storage path, 367 AAA RADIUS server status detection test profile,
troubleshooting PKI CRL obtain failure, 396 23
cross-subnet ARP attack detection (source MAC-based), 571,
extended cross-subnet portal authentication 572
configuration, 255 ARP attack detection configuration, 577
portal authentication configuration, 244 ARP attack detection configuration (VSI), 581
portal authentication mode, 206 IPv6 ND attack detection configuration, 596
crypto engine MAC authentication offline detection configuration,
configuration, 633 182
display, 633 portal authentication detection, 226
maintain, 633 portal authentication server, 227
cryptography portal authentication server detection+user
FIPS self-test, 622 synchronization configuration, 259
customizing portal authentication user online detection, 226
portal authentication local portal Web service portal authentication user synchronization, 229
page customization, 205 portal authentication Web server, 228
portal authentication pages, 214, 214, 214 Web authentication user online detection, 276
D device
802.1X authentication, 103
DAE
802.1X authentication configuration, 145
AAA RADIUS attribute translation (DAS), 37
802.1X authentication initiation, 105
AAA RADIUS DAE server (DAS), 41
802.1X authentication+ACL assignment
data configuration, 149
MACsec configuration, 634, 638, 644 802.1X authentication+EAD assistant
MACsec configuration (client-oriented), 644 configuration (DHCP relay agent), 153
MACsec configuration (device-oriented), 646 802.1X authentication+EAD assistant
SSL configuration, 542, 543 configuration (DHCP server), 156
data encryption 802.1X authorization VLAN configuration, 147
PKI configuration, 359, 361, 376 802.1X basic configuration, 145
default 802.1X client configuration, 651, 651
MFF default gateway, 616 802.1X configuration, 120, 120
delaying 802.1X EAD assistant, 142
MAC authentication delay, 185 802.1X guest VLAN configuration, 147
deleting

693
802.1X server-side EAP-TLS fragment configuring SAVA on inter-AS border devices
maximum size, 143 directly connected the LAN configuration (on
AAA configuration, 1, 15, 69 switch), 670
AAA device ID configuration, 63 cross-subnet portal authentication configuration,
AAA device management user, 16 244
AAA EAP profile, 22 crypto engine configuration, 633
AAA HWTACACS, 43 direct portal authentication configuration, 235
AAA HWTACACS accounting server, 45 direct portal authentication configuration (local
portal Web service), 264
AAA HWTACACS authentication server, 44
extended cross-subnet portal authentication
AAA HWTACACS authorization server, 45
configuration, 255
AAA HWTACACS implementation, 5
extended direct portal authentication
AAA HWTACACS scheme VPN instance, 47 configuration, 248
AAA HWTACACS server SSH user, 69 extended re-DHCP portal authentication
AAA HWTACACS shared keys, 46 configuration, 251
AAA LDAP, 51 IPsec RIPng configuration, 430
AAA LDAP attribute map for authorization, 55 IPv6 ND attack defense device role, 601
AAA LDAP authentication server, 55 keychain configuration, 342, 343, 343
AAA LDAP authorization server, 55 logging off 802.1X user, 143
AAA LDAP implementation, 8 logging off MAC authentication user, 190
AAA LDAP server SSH user authentication, MAC authentication, 171, 192
76 MAC authentication (local), 192
AAA LDAP server timeout period, 52 MAC authentication (RADIUS-based), 194
AAA local user, 16 MAC authentication ACL assignment, 196
AAA RADIUS accounting server, 25 MAC authentication authorization VSI assignment,
AAA RADIUS authentication server, 24 199
AAA RADIUS configuration, 21 MAC authentication configuration, 159
AAA RADIUS implementation, 2 MACsec (device-oriented), 646
AAA RADIUS scheme VPN instance, 26 MACsec operation (device-oriented), 636
AAA RADIUS server 802.1X user, 79 MFF server IP address, 618
AAA RADIUS server configuration, 64 NETCONF-over-SSH configuration, 539
AAA RADIUS server SSH user NETCONF-over-SSH+password authentication
authentication+authorization, 73 configuration, 539
AAA RADIUS server status, 27 password control configuration, 328, 332, 338
AAA RADIUS shared keys, 26 password control parameters (global), 333
AAA SSH user local password control parameters (local user), 336
authentication+HWTACACS password control parameters (super), 337
authorization+RADIUS accounting, 71
password control parameters (user group), 335
AAA VPN implementation, 13
password setting, 328
attack D&P configuration, 548
port security server authorization information
attack D&P device-preventable attacks, 548 ignore, 305
authorized ARP configuration (DHCP server), portal authentication AAA server, 204
574
portal authentication access device ID, 230
configuring SAVA on border devices directly
portal authentication client, 204
connected the LAN configuration (on switch),
661 portal authentication device access, 204
configuring SAVA on border devices indirectly portal authentication policy server, 204
connected the LAN configuration (IPv6 IS-IS) portal authentication server detection+user
(on switch), 666 synchronization configuration, 259
configuring SAVA on border devices indirectly portal server, 204
connected the LAN configuration (OSPFv3) re-DHCP portal authentication configuration, 241
(on switch), 662 SSH SCP client, 495
SSH SCP configuration, 529

694
 SSH SCP server enable, 479 authorized ARP configuration (DHCP relay agent),
SSH SCP+Linux client, 531 575
SSH SCP+password authentication, 529 authorized ARP configuration (DHCP server), 574
SSH Secure Telnet client, 486 extended re-DHCP portal authentication
SSH Secure Telnet client configuration configuration, 251
(password authentication), 510 portal authentication mode (re-DHCP), 206
SSH Secure Telnet client configuration portal authentication modes, 205
(publickey authentication), 514 portal authentication process, 206
SSH Secure Telnet configuration, 501 portal authentication re-DHCP process
SSH Secure Telnet configuration (128-bit (CHAP/PAP authentication), 207
Suite B algorithm), 516 RADIUS subattribute 218 of vendor 25506 in
SSH Secure Telnet server configuration RADIUS packets, 35
(password authentication), 502 re-DHCP portal authentication configuration, 241
SSH Secure Telnet server configuration relay agent-based dynamic IPv4SG configuration,
(publickey authentication), 504 562
SSH Secure Telnet server connection troubleshooting portal authentication users
establishment, 487 cannot log in (re-DHCP), 269
SSH Secure Telnet server enable, 479 DHCP snooping
SSH server configuration, 477 DHCP snooping-based dynamic IPv4SG
SSH SFTP client, 489 configuration (wired network), 561
SSH SFTP client configuration (publickey DHCPv6
authentication), 522 relay agent-based dynamic IPv6SG configuration,
SSH SFTP configuration, 520 565
SSH SFTP configuration (192-bit Suite B SAVI configuration, 608, 608, 610
algorithm), 525 SAVI configuration (DHCPv6+SLAAC), 613
SSH SFTP server configuration (password SAVI configuration (DHCPv6-only), 610
authentication), 520 SAVI configuration (SLAAC-only), 612
SSH SFTP server enable, 479 snooping-based dynamic IPv6SG address
SSL client configuration, 544 binding configuration (wired network), 563
SSL server configuration, 543 snooping-based dynamic IPv6SG prefix binding
SSL server policy configuration, 544 configuration (wired network), 564
user profile configuration, 323, 323 DHCPv6 snooping
user profile+QoS policy configuration, 324 SAVI configuration, 609
Web authentication device access, 270 SAVI deletion delay, 609
DF bit dictionary
IPsec packet DF bit clear, 419 attack D&P login delay, 549
IPsec packet DF bit copy, 419 attack D&P login dictionary attack, 548
IPsec packet DF bit set, 419 digital certificate
DH PKI CA certificate, 359
IPsec IKEv2 DH guessing, 462 PKI CA policy, 360
DH algorithm PKI certificate export, 374
IPsec IKE, 440 PKI certificate import/export configuration, 388
IPsec PFS, 440 PKI certificate obtain, 371
DHCP PKI certificate removal, 374
802.1X authentication+EAD assistant PKI certificate request, 368
configuration (DHCP relay agent), 153 PKI certificate request abort, 370
802.1X authentication+EAD assistant PKI certificate verification, 372
configuration (DHCP server), 156 PKI certificate-based access control policy, 375
allowing only DHCP users to pass portal PKI configuration, 359, 361, 376
authentication, 225 PKI CRL, 359
authorized ARP configuration, 574 PKI domain configuration, 363
PKI entity configuration, 362

695
 PKI local certificate, 359 host public key, 352
PKI online certificate request (manual), 369 IPsec, 424
PKI online certificate request mode IPsec IKE, 451
(automatic), 369 IPsec IKEv2, 471
PKI OpenCA server certificate request, 383 IPSG (wired network), 559
PKI peer certificate, 359 IPv4SG (wired network), 559
PKI RA certificate, 359 IPv6 ND attack defense RA guard, 603
PKI RSA Keon CA server certificate request, IPv6SG (wired network), 559
377 keychain, 343
PKI storage path, 367 MAC authentication, 191
PKI verification (CRL checking), 373 MACsec, 643
PKI verification (w/o CRL checking), 373 MFF, 618
PKI Windows 2003 CA server certificate ND attack detection, 599
request, 379
password control, 338
Digital Signature Algorithm. Use DSA
PKI, 376
direct portal authentication mode, 205
port security, 312
directing
portal authentication, 234
portal authentication Web redirect, 234
public key, 354
directory
SAVA, 661
AAA LDAP directory service, 8
SFTP directory file, 493, 494
SFTP directory deletion, 494
SFTP working directory, 493
SFTP directory file display, 493, 494
SSH, 501
SFTP directory name change, 493
SSH SFTP help information, 495
SFTP new directory creation, 494
SSL, 547
SFTP working directory change, 493
uRPF, 607
SFTP working directory display, 493
user profile, 323
SSH SFTP, 493
Web authentication, 278
disabling
distributing
AAA RADIUS service, 42
local host public key, 351
SSL session renegotiation, 546
domain
discarding
802.1X mandatory port authentication domain,
802.1X duplicate EAPOL-Start request, 136 124
disconnecting 802.1X supported domain name delimiter, 138
SSH session, 485 AAA ISP domain accounting method, 61
displaying AAA ISP domain attribute, 57
802.1X, 144 AAA ISP domain authentication method, 59
802.1X client, 655 AAA ISP domain authorization attribute, 57
AAA connection recording policy, 66 AAA ISP domain authorization method, 60
AAA HWTACACS, 50 AAA ISP domain idle timeout period include in
AAA ISP domain, 62 user online duration, 58
AAA LDAP, 55 AAA ISP domain status, 57
AAA local users/user groups, 21 MAC authentication, 173
AAA RADIUS, 43 PKI domain configuration, 363
AAA RADIUS user+client, 66 portal authentication domain, 219
ARP attack detection, 583 SSH server PKI domain, 485
ARP attack detection (source MAC-based), Web authentication domain, 275
572 Don't Fragment bit. See DF bit
ARP attack protection (unresolvable IP attack), downloading
569
SFTP file+local save, 494
crypto engine, 633
DPD
FIPS, 628
global IPsec IKE DPD, 449

696
 IPsec IKEv2 DPD, 470 802.1X packet format, 101
DSA 802.1X relay, 100
host public key display, 352 802.1X relay authentication, 103
host public key export, 351 802.1X relay/termination, 101
IPsec IKE signature authentication, 440 802.1X server-side EAP-TLS fragment maximum
public key management, 349 size, 143
SSH client host public key configuration, 480 802.1X termination, 100
SSH Secure Telnet client configuration portal support, 208
(publickey authentication), 514 EAP authentication
DSCP 802.1X client EAP authentication method, 652
AAA RADIUS packet DSCP priority setting, 32 EAPOL
SSH server packet DSCP value, 484 802.1X authentication (access device initiated),
dst-mac validity check (ARP attack detection), 579 105
dual stack 802.1X authentication (client-initiated), 105
portal authentication support for IPv4/IPv6 802.1X packet format, 101
dual stack, 217 ECDSA
dynamic public key management, 349
DHCP relay agent-based IPv4SG Elliptic Curve Digital Signature Algorithm. Use ECDSA
configuration, 562 email (PKI secure), 361
DHCP snooping-based dynamic IPv4SG enable
configuration (wired network), 561 captive-bypass feature, 212
DHCPv6 relay agent-based dynamic IPv6SG enabling
configuration, 565
802.1X, 122
DHCPv6 snooping-based dynamic IPv6SG
802.1X authenticated user dynamic IPSG binding
address binding configuration (wired network),
entry generation, 140
563
802.1X critical voice VLAN, 130
DHCPv6 snooping-based dynamic IPv6SG
prefix binding configuration (wired network), 802.1X EAP relay, 122
564 802.1X EAP termination, 122
IPSG dynamic binding (wired network), 552 802.1X guest VLAN assignment delay, 127
port security dynamic secure MAC, 303 802.1X guest VSI assignment delay, 131
port security secure MAC address, 302 802.1X online user synchronization, 134
802.1X prerequisites, 121
E
802.1X user IP freezing, 140
EAD 802.1X user logging, 144
802.1X authentication+EAD assistant, 119 AAA password change prompt logging, 64
802.1X authentication+EAD assistant AAA RADIUS server load sharing, 38
configuration (DHCP relay agent), 153
AAA RADIUS SNMP notification, 41
802.1X authentication+EAD assistant
AAA RADIUS stop-accounting packet forcibly
configuration (DHCP server), 156
sending, 38
802.1X EAD assistant configuration, 142
ARP attack detection logging, 582
troubleshooting 802.1X EAD assistant URL
attack D&P login delay, 549
redirection failure, 158
IPsec ACL de-encapsulated packet check, 416
EAP
IPsec IKE invalid SPI recovery, 449
802.1X Auth-Fail VLAN/VSI user
EAP-Success packet, 133 IPsec IKEv2 cookie challenge, 470
802.1X critical VLAN/VSI user EAP-Success IPsec packet logging, 423
packet, 134 IPsec QoS pre-classify, 418
802.1X EAP over RADIUS, 102 IPv4SG (wired network), 553
802.1X EAP relay enable, 122 IPv4SG alarming on interface (wired network),
802.1X EAP termination enable, 122 556
802.1X EAP termination mode authentication, IPv6 ND attack defense RA guard logging, 603
104

697
IPv6 ND attack defense source MAC SAVI packet spoofing logging and filtering entry
consistency check, 596 logging, 610
IPv6SG (wired network), 556 SSH algorithm renegotiation+key re-exchange,
IPv6SG alarming on interface (wired network), 483
558 SSH login control ACL attempts denied logging,
logging for portal user login/logout, 233 484
MAC authentication, 172 SSH SCP server, 479
MAC authentication critical voice VLAN, 179 SSH Secure Telnet server, 479
MAC authentication guest VLAN SSH server support for SSH1 clients, 483
reauthentication, 177 SSH SFTP server, 479
MAC authentication guest VSI uRPF (global), 607
reauthentication, 180 Web authentication, 274
MAC authentication multi-VLAN mode, 185 encapsulating
MAC authentication online user IKE-based IPsec tunnel for IPv4 packets, 427
synchronization, 183 IPsec ACL de-encapsulated packet check, 416
MAC authentication user logging, 190 IPsec anti-replay, 416
MACsec desire, 639 IPsec configuration, 399, 425
MACsec MKA, 638 IPsec RIPng configuration, 430
MACsec MKA session logging, 643 IPsec RRI configuration, 419, 433
MFF, 617 IPsec transport mode, 400
MFF periodic gateway probe, 618 IPsec tunnel configuration for IPv4 packets
ND attack detection (interface), 597 (IKE-based), 454
ND attack detection logging, 599 IPsec tunnel for IPv4 packets (manual), 425
NETCONF-over-SSH, 480 IPsec tunnel mode, 400
parallel MAC authentication+802.1X encrypting
authentication, 187 crypto engine configuration, 633
password control, 332 IKE-based IPsec tunnel for IPv4 packets, 427
PKI online certificate request mode IPsec, 401
(automatic), 369
IPsec configuration, 399, 425
port security, 299
IPsec encryption algorithm (3DES), 402
port security authorization-fail-offline, 306
IPsec encryption algorithm (AES), 402
port security dynamic secure MAC, 303
IPsec encryption algorithm (DES), 402
port security escape critical VSI, 310
IPsec RIPng configuration, 430
port security MAC move, 305
IPsec RRI configuration, 419, 433
port security open authentication mode, 307
IPsec tunnel configuration for IPv4 packets
port security secure MAC address inactivity (IKE-based), 454
aging, 303
IPsec tunnel for IPv4 packets (manual), 425
port security SNMP notification, 311
MACsec data encryption, 635, 635
port security user logging, 311
public key management, 349, 354
portal authentication (interface), 216
SSH configuration, 474
portal authentication client Rule ARP entry
SSH server configuration, 477
feature, 233
SSL services, 542
portal authentication client Rule ND entry
feature, 233 entering
portal authentication roaming, 225 FIPS mode (automatic reboot), 624, 628
portal authorization strict-checking mode, 224 FIPS mode (manual reboot), 624, 629
portal authorization strict-checking mode peer host public key, 353, 354
(interface), 224 SSH client host public key, 481
remote route-based SAVA entry creation, 659 escape critical VSI
SAVA, 659 port security escape feature enable, 310
SAVI, 608 ESP
IPsec security protocol 50, 399

698
establishing SSH SCP+password authentication, 529
IPv4 Secure Telnet server connection, 487 SSH SFTP, 494
IPv4 SFTP server connection, 491 filtering
IPv6 Secure Telnet server connection, 488 ARP packet filtering configuration, 590, 591
IPv6 SFTP server connection, 492 SAVA configuration, 656
SSH IPv4 SCP server connection, 497 fingerprint
SSH IPv6 SCP server connection, 498 root CA certificate, 359
SSH SCP server connection, 497 FIPS
SSH SCP server connection (Suite B), 499 configuration, 622, 628
SSH Secure Telnet server connection, 487 configuration restrictions, 623
SSH Secure Telnet server connection (Suite display, 628
B), 489 mode entry, 624
SSH SFTP server connection, 491 mode entry (automatic reboot), 628
SSH SFTP server connection (Suite B), 493 mode entry (manual reboot), 629
Ethernet mode exit, 627
802.1X overview, 99 mode exit (automatic reboot), 631
ARP attack protection configuration, 567 mode exit (manual reboot), 631
excluding mode system changes, 624
IPSG IPv4 packets from filtering, 555 self-test, 622
exiting self-test trigger, 626
FIPS mode (automatic reboot), 627, 631 FIPS compliance
FIPS mode (manual reboot), 627, 631 AAA, 15
exporting IPsec, 405
host public key, 351 IPsec IKE, 441
PKI certificate, 374 password control, 332
PKI certificate import/export configuration, PKI, 361
388 public key, 349
troubleshooting PKI certificate export failure, SSH, 477
397
SSL, 543
extending
FIPS functionality, 622
extended cross-subnet portal authentication
fixed ARP
configuration, 255
ARP scanning+fixed ARP configuration, 587
extended direct portal authentication
configuration, 248 forcibly sending
extended re-DHCP portal authentication AAA RADIUS stop-accounting packet forcibly
configuration, 251 sending, 38
format
F
802.1X EAP packet format, 101
fail 802.1X EAPOL packet format, 101
portal fail-permit feature, 226 802.1X packet, 101
failing AAA HWTACACS username, 49
portal authentication fail-permit feature, 226 AAA RADIUS Called-Station-Id attribute format,
Federal Information Processing Standard. Use 33
FIPS AAA RADIUS Called-Station-Id attribute MAC
file address format, 34
portal authentication file name rules, 214 AAA RADIUS Calling-Station-Id attribute MAC
SFTP directory file display, 493, 494 address format, 34
SFTP file deletion, 494 AAA RADIUS packet format, 4
SFTP file download+local save, 494 AAA RADIUS username, 30
SFTP file name change, 494 portal authentication NAS-Port-Id attribute format,
SFTP local file upload, 494 231
SSH SCP+Linux client, 531 forwarding

699
 ARP attack detection restricted forwarding, SSH SFTP outgoing packet source IP address,
580 490
ARP attack protection restricted forwarding SSH SFTP server configuration (password
configuration, 586 authentication), 520
DHCP relay agent-based dynamic IPv4SG SSH SFTP server connection establishment, 491
configuration, 562 SSH SFTP server connection termination, 495
DHCP snooping-based dynamic IPv4SG Fully Qualified Domain Name. Use FQDN
configuration (wired network), 561 function
DHCPv6 relay agent-based dynamic IPv6SG portal authentication extended functions, 203
configuration, 565
DHCPv6 snooping-based dynamic IPv6SG G
address binding configuration (wired network), gateway
563 ARP gateway protection, 589, 589
DHCPv6 snooping-based dynamic IPv6SG IPsec RRI, 404
prefix binding configuration (wired network),
MFF default gateway, 616
564
MFF periodic gateway probe, 618
IPSG configuration (wired network), 551, 553,
560 generating
IPv6 ND attack defense configuration, 595 Secure Telnet client local key pair, 486
IPv6 ND attack defense RA guard SSH SCP client local key pair, 496
configuration, 601, 603 SSH server local key pair, 478
IPv6 ND attack detection configuration, 599 SSH SFTP client local key pair, 490
static IPv4SG configuration (wired network), global
560 IPsec IKE global identity information, 447
static IPv6SG configuration (wired network), global parameter
563 IPsec IKEv2 global parameters, 470
fragment group
attack D&P TCP fragment attack prevention, MACsec group CAK, 634
548 guest VLAN
IPsec packet DF bit, 419 802.1X authentication, 109
fragmenting 802.1X authentication (MAC-based access
IPsec packet fragmentation, 422 control), 110
frame 802.1X authentication (port-based access
port security configuration, 295, 299 control), 109
framework 802.1X configuration, 126, 147
IPsec, 399 802.1X guest VLAN assignment delay, 127
freezing MAC authentication, 163
802.1X user IP freezing enable, 140 MAC authentication configuration, 177
FTP MAC authentication guest VLAN reauthentication,
AAA RADIUS Login-Service attribute check 177
method, 32 MAC authentication port, 177
local host public key distribution, 351 guest VSI
SFTP server public key deletion, 492 802.1X authentication, 114
SSH SCP server connection establishment, 802.1X authentication guest VSI+authorization
497 VSI configuration (MAC-based), 151
SSH SFTP client configuration (publickey 802.1X configuration, 130
authentication), 522 MAC authentication, 166
SSH SFTP client device, 489 MAC authentication configuration, 180
SSH SFTP configuration, 520 MAC authentication guest VSI reauthentication,
SSH SFTP configuration (192-bit Suite B 180
algorithm), 525 MAC authentication port, 180
SSH SFTP directories, 493
H
SSH SFTP files, 494

700
handshaking SSH user local authentication+HWTACACS
802.1X online user handshake, 137 authorization+RADIUS accounting, 71
SSL handshake protocol, 542 stop-accounting packet buffering, 50
hardware timer set), 47
crypto engine configuration, 633 traffic statistics units, 49
history troubleshooting, 89
password history, 330 username format, 49
host Hypertext Transfer Protocol. Use HTTP
local host public key distribution, 351 I
peer host public key configuration, 352
ID
peer host public key entry, 353, 354
AAA device ID configuration, 63
peer host public key import from file, 353
portal authentication access device ID, 230
public key display, 352
identifying
public key export, 351
802.1X client anonymous identifier, 654
SSH client host public key configuration, 480
identity
HTTP
IPsec IKE global identity information, 447
portal URL redirection match rules, 213
ignoring
SSL configuration, 542, 543
ARP attack detection user validity check ingress
HTTPS port, 581
portal URL redirection match rules, 213 Ignoring
HW Terminal Access Controller Access Control ingress ports of ND packets, 598
System. Use HWTACACS
ignoring
HWTACACS
port security server authorization information, 305
AAA configuration, 1, 15, 69
IKE, 438, See also ISAKMP
AAA for SSH user, 69
benefit, 438
AAA implementation, 5
configuration, 438, 451
AAA local user configuration, 16
configuration (main mode+preshared key
AAA VPN implementation, 13 authentication), 451
accounting server, 45 DH algorithm, 440
authentication server, 44 display, 451
authorization server, 45 FIPS compliance, 441
configuration, 43 global DPD configuration, 449
connection recording policy, 66 global identity information, 447
display, 50 identity authentication, 440
HWTACACS/RADIUS differences, 5 IKE-based IPsec tunnel for IPv4 packets, 427
maintain, 50 invalid SPI recovery, 449
outgoing packet source interface (all IPsec negotiation mode, 401
schemes), 49
IPsec policy (IKE-based/direct), 413
outgoing packet source interface (single
IPsec policy (IKE-based/template), 414
scheme), 49
IPsec policy configuration (IKE-based), 412
outgoing packet source IP address, 48
IPsec SA, 401
outgoing packet source IP address (all
schemes), 49 IPsec tunnel configuration for IPv4 packets
(IKE-based), 454
outgoing packet source IP address (single
scheme), 49 keepalive configuration, 448
packet exchange process, 6 keychain configuration, 446
protocols and standards, 14 maintain, 451
scheme creation, 44 NAT keepalive configuration, 448
scheme VPN instance, 47 negotiation, 438
shared keys, 46 PFS, 440
prerequisites, 441

701
 profile configuration, 442 IMC
profile creation, 442, 463 AAA RADIUS session-control, 40
proposal configuration, 445 implementing
protocols and standards, 440 802.1X MAC-based access control, 106
SA max, 450 802.1X port-based access control, 106
security mechanism, 440 AAA for VPNs, 13
SNMP notification, 450 AAA HWTACACS, 5
troubleshoot, 456 AAA LDAP, 8
troubleshoot negotiation failure (no proposal AAA RADIUS, 2
match), 456 IPsec (ACL-based), 405
troubleshoot negotiation failure (no proposal IPsec ACL-based implementation, 402
or keychain specified correctly), 457 IPsec IPv6 routing protocol-based
IKE and IPsec implementation, 403
relationship, 438 importing
IKE profile peer host public key from file, 353
IKE keychain configuration, 442 PKI certificate import/export configuration, 388
IKE phase 1 negotiation mode configuration, public key from file, 356
443 SSH client host public key, 481
IKE proposals configuration, 443 troubleshooting PKI CA certificate import failure,
inside VPN instance configuration, 444 396
local ID configuration, 444 troubleshooting PKI local certificate import failure,
optional features configuration, 444 397
peer ID configuration, 442 including
PKI domain configuration, 442 AAA ISP domain idle timeout period in user online
IKEv2, 461, See also ISAKMP duration, 58
configuration, 461 AAA RADIUS subattribute 218 of vendor 25506 in
cookie challenge, 462, 470 RADIUS packets, 35
DH guessing, 462 MAC authentication request user IP address, 186
display, 471 initiating
DPD configuration, 470 802.1X authentication, 103, 105
global parameter configuration, 470 injecting
keychain configuration, 469 IPsec RRI, 404
maintain, 471 IPsec RRI configuration, 419
message retransmission, 462 interface
NAT keepalive, 471 802.1X client anonymous identifier configuration,
654
negotiation, 461
802.1X client EAP authentication method, 653
policy configuration, 467
802.1X client username+password configuration,
profile configuration, 463
652
proposal configuration, 468
Internet
protocols and standards, 462
Internet Key Exchange. Use IKE
SA rekeying, 462
Internet Key Exchange version 2. Use IKEv2
troubleshoot, 472
SSL configuration, 542, 543
troubleshoot negotiation failure (no proposal
interpreting
match), 472
AAA RADIUS class attribute as CAR parameter,
IKEv2 profile
33
IKE keychain configuration, 464
interval
inside VPN instance configuration, 466
SSH update interval for RSA server key pair, 483
local ID configuration, 464
intrusion detection/protection
optional features configuration, 466
port security blockmac mode, 304
peer ID configuration, 465
port security disableport mode, 304
PKI domain configuration, 464

702
 port security disableport-temporarily mode, SSH SCP outgoing packet source IP address,
304 496
port security feature, 295 SSH Secure Telnet outgoing packet source IP
IP address, 486
portal authentication portal-free rule, 220 SSH SFTP outgoing packet source IP address,
security. Use IPsec 490
IP addressing uRPF configuration, 606
802.1X authenticated user dynamic IPSG IP source guard (IPSG)
binding entry generation enable, 140 configuration (wired network), 551, 553, 560
802.1X user IP freezing enable, 140 display (wired network), 559
AAA HWTACACS outgoing packet source dynamic binding (wired network), 552
interface (all schemes), 49 IPv4. See IPv4 source guard
AAA HWTACACS outgoing packet source IPv4 packet filtering exclusion, 555
interface (single scheme), 49 IPv6. See IPv6 source guard
AAA HWTACACS outgoing packet source IP operating mechanism (wired network), 551
address, 48 SAVI configuration, 609
AAA HWTACACS outgoing packet source IP IPoE
address (all schemes), 49
user profile configuration, 323
AAA HWTACACS outgoing packet source IP
IPsec
address (single scheme), 49
ACL configuration, 406
AAA LDAP server IP address, 51
ACL de-encapsulated packet check, 416
AAA RADIUS outgoing packet source
interface (all schemes), 30 ACL rule keywords, 406
AAA RADIUS outgoing packet source ACL-based implementation, 405
interface (single scheme), 30 ACL-based IPsec, 402
AAA RADIUS outgoing packet source IP anti-replay configuration, 416
address, 29 anti-replay redundancy, 417
AAA RADIUS outgoing packet source IP authentication, 401
address (all schemes), 30 authentication algorithms, 401
AAA RADIUS outgoing packet source IP benefit, 399
address (single scheme), 30 configuration, 399, 425
ARP attack detection ip validity check, 579 display, 424
ARP attack protection (unresolvable IP attack), encryption, 401
567, 569
encryption algorithms, 402
ARP attack protection configuration, 567
FIPS compliance, 405
ARP attack protection configuration
fragmentation configuration, 422
(user+packet validity check), 584
framework, 399
ARP attack protection restricted forwarding
configuration, 586 global IKE DPD, 449
ARP attack protection user validity check, 583 global IPsec SA lifetime and idle timeout
configuration, 422
ARP filtering configuration, 591
IKE configuration, 438, 451
ARP gateway protection, 589
IKE configuration (main mode+preshared key
ARP scanning+fixed ARP configuration, 587
authentication), 451
ARP sender IP address checking, 592, 592
IKE global identity information, 447
authorized ARP configuration (DHCP relay
IKE identity authentication, 440
agent), 575
IKE invalid SPI recovery, 449
authorized ARP configuration (DHCP server),
574 IKE keepalive, 448
MAC authentication request user IP address, IKE keychain configuration, 446
186 IKE NAT keepalive, 448
MFF server IP address, 618 IKE negotiation, 438
portal user preauthentication IP address pool, IKE negotiation mode, 401
218 IKE profile configuration, 442

703
IKE proposal, 445 troubleshoot IKEv2 negotiation failure (no
IKE SA max, 450 proposal match), 472
IKE security mechanism, 440 troubleshoot SA negotiation failure (invalid
IKE SNMP notification, 450 identity info), 458
IKE-based IPsec tunnel for IPv4 packets, 427 troubleshoot SA negotiation failure (no transform
set match), 458, 472
IKEv2 configuration, 461
troubleshoot SA negotiation failure (tunnel failure),
IKEv2 cookie challenge, 470
473
IKEv2 DPD configuration, 470
tunnel configuration for IPv4 packets (IKE-based),
IKEv2 global parameters, 470 454
IKEv2 keychain configuration, 469 tunnel for IPv4 packets (manual), 425
IKEv2 NAT keepalive, 471 tunnel max, 423
IKEv2 negotiation, 461 IPSG
IKEv2 policy configuration, 467 802.1X authenticated user dynamic IPSG binding
IKEv2 profile configuration, 463 entry generation enable, 140
IKEv2 proposal configuration, 468 IPv4
IPsec policy, 403 IKE-based IPsec tunnel for IPv4 packets, 427
IPsec profile, 403 IPsec tunnel configuration for IPv4 packets
IPv6 routing protocol-based IPsec, 403 (IKE-based), 454
IPv6 routing protocols configuration, 420 IPsec tunnel for IPv4 packets (manual), 425
maintain, 424 portal authentication enable (interface), 216
mirror image ACLs, 407 portal authentication support for IPv4/IPv6 dual
non-mirror image ACLs, 407 stack, 217
packet DF bit configuration, 419 portal authentication Web server (interface), 217
packet logging enable, 423 remote portal authentication server, 211
PKI configuration, 359, 361, 376 Secure Telnet server connection establishment,
policy application to interface, 415 487
policy configuration (IKE-based), 412 SFTP server connection establishment, 491
policy configuration (IKE-based/direct), 413 source guard. See IPv4 source guard
policy configuration (IKE-based/template), SSH SCP client device, 495
414 SSH SCP server connection establishment, 497,
policy configuration (manual), 411 497
policy configuration restrictions, 411 SSH SCP server connection establishment (Suite
B), 499
policy configuration restrictions (IKE-based),
412 SSH Secure Telnet server connection
establishment, 487
protected traffic, 402
SSH Secure Telnet server connection
protocols and standards, 405 establishment (Suite B), 489
QoS pre-classify enable, 418 SSH SFTP server connection establishment, 491
RIPng configuration, 430 SSH SFTP server connection establishment
RRI, 404 (Suite B), 493
RRI configuration, 419, 433 IPv4 source guard (IPv4SG)
SA, 401 configuration (wired network), 551, 553, 553, 560
security services, 399 DHCP relay agent-based dynamic configuration,
SNMP notification configuration, 423 562
source interface policy bind, 417 DHCP snooping-based dynamic configuration
transform set configuration, 408 (wired network), 561
troubleshoot IKE, 456 display (wired network), 559
troubleshoot IKE negotiation failure (no enable (wired network), 553
proposal match), 456 interface enable restrictions (wired network), 553
troubleshoot IKE negotiation failure (no static binding configuration (wired network), 554
proposal or keychain specified correctly), 457 static binding configuration restrictions (wired
troubleshoot IKEv2, 472 network), 554

704
 static configuration (wired network), 560 configuration restrictions, 597
IPv4SG alarming IPv6 routing protocol
interface enable (wired network), 556 IPsec IPv6 routing protocol-based
IPv6 implementation, 403
IPsec IPv6 routing protocol profile (manual), IPv6 source guard (IPv6SG)
420 binding max (interface), 558
ND attack defense. See IPv6 ND attack configuration (wired network), 551, 553, 556, 560
defense DHCPv6 relay agent-based dynamic
portal authentication enable (interface), 216 configuration, 565
portal authentication support for IPv4/IPv6 DHCPv6 snooping-based dynamic address
dual stack, 217 binding configuration (wired network), 563
portal authentication Web server (interface), DHCPv6 snooping-based dynamic prefix binding
217 configuration (wired network), 564
remote portal authentication server, 211 display (wired network), 559
SAVA configuration, 656, 658 enable (wired network), 556
SAVI configuration, 608, 608, 610 interface enable restrictions (wired network), 556
SAVI configuration (DHCPv6+SLAAC), 613 static binding configuration (wired network), 557
SAVI configuration (DHCPv6-only), 610 static binding configuration restrictions (wired
SAVI configuration (SLAAC-only), 612 network), 557
Secure Telnet server connection static configuration (wired network), 563
establishment, 488 IPv6SG alarming
SFTP server connection establishment, 492 interface enable (wired network), 558
source guard. See IPv6 source guard IRF compatibility, 624
SSH SCP client device, 495 ISAKAMP
SSH SCP server connection establishment, protocols and standards, 440, 462
497, 498 ISAKMP, 438, 461, See also IKE
SSH SCP server connection establishment IPsec IKE configuration, 438, 451
(Suite B), 499 IPsec IKE configuration (main mode+preshared
SSH Secure Telnet server connection key authentication), 451
establishment, 487 IPsec IKEv2 configuration, 461
SSH Secure Telnet server connection ISP
establishment (Suite B), 489
AAA ISP domain accounting method, 61
SSH SFTP server connection establishment,
AAA ISP domain attribute, 57
491
AAA ISP domain authentication method, 59
SSH SFTP server connection establishment
(Suite B), 493 AAA ISP domain authorization attribute, 57
IPv6 ND attack defense AAA ISP domain authorization method, 60
attack detection configuration, 599 AAA ISP domain creation, 56
attack detection display, 599 AAA ISP domain idle timeout period include in
user online duration, 58
attack detection maintain, 599
AAA ISP domain method, 59
configuration, 595
AAA ISP domain status, 57
configuring ND attack detection, 596
default ISP domain specifying, 57
device role, 601
ISP domain creation, 56
device role restrictions, 601
ISP domain specifying for users that are assigned
RA guard configuration, 601, 603
to nonexistent domains, 57
RA guard display, 603
RA guard logging enable, 603 K
RA guard maintain, 603 keepalive
RA guard policy application, 602 IPsec IKE configuration, 448
RA guard policy configuration, 602 IPsec IKE NAT configuration, 448
source MAC consistency check, 596 IPsec IKEv2 NAT, 471
IPv6 ND attack detection key

705
 IPsec IKE preshared key authentication, 440 AAA configuration, 1, 15, 69
MACsec MKA key server priority, 640 AAA implementation, 8
MACsec preshared key, 639 AAA local user configuration, 16
PKI configuration, 359, 361, 376 administrator attribute, 52
SSH algorithm renegotiation+key attribute map, 54
re-exchange, 483 attribute map for authorization, 55
key pair authentication, 8
Secure Telnet client server key pair, 486 authentication process, 9
SSH SCP client server key pair, 496 authentication server, 55
SSH server local key pair generation, 478 authorization, 8
SSH SFTP client server key pair, 490 authorization process, 10
keychain authorization server, 55
configuration, 342, 342, 343, 343 configuration, 51
display, 343 directory service, 8
IPsec IKE keychain configuration, 446 display, 55
IPsec IKEv2 keychain configuration, 469 protocols and standards, 14
troubleshooting IPsec IKE negotiation failure scheme creation, 54
(no keychain specified correctly), 457 server creation, 51
keyword server IP address, 51
IPsec ACL rule keywords, 406 server SSH user authentication, 76
L server timeout period, 52
LAN troubleshooting authentication failure, 89
802.1X overview, 99 user attribute, 53
configuring SAVA on border devices versions, 52
direcindirectly connected the LAN (IPv6 IS-IS) life time
(on switch), 666 MACsec MKA life time, 640
configuring SAVA on border devices Lightweight Directory Access Protocol. Use LDAP
direcindirectly connected the LAN (OSPFv3) limiting
(on switch), 662 ARP packet rate limit, 570
configuring SAVA on border devices directly port security MAC address limit per port VLAN,
connected the LAN (on switch), 661 307
configuring SAVA on inter-AS border devices port security secure MAC addresses, 301
directly connected the LAN (on switch), 670
Linux
MACsec configuration, 634, 638, 644
SSH SCP+Linux client, 531
MACsec configuration (client-oriented), 644
load sharing
MACsec configuration (device-oriented), 646
AAA RADIUS server load sharing, 38
Layer 2
local
IPv6 ND attack defense RA guard
802.1X authorization VLAN, 106
configuration, 601, 603
802.1X authorization VSI, 114
MFF configuration, 615, 616, 619
802.1X VLAN authorization, 107
MFF configuration (in ring network), 620
AAA local accounting method, 11
MFF configuration (in tree network), 619
AAA local authentication, 11
Layer 3
AAA local authentication configuration, 15
IKE-based IPsec tunnel for IPv4 packets, 427
AAA local authorization method, 11
IPsec configuration, 399, 425
AAA local user, 16
IPsec RIPng configuration, 430
AAA SSH user local authentication+HWTACACS
IPsec RRI configuration, 419, 433
authorization+RADIUS accounting, 71
IPsec tunnel configuration for IPv4 packets
host public key distribution, 351
(IKE-based), 454
key pair creation, 350
IPsec tunnel for IPv4 packets (manual), 425
key pair destruction, 354
LDAP
local portal Web service, 205

706
 MAC authentication (local), 192 M
MAC authentication method, 160 MAC
password control parameters (local user), 336 802.1X MAC-based access control, 106
PKI digital certificate, 359 address. See MAC addressing
portal authentication local portal Web service authentication. See MAC authentication
parameter configuration, 216
RADIUS Called-Station-Id attribute format, 33, 34
troubleshooting PKI certificate obtain failure,
RADIUS Calling-Station-Id attribute format, 34
394
security. Use MACsec
troubleshooting PKI certificate request failure,
395 SSL services, 542
troubleshooting PKI local certificate import triple authentication configuration, 283, 285, 285
failure, 397 user profile configuration, 324
local portal Web service MAC address
local portal Web service page customization, 802.1X authentication (client-initiated), 105
205 MAC addressing
system components, 205 802.1X authentication (access device initiated),
local VLAN 105
MAC authentication local VLAN authorization, 802.1X Auth-Fail VLAN (MAC-based access
162 control), 111
log 802.1X client MAC address, 653
SAVI packet spoofing logging and filtering 802.1X critical VLAN (MAC-based access control),
entry logging, 610 112
logging 802.1X critical voice VLAN (MAC-based access
802.1X user logging enable, 144 control), 113
AAA password change prompt logging 802.1X guest VLAN (MAC-based access control),
configuration, 64 110
ARP attack detection logging enable, 582 802.1X MAC address binding, 141
enabling logging for portal user login/logout, ARP attack detection (source MAC-based), 571,
233 572
IPsec packet logging enable, 423 ARP attack protection configuration, 567
MAC authentication user logging enable, 190 ARP packet source MAC consistency check, 573
MACsec MKA session logging enable, 643 ARP scanning+fixed ARP configuration, 587
password events, 331 DHCP relay agent-based dynamic IPv4SG
configuration, 562
port security user logging enable, 311
DHCP snooping-based dynamic IPv4SG
SAVA logging configuraiton, 660
configuration (wired network), 561
logging in
DHCPv6 relay agent-based dynamic IPv6SG
AAA concurrent login user max, 62 configuration, 565
attack D&P login delay, 549 DHCPv6 snooping-based dynamic IPv6SG
attack D&P login dictionary attack, 548 address binding configuration (wired network),
password control blacklist, 330 563
password expired login, 330 DHCPv6 snooping-based dynamic IPv6SG prefix
password user first login, 330 binding configuration (wired network), 564
password user login attempt limit, 331 IPSG configuration (wired network), 551, 553,
password user login control, 330 560
RADIUS Login-Service attribute, 32 MAC authentication, 171, 192
user login with weak password, 331 MAC authentication (local), 192
logging off MAC authentication (RADIUS-based), 194
802.1X user, 143 MAC authentication blackhole attribute
assignment, 169
MAC authentication user, 190
MAC authentication configuration, 159
logging out
MFF configuration, 615, 616, 619
portal authentication online user logout, 232
MFF configuration (in ring network), 620

707
 MFF configuration (in tree network), 619 guest VSI, 166
port security client guest VSI configuration, 180
macAddressElseUserLoginSecure guest VSI configuration restrictions, 180
configuration, 317 guest VSI reauthentication, 180
port security dynamic secure MAC, 303 local authentication, 192
port security MAC address autoLearn local VLAN authorization, 162
configuration, 312
logging off user, 190
port security MAC address limit per port VLAN,
maintain, 191
307
methods, 160
port security macAddressWithRadius, 297
multi-VLAN mode configuration, 185
port security secure MAC address, 302
offline detection configuration, 182
port security secure MAC address add, 303
online user synchronization enable, 183
port security secure MAC address inactivity
aging, 303 parallel MAC authentication+802.1X
authentication, 187
port security secure MAC address port limit,
301 parallel MAC authentication+802.1X
authentication restrictions, 188
static IPv4SG configuration (wired network),
560 periodic reauthentication, 169, 176
static IPv6SG configuration (wired network), periodic reauthentication restrictions, 176
563 port guest VLAN, 177
troubleshooting port security secure MAC port guest VSI, 180
addresses, 322 port security authentication control mode, 295
MAC authentication port security client
ACL assignment, 167, 196 macAddressElseUserLoginSecure configuration,
authentication method, 173 317
authorization VLAN, 161 port security client userLoginWithOUI
configuration, 314
authorization VLAN port manipulation, 162
port security configuration, 295, 299, 312
authorization VSI, 166
port security free VLAN, 308
authorization VSI assignment, 199
port security MAC address autoLearn
blackhole MAC attribute assignment, 169
configuration, 312
CAR attribute assignment, 169
port security MAC move, 305
concurrent port users max, 184
port security MAC+802.1X authentication, 297
configuration, 159, 171, 192
port security mode, 300
configuration restrictions, 171
port security open authentication, 307
critical VLAN, 164
RADIUS-based, 194
critical VLAN configuration, 178
redirect URL assignment, 169
critical VLAN configuration restrictions, 178
remote VLAN authorization, 161
critical voice VLAN, 165
request user IP address, 186
critical voice VLAN enable, 179
request user IP address inclusion restrictions, 186
critical VSI, 167
RESTful server-assisted user recovery, 170
critical VSI configuration, 181
RESTful server-assisted user recovery
critical VSI configuration restrictions, 181 configuration, 188
delay configuration, 185 timer configuration, 175
delay configuration restrictions, 185 unauthenticated user aging, 182
display, 191 user account policies, 159
domain specification, 173 user account policy, 174
enable, 172 user logging configuration restrictions, 190
enable restrictions, 172 user logging enable, 190
guest VLAN, 163 user profile assignment, 168
guest VLAN configuration, 177 VLAN assignment, 161
guest VLAN configuration restrictions, 177 VSI manipulation, 165
guest VLAN reauthentication, 177

708
 VXLAN support, 165 IPsec IKEv2, 471
Web proxy port URL redirection configuration, IPv6 ND attack defense RA guard, 603
189 IPv6 ND attack detection, 599
MAC learning MAC authentication, 191
port security autoLearn MAC learning control, MACsec, 643
296 password control, 338
port security MAC learning control modes, 295 portal authentication, 234
port security secure MAC learning control, 296 SAVA, 661
MAC-forced forwarding. Use MFF managing
MACsec public key, 349, 354
application mode, 635 manipulating
basic concepts, 634 MAC authentication VSI manipulation, 165
client-oriented configuration, 644 manual
configuration, 634, 638, 644 FIPS mode (manual reboot), 624
data encryption, 635 FIPS mode entry (manual reboot), 629
desire enable, 639 FIPS mode exit (manual reboot), 627, 631
device-oriented configuration, 646 IPsec IPv6 routing protocol profile (manual), 420
display, 643 Media Access Control Security. Use MACsec
hardware compatibility restrictions, 638 message
integrity check, 635 ARP attack protection configuration, 567
maintain, 643 IPsec IKEv2 message retransmission, 462
MKA enable, 638 Message Authentication Code. Use MAC
MKA key server priority configuration, 640 MFF
MKA key server priority configuration ARP packet processing, 616
restrictions, 640
configuration, 615, 616, 619
MKA life time configuration, 640
configuration (in ring network), 620
MKA session logging enable, 643
configuration (in tree network), 619
MKA session logging enable restrictions, 643
default gateway, 616
operation (client-oriented), 636
display, 618
operation (device-oriented), 636
enable, 617
preshared key configuration, 639
enable restrictions, 617
preshared key configuration restrictions, 639
network model, 615
protection parameter configuration, 640
network port, 616
protection parameter configuration restrictions,
network port configuration, 617
641
periodic gateway probe enable, 618
protection parameter configuration restrictions
(MKA policy), 642 port roles, 615
protocols and standards, 637 protocols and standards, 616
replay protection, 635 server IP address, 618
services, 635 user port, 615
troubleshoot, 650 minimum password length, 328
troubleshoot device cannot establish MKA mirroring
session, 650 IPsec mirror image ACLs, 407
maintaining IPsec non-mirror image ACLs, 407
802.1X, 144 MKA
AAA HWTACACS, 50 MACsec enable, 638
AAA RADIUS, 43 MACsec MKA key server priority, 640
ARP attack detection, 583 MACsec MKA life time, 640
crypto engine, 633 MACsec MKA session logging enable, 643
IPsec, 424 MACsec protection parameters, 640
IPsec IKE, 451

709
 troubleshooting MACsec device cannot port security userLoginSecure 802.1X
establish MKA session, 650 authentication, 297
mode port security userLoginSecureExt 802.1X
802.1X multicast trigger, 105, 135 authentication, 297
802.1X unicast trigger, 105, 135 port security userLoginWithOUI 802.1X
global IPsec IKE DPD periodic, 449 authentication, 297
IKEv2 DPD on-demand, 470 portal authentication, 205
IKEv2 DPD periodic, 470 portal authentication (cross-subnet), 206
IPsec ACL-based implementation aggregation, portal authentication (direct), 205
402 portal authentication (re-DHCP), 206
IPsec ACL-based implementation per-host, troubleshooting port security mode cannot be set,
402 321
IPsec ACL-based implementation standard, uRPF loose check, 606
402 uRPF strict check, 606
IPsec encapsulation transport, 400 MPLS L3VPN
IPsec encapsulation tunnel, 400 AAA RADIUS device server feature, 13
IPsec IKE negotiation, 401 multicast
IPsec IKE negotiation (time-based lifetime), 802.1X multicast trigger mode, 105, 135
401 port security NTK configuration, 304
IPsec IKE negotiation (traffic-based lifetime),
N
401
IPsec IPv6 routing protocol-based naming
implementation, 403 SFTP directory name change, 493
MAC authentication multi-VLAN, 185 SFTP file name change, 494
MACsec application client-oriented, 635 Naptha
MACsec application device-oriented, 635 TCP attack prevention (Naptha attack), 550
PKI offline, 368 NAS
PKI online, 368 AAA configuration, 15
port security, 300 AAA HWTACACS implementation, 5
port security authentication control, 295 AAA LDAP implementation, 8
port security autoLearn MAC learning control, AAA NAS-ID configuration, 63
296 AAA RADIUS implementation, 2
port security intrusion protection blockmac, AAA VPN implementation, 13
304 port security NAS-ID profile, 309
port security intrusion protection disableport, portal authentication interface NAS-ID profile
304 (RADIUS), 232
port security intrusion protection portal authentication NAS-Port-Id attribute format,
disableport-temporarily, 304 231
port security MAC learning control, 295 NAT
port security MAC learning control autoLearn, IPsec IKE keepalive, 448
295
IPsec IKEv2 keepalive, 471
port security MAC learning control secure, 295
ND
port security macAddressWithRadius
portal authentication client Rule ND entry feature,
authentication, 297
233
port security NTK ntkonly, 304
ND attack defense
port security NTK ntk-withbroadcasts, 304
IPv6. See IPv6 ND attack defense
port security NTK ntk-withmulticasts, 304
ND attack detection
port security open authentication, 307
configuration (VLAN), 597
port security secure MAC learning control, 296
configuration (VSI), 598
port security userLogin 802.1X authentication,
ignoring ND packet ingress port, 598
297
ND attack detection logging
enabling, 599

710
ND snooping 802.1X critical voice VLAN, 113, 130
SAVI deletion delay, 609 802.1X critical VSI, 115, 132
need to know. Use NTK 802.1X duplicate EAPOL-Start request discarding,
negotiating 136
IPsec IKE negotiation, 438 802.1X EAD assistant, 142
IPsec IKE negotiation mode, 401 802.1X EAP over RADIUS, 102
IPsec IKEv2 negotiation, 461 802.1X EAP relay, 100
neighbor discovery (ND) 802.1X EAP relay authentication, 103
IPv6 ND attack defense configuration, 595 802.1X EAP relay enable, 122
IPv6 ND attack defense source MAC 802.1X EAP relay/termination, 101
consistency check, 596 802.1X EAP termination, 100
IPv6 ND attack detection, 599 802.1X EAP termination enable, 122
SAVI ND parameters, 609 802.1X EAP termination mode authentication,
NETCONF 104
enable over SSH, 480 802.1X guest VLAN, 109, 126
enable over SSH restrictions, 480 802.1X guest VLAN assignment delay, 127
Secure Telnet client user line configuration, 802.1X guest VLAN configuration, 147
480 802.1X guest VSI, 114, 130
SSH application, 474 802.1X guest VSI assignment delay, 131
SSH client user line configuration, 480 802.1X MAC address binding, 141
SSH configuration, 539 802.1X MAC user authentication attempts max,
SSH+password authentication configuration, 139
539 802.1X online user handshake, 137
network 802.1X online user synchronization, 134
802.1X access control method, 123 802.1X packet exchange method, 100
802.1X architecture, 99 802.1X packet format, 101
802.1X authenticated user dynamic IPSG 802.1X reauthentication, 125
binding entry generation enable, 140 802.1X server-side EAP-TLS fragment maximum
802.1X authentication, 103 size, 143
802.1X authentication guest 802.1X unauthenticated user aging, 132
VSI+authorization VSI configuration 802.1X user IP freezing enable, 140
(MAC-based), 151 802.1X user logging enable, 144
802.1X authentication initiation, 105 802.1X VLAN manipulation, 106
802.1X authentication request attempts max, 802.1X VSI manipulation, 113
136
AAA device ID configuration, 63
802.1X authentication server timeout timer,
AAA EAP profile, 22
124
AAA HWTACACS, 43
802.1X authentication trigger, 135
AAA HWTACACS implementation, 5
802.1X authentication+ACL assignment
configuration, 149 AAA HWTACACS server SSH user, 69
802.1X authentication+EAD assistant AAA ISP domain accounting method, 61
configuration (DHCP relay agent), 153 AAA ISP domain attribute, 57
802.1X authentication+EAD assistant AAA ISP domain authentication method, 59
configuration (DHCP server), 156 AAA ISP domain authorization method, 60
802.1X Auth-Fail VLAN, 110, 128 AAA ISP domain creation, 56
802.1X Auth-Fail VSI, 115, 131 AAA ISP domain method, 59
802.1X authorization state, 123 AAA LDAP, 51
802.1X authorization VLAN configuration, 147 AAA LDAP implementation, 8
802.1X basic configuration, 145 AAA LDAP server SSH user authentication, 76
802.1X client enable, 651 AAA local user, 16
802.1X concurrent port users max, 136 AAA NAS-ID configuration, 63
802.1X critical VLAN, 111, 129 AAA network access user, 16

711
AAA password change prompt logging ARP scanning+fixed ARP configuration, 587
configuration, 64 ARP sender IP address checking, 592, 592
AAA RADIUS client configuration, 65 attack D&P device-preventable attacks, 548
AAA RADIUS configuration, 21 authorized ARP configuration, 574
AAA RADIUS device server feature, 13 authorized ARP configuration (DHCP relay agent),
AAA RADIUS implementation, 2 575
AAA RADIUS server 802.1X user, 79 authorized ARP configuration (DHCP server), 574
AAA RADIUS server 802.1X user captive-bypass feature enabling, 212
authentication+authorization, 86 cross-subnet portal authentication configuration,
AAA RADIUS server configuration, 64, 65 244
AAA RADIUS server SSH user DHCP relay agent-based dynamic IPv4SG
authentication+authorization, 73 configuration, 562
AAA SSH user local DHCP snooping-based dynamic IPv4SG
authentication+HWTACACS configuration (wired network), 561
authorization+RADIUS accounting, 71 DHCPv6 relay agent-based dynamic IPv6SG
AAA test, 67 configuration, 565
AAA VPN implementation, 13 DHCPv6 snooping-based dynamic IPv6SG
adding interface to SAVA access group, 660 address binding configuration (wired network),
allowing only DHCP users to pass portal 563
authorization, 225 DHCPv6 snooping-based dynamic IPv6SG prefix
ARP active acknowledgement, 573 binding configuration (wired network), 564
ARP attack detection (source MAC-based), digital certificate retrieval, usage, and
571, 572 maintenance, 361
ARP attack detection configuration, 577 FIPS mode entry (automatic reboot), 628
ARP attack detection configuration (VSI), 581 FIPS mode entry (manual reboot), 629
ARP attack detection logging enable, 582 FIPS mode exit (automatic reboot), 631
ARP attack detection packet validity check, FIPS mode exit (manual reboot), 631
579 IKE-based IPsec tunnel for IPv4 packets, 427
ARP attack detection packet validity check IPsec ACL, 406
(VSI), 582 IPsec ACL de-encapsulated packet check, 416
ARP attack detection restricted forwarding, IPsec ACL-based implementation, 402
580 IPsec anti-replay, 416
ARP attack detection user validity check, 577 IPsec anti-replay redundancy, 417
ARP attack detection user validity check (VSI), IPsec fragmentation, 422
581 IPsec IKE configuration (main mode+preshared
ARP attack detection user validity check key authentication), 451
ingress port, 581 IPsec IKE SNMP notification, 450
ARP attack protection (unresolvable IP attack), IPsec implementation (ACL-based), 405
567, 569
IPsec IPv6 routing protocol profile (manual), 420
ARP attack protection blackhole routing
IPsec IPv6 routing protocol-based
(unresolvable IP attack), 568
implementation, 403
ARP attack protection configuration
IPsec IPv6 routing protocols, 420
(user+packet validity check), 584
IPsec packet DF bit, 419
ARP attack protection restricted forwarding
configuration, 586 IPsec packet logging enable, 423
ARP attack protection source suppression IPsec policy (IKE-based/direct), 413
(unresolvable IP attack), 568 IPsec policy (IKE-based/template), 414
ARP attack protection user validity check, 583 IPsec policy application to interface, 415
ARP filtering configuration, 590, 591 IPsec policy configuration (IKE-based), 412
ARP gateway protection, 589, 589 IPsec policy configuration (manual), 411
ARP packet rate limit, 570 IPsec QoS pre-classify enable, 418
ARP packet source MAC consistency check, IPsec RIPng configuration, 430
573 IPsec RRI, 404

712
IPsec RRI configuration, 419, 433 MAC authentication concurrent port users max,
IPsec SNMP notification, 423 184
IPsec source interface policy bind, 417 MAC authentication critical VLAN, 164, 178
IPsec transform set configuration, 408 MAC authentication critical voice VLAN, 165, 179
IPsec tunnel configuration for IPv4 packets MAC authentication critical VSI, 167, 181
(IKE-based), 454 MAC authentication delay, 185
IPsec tunnel for IPv4 packets (manual), 425 MAC authentication domain, 173
IPsec-protected traffic, 402 MAC authentication guest VLAN, 163, 177
IPSG dynamic binding (wired network), 552 MAC authentication guest VLAN reauthentication,
IPSG IPv4 packet filtering exclusion, 555 177
IPSG static binding (wired network), 551 MAC authentication guest VSI, 166, 180
IPv4SG alarming enable (wired network), 556 MAC authentication guest VSI reauthentication,
IPv4SG configuration (wired network), 553 180
IPv4SG enable (wired network), 553 MAC authentication method, 173
IPv4SG static binding configuration (wired MAC authentication multi-VLAN mode, 185
network), 554 MAC authentication offline detection configuration,
IPv6 ND attack defense device role, 601 182
IPv6 ND attack defense RA guard MAC authentication online user synchronization,
configuration, 601, 603 183
IPv6 ND attack defense RA guard logging MAC authentication port guest VLAN, 177
enable, 603 MAC authentication port guest VSI, 180
IPv6 ND attack defense RA guard policy, 602 MAC authentication redirect URL assignment,
IPv6 ND attack defense source MAC 169
consistency check, 596 MAC authentication request user IP address, 186
IPv6 ND attack detection, 596 MAC authentication timer, 175
IPv6 ND attack detection (VLAN), 597 MAC authentication unauthenticated user aging,
IPv6 ND attack detection (VSI), 598 182
IPv6 source guard (IPv6SG) binding max MAC authentication user account policy, 174
(interface), 558 MAC authentication user logging enable, 190
IPv6SG alarming enable (wired network), 558 MAC authentication user profile assignment, 168
IPv6SG configuration (wired network), 556 MAC authentication VLAN assignment, 161
IPv6SG enable (wired network), 556 MAC authentication VSI manipulation, 165
IPv6SG static binding configuration (wired MACsec application mode, 635
network), 557 MACsec configuration (client-oriented), 644
local portal authentication service, 213 MACsec configuration (device-oriented), 646
local portal Web service, 205 MACsec desire enable, 639
logging off 802.1X user, 143 MACsec MKA enable, 638
logging off MAC authentication user, 190 MACsec MKA session logging enable, 643
MAC authentication (local), 192 MACsec preshared key, 639
MAC authentication (RADIUS-based), 194 MACsec services, 635
MAC authentication ACL assignment, 167, MFF configuration (in ring network), 620
196 MFF configuration (in tree network), 619
MAC authentication authorization VLAN, 161 MFF network model, 615
MAC authentication authorization VLAN port MFF network port, 616, 617
manipulation, 162 MFF periodic gateway probe, 618
MAC authentication authorization VSI, 166 MFF port roles, 615
MAC authentication authorization VSI ND attack detection ignoring ND packet ingress
assignment, 199 port, 598
MAC authentication blackhole attribute NETCONF-over-SSH client user line, 480
assignment, 169
NETCONF-over-SSH configuration, 539
MAC authentication CAR attribute assignment,
NETCONF-over-SSH enable, 480
169

713
NETCONF-over-SSH+password port security secure MAC address add, 303
authentication configuration, 539 port security secure MAC address port limit, 301
parallel MAC authentication+802.1X port security SNMP notification, 311
authentication, 187 port security user logging enable, 311
password control parameters (global), 333 portal authentication AAA server, 204
password control parameters (local user), 336 portal authentication BAS-IP, 230
password control parameters (super), 337 portal authentication client, 204
password control parameters (user group), portal authentication client Rule ARP entry
335 feature, 233
peer host public key entry, 354 portal authentication client Rule ND entry feature,
periodic 802.1X reauthentication, 118 233
periodic MAC reauthentication, 169, 176 portal authentication destination subnet, 222
PKI applications, 361 portal authentication detection, 226
PKI architecture, 360 portal authentication domain, 219
PKI CA policy, 360 portal authentication EAP support, 208
PKI certificate import/export configuration, portal authentication enable (interface), 216
388 portal authentication fail-permit, 226
PKI certificate request, 368 portal authentication filtering rules, 208
PKI CRL, 359 portal authentication interface NAS-ID profile, 232
PKI digital certificate, 359 portal authentication local portal Web service
PKI domain configuration, 363 parameter configuration, 216
PKI entity configuration, 362 portal authentication NAS-Port-Id attribute format,
PKI OpenCA server certificate request, 383 231
PKI RSA Keon CA server certificate request, portal authentication online user logout, 232
377 portal authentication portal-free rule, 220
PKI storage path, 367 portal authentication process, 206
PKI Windows 2003 CA server certificate portal authentication server detection, 227
request, 379 portal authentication source subnet, 221
PKI Windows 2003 CA server IKE portal authentication support for IPv4/IPv6 dual
negotiation+RSA digital signature, 386 stack, 217
port security authorization-fail-offline, 306 portal authentication system, 203
port security client portal authentication system component
macAddressElseUserLoginSecure interaction, 204
configuration, 317
portal authentication user access control, 220
port security client userLoginWithOUI
portal authentication user online detection, 226
configuration, 314
portal authentication user setting max, 223
port security dynamic secure MAC, 303
portal authentication Web redirect, 234
port security escape critical VSI, 310
portal authentication Web server (interface), 217
port security features, 295
portal authentication Web server detection, 228
port security functions, 295
portal packet attributes configuration, 230
port security intrusion protection, 304
portal URL redirection match rules configuration,
port security MAC address autoLearn
213
configuration, 312
portal user preauthentication IP address pool, 218
port security MAC address learning control,
296 portal Web server basic parameters, 212
port security MAC address limit per port VLAN, public key import from file, 356
307 RADIUS packet attributes configuration, 231
port security MAC move, 305 re-DHCP portal authentication configuration, 241
port security mode, 295, 300 remote entry-based SAVA entry creation enabling,
port security NAS-ID profile, 309 659
port security NTK, 304 remote portal authentication server, 211
port security secure MAC address, 302 remote portal authentication Web server, 212

714
RESTful server-assisted MAC authentication SSH SFTP client configuration (publickey
user recovery, 170 authentication), 522
SAVA application scenarios, 657 SSH SFTP client device, 489
SAVA logging configuration, 660 SSH SFTP configuration, 520
SAVI application scenarios, 608 SSH SFTP configuration (192-bit Suite B
SAVI configuration (DHCPv6+SLAAC), 613 algorithm), 525
SAVI configuration (DHCPv6-only), 610 SSH SFTP directories, 493
SAVI configuration (SLAAC-only), 612 SSH SFTP files, 494
SAVI deletion delay, 609 SSH SFTP outgoing packet source IP address,
SAVI DHCPv6 snooping configuration, 609 490
SAVI IP source guard configuration, 609 SSH SFTP server configuration (password
authentication), 520
SAVI ND parameters, 609
SSH SFTP server connection establishment, 491
SAVI packet spoofing logging and filtering
entry logging, 610 SSH SFTP server connection establishment
(Suite B), 493
Secure Telnet client user line, 480
SSH SFTP server connection termination, 495
SSH client host public key configuration, 480
SSH SFTP server enable, 479
SSH management parameters, 483
SSH user configuration, 482
SSH SCP client device, 495
SSH2 algorithms, 499
SSH SCP configuration, 529
SSH2 algorithms (encryption), 500
SSH SCP configuration (Suite B algorithm),
533 SSH2 algorithms (key exchange), 499
SSH SCP outgoing packet source IP address, SSH2 algorithms (MAC), 500
496 SSH2 algorithms (public key), 500
SSH SCP server connection establishment, SSL client configuration, 544
497 SSL client policy configuration, 545
SSH SCP server connection establishment SSL protocol stack, 542
(Suite B), 499 SSL server configuration, 543
SSH SCP server enable, 479 SSL server policy configuration, 544
SSH SCP+Linux client, 531 static IPv4SG configuration (wired network), 560
SSH SCP+password authentication, 529 static IPv6SG configuration (wired network), 563
SSH Secure Telnet client configuration TCP attack prevention (Naptha attack), 550
(password authentication), 510 triple authentication basic configuration, 285
SSH Secure Telnet client configuration triple authentication configuration (authorization
(publickey authentication), 514 VLAN+Auth-Fail VLAN), 289
SSH Secure Telnet client device, 486 uRPF application, 606
SSH Secure Telnet configuration, 501 uRPF application scenario, 606
SSH Secure Telnet configuration (128-bit uRPF check modes, 606
Suite B algorithm), 516
uRPF enable (global), 607
SSH Secure Telnet outgoing packet source IP
user profile+QoS policy configuration, 324
address, 486
Web authentication Auth-Fail VLAN, 277
SSH Secure Telnet server configuration
(password authentication), 502 Web authentication configuration (local
authentication server), 278
SSH Secure Telnet server configuration
(publickey authentication), 504 Web authentication configuration (RADIUS
authentication server), 280
SSH Secure Telnet server connection
establishment, 487 Web authentication domain, 275
SSH Secure Telnet server connection Web authentication enable, 274
establishment (Suite B), 489 Web authentication process, 271
SSH Secure Telnet server enable, 479 Web authentication proxy support, 277
SSH server configuration, 477 Web authentication server, 274
SSH server port, 478 Web authentication system components, 270
Web authentication user online detection, 276

715
 Web authentication user setting max, 276 port security SNMP notification, 311
Web authentication-free subnet, 276 NTK
network management ntkauto mode, 304, 304
802.1X authentication configuration, 145 ntkonly mode, 304
802.1X client configuration, 651, 651 ntk-withbroadcasts mode, 304
802.1X configuration, 120, 120 ntk-withmulticasts mode, 304
802.1X overview, 99 port security feature, 295
AAA configuration, 1, 15, 69 numbering
AAA HWTACACS/RADIUS differences, 5 IPsec IKE SA max, 450
ARP attack protection configuration, 567 IPsec tunnel max, 423
attack D&P configuration, 548 O
crypto engine configuration, 633
obtaining
FIPS configuration, 622, 628
PKI certificate, 371
IPsec configuration, 399, 425
offline
IPsec IKE configuration, 438, 451
MAC authentication offline detect, 175
IPsec IKEv2 configuration, 461
MAC authentication offline detection configuration,
IPSG configuration (wired network), 551, 553,
182
560
PKI offline mode, 368
IPv6 ND attack defense configuration, 595
port security authorization-fail-offline feature, 306
IPv6 ND attack detection configuration, 599
online
keychain configuration, 342, 342, 343, 343
802.1X online user handshake, 137
MAC authentication, 171, 192
PKI online mode, 368
MAC authentication configuration, 159
portal authentication user online detection, 226
MACsec configuration, 634, 638, 644
SSH online user max number, 485
MFF configuration, 615, 616, 619
Web authentication user online detection, 276
password control configuration, 328, 332, 338
OpenCA
PKI configuration, 359, 361, 376
PKI CA server certificate request, 383
port security configuration, 295, 299, 312
portal authentication configuration, 203, 209, P
209, 235 packet
public key management, 349, 354 802.1X Auth-Fail VLAN/VSI user EAP-Success
SAVA configuration, 656, 658 packet, 133
SAVI configuration, 608, 608, 610 802.1X client EAP-Response and EAPOL-Logoff
SSH configuration, 474 packet sending mode, 653
SSL configuration, 542, 543 802.1X critical VLAN/VSI user EAP-Success
SSL services, 542 packet, 134
TCP attack prevention configuration, 550 802.1X EAP format, 101
triple authentication configuration, 283, 285, 802.1X EAPOL format, 101
285 802.1X format, 101
uRPF configuration, 606 802.1X packet exchange method, 100
user profile configuration, 323, 324 802.1X protocol packet VLAN tag removal, 139
Web authentication configuration, 270, 273, AAA HWTACACS outgoing packet source IP
278, 278 address, 48
no AAA HWTACACS packet exchange process, 6
AAA no accounting method, 11 AAA RADIUS outgoing packet source IP address,
AAA no authentication, 11 29
AAA no authorization, 11 AAA RADIUS packet exchange process, 3
notifying AAA RADIUS packet format, 4
AAA RADIUS SNMP notification, 41 ARP active acknowledgement, 573
IPsec IKE SNMP notification, 450 ARP ARP sender IP address checking, 592
IPsec SNMP notification, 423 ARP attack detection packet validity check, 579

716
 ARP attack detection packet validity check IPv6 ND attack defense RA guard configuration,
(VSI), 582 601, 603
ARP attack protection (unresolvable IP attack), IPv6 ND attack detection configuration, 599
567, 569 static IPv4SG configuration (wired network), 560
ARP attack protection blackhole routing static IPv6SG configuration (wired network), 563
(unresolvable IP attack), 568 page
ARP attack protection configuration portal authentication authenticated user
(user+packet validity check), 584 redirection, 215
ARP attack protection source suppression portal authentication page file
(unresolvable IP attack), 568 compression+saving rules, 215
ARP filtering configuration, 590, 591 portal authentication page request rules, 214
ARP packet rate limit, 570 portal authentication post request rules, 214
ARP packet source MAC consistency check, pairwise CAK (MACsec), 634
573
PAP
ARP sender IP address checking, 592
MAC authentication method, 173
attack D&P TCP fragment attack prevention,
parallel
548
MAC authentication+802.1X authentication, 187
IPsec ACL de-encapsulated packet check,
416 parameter
IPsec anti-replay, 416 AAA RADIUS class attribute as CAR parameter,
33
IPsec packet DF bit, 419
configuring SSH management parameters, 483
IPsec packet fragmentation, 422
MACsec protection parameters, 640
IPsec packet logging enable, 423
password control parameters (global), 333
IPsec QoS pre-classify enable, 418
password control parameters (local user), 336
IPsec-protected traffic, 402
password control parameters (super), 337
MFF ARP packet processing, 616
password control parameters (user group), 335
portal authentication BAS-IP for portal packets,
230 SAVI ND parameters, 609
portal packet attributes configuration, 230 password
RADIUS packet attributes configuration, 231 SSH password authentication, 475
SAVA configuration, 658 SSH password-publickey authentication, 475
SAVI configuration, 608, 608, 610 SSH SCP+password authentication, 529
SAVI configuration (DHCPv6+SLAAC), 613 SSH Secure Telnet client configuration (password
authentication), 510
SAVI configuration (DHCPv6-only), 610
SSH Secure Telnet server configuration
SAVI configuration (SLAAC-only), 612
(password authentication), 502
uRPF configuration, 606
SSH SFTP server configuration (password
packet filtering authentication), 520
DHCP relay agent-based dynamic IPv4SG password control
configuration, 562
configuration, 328, 332, 338
DHCP snooping-based dynamic IPv4SG
configuration restrictions, 332
configuration (wired network), 561
display, 338
DHCPv6 relay agent-based dynamic IPv6SG
configuration, 565 enable, 332
DHCPv6 snooping-based dynamic IPv6SG enable restrictions, 332
address binding configuration (wired network), event logging, 331
563 expired password login, 330
DHCPv6 snooping-based dynamic IPv6SG FIPS compliance, 332
prefix binding configuration (wired network), maintain, 338
564 max user account idle time, 331
IPSG configuration (wired network), 551, 553, parameter restrictions (global), 333
560
parameters (global), 333
IPv6 ND attack defense configuration, 595
parameters (local user), 336

717
 parameters (super), 337 display, 376
parameters (user group), 335 domain configuration, 363
password complexity checking, 329 entity configuration, 362
password composition checking, 328 fingerprint of root CA certificate, 359
password control blacklist, 330 FIPS compliance, 361
password expiration, 329, 329 local digital certificate, 359
password expiration early notification, 330 online certificate request (manual), 369
password history, 330 online certificate request mode (automatic), 369
password min length, 328 OpenCA server certificate request, 383
password not displayed, 331 peer digital certificate, 359
password setting, 328 public key management, 349
password updating, 329, 329 RA digital certificate, 359
user first login, 330 RSA Keon CA server certificate request, 377
user login attempt limit, 331 SSH server PKI domain, 485
user login control, 330 storage path, 367
user login with weak password, 331 submitting certificate request in offline mode, 370
path terminology, 359
troubleshooting PKI storage path set failure, troubleshoot CA certificate import failure, 396
398 troubleshoot CA certificate obtain failure, 394
peer troubleshoot certificate export failure, 397
host public key configuration, 352 troubleshoot configuration, 393
host public key entry, 353, 354 troubleshoot CRL obtain failure, 396
host public key import from file, 353 troubleshoot local certificate import failure, 397
IPsec SA, 401 troubleshoot local certificate obtain failure, 394
IPsec-protected traffic, 402 troubleshoot local certificate request failure, 395
PKI digital certificate, 359 troubleshoot storage path set failure, 398
Perfect Forward Secrecy. See PFS Windows 2003 CA server certificate request
periodic configuration, 379
MFF periodic gateway probe, 618 Windows 2003 CA server IKE negotiation+RSA
periodic 802.1X reauthentication, 118 digital signature, 386
periodic MAC reauthentication, 169 PKI domain
PFS (IKE), 440 creation, 364
PKI root CA certificate verification fingerprint, 365
applications, 361 specifying certificate request key pair, 366
architecture, 360 specifying certificate request reception authority,
CA digital certificate, 359 364
CA policy, 360 specifying certificate request URL, 365
certificate export, 374 specifying intended purpuse for certificate, 366
certificate import/export configuration, 388 specifying LDAP server, 365
certificate obtain, 371 specifying PKI entity name, 364
certificate removal, 374 specifying PKI protocol packets source IP
address, 367
certificate request, 368
specifying SCEP polling interval and maximum
certificate request abort, 370
polling attempts, 365
certificate verification, 372
specifying trusted CA, 364
certificate verification (CRL checking), 373
policy
certificate verification (w/o CRL checking), 373
802.1X client SSL client policy, 655
certificate-based access control policy, 375
AAA connection recording policy configuration, 66
configuration, 359, 361, 376
IPsec application to interface, 415
CRL, 359
IPsec configuration (manual), 411
digital certificate retrieval, usage, and
IPsec IKEv2 configuration, 467
maintenance, 361

718
 IPsec policy (IKE-based/direct), 413 MAC authentication (local), 192
IPsec policy (IKE-based/template), 414 MAC authentication (RADIUS-based), 194
IPsec policy configuration (IKE-based), 412 MAC authentication authorization VLAN port
IPsec QoS pre-classify enable, 418 manipulation, 162
IPsec source interface policy bind, 417 MAC authentication concurrent port users max,
IPsec transform set configuration, 408 184
IPv6 ND attack defense RA guard logging MAC authentication configuration, 159
enable, 603 MAC authentication critical VLAN, 178
IPv6 ND attack defense RA guard policy, 602 MAC authentication critical voice VLAN, 179
MAC authentication user account, 174 MAC authentication critical VSI, 181
MAC authentication user account policies, MAC authentication delay, 185
159 MAC authentication guest VLAN, 177, 177
password control configuration, 328, 332, 338 MAC authentication guest VSI, 180, 180
PKI CA policy, 360 MAC authentication multi-VLAN mode, 185
PKI certificate-based access control policy, MAC authentication Web proxy port URL
375 redirection configuration, 189
portal authentication extended functions, 203 MFF network port, 616, 617
portal authentication policy server, 204 MFF port roles, 615
SSL client policy configuration, 545 MFF user port, 615
SSL server policy configuration, 544 portal authentication configuration, 203, 209, 235
port portal authentication interface NAS-ID profile, 232
802.1X Auth-Fail VLAN, 128 portal authentication server detection+user
802.1X Auth-Fail VLAN (port-based access synchronization configuration, 259
control), 110 re-DHCP portal authentication configuration, 241
802.1X Auth-Fail VSI, 131 security. See port security
802.1X authorization VLAN port manipulation, SSH server port, 478
108 port security
802.1X critical VLAN, 129 802.1X access control method, 123
802.1X critical VLAN (port-based access 802.1X authentication, 297
control), 111 802.1X authentication configuration, 145
802.1X critical voice VLAN, 130 802.1X authentication guest VSI+authorization
802.1X critical voice VLAN (port-based VSI configuration (MAC-based), 151
access control), 113 802.1X authentication+ACL assignment
802.1X critical VSI, 132 configuration, 149
802.1X guest VLAN, 126 802.1X authentication+EAD assistant
802.1X guest VLAN (port-based access configuration (DHCP relay agent), 153
control), 109 802.1X authentication+EAD assistant
802.1X guest VSI, 130 configuration (DHCP server), 156
ARP attack detection user validity check 802.1X authorization state, 123
ingress port, 581 802.1X authorization status, 99
cross-subnet portal authentication 802.1X authorization VLAN configuration, 147
configuration, 244 802.1X basic configuration, 145
direct portal authentication configuration, 235 802.1X concurrent port users max, 136
direct portal authentication configuration (local 802.1X configuration, 120, 120
portal Web service), 264
802.1X controlled/uncontrolled port, 99
extended cross-subnet portal authentication
802.1X guest VLAN configuration, 147
configuration, 255
802.1X mandatory port authentication domain,
extended direct portal authentication
124
configuration, 248
802.1X overview, 99
extended re-DHCP portal authentication
configuration, 251 authentication modes, 295
MAC authentication, 171, 192 authorization-fail-offline, 306

719
 client macAddressElseUserLoginSecure Web authentication local portal Web server, 270
configuration, 317 portal authentication
client userLoginWithOUI configuration, 314 AAA server, 204
configuration, 295, 299, 312 access device, 204
configuration restrictions, 298 access device ID, 230
display, 312 advantages, 203
dynamic secure MAC, 303 allowing only DHCP users to pass authentication,
enable, 299 225
enable restrictions, 299 authenticated user redirection, 215
escape critical VSI, 310 authentication destination subnet, 222
escape critical VSI configuration restrictions, authentication source subnet, 221
310 BAS-IP, 230
features, 295 checking category-2 portal filtering rule issuing,
free VLAN configuration, 308 223
functions, 295 client, 204
intrusion protection, 304 client Rule ARP entry feature enable, 233, 233
intrusion protection configuration restrictions, configuration, 203, 209, 235
304 cross-subnet configuration, 244
intrusion protection feature, 295 detection, 226
MAC address autoLearn configuration, 312 direct configuration, 235
MAC address learning control, 296 direct configuration (local portal Web service),
MAC address limit per port VLAN, 307 264
MAC address limit per port VLAN restrictions, direct/cross-subnet authentication process
307 (CHAP/PAP authentication), 206
MAC authentication, 297 display, 234
MAC move configuration restrictions, 306 domain specification, 219
MAC move enable, 305 EAP support, 208
MAC+802.1X authentication, 297 enable (interface), 216
mode configuration restrictions, 300 enabling logging for portal user login/logout, 233
mode set, 300 extended cross-subnet configuration, 255
NAS-ID profile application, 309 extended direct configuration, 248
NAS-ID profile application restrictions, 309 extended functions, 203
NTK configuration, 304 extended re-DHCP configuration, 251
NTK configuration restrictions, 304 fail-permit configuration, 226
NTK feature, 295 file name rules, 214
open authentication mode configuration filtering rules, 208
restrictions, 308 interface NAS-ID profile, 232
open authentication mode enable, 307 local portal service configuration, 213
secure MAC address add, 303 local portal Web service, 205
secure MAC address configuration, 302 local portal Web service parameter configuration,
secure MAC address inactivity aging, 303 216
secure MAC address port limit, 301 maintain, 234
server authorization information ignore, 305 modes, 205
SNMP notification enable, 311 NAS-Port-Id attribute format, 231
troubleshoot, 321 NAS-Port-Type attribute configuration, 231
troubleshoot mode cannot be set, 321 online user logout, 232
troubleshoot secure MAC addresses, 322 page customization, 214
user logging enable, 311 page file compression+saving rules, 215
user logging enable restrictions, 311 page request rules, 214
portal policy server, 204
user profile configuration, 323 portal authorization strict-checking mode, 224

720
 portal user preauthentication IP address pool, 802.1X prerequisites, 121, 121
218 activating AAA RADIUS server configuration, 65
portal-free rule configuration, 220 adding interface to SAVA access group, 660
post request rules, 214 adding port security secure MAC address, 303
process, 206 allowing DHCP users to pass portal
re-DHCP configuration, 241 authentication, 225
remote portal Web server configuration, 212 allowing only DHCP users to pass portal
remote server configuration, 211 authorization (interface), 225
roaming enable, 225 applying IPsec policy to interface, 415
server, 204 applying IPv6 ND attack defense RA guard policy,
server detection, 227 602
server detection+user synchronization applying port security NAS-ID profile, 309
configuration, 259 applying portal authentication interface NAS-ID
Support of IPv4/IPv6 dual stack, 217 profile, 232
system, 203 authenticating with 802.1X EAP relay, 103
system component interaction, 204 authenticating with 802.1X EAP termination mode,
104
troubleshoot, 267
binding IPsec source interface to policy, 417
troubleshoot cannot log out users (access
device), 267 changing SFTP directory name, 493
troubleshoot cannot log out users (RADIUS changing SFTP file name, 494
server), 268 changing SFTP working directory, 493
troubleshoot no page pushed for users, 267 checking category-2 portal filtering rule issuing,
troubleshoot users cannot log in (re-DHCP), 223
269 configuring 802.1X, 120
troubleshoot users logged out still exist on configuring 802.1X authentication trigger, 135
server, 268 configuring 802.1X authentication+ACL
URL redirection match rules, 213 assignment, 149
user access control, 220 configuring 802.1X authentication+EAD assistant
user online detection, 226 (DHCP relay agent), 153
user setting max, 223 configuring 802.1X authentication+EAD assistant
(DHCP server), 156
user synchronization configuration, 229
configuring 802.1X Auth-Fail VLAN, 128
Web proxy support, 222
configuring 802.1X Auth-Fail VSI, 131
Web redirect configuration, 234
configuring 802.1X authorization VLAN, 147
Web server detection configuration, 228
configuring 802.1X basics, 145
Web server specify (interface), 217
configuring 802.1X client, 651
portal filtering rule
configuring 802.1X client anonymous identifier,
portal authentication category-2 portal filtering
654
rule issuing check, 223
configuring 802.1X client anonymous identifier
power-up self-test, 622
(Ethernet interface view), 654
prerequisites
configuring 802.1X client MAC address, 653
IPsec IKE, 441
configuring 802.1X client username+password,
preshared key (PSK) 652
MACsec configuration, 639 configuring 802.1X client username+password
preventing (Ethernet interface view), 652
attack detection and prevention. See attack configuring 802.1X critical VLAN, 129
D&P configuring 802.1X critical VSI, 132
TCP attack prevention configuration, 550 configuring 802.1X EAD assistant, 142
priority configuring 802.1X guest VLAN, 126, 147
AAA RADIUS packet DSCP priority setting, 32 configuring 802.1X guest VSI, 130
MACsec MKA key server priority, 640 configuring 802.1X guest VSI+authorization VSI
procedure (MAC-based), 151

721
configuring 802.1X MAC address binding, 141 configuring AAA RADIUS Called-Station-Id
configuring 802.1X online user handshake, attribute MAC address format, 34
137 configuring AAA RADIUS Calling-Station-Id
configuring 802.1X protocol packet VLAN tag attribute MAC address format, 34
removal, 139 configuring AAA RADIUS DAE server (DAS), 41
configuring 802.1X reauthentication, 125 configuring AAA RADIUS Login-Service attribute
configuring 802.1X unauthenticated user check method, 32
aging, 132 configuring AAA RADIUS server, 64
configuring AAA, 15 configuring AAA RADIUS server 802.1X user, 79
configuring AAA connection recording policy, configuring AAA RADIUS server 802.1X user
66 authentication+authorization, 86
configuring AAA device ID, 63 configuring AAA RADIUS server SSH user
configuring AAA device management user authentication+authorization, 73
attributes, 17 configuring AAA RADIUS server status detection
configuring AAA EAP profile, 22 test profile, 23
configuring AAA HWTACACS, 43 configuring AAA RADIUS session-control, 40
configuring AAA HWTACACS server SSH configuring AAA RADIUS stop-accounting packet
user, 69 buffering, 37
configuring AAA HWTACACS stop-accounting configuring AAA SSH user local
packet buffering, 50 authentication+HWTACACS
configuring AAA ISP domain accounting authorization+RADIUS accounting, 71
method, 61 configuring AAA test, 67
configuring AAA ISP domain attribute, 57 configuring AAA user group attributes, 20
configuring AAA ISP domain authentication configuring ARP active acknowledgement, 573
method, 59 configuring ARP attack detection, 577
configuring AAA ISP domain authorization configuring ARP attack detection (source
attribute, 57 MAC-based), 571, 572
configuring AAA ISP domain authorization configuring ARP attack detection (VSI), 581
method, 60 configuring ARP attack detection packet validity
configuring AAA ISP domain method, 59 check, 579
configuring AAA LDAP, 51 configuring ARP attack detection packet validity
configuring AAA LDAP administrator attributes, check (VSI), 582
52 configuring ARP attack detection restricted
configuring AAA LDAP attribute map, 54 forwarding, 580
configuring AAA LDAP server IP address, 51 configuring ARP attack detection user validity
configuring AAA LDAP server SSH user check, 577
authentication, 76 configuring ARP attack detection user validity
configuring AAA LDAP user attributes, 53 check (VSI), 581
configuring AAA local user, 16 configuring ARP attack protection, 567
configuring AAA local user auto-delete, 21 configuring ARP attack protection (unresolvable
IP attack), 567, 569
configuring AAA NAS-ID, 63
configuring ARP attack protection (user+packet
configuring AAA network access user
validity check), 584
attributes, 18
configuring ARP attack protection blackhole
configuring AAA RADIUS, 21
routing (unresolvable IP attack), 568
configuring AAA RADIUS accounting-on, 39
configuring ARP attack protection restricted
configuring AAA RADIUS attribute translation, forwarding, 586
36
configuring ARP attack protection source
configuring AAA RADIUS attribute translation suppression (unresolvable IP attack), 568
(DAS), 37
configuring ARP attack protection user validity
configuring AAA RADIUS attribute translation check, 583
(single scheme), 36
configuring ARP filtering, 590, 591
configuring AAA RADIUS Called-Station-Id
configuring ARP gateway protection, 589, 589
attribute format, 33

722
configuring ARP packet rate limit, 570 configuring IPsec anti-replay redundancy, 417
configuring ARP packet source MAC configuring IPsec for IPv6 routing protocols, 420
consistency check, 573 configuring IPsec fragmentation, 422
configuring ARP scanning+fixed ARP, 587 configuring IPsec IKE (main mode+preshared key
configuring ARP sender IP address checking, authentication), 451
592, 592 configuring IPsec IKE global identity information,
configuring attack D&P TCP fragment attack 447
prevention, 548 configuring IPsec IKE keepalive, 448
configuring Auth-Fail VLAN, 277 configuring IPsec IKE keychain, 446
configuring authorized ARP (DHCP relay configuring IPsec IKE NAT keepalive, 448
agent), 575 configuring IPsec IKE profile, 442
configuring authorized ARP (DHCP server), configuring IPsec IKE proposal, 445
574
configuring IPsec IKE SA max, 450
configuring authorized ARP configuration, 574
configuring IPsec IKE SNMP notification, 450
configuring cross-subnet portal authentication,
configuring IPsec IKEv2 DPD, 470
244
configuring IPsec IKEv2 global parameters, 470
configuring destination-based portal-free rule,
221 configuring IPsec IKEv2 keychain, 469
configuring DHCP relay agent-based IPv4SG, configuring IPsec IKEv2 NAT keepalive, 471
562 configuring IPsec IKEv2 policy, 467
configuring DHCP snooping-based dynamic configuring IPsec IKEv2 profile, 463
IPv4SG (wired network), 561 configuring IPsec IKEv2 proposal, 468
configuring DHCPv6 relay agent-based configuring IPsec IPv6 routing protocol profile
dynamic IPv6SG, 565 (manual), 420
configuring DHCPv6 snooping-based configuring IPsec packet DF bit, 419
dynamic IPv6SG address bindings (wired configuring IPsec policy (IKE-based), 412
network), 563 configuring IPsec policy (IKE-based/direct), 413
configuring DHCPv6 snooping-based configuring IPsec policy (IKE-based/template),
dynamic IPv6SG prefix bindings (wired 414
network), 564
configuring IPsec policy (manual), 411
configuring direct portal authentication, 235
configuring IPsec RIPng, 430
configuring direct portal authentication (local
configuring IPsec RRI, 419, 433
portal Web service), 264
configuring IPsec SNMP notification, 423
configuring extended cross-subnet portal
authentication, 255 configuring IPsec transform set, 408
configuring extended direct portal configuring IPsec tunnel for IPv4 packets
authentication, 248 (IKE-based), 454
configuring extended re-DHCP portal configuring IPsec tunnel for IPv4 packets
authentication, 251 (manual), 425
configuring global IPsec IKE DPD, 449 configuring IPSG (wired network), 553
configuring global IPsec SA lifetime and idle configuring IPv4SG (wired network), 553
timeout, 422 configuring IPv4SG static binding (global)(wired
configuring IKE keychain or PKI domain, 442, network), 555
464 configuring IPv4SG static binding (on
configuring IKE phase 1 negotiation mode, interface)(wired network), 555
443 configuring IPv4SG static binding (wired network),
configuring IKE profile optional features, 444 554
configuring IKE-based IPsec tunnel for IPv4 configuring IPv6 ND attack defense, 595
packets, 427 configuring IPv6 ND attack defense RA guard,
configuring IKEv2 profile optional features, 601, 603
466 configuring IPv6 ND attack defense RA guard
configuring IP-based portal-free rule, 220 policy, 602
configuring IPsec ACL, 406 configuring IPv6 ND attack detection, 596, 599
configuring IPsec anti-replay, 416

723
configuring IPv6 source guard (IPv6SG) configuring MACsec protection parameters (MKA
binding max (interface), 558 policy), 642
configuring IPv6SG (wired network), 556 configuring MFF, 616
configuring IPv6SG static binding configuring MFF (in ring network), 620
(global)(wired network), 557 configuring MFF (in tree network), 619
configuring IPv6SG static binding (on configuring MFF network port, 617
interface)(wired network), 557 configuring NAS-Port-Type attribute, 231
configuring IPv6SG static binding (wired configuring ND attack detection (VLAN), 597
network), 557
configuring ND attack detection (VSI), 598
configuring keychain, 342, 342, 343, 343
configuring NETCONF-over-SSH client user line,
configuring local ID for IKE profile, 444 480
configuring local ID for IKEv2 profile, 464 configuring NETCONF-over-SSH+password
configuring local portal authentication service, authentication, 539
213 configuring password control, 332
configuring MAC authentication, 171 configuring peer host public key, 352
configuring MAC authentication (local), 192 configuring peer IDs for IKE profile, 442
configuring MAC authentication configuring peer IDs for IKEv2 profile, 465
(RADIUS-based), 194
configuring periodic MAC reauthentication, 176
configuring MAC authentication ACL
configuring PKI, 361
assignment, 196
configuring PKI certificate import/export, 388
configuring MAC authentication authorization
VSI assignment, 199 configuring PKI certificate request abort, 370
configuring MAC authentication critical VLAN, configuring PKI certificate-based access control
178 policy, 375
configuring MAC authentication critical VSI, configuring PKI domain, 363
181 configuring PKI entity, 362
configuring MAC authentication delay, 185 configuring PKI online certificate request
configuring MAC authentication guest VLAN, (manual), 369
177 configuring PKI OpenCA server certificate request,
configuring MAC authentication guest VSI, 383
180 configuring PKI RSA Keon CA server certificate
configuring MAC authentication multi-VLAN request, 377
mode, 185 configuring PKI Windows 2003 CA server
configuring MAC authentication offline certificate request, 379
detection, 182 configuring PKI Windows 2003 CA server IKE
configuring MAC authentication timer, 175 negotiation+RSA digital signature, 386
configuring MAC authentication configuring port security, 299
unauthenticated user aging, 182 configuring port security client
configuring MAC authentication user account macAddressElseUserLoginSecure, 317
policy, 174 configuring port security client userLoginWithOUI,
configuring MAC authentication Web proxy 314
port URL redirection, 189 configuring port security free VLAN, 308
configuring MACsec, 638 configuring port security intrusion protection, 304
configuring MACsec (client-oriented), 644 configuring port security MAC address autoLearn,
configuring MACsec (device-oriented), 646 312
configuring MACsec MKA key server priority, configuring port security NTK, 304
640 configuring port security secure MAC addresses,
configuring MACsec preshared key, 639 302
configuring MACsec protection parameters, configuring portal authentication, 209
640 configuring portal authentication destination
configuring MACsec protection parameters subnet, 222
(interface view), 641 configuring portal authentication detection, 226
configuring portal authentication fail-permit, 226

724
configuring portal authentication local portal configuring SAVI DHCPv6 snooping, 609
Web service parameter, 216 configuring SAVI IP source guard, 609
configuring portal authentication portal-free configuring SAVI ND parameters, 609
rule, 220 configuring Secure Telnet client user line, 480
configuring portal authentication server configuring security password control, 338
BAS-IP, 230
configuring source-based portal-free rule, 221
configuring portal authentication server
configuring SSH client host public key, 480
BAS-IP (interface), 230
configuring SSH device as Secure Telnet client,
configuring portal authentication server
486
detection, 227
configuring SSH device as server, 477
configuring portal authentication server
detection+user synchronization, 259 configuring SSH device as SFTP client, 489
configuring portal authentication source configuring SSH management parameters, 483
subnet, 221 configuring SSH SCP (Suite B algorithm), 533
configuring portal authentication user online configuring SSH SCP client device, 495
detection, 226 configuring SSH SCP+Linux client, 531
configuring portal authentication user configuring SSH SCP+password authentication,
synchronization, 229 529
configuring portal authentication Web proxy configuring SSH Secure Telnet (128-bit Suite B
support, 222 algorithm), 516
configuring portal authentication Web redirect, configuring SSH Secure Telnet client (password
234 authentication), 510
configuring portal authentication Web server configuring SSH Secure Telnet client (publickey
detection, 228 authentication), 514
configuring portal packet attributes, 230 configuring SSH Secure Telnet server (publickey
configuring portal RADIUS packet attributes, authentication), 504
231 configuring SSH Secure Telnet server
configuring portal URL redirection match rules, configuration (password authentication), 502
213 configuring SSH SFTP (192-bit Suite B algorithm),
configuring portal Web server basic 525
parameters, 212 configuring SSH SFTP client (publickey
configuring re-DHCP portal authentication, authentication), 522
241 configuring SSH SFTP server (password
configuring remote portal authentication authentication), 520
server, 211 configuring SSH user, 482
configuring remote portal authentication Web configuring SSH2 algorithms (encryption), 500
server, 212 configuring SSH2 algorithms (key exchange), 499
configuring RESTful server-assisted MAC configuring SSH2 algorithms (MAC), 500
authentication user recovery, 188 configuring SSH2 algorithms (public key), 500
configuring SAVA, 658 configuring SSL, 543
configuring SAVA border devices directly configuring SSL client, 544
connected the LAN(on switch), 661
configuring SSL client policy, 545
configuring SAVA border devices indirectly
configuring SSL server, 543
connected the LAN (IPv6 IS-IS)(on switch),
666 configuring SSL server policy, 544
configuring SAVA border devices indirectly configuring static IPv4SG (wired network), 560
connected the LAN (OSPFv3)(on switch), 662 configuring static IPv6SG (wired network), 563
configuring SAVA logging, 660 configuring TCP attack prevention (Naptha
configuring SAVA on inter-AS border devices attack), 550
directly connected the LAN(on switch), 670 configuring triple authentication, 285
configuring SAVI, 608 configuring triple authentication (authorization
configuring SAVI (DHCPv6+SLAAC), 613 VLAN+Auth-Fail VLAN), 289
configuring SAVI (DHCPv6-only), 610 configuring triple authentication basics, 285
configuring SAVI (SLAAC-only), 612 configuring user profile, 323

725
configuring user profile+QoS policy, 324 displaying ARP attack protection (unresolvable IP
configuring Web authentication, 273 attack), 569
configuring Web authentication (local displaying crypto engine, 633
authentication server), 278 displaying FIPS, 628
configuring Web authentication (RADIUS displaying host public key, 352
authentication server), 280 displaying IPsec, 424
configuring Web authentication proxy support, displaying IPsec IKE, 451
277 displaying IPsec IKEv2, 471
configuring Web authentication server, 274 displaying IPSG (wired network), 559
configuring Web authentication user online displaying IPv4SG (wired network), 559
detection, 276
displaying IPv6 ND attack defense RA guard, 603
configuring Web authentication-free subnet,
displaying IPv6 ND attack detection, 599
276
displaying IPv6SG (wired network), 559
controlling portal authentication user access,
220 displaying keychain, 343
creating AAA HWTACACS scheme, 44 displaying MAC authentication, 191
creating AAA ISP domain, 56 displaying MACsec, 643
creating AAA ISP domain creation, 56 displaying MFF, 618
creating AAA LDAP scheme, 54 displaying port security, 312
creating AAA LDAP server, 51 displaying portal authentication, 234
creating AAA RADIUS scheme, 24 displaying public key, 354
creating IPsec IKE profile, 442 displaying SAVA, 661
creating IPsec IKEv2 profile, 463 displaying security password control, 338
creating local key pair, 350 displaying security PKI, 376
creating PKI domain, 364 displaying SFTP directory file, 493, 494
creating SFTP new directory, 494 displaying SFTP working directory, 493
deleting SFTP directory, 494 displaying SSH, 501
deleting SFTP file, 494 displaying SSH SFTP help information, 495
deleting SSH SCP server public key, 498 displaying SSL, 547
deleting SSH Secure Telnet server public key, displaying uRPF, 607
489 displaying user profile, 323
deleting SSH SFTP server public key, 492 displaying Web authentication, 278
destroying local key pair, 354 distributing local host public key, 351
disabling AAA RADIUS service, 42 downloading SFTP file+local save, 494
disabling SSL protocol version, 546 enabling 802.1X, 122
disabling SSL session renegotiation, 546 enabling 802.1X authenticated user dynamic
discarding 802.1X duplicate EAPOL-Start IPSG binding entry generation, 140
request, 136 enabling 802.1X critical voice VLAN, 130
disconnecting SSH session, 485 enabling 802.1X EAP relay, 122
displaying 802.1X, 144 enabling 802.1X EAP termination, 122
displaying 802.1X client, 655 enabling 802.1X guest VLAN assignment delay,
displaying AAA connection recording policy, 127
66 enabling 802.1X guest VSI assignment delay, 131
displaying AAA HWTACACS, 50 enabling 802.1X online user synchronization, 134
displaying AAA ISP domain, 62 enabling 802.1X user IP freezing, 140
displaying AAA LDAP, 55 enabling 802.1X user logging, 144
displaying AAA local users/user groups, 21 enabling AAA password change prompt logging,
displaying AAA RADIUS, 43 64
displaying AAA RADIUS user+client, 66 enabling AAA RADIUS server load sharing, 38
displaying ARP attack detection, 583 enabling AAA RADIUS SNMP notification, 41
displaying ARP attack detection (source enabling AAA RADIUS stop-accounting packet
MAC-based), 572 forcibly sending, 38

726
enabling ARP attack detection logging, 582 enabling port security secure MAC address
enabling attack D&P login delay, 549 inactivity aging, 303
enabling automatic online certificate request enabling port security SNMP notification, 311
mode, 369 enabling port security user logging, 311
enabling IPsec ACL de-encapsulated packet enabling portal authentication (interface), 216
check, 416 enabling portal authentication client Rule ARP
enabling IPsec IKE invalid SPI recovery, 449 entry feature, 233
enabling IPsec IKEv2 cookie challenge, 470 enabling portal authentication client Rule ND
enabling IPsec packet logging, 423 entry feature, 233
enabling IPsec QoS pre-classify, 418 enabling portal authorization strict-checking mode,
enabling IPv4SG (wired network), 553 224
enabling IPv4SG alarming on interface (wired enabling portal authorization strict-checking mode
network), 556 (interface), 224
enabling IPv6 ND attack defense RA guard enabling portal to support for IPv4/IPv6 dual stack,
logging, 603 217
enabling IPv6 ND attack defense source MAC enabling SAVA, 659
consistency check, 596 enabling SAVI, 608
enabling IPv6SG (wired network), 556 enabling SAVI packet spoofing logging and
enabling IPv6SG alarming on interface (wired filtering entry logging, 610
network), 558 enabling security portal authentication roaming,
enabling logging for portal user login/logout, 225
233 enabling SSH algorithm renegotiation+key
enabling MAC authentication, 172 re-exchange, 483
enabling MAC authentication critical voice enabling SSH login control ACL attempts denied
VLAN, 179 logging, 484
enabling MAC authentication guest VLAN enabling SSH SCP server, 479
reauthentication, 177 enabling SSH Secure Telnet server, 479
enabling MAC authentication guest VSI enabling SSH server support for SSH1 clients,
reauthentication, 180 483
enabling MAC authentication online user enabling SSH SFTP server, 479
synchronization, 183 enabling the captive-bypass feature, 212
enabling MAC authentication user logging, enabling uRPF (global), 607
190 enabling Web authentication, 274
enabling MACsec desire, 639 enbling remote entry-based SAVA entry creation,
enabling MACsec MKA, 638 659
enabling MACsec MKA session logging, 643 entering FIPS mode (automatic reboot), 624, 628
enabling MFF, 617 entering FIPS mode (manual reboot), 624, 629
enabling MFF periodic gateway probe, 618 entering peer host public key, 353
enabling ND attack detection (interface), 597 entering SSH client host public key, 481
enabling ND attack detection logging, 599 establishing IPv4 Secure Telnet server
enabling NETCONF-over-SSH, 480 connection, 487
enabling parallel MAC authentication+802.1X establishing IPv4 SFTP server connection, 491
authentication, 187 establishing IPv6 Secure Telnet server
enabling password control, 332 connection, 488
enabling port security, 299 establishing IPv6 SFTP server connection, 492
enabling port security authorization-fail-offline, establishing SSH IPv4 SCP server connection,
306 497
enabling port security dynamic secure MAC, establishing SSH IPv6 SCP server connection,
303 498
enabling port security escape critical VSI, 310 establishing SSH SCP server connection, 497
enabling port security MAC move, 305 establishing SSH SCP server connection (Suite
enabling port security open authentication B), 499
mode, 307

727
establishing SSH Secure Telnet server maintaining IPv6 ND attack defense RA guard,
connection, 487 603
establishing SSH Secure Telnet server maintaining IPv6 ND attack detection, 599
connection (Suite B), 489 maintaining MAC authentication, 191
establishing SSH SFTP server connection, maintaining MACsec, 643
491 maintaining portal authentication, 234
establishing SSH SFTP server connection maintaining SAVA, 661
(Suite B), 493
maintaining security password control, 338
excluding IPSG IPv4 packets from filtering,
obtaining PKI certificate, 371
555
removing PKI certificate, 374
exiting FIPS mode, 627
requesting PKI certificate request, 368
exiting FIPS mode (automatic reboot), 627,
631 sending 802.1X Auth-Fail VLAN/VSI user
EAP-Success packet, 133
exiting FIPS mode (manual reboot), 627, 631
sending 802.1X critical VLAN/VSI user
exporting host public key, 351
EAP-Success packet, 134
exporting PKI certificate, 374
setting 802.1X authentication request attempts
generating SCP client local key pair, 496 max, 136
generating Secure Telnet client local key pair, setting 802.1X authentication timeout timer, 124
486
setting 802.1X concurrent port users max, 136
generating SFTP client local key pair, 490
setting 802.1X MAC user authentication attempts
generating SSH server local key pair, 478 max, 139
ignoring ARP attack detection user validity setting 802.1X port authorization state, 123
check ingress port, 581
setting 802.1X quiet timer, 126
ignoring ND packet ingress port, 598
setting 802.1X server-side EAP-TLS fragment
ignoring port security server authorization maximum size, 143
information, 305
setting AAA concurrent login user max, 62
implementing IPsec (ACL-based), 405
setting AAA HWTACACS timer, 47
importing peer host public key from file, 353
setting AAA HWTACACS traffic statistics unit, 49
importing public key from file, 356
setting AAA HWTACACS username format, 49
importing SSH client host public key, 481
setting AAA ISP domain status, 57
including AAA ISP domain idle timeout period
setting AAA LDAP server timeout period, 52
in user online duration, 58
setting AAA RADIUS real-time accounting
including AAA RADIUS subattribute 218 of
attempts max, 31
vendor 25506 in RADIUS packets, 35
setting AAA RADIUS Remanent_Volume attribute
including MAC authentication request user IP
data measurement unit, 35
address, 186
setting AAA RADIUS request transmission
interpreting AAA RADIUS class attribute as
attempts max, 31
CAR parameter, 33
setting AAA RADIUS server status, 27
limiting port security secure MAC addresses,
301 setting AAA RADIUS timer, 28
logging off 802.1X user, 143 setting AAA RADIUS traffic statistics unit, 30
logging off MAC authentication user, 190 setting AAA RADIUS username format, 30
logging out portal authentication online users, setting IPsec tunnel max, 423
232 setting MAC authentication concurrent port users
maintaining 802.1X, 144 max, 184
maintaining AAA HWTACACS, 50 setting MACsec MKA life time, 640
maintaining AAA RADIUS, 43 setting password control parameters (global), 333
maintaining ARP attack detection, 583 setting password control parameters (local user),
336
maintaining crypto engine, 633
setting password control parameters (super), 337
maintaining IPsec, 424
setting password control parameters (user group),
maintaining IPsec IKE, 451
335
maintaining IPsec IKEv2, 471

728
setting port security MAC addresses limit per specifying AAA HWTACACS shared keys, 46
port VLAN, 307 specifying AAA ISP domain for users that are
setting port security mode, 300 assigned to nonexistent domains, 57
setting portal authentication users max, 223 specifying AAA LDAP attribute map for
setting portal authentication users max authorization, 55
(global), 224 specifying AAA LDAP authentication server, 55
setting portal authentication users max specifying AAA LDAP authorization server, 55
(interface), 224 specifying AAA LDAP version, 52
setting SAVI deletion delay, 609 specifying AAA RADIUS accounting server, 25
setting SSH authentication attempt max specifying AAA RADIUS authentication server, 24
number, 484 specifying AAA RADIUS client, 65
setting SSH online user max number, 485 specifying AAA RADIUS outgoing packet source
setting SSH server packet DSCP value, 484 interface (all schemes), 30
setting SSH SFTP connection idle timeout specifying AAA RADIUS outgoing packet source
timer, 485 interface (single scheme), 30
setting SSH update interval for RSA server specifying AAA RADIUS outgoing packet source
key pair, 483 IP address, 29
setting SSH user authentication timeout timer, specifying AAA RADIUS outgoing packet source
484 IP address (all schemes), 30
setting Web authentication redirection wait specifying AAA RADIUS outgoing packet source
time, 275 IP address (single scheme), 30
setting Web authentication users max, 276 specifying AAA RADIUS scheme VPN instance,
settingAAA RADIUS packet DSCP priority, 32 26
specifying 802.1X access control method, 123 specifying AAA RADIUS server selection mode
specifying 802.1X client EAP authentication for reauthentication, 39
method, 652 specifying AAA RADIUS shared keys, 26
specifying 802.1X client EAP authentication specifying certificate intended purpuse, 366
method (Ethernet interface view), 653 specifying certificate request key pair, 366
specifying 802.1X client EAP-Response and specifying certificate request reception authority,
EAPOL-Logoff packet sending mode, 653 364
specifying 802.1X client SSL client policy, 655 specifying certificate request URL, 365
specifying 802.1X mandatory port specifying HTTPS redirect listening port number,
authentication domain, 124 274
specifying 802.1X supported domain name specifying IKE proposals for IKE profile, 443
delimiter, 138 specifying inside VPN instance for IKE profile,
specifying AAA default ISP domain, 57 444
specifying AAA HWTACACS accounting specifying inside VPN instance for IKEv2 profile,
server, 45 466
specifying AAA HWTACACS authentication specifying IPv6 ND attack defense device role,
server, 44 601
specifying AAA HWTACACS authorization specifying LDAP server, 365
server, 45 specifying MAC authentication domain, 173
specifying AAA HWTACACS outgoing packet specifying MAC authentication method, 173
source interface (all schemes), 49
specifying MAC authentication port guest VLAN,
specifying AAA HWTACACS outgoing packet 177
source interface (single scheme), 49
specifying MAC authentication port guest VSI,
specifying AAA HWTACACS outgoing packet 180
source IP address, 48
specifying MFF server IP address, 618
specifying AAA HWTACACS outgoing packet
specifying PKI entity name, 364
source IP address (all schemes), 49
specifying PKI protocol packets source IP
specifying AAA HWTACACS outgoing packet
address, 367
source IP address (single scheme), 49
specifying PKI storage path, 367
specifying AAA HWTACACS scheme VPN
instance, 47

729
specifying portal authentication access device troubleshooting IPsec SA negotiation failure
ID, 230 (tunnel failure), 473
specifying portal authentication domain, 219 troubleshooting MACsec device cannot establish
specifying portal authentication domain MKA session, 650
(interface), 220 troubleshooting PKI CA certificate import failure,
specifying portal authentication NAS-Port-Id 396
attribute format, 231 troubleshooting PKI CA certificate obtain failure,
specifying portal authentication Web server 394
(interface), 217 troubleshooting PKI certificate export failure, 397
specifying portal user preauthentication IP troubleshooting PKI CRL obtain failure, 396
address pool, 218 troubleshooting PKI local certificate import failure,
specifying root CA certificate verification 397
fingerprint, 365 troubleshooting PKI local certificate obtain failure,
specifying SCEP polling interval and 394
maximum polling attempts, 365 troubleshooting PKI local certificate request
specifying SSH SCP outgoing packet source failure, 395
IP address, 496 troubleshooting PKI storage path set failure, 398
specifying SSH Secure Telnet outgoing packet troubleshooting port security mode cannot be set,
source IP address, 486 321
specifying SSH server PKI domain, 485 troubleshooting port security secure MAC
specifying SSH server port, 478 addresses, 322
specifying SSH SFTP outgoing packet source troubleshooting portal authentication cannot log
IP address, 490 out users (access device), 267
specifying SSH user connection control ACL, troubleshooting portal authentication no page
484 pushed for users, 267
specifying SSH2 algorithms, 499 troubleshooting portal authentication users
specifying trusted CA, 364 cannot log in (re-DHCP), 269
specifying Web authentication domain, 275 troubleshooting portal authentication users
submitting PKI certificate request in offline logged out still exist on server, 268
mode, 370 troubleshooting security portal authentication
terminating SSH SFTP server connection, 495 cannot log out users (RADIUS server), 268
triggering FIPS self-test, 626 troubleshooting Web authentication failure to
come online, 282
troubleshooting 802.1X EAD assistant URL
redirection failure, 158 uploading SFTP local file, 494
troubleshooting AAA LDAP authentication verifying PKI certificate, 372
failure, 89 verifying PKI certificate verification (CRL
troubleshooting AAA RADIUS accounting checking), 373
error, 89 verifying PKI certificate verification (w/o CRL
troubleshooting AAA RADIUS authentication checking), 373
failure, 88 working with SSH SFTP directories, 493
troubleshooting AAA RADIUS packet delivery working with SSH SFTP files, 494
failure, 88 process
troubleshooting IPsec IKE negotiation failure AAA LDAP authentication, 9
(no proposal match), 456 AAA LDAP authorization process, 10
troubleshooting IPsec IKE negotiation failure profile
(no proposal or keychain specified correctly), AAA RADIUS server status detection test profile,
457 23
troubleshooting IPsec IKEv2 negotiation IPsec IKE configuration, 442
failure (no proposal match), 472
IPsec IKEv2 configuration, 463
troubleshooting IPsec SA negotiation failure
IPsec IPv6 routing protocol profile (manual), 420
(invalid identity info), 458
port security NAS-ID profile, 309
troubleshooting IPsec SA negotiation failure
(no transform set match), 458, 472 proposal
IPsec IKE proposal, 445

730
 IPsec IKEv2 proposal configuration, 468 SSH publickey authentication, 475
troubleshooting IPsec IKE negotiation failure SSH SCP server public key deletion, 498
(no proposal match), 456 SSH Secure Telnet server configuration
troubleshooting IPsec IKE negotiation failure (publickey authentication), 504
(no proposal specified correctly), 457 SSH Secure Telnet server public key deletion,
troubleshooting IPsec IKEv2 negotiation 489
failure (no proposal match), 472 SSH SFTP client configuration (publickey
proprietary attribute authentication), 522
AAA RADIUS subattribute 218 of vendor SSH SFTP server public key deletion, 492
25506 in RADIUS packets, 35 SSH user configuration, 482
protecting SSH v client configuration (publickey
ARP attack protection configuration, 567 authentication), 514
ARP gateway protection, 589 Public Key Infrastructure. Use PKI
MACsec replay protection, 635, 635 Q
protocols and standards
QoS
802.1X overview, 99
IPsec QoS pre-classify enable, 418
802.1X protocol packet VLAN tag removal,
139 quiet
AAA, 14 802.1X timer, 126
AAA HWTACACS, 5, 14 MAC authentication quiet timer, 175
AAA LDAP, 8, 14 R
AAA RADIUS, 2, 14 RA
IPsec, 405 IPv6 ND attack defense device role, 601
IPsec IKE, 440 IPv6 ND attack defense RA guard configuration,
IPsec IKEv2, 462 601, 603
IPsec IPv6 routing protocols configuration, IPv6 ND attack defense RA guard logging enable,
420 603
IPsec security protocol 50 (ESP), 399 IPv6 ND attack defense RA guard policy, 602
IPsec security protocol 51 (AH), 399 PKI architecture, 360
MACsec, 637 PKI certificate, 359
MFF, 616 RADIUS
SSL configuration, 542, 543 802.1X authentication+redirect URL assignment,
SSL protocol stack, 542 117
proxying 802.1X EAP over RADIUS, 102
Web authentication proxy support, 277 802.1X EAP relay enable, 122
public key 802.1X EAP termination enable, 122
display, 354 AAA Appendix A, commonly used attributes, 90
file import, 356 AAA Appendix C, subattributes (vendor ID 25506),
FIPS compliance, 349 94
host public key display, 352 AAA Appendix D, dynamic authorization ACL, 97
host public key export, 351 AAA configuration, 1, 15, 69
local host public key distribution, 351 AAA implementation, 2
local key pair creation, 350 AAA local user configuration, 16
local key pair creation restrictions, 350 AAA RADIUS client configuration, 65
local key pair destruction, 354 AAA RADIUS server configuration, 64, 65
management, 349, 354 AAA VPN implementation, 13
peer host public key configuration, 352 accounting server, 25
peer host public key entry, 353, 354 accounting-on configuration, 39
peer host public key import from file, 353 attribute translation, 36
SSH client host public key configuration, 480 attribute translation (DAS), 37
SSH password-publickey authentication, 475 attribute translation (single scheme), 36

731
authentication server, 24 scheme creation, 24
Called-Station-Id attribute format, 33 scheme VPN instance specification, 26
Called-Station-Id attribute MAC address server 802.1X user AAA, 79
format, 34 server 802.1X user AAA
Calling-Station-Id attribute MAC address authentication+authorization, 86
format, 34 server load sharing, 38
class attribute as CAR parameter, 33 server selection mode for reauthentication, 39
client/server model, 2 server status, 27
common standard attributes, 92 server status detection test profile, 23
configuration, 21 service disable, 42
DAE server (DAS), 41 session-control, 40
device server feature, 13 shared keys, 26
display, 43 SNMP notification enable, 41
extended attributes, 5 SSH user authentication+authorization, 73
HWTACACS/RADIUS differences, 5 SSH user local authentication+HWTACACS
information exchange security, 2 authorization+RADIUS accounting, 71
Login-Service attribute check method, 32 stop-accounting packet buffering, 37
MAC authentication (RADIUS-based), 194 stop-accounting packet forcibly sending, 38
MAC authentication authorization VLAN, 161 subattribute 218 of vendor 25506 included in
MAC authentication authorization VSI, 166 RADIUS packets, 35
MAC authentication blackhole attribute timer set, 28
assignment, 169 traffic statistics units, 30
MAC authentication CAR attribute assignment, troubleshooting accounting error, 89
169 troubleshooting authentication failure, 88
MAC authentication method, 160 troubleshooting packet delivery failure, 88
MAC authentication redirect URL assignment, troubleshooting security portal authentication
169 cannot log out users (RADIUS server), 268
maintain, 43 user authentication methods, 3
NAS-Port-Type attribute, 231 user+client display, 66
outgoing packet source interface (all username format, 30
schemes), 30 Web authentication configuration (RADIUS
outgoing packet source interface (single authentication server), 280
scheme), 30 RADIUS scheme
outgoing packet source IP address, 29 AAA EAP profile, 22
outgoing packet source IP address (all rate limiting
schemes), 30
ARP packet rate limit, 570
outgoing packet source IP address (single
real-time
scheme), 30
AAA HWTACACS real-time accounting timer, 47
packet DSCP priority setting, 32
AAA RADIUS real-time accounting attempts max,
packet exchange process, 3
31
packet format, 4
AAA RADIUS real-time accounting timer, 28
port security macAddressWithRadius, 297
reauthentication
port security NAS-ID profile, 309
AAA RADIUS RADIUS server selection mode, 39
portal authentication interface NAS-ID profile,
rebooting
232
FIPS mode (automatic reboot), 631
portal authentication NAS-Port-Id attribute
format, 231 FIPS mode (manual reboot), 631
protocols and standards, 14 FIPS mode entry (manual reboot), 629
real-time accounting attempts max, 31 record protocol (SSL), 542
Remanent_Volume attribute data recovering
measurement unit, 35 IPsec IKE invalid SPI recovery, 449
request transmission attempts max, 31

732
 RESTful server-assisted MAC authentication RESTful server-assisted MAC authentication user
user recovery configuration, 188 recovery configuration, 188
re-DHCP RESTful server-assisted MAC authentication user
portal authentication mode, 206 recovery, 170
portal authentication mode (CHAP/PAP restrictions
authentication), 207 802.1X authentication timeout timer, 124
redirecting 802.1X authentication trigger configuration, 135
portal authentication Web redirect, 234 802.1X Auth-Fail VLAN configuration, 128
Web authentication redirection wait time, 275 802.1X Auth-Fail VSI configuration, 131
redundancy 802.1X client anonymous identifier configuration,
IPsec anti-replay redundancy, 417 654
registration authority. Use RA 802.1X client EAP authentication method
rekeying configuration, 652
IKEv2 SA rekeying, 462 802.1X client username+password configuration,
652
relationship
802.1X configuration, 120
IKE and IPsec, 438
802.1X critical VLAN configuration, 129
relay agent
802.1X critical voice VLAN enable, 130
802.1X authentication+EAD assistant
configuration (DHCP relay agent), 153 802.1X critical VSI configuration, 132
authorized ARP configuration (DHCP relay 802.1X EAD assistant configuration, 142
agent), 575 802.1X EAP relay enable, 122
DHCP relay agent-based dynamic IPv4SG 802.1X EAP termination enable, 122
configuration, 562 802.1X enable, 122
DHCPv6 relay agent-based dynamic IPv6SG 802.1X guest VLAN configuration, 126
configuration, 565 802.1X guest VSI configuration, 130
remote 802.1X MAC address binding configuration, 141
802.1X authorization VLAN, 106 802.1X online user handshake configuration, 137
802.1X authorization VSI, 114 802.1X protocol packet VLAN tag removal, 139
802.1X remote VLAN authorization, 106 802.1X quiet timer, 126
AAA remote accounting method, 11 802.1X reauthentication, 125
AAA remote authentication, 11 802.1X supported domain name delimiters, 138
AAA remote authentication configuration, 15 802.1X user logging configuration, 144
AAA remote authorization method, 11 AAA ISP domain accounting method
Remote Authentication Dial-In User Service. Use configuration, 61
RADIUS AAA ISP domain authentication method
remote server configuration, 59
portal authentication configuration, 211 AAA ISP domain authorization method
remote VLAN configuration, 60
MAC authentication remote VLAN AAA ISP domain configuration, 56
authorization, 161 AAA RADIUS session-control configuration, 40
removing AAA RADIUS timer configuration, 28
802.1X protocol packet VLAN tag, 139 ARP attack detection restricted forwarding, 580
PKI certificate, 374 ARP attack protection filtering configuration, 590
request ARP attack protection gateway protection, 589
PKI certificate request abort, 370 ARP attack protection packet rate limit
requesting configuration, 570
PKI certificate request, 368 ARP attack protection restricted forwarding, 580
requirements ARP attack protection restricted forwarding
key pairs and passwords, 623 configuration, 586
resource access restriction (portal authentication), ARP attack protection scanning+fixed ARP
203 configuration, 588
RESTful

733
ARP attack protection source MAC-based port security escape critical VSI configuration,
attack detection, 571 310
ARP attack protection unresolvable IP attack port security intrusion protection configuration,
blackhole routing, 568 304
ARP attack protection user validity check port security MAC address limit per port VLAN
configuration, 578 configuration, 307
ARP sender IP address checking, 592 port security MAC move configuration, 306
FIPS configuration, 623 port security mode configuration, 300
IPsec policy configuration, 411 port security NAS-ID profile application, 309
IPsec policy configuration (IKE-based), 412 port security NTK configuration, 304
IPv4SG interface enable (wired network), 553 port security open authentication mode
IPv4SG static binding configuration (wired configuration, 308
network), 554 port security user logging enable, 311
IPv6 ND attack defense device role, 601 public key ocal key pair creation, 350
IPv6 ND attack detection, 597 SAVI DHCPv6 snooping configuration, 609
IPv6SG interface enable (wired network), 556 SAVI ND parameter configuration, 609
IPv6SG static binding configuration (wired Secure Telnet client local key pair generation, 486
network), 557 SSH client host public key configuration, 481
MAC authentication configuration, 171 SSH local key pair configuration, 478
MAC authentication critical VLAN SSH SCP client local key pair generation, 496
configuration, 178 SSH SCP outgoing packet source IP address
MAC authentication critical VSI configuration, restrictions, 496
181 SSH SCP server connection establishment, 497
MAC authentication delay configuration, 185 SSH SCP server enable, 479
MAC authentication enable, 172 SSH Secure Telnet outgoing packet source IP
MAC authentication guest VLAN configuration, address, 486
177 SSH Secure Telnet server connection
MAC authentication guest VSI configuration, establishment, 487
180 SSH server port specification, 478
MAC authentication periodic reauthentication, SSH SFTP client local key pair generation, 490
176
SSH SFTP outgoing packet source IP address,
MAC authentication request user IP address 490
inclusion, 186
SSH SFTP server connection establishment, 491
MAC authentication user logging configuration,
SSH SFTP server enable, 479
190
SSH user configuration, 482
MACsec hardware compatibility, 638
triple authentication configuration, 285
MACsec MKA key server priority configuration,
640 uRPF enable (global), 607
MACsec MKA session logging enable, 643 reverse route injection. Use RRI
MACsec preshared key configuration, 639 Revest-Shamir-Adleman Algorithm. Use RSA
MACsec protection parameter configuration, RIPng
641 IPsec RIPng configuration, 430
MACsec protection parameter configuration roaming
(MKA policy), 642 portal authentication roaming, 225
MFF enable, 617 role
NETCONF-over-SSH enable, 480 IPv6 ND attack defense device role, 601
parallel MAC authentication+802.1X MFF port roles, 615
authentication, 188 root CA certificate
password control configuration, 332 fingerprint, 359
password control enable, 332 route
password control parameters (global), 333 IPsec RRI, 404
port security configuration, 298 IPsec RRI configuration, 419
port security enable, 299

734
routing portal authentication filtering, 208
802.1X authentication configuration, 145 portal authentication page file
802.1X authentication guest compression+saving rules, 215
VSI+authorization VSI configuration portal authentication page request rules, 214
(MAC-based), 151 portal authentication portal-free rule, 220
802.1X authentication+ACL assignment portal authentication post request rules, 214
configuration, 149 portal URL redirection match rules configuration,
802.1X authentication+EAD assistant 213
configuration (DHCP relay agent), 153
S
802.1X authentication+EAD assistant
configuration (DHCP server), 156 S/MIME (PKI secure email), 361
802.1X basic configuration, 145 SA
802.1X configuration, 120, 120 IPsec IKEv2 SA rekeying, 462
802.1X guest VLAN configuration, 147 IPsec transform set configuration, 408
IPsec IPv6 routing protocol profile (manual), security IKE SA max, 450
420 troubleshooting IPsec SA negotiation failure
IPsec IPv6 routing protocols configuration, (invalid identity info), 458
420 troubleshooting IPsec SA negotiation failure (no
MFF configuration, 615, 616, 619 transform set match), 458, 472
MFF configuration (in ring network), 620 troubleshooting IPsec SA negotiation failure
MFF configuration (in tree network), 619 (tunnel failure), 473
MFF periodic gateway probe, 618 SAVA
SSH configuration, 474 adding interface to SAVA access group, 660
SSH server configuration, 477 application scenarios, 657
RRI configuration, 656, 658
IPsec RRI configuration, 419, 433 enable, 659
RSA logging configuration, 660
host public key display, 352 remote entry-based SAVA entry creation enabling,
host public key export, 351 659
IPsec IKE signature authentication, 440 SAVA display, 661
peer host public key entry, 354 SAVA maintain, 661
PKI certificate export, 374 SAVI
PKI OpenCA server certificate request, 383 application scenarios, 608
PKI RSA Keon CA server certificate request, configuration, 608, 608, 610
377 deletion delay, 609
PKI Windows 2003 CA server certificate DHCPv6 snooping configuration, 609
request, 379 DHCPv6 snooping configuration restrictions, 609
PKI Windows 2003 CA server IKE DHCPv6+SLAAC configuration, 613
negotiation+RSA digital signature, 386 DHCPv6-only configuration, 610
public key import from file, 356 enable, 608
public key management, 349, 354 IP source guard configuration, 609
SSH client host public key configuration, 480 ND parameter configuration, 609
SSH management parameters, 483 ND parameter configuration restrictions, 609
SSH Secure Telnet server configuration packet spoofing logging and filtering entry logging,
(publickey authentication), 504 610
SSH SFTP client configuration (publickey SLAAC-only configuration, 612
authentication), 522 saving
SSH update interval for RSA server key pair, SFTP file download+local save, 494
483
scheme
rule
AAA HWTACACS, 43
IPsec ACL rule keywords, 406
AAA HWTACACS scheme VPN instance, 47
portal authentication file name rules, 214
AAA LDAP, 51

735
 AAA LDAP scheme creation, 54 server connection establishment restrictions, 487
AAA RADIUS configuration, 21 server public key deletion, 489
AAA RADIUS scheme VPN instance, 26 SSH application, 474
SCP SSH outgoing packet source IP address, 486
client device configuration, 495 SSH outgoing packet source IP address
client local key pair generation, 496 restrictions, 486
client local key pair generation restrictions, security
496 802.1X access control method, 123
configuration, 529 802.1X authenticated user dynamic IPSG binding
configuration (Suite B algorithm), 533 entry generation enable, 140
IPv4 server connection establishment, 497 802.1X authentication, 103
IPv6 server connection establishment, 498 802.1X authentication configuration, 145
outgoing packet source IP address, 496 802.1X authentication guest VSI+authorization
outgoing packet source IP address restrictions, VSI configuration (MAC-based), 151
496 802.1X authentication initiation, 105
password authentication, 529 802.1X authentication request attempts max, 136
server connection establishment, 497 802.1X authentication server timeout timer, 124
server connection establishment (Suite B), 802.1X authentication timeout timer restrictions,
499 124
server connection establishment restrictions, 802.1X authentication trigger, 135
497 802.1X authentication trigger configuration
server enable, 479 restrictions, 135
server enable restrictions, 479 802.1X authentication+ACL assignment
server public key deletion, 498 configuration, 149
SSH application, 474 802.1X authentication+EAD assistant
configuration (DHCP relay agent), 153
secure association (SA)
802.1X authentication+EAD assistant
MACsec, 634
configuration (DHCP server), 156
secure association key (SAK)
802.1X Auth-Fail VLAN, 110, 128
MACsec, 634
802.1X Auth-Fail VLAN configuration restrictions,
secure shell. Use SSH 128
Secure Sockets Layer. Use SSL 802.1X Auth-Fail VLAN/VSI user EAP-Success
Secure Telnet packet, 133
client configuration (password authentication), 802.1X Auth-Fail VSI, 115, 131
510 802.1X Auth-Fail VSI configuration restrictions,
client configuration (publickey authentication), 131
514 802.1X authorization VLAN, 106
client device configuration, 486 802.1X authorization VLAN configuration, 147
client local key pair generation, 486 802.1X authorization VSI, 114
client local key pair generation restrictions, 802.1X basic configuration, 145
486
802.1X client anonymous identifier configuration,
configuration, 501 654
configuration (128-bit Suite B algorithm), 516 802.1X client anonymous identifier configuration
IPv4 server connection establishment, 487 restrictions, 654
IPv6 server connection establishment, 488 802.1X client configuration, 651, 651
server configuration (password 802.1X client display, 655
authentication), 502 802.1X client EAP authentication method, 652
server configuration (publickey authentication), 802.1X client EAP authentication method
504 configuration restrictions, 652
server connection establishment, 487 802.1X client EAP-Response and EAPOL-Logoff
server connection establishment (Suite B), packet sending mode, 653
489 802.1X client enable, 651

736
802.1X client MAC address configuration, 653 802.1X online user handshake configuration
802.1X client SSL client policy, 655 restrictions, 137
802.1X client username+password 802.1X online user synchronization, 134
configuration, 652 802.1X overview, 99
802.1X client username+password 802.1X packet exchange method, 100
configuration restrictions, 652 802.1X port authorization state, 123
802.1X concurrent port users max, 136 802.1X protocol packet VLAN tag removal
802.1X configuration prerequisites, 121 restrictions, 139
802.1X configuration restrictions, 120 802.1X quiet timer restrictions, 126
802.1X critical VLAN, 111, 129 802.1X reauthentication, 125
802.1X critical VLAN configuration restrictions, 802.1X reauthentication restrictions, 125
129 802.1X server-side EAP-TLS fragment maximum
802.1X critical VLAN/VSI user EAP-Success size, 143
packet, 134 802.1X supported domain name delimiter, 138
802.1X critical voice VLAN, 113, 130 802.1X supported domain name delimiter
802.1X critical voice VLAN enable restrictions, restrictions, 138
130 802.1X unauthenticated user aging, 132
802.1X critical VSI, 115, 132 802.1X user IP freezing enable, 140
802.1X critical VSI configuration restrictions, 802.1X user logging configuration restrictions,
132 144
802.1X display, 144 AAA concurrent login user max, 62
802.1X duplicate EAPOL-Start request AAA configuration, 1, 15, 69
discarding, 136 AAA connection recording policy configuration, 66
802.1X EAD assistant, 142 AAA EAP profile, 22
802.1X EAD assistant configuration AAA HWTACACS, 43
restrictions, 142
AAA HWTACACS implementation, 5
802.1X EAP relay enable, 122
AAA HWTACACS protocols and standards, 14
802.1X EAP relay enable restrictions, 122
AAA HWTACACS scheme, 44
802.1X EAP termination enable, 122
AAA HWTACACS server SSH user, 69
802.1X EAP termination enable restrictions,
AAA ISP domain accounting method, 61
122
AAA ISP domain accounting method
802.1X enable, 122
configuration restrictions, 61
802.1X enable restrictions, 122
AAA ISP domain attribute, 57
802.1X guest VLAN, 109, 126
AAA ISP domain authentication method, 59
802.1X guest VLAN assignment delay, 127
AAA ISP domain authentication method
802.1X guest VLAN configuration, 147 configuration restrictions, 59
802.1X guest VLAN configuration restrictions, AAA ISP domain authorization method, 60
126
AAA ISP domain authorization method
802.1X guest VSI, 114, 130 configuration restrictions, 60
802.1X guest VSI assignment delay, 131 AAA ISP domain configuration restrictions, 56
802.1X guest VSI configuration restrictions, AAA ISP domain creation, 56
130
AAA ISP domain display, 62
802.1X MAC address binding, 141
AAA ISP domain method, 59
802.1X MAC address binding configuration
AAA LDAP, 51
restrictions, 141
AAA LDAP implementation, 8
802.1X MAC user authentication attempts
max, 139 AAA LDAP protocols and standards, 14
802.1X maintain, 144 AAA LDAP server SSH user authentication, 76
802.1X mandatory port authentication domain, AAA local user, 16
124 AAA protocols and standards, 14
802.1X online user handshake, 137 AAA RADIUS attribute translation, 36
AAA RADIUS client configuration, 65

737
AAA RADIUS configuration, 21 ARP attack protection configuration (user+packet
AAA RADIUS DAE server (DAS), 41 validity check), 584
AAA RADIUS device server feature, 13 ARP attack protection filtering configuration
AAA RADIUS implementation, 2 restrictions, 590
AAA RADIUS information exchange security ARP attack protection gateway protection
mechanism, 2 restrictions, 589
AAA RADIUS packet DSCP priority, 32 ARP attack protection packet rate limit
configuration restrictions, 570
AAA RADIUS protocols and standards, 14
ARP attack protection restricted forwarding
AAA RADIUS server 802.1X user, 79
configuration, 586
AAA RADIUS server 802.1X user
ARP attack protection restricted forwarding
authentication+authorization, 86
restrictions, 580
AAA RADIUS server configuration, 64, 65
ARP attack protection scanning+fixed ARP
AAA RADIUS server SSH user configuration restrictions, 588
authentication+authorization, 73
ARP attack protection source MAC-based attack
AAA RADIUS server status detection test detection restrictions, 571
profile, 23
ARP attack protection source suppression
AAA RADIUS session-control, 40 (unresolvable IP attack), 568
AAA RADIUS session-control configuration ARP attack protection unresolvable IP attack
restrictions, 40 blackhole routing restrictions, 568
AAA RADIUS timer configuration restrictions, ARP attack protection user validity check, 583
28
ARP attack protection user validity check
AAA SSH user local configuration restrictions, 578
authentication+HWTACACS
ARP filtering configuration, 590, 591
authorization+RADIUS accounting, 71
ARP gateway protection, 589, 589
AAA VPN implementation, 13
ARP packet rate limit, 570
adding interface to SAVA access group, 660
ARP packet source MAC consistency check, 573
allowing only DHCP users to pass portal
authorization, 225 ARP scanning+fixed ARP configuration, 587
ARP active acknowledgement, 573 ARP sender IP address checking, 592, 592
ARP attack detection (source MAC-based), ARP sender IP address checking restrictions, 592
571, 572 association. See SA
ARP attack detection configuration, 577 attack D&P configuration, 548
ARP attack detection configuration (VSI), 581 attack D&P device-preventable attacks, 548
ARP attack detection display, 583 authorized ARP configuration, 574
ARP attack detection logging enable, 582 authorized ARP configuration (DHCP relay agent),
ARP attack detection maintain, 583 575
ARP attack detection packet validity check, authorized ARP configuration (DHCP server), 574
579 captive-bypass feature enabling, 212
ARP attack detection packet validity check configuring SAVA on border devices directly
(VSI), 582 connected the LAN configuration (on switch), 661
ARP attack detection restricted forwarding, configuring SAVA on border devices indirectly
580 connected the LAN (IPv6 IS-IS) configuration (on
ARP attack detection user validity check switch), 666
configuration, 577 configuring SAVA on border devices indirectly
ARP attack detection user validity check connected the LAN (OSPFv3) configuration (on
configuration (VSI), 581 switch), 662
ARP attack detection user validity check configuring SAVA on inter-AS border devices
ingress port, 581 directly connected the LAN configuration (on
switch), 670
ARP attack protection (unresolvable IP attack),
567, 569 cross-subnet portal authentication configuration,
244
ARP attack protection blackhole routing
(unresolvable IP attack), 568 crypto engine configuration, 633
ARP attack protection configuration, 567 crypto engine display, 633

738
crypto engine maintain, 633 IPsec IKE profile configuration, 442
DHCP relay agent-based dynamic IPv4SG IPsec IKE protocols and standards, 440
configuration, 562 IPsec IKEv2 configuration, 461
DHCP snooping-based dynamic IPv4SG IPsec IKEv2 display, 471
configuration (wired network), 561 IPsec IKEv2 maintain, 471
DHCPv6 relay agent-based dynamic IPv6SG IPsec IKEv2 policy configuration, 467
configuration, 565
IPsec IKEv2 profile configuration, 463
DHCPv6 snooping-based dynamic IPv6SG
IPsec IKEv2 protocols and standards, 462
address binding configuration (wired network),
563 IPsec implementation (ACL-based), 405
DHCPv6 snooping-based dynamic IPv6SG IPsec IPv6 routing protocols, 420
prefix binding configuration (wired network), IPsec maintain, 424
564 IPsec packet DF bit, 419
digital certificate retrieval, usage, and IPsec packet logging enable, 423
maintenance, 361 IPsec policy configuration restrictions, 411
direct portal authentication configuration, 235 IPsec policy configuration restrictions
direct portal authentication configuration (local (IKE-based), 412
portal Web service), 264 IPsec protocols and standards, 405
disabling SSL protocol version, 546 IPsec QoS pre-classify enable, 418
enabling logging for portal user login/logout, IPsec RRI, 404
233 IPsec RRI configuration, 419
enabling ND attack detection (interface), 597 IPsec SNMP notification, 423
expired password login, 330 IPSG configuration (wired network), 551, 553,
extended cross-subnet portal authentication 560
configuration, 255 IPSG dynamic binding (wired network), 552
extended direct portal authentication IPSG static binding (wired network), 551
configuration, 248
IPv4SG alarming enable (wired network), 556
extended re-DHCP portal authentication
IPv4SG configuration (wired network), 553
configuration, 251
IPv4SG enable (wired network), 553
FIPS, 622
IPv4SG interface enable restrictions (wired
FIPS configuration, 622, 628
network), 553
FIPS configuration restrictions, 623
IPv4SG static binding configuration (wired
FIPS display, 628 network), 554
FIPS mode entry, 624 IPv4SG static binding configuration restrictions
FIPS mode entry (automatic reboot), 628 (wired network), 554
FIPS mode entry (manual reboot), 629 IPv6 ND attack defense configuration, 595
FIPS mode exit, 627 IPv6 ND attack defense device role, 601
FIPS mode exit (automatic reboot), 631 IPv6 ND attack defense device role restrictions,
FIPS mode exit (manual reboot), 631 601
FIPS mode system changes, 624 IPv6 ND attack defense RA guard configuration,
global IPsec IKE DPD, 449 601, 603
host public key export, 351 IPv6 ND attack defense RA guard display, 603
IP, 399, See also IPsec IPv6 ND attack defense RA guard logging enable,
IPsec anti-replay configuration, 416 603
IPsec configuration, 399, 425 IPv6 ND attack defense RA guard maintain, 603
IPsec display, 424 IPv6 ND attack defense RA guard policy, 602
IPsec fragmentation, 422 IPv6 ND attack detection configuration, 599
IPsec IKE configuration, 438, 451 IPv6 ND attack detection configuration
restrictions, 597
IPsec IKE display, 451
IPv6 source guard (IPv6SG) binding max
IPsec IKE keepalive, 448
(interface), 558
IPsec IKE maintain, 451
IPv6SG alarming enable (wired network), 558
IPsec IKE mechanism, 440
IPv6SG configuration (wired network), 556

739
IPv6SG enable (wired network), 556 MAC authentication guest VSI configuration
IPv6SG interface enable restrictions (wired restrictions, 180
network), 556 MAC authentication guest VSI reauthentication,
IPv6SG static binding configuration (wired 180
network), 557 MAC authentication maintain, 191
IPv6SG static binding configuration MAC authentication method, 173
restrictions (wired network), 557 MAC authentication multi-VLAN mode, 185
keychain configuration, 342, 342, 343, 343 MAC authentication multi-VLAN mode
keychain display, 343 configuration, 185
local host public key distribution, 351 MAC authentication offline detection configuration,
local key pair creation, 350 182
local key pair destruction, 354 MAC authentication online user synchronization,
local portal Web service, 205 183
logging off 802.1X user, 143 MAC authentication port guest VLAN, 177
logging off MAC authentication user, 190 MAC authentication port guest VSI, 180
MAC authentication, 171, 192 MAC authentication redirect URL assignment,
169
MAC authentication (local), 192
MAC authentication request user IP address, 186
MAC authentication (RADIUS-based), 194
MAC authentication request user IP address
MAC authentication ACL assignment, 167,
inclusion restrictions, 186
196
MAC authentication timer, 175
MAC authentication authorization VSI
assignment, 199 MAC authentication unauthenticated user aging,
182
MAC authentication blackhole attribute
assignment, 169 MAC authentication user account policies, 159
MAC authentication CAR attribute assignment, MAC authentication user account policy, 174
169 MAC authentication user logging configuration
MAC authentication concurrent port users restrictions, 190
max, 184 MAC authentication user profile assignment, 168
MAC authentication configuration, 159 MAC authentication VLAN assignment, 161
MAC authentication configuration restrictions, MAC authentication Web proxy port URL
171 redirection configuration, 189
MAC authentication critical VLAN, 178 MAC security. Use MACsec
MAC authentication critical VLAN MACsec application mode, 635
configuration restrictions, 178 MACsec configuration, 634, 638, 644
MAC authentication critical voice VLAN, 179 MACsec configuration (client-oriented), 644
MAC authentication critical VSI, 181 MACsec configuration (device-oriented), 646
MAC authentication critical VSI configuration MACsec desire enable, 639
restrictions, 181 MACsec display, 643
MAC authentication delay, 185, 185 MACsec hardware compatibility restrictions, 638
MAC authentication delay configuration MACsec maintain, 643
restrictions, 185 MACsec MKA enable, 638
MAC authentication display, 191 MACsec MKA key server priority, 640
MAC authentication domain, 173 MACsec MKA key server priority configuration
MAC authentication enable, 172 restrictions, 640
MAC authentication enable restrictions, 172 MACsec MKA life time, 640
MAC authentication guest VLAN, 177 MACsec MKA session logging enable restrictions,
MAC authentication guest VLAN configuration 643
restrictions, 177 MACsec preshared key, 639
MAC authentication guest VLAN MACsec preshared key configuration restrictions,
reauthentication, 177 639
MAC authentication guest VSI, 180 MACsec protection parameter configuration
restrictions, 641

740
MACsec protection parameter configuration peer host public key configuration, 352
restrictions (MKA policy), 642 peer host public key entry, 353, 354
MACsec protection parameters, 640 peer host public key import from file, 353
MACsec protocols and standards, 637 periodic 802.1X reauthentication, 118
MACsec secure association (SA), 634 periodic MAC reauthentication, 169, 176
MACsec secure association key (SAK), 634 PKI applications, 361
MACsec services, 635 PKI architecture, 360
MFF configuration, 615, 616, 619 PKI CA policy, 360
MFF configuration (in ring network), 620 PKI certificate export, 374
MFF configuration (in tree network), 619 PKI certificate import/export configuration, 388
MFF default gateway, 616 PKI certificate obtain, 371
MFF display, 618 PKI certificate removal, 374
MFF enable, 617 PKI certificate request, 368, 368
MFF enable restrictions, 617 PKI certificate request abort, 370
MFF network port, 616, 617 PKI certificate request submission in offline mode,
MFF periodic gateway probe, 618 370
MFF port roles, 615 PKI certificate verification, 372
MFF protocols and standards, 616 PKI certificate verification (CRL checking), 373
MFF server IP address, 618 PKI certificate verification (w/o CRL checking),
MFF user port, 615 373
NETCONF-over-SSH client user line, 480 PKI certificate-based access control policy, 375
NETCONF-over-SSH configuration, 539 PKI configuration, 359, 361, 376
NETCONF-over-SSH enable, 480 PKI CRL, 359
NETCONF-over-SSH enable restrictions, 480 PKI digital certificate, 359
NETCONF-over-SSH+password PKI display, 376
authentication configuration, 539 PKI domain configuration, 363, 363
parallel MAC authentication+802.1X PKI entity configuration, 362, 362
authentication, 187 PKI online certificate request (manual), 369
password control configuration, 328, 332, 338 PKI online certificate request mode (automatic),
password control configuration restrictions, 369, 369
332 PKI OpenCA server certificate request, 383
password control display, 338 PKI RSA Keon CA server certificate request, 377
password control enable, 332 PKI storage path, 367
password control enable restrictions, 332 PKI terminology, 359
password control maintain, 338 PKI Windows 2003 CA server certificate request,
password control parameter restrictions 379
(global), 333 PKI Windows 2003 CA server IKE
password control parameters (global), 333 negotiation+RSA digital signature, 386
password control parameters (local user), 336 port. See port security
password control parameters (super), 337 port security display, 312
password control parameters (user group), portal authentication access device ID, 230
335 portal authentication advantages, 203
password event logging, 331 portal authentication BAS-IP, 230
password expiration, 329, 329 portal authentication check category-2 portal
password expiration early notification, 330 filtering rule issuing, 223
password history, 330 portal authentication client Rule ARP entry
password not displayed, 331 feature, 233
password setting, 328 portal authentication client Rule ND entry feature,
password updating, 329, 329 233
password user first login, 330 portal authentication configuration, 203, 209, 235
password user login control, 330 portal authentication destination subnet, 222

741
portal authentication detection, 226 RESTful server-assisted MAC authentication user
portal authentication display, 234 recovery, 170
portal authentication domain, 219 RESTful server-assisted MAC authentication user
portal authentication EAP support, 208 recovery configuration, 188
portal authentication enable (interface), 216 SAVA application scenarios, 657
portal authentication fail-permit, 226 SAVA configuration, 656, 658
portal authentication filtering rules, 208 SAVA display, 661
portal authentication local portal Web service SAVA logging configuration, 660
parameter configuration, 216 SAVA maintain, 661
portal authentication maintain, 234 SAVI application scenarios, 608
portal authentication online user logout, 232 SAVI configuration, 608, 608, 610
portal authentication page customization, 214 SAVI configuration (DHCPv6+SLAAC), 613
portal authentication policy server, 204 SAVI configuration (DHCPv6-only), 610
portal authentication process, 206 SAVI configuration (SLAAC-only), 612
portal authentication roaming, 225 SAVI deletion delay, 609
portal authentication security check function, SAVI DHCPv6 snooping configuration, 609
203 SAVI DHCPv6 snooping configuration restrictions,
portal authentication server detection, 227 609
portal authentication server detection+user SAVI IP source guard configuration, 609
synchronization configuration, 259 SAVI ND parameter configuration restrictions,
portal authentication source subnet, 221 609
portal authentication system component SAVI ND parameters, 609
interaction, 204 SAVI packet spoofing logging and filtering entry
portal authentication troubleshooting, 267 logging, 610
portal authentication user access control, 220 Secure Telnet client local key pair generation, 486
portal authentication user online detection, Secure Telnet client user line, 480
226 SSH authentication methods, 475
portal authentication user setting max, 223 SSH client host public key configuration, 480
portal authentication user synchronization, SSH client host public key configuration
229 restrictions, 481
portal authentication Web proxy support, 222 SSH configuration, 474
portal authentication Web redirect, 234 SSH display, 501
portal authentication Web server detection, SSH local key pair configuration restrictions, 478
228 SSH management parameters, 483
portal authorization strict-checking mode, 224 SSH SCP client device, 495
portal packet attributes configuration, 230 SSH SCP client local key pair generation, 496
portal URL redirection match rules SSH SCP configuration, 529
configuration, 213 SSH SCP configuration (Suite B algorithm), 533
portal user preauthentication IP address pool, SSH SCP outgoing packet source IP address,
218 496
public key display, 354 SSH SCP server connection establishment, 497
public key import from file, 356 SSH SCP server connection establishment (Suite
public key local key pair creation restrictions, B), 499
350 SSH SCP server enable, 479
public key management, 349, 354 SSH SCP server enable restrictions, 479
RADIUS packet attributes configuration, 231 SSH SCP server public key deletion, 498
re-DHCP portal authentication configuration, SSH SCP+Linux client, 531
241
SSH SCP+password authentication, 529
remote entry-based SAVA entry creation
SSH Secure Telnet client configuration (password
enabling, 659
authentication), 510
remote portal authentication server, 211
SSH Secure Telnet client configuration (publickey
authentication), 514

742
SSH Secure Telnet client device, 486 SSH SFTP server public key deletion, 492
SSH Secure Telnet configuration, 501 SSH Suite B support, 476
SSH Secure Telnet configuration based on SSH user configuration, 482
(128-bit Suite B algorithm), 516 SSH user configuration restrictions, 482
SSH Secure Telnet outgoing packet source IP SSH X.509v3 certificate, 476
address, 486 SSH2 algorithms, 499
SSH Secure Telnet outgoing packet source IP SSH2 algorithms (encryption), 500
address restrictions, 486
SSH2 algorithms (key exchange), 499
SSH Secure Telnet server configuration
SSH2 algorithms (MAC), 500
(password authentication), 502
SSH2 algorithms (public key), 500
SSH Secure Telnet server configuration
(publickey authentication), 504 SSL client configuration, 544
SSH Secure Telnet server connection SSL client policy configuration, 545
establishment, 487 SSL configuration, 542, 543
SSH Secure Telnet server connection SSL display, 547
establishment (Suite B), 489 SSL security services, 542
SSH Secure Telnet server connection SSL server configuration, 543
establishment restrictions, 487 SSL server policy configuration, 544
SSH Secure Telnet server enable, 479 SSL session renegotiation disable, 546
SSH Secure Telnet server public key deletion, static IPv4SG configuration (wired network), 560
489 static IPv6SG configuration (wired network), 563
SSH server configuration, 477 TCP attack prevention (Naptha attack), 550
SSH server local key pair generation, 478 TCP attack prevention configuration, 550
SSH server PKI domain, 485 triple authentication basic configuration, 285
SSH server port, 478 triple authentication configuration, 283, 285, 285
SSH server port specification restrictions, 478 triple authentication configuration (authorization
SSH session disconnect, 485 VLAN+Auth-Fail VLAN), 289
SSH SFTP client configuration (publickey troubleshooting 802.1X EAD assistant URL
authentication), 522 redirection failure, 158
SSH SFTP client device, 489 troubleshooting AAA, 88
SSH SFTP client local key pair generation, troubleshooting AAA HWTACACS, 89
490 troubleshooting AAA LDAP authentication failure,
SSH SFTP configuration, 520 89
SSH SFTP configuration (192-bit Suite B troubleshooting AAA RADIUS accounting error,
algorithm), 525 89
SSH SFTP directories, 493 troubleshooting AAA RADIUS authentication
SSH SFTP files, 494 failure, 88
SSH SFTP help information display, 495 troubleshooting AAA RADIUS packet delivery
SSH SFTP outgoing packet source IP address, failure, 88
490 troubleshooting IPsec IKE, 456
SSH SFTP outgoing packet source IP address troubleshooting IPsec IKEv2, 472
restrictions, 490 troubleshooting MACsec, 650
SSH SFTP server configuration (password troubleshooting MACsec device cannot establish
authentication), 520 MKA session, 650
SSH SFTP server connection establishment, troubleshooting PKI CA certificate failure, 394
491 troubleshooting PKI CA certificate import failure,
SSH SFTP server connection establishment 396
(Suite B), 493 troubleshooting PKI certificate export failure, 397
SSH SFTP server connection establishment troubleshooting PKI configuration, 393
restrictions, 491
troubleshooting PKI CRL obtain failure, 396
SSH SFTP server connection termination, 495
troubleshooting PKI local certificate failure, 394
SSH SFTP server enable, 479
troubleshooting PKI local certificate import failure,
SSH SFTP server enable restrictions, 479 397

743
 troubleshooting PKI local certificate request 802.1X guest VLAN configuration, 147
failure, 395 AAA HWTACACS quiet timer, 47
troubleshooting PKI storage path set failure, AAA HWTACACS response timeout timer, 47
398 AAA LDAP timeout period, 52
troubleshooting Web authentication failure to AAA RADIUS configuration, 65
come online, 282
AAA RADIUS quiet timer, 28
uRPF configuration, 606
AAA RADIUS response timeout timer, 28
uRPF display, 607
AAA RADIUS server configuration, 64
uRPF enable (global), 607
AAA RADIUS server load sharing, 38
uRPF enable restrictions (global), 607
local portal authentication service, 213
user login with weak password, 331
MAC authentication server timeout timer, 175
user profile configuration, 323, 323, 324
MACsec MKA key server priority, 640
user profile display, 323
MFF server IP address, 618
user profile+QoS policy configuration, 324
PKI OpenCA server certificate request, 383
Web authentication Auth-Fail VLAN, 277
PKI Windows 2003 CA server certificate request,
Web authentication configuration, 270, 273, 379
278
port security authorization information ignore, 305
Web authentication configuration (local
portal authentication AAA server, 204
authentication server), 278
portal authentication fail-permit, 226
Web authentication configuration (RADIUS
authentication server), 280 portal authentication local portal Web service
parameter, 216
Web authentication display, 278
portal authentication policy server, 204
Web authentication domain, 275
portal authentication server detection, 227
Web authentication enable, 274
portal authentication system, 203
Web authentication process, 271
portal authentication Web server (interface), 217
Web authentication proxy support, 277
portal authentication Web server detection, 228
Web authentication server, 274
portal server, 204
Web authentication troubleshooting, 282
remote portal authentication Web server, 212
Web authentication user online detection, 276
RESTful server-assisted MAC authentication user
Web authentication user setting max, 276
recovery configuration, 188
security services
SSL server policy configuration, 544
IPsec, 399
Web authentication server configuration, 274
sending
Web authentication system components, 270
802.1X Auth-Fail VLAN/VSI user
server-unreachable VLAN
EAP-Success packet, 133
triple authentication, 284
802.1X client EAP-Response and
EAPOL-Logoff packet sending mode, 653 service
802.1X critical VLAN/VSI user EAP-Success MACsec data encryption, 635
packet, 134 MACsec integrity check, 635
server MACsec replay protection, 635
802.1X authentication configuration, 145 session
802.1X authentication server timeout timer, AAA RADIUS session-control, 40
124 SSH SCP client key pair, 496
802.1X authentication+ACL assignment SSH SFTP client key pair, 490
configuration, 149 setting
802.1X authentication+EAD assistant 802.1X authentication request attempts max, 136
configuration (DHCP relay agent), 153 802.1X authentication timeout timer, 124
802.1X authentication+EAD assistant 802.1X concurrent port users max, 136
configuration (DHCP server), 156
802.1X MAC user authentication attempts max,
802.1X authorization VLAN configuration, 147 139
802.1X basic configuration, 145 802.1X port authorization state, 123
802.1X configuration, 120, 120 802.1X quiet timer, 126

744
 802.1X server-side EAP-TLS fragment client configuration (publickey authentication),
maximum size, 143 522
AAA concurrent login user max, 62 client device configuration, 489
AAA HWTACACS timer, 47 client local key pair generation, 490
AAA HWTACACS traffic statistics unit, 49 client local key pair generation restrictions, 490
AAA HWTACACS username format, 49 configuration, 520
AAA ISP domain status, 57 configuration (192-bit Suite B algorithm), 525
AAA LDAP server timeout period, 52 connection idle timeout timer, 485
AAA RADIUS packet DSCP priority, 32 directories, 493
AAA RADIUS real-time accounting attempts directory deletion, 494
max, 31 directory file display, 493, 494
AAA RADIUS Remanent_Volume attribute directory name change, 493
data measurement unit, 35 file deletion, 494
AAA RADIUS request transmission attempts file download+local save, 494
max, 31
file name change, 494
AAA RADIUS server status, 27
files, 494
AAA RADIUS timer, 28
help information display, 495
AAA RADIUS traffic statistics unit, 30
IPv4 server connection establishment, 491
AAA RADIUS username format, 30
IPv6 server connection establishment, 492
IPsec IKE SA max, 450
local file upload, 494
IPsec packet DF bit set, 419
new directory creation, 494
IPsec tunnel max, 423
outgoing packet source IP address, 490
IPv6 source guard (IPv6SG) binding max
outgoing packet source IP address restrictions,
(interface), 558
490
MAC authentication concurrent port users
server configuration (password authentication),
max, 184
520
MACsec MKA life time, 640
server connection establishment, 491
password, 328
server connection establishment (Suite B), 493
password control parameters (global), 333
server connection establishment restrictions, 491
password control parameters (local user), 336
server connection termination, 495
password control parameters (super), 337
server enable, 479
password control parameters (user group),
server enable restrictions, 479
335
server public key deletion, 492
port security MAC address limit per port VLAN,
307 SSH application, 474
port security mode, 300 SSH management parameters, 483
portal authentication users max, 223 working directory change, 493
portal authentication users max (global), 224 working directory display, 493
portal authentication users max (interface), shared key
224 AAA HWTACACS, 46
SAVI deletion delay, 609 AAA RADIUS, 26
SSH authentication attempt max number, 484 signature authentication (IKE), 440
SSH online user max number, 485 SLAAC
SSH server packet DSCP value, 484 SAVI configuration (DHCPv6+SLAAC), 613
SSH SFTP connection idle timeout timer, 485 SAVI configuration (SLAAC-only), 612
SSH update interval for RSA server key pair, SNMP
483 AAA RADIUS notifications, 41
SSH user authentication timeout timer, 484 IPsec IKE SNMP notification, 450
Web authentication redirection wait time, 275 IPsec SNMP notification, 423
Web authentication users max, 276 port security enable, 311
SFTP snooping
SAVI configuration, 608, 608, 610

745
 SAVI configuration (DHCPv6+SLAAC), 613 AAA RADIUS accounting server, 25
SAVI configuration (DHCPv6-only), 610 AAA RADIUS authentication server, 24
SAVI configuration (SLAAC-only), 612 AAA RADIUS client, 65
software AAA RADIUS outgoing packet source interface
crypto engine configuration, 633 (all schemes), 30
source AAA RADIUS outgoing packet source interface
ARP attack detection (source MAC-based), (single scheme), 30
571, 572 AAA RADIUS outgoing packet source IP address,
ARP attack detection src-mac validity check, 29
579 AAA RADIUS outgoing packet source IP address
IPsec source interface policy bind, 417 (all schemes), 30
portal authentication portal-free rule, 220 AAA RADIUS outgoing packet source IP address
(single scheme), 30
portal authentication subnet, 221
AAA RADIUS scheme VPN instance, 26
Source Address Validation Improvement. Use
SAVI AAA RADIUS server selection mode for
reauthentication, 39
Source Address Validation Architecture. Use SAVA
AAA RADIUS shared keys, 26
source MAC
certificate intended purpuse, 366
IPv6 ND attack defense source consistency
check configuration, 596 certificate request key pair, 366
specifying certificate request reception authority, 364
802.1X access control method, 123 certificate request URL, 365
802.1X client EAP authentication method, 652 IKE IKE proposals for IKE profile, 443
802.1X client EAP authentication method inside VPN instance for IKE profile, 444
(Ethernet interface view), 653 inside VPN instance for IKEv2 profile, 466
802.1X client EAP-Response and IPv6 ND attack defense device role, 601
EAPOL-Logoff packet sending mode, 653 LDAP server, 365
802.1X client SSL client policy, 655 MAC authentication domain, 173
802.1X mandatory port authentication domain, MAC authentication method, 173
124 MAC authentication port guest VLAN, 177
802.1X supported domain name delimiter, 138 MAC authentication port guest VSI, 180
AAA HWTACACS accounting server, 45 MFF server IP address, 618
AAA HWTACACS authentication server, 44 PKI entity name, 364
AAA HWTACACS authorization server, 45 PKI protocol packets source IP address, 367
AAA HWTACACS outgoing packet source PKI storage path, 367
interface (all schemes), 49 portal authentication access device ID, 230
AAA HWTACACS outgoing packet source portal authentication domain, 219
interface (single scheme), 49
portal authentication domain (interface), 220
AAA HWTACACS outgoing packet source IP
portal authentication NAS-Port-Id attribute format,
address, 48
231
AAA HWTACACS outgoing packet source IP
portal authentication Web server (interface), 217
address (all schemes), 49
portal user preauthentication IP address pool, 218
AAA HWTACACS outgoing packet source IP
address (single scheme), 49 root CA certificate verification fingerprint, 365
AAA HWTACACS scheme VPN instance, 47 SCEP polling interval and maximum polling
attempts, 365
AAA HWTACACS shared keys, 46
SSH SCP outgoing packet source IP address,
AAA ISP domain, 57
496
AAA ISP domain for users that are assigned to
SSH Secure Telnet outgoing packet source IP
nonexistent domains, 57
address, 486
AAA LDAP attribute map for authorization, 55
SSH server PKI domain, 485
AAA LDAP authentication server, 55
SSH server port, 478
AAA LDAP authorization server, 55
SSH SFTP outgoing packet source IP address,
AAA LDAP version, 52 490

746
 SSH user connection control ACL, 484 SCP client device, 495
SSH2 algorithms, 499 SCP client local key pair generation, 496
trusted CA, 364 SCP client local key pair generation restrictions,
Web authentication domain, 275 496
SPI SCP configuration, 529
IPsec IKE invalid SPI recovery, 449 SCP configuration (Suite B algorithm), 533
spoofing SCP outgoing packet source IP address, 496
uRPF configuration, 606 SCP outgoing packet source IP address
SSH restrictions restrictions, 496
AAA HWTACACS server SSH user, 69 SCP server connection establishment, 497
AAA LDAP server SSH user authentication, SCP server connection establishment (Suite B),
76 499
AAA RADIUS Login-Service attribute check SCP server connection establishment restrictions,
method, 32 497
AAA RADIUS server SSH user SCP server enable, 479
authentication+authorization, 73 SCP server enable restrictions, 479
AAA SSH user local SCP server public key deletion, 498
authentication+HWTACACS SCP+Linux client, 531
authorization+RADIUS accounting, 71 SCP+password authentication, 529
authentication methods, 475 Secure Copy. Use SCP
client host public key configuration, 480 Secure FTP. Use SFTP
client host public key configuration restrictions, Secure Telnet, 474
481 Secure Telnet client configuration (password
configuration, 474 authentication), 510
display, 501 Secure Telnet client configuration (publickey
FIPS compliance, 477 authentication), 514
how it works, 474 Secure Telnet client device, 486
IPv4 SCP server connection establishment, Secure Telnet client local key pair generation
497 restrictions, 486
IPv4 Secure Telnet server connection Secure Telnet client user line, 480
establishment, 487 Secure Telnet configuration, 501
IPv4 SFTP server connection establishment, Secure Telnet configuration (128-bit Suite B
491 algorithm), 516
IPv6 SCP server connection establishment, Secure Telnet outgoing packet source IP address,
498 486
IPv6 Secure Telnet server connection Secure Telnet outgoing packet source IP address
establishment, 488 restrictions, 486
IPv6 SFTP server connection establishment, Secure Telnet server configuration (password
492 authentication), 502
local key pair configuration restrictions, 478 Secure Telnet server configuration (publickey
login control ACL attempts denied logging, authentication), 504
484 Secure Telnet server connection establishment,
management parameter configuration, 483 487
NETCONF, 474 Secure Telnet server connection establishment
NETCONF-over-SSH client user line, 480 (Suite B), 489
NETCONF-over-SSH configuration, 539 Secure Telnet server connection establishment
NETCONF-over-SSH enable, 480 restrictions, 487
NETCONF-over-SSH enable restrictions, 480 Secure Telnet server enable, 479
NETCONF-over-SSH+password Secure Telnet server public key deletion, 489
authentication configuration, 539 server configuration, 477
public key management, 349 server PKI domain, 485
SCP, 474 server port specification, 478

747
 server port specification restrictions, 478 PKI configuration, 359, 361, 376
session disconnect, 485 PKI Web application, 361
SFTP, 474 protocol stack, 542
SFTP client configuration (publickey public key management, 349
authentication), 522 security services, 542
SFTP client device, 489 server configuration, 543
SFTP client local key pair, 490 server policy configuration, 544
SFTP configuration, 520 SSL protocol version
SFTP configuration (192-bit Suite B algorithm), disabling, 546
525 static
SFTP directories, 493 IPSG static binding (wired network), 551
SFTP files, 494 IPv4SG configuration (wired network), 560
SFTP help information display, 495 IPv4SG static binding configuration (wired
SFTP outgoing packet source IP address, 490 network), 554
SFTP outgoing packet source IP address IPv6SG configuration (wired network), 563
restrictions, 490 IPv6SG static binding configuration (wired
SFTP server configuration (password network), 557
authentication), 520 port security static secure MAC address, 302
SFTP server connection establishment, 491 statistics
SFTP server connection establishment (Suite AAA HWTACACS traffic statistics units, 49
B), 493
AAA RADIUS traffic statistics units, 30
SFTP server connection establishment
sticky
restrictions, 491
port security secure MAC address, 302
SFTP server connection termination, 495
port security secure MAC address add, 303
SFTP server enable, 479
storage
SFTP server enable restrictions, 479
PKI storage path, 367
SFTP server public key deletion, 492
troubleshooting PKI storage path set failure, 398
SSH2 algorithms, 499
strict-checking mode (portal authentication), 224
SSH2 algorithms (encryption), 500
submitting
SSH2 algorithms (key exchange), 499
PKI certificate request in offline mode, 370
SSH2 algorithms (MAC), 500
subnetting
SSH2 algorithms (public key), 500
cross-subnet portal authentication configuration,
Suite B support, 476
244
user configuration, 482
extended cross-subnet portal authentication
user configuration restrictions, 482 configuration, 255
versions, 474 portal authentication cross-subnet mode, 206
X.509v3 certificate, 476 portal authentication destination subnet, 222
SSH2 portal authentication direct/cross-subnet
algorithms, 499 authentication process (CHAP/PAP
algorithms (encryption), 500 authentication), 206
algorithms (key exchange), 499 portal authentication source subnet, 221
algorithms (MAC), 500 Web authentication-free subnet, 276
algorithms (public key), 500 super password control parameters, 337
SSL suppressing
802.1X client SSL client policy, 655 ARP attack protection source suppression
client configuration, 544 (unresolvable IP attack), 568
client policy configuration, 545 synchronizing
configuration, 542, 543 802.1X online user synchronization enable, 134
disabling session renegotiation, 546 MAC authentication online user synchronization
display, 547 enable, 183
FIPS compliance, 543 portal authentication server detection+user
synchronization configuration, 259

748
 portal authentication user synchronization, AAA HWTACACS implementation, 5
229 attack D&P TCP fragment attack, 548
system administration attack D&P TCP fragment attack prevention
attack D&P configuration, 548 configuration, 548
attack D&P login delay, 549 attack prevention configuration, 550
attack D&P TCP fragment attack prevention, SSL configuration, 542, 543
548 TCP attack prevention
FIPS configuration, 622, 628 configuration, 550
FIPS mode entry (automatic reboot), 628 Telnet
FIPS mode entry (manual reboot), 629 Secure Telnet server public key deletion, 489
FIPS mode exit (automatic reboot), 631 SSH SCP server connection establishment (Suite
FIPS mode exit (manual reboot), 631 B), 499
FIPS mode system changes, 624 SSH Secure Telnet client configuration (password
IPsec authentication, 401 authentication), 510
IPsec configuration, 399 SSH Secure Telnet client configuration (publickey
IPsec encryption, 401 authentication), 514
IPsec IKE configuration, 438, 451 SSH Secure Telnet client device, 486
IPsec IKE global identity information, 447 SSH Secure Telnet configuration, 501
IPsec IKE invalid SPI recovery, 449 SSH Secure Telnet configuration (128-bit Suite B
algorithm), 516
IPsec IKE keychain, 446
SSH Secure Telnet outgoing packet source IP
IPsec IKE proposal, 445
address, 486
IPsec IKE SA max, 450
SSH Secure Telnet server configuration
IPsec IKE SNMP notification, 450 (password authentication), 502
IPsec IKEv2 configuration, 461 SSH Secure Telnet server configuration
IPsec IKEv2 cookie challenge, 470 (publickey authentication), 504
IPsec IKEv2 global parameters, 470 SSH Secure Telnet server connection
IPsec IKEv2 keychain, 469 establishment, 487
IPsec IKEv2 proposal, 468 SSH Secure Telnet server connection
IPsec tunnel max, 423 establishment (Suite B), 489
password control configuration, 328, 332, 338 SSH SFTP server connection establishment
portal authentication configuration, 203 (Suite B), 493
Secure Telnet client local key pair generation, terminal
486 AAA RADIUS Login-Service attribute check
SSH authentication methods, 475 method, 32
SSH configuration, 474 terminating
SSH SCP client local key pair generation, 496 SSH SFTP server connection, 495
SSH server local key pair generation, 478 test profile
SSH SFTP client local key pair generation, AAA EAP profile, 22
490 testing
triple authentication basic configuration, 285 AAA RADIUS server status detection test profile,
triple authentication configuration, 283, 285, 23
285 FIPS conditional self-test, 622
triple authentication configuration FIPS power-up self-test, 622
(authorization VLAN+Auth-Fail VLAN), 289 TFTP
Web authentication configuration, 270, 273 local host public key distribution, 351
Web authentication configuration (local time
authentication server), 278 IPsec IKE negotiation (time-based lifetime), 401
Web authentication configuration (RADIUS SAVI deletion delay, 609
authentication server), 280 Web authentication redirection wait time, 275
T timeout
TCP 802.1X authentication timeout, 124

749
 MAC authentication server timeout, 175 configuration (authorization VLAN+Auth-Fail
SSH server packet DSCP value, 485 VLAN), 289
SSH user authentication timeout timer, 484 configuration restrictions, 285
timer how it works, 283
802.1X authentication timeout, 124 online user detection, 285
802.1X quiet, 126 troubleshooting
AAA HWTACACS real-time accounting, 47 802.1X, 158
AAA HWTACACS server quiet, 47 AAA AAA, 88
AAA HWTACACS server response timeout, AAA HWTACACS, 89
47 AAA LDAP authentication failure, 89
AAA RADIUS real-time accounting, 28 AAA RADIUS accounting error, 89
AAA RADIUS server quiet, 28 AAA RADIUS authentication failure, 88
AAA RADIUS server response timeout, 28 AAA RADIUS packet delivery failure, 88
MAC authentication offline detect, 175 IPsec IKE, 456
MAC authentication quiet, 175 IPsec IKE negotiation failure (no proposal match),
MAC authentication server timeout, 175 456
topology IPsec IKE negotiation failure (no proposal or
MFF configuration (in ring network), 620 keychain specified correctly), 457
MFF configuration (in tree network), 619 IPsec IKEv2, 472
traffic IPsec IKEv2 negotiation failure (no proposal
match), 472
AAA HWTACACS traffic statistics units, 49
IPsec SA negotiation failure (invalid identity info),
AAA RADIUS traffic statistics units, 30
458
IKE-based IPsec tunnel for IPv4 packets, 427
IPsec SA negotiation failure (no transform set
IPsec configuration, 399, 425 match), 458, 472
IPsec IKE negotiation (traffic-based lifetime), IPsec SA negotiation failure (tunnel failure), 473
401
MACsec, 650
IPsec RIPng configuration, 430
MACsec device cannot establish MKA session,
IPsec RRI configuration, 419, 433 650
IPsec tunnel configuration for IPv4 packets PKI CA certificate import failure, 396
(IKE-based), 454
PKI CA certificate obtain failure, 394
IPsec tunnel for IPv4 packets (manual), 425
PKI certificate export failure, 397
traffic monitoring
PKI configuration, 393
MFF configuration, 615, 616, 619
PKI CRL obtain failure, 396
MFF configuration (in ring network), 620
PKI local certificate import failure, 397
MFF configuration (in tree network), 619
PKI local certificate obtain failure, 394
transform set (IPsec), 408
PKI local certificate request failure, 395
Transmission Control Protocol. Use TCP
PKI storage path set failure, 398
transporting
port security, 321
IPsec encapsulation transport mode, 400
port security mode cannot be set, 321
trapping
port security secure MAC addresses, 322
AAA RADIUS SNMP notification, 41
portal authentication, 267
IPsec IKE SNMP notification, 450
portal authentication cannot log out users (access
IPsec SNMP notification, 423 device), 267
port security SNMP notification, 311 portal authentication cannot log out users
triggering (RADIUS server), 268
802.1X authentication trigger, 135 portal authentication no page pushed for users,
FIPS self-test, 626 267
triple authentication portal authentication users cannot log in
authorization VLAN, 284 (re-DHCP), 269
basic configuration, 285 portal authentication users logged out still exist on
configuration, 283, 285, 285 server, 268

750
 Web authentication, 282 display, 607
Web authentication failure to come online, 282 enable (global), 607
tunnel enable restrictions (global), 607
IPsec tunnel max, 423 network application, 606
tunneling user
IKE-based IPsec tunnel for IPv4 packets, 427 802.1X concurrent port users max, 136
IPsec configuration, 399, 425 802.1X online user synchronization enable, 134
IPsec encapsulation tunnel mode, 400 802.1X reauthentication, 125
IPsec RIPng configuration, 430 802.1X user logging enable, 144
IPsec RRI, 404 AAA concurrent login user max, 62
IPsec RRI configuration, 419, 433 AAA local user, 16
IPsec tunnel configuration for IPv4 packets AAA management by ISP domains, 11
(IKE-based), 454 AAA management by user access types, 11
IPsec tunnel for IPv4 packets (manual), 425 AAA user role authentication, 11
troubleshooting IPsec SA negotiation failure allowing only DHCP users to pass portal
(tunnel failure), 473 authorization, 225
U ARP attack detection user validity check, 577
ARP attack detection user validity check (VSI),
UDP
581
AAA RADIUS implementation, 2
ARP attack protection configuration (user+packet
AAA RADIUS packet format, 4 validity check), 584
AAA RADIUS request transmission attempts ARP attack protection user validity check, 583
max, 31
enabling logging for login/logout, 233
AAA RADIUS session-control, 40
MAC authentication online user synchronization
uncontrolled port (802.1X), 99 enable, 183
unicast MAC authentication request user IP address, 186
802.1X unicast trigger mode, 105, 135 MAC authentication user logging enable, 190
SAVI configuration, 608, 608, 610 port security client userLoginWithOUI
SAVI configuration (DHCPv6+SLAAC), 613 configuration, 314
SAVI configuration (DHCPv6-only), 610 port security user logging enable, 311
SAVI configuration (SLAAC-only), 612 port security userLogin 802.1X authentication
Unicast Reverse Path Forwarding. Use uRPF mode, 297
unit port security userLoginSecure 802.1X
AAA RADIUS Remanent_Volume attribute authentication mode, 297
data measurement unit, 35 port security userLoginSecureExt 802.1X
updating authentication mode, 297
passwords, 329, 329 port security userLoginWithOUI 802.1X
uploading authentication mode, 297
SFTP local file, 494 portal authentication authenticated user
redirection, 215
URL
portal authentication online user logout, 232
802.1X authentication+redirect URL
assignment, 117 portal authentication roaming, 225
MAC authentication CAR attribute assignment, portal authentication user access control, 220
169 portal authentication user online detection, 226
MAC authentication redirect URL assignment, portal authentication user setting max, 223
169 portal authentication user synchronization, 229
MAC authentication Web proxy port URL RESTful server-assisted MAC authentication user
redirection configuration, 189 recovery configuration, 188
uRPF SSH online user max number, 485
application scenario, 606 SSH session disconnect, 485
check modes, 606 SSH user configuration, 482
configuration, 606 SSH user connection control ACL, 484

751
 Web authentication user online detection, 276 user policy+QoS policy configuration, 324
Web authentication user setting max, 276 username
user access 802.1X client username+password configuration,
DHCP relay agent-based dynamic IPv4SG 652
configuration, 562 AAA HWTACACS format, 49
DHCP snooping-based dynamic IPv4SG AAA RADIUS format, 30
configuration (wired network), 561
V
DHCPv6 relay agent-based dynamic IPv6SG
configuration, 565 validity check
DHCPv6 snooping-based dynamic IPv6SG ARP attack detection packet, 579
address binding configuration (wired network), ARP attack detection packet (VSI), 582
563 ARP attack detection user, 577
DHCPv6 snooping-based dynamic IPv6SG ARP attack detection user (VSI), 581
prefix binding configuration (wired network), ARP attack detection user validity check ingress
564 port, 581
IPSG configuration (wired network), 551, 560 ARP attack protection configuration (user+packet
static IPv4SG configuration (wired network), validity check), 584
560 ARP attack protection user, 583
static IPv6SG configuration (wired network), verifying
563
PKI certificate, 372
user account
PKI certificate verification (w/o CRL checking),
MAC authentication user account policies, 373
159
PKI certificate with CRL checking, 373
MAC authentication user account policy, 174
version
user authentication
AAA LDAP, 52
password control blacklist, 330
VLAN
password control configuration, 328, 332, 338
802.1X authentication guest VSI+authorization
password control parameters (global), 333 VSI configuration (MAC-based), 151
password control parameters (local user), 336 802.1X authentication+ACL assignment
password control parameters (super), 337 configuration, 149
password control parameters (user group), 802.1X Auth-Fail VLAN, 110, 128
335 802.1X Auth-Fail VLAN (MAC-based access
password event logging, 331 control), 111
password expiration, 329, 329 802.1X Auth-Fail VLAN (port-based access
password expiration early notification, 330 control), 110
password expired login, 330 802.1X Auth-Fail VSI, 115
password history, 330 802.1X authorization VLAN, 106
password max user account idle time, 331 802.1X authorization VLAN configuration, 147
password not displayed, 331 802.1X authorization VLAN port manipulation,
password setting, 328 108
password updating, 329, 329 802.1X critical VLAN, 111, 129
password user first login, 330 802.1X critical VLAN (MAC-based access control),
password user login attempt limit, 331 112
password user login control, 330 802.1X critical VLAN (port-based access control),
111
user login with weak password, 331
802.1X critical voice VLAN, 113, 130
user profile
802.1X critical voice VLAN (MAC-based access
802.1X authentication+user profile
control), 113
assignment, 117
802.1X critical voice VLAN (port-based access
configuration, 323, 323, 324
control), 113
display, 323
802.1X guest VLAN, 109, 126
MAC authentication user profile assignment,
802.1X guest VLAN (MAC-based access control),
168
110

752
802.1X guest VLAN (port-based access triple authentication server-unreachable VLAN,
control), 109 284
802.1X guest VLAN assignment delay, 127 Web authentication Auth-Fail VLAN, 272, 277
802.1X guest VLAN configuration, 147 Web authentication authorization VLAN, 271
802.1X local VLAN authorization, 107 VPN
802.1X protocol packet VLAN tag removal, AAA HWTACACS scheme VPN instance, 47
139 AAA implementation, 13
802.1X remote VLAN authorization, 106 AAA RADIUS scheme VPN instance, 26
802.1X VLAN manipulation, 106 AAA VPN implementation, 13
802.1X VSI manipulation, 113 IKE-based IPsec tunnel for IPv4 packets, 427
DHCP snooping-based dynamic IPv4SG IPsec configuration, 399, 425
configuration (wired network), 561 IPsec RIPng configuration, 430
IPSG configuration (wired network), 551, 553, IPsec RRI, 404
560
IPsec RRI configuration, 419, 433
IPv6 ND attack defense configuration, 595
IPsec tunnel configuration for IPv4 packets
IPv6 ND attack defense RA guard (IKE-based), 454
configuration, 601, 603
IPsec tunnel for IPv4 packets (manual), 425
IPv6 ND attack detection configuration, 599
PKI application, 361
MAC authentication authorization VLAN, 161
VSI
MAC authentication authorization VLAN port
802.1X authentication guest VSI+authorization
manipulation, 162
VSI configuration (MAC-based), 151
MAC authentication critical VLAN, 164
802.1X Auth-Fail VSI, 131
MAC authentication critical VLAN
802.1X authorization VSI, 114
configuration, 178
802.1X critical VSI, 115, 132
MAC authentication critical voice VLAN, 165
802.1X guest VSI, 114, 130
MAC authentication critical voice VLAN
enable, 179 802.1X guest VSI assignment delay, 131
MAC authentication guest VLAN, 163, 177 802.1X manipulation, 113
MAC authentication guest VLAN MAC authentication authorization VSI, 166
reauthentication, 177 MAC authentication critical VSI, 167
MAC authentication local VLAN authorization, MAC authentication critical VSI configuration, 181
162 MAC authentication guest VSI, 166, 180
MAC authentication port guest VLAN, 177 MAC authentication guest VSI reauthentication,
MAC authentication remote VLAN 180
authorization, 161 MAC authentication manipulation, 165
MAC authentication VLAN assignment, 161 MAC authentication port guest VSI, 180
MAC authentication VSI manipulation, 165 port security escape critical VSI, 310
MFF configuration, 615, 616, 619 VXLAN
MFF configuration (in ring network), 620 802.1X support, 113
MFF configuration (in tree network), 619 MAC authentication support, 165
port security free VLAN, 308 W
port security secure MAC address, 302
WAPI
port security secure MAC address add, 303
PKI configuration, 359, 361, 376
portal authentication roaming, 225
Web
static IPv4SG configuration (wired network),
560 cross-subnet portal authentication configuration,
244
static IPv6SG configuration (wired network),
563 direct portal authentication configuration, 235
triple authentication Auth-Fail VLAN, 284 direct portal authentication configuration (local
portal Web service), 264
triple authentication authorization VLAN, 284
extended cross-subnet portal authentication
triple authentication configuration
configuration, 255
(authorization VLAN+Auth-Fail VLAN), 289

753
 extended direct portal authentication user setting max, 276
configuration, 248 VLAN assignment, 284
extended re-DHCP portal authentication VLAN assignment support, 271
configuration, 251 Web proxy
local portal authentication service, 213 MAC authentication Web proxy port URL
local portal Web service, 205 redirection configuration, 189
PKI, 361 Windows
portal authentication configuration, 203, 209, 2000 PKI CA server SCEP add-on, 362
235 2000 PKI entity configuration, 362
portal authentication extended functions, 203 2003 PKI CA server certificate request, 379
portal authentication local portal Web service 2003 PKI CA server IKE negotiation+RSA digital
page customization, 205 signature, 386
portal authentication local portal Web service WLAN
parameter, 216
802.1X overview, 99
portal authentication redirect, 234
port security client
portal authentication server detection+user macAddressElseUserLoginSecure configuration,
synchronization configuration, 259 317
portal authentication system, 203 port security client userLoginWithOUI
portal authentication Web proxy support, 222 configuration, 314
portal authentication Web server (interface), port security configuration, 295, 299, 312
217 port security MAC address autoLearn
portal authentication Web server detection, configuration, 312
228 working with
re-DHCP portal authentication configuration, SSH SFTP directories, 493
241
SSH SFTP files, 494
remote portal authentication Web server, 212
triple authentication configuration, 283, 285, X
285 X.500
troubleshooting 802.1X EAD assistant URL AAA LDAP implementation, 8
redirection failure, 158
Web authentication configuration, 278
Web authentication
authentication-free subnet configuration, 276
Auth-Fail VLAN configuration, 277
authorization ACL support, 272
configuration, 270, 273, 278
configuration (local authentication server),
278
configuration (RADIUS authentication server),
280
display, 278
domain specification, 275
enable, 274
local portal service, 274
process, 271
proxy support configuration, 277
redirection wait time, 275
server configuration, 274
system components, 270
troubleshoot, 282
troubleshoot failure to come online, 282
user online detection, 276

754